By Jibility Co-Founder Chris Benthien
We recently worked with a client to establish a strategic roadmap for their digital transformation. We worked through their key challenges and objectives, determined the major changes and impact on their business capabilities and set priorities for investment. We identified the key changes for each of those capabilities and then created a roadmap of initiatives for them to achieve the transformation. A great outcome!
But the conversation then moved to execution and the best approach to deliver each initiative. We had a lot of agile evangelists in the room, with very definitive views on how the initiatives should be executed. But is agile always the way? And what did they mean by agile anyway? Scrum? Kanban? Lean Design? Someone then asked: why would we ever use the waterfall methodology again?
Here is a useful method that we often use to guide us on which approach to take at a macro level when executing roadmap initiatives.
Degrees of Uncertainty
We discovered a simple method many years ago (we love simple methods – particularly ones that involve a 2×2). I believe the originator was Jez Humble, and it’s a variation of the original Stacey Matrix by Ralph Stacey. We’ve adapted it and used it ever since to broadly guide us when deciding on the right approach to execute the initiatives on our roadmaps.
The core of the method is the determination of the degree of uncertainty for two key aspects of your initiative: the clarity or certainty of the problem and the certainty of the solution.
The problem you are trying to solve with your initiative is often crystal clear. Perhaps your organization is losing customers, and you know for a fact that the key issue is not responding to customer problems and queries in a timely fashion. That is a clear and succinct problem. How you solve it may be up for grabs, but it’s a well-defined problem statement for your initiative.
But if your objective is more broadly to reduce customer churn, are you certain that the fundamental issue is the slow response time to customer queries? Perhaps the challenge is being driven by other issues of which you’re unaware. Maybe your customers can’t easily find and access your help material and manuals, necessitating a need to submit queries. This could be a much better problem to solve to reduce customer churn.
Before you rush out and buy a CRM system to manage customer queries, you need to be certain about the problem or challenge you are solving for.
The solution to your problem can also be clear and well-defined, or much less so.
The solution to a customer churn issue could clearly be the installation of a CRM and implementing its capabilities out of the box. There is a high degree of certainty that the system and the proven business processes it encapsulates will solve your problem. But sometimes the solution is not so clear. Will a new system solve the problem? Or is it a matter of simple people and process tweaks?
The Two by Two
The Experimentation Model is where the problem and the solution are less certain. This lends itself to starting with a Lean Startup approach, including Design Thinking and Human Centred Design .
Beginning with a clear exploration of the problem, you ideate a solution hypothesis. Then, you progressively test and refine it for the least cost/effort until you have more certainty about the true underlying issues and the feasibility and viability of the proposed solution. Once this is clear, you may use Scrum, the Waterfall methodology, Kanban or other approaches to implement the solution (subject to clarity of problem or solution).
To solve the customer churn issue previously discussed, you may choose to immerse yourself in customer feedback and investigate why they are leaving. From this, you may formulate a hypothesis and potential solution, then develop a series of solution prototypes (or Minimum Viable Products) and associated experiments to prove that your problem/solution is certain.
Iterative Solutioning Model
When the problem is more certain, but the solution is less so, an iterative approach is more suitable.
In our scenario, it may have become clear that the issue of failing to handle customer queries and complaints in a timely fashion is driving customer churn. However, the shape and complete specification of the solution is far less clear.
You could progressively establish an implementable solution (technology, people and process changes), testing and seeking feedback after each increment. In this way, you can continually shape your solution as you learn more about its effectiveness in addressing the problem.
This is where the Waterfall methodology is likely to still be your best option.
In a linear model, the problem and solution are both certain and the Waterfall methodology is valid as long as:
You’re clear about the solution requirements
The definition of the solution is stable
The technology or solution components are mature
In relation to our customer churn scenario, you may know that query handling is a problem and that the lack of a system and processes is the underlying cause. You have chosen a SaaS solution and an initial proof of concept has shown that it alleviates your problem. You could then implement this solution out of the box (well, out of the cloud in this case), clarifying your requirements, configuring the software and deploying it to your teams in a linear fashion.
In this case, the problem is clear; the solution requirements are known; the solution definition is stable (bounded by the SaaS product chosen); and the technology and solution components are mature. This is a candidate for a linear approach.
This is where the solution exists (or is known), but the problems to be solved haven’t yet been discovered. Or in other words, we have an approach to solve a set of unknown problems, within a known space, using a set of known solution patterns.
We call this the Factory Model. You have an existing solution or capability and you just keep feeding it the next piece of work or problem to solve Kanban style. The Factory’s goal is to constantly optimise its throughput to get more done more efficiently and for less cost.
An example of this could be workflow automation, where you have an existing workflow automation technology platform, team and delivery approach (“The Workflow Factory”), and you just keep feeding it business workflows to automate. No need to think about the solution – you only need to identify the business opportunities to feed it and ensure the prioritization of the input aligns to organizational priorities.
Navigating the Quadrants
Sometimes a challenge moves through the quadrants. Perhaps you start in Experimentation to diagnose the problem and formulate the most viable solution; then move to an Iterative Model to establish the solution; and then finally move to a Factory Model to roll out the solution.
To illustrate this with our customer churn scenario: perhaps we have iteratively developed a new CRM solution, but now need to deploy the system and process changes across all of our operations globally. We may choose to create a deployment “factory” that takes the next group of stakeholders in the backlog and puts them through a repeatable and optimized process for migration to the new way of solving customer queries.
Broad Guide Only
Obviously, this framework is a broad guide only; determining the certainty of the problem and solution is subjective.
Whether you choose an iterative approach or waterfall methodology also depends on a number of unrelated factors, such as:
Existing organizational standards and approaches
Availability of skills
Stakeholder understanding of the preferred approach
Commercial models (e.g. fixed price)
Having said all of that, things can become very inefficient when you find yourself executing in the wrong quadrant.
An organization we have previously consulted to had established a workflow automation team and solution. It was progressively responding to internal customer requests to digitize and automate business workflows to improve efficiency. However, the standard framework for executing any work in the business unit was a traditional Prince2® framework, mandated by their Project Office. This team was therefore executing in the waterfall methodology quadrant.
When we analyzed the value chain, the actual tasks performed to deliver the customer output (i.e. the automated workflow) were a small portion of the overall process, which was largely consumed by delivering project management artefacts. We helped them move to a Factory Model by developing an optimized and streamlined value chain (Kanban style) that helped them to significantly achieve more throughput with happier customers for the same overall cost. Management overheads were reduced, and the value chain was now dominated by activities associated with actually producing customer value.
There is no one optimal approach to delivering initiatives or releases on a strategic roadmap.
Waterfall methodology still has its place and is effective.
The key to success is choosing a broad macro approach and then designing the optimal value chain of deliverables and activities to achieve your initiative outcomes.
Often, initiatives can use several of the macro approaches as the problem or solution becomes clearer or the initiative moves into a different phase.
A Tool for building your Strategic Roadmap
Whilst the technique outlined above serves as a useful guide when executing initiatives. The bigger question of what initiatives you should be executing lies in having a simple but effective strategic roadmap.
To quickly create, iterate and visually collaborate on your strategic roadmap then download the Jibility tool. It encapsulates a simplified Capability Based Planning approach to help you translate your vision into an executable roadmap that focuses on the right things.