We have spend the past several weeks covering how to deliver efficiency and cost reduction in IT, and particularly how to do it while maintaining or improving your capabilities. In my last post we discussed some two long terms tactics to drive efficiency but also at the same time to achieve improved capability. In this post we will cover the another key long term tactics that you can leverage to achieve world class cost and performance: leveraging metrics and benchmarking.

Let’s assume you have begun to tackle the quality and team issues in your shop. One of the key weapons to enable you to make better decisions as a manager and to identify those areas that you need to focus on is having a level of transparency around the operational performance of your shop. This doesn’t mean your team must produce reams of reports for senior management or for you. If fact, that is typically wasted effort as it is as much a show as real data. What you require to obtain effective operational transparency is the regular reporting of key operational metrics as they are used by the teams themselves. You and your senior team should be reviewing the Key Process Metrics(KPMs) that are used by the operational teams to drive the processes day-to-day and week-to-week. These would include things such as change success rates by team or a summary of project statuses with regular project reporting behind each status.

The ability to produce and manage using metrics depends substantially on the maturity of your teams. You should match the metrics to be reported and leveraged to your team’s maturity with an eye for the to master their current level and move to the next level.

For example, for production metrics you should start, if a Level 1 or 2 organization, with having basic asset information and totals by type and by business along with basic change success volumes and statistics and incident volumes and statistics. A level 3 organization would have additional information on causal factors. So in addition to change or incident statistics there would be data on why (or root cause) for a failed change or a production incident. A level 4 organization would have information on managing the process improvement itself. Thus you would have information on how long root cause takes to complete, how many are getting resolved, what areas have chronic issues, etc. Consider the analogy of having information on a car. At the lowest level, we have information on the car’s position, then we add information on the car’s velocity, and then on its acceleration at the highest level.

These three levels of information (basic position and volumes, then causes and verification metrics, then patterns and improvement metrics and effects) can be applied across any IT service or component. And in fact, if applied, your management team can move from guessing what to do, to knowing what the performance and capabilities are to understanding what is causing problems to scientifically fixing the problems. I would note that many IT managers would view putting the metrics in place as a laborious time-consuming step that may not yield results. They would rather fly and direct by the seat of their pants. This is why so many shops have failed improvement programs and a lack of effective results. It is far better to take a scientific, process-oriented approach and garner repeatable results that enable your improvement programs to accelerate and redouble their impact over time.

Another advantage of this level of transparency is that both your team and your business partners can now see measurable results rather than promises or rosy descriptions. You should always seek to make key data a commodity in your organization. You should be publish the key process metrics broadly. This will reinforce your goals and the importance of quality throughout your team and you will be surprised and the additional benefits that will be gathered by employees able to now to a better job because they have visibility of the impact of their efforts.

And when you do develop key process metrics, make sure you include metrics that have business meaning. For example, why publish metrics on number of incidents or outage time (or conversely system time availability) to your business partners? While there is some merit in these data for the technical team, you should publish for the business in more appropriate terms. For availability, publish the customer impact availability (which would be the total number of transaction failed or impacted to a customer divided by the total number of transaction that typically occur or would have occurred that month) plus the number of customers impacted. If you tell the business they had 50,000 customers impacted by IT last month versus you had 98.7% system time availability, it now becomes real for them. And they will then better understand the importance of investing in quality production.

In essence, by taking a metrics-based approach, we in IT are then following in the footsteps of the manufacturing revolutions on process that has been underway for the past 60 years. Your team should know about the basics on Continuous Process Improvement and Lean. Perhaps give them some books on Deming or others. We should run our shops as a factory for all of our routine or volume services. Our businesses must compete in a lean manufacturing world, and our work is not handcraft, it should be formalized and improved to yield astounding gains that compound over 12, 24 or 36 months.

On a final note, once you have the base metrics in place, you should benchmark. You will have one of two good outcomes: either you will find out you have great performance and a leader in the industry (and you can then market this to your business sponsors) or you will find out lots of areas you must improve and you now have what to work on for the next 12 months.

 

Have you seen success by applying these approaches? How has your team embraced or resisted taking such a disciplined approach? What would you add or change?

 

Best, Jim