The Skinny on Lean ITpost by Chris Curran on August 7, 2009
by Chris Curran, Steve Legnine and Rob Boudrow
Lean, an optimization philosophy embodied in the Toyota Production System, is re-gaining popularity among some of our consumer products clients as they continue to search for ways to do more with less. I’ve asked Diamond’s business process expert, Steve Legnine and our IT optimization guru, Rob Boudrow, to work with me on this post to get the best thinking from the process quality world and to make sure we make a solid translation to the IT world.
For some, “Lean” has a negative connotation, especially in the current economic environment. The reality is Lean is about eliminating waste, not operating with fewer resources. Companies are already running with minimal staff, but also have corporate agendas to grow revenues. This is where Lean comes into play, helping companies stop doing non-value added activities and start handling growth.
As a simple but stark example of waste, Steve describes a company whose customer service agents make 12,000 weekly trips to and from the printer only to throw away the paper. Now that’s some serious pork! Imagine the opportunity for additional calls and deeper interaction represented by that wasted time. Not to mention, IT spend associated with printer maintenance and support continues to rise.
I saw another example highlighted in my WSJ iPhone app describing Starbucks and its efforts to apply lean principles to its 11,000 stores. The most important concept for them is identifying wasted motion:
“…reducing waste will free up time for baristas…to interact with customers and improve the Starbucks experience. Motion and work are two different things. Thirty percent of the partners’ time is motion; the walking, reaching, bending…”
So How Does Lean Apply to IT?
Some has been written to apply lean concepts to IT comparing lean with agile, focusing mainly on the software development process versus on IT as a whole. I don’t view the two as similar. Lean describes the ‘what’ - reduce waste, etc. Agile, as an extension, is one way to approach ‘how’ - describing ways to eliminate low value meetings, etc.
When discussing Lean IT, it’s more useful to separate the “what” and “how.” Furthermore, it does not have to be an all or nothing. You don’t have to apply the same level of lean to the entire organization. You could apply agile to the SDLC but leave the help desk alone
Also, before looking for waste in IT processes, we need to understand the processes themselves. In our experience, IT organizations often struggle in getting efficient processes communicated and adopted across their organizations. Inconsistent and ad hoc processes are a root cause of much of the waste. Some examples:
- During a new social media project requiring a flexible approach in dealing with multiple vendors and hosted components, we discovered that our client team did not have a basic understanding of ANY software construction method or approach (Healthcare)
- A CIO asked for an approach for measuring productivity in his development staff and invested $2 million in implementing a tracking and reporting tool. The staff however wasn’t clear on the SDLC process steps or terminology and as a result couldn’t provide any accurate and detailed activity data. (Insurance)
- One client recently discovered that one daily report was producing 5 million printed pages. No one seems to know if anyone actually uses it. They shut it off saving an estimated $18m a year and are waiting to see who screams. (Healthcare)
- A recent diamond project team analyzed service request processes in IT. Out of the 43 request types identified some ~25+ of them required approvals. When pressed on if they have ever declined one of them, many of the request owners shrugged and said never. So, why is there a 3 day fulfillment time because a single person has to approve? (Transportation)
Over the last 5 years or so, adoption has certainly increased in standard processes, especially around ITIL. That said, no studies on core process adoption are above 40% for any of the IT’s major functions.
Forrester 2008 Agile Survey
- 33% using some form of Agile
- 35% using a waterfall approach
- 9% using CMMi
- Almost 60% are working with ITIL
- Only 10% consider themselves “true practitioners”
I think this data is interesting because organizations seem more interested in optimizing their processes than in defining them in the first place.
Two Kinds of Lean IT Initiatives
Lean initiatives come in two flavors: Quick Hit and Deep Dive. The Quick Hit approach is most appropriate with processes that have obvious trouble spots and those with little variability. The Deep Dive approach is appropriate for established processes where inefficiencies are suspected but are not obvious and for organizations who wish to establish or expand their continuous improvements.
|Quick Hit||Deep Dive|
Fix a really bad process
Improve a stable process where no obvious quick hits exist
|Level of Process Analysis||
Can be completed in a few workshops
Detailed process decomposition and work observation
Order of magnitude
Data driven, time and motion studies
|Suitable IT Functions||
Problem resolution/help desk, desktop provisioning
The major point of the table is that if you don’t have well-established core processes, then you are not ready for a Deep Dive Lean program yet. Instead, you should focus your efforts on identifying Lean Quick Hits and implementing more efficient core processes.
Going on a Diet
There are many gaps and delays in how IT organizations communicate internally - Applications to Infrastructure, Architecture to Everyone else, one application team to another. SDLC methodologies are supposed to help, but taking waterfall as an example, it could easily create waste (waiting, breakdowns in communications) if not well engineered.
Once you have defined the priorities, follow one of the many variations of Lean methodology, for example:
- Build a value stream map
- Identify opportunities or gaps (see Kaizen Bursts as one technique for capturing ideas)
- Prioritize the opportunities based on level of complexity and impact
- Create a baseline to measure impact
- Fix the easy to implement opportunities with the greatest benefit
- Review the value stream map and target the next wave of opportunities which may be moderately more difficult to implement, but has the potential for significant benefit
Bottom line is - like Six Sigma, CMMi and other improvement models - Lean is not a formula for success. It requires both subject matter experts who understand how things are and can develop ideas for where waste lives and process optimization experts who analyze work, understand cost-benefit tradeoffs and can plan and execute the improvements.
Obviously, this article just scratches the surface on a very complex topic. The most important thing here is to not jump into a Lean IT effort without understanding the maturity of your core processes and getting the right skills an experience involved in the project. In future posts, we will further explore the topic from an SDLC perspective.
Pingback: Links for August 9, 2009 | Eric D. Brown - Technology, Strategy, People, Projects()
Pingback: Twitted by glennwhit()
Pingback: Is Lean Equivalent to Optimized? | Tao of IT - Leading and living wisely in the world of Information Technology()