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?

  • excuse me, but I don't understand your words: "The main issue I am having is that, for some reason (lack of attention from my issue administrator or client constant changes), this have only become handy to refer back to change documentation." Feb 11, 2011 at 4:58
  • @Long, I reworded the last paragraph based on your comment. Please let me know if this is better now.
    – Geo
    Feb 11, 2011 at 22:34

3 Answers 3


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.

  • Thanks for this response. I use a 50/100 model for all tasks in the project plan. If the person started the task is 50% done, if is completed is 100, this keeps it simple and consistent across all my projects. I will like to understand more how you accomplish the first part of your plan. Where you said "know how are you going against the plan"
    – Geo
    Feb 11, 2011 at 22:38
  • Assume I have 20 tasks and I plan that team completes a single task every 4 days (that's the case from my last Kanban team). After 40 days the team should have completed 7-8 tasks. I can compare number of completed tasks with that and learn how screwed we are ;) Of course this is huge oversimplification but you see the pattern. Feb 12, 2011 at 13:11

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.


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

  • Mark, I think I get the essence of the answer, but not completely. I like the comparison, but who I am putting in the "payment history report", the client or the team members? I guess, I just need the final push on your idea to get it. sorry.
    – Geo
    Feb 11, 2011 at 22:41
  • The report is about the client. Accounting/billing is someone who would get the report and use it when pricing another project for that client. Does that help? Feb 14, 2011 at 1:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.