Virtual Teams, do they perform? Or….

With the advent of Covid-19, most teams in practically every industry have been hard-hit with uncertainty on how to sustain performance and ensure they remain actively engaged to the goals. Stakeholder satisfaction has gone south for most of these teams and it is increasingly becoming frustrating for leadership to regain their glorious past of co-located teams. Talking to one of my friends who is a project manager, he told me “I have simply lost it. Nothing is working anymore, and our backlog looks like a jungle.” This is not unique for only this team but is something that most teams are continuously experiencing. It is even worse for teams that previously were struggling to function when they were co-located and have now been thrown in unfamiliar territory. Within the last two years, my experience with other teams has shown that there is a myriad of challenges but there are some which are common, despite the industry the team is working in. I will highlight 3 of these issues and then in my next series, I will address my supposed approach to handling them.

Lack of unified goals

It used to be easy to define a goal around which a team could rally their focus while working on a set of issues. In Scrum, this has always been the norm before any set of issues are chosen by the team. The product owner defines the goal and a whole list of prioritized issues from which the team chooses, based on their understanding of these issues and their velocity. Arguably, most teams did not find this to be an issue and it is quite impressive that Agile defined this approach so well, addressing the traditional centralized authority. However, while working remotely, it is increasingly becoming difficult to have an understandable unified goal which teams can use to deliver the next increment. This is not because they don’t communicate, but it is because the level of team engagement has been severly compromised, that most people find it frustrating to remain actively motivated. I have seen fluffy sprint goals such as “Solving issues from Revision 3.2.4“. The problems with such goals are that they create dependencies and do not really motivate the team. Some of the goals are defined based on a single stakeholder feedback, which in actual sense creates imbalance in stakeholder satisfaction. By using feedback from a single stakeholder, the whole team gets blinded to the needs of the whole stakeholder fraternity across the spectrum. There is a genuine need that goals aren’t individual-centered, if the whole team is to gravitate their efforts around them to achieve satisfaction equilibrium.

Lack of Support from Top Management

Teams working without the support of the top management are prone to experience instability and disruptions within their iterations. This is commonly in the form of in-coming work from customers and colleagues, urgent hotfixes, or even changes of the team’s plan by the management. Such teams suffer from being unable to execute their work within locked timeframes that allow them to deliver an incremental release of the product. When management is not in tandem with the activities of the team, do not participate in reviews nor are they aware of the current status, then the two units drift apart. It is common to see efficient agile teams being managed by leaders with old-mentality of project management. This causes rifts in achieving any meaningful progress, mostly because the team feels that they are not respected by the management and their efforts are not appreciated. The bigger and “ugly” caveat is that the team finds it difficult to tie their activities to the goals and objectives defined by the management. On the lower side, it leads to a frustrated team at a crossroads on achieving their sprint goals and satisfying the demands of the management. On the upper side, it leads to an organization that cannot adapt appropriately to changes, failing in achieving to align the teams’ activities to the strategic goals and non-achievement of BRM.

Sect-like/Religious practice of Agile

While agile is flexible and can be customized to different industries, it is not uncommon to see teams embracing agile and following it rigidly. Often, when top management advocates for teams to embrace agile, there is a poor change management process to help the team transit to the new way of working. If the team does not understand why they should use agile, or the activities and ceremonies of agile are followed in a sect-like manner without any understanding, it is doomed to fail. Team members sooner or later feel the pressure to deliver incremental value during each sprint. It feels like being put on a pedestal without having any room to gasp for air. Working virtually, compounds the problem because the team members lack face to face interaction (one of the 12 agile principles). Additionally, it introduces long waiting times that delay the workflows. Teams should be allowed to embrace agile and suit it to achieve their objectives. Sure, this does not mean compromising on the activities or goals of the team, but by remembering the 4 values of agile, it is believable that agile can be embraced even by the faint-hearted. The beauty of agile is seeing the incremental value the team produces at regular intervals. Combined with the transparency of the team’s progress, it enables the team to be reflective and adaptive, ultimately becoming even more productive. The team should be able to see the outcome of their activities and relate to the goal they are achieving, and whether it is delivering value or not.

