I recently posted the following response to a question on LinkedIn regarding how to implement Lean principles in an IT organization.
This was my advice...
If you are asking about examples of applying Lean principles in an IT environment I have done that for a client in the past. My client was a well-known international software developer. They were working on developing and implementing a database application for a government agency in the Healthcare sector.
When I was asked to join the project as a Release Manager it was a very tricky situation. Individuals on all sides were very frustrated. The challenge put to me by my client was as follows:
They needed to code, test and deploy 15 months worth of functionality and fixes through 8 environments including 2 production environments in just 6 months.
They had determined that they needed 15 months because up until that point they had been developing, testing. approving and deploying quarterly Releases bundled into 3 month packages. For those of you not familiar with IT terminology (as I wasn't before I started this particular project) a "Release" is simply a new version of a program. It this case it contained combinations of new functionality (neat stuff) as well as fixes (solutions to stuff that didn't work properly).
My first challenge was the fact that my client's perception was that Lean Manufacturing was a concept suited only for car makers in particular and factories in general. It was certainly not applicable in the highly technical and complicated world of software development. So I had to be careful not to talk about things like "Value," "Value Maps," "Flow" and "Backlogs."
Not being familiar with best-in-class methods for Application Development at the time I started to do some research. I quickly discovered that for the IT world they refer to something called "ITIL" as the standard process for effectively developing, testing, approving and deploying software. Note that "ITIL" does stand for something, but like most IT acronyms almost no one knows what it is. I did some more research and decided to use the ITIL process as my Value Map. Of course I was careful to use proper ITIL terminology when I reviewed my approach with my client.
Once I had my Value Map I set up a series of meetings with the various managers along the ITIL process (Scope, Development, Testing, Change Management, Deployment, etc.) to review how they were doing things versus what was prescribed in ITIL. While they had a lot of "excuses" for why they were not following ITIL they all agreed "that they should be."
With this support I then needed to gently approach the subject of moving from a "Batch and Queue" approach (3 month release packages containing many many new features and fixes) to smaller packages. As luck would have it I was able to use a well-timed critical Change Request (very urgent and needed "right away") from the client as a good excuse to try out the smaller Release idea.
I created a Project Plan (Value Stream) based on ITIL methodology (Value) that was specifically designed for the small (Flow) yet critical Change Request. After all the Value Added steps were listed, including reviews and sign-offs at each critical milestone, the complete process had a duration of just over one week. This was a far cry from the 3 month Release Process that was currently in place.
Long story short we made it through the Critical Change Request with very little difficulty. In fact most agreed that it had gone "significantly better than the normal Releases." This was mostly due to the fact that such a small change package was very easy to develop, test, approve and deploy as opposed to the massive Quarterly Releases they had been doing.
Building on that success I tactfully suggested that we could do the same thing with another small package of slightly less critical Change Requests that the client also wanted deployed as quickly as possible. My software developer client was still skeptical. But their client, however, after experiencing the drastically reduced cycle-time of the first Lean prototype gave me all the support I needed. Still not fully appreciating the significant of what was happening everyone agreed and I was able to get approval for this next little package to go through the Value Stream.
From then on I basically kept using the "new" ITIL process to work through the "15 month backlog" of functionality and changes one little piece at a time. And ultimately my client was able to meet their six-month deadline. By the time things stabilized we were doing four week Release cycles which seemed to be the right balance between "flow" and "batch" in this particular situation. To this day I have told very few people involved with that project that they owe most of their success to Taiichi Ohna and others.
Good luck and I hope this helps.
