I was poking around for an EV document I had misplaced and came across a 2008 article by Scott Abler in Doctor Dobb's Journal. Scott is a thought leader in many areas of software development. I used his "process" books for many years when I was managing development organizations. I was troubled though by the misunderstanding of a core concept in Earned Value.
The premise that the "value" in Earned Value, is monetary value to the firm is not the case. The "V" in EV, is the measure of physical percent complete in units of measure of money. The money of the budgeted cost of work scheduled (BCWS). That is how much of the BCWS was converted into tangible items – physical percent complete. Whether the functional specification has are "balanced sheet" value to anyone is a local issue. If may be invaluable to NASA for the design of a manned vehicle. It may be worthless to the CIO who is on the line for making a service work.
The Value in Earned Value is not business value
For the government, it's an indication of how much "physical percent complete" has been accomplished to the "planned percent complete." Our firm manages software development projects in aerospace and defense and large IT (enterprise ERP) were EV provides measures of progress in ways not available in the absence of EV. These developments – even in A&D – make use of many of the principles of agile development, along with CMMI process areas.
In a later paragraph you mention EV effective if you have an effective plan. The opposite is actually true – if your plan is not effective you don't need project performance measures, because your project won't last long. Changes to the Performance Measurement Baseline (PMB, the source of BCWS) occur all the time. The need for a PMB, to show where we have come from and where we are going is the key to success of EV. Without some form of "baselining" the team is simply spending some else's money without accountability – this is a common failure mode for IT projects. In the EV world, this is called Level of Effort (LOE) – or "train watching" – actually "watching the train wreck." In LOE, the consumption of funds = progress.
BRUF, BDUF, big anything up front is not a prerequisite for EV. This is a popular myth of those unfamiliar with applying EV. Just the opposite in fact. Rolling Wave Planning Packages are part of DOD 5000.02. Only the open active work packages are used to perform measurements for management decisions.
If you invert your last paragraph of Scotts article and remove a few NOT's you've got how EV is done in A&D software development and Enterprise ERP.
- Define work packages that produce tangibly measureable outcomes. Be they complete and ready to ship, or measurably valuable intermediate deliverables need to produce the actual deliverables. It's the focus on deliverables and the planned value – earned value- for these. Predefining the Earned Value target, and measuring physical progress – physical percent complete – in a standard unit of measure, is what allows EV to be a stable estimator of progress to plan.
- Define what "physical percent complete" means for each work package. We typically (of IT) use an apportioned milestone method within the work package. Define this upfront, measure to the agreed outcomes (deliverables) and record this progress for forecasting future progress. NEVER CONFUSE EFFORT WITH RESULTS. Only measure tangible deliverables. Typically the tasks within a work package have 0/100 measures. Either you're done or you're not done. No partial credit.
- In the worlds we work, Scrum and EV, along with Integrated Master Plan / Integrated Master Schedule are all cousins. IMP/IMS requires you measure progress by the increasing maturity of the product or service being built. Assessment points (Events), are "assessed" with Significant Accomplishment (what is the evidence that you are at a level of maturity you say you are), and Accomplishment Criteria (what is the exit criteria for the Work Package)?
- The notion that partial maturity and 100% completion are strategies for performance is lost on most people outside of defense. For example:
- I need a database to be stood up for a customer order tracking system
- What are the incremental measures of maturity for this database? This could be the "walking skeleton" as someone called incremental parts.
- But what are the actual units of measure for this incremental piece? Critical tables defined, critical PL/SQL tested, etc.
- Define all this before starting work so you can do one critically important thing that the majority of IT projects we rescue don't – WHAT DOES DONE LOOK LIKE? And how would we recognize we're moving toward DONE, along the way?
Answering the question – What Does Done Look Like – means defining done in some unit of measure meaningful to both the customer and the project team. Physical Percent Complete of a tangible deliverable is a good place to start. Testable Requirements is the formal approach to this outside the agile world. No matter the approach the legal definition is "evidentiary materials." Show me something that you said you were going to show me, and show that it is "done." Not almost done, not "I'm gonna fix the bugs over the weekend," not "well I worked on my machine." No Done, means you won't have to touch this again unless the requirements change. We can ship it. to the customer or the SCC system.
Now how much did we plan to spend for this "done-ness?" If it is completely done, then you get 100% credit for being 100% physically percent complete. BCWP = BCWS X Physical Percent Complete. The actual cost to do the work is a cost management issue, not a schedule management issue.
If you spend the planned budget but were not 100% done, then several things result.
- You're over budget
- You're behind schedule
- You've had to remove features
- You've got rework to do
- You'll have to rob future Work Packages of their budget and schedule to get this Work Package "done"
These are all correct responses. Making them visible is the role of Earned Value.
