The Skinny on Lean IT

Share on LinkedIn8Tweet about this on TwitterShare on Google+0Share on Facebook0

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

Dimension Data 2008 Study

  • 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
Desired Outcome

Fix a really bad process

Improve a stable process where no obvious quick hits exist

Established Processes?

Not necessary

Required

Level of Process Analysis

Can be completed in a few workshops

Detailed process decomposition and work observation

Waste/Time Measurement

Order of magnitude

Data driven, time and motion studies

Suitable IT Functions

Problem resolution/help desk, desktop provisioning

SDLC

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:

  1. Build a value stream map
  2. Identify opportunities or gaps (see Kaizen Bursts as one technique for capturing ideas)
  3. Prioritize the opportunities based on level of complexity and impact
  4. Create a baseline to measure impact
  5. Fix the easy to implement opportunities with the greatest benefit
  6. 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.

Share on LinkedIn8Tweet about this on TwitterShare on Google+0Share on Facebook0
  • Pingback: Links for August 9, 2009 | Eric D. Brown - Technology, Strategy, People, Projects()

  • Chris,

    Nice summary, and you are correct that this just scratches the surface. I think it is important to remember that to truly implement Lean, it must be viewed as more than just a set of tools. Yes, the tools work and get results, but sustaining without changing the culture of the organization is difficult, if not impossible.

    I write more about this here (Lean & IT): http://itbusinessalignment.wordpress.com/2009/01/26/lean-it/

    Glenn

  • Chris,

    Nice summary, and you are correct that this just scratches the surface. I think it is important to remember that to truly implement Lean, it must be viewed as more than just a set of tools. Yes, the tools work and get results, but sustaining without changing the culture of the organization is difficult, if not impossible.

    I write more about this here (Lean & IT): http://itbusinessalignment.wordpress.com/2009/01/26/lean-it/

    Glenn

  • Pingback: Twitted by glennwhit()

  • Agree and interesting to see the Dimension Data study show that of the 60% are working with ITIL; only 10% consider themselves “true practitioners” .

    ITIL is a framework, it describes what processes need to be in place, and many organisations think that by implementing the processes they will have achived perfection. It goes without saying that the processes need to be “Lean”.

    Cobit and ValIT go a couple of steps further and are more comprehensive than ITIL, ValIT in particular talks of IT value and in my opinion talks the same language as Lean.

  • Agree and interesting to see the Dimension Data study show that of the 60% are working with ITIL; only 10% consider themselves “true practitioners” .

    ITIL is a framework, it describes what processes need to be in place, and many organisations think that by implementing the processes they will have achived perfection. It goes without saying that the processes need to be “Lean”.

    Cobit and ValIT go a couple of steps further and are more comprehensive than ITIL, ValIT in particular talks of IT value and in my opinion talks the same language as Lean.

  • Krishna iyer

    Chris, Steve & Rob - great start. Very apt in todays environment - where Process Automation is getting integrated with the CIO function. And for the CIO to drive this change with credibility - the first processes to tackle are within IT.

    A good way to start would be a couple of very clearly defined Pilot projects - which will help establish the credibility of the Lean approach. When it needs to be applied to larger Operational processes then a Lean + 6 Sigma combination can work well.

  • Krishna iyer

    Chris, Steve & Rob - great start. Very apt in todays environment - where Process Automation is getting integrated with the CIO function. And for the CIO to drive this change with credibility - the first processes to tackle are within IT.

    A good way to start would be a couple of very clearly defined Pilot projects - which will help establish the credibility of the Lean approach. When it needs to be applied to larger Operational processes then a Lean + 6 Sigma combination can work well.

  • An excellent article showing how we can use Lean to solve real practical problems in IT.

    I like the point about not optimising a process that doesn’t exist - obvious, but often overlooked in the rush.

    The distinction between “Quick Hit” and “Deep Dive” is also useful. This counters a recent Ovum opinion that it’s too late to do Lean IT because it all takes too long. I use a Lean IT Healthcheck as a diagnostic which can rapidly identify the “Quick Hits” and the “Deep Dives”. That means CIOs know how to get improvements quickly

  • An excellent article showing how we can use Lean to solve real practical problems in IT.

    I like the point about not optimising a process that doesn’t exist - obvious, but often overlooked in the rush.

    The distinction between “Quick Hit” and “Deep Dive” is also useful. This counters a recent Ovum opinion that it’s too late to do Lean IT because it all takes too long. I use a Lean IT Healthcheck as a diagnostic which can rapidly identify the “Quick Hits” and the “Deep Dives”. That means CIOs know how to get improvements quickly

  • Pingback: Is Lean Equivalent to Optimized? | Tao of IT - Leading and living wisely in the world of Information Technology()

  • Sudesh Sapra

    Thanks Chris.

    I like the comment about the recent diamond project team analyzing service request processes in IT (Transportation industry)where it will take 3 day fulfillment time because a single person has to approve.

    My question is how many processes do we have that require manual interventions that are so inefficient to the business. These are opportunities for the business to redesign and introduce straight through processing. On the other hand, IT can advise on the best tools and technologies out there that will enable this automation more efficient and thus demise the legacy technology that may be carrying excess weight.

    Good article indeed!

  • Sudesh Sapra

    Thanks Chris.

    I like the comment about the recent diamond project team analyzing service request processes in IT (Transportation industry)where it will take 3 day fulfillment time because a single person has to approve.

    My question is how many processes do we have that require manual interventions that are so inefficient to the business. These are opportunities for the business to redesign and introduce straight through processing. On the other hand, IT can advise on the best tools and technologies out there that will enable this automation more efficient and thus demise the legacy technology that may be carrying excess weight.

    Good article indeed!