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.
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
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.