Multiverse: Planning or Execution?

If you want to be agile, you have to execute multiple scenarios at once. You have a Plan A, plan B, plan C, Plan D. And you take steps with each of them. You do it fast and you do it in parallel. Not just for the sake of documenting a nice risk register that nobody really uses (hello FMEA!), but for agile and seamless delivery. Less documentation (less is still something), and more action.

Project planning for risk management seems to be riddled with extremes, at least in theory. From the waterfall approach where all aspects of the project are thought of and planned to the most infinite detail, to agile approach where planning is conceived as a “just enough, just in time” effort.

Traditional approaches towards project planning put a lot of emphasis on risk management, but mostly around the identification of risks and planning of approaches to minimize risk. The PMBOK talks about the following processes for Risk Management:

1. Plan Risk Management
2. Identify Risks
3. Perform Qualitative Risk Analysis
4. Perform Quantitative Risk Analysis
5. Plan Risk Responses
6. Implement Risk Responses, and
7. Monitor Risks.

Wow, lots of planning, lots of documentation, not so much thought process on implementing responses. Strategies for responses to threats typically involve:

a. Escalate (the PM decides the risk is outside the scope of the project)

b. Avoid (eliminating scope to avoid risks)

c. Transfer (such as insurance)

d. Mitigate (QA, testing)

e. Accept (typical for low priority threats or when the response is cost prohibitive).

Now, on the implementation of all the planned responses, the PMBOK acknowledges a typical project management failure, and goes as far as saying: “A common problem with Project Risk Management is that project teams spend effort in identifying and analyzing risks and developing risk responses, then risk responses are agreed upon and documented in the risk register and risk report, but no action is taken to manage the risk”. This is, in my experience, spot on. Excess planning gives a false sentiment of security. We thought about it, we dotted all the i’s, we crossed all t’s. But the truth is we just got complacent but fell short on execution.

Typical Agile approaches put less effort on documentation, but maybe even less effort on implementation of responses. Agile approaches make use of frequent review of incremental work products to have greater flexibility and speed of change where pivoting is needed to avoid risks. But, that’s mainly it, fast enough pivoting is shown as the holy grail of risk management and excused under the uncertainty and complexity of scope that agile projects typically face. Again, complacency comes to mind, but instead of “we thought about everything” the mindset seems to be “there is only so much we can think about”. Again, no efforts put on the real action to avoid risks.

Thus, planning is important, you have to weight risks in advance. But planning along will not suffice. Execution is required. Hence, Multiverse Execution. And this is, at the end of the day, a matter of redundancy. This is concept that is very well used in vendor management (you can’t have a supply chain link with only 1 option). Well, the advice is to generate redundancy for various stages of business development, specially if you are a startup. How is your sales pipeline looking like? Do you have redundancy? What if that super big client does not come through? How is that recruiting pipeline looking? What if that Solutions Architect says no? How is that office fit up project coming along? What if your preferred location contract is not executed on time? Redundancy, Redundancy, Redundancy. And you only get redundancy if you start executing in parallel (big enough pipeline, various recruits or subcontractors, various office locations under negotiation).

You have a Plan A, plan B, plan C, Plan D. And you take steps with each of them. You do it fast and you do it in parallel.