Concept: How well or poorly is time being used on the project? One way to tell is by the effect of schedule performance on the end date.
Practice: That’s where EACt fits in. It’s an estimate of how long it will take to complete the project, assuming that future performance will be similar to past performance.
A Controversial Assumption
But, is that assumption correct? As pointed out by Glen Alleman (2015) there are factors that militate against an assumption of similiarity:
- Are work products in the future really the same as those in the past?
- Is there future growth in complexity due to increasing interdependency between work products?
- What about emerging requirements?
- Surely, the externalities around a project evolve
with time—changing budgets, increased competition, unforeseen pandemics.
At the same time, in many domains, there is a consistent pattern of work products.
- Software development, for instance, rarely varies from a basic model: analysis-design-build-test-deliver, although the steps do not have to be done in waterfall fashion.
- For construction projects, planners generally embroider standard templates, rather than building schedules from scratch.
The assumption of continuity appears to be viable in at least some domains. Admittedly anecdotal, our experience at ProjectFlightDeck has been that over the long term, there’s enough consistency to support the use of EACt, especially given its benefit.
The Benefit of EACt
Unlike the ES metrics considered previously (ES and SPIt), EACt offers quantitative grounds for assessing schedule performance.
EACt can be compared to allowances for uncertainty (Alleman, 2017). The allowances are usually expressed in Contingency and Reserve, where Contingency is part of the baseline and Reserve is beyond the baseline but within the negotiated timeline.
As the EACt crosses boundaries set by Contingency and Reserve, it signals worsening performance. That’s often represented as a progression from “Green” status through “Yellow” (across Contingency) to “Red” (beyond Reserve).
Assuming uncertainty allowances are sound, the performance assessment rests on quantitative threshold values rather than on impression and intuition.
EACt therefor applies uniformly across projects of different sizes, as long as they have made allowances for uncertainty.* EACt works works equally well on projects that use different approaches, from Agile to plan-driven.
EACt Warning Label
Use of nominal EACt should bear a warning label, however.
The danger is exaggerating the import of the metric. We have observed cases in which the EACt was called called “definitive”, giving the impression that it guarantees a duration. That must be avoided.
EACt is not definitive; it’s indicative. It’s not a guarantee; it’s a point estimate. But, even that is too much. To reference Glen once more: “No simple point estimate can be credible without the variance” (Alleman, 2013).
How does Earned Schedule meets Glen's challenge? See the next post.
References:
Alleman, G. (2017, November 30). Aleatory and epistemic uncertainty in software development projects. Retrieved from http://herdingcats.typepad.com/my_weblog/2017/11/aleatory-and-epistemic-uncertainty-in-software-development-projects.html.
Alleman, G. (29 March 2015). How to Avoid the
"Yesterday's Weather" Estimating Problem. Retrieved from https://herdingcats.typepad.com/my_weblog/2015/03/hoe-to-avoid-the-yesterdays-weather-estimating-problem.html.
Alleman, G. (01 February 2013). A Point Measure Needs a Variance. Retrieved from https://herdingcats.typepad.com/my_weblog/2013/02/a-point-measures-need-a-variance.html?cid=6a00d8341ca4d953ef017ee8440b8b970d%20-%20comment-6a00d8341ca4d953ef017ee8440b8b970d. |