Clarity In The Steamy Channel…

Getting a team to transit from their old working ways and embrace a new “unorthodox” way of working is never easy and requires patience. The team I have been working with has proved to be the exact opposite of what I expected. While I was initially optimistic that things would sail with less opposition from the team, it has actually turned out to be a daunting task. Moreover, the leadership is curious to see if there is anything coming out of “the many meetings” and has continuously urged me to train the team but reduce the frequency of the meetings. I find it contradictory that the team should be “trained” but at the same time they should be allowed to “work” in a domain where there is almost zero collaboration. Withut causing unnecessary extra pressure, I decided to spend time to understand the dynamics of the team. I did not want to come in with past experience from other teams, ut decided to first and formost understand the challenges that the team was facing. What problems did they have and why was I involved. The latter part was particularly important for m to hear it from the horsens mouth. Firstly, at the team level, and secondly from the leadership level. This was crucial in finding out where the disconnect came from and how this could be bridged. Over the last one month, I came to learn several important issues that the team was unknowingly struggling with. I narrowed down on what I considered was the most significant ones, in terms of productivity and harmonization of team efforts.

Disoriented Management or Absurd Company Culture?

I knew from the beginning that to have success on this mission, I had to win the management’s support. While talking to the project owner it occurred to me that he was not actually keen on having the status qúo change, but yet wanted to see improvement in the team. On the other hand, the project sponsor was laid back and trusted the project owner with the decisions he made. This was unsettling, to know that power was vested in one center and I had to spend more time working from his perspectives, even when I knew that they were counter productive. It was indeed an absurd company culture that was causing quire resentment especially at the team level but no one dared raise issues about it. The team did not feel psychologically safe to address these issues. But I knew that it was a safe approach if the management was to be convinced that there was need for change.

Secondly, decisions were frequently being made and changed without involving the team. It made the management appear undecided and unsure of the direction they wanted to take. Agile advocates for adaptation to uncertainity but it also highlights the importance of inclusivity and dolving decision making. It was quite odd to see that team members would need permission to make tactical decisions which affected their productivity level. Developing a tool to be used by the team, would require managements permission to spend time on that, and even then it would need to be scrutinized closely, planned at a detailed level and then strict time estimations were then provided. Phew!!! That was hard for the team but looked like they had resigned to fate.

I have now had two meetings with the business sponsor, business owner and the scrum master to raise this concern. Using this approach, I intend to introduce inclusivity in decision making. I do acknowledge that there will always be strategic decisions and tactical decisions, and my desire is that these two levels should co-exist harmoniously where the actors in each domain feel included. The meetings have been positive so far, and I have been facilitating it with the knowledge that there is need to improve psychological safety and empower the scrum master to not only feel like a participant but an active representer of the team. We have joint meetings on Fridays just before midday, and it is one of the meetings I always look forward to.

Lack of visualization

The second problem that I noticed was that the projects and tasks that the team worked on was not visualized on a common platform where the team and the management could have a common focus on. Borrowing from Lean’s principle on mapping value streams to actual actions needed to satisfy the stakeholders, it was apparent that lack of visualization was a problem. I soon started to understand why the management changed thei minds frequently and the team was informed in the last minute. It also began to make sense, on the couple of times that the team members would unknowingly be working on duplicate tasks or get derailed on side tasks that did not add any value to the customers. The scrum master was mostly working using spread sheets to keep track of what they were working on, but this was not visualized to the team. After a weekly meeting, the scrum master would update the spreadsheet to mirror the progress the team had made. What was puzzling was that the scrum master then had to meet the project owner and discuss the progress based on the reportings made in the spreadsheeet. My curiosity got me thinking, how much misinformation could be taking place by having the “middle-man” in the process. To increase the complexity of the process, the project owner would then use a copy of the spreadsheet to communicate to the project sponsor. It became apparent that this process introduced other underslying challenges; Missing expectations management between the team and the leadership occassioned by the absence of a common alignment, poor understanding of what the different team members were working on and lack of commitment due to absence of a common goal in between the sprints. Goals were defined for each quarter but then that was it. There was no further breakdown.

