In addition to a baseline measure, you also need a target! Make sure that you get agreement from your stakeholders regarding what the target should be. In other words, you want to try to get agreement on the definition of success - if we hit this target, then the system is successful. I can't emphasize the importance of this step enough: make sure that your stakeholders agree on the definition of success. In fact, I often start stakeholder interviews with these questions:
- How will you know if the solution we are building is successful?
- What specific measures will you use?
If I ask these questions up front, I have a pretty good clue on what I should be counting!
The image shows some of the targets we used for the support call deflection use case:
Measure and monitor: be prepared to change
Metrics are just a tool. The entire goal of your measurement program is to get better - to make changes to your solution or even your metrics program so that you can make better decisions and have a bigger impact on organizational results. One thing is certain: the complex and dynamic nature of pretty much all organizations means that the SharePoint solutions we build are going to have to be flexible enough to change in order to continue to provide value. The only way to understand what changes you need to make is to define and execute your measurement plan.
Use your measurement plan to assess how users are taking advantage of the solution and let it act as an early warning system to identify both new metrics and new capabilities that can help achieve your business objectives. In other words, use it to provide clues about what you need to change.
When a metric shows an unexpected result, try to find out why the result occurred. Is it due to a one-time event or it is an indicator of a trend? Ask yourself if the result you are seeing tells you that you may be measuring the wrong thing or whether there is something fundamentally wrong with the way the solution has been developed or deployed. At the very least, metrics will help you get ideas for how to improve your solution. Collect and prioritize these new ideas and go back to your original plans and assumptions to see if they need to be changed. Then, build consensus on what needs to be changed, how to make the change, and when and how to introduce the change to your users.
Sign up for Computerworld eNewsletters.