There are two reasons to collect measures on your project — to improve processes and to declare success. Let's look specifically at "declaring success." Before the project starts, you should work with your sponsor to define what success looks like. For instance, there is probably a deadline and maybe a budget you're trying to achieve. You might also have success metrics around product quality, customer satisfaction, defect rates, etc.
The old adage about "what gets measured gets done" is true on projects. Once you have the success criteria defined, it's necessary to determine how you're going to measure whether you achieved the criteria. This includes defining targets for your success measures and then actually measuring to see if you achieved your targets. Let's look at three examples:
- If it is important to hit a deadline date, the project manager should be updating the estimated deadline dates throughout the project.
- If project team communication is important on your project, you will want to build some metrics (maybe a customer survey) that provide an indication of how effectively the team is communicating.
- If you are encouraging your team to reuse existing components, track the instances of reuse and the hours and cost savings.
If you're using metrics to declare project success, you should periodically measure throughout the project. Otherwise, you won't know if you are heading toward success or not. Let's take the prior example where the project team was being measured on how well they were communicating. You don't want to wait until the end of the project to take your first survey. If you do and you didn't achieve your target, you'll have no way to improve. Instead, you should send a survey out you'll have a chance to make improvements before the project is completed.
A good thing about metrics is that they will drive certain behaviors. However, it's critical that the metrics not drive unintended behaviors. For example, a team was being measured on the length of time that it took to close problem tickets that were opened in the testing process. The target was to close the problem ticket in two business days. Seems simple enough, right? However in reality, if a team member could not determine the cause quickly enough, he or she guessed at the cause, made a quick change and then closed the open ticket. If the guess didn't solve the problem, a new problem ticket was opened and quickly resolved again. The result was repetitive thrashing of problem tickets, wasting much more time than required. In this case, one of the problems was the metric. This team looked good on paper, since they were closing problem tickets quickly. However, you can see that they were really performing poorly, generating extra work and causing the client to be dissatisfied. In this case, perhaps a better metric would have been to consider the ticket successfully "closed" only after the resolution had been independently verified.
It's good practice to determine ahead of time what it means for the project team to be successful. However, make sure you are smart about the way the success metrics are defined and reported so that they end up driving the desired behaviors.