What metrics to keep through out the life of the project?

Question

Apart from the regular cost/scope/time metrics that every project contains, I am interested in knowing if I can include a few more metrics that will trigger alerts on future projects.

Let me exemplify what I mean. As a pilot I have started to keep track of all project issues in the register, these include: Change Requests, Tasks that rise but are not worthy to go into the plan, decisions, etc. Having a count of these every week let the management team know that there is additional work coming down the pipe.

The issue I am having is that I am not sure yet if these metrics have been helpful or not. Either because lack of attention of my issue administrator or client constant changes.

Any ideas that might help?

Answer 1

In the first place I would add keeping your historical estimates (no matter how you make them) and real effort spent on tasks. This will help you to tell how reasonable your current estimates are and make them better. It will also give you another tool to discuss new work incoming to the project or raise red flags when you know that you're not going to make it before the deadline.

If you have something like general plan and work doesn't just come constantly in a steady stream I'd also like to know how are you going against the plan. This means you would need good work breakdown structure and update information how much is done regularly. One issue here: percent complete should be updated by the people who do the work, but sometimes you see that everything is 90% complete and nothing is 100% complete, which basically means you're screwed. In vast majority of cases you should count a feature as done only when it's on 100%, not any lower.

Answer 2

A metric that you might want to add is velocity.

Before a project usually starts some form of schedule outlining milestones and resource allocation is created. Milestones are made up of a number of sub tasks. The speed at which these tasks are completed against the original estimate is known as velocity. Whilst a project may be delivered on time and near budget you will find the velocity will be poor at he start of your roject but vastly improves (I.E., more tasks completed more frequently) as the project comes closer to delivery. The reasons for this may include; improved domain or business knowledge, better communication, etc. You should also find that as velocity improves so does your ability to determine the delivery date. Velocity is evident in many aspects of IT agile project management, for example a scrum burndown chart.

Without wanting to preach I feel that it is important to understand, record and diagnose velocity and how it can benefit you to deliver your projects.

Answer 3

It sounds like a client profile would be helpful.

This would contain specific information on the client's behavior throughout the project lifecycle. Most specifically, this will help you price/cost the next project.

In terms of metrics, this can be as simple as estimated vs actual time spent on the project across all tasks. Big deviation means that either the project wasn't well estimated or that the scope of work changed a lot over the course of the project. Over time, you'll be able to best isolate the cause, but at least you'll start to have a record of it per client.

To make this even more actionable, put your accounting or billing department as stakeholders on the report for this metric (just like how they might keep a record of each client's payment history e.g. who pays early, on time or late).