I raised these observations with the scrum master and why it was important to have a web platform that could visualize what the team was working on. Her major reservation at this point was that management would now be willing to spend on a platform that they felt was nott improving any value. Secondly, she also felt that it might take a long time to know how the platform was working. After much talk the last three weeks, we finally decided last week to start with JIRA, which I recommended due to its simplicity and also because they could get a free version for limited users. We have created users in the platform and the team is now able to see what each other is working on. there is a sense of curiosity and eagerness in the team. For the first time, they are feeling a sense of unity is starting to creep in, creating impact in their working approach and I am happy to see that we are slowly turning the wheel towards the right direction. Albeit for now. Will it be a success? I bet so. the enthusiasm in the team can be smelled miles away.

Have you had similar challenges? How did you approach them with your team? I would like to hear from you, please share your comments

Challenges in Going Agile

This week has been a fascinating one, packed with suspense and speculation. I have supported a team that is transiting to Agile from a chaotic state and I came face to face with the challenges of embracing change within a team and at the leadership level. I have seldomly worked with this team, but it is the first time I am getting to understand their working process. It is a team comprised of 6 developers and a product owner. One of the developers doubles as a Scrum master and is the one pushing the team to embrace Agile. While there are a few baby steps that the team has made, they are still in the dark about what to expect and what to do. I had the following observations, which made me wonder how other teams experienced their transition to Agile.

Leadership

The “Scrum Master” has been tasked with streamlining the team and coaching them on the benefits of transiting to Agile. However, a caveat in this approach is that the leadership has a laid-back approach and is also pessimistic on whether there is any value coming out of the process. The team has been in existence for the last 5 months, and the leadership is yet to officially communicate to the team why they believe that they should go Agile. What happens to a team where they can clearly see that the Leadership is paying lip service to the process, but going contrary to what they are advocating for? There will be lackluster in the team and however much the Scrum Master works hard to help the team embrace Agile, it will be an exercise in futility. Because human beings naturally tend to be followers, the leadership has to be supportive of the process if they are to exceed. In his 2014 book, Accelerate, about Change Management, Dr. Kotter observes that Leadership involvement is necessary if real change is to happen and the value sustained so that things do not ultimately drift back to default status. This team needs the leadership to step up and back the efforts being made to transit to Scrum way of working.

Overachieving

While the leadership is skeptical of the process, the “Scrum Master” is an overachiever who is so zealous to get the process injected into the team. She has been busy having uncoordinated meetings with her team and shoving down their throats on what is Agile and what is not Agile. Interestingly, she gets mixed on her own facts and when asked about the claims, she has a standard answer “That is what we will do for now”. This has left the team frustrated and feeling hopeless about the situation. This is because the developers believe they have proper control of their workspace and understand what is needed of them.

The team members have occasionally stopped me at the coffee machine or in the corridors to ask whether “this and that” is Scrum practice or not. While in some situations I have been able to answer them, in most cases I think their concerns are genuine and I always end up telling them that Scrum by definition is a Guide and should not be used as a metric standard for working in a team. For example, if I am driving from Copenhagen to Hamburg, I know that the GPS will guide me through the most convenient route, but I have to define the criteria for convenience. But this in itself is just a guide. I could drive from Copenhagen to Odense on the highway, and then drive along the countryside for the next 30Km, drive from small cities to cities in the next 50Km and then round it up again on the highway. What matters is does the route suit me and my passengers? Are we in a hurry to come to the destination or we would like to explore the routes as we drive? Are we willing to have some stop-overs along the routes to drop or pick someone? These specifications will define the parameters for my “convenience” criteria. Similarly, when starting out on Scrum/Agile, the Scrum Master does not have to whip the team to abide by all the practices that are embodied in Scrum. Start with small practices, ensure transparency in the process and importantly help the team to understand WHY they are doing something. Surely, not all practices will be suitable for the team from the beginning, especially the ceremonies. So, allow them to Inspect the processes and Adapt as they go along the way.

When starting on Scrum, I advise teams to take a stance of zero heroism. No matter how much a team member understands Scrum, the ultimate reason of engaging the team is to work collaboratively and keep on improving the process at a sustainable pace and continuously satisfy the stakeholders. This is analogous to being a top scorer in a football team that is under threat of being relegated from the league. It is then better not to score a goal for a whole season, but support your team to avoid being relegated from the league. Being a top scorer and the team is in relegation zone, earns the team no credit. Zero heroism!!

