Go to Top

Making Metrics Work for You

I recently read an article in CLOmedia about the challenge of measuring corporate learning. According to the article, measuring the effect of training proved difficult due to it being a non-revenue generating activity, i.e., it is essentially a support activity. This led me to think about how common this challenge is regardless of what you are measuring—be it a project you are running or a process improvement you are implementing.

Measure of success
IT Project Metrics
Let’s use the example of running a large IT implementation project to further take a look at metrics in use. IT is generally classified as a support function. Organizations typically justify the expense of a project with a long list of benefits including revenue increases, cost savings and resource realignment regardless of whether these aspects can be directly related to the project. The intent is to secure funding and start the project. However, doing a back-end analysis of whether or not these benefits were achieved is oftentimes lacking. The question is why.

Defining the Metrics
Many organizations cite that the data is not available or they lack the tools and expertise to do the analysis. However, in my experience, it is more due to an inability to define the metrics upfront in a way that can be captured on the back-end. In other words, it is a business process problem, not a technical one

First and foremost, metrics should be defined in terms of alignment to the organization’s strategic goals. We’ve talked about this concept at length in previous blogs (see Developing a Balanced Strategy). The point is that project metrics should be defined in such a way that a causal relationship can be determined after implementation.

Determining Efficacy
Effectiveness of the IT project is another component to consider when defining your metrics upfront. Software that is elegantly configured but that no one uses cannot be deemed a success. Consider defining metrics that revolve around solving the problem you set out to solve. Examples include: How many transactions are correctly processed the first time (i.e., first past yield)? Are Help Desk inquiries trending up or down?

Defining efficiencies that you expect to attain through the use of the new software can result in measureable benefits at the back end. Questions you should consider include:

  • Do you expect the retirement of manual processes? Define those processes upfront.
  • Is transaction time expected to decrease? Be sure to measure transaction time before and after the project completion.
  • Is the number of transactions per headcount (i.e., throughput) expected to increase? Make sure you capture trends throughout the implementation.
  • Are resources expected to be redeployed as a result of the implementation? Lay out the before and after picture as part of your analysis.

Defining metrics that can be tied to your strategic goals, have a causal relationship to the project under discussion and can be captured before and after the project is implemented can go a long way to helping justify your project.

, , , , ,

Add to the conversation

Leave a Reply

Your email address will not be published. Required fields are marked *