For a while now I have been eager to look at the bigger picture of Lean and Kanban beyond the pure software development context. My inspiration comes mainly from the work of Alan Ward, Micheal Kennedy, John Shook and the likes on Lean Product Development and A3 thinking. The challenge was to apply it to a business/IT context. Recently I have had some opportunities to explore Lean and Kanban concepts in the context of Large Transformation Programmes (abbreviated to LTP in the rest of the blog).
Large business and IT transformation programmes represent a large expenditure with a substantial impact on the business and IT systems. Uncertainty in these programmes is high – both on the side of expected benefits as well as on the side of the capability of the organization to deliver the programme. Hence large transformation programmes are often plagued with overruns in budget and schedule, quality issues and in the end not delivering the aspired benefits. Due to economic and market reasons, organizations are starting to show less tolerance for overruns and quality issues in such programmes. It is time to explore how lean thinking can transform large transformation programmes.
The traditional cornerstones for delivering LTPs include: stage gate project life-cycle, division of work in work-streams, some kind of portfolio management to release projects in the organization. These traditional cornerstones have proven to be deficient in the following ways:
Largely linear project life-cycle with stage gates gives rise to long project lead times (spending a lot of time in analysis and re-analysis) and loopbacks in later project stages.
In one example the LTP spend an additional 9 months in analysis. Even after doing a thorough analysis of all the business processes, the different (application oriented) work-streams felt the need to re-do the analysis from an application perspective and taking into account the capabilities of existing applications and a package application that was going to be implemented. Even after all this analysis it was hard to assess the impact of the transformation for the business people involved.
The programme also suffered from loopbacks. Work streams were de-scoped late in the project because of time pressure, wasting work that was already performed. Of all the (+20) business process that were analysed, only 5 processes were deemed critical. The work of the architecture team was largely neglected by the work streams resulting in the need to reverse engineer the (as-build) solution architecture. The purpose of the programme was to build an architecture that could be reused across business lines and regions. Even before the first implementation it was clear that much rework would be needed before going to the next implementation.
Work that is organized in technically driven work-streams ( roughly corresponding to existing delivery teams) giving rise to silo thinking, fragmented knowledge, integration problems and resistance to change.
In traditional programmes, separate work streams are delivering in organizational silos each with their own goals and objectives. This means that goals and objectives of the work-stream are often too remote from the programme goals and objective. Also, the know-how and responsibilities about the solution is fragmented (in silos), without end-to-end ownership. Because each of the work-streams is working in a silo, integration proves to be a problem. Because non of the work-streams actually delivers business value in itself (only the integrated solution does) no value can be delivered before all integration problems are resolved. It’s an all or nothing solution making it hard to manage the programme towards its aspirational budget and schedule. Moreover it means that the business can expect a big change when the solution is implemented. Business is not ready for this big change and may never be ready to truly accept a big change like that.
Releasing projects into the organization based on “priority” and resource availability gives rise to reinvention of knowledge and duplication of effort.
Similar transformation projects are simultaneously started in different lines of business or in different geographical regions because of time pressure. Because transformation projects for each line of business are started in parallel there is no opportunity to learn across these projects. Even when projects are started sequentially, organizations do not have the capabilities to learn across projects.
So what can lean thinking contribute to solving the above problems. We will look at the following pilars of lean and how they apply to managing an LTP:
Focus on value
The purpose of a transformation programme is not to deliver IT systems but to improve the business. The business is struggling with a problem. Let’s say that we are a manufacturing company. Maybe inventories are too big (and costly). Maybe delivery times are too slow (and not to the satisfaction of the customer) or too variable. Probably, performance in both dimensions is unacceptable. The main challenge for the programme is how to fundamentally improve the business. In the current state of business improving in one dimension (inventory) leads to unacceptable performance in the other dimension (due date performance for delivery). Fundamental improvement means to improve on both making inventories smaller and delivery times shorter. Typically we can capture the business problem in a trade-off curve as shown below.
Pull not push
Pushing one overarching, one-size-fits-all solution to our business problem has proven not to work. The situation analysis has shown that it leads to programmes that are hard to manage towards budget and schedule, a business that is not ready, and probably not delivering the improvement that was envisioned. At worst the programme cascades into failure – the technical problems become to big and resistance to change kills the programme off.
Value-driven programmes allow the business to pull small increments of value. They work in small steps allowing the business to learn what works and what does not work. As confidence grows (and also knowledge), bigger and bigger increments of change can be undertaken.
A value-driven programme is organized around A3 sized business improvements: business improvements that can be described and visualized on an A3 sized paper. (an example A3 is given at the bottom of the blog post). Each A3 sized improvement addresses a different root cause of the business problem.
Each A3 sized improvement also provides an opportunity for learning. At the start of the programme we have unclear visibility about what is realistic and what is not realistic business performance. Improvements need to be carefully planned to provide maximal learning opportunities about the trade-offs between the different dimensions of business performance.
As the programme progresses, we need to validate what has been delivered before starting new work. We can design a simple Kanban system to manage the flow of improvements.
With the above steps we have actually started to implement the plan, do and check steps of the PDCA cycle as show below.
As the cherry on the cake we now turn our attention to the act step. In the act step of the PDCA we need to make sure that what has been learned and developed in previous incremental improvement in the programme is made available for reuse for future incremental improvements. We need to scale up what works well and scale down what did not work well.
Examples of what needs to be captured and standardized for future reuse includes:
- Business policies and procedures
- IT systems and solutions
- Delivery and delivery management capabilities
The following A3 summarizes the Lean Transformation of Large Programmes.