How did you transit to Agile and which practices were difficult for you to embrace? Have you finally embraced them in your processes and how do you handle lack-lusture leadership and/or overachieving Scrum masters? Please share your thoughts and comments

Team Building from Scratch….

I have been away for quite some time and it is refreshing to come back again to what I like and enjoy the most. My summer break was quite fun, enjoying it with the kids and had a road trip to Berlin. Everything has come back to normal and even with Covid-19, the rules have been removed. We are slowly going regaining normalcy again and hopefully businesses are starting to see early signs of positive trends. When I talk with my friends across different industries, it is apparent that most of us are hopeful of how things are unfolding, and remain very optimistic, that the dragon has been slain.

While at it, I have been assigned two project teams that have varying level of maturity when working with projects. One of the teams is co-located and the other one is a virtual team, where we interact online. Any project manager, will tell you that this is a nightmare and it is no easy task. The virtual team composes of competent individuals, who unfortunately are not used to working within a project framework and “Teaming” is alien to them. The leadership is also wanting in communication and planning is just a buzz word for them.

The co-located team is also competent, have a fair knowledge of what it means to work in a team and have the advantage of a fairly supportive leadership. The team is not so much cross-functional and it means that I have to play a double role, assisting with the technical stuff as well. I am aware that double-dealing contradicts the tenets of psychological safety, but then again I am at a crossroad on how to support the team to achieve stability. Recently I have been revising the “Servant leadership” approach of leading to understand how to approach the situation and I am happy I got some good insights.

So, I am currently meeting the team members individually to understand them and create a bonding session. I want to establish a platform where we can leverage each others strengths and form a strong coalition where the team members feel safe to operate in. Within the last two weeks, this has gone so well and I have also had online meetings with the virtual team. All is not rosy, but it is not bad either. One of the greatest tools from project management that has been of great use is LISTENING. It feels so refreshing to hear team members open up about the pains and troubles they are experiencing, and yet they remain optimistic that I can be a core player in finding a solution. I am also finding the skills of Decision-making coming into play, being applicable in areas where there is need to elicit more information from stakeholders. I remain positive, that the experience I have and the knowledge acquired, will be feasible in helping the teams to have a conducive environment. So far, I am avoiding situations where my teams feel cornered and have to play along my rules. I try to facilitate the meetings and hear the participants’ corncers’ and then finally voice my thoughts as well. It is working well so far, and participants are sharing their thoughts out.

This, my friends, will be interesting. Follow me on this journey of “Team Virtual” and “Team Office”.

PMBOK 7th Edition

It has been a long wait for the new edition of PMBOK guide, which is set to be released very soon. According to PMI, this was delayed to January 2021 and it will only be fair to say that it should now be almost out. It is understandable that COVID-19 has disrupted businesses worldwide, but as we inspect the current status and adapt to the new status, we have to be agile. The new PMBOK 7th edition departs from the previous editions that were based on the 10 knowledge areas (Integration, Scope, Schedule, Cost, Quality, Resources, Risks, Stakeholders, Communication and Team) and 5 process groups (Initiation, Planning, Execution, Monitoring and Controlling, and Closing) to principles.

These principles are more centered around working with other stakeholders and most IMPORTANTLY sends the message of value delivery. This is a departure from the 6th edition which was mostly corncerned about processes, input, outputs, tools and how the different project phases interacted. PMI, however, has been very fast to underline that the previous project management approaches should not be rendered invalid, rather they are a building block to what the new edition advocates for. As an agile enthusiast, I am keen to see how what the new edition brings on the table. I am especially keen to see if and how they explicitly address risk management, cost management and procurement, something that the current Agile manifesto (2021 release) does not explicitly talk about. I have a feeling that the new edition also integrates Lean into the 12 principles (Stewardship, Team, Stakeholders, Value, Holistic Thinking, Leadership, Quality, Tailoring, Complexity, Risks – Opportunities and Threats, Resilience & Ability, and application of change management). Project managaement is taking a new turn and we have to be more agile than ever before. Let me know what your feelings and thoughts are about the new PMBOK 7th edition release.

