7 Dirty Little Truths About Metrics from DITY

Looks like today is a number day! The previous post was with the number 6 and this one with the number 7.

Hang Marquis in this weekly newsletter from DITY (Do IT Yourself) writes some truths about Metrics followed by a simple checklist to create metrics that matter.

Click here to read the article or here to download a PDF. For my own benefit, here is the checklist that he has written in his article:

Align with Vital Business Functions. Regardless of the IT activity, you need to make sure your metrics tells you something about the VBF that depends on what you are measuring.

Keep it simple. A common problem manager fault is overloading a metric. That is, trying to get a single metric to report more than one thing. If you want to track more than one thing, create a metric for each. Keep the metric simple and easy to understand. If it is too hard to determine the metrics, people often fake the data or the entire report.

Good enough is perfect. Do not waste time polishing your metrics. Instead, select metrics that are easy to track, and easy to understand. Complicated or overloaded metrics often require excessive work, usually confuse people, and do not get used. Use a tool like the Goal Question Metric (GQM) model to clarify your metrics.

Use metrics as indicators. Key Performance Indicators are metrics! A KPI does not troubleshoot anything, but rather the KPI indicates something is amiss. A KPI normally does not track or show work done. Satisfying several KPI normally means satisfying the related CSF. The KPI is an indicator, a metric designed to alert you that CSF attainment might be in jeopardy, that is all. A good metric (KPI) is just an excellent indicator of the likelihood of attaining a CSF.

A few good metrics. Too many metrics, even if they are effective, can overwhelm a team. For any processes 3 to 6 CSFs are usually all that is required. Each CSF might have 1 to 3 KPI. This means most teams and individuals might have just 2-5 metrics related to their activities or process. Any more and either the metrics won’t get reported, or the data gets faked. Too many metrics transforms an organization into a reporting factory — focusing on the wrong things for the wrong reasons. In either case, the usefulness of the metric is compromised.

Beware the trap of metrics. Failure to follow these guidelines invariably results in process problems. Look around your current organization.

And talking about number 8, here is a link to another post that talks about 8 features of a successful real time dashboard.

Project Failure and Success

Link to Six reasons of project failure. I got this article on a post written by Michael Kringsman where he has referenced this blog post by Michiko Diby. Michiko in his post has talked about the 6 reasons of project failure in detail and also has links to explain the reasons.

The reasons which have been highlighted in these posts are:

Intent Failure – Occurs when the project doesn’t bring enough added value or capability to beat down the obstacles inherent throughout the process. This suggests the original intent of the project was flawed from the beginning.

Sponsor Failure – Occurs when the person heading up the project is not actively engaged and/or does not have the authority to make decisions critical to project success.

Design and Definition/Scope Failure – Occurs when the scope is not clearly defined, so the project team is unclear on deliverables.

Communications Failure – Occurs when communications are infrequent or honest discussion of project problems and issues are avoided.

Project Discipline Failure – Occurs when process/project methodology is allowed to lapse so that the mitigation factors inherent in the process are never used.

Supplier/Vendor Failure – Occurs when the structure of supplier /vendor relationships doesn’t allow for communication and adjustments.

In addition to these, here are a few that I added in the comments:

• Change Process failure – where the scope and deliverables keep changing and there is no set/agrees change process to update the scope
• Skill Failure – when the right skills are not identified for a task and it takes longer than expected
• Stakeholder identification failure – where the reviewing authority/decision making authority is clearly identified
• Turnaround time failure (similar to Project Discipline Failure) – where the participants other than the key project team members fail to revert back in time

Michael Kringsman has a post on IT project success as well which can be read here.

Text in italics is from Michiko Diby’s post, and the clip-art is Microsoft PowerPoint