Task Status
"Are we There Yet?"
If you are a parent who has driven long distances with young children, you have probably heard this plaintive cry from the back seat. Project managers hear it often, and from just about every stakeholder. In the context of project management, the question is really: "When the budget is spent, and the schedule has expired, will the work be done?"
Unfortunately, many projects focus on tracking schedule and cost, but do a poor job of tracking technical performance. So we can see how much money we have left and how much time is left before we need to be at our destination, but we can't clearly see how far we have traveled, or how far we have left to go!
Some projects will try to derive technical performance numbers by obtaining estimates of task percent complete from the team, or a report of time spent along with an estimate to complete. In essence, they use proxy data as indicators of technical performance. This raises some questions. On what basis were the estimations made? Are they accurate? Consistent? Defensible? Is the estimate a measure of effort or results?
The question then becomes: What can we use as a reliable indicator of task status? A simple solution is to look at a task's deliverables. Only when the deliverable is, er, delivered, can we say that the task is 100% complete.
For example, let's say that we have a very simple project to write and approve a requirements document for a new inventory report. We have in hand an estimate that says it will take 40 hours of effort, and the project has been given a single Business Analysis resource billed at $100/hour and allocated at 100%, ready to start next Monday.
The task deliverable is clear: an approved requirements document. Since the project is relatively short, the value of a percent complete measurement is not very useful and all stakeholders should agree that the task can only be either 0% or 100% complete. The task will be 100% complete only upon receipt of the draft document, and will be 0% complete otherwise. We either have the document or we don't.
What about long-duration tasks? For these, we can define intermediate milestones, and agree on an allocation of their percents complete. For example, let's say we agree that when the first draft of the document is received, the task is 50% complete, and upon document approval the task is 100% complete. The task can now be 0%, 50% or 100% complete. Again, we will not ask for a percent complete, since we have explicitly stated that the task will be 50% complete upon receipt of the first draft, and 100% complete upon approval of the document.
Notice that we will not be asking the analysis for an estimate of percent complete. Instead, we introduce an objective, consistent and defensible way to measure technical progress. This method measures results rather than effort, and since results are the whole point of a project, we no longer need to rely on a vague estimate of percent complete to get an accurate picture of task status.
Next time: How *not* to measure variance.
If you are a parent who has driven long distances with young children, you have probably heard this plaintive cry from the back seat. Project managers hear it often, and from just about every stakeholder. In the context of project management, the question is really: "When the budget is spent, and the schedule has expired, will the work be done?"
Unfortunately, many projects focus on tracking schedule and cost, but do a poor job of tracking technical performance. So we can see how much money we have left and how much time is left before we need to be at our destination, but we can't clearly see how far we have traveled, or how far we have left to go!
Some projects will try to derive technical performance numbers by obtaining estimates of task percent complete from the team, or a report of time spent along with an estimate to complete. In essence, they use proxy data as indicators of technical performance. This raises some questions. On what basis were the estimations made? Are they accurate? Consistent? Defensible? Is the estimate a measure of effort or results?
The question then becomes: What can we use as a reliable indicator of task status? A simple solution is to look at a task's deliverables. Only when the deliverable is, er, delivered, can we say that the task is 100% complete.
For example, let's say that we have a very simple project to write and approve a requirements document for a new inventory report. We have in hand an estimate that says it will take 40 hours of effort, and the project has been given a single Business Analysis resource billed at $100/hour and allocated at 100%, ready to start next Monday.
The task deliverable is clear: an approved requirements document. Since the project is relatively short, the value of a percent complete measurement is not very useful and all stakeholders should agree that the task can only be either 0% or 100% complete. The task will be 100% complete only upon receipt of the draft document, and will be 0% complete otherwise. We either have the document or we don't.
What about long-duration tasks? For these, we can define intermediate milestones, and agree on an allocation of their percents complete. For example, let's say we agree that when the first draft of the document is received, the task is 50% complete, and upon document approval the task is 100% complete. The task can now be 0%, 50% or 100% complete. Again, we will not ask for a percent complete, since we have explicitly stated that the task will be 50% complete upon receipt of the first draft, and 100% complete upon approval of the document.
Notice that we will not be asking the analysis for an estimate of percent complete. Instead, we introduce an objective, consistent and defensible way to measure technical progress. This method measures results rather than effort, and since results are the whole point of a project, we no longer need to rely on a vague estimate of percent complete to get an accurate picture of task status.
Next time: How *not* to measure variance.
posted by michael at 8:20 PM
1 Comments:
In Project Management terms, a task has well-defined start and end points in the form of effort and duration.
More importantly, how are we to know when a task is complete? A task has success criteria, in the form of well-defined outcomes. Tasks deliver results, which are measured against their expected outcome. It is not the task activities, but their outcome that is important.
For example, we gather requirements because we need to understand what the business is trying to accomplish. A requirements gathering effort that does not advance our understanding of the problem to be solved has not met its success criteria. Reaching a "requirements signed off" milestone therefore, means more than the fact that we have completed a task. It means that we have increased our capability in some way, and the project has matured toward its objective.
Along with cost and schedule, this is key measurement of project success.
Post a Comment
<< Home