Major Reasons for Projects’ Failure

I have been blessed to work in the IT industry now for over 12 years and have been part of numerous projects. I have worked with both IT and business people and taken part in many projects. Throughout this journey, I have used both the traditional project approach and Agile approach (read Vanilla scrum). One thing that I have learned is that projects can easily be derailed and can easily fail even when the project team believes that they have done their best.

Often, there are early pointers that are not heeded until it is late and that is why projects easily fail. Frankly though, there are times when the project team has done their best, but then other circumstances beyond their control leads to project failure. As a project manager, Product owner or Scrum master, there are certain things which you can spot, that can help you to take action early enough to avoid such failures. In traditional project management, initiation and planning is always done upfront, which helps to reduce uncertainty but then the project becomes rigid to mid-stream changes. This can both be good and bad for the project depending on the project type, stakeholders, organizational strategy and culture, project duration and so on. Agile on the other hand introduces flexibility to accomodate change and reduce uncertainty. It’s inbuilt monitoring and control integrates risk management which reduces failure rate but then this is not feasible in all kinds of projects. From my experience, the following are the common major reasons for project failures regardless of whether the project is plan-driven or value-driven:

Failure to focus on business value and focusing instead on technical detail. This is quite common where the project team is highly involved in the project management and the project manager/product owner cedes some authority or is under involved. In the worst case scenario, the team could be comprised of inexperienced members, unaware of what is expected of them. In a past project, I have experienced project teams working without understanding their contribution to the business value. As a developer, one easily slides into technical field where one is familiar with the working of the project and easily sidelines the business part. The end result is that there is no well-established and clear link between the project and the organizations key strategic practices. The project plan needs to cover the planned delivery, the business change required and the means of benefits realization.

Lack of properly established clear accountability for measured results. The management (PMO) must support project managers by creating a clear view of the interdependencies between the projects, the benefits, and the criteria against which success will be judged. It is necessary to establish a reasonably stable requirement baseline before any other work goes forward. Requirements may still continue to creep. In virtually all projects there will be some degree of “learning what the requirements really are” while building the project product.

Inconsistent processes for managing unambiguous checkpoints. Projects are often marred with unambigous checkpoints , from procurement to complex decision making. Successful large or medium sized projects usually have software measurement programs for capturing productivity and quality historical data that can be sued to compare it against similar projects in order to judge the validity of schedules, costs, quality, and other project related factors. The lack of effective quality centered mechanisms can be a major contributor to both cost and schedule overruns. project managers should learn how to use their lessons learned register or scrum masters should also used retrospectives and daily scrum meetings to gather information and use the PDSA Deming’s cycle throughout the project to ascertain project progress.

Poor and inconsistent methodology for planning and executing projects. There should be a detailed plan developed before any release date of a project is announced. both plan-driven and value driven should incorporate this in their working processes. It is not unusual to hear extremists insist that agile is not about planning. I differ with this and underline that agile actual has more planning than traditional project managerment. The difference is that they don’t do alot of upfront planning, rather it is “just-in-time” planning and with less documentation. But it has numerous integrated planning processes in a project lifetime. Again, inadequate planning is one of the major reasons why projects spin out of control, whether early or in the latter phases of the project.

Include the customer at the beginning of the project and continually involve the customer as things change so that the required adjustments can be made together. It has been observed that successful projects occur when end users (customers) and the project members work as teams in the same cubicle, although this is not always possible. Projects are less likely to fail if there are informed customers giving meaningful input during every phase of requirements elicitation, product description and implementation. The customer needs to be asking, “how are the project result used over time and what do I get out of the results?

Failure by the project manager or Scum master to manage and motivate people so that project efforts will experience a zone of optimal performance throughout its life. This involves managing and retaining the most highly skilled and productive people. Knowledge is money. A project team made up of higher paid people with the right specialized skills is worth more per dollar than a group of lower cost people who need weeks or months of training before they can start to be productive.

