"... 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?
"If you can keep your head when all about you/Are losing theirs and blaming it on you..." - Rudyard Kipling
I wrote two weeks back about Complex Adaptive Systems (CAS) and the benefit of models such as Cynefin and the Theory of Constraints for being able to understand them. What I didn't focus on in that article was how important the people element is when dealing with CAS. Two HBR articles published this week reminded me of that critical ingredient.
Amy C. Edmondson, who has literally written the book on psychological safety (The Fearless Organization), wrote about the culture at Boeing which enabled the 737 Max issues to fester for a long time before they tragically became mainstream news. In her article, Amy lists three contributing factors including:
In the same week, Ryan Gottfredson and Chris Reina, wrote about the importance of leaders having the right mindset. Going beyond the well known Growth vs. Fixed mindset model, they covered three other mindset pairs:
Out of these three, the middle one is apropos. According to Ryan and Chris: "Leaders with a deliberative mindset have a heightened receptiveness to all kinds of information as a way to ensure that they think and act as optimally as possible... Comparing the two, leaders with deliberative mindsets tend to make better decisions because they are more impartial, more accurate, and less biased in their processing and decision making."
This aligns well with two of the leadership actions which Amy recommends in her article. Leaders need to insist on input by explicitly soliciting feedback and by responding productively to concerns raised by staff.
So what does this have to do with CAS?
Most of you would probably agree that a modern jetliner is complex system given the large number of interdependent software and hardware components which all need to work effectively together under a wide range of physical operating conditions. While it is possible to build solutions in which complexity won't increase non-linearly as the size increases, this requires significant, sustained commitment to good architectural principles with an appropriate balance between quality and other delivery constraints.
When faced with a CAS, psychological safety within a delivery team is more important than with simple or complicated systems as there is a higher likelihood of things not going as expected which drives a greater need for legitimate transparency and candor.
It is a common challenge for anyone who has managed projects for a meaningful amount of time. One or more of your key stakeholders who are integral to the successful completion of the project appears unwilling to engage as expected. It could be the project sponsor who ignores your pleas for assistance with a project issue, the functional manager who turns a blind eye to your requests for staffing support or the executive who never seems to have the time to review and sign off on a key deliverable.
How should we handle this situation? As usual, "It depends!" is the correct, yet, most unhelpful answer!
While the response varies depending on the scenario, we need to understand the root cause for the behavior and then assess the range of options available to us within the specific context we are facing.
Four causes for unresponsiveness are:
If the stakeholder isn't being responsive to an urgent request they are rarely going to tell you the real reason why. You will have to do some digging to determine the truth. It is fairly easy for someone to say they are too busy or they don't see why your request is important when their real reason is they actually don't want your project to succeed. Or, they might take the easy route and pass the buck ("I don't have the authority") when it could be one of the other reasons.
Even still, once you've identified the root cause, it may not be easy or even possible to implement an effective countermeasure. For example, if you are delayed on the sign off from a key stakeholder, there is no way to proceed without that key stakeholder's approval and they are unable or unwilling to appoint a proxy, your project will be delayed. You might have done a great job of informing all other stakeholders in a timely manner about the cause and impact of the issue, but if schedule performance is one of your project's success criteria, it won't be met.
This is why the scope of risk management is so critical. Identifying critical dependencies, failure points in decision processes and stakeholder unresponsiveness issues from past projects can help us to be better prepared. It can also be helpful to identify common decisions over the life of a project and define the decision processes and exception paths up front before we find ourselves in trouble.
You can't control other people. But you can proactively plan your reactions to them.
Over the past couple of years I have regularly heard companies, their portfolios and even individual projects referred to as Complex Adaptive Systems (CAS). With a CAS, understanding of the individual components does not convey an understanding of the whole, and reductionist thinking which can work so well with simple or even complicated systems is of limited use.
Given this, I felt it was somewhat timely when I was invited to review Jonathan Sapir's new book, Thriving at the Edge of Chaos - Managing Projects as Complex Adaptive Systems.
In the first half of the book, Jonathan does a good job of covering the challenges we face when trying to apply traditional planning approaches to complex projects. His differentiation between complicated and complex contexts, the importance of systems thinking and his walk through of the Cynefin framework make these sections a good primer on the subject.
Whether it is Ian Malcolm's quote about non-linearity from Jurassic Park, the old joke about the drunk looking for his keys around a lamp post, or the analogy of a fence and treats for a dog as examples of boundaries and attractors, Jonathan provides many quotes, analogies and examples which all help to make a complex (no pun intended) topic approachable for most readers.
A number of the principles he covers in the first half of the book will resonate with both agilists and anti-fragilists including:
I liked his guidance that operating at the edge of chaos is where modern organizations should strive to be as excessive control leads to paralysis and eventual obsolescence whereas a lack of any guardrails will often result in chaos. Uber is frequently referenced in the book as almost a "poster child" for living on the edge, but I found the inclusion of Cemex and how they overcame the challenges they were facing in a traditional industry more appealing to me given that the majority of organizations are not founded to disrupt an existing business model.
The second half of the book covers Dr. Eli Goldratt's Theory of Constraints (ToC) and focuses heavily on its application in Critical Chain Project Management (CCPM).
While CCPM provides good solutions for dealing with common scheduling issues, I did feel that the book could have delved deeper in terms of applying ToC and other models to addressing some of the non-scheduling concerns caused by CAS. There could have also been some guidance provided for leaders who face the challenge where there are multiple resources who are all equally constrained. ToC works well when there is a single bottleneck but with multiple equivalent bottlenecks what should we do?
The following qualifier from the Introduction also raised some concerns: "This book applies primarily to repetitive, as opposed to one-off, never-to-be-done-again projects. It does not apply to software development projects that use agile methodology." I would argue that some of the most complex projects we have to deliver are highly unique. Also, while many of the ideas shared by Jonathan are already incorporated in agile methods, these approaches haven't fully solved CAS challenges and the book could have addressed those.
If we accept that complexity is going to continue to increase in delivery, Jonathan's book provides a solid grounding on the subject and I hope that a future revision will address some of the opportunities I've raised.
Inspection and adaptation are two of the pillars of the Scrum framework but all agile methods recognize the wisdom of Deming's Plan-Do-Study-Act cycle.
While the Manifesto does not explicitly reference the scientific method, it is implied in the value statement "Responding to change over following a plan" and in its final principle "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
Agile teams embrace experimentation in many ways.
Some of these relate to the product. Minimum Viable Products and Minimum Business Increments can be designed and run to test hypotheses about what we feel is valuable to customers at a macro level. Split testing and similar short feedback techniques might validate whether specific features should be pursued or not.
Some relate to the team's delivery process.
Both the Rational Unified Process and Disciplined Agile Delivery highlight the importance of proving solution architecture early and one effective means of doing this is through the design, construction and execution of experiments focused on quality attributes such as performance or flexibility.
Working agreements such as Definitions of Ready or Definitions of Done can be thought of as experiments to validate whether teams are able to efficiently complete work items and whether teams understand what complete means.
Ceremonies such as retrospectives help a team to identify delivery improvement ideas. Rather than assuming these ideas will help and implementing them on a broad scale, teams will run experiments to see whether these ideas actually show promise. For example, improving product quality through pair programming might seem like a good idea so a team might elect to try pairing on a subset of their upcoming work items and comparing the outcomes to those completed using their previous methods.
Spikes are another form of agile experimentation. Rather than losing significant effort in comprehensive analysis of a specific uncertainty, a short time boxed deep dive focused on learning which options might be feasible is often a better alternative.
So how could adopting this commitment to experimentation help those teams using a predictive life cycle?
Assumptions which have not been validated are a common source of project risks. While a team could wait for an assumption to be passively proven, wouldn't it be more effective to frame a critical assumption as a hypothesis and then design and run an experiment to get data to make the team feel more confident about that assumption?
Incorporating ongoing experimentation into the risk management life cycle might provide a more effective method of de-risking all types of projects.