Demand Management: Accelerating the Flow of Ideas to Production
Our clients have lots of great ideas they’re keen to get in front of their customers. We are often approached to help accelerate the delivery process so that customers can benefit from these ideas as quickly as possible.
Whilst there is a common misconception that this acceleration can be achieved through technological change alone, this is often not the case.
We must look at the organisation’s value stream - the path an idea takes from inception to live. The difficulty here is that this value stream is usually changed by the organisation over time, often moving away from its original intent and causing unintended friction deep within the organisation.
Here are a few points of friction you may recognise:
- Projects get ‘stuck’ during software delivery, often being delivered late or over-budget
- Value proposition is being undercut by new industry players
- Increasing focus on SaaS products because delivering software in-house is complex
- Leaders often have to get involved with firefighting software delivery
- Often require consultants or contractors to bring in additional knowledge
These points of friction lead to a slower-moving software delivery process and a backlog of outstanding projects.
So what can be done to understand and overcome these obstacles to speed up the delivery process?
Demand Management as a process is designed to cap demand and safeguard the limited delivery capability, letting only those projects of highest priority pass into delivery.
At Contino, we see the introduction of a Demand Management process as a stepping stone. The intent - like most imposed orchestration layers - is for it to dissolve as we help the organisation to improve the speed and quality of the software delivery process by better understanding the reason behind the points of friction. As an example, it might involve a move towards a decentralised product delivery approach, empowering the software teams that are closest to the customer to choose features that would best help those customers with their unmet needs.
Our Approach to Accelerating the Delivery Process
Whilst every client is different, and every story is unique, here is an approach we take at Contino to understand and help an organisation suffering from costly and slow software delivery, using the principles of demand management to identify and overcome points of friction.
1. Cap demand by implementing a short-term Demand Management process
First, we help the organisation make the most of the limited delivery capacity available. This involves applying additional scrutiny to how projects are prioritised and preempting potential issues before they arise during delivery and further erode delivery capacity.
Organisations often naturally build this short-term defense mechanism through centralised project prioritisation decisions. We augment this slightly by applying a balanced product management lens, prioritising those projects that are desirable, feasible and viable.
Good products and services are desirable, feasible and viable. Adapted from IDEO’s How to Prototype a New Business.
We determine this through interviews with project stakeholders and through workshops. If answers are uncertain, we partner with the project team to help surface the right information or to augment their project plans to surface these answers early. Reducing uncertainty in this way not only helps in prioritisation but it also aims to reduce the impact of issues that often arise late in project delivery; for example by clearly defining the project success metrics (as OKRs), or by identifying wider project dependencies.
2. Identify obstacles that are slowing software delivery
Before we consider solutions to accelerate software delivery, we aim to understand the status quo and the reasons behind it. As pioneered in Lean Software Development, we help the client answer “how long does it take for a team to deploy into production a single small change that solves a customer problem?”.
We often use Value Stream Mapping as an approach to unearth and measure the common obstacles that lead to waste, such as delays or rework. Should the landscape be more complex, we may opt for the Theory of Constraints to help produce a more two-dimensional map of the organisation, and the reasons behind delivery woes.
3. Test cure by running safe-to-fail experiments
We should have enough data at this point to form a hypothesis on the potential causes of friction. We accept that this data is not perfect and therefore requires validation before organisation-wide implementation and adoption.
To avoid prescribing change based on limited data, opinions or gut feelings we design safe, low-cost experiments that prove out a clear hypothesis, following three steps: measure, execute and learn.
A successful experiment should validate the pressure point where a small change will have a wide impact, as well as providing sufficient data to build confidence with leadership. A failed experiment provides a better understanding of the situation that will allow an improved solution to be crafted, whilst also preventing the wrong change being rolled out across the organisation.
We attempt to experiment without investing in technology, as this often is expensive and difficult to reverse if the experiment is unsuccessful.
4. Administer cure by rolling out successful experiments
We are cautious with successful experiments. We are aware that, when applied more widely, they may still fail or have unforeseen repercussions. During the initial stages of roll out we want to be able to roll back if necessary.
We therefore administer the cure in small steps:
Define bounds: We ensure changes are incrementally rolled out so they can be quickly withdrawn with limited impact if proving detrimental.
Re-measure: If our hypothesis is sound we should be able to measure the same results from a larger scale experiment.
Be vigilant: Look for unforeseen wider side-effects. If found, mitigate or withdraw.
5. Uncap demand by strangling the Demand Management process.
As software delivery capacity starts to increase with time, we begin to strangle the Demand Management process by allowing more projects to begin.
We then return to Step 2 to find the next obstacle to tackle that will further increase software delivery capacity, and allow more of our valuable projects through the pipeline.
Let’s have a look at our approach in action.
Case Study: Helping a Utility Provider to Improve the Speed and Quality of Their Delivery Process Using Demand Management
Our client was experiencing increasingly slow and costly software delivery, impairing their ability to deliver competitive products in a dynamic marketplace. It was suspected that this slow and costly delivery was due to their dependence on consultancy partners, and could be remedied by hiring software engineers into the organisation. Contino’s primary focus was to implement Demand Management to temporarily cap demand, whilst identifying obstacles that could be removed to increase their overall software delivery capacity.
Due to the increasing backlog of software projects awaiting delivery, Contino’s first step was to cap demand by introducing additional qualification criteria to prioritise those projects that would offer the greatest business and customer benefit.
This process involved a cross-functional workshop to understand the customer desirability, technical feasibility and business viability of projects in the backlog to aid in prioritisation, whilst also identifying and tackling early potential issues that could lead to later delays in project delivery.
Assumption Mapping was used indirectly as a technique for understanding the inherent uncertainty in projects
Subsequently, Contino held short interviews across the organisation to build a holistic understanding of the value stream, and identify obstacles that were slowing delivery and leading to an increasing project backlog. A causality diagram helped us synthesise these interviews into a single key finding along with six recommendations to reduce waste in the delivery process, and thereby unlock additional delivery capacity.
The key finding was that a business-wide focus on cost reduction was reducing the ability for the business to be successful in the long-term by increasing invisible costs. These included:
- Skill debt in employees, encouraging key-person risk which can delay projects and a reliance on consultancies which can increase project costs
- Technical debt across the enterprise architecture, increasing the complexity of future project delivery, and therefore greater analysis and cost
- Process debt in centralised decision-making, creating greater lead times and rework due to longer feedback loops
In response to these findings, Contino proposed six cures that aimed to reduce the direct focus on costs and thereby increase the speed and quality of software delivery. These included providing space for staff to learn thereby reducing the future reliance on costly consultancies, and balancing out cost targets to reduce a significant upfront cost benefit analysis for each project.
Low-cost experiments were designed and proposed to the client for testing the cures safely, such as against a particular team, project, or type of customer. Clear success metrics were established to determine whether the experiment would be considered a success before considering administration of those cures more widely.
In order to get our ideas to customers sooner, we must ensure we are making best use of the limited software delivery capacity available, whilst focusing on identifying and removing obstacles.
These obstacles will naturally accumulate over time as an organisation evolves. They are similar to blockages in our software delivery pipe, which must be identified and removed to increase overall throughput.
The changes necessary to remove those obstacles, however, are not always simple and may often need to be tested cheaply and safely in isolation as short-lived experiments. The changes will often be small but far-reaching - such as modifying the organisational structure or operating model, often to enable a decentralised product delivery approach and empower those closest to the customer. If those experiments reap the desired shift in measures, with no unintended wider side-effects, they are ready for rollout - whilst always remaining vigilant. This is a continuous improvement process.
We will share more insights on these topics in upcoming articles.