Easy in theory, difficult in practice

Part of tailoring our approach to delivering a project needs to consider its relative level of uncertainty. While it is not the only determinant of complexity, uncertainty is certainly a key contributing factor. And while there are other dimensions which need to be evaluated when deciding whether to utilize a predictive or adaptive life cycle, higher uncertainty would be a supporting factor for the latter.

But before finalizing a delivery approach, it is important to confirm that all key stakeholders who are directly contributing to or supporting the project are in agreement about the approach. In securing this agreement, it can be helpful to understand individual perceptions about the project's uncertainty as that may affect the stakeholder's opinion.

For example, if a project manager and team believe that the project possesses a high level of uncertainty yet the sponsor does not, it might be a hard sell to get support for an adaptive approach, especially if the sponsor does not have much experience with such life cycles. Even worse, if some team members feel that the project is quite straightforward and others feel it is highly complex, it can be challenging to get consensus on the approach.

Just asking individuals to give you their assessment of uncertainty is unlikely to be too useful. Anchoring and other biases will affect the outcome and understanding uncertainty at an overall level won't really help.

An alternative would be to start by defining specific areas of uncertainty which would influence how the project gets delivered (e.g. commercial viability, solution feasibility, resource availability) and then to use a similar approach to estimating poker by providing everyone with uncertainty poker cards. These cards could have the following pictures on them to represent different levels of uncertainty:

• A basketball player completing a slam dunk: Complete certainty
• A brick wall with one brick missing in it: Low uncertainty
• A glass which is half-full of water: Moderate uncertainty
• An iceberg with the bulk of the ice underwater: High uncertainty
• A photo of a very foggy road: Complete uncertainty

Key stakeholders will simultaneously vote on how much uncertainty exists about a given area. Similar to estimating poker, after voting, if there is agreement on the level of uncertainty you can move to the next area. If there is significant difference in perceptions for a given area, this becomes a good opportunity to discuss those.

Not only might this technique help to get alignment on the delivery approach, but it may also help to surface invalid assumptions and to address individual fears and doubts.

"Uncertainty is not an indication of poor leadership; it underscores the need for leadership." - Andy Stanley

The WHO recently renamed the virus which had initially been referred to as Novel Coronavirus to COVID-19. While this new name is easier to pronounce and is more specific (Coronavirus being a family of viruses), it is no more informative than its former name. This is surprising given that lethal pathogens from the past few decades had been given much more descriptive names including:

• SARS - Severe Acute Respiratory Syndrome. No confusion about what that disease is all about!
• AIDS - Acquired Immune Deficiency Syndrome. Ditto.
• Ebola - Refers to the geographic region where the disease was first identified
• Legionnaires - First identified by an outbreak in Philadelphia at a convention of the American Legion

So what does this have to do with projects or project management?

In most of the companies I've worked with or for, I've very rarely seen project sponsors exploit the power of effective project names. This is especially true of technology-focused projects. "Upgrade XYZ" is just one of the common yet uninformative names I've seen. I accept that for confidential projects, code names might be warranted but these are usually a very small percentage of most organizations' enterprise project portfolios.

A project name is that first impression which you'll never get a second chance to make. It is the elevator pitch for your elevator pitch about the project.

It is the difference between calling someone a janitor or a health & safety custodian. It is why many companies use the term "QA" rather than "QC" to refer to their testing staff. And, it is that first opportunity we have as leaders to help our team members find the purpose in the work they are doing. And as Daniel Pink has taught us, Purpose is one of the three key ingredients to unleash intrinsic motivation.

So the next time you are assigned to lead a project which has an uninspiring name, use your powers of influence and persuasion to convince the sponsor to change it to something which better describes the purpose behind the project. Come up with a name that captures WHY we are investing in the project rather than WHAT or HOW we are going to deliver it.

Agent Smith, The Matrix Reloaded - "Without purpose, we would not exist. It is purpose that created us. Purpose that connects us. Purpose that pulls us. That guides us. That drives us. It is purpose that defines us."

The January 2020 issue of PM Network provide a case study for one of the 2019 PMI Project of the Year finalists, the Société de transport de Montréal's (STM) eight-year project to modernize the underground Montréal rail system. I have a soft spot in my heart for this system, having spent most of my formative years in Montréal and having been a frequent user of its services while commuting to university and my first job. I always found it to be a clean, safe, efficient and reliable method of getting around the city. As such, it was a bit of a surprise for me to read about the operating challenges faced by the STM in recent years and the anticipated growth projections, both of which were the impetus for this ambitious project.

While this would be considered a small mega-project (CA$2.1 billion), it is still a testament to the team that they delivered it under budget and on schedule utilizing only one percent of their overall contingency budget. The post-project outcomes are also in line with expected benefits.

What impressed me about the case study was the number of practices which were used by the team which we would normally associate with projects following an agile or adaptive life cycle. This includes close collaboration and short feedback loops with customers, building a "whole" team representing all disciplines, performing operator training in parallel with build activities to streamline transition, and encouraging learning from failures rather than hunting for scapegoats.

However, what really resonated with me was the team's commitment to shifting quality left.