Lack of tools and techniques to produce consistently successful projects. The project team must be skilled and experienced with clear defined roles and responsibilities. If not, there must be access to expertise which can benefit those fulfilling the requisite roles. This reinforces the first point above on the damage that incompetent team members have on a business.

There are definitely other reasons that could underline why projects fail, depending on several other parameters. However, this article has focused on the most common ones that override the project type, organizational size and so on. So what made projects fail in your team, in the past? Please share.

Work Breakdown Structure in Agile Project Management

Last year, I wrote a post about the Work Breakdown Structure (WBS) which opened let to many questions from my readers on how this differs between the traditional project management approach and the agile management approach. One reader in particular asked whether WBS is still valid in today’s project management industry, considering the vertality of the industry. I have summed up the discussions sent by mail, to make an open discussion on this topic in both the traditional and agile approach.

While WBS is importand as part of the scope baseline, it is true that it can be demanding in agile, especially because agile is founded on the tenets of acceptance to change. This is because, it is not necesarily the same activities that have been defined in the WBS that will be the same for deliverables that lie further into the future. The same deliverable may be delivered, but the activities may have changed in the course of the project.

The work breakdown structure (WBS) as used in the traditional planning, is good at identifying the actual tasks to be performed as identified in the project scope statement, easing tasks-assignment to team members, ultimately helping them to identify how their contribution fits into the big picture (PMI, 2006, pp. 5-7). This boosts team-morale and productivity. Additionally, its use to create a detailed action plan also contributes in safeguarding continuous progress towards earning value as each team member works on an assigned task. The structure acts as an assurance that the project scope is decomposed to cover all the necessary activities to be
performed in completing a deliverable (PMI, 2017, p. 158). This is important in the efficient management of resources, since it relies on a realistic project plan constructed from the structure, consequently enhancing accountability and transparency. Moreover, since it provides an overview of the activities required to contribute to the project’s goal, it reduces the burden of tracking how well each task matches the deliverables. Finally, the structural design of WBS in traditional planning makes it easier to identify potential risks, likelihood of occurrence, and how they can be managed.
The structure however, has a high risk of being too detailed at the work package level, due to poor definition of “done”, making it unmanageable. In such cases, it can easily lead to micromanagement by insecure management, causing resentment and distrust, inefficient resources use, and difficulty in data aggregation over the levels (PMI, 2017, p. 150).
Its’ also cumbersome in managing changes that mirror the actual status of the deliverables due to the time and effort associated with the process, which can be a major shortcoming since projects by nature have a high likelihood of encountering changes. This leads to a derailed WBS that doesn’t reflect the actual status of the project plan especially for changes that lie far in the future, creating room for scope creep, missed deadlines, incomplete deliverables or even budget overrun (PMI, 2017, p. 150). Lastly, it can easily be misinterpreted as a project plan.

PMBOK guide edition 6, discusses about creation of WBS in chapter 5.4 and underpins the importance of WBS as providing a framework of what is to be delivered and done once or predefined stages in the lifecycle of a project. It further states that the work packages groups activities where work is scheduled and estimated, monitored and controlled. But it also explicitly states that work in this context is not necessarily the work done but can also refer to the outcome (work products or deliverables) and not the activity itself. Agile introduces Feature Breakdown Structure (FBS) which enhances this difference.

FBS, instead of using activities in the control, planning and work packages, it uses features and stories. This distinction is important for the agile team, because they don’t have to worry about the work series to be performed but rather focus on shipping a functional deliverable, within the defined time and resources to meet the defined deliverable objectives. The structure is used in agile approach of planning projects and is centered on user stories
which belie the strength of agile by delivering values to the user at the high level of the hierarchy. This supports continuous delivery and integration, allowing customers to get quicker value, as the team remains focused on delivering shippable products rather than focusing on the work to be done. Unlike in the WBS, this abstraction of implementation from the deliverables is important even for products that lie further in the future, reducing the risk of being derailed from the project scope (Wettergren, 2020). Second, it supports just-in-time story development, eliminating requirements
specification and allows a team to still focus on deliverables while accommodating changes even later in the project.
This enables the team to have better evaluation of the impact of the decisions made at all levels of product development through accommodating improved and detailed definition of deliverables, hence maintaining the relationship between a product deliverable and its constituents (PMI, 2017).
It is useful for expectations and communication management, ensuring that it covers not more or less than defined in the project scope to meet stakeholders’ expectations. Similar to WBS, it helps the team members to have a clear understanding of their roles and when a deliverable is considered complete due to early definition of “done” for a deliverable. This boosts their confidence of project understanding, accountability, and transparency. (Dean Leffingwell, 2009). This also ensures that the development of the product has the right people involved and they are communicating together.
On the other hand, since it focuses on deliverables, there is a high risk of losing focus on how much details may be necessary to achieve the completion of a feature. It may be difficult to find a good estimation of deliverable decomposition to reach a “done” status. (Wettergren, 2020). Another shortcoming is that it fails to show dependencies between features.

