Metrics_ How to Improve Key Business Results - Martin Klubeck [39]
Also, experiment with different ways to depict the metric. You might even test ideas for the visuals with your metric customers.
Narrative Description
I love it when someone asks, “Do I have to spell it out for you?” My answer is frequently, “Thanks! That would be nice.”
Why not? No matter how good your graphical representation is, you can’t afford to risk a misunderstanding. You rooted out the question and you designed the metric so that you could provide the right answer to the right question. You cannot allow the viewer of the metric to misinterpret the story that you’ve worked so hard to tell.
The narrative is your chance to ensure the viewer sees what you see, the way you see it. They will hopefully hear what you are trying to tell them. Any part of the plan can be updated on a regular basis, but the narrative requires frequent documentation. Since the narrative explains what the metric is telling the viewer, the explanation has to change to match the story as it changes. The narration which accompanies the picture and documents what the metric means is critical to how the metric will be used.
Figure 3-6 shows when the narration is documented.
Figure 3-6. Narrative
Documentation: Making the Metric Development Plan More Than a Plan
In the end, the metric development plan should document the why (purpose statement), what (metric), when (schedule), who (customers), and how (analysis, how it will and how it won’t be used).
Document it as thoroughly as possible—putting all of the details into one place. This will help you in the following three ways:
It will help you think out the metric in a comprehensive manner.
It will help you if you need to improve your processes.
It will help you if you need to replicate the steps.
Figure 3-7 shows them all together in coordination with the process for developing the metric.
Figure 3-7. The Development Plan
Rather than prescribe a length or specific format, I want to stress the readability of the final plan. You will want it for reference and at times for evidence of agreements made. I find it extremely useful when the metrics are reported infrequently. The more infrequently the metrics are reported, the more likely I’ll forget the steps I followed. The collection can be very complicated, cleaning the data can be complex, and the analysis can require even more detailed steps. The more complex and the more infrequent the process, the more likely I’ll need the plan documented.
Of course, even if I perform the process weekly, the responsible thing to do is to document the plan so others can carry it out in my absence.
The plan has use throughout the life of the metric. It starts out helping me to fully think out the design and creation of the metric. It then helps in capturing the agreements made around the metrics use and schedule. It helps in defending actions (it becomes a contract between the metric analyst and the data providers and the end customer) and meeting expectations. Finally it is also critical to long-term success. It provides a historical view as well as a “how to” guide. Without repeatability you can’t improve.
Without repeatability, you can’t improve.
The components of the development plan need to be documented in a manner that allows easy and accurate access. Ensuring accuracy is more difficult than making it easy to access. We discussed different means of collecting data and ways to make it more accurate. The really good news is that many times, the way we make it more accurate also makes it easy to access. Less human interaction moves us toward more confidence in the accuracy of the data, and automation makes it easier to collect.
When you document the components, don’t be afraid to be verbose. This isn’t a time for brevity. We need to build confidence in the metric and the components. We need to document as much information around each component as necessary to build trust in the following:
Accuracy