Apologies for slacking off from blogging, but there has been too many things to do. On the positive side, I had plenty of time to think about, think through and then re-think some of the ideas I started earlier this year. Now getting back to the subject I started on before I took my writer’s break.
Starting Point
Lean is more of an operations philosophy rather than set of techniques and that’s why it requires looking first at its principles before dwelling on techniques. Let’s start with the principles set by Womack & Jones’ in the book that started it all:
- Specify value (or know what your customers want & need);
- Identify the value stream (or understand the sequence of steps leading to delivery of the end result within and without your organisation);
- Flow (make sure there are no stop-gaps in the process);
- Pull (reconfigure the process to be driven by customer demand as much as possible);
- Perfection (which seems to me very similar to continuous improvement).
Process Improvement & Its Costs
A quick search will show that the core of the techniques originating in Lean, that are actually used, focus on process improvement (principles 2,3). It is hard to argue against process improvement, but the way that it is supposed to be applied to IT as part of Lean poses some interesting challenges.
Identification of the value stream is something popular and achievable even if it is not not exactly easy. Unless your operation is CMMI level 3 or above, your existing process are probably blurry or missing in places. To sort out the holes or blurry patches mean formalising, rationalising and agreeing the end-to-end process:
- This is possible for repetitive activities, such as live service support. ITIL gives a reasonable reference process framework to start with this. It is not the easiest process but certainly can be done;
- Solution delivery processes are harder as they fall largely into the Barely Repeatable Processes category. Firstly, projects are rather varied when seen from the viewpoint of an enterprise Process to design a new website is rather different from a process to decide how to upgrade your desktop, which is different from a process to improve your data quality). Secondly, big projects are not repeated that frequently. Considering large projects of each type happen perhaps once every 5 years, what benefit does a detailed process definition gives;
- Front-end process activities are also hard. For tasks such as identification of potential projects or initial project scoping, lack of detailed process is a benefit rather than drawback as it enables creativity and innovation.
If mapping the value stream is not easy, reconfiguring it for flow is even harder:
- Firstly, making IT requires more than just agile process (that is the boilerplate answer from Lean proponents in IT). There is a number of other things that you don’t need to care about as a developer, but that are really important from a management perspective, e.g. how capacity management is, staff cross-training, how much spare staff do you want to pay whilst they aren’t doing anything useful and others;
- Secondly, some of the biggest issues IT faces are upstream - facing off to the customer - rather than downstream. Making the upstream process flow hints on business-IT alignment, which is a subject that has been one of the consultants and academics’ favourite for almost 20 years, but still remains a problem.
- Thirdly, I would claim that as long as the IT organisation provides a good service to its customers (e.g. does not discourage them), it will be facing demand that is much less predictable and homogeneous that that of manufacturers. Under certain conditions, loss of flexibility due to over-optimisation may become a bigger issue than the perceived waste in the process.
Questioning the Benefit
Let’s now move to benefit side of the equation, starting with Womack & Jones explanation of the implications of the Flow principle:
when we start thinking about ways to line up all of the essential steps needed to get the job done into a steady, continuous, flow with no wasted motions, no interuptions, no batches and no queues, it changes everything: how we work together, the kind of tools we devise to help with our work, the organisations we create to facilitate the flow, the kinds of carreers we pursue, the nature of business firms (including non profit service providers) and their linkages to each other and society.
From the quote it is clear that the expected business benefit of Lean comes from eliminating waste. The problem is that waste in IT is much harder to identify and quantify, especially when compared to manufacturing which has a pretty large, single and visible source of waste called inventory. The people who interpreted Lean into IT domain will tell you that IT process waste consists of unfinished, unneeded functionality, processes, multi-tasking, delays and handoffs etc. The issue with this list is that is rather long, full of small and often hard to quantify inefficiencies, rather than a large, single and visible one, which makes reducing IT process waste harder and its payoff smaller.
Considering the level of disruption when adopting Lean, lack of a single large category of benefit greatly erodes the benefit case and the support you can expect from the CIO or the board for an enterprise scope implementation.
In Summary
The implementation challenges combined with difficulty of developing a robust enterprise-wide benefits case, means Lean is not as groundbreaking as some of its advocate think. It still makes useful operational improvement approach that can deliver a reasonable business benefit. When take and go with it, it is important to consider the type of operation you want to apply it to and start where the cost/benefit ratio is the best. If you have a good relationship with business, it may be worth addressing your business architecture and portfolio management as enablers of a wider application of Lean in IT delivery.
There are few more implications that I won’t go into here as I’m running out of space & time, so you can look forward for one more post on the subject.