Task Complete
Last time I advised that actual cost (AC) should be used to determine EV (BCWP). The reasoning, which would have been more fully explained in a follow-up post on handling work in progress, was that a task's percent complete can be given as AC / (AC + ETC), so that EV = percent complete x PV.
In order to make this approach work, I introduced a rule that EV cannot exceed PV, no matter what the AC. I received some excellent feedback on that rule, and although the math still works, I am now convinced that it only adds complexity. More importantly, it relies on AC as a proxy for the quantity of work completed, and thereby assumes that effort equals results. As Glen Alleman pointed out, this is a dangerous assumption. The issue of completeness is therefore left unresolved. How are we to know when a task is complete?
Tasks should have success criteria, in the form of well-defined outcomes. Unfortunately, project managers seem to focus more on task activities than on outcomes, perhaps because of pressure to meet schedule and budget constraints. In reality, activities lead to outcomes, and only upon receipt of an outcome is the project matured toward its objective. Therefore, it is not so much the activities that are important, but their outcome.
Outcomes can then be measured against expectations, and a determination made about the completeness of the task. Glen suggests physical evidence as a key indicator of completeness. I would amend this to say physical evidence which everyone agrees meets the task success criteria. Incomplete or low quality results may not sufficiently advance the project's maturity. For example, a requirements gathering effort that does not provide an understanding of the problem domain has not met its success criteria. Reaching a "requirements signed off" milestone therefore means that everyone agrees that the task has met its success criteria.
In order to make this approach work, I introduced a rule that EV cannot exceed PV, no matter what the AC. I received some excellent feedback on that rule, and although the math still works, I am now convinced that it only adds complexity. More importantly, it relies on AC as a proxy for the quantity of work completed, and thereby assumes that effort equals results. As Glen Alleman pointed out, this is a dangerous assumption. The issue of completeness is therefore left unresolved. How are we to know when a task is complete?
Tasks should have success criteria, in the form of well-defined outcomes. Unfortunately, project managers seem to focus more on task activities than on outcomes, perhaps because of pressure to meet schedule and budget constraints. In reality, activities lead to outcomes, and only upon receipt of an outcome is the project matured toward its objective. Therefore, it is not so much the activities that are important, but their outcome.
Outcomes can then be measured against expectations, and a determination made about the completeness of the task. Glen suggests physical evidence as a key indicator of completeness. I would amend this to say physical evidence which everyone agrees meets the task success criteria. Incomplete or low quality results may not sufficiently advance the project's maturity. For example, a requirements gathering effort that does not provide an understanding of the problem domain has not met its success criteria. Reaching a "requirements signed off" milestone therefore means that everyone agrees that the task has met its success criteria.
posted by michael at 8:03 PM
3 Comments:
Michael,
I notice the equation of AC/(AC+ETC). This approach lays the gorund work for the notorious manipulation of the EV numbers for the benefit of the project.
If ETC+AC (Estimate to Complete + Actuals to Date) is beyond the BAC (Budget at Completion), then the activity is "over budget" or "Off baseline." If the activity is Baselined, adding ETC is OK, since it will show the forecast effort to complete. BUT and this is critical since is it done all the time, the activity can not be re-baselined with the new ETC.
Now back to the current post. In fact PV(BCWP) can exceed the PV(BCWS) for seevral reasons.
1. The actual value of the deliverable in units measningful to the customer can exceed planned value.
2. If we're bending metal into money, the PV and AC make be on plan, but we produced more than planned in terms of EV.
One term useful in place of "success criteria" is "Exit Criteria."
Glen,
Your point about the tendency to re-baseline projects is a good one, but it's not always a lack of project discipline that causes a PM to do it. There are are lot of influences on a project, both internal and external, many of them political, and virtually any technique can be twisted to nefarious purpose. I'm not sure that obviates the approach.
Your point that PV(BCWP) can exceed PV(BCWS) is extremely interesting because it brings up what must be a common source of confusion in EVM: the term "value". In my reading on EVM, I have never seen this addressed, but a key assumption in EVM seems to be that value and cost are the same thing. It appears that we are actually measuring cost, but calling it value. For example, during the planed value "phase" of EVM, are we projecting the actual *value* of the project to the business or the customer? Or just the project's cost? In my experience, value is expected to be at least equal, but usually greater than cost, otherwise it's unlikely we would be doing the project. But it is cost, not value, that we record as BCWS. Otherwise, why isn't it called BCVS?
The case where the team produces more than what was planned even though AC <= PV, presents a similar problem. How are we to measure the additional value? The customer could perceive that the project added value, while the PM sees it as a lost cost savings opportunity. Again, value vs. cost.
Sorry, I meant BVWS, not BCVS.
Post a Comment
<< Home