So there it is, the discussion between advantages and disadvantages of WBS and FBS in the traditional project planning and agile project planning. What is your take?

Tools of decision-making as a manager

Making decisions in an organization is partly an art but also a skill that can be perfected over time. A quick recap one of my previous posts, where I explored decision making in organizations and the conditions necessary for making sound decisions. These conditions were named as evidence, authority and process. From the executive to the components and to employees, this is something that an organization should be keen to enforce in its company-culture. PMI advocates for the use of Code of Ethics and Professional Conduct to instill confidence in project management and help leaders make sound and wise decisions without compromising their integrity, PMBOK 4th Edition (2017). The complexity of decisions made in an organization scales with the management level in an organization. At the portfolio level, it is critical that the portfolio manager makes the right decisions when pairing projects to organizational strategies and choosing the right projects. As a project manager, it is also important that the right decisions are made in the management of projects. Employees should also make the right decisions when executing their job to safeguard the quality of the product or services they are working on.

To make a decision, one should evaluate on the nature and significance of the problem at hand. Programmed decisions are routnious in nature and are taken within the specified procedures. They are made with regard to

routine and recurring problems which require structured solutions. A manager is not expected to go through the problem solving procedures continously make programmed decisions. On the other hand non-programmed decisions are associated with unique problems that are non-repetitive. There are zero to very limited information and knowledge about such decisions. These kind of decisions are made under unfamiliar circumstances using new techniques. The standard and pre-determined procedures and rules are rendered ineffective because every decision will have to be taken separately. Such types of descions are meant for solving unstructured problems which keep on changing from time to time.

There are quite a number of tools and techniques that can be used in decision making that PMBOK suggests, which can come in handy. Some of the most effective and popular decision making tools include:

Cause and effect diagram: Also known as a fishbone diagram. It is very effective when the casue of a problem is to be found out In IT industry it focuses on the Big-5 M namely: Machine, Methods, Material (cosumables/information), Manpower and measurement.

Scatter diagram: This is a simple but also effective tool that is used at varying relations between 2 variables to support a decision. In case of investing how they relate, correlation may be deduced from such a graph.

Benefit/Cost ratio: An effective decision tool where finance is involved and there are alternatives. The benefits are calculated and divided with the costs. There is a coeffecient for each alternative and the one with the highest coeffecient is the best alternative. The problem associated with this tool however is that some benefits are not easily calculated such as customer satisfaction.

Histograms. These are used for showing a graphical representation of numerical data especially when there is need to view the number of defects per deliverable, a ranking of the cause of defects, the number of times each process is noncompliant or other representations of project or product defects

Some other effective tools include: weighted scoring models, Net Present Value, Opportunity Costs etc. As a project manager, the tool you choose and the method applied should be guided by code of ethics to improve transparency on the decisions made.

The agile project manager

Project management has today incorporated agility in it’s processes to help the project manager and the stakeholders to have better control of the processes and tools used. Organizations are demanding for better Agile practices that enhances the quality of the deliverables. A project manager has to therefore be willing to put some extra effort in the agile transformation journey if they are to realize any success. The most popular agile mindset used today in most organizations is Scrum, which is touted to encourage continual feedback, iterative development, rapid and high-quality delivery. Unfortunately, companies are rushing to be “Agile”, conducting morning stand-ups but do not actually understand how to go about the whole processes. When I was first introduced to Agile, we had our morning stand-ups and the whole team did not understand why the project manager was “Micromanaging the team” everyday. Most of the time Agile fails because the team is not well trained on what to expect. Some of these pointers are:

Missing discipline: When a team is not trained on the need to track stories, respect definition of “Done” and “Acceptance criteria”, being present on time during stand-ups and finishing tasks on agreed time, then the team will find it wasteful. These have to be adhered to and the project manager has to ensure that he provides the necessary coaching to get the team jump-started when they are slacking.

Continuous coaching: This does not necessarily mean coaching the team on the aspects already mentioned above, but also helping them to understand the business aspects of a project, keeping the inventory updated and addressing other arising team issues.

Absent or insufficient documentation: A project manager who does not keep documentation of anything, is digging the team’s grave. Though Agile advocates for value completed funtionality over comprehensive documentation, the project manager should remember that the aim of having a team is not just to deliver a project but also knowledge-sharing. This should cover technical specifications, test plans and functionality specifications.

Frequent feedback loops: The project manager should encourage rapid feedback loops from stakeholders to ensure that the product becomes stable and robust. Feedback that touches on modification of the project should however be added in the backlog, to be taken together with the whole team and also to prevent project creep.

These are some of the best practices that an agile project manager should ensure he practices to help the team be truly agile. So what tips do you use in your team? Kindly comment, I would like to hear.

Monitoring project progress as a project manager

As a project manager, there are numerous reports one has to file in, every time there is a project at hand. Actually, it is embedded in your work description and will be part of everyday activity. Whether it is reported in small or weekly bits, reporting is inevitable. Effective reports are able to convince the stakeholders to take action resulting in the project moving in the desired direction. One of the worst things that can ever happen in an organization, is to have lazy project managers who do reporting merely because they have to or have been asked to do so. The weekly report should not be made routinely without much impact. The team and the senior leadership should be able to see how the project impacts the strategies of the company and how it helps it realize its benefits. Poor reporting at times have led to candidate projects being denied funding or proposals being rejected.

Some of the most common mistakes that project managers make include

not being detailed enough about what the project details are. This denies the stakeholders the chance to understand the i’s and the j’s of the project. While reporting, the project manager should not only give account of what happened last tme and what they plan to do next, but should also indicate how this fits in with the project management plan, the risk management plan and how the roadmap leading to the deliverables look like. I have seen project managers write reports that you would have thought is a high school essay. Poor description with bare context and denying the audience the chance to get the information.

Thanks to project management standards, this can be done efficiently by following the steps below.

1. The project report while being kept simple, should at least add value by providing an overview of milestones, risks, issues and budgetary information.
2. The background of the project and why it is being undertaken is not and should not be included as part of the project. Remeber that this is execution stage and not initiation stage. The background should definitely be included as part of this report.
3. For transparency, the sponsor and project manager’s name should be included in the report
4. Reports can be boring to read especially for the senior management/executive who have less time. The port should strive to capture eveything in a single page concisely and clearly.
5. High risks that are a threat to the project should be captured, including mitigation measures under consideration.
6. Budget tracking and expenditure should be part of the budget. Is there something that will make the budget exceed beyond the exepcted amount, then it should be included as a risk instead.
7. An overview of major milestones, planned dates for this milestones and a RAG status of each milestone, helps the stakeholders to understand the project’s progression.
8. An evaluation of successes and failures should be included in the plan , to give an overview on recurring/resurgent problems so that the correct action can be taken. Successful projects can be marked for review and eventual learning to be used as a take-away.
9. In a clear and simple language, the report should note the action to be taken i.e. whether the report is for notification purposes or they are to be used for decision making.
10. Whereas it is fashionable to send reports by mails, it is a good practice to provide a summary in the body context of the mail. This is helpful especially in this current era where people use phones for reading mails.
11. Avoid sending breaking news/information on mail before communicating with the stakeholders. A mail on Monday morning about a server that crashed just hours before presentation can be demoralizing. Ensure the stakeholders are informed either face-to-face or by phone before ending mails.

So, which best practices do you follow as a project manager to ensure that the stakeholders are updated? I would love to hear.