During the preliminary qualification phase for the new trains, problems were identified during integrated testing which hadn't been identified in the manufacturer's unit testing of the individual components. Rather than blaming the contractors, STM owned the issue and worked closely with them to fully resolve the issues. While this caused a two year delay to the qualification phase, over the remaining life of the project it resulted in minimal change requests and contributed to acceptance of the trains upon final delivery with no costly late stage rework required.

Complex projects often experience design or other solution-related issues early in their life. While no one likes reporting negative schedule variance, especially at an early stage, if these issues do not get properly resolved, or worse, are ignored to protect schedule performance (and to save executive embarrassment), the cost and schedule impacts will often be much worse later on.

Courage is one of the values of the Scrum framework, but it applies to all delivery approaches. As project managers, we need to have the courage to convince our executives that it is better to slow down now so that we will be able to speed up later.

A stitch in time saves nine!

In 2013 I wrote an article about the advantages and disadvantages of contract project managers.

Competent agile coaches have been in high demand for many years due to the large number of companies across multiple industries who are going through agile transformations.

Scrum asserts that the role of the Scrum Master includes coaching activities and this is fair in small contexts, but in larger organizations early in their journeys to greater agility, a Scrum Master is likely to find they have limited capacity to effectively coach stakeholders beyond members of the development team and Product Owner.

In such situations, a delivery team might try hard to be more agile, but functional managers, executives and other internal and external stakeholders might not be supportive of this transition. Applying Theory of Constraints principles to this situation, a coach would want to identify the primary bottleneck and focus their efforts there.

But should you hire them full-time or on contract?

While all the considerations from my earlier article apply to the role of an agile coach, here are a few more which should be considered before making any decisions.

• Full-time staff tend to go native. Putting aside those truly Quixotic people who tilt at windmills regardless of how long they have been told by others that this is a futile pursuit, for most, after spending sufficient time within an organization, they find it harder over time to continue to challenge the status quo. Complacency is cancer to coaches, and a fixed duration contract reduces the probability of this evil.
• Contract coaches can be very pricey. Even for companies with deep pockets, the cost of a role which doesn't directly contribute to value delivery can be hard to swallow. While some companies will establish separate funding at an enterprise level for covering coaching costs, those that don't will need to find some way to justify those costs at the department, value stream or project level. This might encourage these companies to overwhelm the coaches with multiple delivery teams which will keep them busy but won't necessarily achieve desired outcomes. It will also discourage use of the coaches for "non-billable" activities which are often more strategic than their contribution to any one project.
• Having full-time coaches might prolong the journey to sustainable agility. Coaching as a service is valuable on an ongoing basis, but focusing this on a single role might result in teams using that role as a crutch rather than being truly able to "fish for themselves". A greater sense of urgency emerges when we know that our coach has an expiry date.
• You may not be able to afford good full-time coaches. A good agile coach is worth their weight in gold. Unfortunately, most companies don't have the Midas touch and the fully loaded costs of a team of competent agile coaches might be more than they can afford. This is especially true in the first few quarters of a transformation where the benefits of increased agility are still insufficient to cover their costs.

While an agile coach is not mandatory, the support a good coach provides can accelerate the journey through an agile transformation. The best choice for many companies might be to staff a combination of full and contract coaches to make the journey as pleasant as possible.

"... the only thing we have to fear is...fear itself."

When FDR spoke those words as part of his presidential inaugural address in March 1933, it was meant to inspire a nation to recover from the depths of the Great Depression.

But looking at global reactions to the new 2019-nCoV Coronavirus, I wonder if it would have been better stated as the only thing we have to fear is our reactions to fear itself.

This disease, like many before it, will injure and kill many before it is controlled. Economies will take time to recover from its impacts. But it is how we respond to it that will define how successful we are at recovering from it.

Whether it is the willful distribution of misinformation, hiding critical information to save face, latching on to snake oil remedies, or worse, ostracizing or even persecuting others just because of what they look like or where they come from, our reactions to this global crisis will either prolong or curtail the suffering.

So what is the project delivery lesson we can learn from this?

Issues will happen on projects. The magnitude of those issues will vary depending on the level of project complexity and the effectiveness of risk management practices. And sometimes the impacts of project issues can be dire.

But more often it is not the tangible impacts of those issues themselves that we have to be worried about, but rather how our stakeholders will respond to the issues. Acting on their amygdala impulses or using project issues as an opportunity to further personal agendas are unlikely to result in the best possible recovery outcomes.

I've witnessed projects which could have recovered fairly easily from an issue get pulled into a death roll by a few "crocodile" stakeholders. Rarely do these stakeholders suffer any personal consequences from their actions as scapegoats are easy to find.

So how do we combat this?

• Increase transparency into what is known, what is believed and what is still unknown. Separating key information into these three buckets and updating and re-communicating this frequently will help to quell the spread of misinformation.
• Increase predictability and consistency in our actions. When things are starting to spin out of control, stakeholders will be looking for stability within the chaos. If we are not doing what we say we will do, we will drive these stakeholders into the arms of false prophets.
• Emphasize ongoing planning over plans. While it is important to develop and communicate recovery plans, we shouldn't fall into the trap of sticking to those plans when evidence refuting their value emerges. Our own biases will often be our worst enemies so reinforce the importance of radical candor among our trusted advisors.

"If you can keep your head when all about you/Are losing theirs and blaming it on you..." - Rudyard Kipling