Using Lean Practices in IT, Big Savings and Performance Improvement

It has been a busy 2012 for everyone, It seems everyone I know is like me, working harder than ever, hoping the economy picks up and that our Government gets budgeting and contracting plans set and in motion.  While weathering the current economic storm, I had the opportunity to work with a client in the first quarter of this year in one of my favorite environments – IT.  I have found myself in various IT positions and consulting roles throughout my career, picking up technical skills as well as experience with ITIL, CMMi, and various development methodologies.  I have in many cases applied Lean and Six Sigma in conjunction with IT best practices to help organizations improve performance and save money.  Recently, I helped an organization shave millions in annual operating costs while significantly improving performance by applying agile work cells and leveraging a few simple Lean techniques such as one-piece-flow.  This article summarizes three methods nearly any IT support organization can use to drastically cut costs and improve performance.  Given the current economic and budget environment, this may be a timely read for some of our followers.

******

A graduate school professor assigns a software development final class project to teams of five students each.  All students on each five person team will receive the same grade and it accounts for 50% of the final grade for the class.  Team 1 (Sally, Jack, Dan, Tom, and Ken) and Team 2 (Bill, Dave, Will, Cindy, and Beth) take two different approaches to tackling the project. Team one assigns requirements to Sally, Design to jack, Development to Dan, testing to Tom, and presentation of the product to Ken.  Each person will perform their respective part of the project and then hand their work to the next until all work is complete and the final product is handed off to Ken who will present the final product to the professor and his assistant and the grade for the project will be determined.

Team Two decides that they will tackle each task from requirements through final presentation together, but take turns as the task leader based on the strengths of each team member.  The members of team two do not completely trust each other and want to make sure the project progresses on schedule and with high quality since it can cause them to fail the class if done poorly.  They also want to make sure they are all at the presentation to the professor just in case something goes wrong.

Which team would you want to be on? On team one, you know your part of the work, you can focus on your piece and the roles and responsibilities are clear.  On team two, the roles and responsibilities are blurred and everyone on the team will be pounding away the entire time to create the best product possible.  Anyone that has been to graduate school knows that almost without exception, students inherently adopt the collaborative approach of Team Two.  Why do these young minds, yet to be trained by corporate master-minds and molded by policy, politics, bureaucracy, and standardization take this collaborative approach almost every time.  It is because they still have “common sense” and they feel a true sense of urgency and commitment to excellence.  They know their future is on the line with each major project.  They also know that the deadline cannot be changed, resources are constrained, and quality cannot be sacrificed.  Common sense brings them together into what Lean experts call a work cell and software professionals call a Scrum team using an agile approach.

Is this really the best approach?  Many managers will say “this approach is a waste of labor.” “By taking team one’s serial approach they can have multiple projects underway, or Work In Process (WIP) with the same labor pool, while the team two approach limits me to one project at a time with the same resources.”  This is a logical pitfall.  Managers should focus on level of effort in value adding activities and throughput while minimizing WIP.  The Team Two approach on the other hand ensures a “connection” among tasks and essentially eliminates rework within the process.  It also eliminates work waiting in queues and mitigates risks associated with single points of failure in your labor pool.

Lean/Operations Research people call this one-piece-flow in a cellular work cell system.  This article is not a lesson in Lean.  It is a message that assembly line type of thinking is simply wrong in diverse IT environments as proven by the many successful Lean/Agile Scrum implementations.  Yet, this thinking is still prevalent and still the dominant approach to tackling IT projects in most organizations.

I have worked with numerous IT organizations from the largest telecommunications companies to start-up software companies and internal IT shops and can tell you with certainty, that a serial assembly line approach is almost always the wrong way to complete IT projects.  I remember clearly how one of the telecommunications firms I worked with, rooted in old school Bell Corps thinking insisted on breaking the work of implementing new equipment at their Points of Presence (POPs) into a serial approach of power installation, rack installation, equipment installation, wiring, configuration, test, and turn-up.  They would go round-and-round trying to get vital services running with each step of the process pointing fingers at the other. Projects usually made their way to some ridiculous phone conference where the bosses of the various technical teams would accuse each other of various sins until someone higher up would finally tell them all to get their technicians to the site at the same time and don’t leave until the service is working.  In other words, they pulled together a collaborative work cell to get the job done.  The technical leads would declare victory after working nights and weekends to get the service running. This scenario would play out over and over, but the process never changed. That was well over a decade ago and I would like to believe things have changed, but from what I hear, they are only a little better.

To avoid these same inefficiencies, to improve quality, and to drastically cut costs there are three simple methods we recommend.  We call this the “Lean Agile Work Cell Approach”.

1. Align your IT work force to customer value propositions (a.k.a. value streams)
2. Implement a Lean centric, pull based cellular work cell approach.
3. Adopt a unified process automation environment

Aligning your work force to customer value propositions is actually very simple.  Think in terms of the services your IT organization provides to the end customer.  For example, enterprise software projects and support, desk applications and support, and printer support.  You can also think in terms of Service Oriented Architecture (SOA).  You need to understand the Voice of the Customer (VOC) for each line of value.  You need to quantify the key metrics for satisfaction, performance, cost, etc.  You then need to align your teams and processes to these value propositions and measure everyone in them against the key metrics.

Creating pulled based cellular work cells is partially explained above.  As an example, consider the process of deploying new desk top operating systems in your enterprise.  If this process is done in a serial process, disconnected from the customer, you get a situation in which technical details and requirements are gathered for months, then handed off the a integrator that has to figure out the requirements and then develop integration scripts, which are then handed off to a testing team who will then get into a series of re-work loops with the integrator and after many months of testing, the operating system push will be sent to some type of distribution team that will then blindly launch the distribution process.  Alternatively, a series of small work cells containing integrators, testers, distributors, and customer technical liaisons can work together on a focused integrated project team to integrate, test, and deploy operating systems in a rapid order.  By testing at an incremental level and developing deployment scripts with an eye for testing and distribution at the same time, cycle time is significantly reduced and defects essentially eliminated.  This approach also allows for the operating system deployment team to learn from each iteration and get better with each operating system project from customer to customer.  In my firm, we have implemented similar work cells in various organizations with profound improvements in both effectiveness and efficiency.

Lastly, adopting a unified process automation platform is a powerful way to significantly reduce your IT license costs, maintenance costs, and software support costs while improving process performance.  For the last ten years, these tools have been called Business Process Management (BPM) and for the organizations that have adopted them and implemented well, great savings, process improvement, and transparency have been recognized.  The process automation environment becomes a process centric integrated development environment eliminating the need for custom software development, institutionalizing processes, but raising the need for proper IT Governance and enterprise architecture.  Today, process automation tools are available in cloud computing platforms and costs are falling precipitously.

In summary, the Lean Agile Work Cell approach to information system management creates agile work cells working in alignment with customer needs that are developing new software and managing their own work within a common process automation/development environment.  This is bad news for custom software development shops and great news for the CIO with a shrinking budget and pressure to show results.