Herding Cats

Yet another misunnderstanding of Earned Value

Roger Kent posted a comment in the current edition of PMI's PM Network. It's one of those posts that causes a twitch to appear in me if for the only reason there is a PMI logo on the material.

Let's start with the second edition of the Earned Value Management Practice Guide for look at Roger's comments:

• EV actually comes from the shop floor, where the question was are we earning our budget for this work.
• EV doesn't care about the size of the project, it simply asks the question if we had planned to spend an amount of money to produce an outcome, did we spend this money at the planned time for the planned outcomes. And if so did this outcome fulfill the planned requirements? That is was the outcome 100% complete on the planned day for the planned amount?
• You'd think that for a Project Manager knowing the percent complete of your efforts would be an important measure of the project's success. If you're making these numbers up, you've got bigger problems than understanding the application of EV.
• If Roger has a project that is 95% complete for a long time, he needs EV. He'd see that the project is now making no progress and it's just spending money. The CV is going in the ditch along with the SV.
• EV works for any project that has a budget, has a means of capturing actual costs, and a means of measuring physical percent complete against the planned percent complete. You know a credible project plan with a credible project management method. Don't have this information, no problem, you'll discover soon enough you're late, over budget, and you're gadget probably doesn't work.

So the real question is how can a PMI publication, with a contribution from a PMP, who provides PM consultanting not have a basic misunderstanding of how EV contributes to increasing the probability of project success?

I'm not suggesting at all that every project should make use of EV. But that decision needs to be made in the presence of the 5 Immutable Principles of project management. Then those making the decision can determine how to answer those questions in the absence of EV for the neede to measure progress to plan, cost, and techncial performance.

Two Mandatory Readings

The Association of Project Management (APM) has produced a guide for integrating Risk and Earned Value.

I sit on a NDIA Committee in the Program Management Steering Committee (PMSC) that is addressing the same issue - how can risk and opportunity be integrated with Earned Value.

The core issue here is what does it mean to be managing a program using earned value if the risk of completing on time or on budget is not considered in the Performance Measurement Baseline?

The establishment of the Performance Measurement Baseline is described in a anchor diagram.

1. Establish the project context
2. Develop the Statement of Work and initial WBS
3. Develop the top down budget and schedule
4. Identify the strategic level risks
5. Perform  the initial risk analysis
6. Revise the top down budget and schedule
7. Integrated the WBS and OBS
8. Create control accounts and perform risk analysis
9. Update the initial Performance Measurement Baseline
10. Update and baseline the project risk register
11. Approve the PMB and the Management Reserve (MR)

The second must read document is the new - Version 2 - Practice Standard for Earned Value Management. I started working on the agile and EVM appendix, but discovered the PMI Practice Guide is not based on ANSI-748B. Fortunately the Practice Guide dropped that appendix, so it was a moot point.

What is important is that the Earned Schedule Appendix made it thanks to the work of many, but especially Kym Henderson.

What's interesting though is ANSI-748B is mentioned 3 times.

• Page 8 - contingency
• Pages 46 and 47 - contingency reservers
• Page 52 - contingency

This contingency paradigm is common in construction and the Department of Energy.

No where else in the Practice Guide is 748B mentioned. I find this a big gap, since 748B desribes 32 criteria for a successful EVM System.

The chapters of the Practice Guide address many of the criteria found in 748B

• Organize the project
• Assign responsibility
• Develop schedule
• Establish budget
• Determine measurement methods
• Establish Performance Measurement Baseline (PMB)
• Analyze project performance
• Maintain PMB

These activities can be found in the 32 criteria shown below. The colored items are the 11 mandatory criteria needed for the success of any project independent of Earned Value.

1. Define the WBS - Chapter 3.4.3

2. Identify the organizaiton - Chapter 4

5. Integrate the WBS and OBS - Chapter 4.3.2

6. Schedule the work - Chapter 5

7. Identify the products and milestones - Chapter 2.4 (basics), Chapter 3.2.1 (Charter)

8. Set the time phased budget - Chapter 6

16. Record the direct costs - Chapter 9.2.2

23. Determine variances - Chapter 9

25. Sum data and variances - Chapter 9

26. Manage action plans - Chapter 10

28. Incorporate changes Chapter 10

The EVM Hoax

A colleague - Pat Barker (adjunct Professor at the Defense Acquisition University) - has a short piece in this issue of Defense AT&L, where he and his co-author Roy Wood speak to the fundamental failing of Earned Value Management.

This is not the application of EVM, the processes of EVM, or any of the common myths around EVM.

No, it is the failure to understand that the 5 Immutable Principles of any successful project

1. Do we know where we are going?
2. Do we know how to get there?
3. Do we have everything we need to get there?
4. Do we know what impediments we'll encounter along the way?
5. Do we know how to measure our progress in units meaningful to the decision makers?

Earned Value Management contributes to 1, 2, 3, 4 and is the full basis of success for 5.

So if your project is not applying EVM, then it is foregoing a Critical Success Factor, and likely forgoing this factor on purpose. Long ago, I worked as a program manager where billions were at stake and people died if serious mistakes were made. The site had the normal poster campaign for safety. One of the best posters was

Don't do stupid things on purpose

If you don't have credible answers to each of the 5 Immutable Principles, you're doing just that.

Here's an example of applying the 5 Immutable Principles in the development of software.

Is EV Really That Hard?

While doing all 32 of the 748B criteria may not be for everyone, I'd suggest there are a minimum set of EV criteria needed to simply manage any program.

These 11 are numbered by their 748B criteria:

(1) Define the WBS - what are we building?
(2) Identify the organization - who's doing the work?
(5) Integrate the WBS and OBS - who is doing what?
(6) Schedule the work - when are they doing it?
(7) Identify products and milestones - tell what I get for the work.
(8) Set a time phased budget - how much is it going to cost?
(16) Record direct costs - how much did it cost?
(23) Determine variances - the difference between plan and actual cost?
(25) Sum data and variances -add those up so I can see the big picture.
(26) Manage action plans - how can i fix the gaps?
(28) Incorporate changes - fix the gaps.

I'd suggest these "program control" activities are minimally needed for success` of any project using any project management method.

If you're doing these in any credible manner - that is, maintaining the integrity of the data - then you're very close to having a full up EV system.

If you're not doing these, then you probably can't answer the 5 immutable questions of successful project management:

1. What does done look like?
2. How do we get to done?
3. Do we have enough of what we need to get to done?
4. What are the impediments along the way?
5. How do we measure progress toward done?

EV is a contributor in each of these answers. So when I hear

"EV is just too hard, too much complexity, too mauch paper work."

What would be credible alternatives to answering the 5 questions?

Alert - EVM Site

The Earned Value Management (EVM) Division web site provides useful information for reference documents, templates, links to other Federal EVM sources.

Earned Value

When IT projects start to manage planning, progress measurement, and performance adjustments basedon baselined meassures of physical percent complete againts pre-defined technical performance measures at fine grained boundaries (every week), then we may read similar press releases.

Agile software development has all the makings of this approach. All that is needed is the broader framework of defining the needed capabilities in terms of scenarios connected to business or mission outcomes, traceable to teechnical and operational requirements, then to the "packages of work" that implement these on fine grained periodic cycles, while moving toward the broad set of capabilities that are verified through the feedback of working products, all the time measuring cost and schedule performance.

5 Immutable Principles

I've spoken about this before. There are 5 Immutable Principles of successful project management. No matter what method used to manage the project, develop the product, or what ever technique you want to use for getting to the end, these principles must be in place.

 

1. What Does Done Look Like? What capabilities are needed to fullfill the stakeholders business needs.
2. How do we get there? We need a Plan and a Schedule. The Plan is the strategy for the success of the project. The Schedule is the sequence of work needed to implement the Plan. Both are needed.
3. Do we have enough of everything to get there? This means a  resource loaded Schedule, with labor and Other Direct Costs (ODCs)
4. What impediments will be encountered along the way? Risk Management is how adults manage projects.
5. How do we know we're making progress to plan? Earned Value.

 

I Don't Need No Stink'in Earned Value

Came across a nice You Tube video of applying EV. There are three simple reasons for EV to monitor a project

1. Knowing where you are against the plan
2. Knowing how much you spent against the budget
3. Knowing what is left to done

From these three you can forecast how long it's going to take to complete the project and how much it will cost to reach this completion date.

Now if you don't have a plan then who cares abotu knowing where you are in the plan. If you don't have a budget for the project, then who cares about where are in the budget. And if you are working on a "level of effort" project, then you don't care when you done.

So if you software development project is using agile - poor agile BTW - and you don't have a planned completion date, then EV adds no value. If you gile project has no budget - a Not To Exceed value - then you could care less about measuring budget performance. And most importantly, if your agile project is being driven by the customers requirements and those are changing all the time, then who cares about knowing about how much work is left, because there is no way to know this.

So EV is worthless in this context. - Yea Right

If you have a project where the requirements are emerging in the presence of no budget limits, call me, I want to work that project. How fun. I want to spend the customers money, react to the whims of the customer, and work to short term deadlines - sprints - and forget the long term commitments to stay on budget and complete on or before the deadline.

Yea Right

Measuring Business Value

When we talk about "business value," and in the same sentence say Earned Value is not Business Value, therefore Earned Value is of no interest to the business, it's likely that we don't actually understand how projects are managed at the business or governance level. Both business facing and project facing measures are needed for success.

The "values" of interest to the business should be connected to the "business case." They need to answer the question why are we doing this project. While it is necessary to have a business case and hopefully define what business value means, it is FAR from sufficient for success of a business system project.

This is a common lament of those on the business side when encountering project managers. And even more so when encountering agile software developers. Both the project managers and the software developers have their "units of measure." These units are meaningful to the members of their domain - or at least we should assume so.

• Earned Value project managers speak in Cost and Schedule measures. Of course both cost and schedule in Earned Value is measured in "money." What does it mean to be $125,000 behind schedule? How much is an hour worth?
• Agile software developers speak in "story points." How many story points are there in the Estimate to Complete? They can say. They can say how many story points per iteration and provide an approximate forecast of when "done" will arrive. But how much will it cost to complete - the Estimate At Completion (EAC) of the financial view of the project?

There is a better starting point in trying to connect the project facing measures with the business facing measures of performance - the achievement of business value. This starting point is the Systems Engineering paradigm. This paradigm has "measures" that are connected to the participants. Here they are...

These measures define meaningful units that can be used by the decision makers to make decisions.

• Measures of Effectiveness (MoE) are stated in units meaningful to the buyer. They Focus on capabilities independent of any technical implementation. They are connected to the mission success. These are operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in the operational environment, under a specific set of conditions.The MoE's belong to the customer.
• Measures of Performance (MoP) are attributes that assure the system has the capability to perform. They are an assessment of the system to ensure it meets design requirements to satisfy the MoE. These measures characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions. MoP’s belong to the Program – Developed by the Systems Engineer, Measured By CAMs, and Analyzed by Program Planning & Control function.
• Key Performance Parameters (KPP) have a threshold or objective value. They characterize the major drivers of performance. They are considered Critical to Customer(CTC). They represent the capabilities and characteristics so significant that failure to meet them can be cause for reevaluation, reassessing, or termination of the program. The acquirer defines the KPPs during the operational concept development – KPPs say what DONE looks lik.
• Technical Performance Measures (TPM) assess design progress, Define compliance to performance requirements. TPMs identify technical risk. They are limited to critical thresholds and include projected performance. They are the attributes that determine how well a system or system element is satisfying or expected to satisfy a technical requirement or goal.

So when someone speaks about "business value," or worse states Earned Value has no business in the business of developing software for business, ask a few questions just to clarify understanding:

• What are the units of measure we're using in this discussion. Without shared units of measure it's just blather.
• How are you assigning these units of measure to specific actionable outcomes that need to be made by the decision makers? In other words how can I know if the project is getting better or getting worse from my specific point of view?
• When you say "value" what are the units of measure, how did you derive these, are they in fact meaningful to someone outside your domain of action (developer, cost analyst, CIO)?

Now you may not be interested in Estimates At Completion (EAC), Estimates to Complete (ETC), MoP's, MoE's, TPM's and KPP's. But someone better be interested if you're spending other people's money.

Earned Value Management in a Nutshell

There is on going discussion on forums and in publications about Earned Value and the confusesion between EV and Business Value.

Here's content from Ray Stratton's The Earned Value Management Maturity Model, Management Concepts, 2006 that makes it clear what EV is about. For any one interested in the actual use of EV in the proper way, this book is a most.

• Planned Value (Budgeted Cost of Work Scheduled - BCWS) - The Planned Value of the Work

Planned Value (BCWS) is the planned value of all the work activities in the schedule. Each piece of work has two attributes: its planned value (its allocated budget) and its planned completion date (the time in the schedule it is to be completed, or the iteration in which it is to be completed).

• Earned Value (Budgeted Cost for Work Performance - BCWP) - The Value of the Work Completed

Earned value results from completing work activities. Assessment of this earned value compares what was planned to be earned (the budget) with what was actually accomplished at the planned time in the schedule, using some meaure of physical percent complete. Those meassures range from 0/100 (you did it or you didn't) to Apportioned Milestones (we agreed up front that when you had this done you'd get 30% credit for being done).

• Actual Cost (Actual Cost of Work Performed - ACWP) - The Cost of the Completed Work

The cost of completing each piece of work, usually reported against the Work Breakdown Structure. Comparing actual cost with planned cost (budget) indicates if the projects expenditures are following the budget plan.

There are other terms used in Earned Value

• Budget - generally is the Budget At Completion (BAC). How much money is expected to be spent for the project.
• Management Reserve - is money held at the project manager level for technical and cost issues that come up during the project.
• Overhead - (burdened cost) is a "tax" on the project cost to pay for the organizational infrastructure.
• Undistributed Budget - money in the BAC that has not been allocated to defined work.

No where in these terms and the formulas that result from their use is "Business Value" defined or used. That is in a separate and distinct set of performance measures. Earned Value's performance measures are the basis of answering two important project management questions needed to provide the Business Value

• When will we be done with the project?
• What will it cost on the day we are done?

Along the way the business value can be measured according to processes like Balanced Scorecard or other business investment processes. But it's not Earned Value's job to do that measuring.

What is a good performance metric?

When the discussion turns to measuring project performance, the question of "what is a good metric" comes up. There are many answers depending on your view of the world. Burn Down charts, cost performance measures, schedule adherence, technical performance measures.

Here's what has worked well for me in a variety of domains - software, hardware, construction, process improvement, commercial, defense, energy, paper mills, power plants, ERP systems, and building our house.

• Define what done looks like in units of measure meaningful to the decision maker.

This means something that has business value. Story points for software probability aren't it. An ability to do something with the software that is connected to the balance sheet probability is. This is called a "capability." This capability should be found in some strategy document somewhere. This document answers the question "why are we doing this?" "Why is these feature needed?"

"We  need the capability to process claim transactions at $0.07 versus our current $0.11"

• Define the budget and schedule needed to produce "done."

If you're spending someone else's money, you're going to need some form of budget control. These means you'll need to know what the project will likely cost with some level of confidence. You'll also need to know some level of detail about where those cost are being allocated. "How much do we need for licenses?" "How much for those external testers we've used in the past?" "Do we have a burdened cost for our staff and if so what is that compared to the budget we've got for this project?"

• Define intermediate assessment points along the way to answer the simple question how long are you willing to wait before you find out you're late?

Planning looks to the future to recognize what done looks like before the time and the money run out. Planning is essential for all project success. From mowing the lawn to flying to the moon. We need a plan.

But more importantly, how can we recognize that we're making progress to the plan? What are the measures of progress? Physical Percent Complete is a good one. This is why Agile is a nice way to measure progress at the software development level. "We planned these features, some appeared some didn't at the end of iteration."

• At each assessment point, determine the actual cost to reach that point, compared to the planned cost to reach that point.

When there is talk of "business value," we need to incldue the "cost" of that business value. Collecting costs  is part of project management. Agile projects have it easy. They are essentially Level of Effort work activities. The staff level is steady, the period of performance is fixed (iteration). For other projects, not so much.

• At each assessment point determine the physical percent complete of the planned deliverable in units you defined before you started the work compared to the actual percent compete at the same assessment point.

Measures of physical percent complete need to be defined before the work starts, That way you'll recognize them when they appear. These measures must be meaningful. They must be tangible.

At each assessment point assure all measures are represented by tangible evidence that the physical percent complete is actually true.

• At each assessment point, assure that the measures of performance, effectiveness, and technical attributes are within the boundaries of the planned performance. This the P-Chart from Six-Sigma. Errors bands for EVERYTHING are a must, no point estimates without variances.

With these measures taken on the day you planned to measure them, for the values you planned to achieve, you will learn if:

• You're ahead or behind schedule
• You're under or over budget
• The thing you're building works as planned or it doesn't

If you kept track of the planned cost versus the actual cost and you kept track of the physical percent complete at the assessment point versus the planned percent complete at the same point, then you've got the numbers needed to forecast future performance.

This approach is called Earned Value - you earned the planned budget at the time you planned to earn it, with the planned performance attributes (effectiveness, performance).

There are no magic beans here. Just units meaningful to the decision makers. Units in money and time.

Do this simple process and you'll have all the metrics you need to have visibility into your projects performance.

A Reminder

No matter what development process you're using, how you're measuring progress to plan, or how you interact with the customer, all successful project must start with 5 immutable principles.

So when it is said for example, EV is "hog wash," for IT projects, we'll need to find some method that can account for the performance of the work effort that is based on units of measure meaningful to the decision makers. This is most often measured in Dollars.

So we'll need to come up with a measurement process that compares our budgeted cost with the "value" earned from the investment of that budget. With this information, we'll need to forecast an important measures for those accountable for this budget. Those interested in the "real" aspects of the project...

• How much will this cost when we're done?
• When will we be done?

Can't answer questions like this, you're probably not actually "managing" the project. You're developing software that's for sure. But they're not the same.

To credibly address the 5 Immutable Principles, there are 11 practices.

Each of these 11 practices needs to produce some tangible evidence that they are being applied. This evidence is the data produced from the practice or artifacts produced after the practice is applied.

Quote of the Day - Billion Here, Billion There

A billion here, a billion there, and pretty soon you're talking about real money. - Everett Dirksen

When we speak about "program controls," there are lots of domains and context where this is a mandatory role. Some are larger than others. Some are more formal than others. Some have special needs and others are just straight forward Program Planning and Controls using Earned Value straight out of ANSI-748B.

Here's a program we're working on getting on. Look carefully at the total award value for the engineering, technical, and programmatic support services. Programmatic Support means "program controls." That means "project" management, and the process around "managing" projects.

Yep, that number on the right is $19 Billion, as in a $Billion with a $B. In this domain there are all kinds of development and engineering services. Including IT development, including Agile development in IT. So when it is suggested by some thought leaders that EV is "hog wash," ini the IT world, ask yourself the question - who's looking after the $B's? A self organizing team of very qualified software developers?

Uh, probably not.

Part of that number on the right goes to

Yep, good old software development processes. This is where agile is most needed. When we get into serious money as Senator Dirkson mentions above, we need to best of both worlds. Rapid development to verify the requirements are right, put the software to work to verify it can earn it's keep. And control mechanisms that can forecast future performance in units meaningful to the decision makers. Those units are of course Dollars.

The Fallacious Comparison Argument

I've come across Scott Ambler's statement from the Dr. Dobbs article again. Rereading it for the n^th time, I'm still struck by the fundamental misunderstanding of the term "value" between Earned Value and Business Management. Scott proffers.

The fundamental problem with EVM is that it has very little to do with earning value and everything to do with managing against what often proves to be naive/fictitious schedules and estimates committed to far too early in the project. Although EVM is interesting project management theory, and I have no doubt that it may work in some non-IT domains, it proves to be a really bad project management strategy in practice for IT development projects.

From my Formal Logic book sitting on the dusty shelf, this is the Fallacious Comparison or the Improper Comparison argument. Flaws and Fallacies in Statistical Thinking, Stephen K. Campbell, is a nice source for these things.

Ignoring for the moment that fallacious statement of "naive/fictitios schedules." If there were such schedules as the baseline for EV, then the project is doomed from day one, and those creating and those accepting those schedules should be excorted from the building. Using bad management as the basis of an argument is, who should I say this - nonsense. Get real. Bad Management is just that, Bad Management.

The "value" in business value is just that value to the business. This is almost always measured in units meaningful to the business - money connected to some investment process. This value can be captured through many sources. Return on Investment, Internal Rate of Return, Balanced Scorecard Critical Success Factors, Key Performance Parameters. Things like that. Numbers that appear on the balance sheet. Numbers reported at board meetings.

The "value" in Earned Value is the "earned budget" from the baselined plan of the budget for the planned work. The Value in EV is simple. These numbers are most often money as well, but the color of that money can be different than the money reported on the balance sheet. Many times this money comes from allocated budget to the project - "blue" money as we say in our domain. It can come from "green" money (customer money) as well. Construction uses the term "hard money

It's just that.

• We budgeted $234,000 for a set of features (capabilities).
• We defined the period of performance over which we planned to spend this $234,000.
• Over this period of performance, we decided to measure physical percent complete in some form of tangible evidence.
• Let's say at 50% of the time we planned to spend $115,000 of our budget.
• We also pre-defined what it means to be 50% "done" at 50% of the time.
• When we get to that point in time - the 50% mark - we take an actual measurement of the physical percent complete, using the pre-defined tangible evidence.
• It turns out that evidence shows 45% of the planned 50% is actually done. It's not for the lack of trying, so we've spend the planned 50% of the budget. The $115,000 of the budget.
• Rats, we didn't "earn" what we planned to "earn."

Our Earned Value says:

BCWP = BCWS x 0.45 = $234,000 x 0.50 = $105,3000

our plan was

BCWP = BCWS x 0.50 = $234,000 x 0.50 = $117,000

We didn't make our plan. We underperformed against plan is a common plan. We're unfavorable to plan is another. With this information and the collection of the actual costs for performing this work - which may or may not be equal to the budgeted cost for the work, we can forecast both the schedule performance and the cost performance of the further project activities in units of "money."

There are issues with EV for sure. First is the schedule variance is measured in money. This is overcome by the Earned Value Engine (the system that produces the reports, maintains the Baseline, and other little details) using labor spreads and labor absorbtion rates.

But this performance is not connected to the "business value" of the tangible evidence of the outcomes from the work. Attempts to connect the Business Value with Earned Value is simply not the right paradigm. Don't do it. Stop doing it if you're thinking of doing it. Ignore the advice of those suggesting EV should be Business Value, or EV is not Business Value and that is a problem. It's not a problem, it's irrelevant.

This approach by the way is not uncommon, Michael Hatfield made a similar error in Earned Value Means Measuring Progress Against Plan Cost Not Actual Cost, Managing Projects with Earned Value, and The Value of Earned Value.

Why Is This Important?

As Agile enters to Enterprise IT domain and more so Agile entering the government funded Enterprise IT, Agile will start to encounter Earned Value guided by ANSI-748B. As this proceeds we really do need to get the facts straight when we start to discuss the applicability of Agile and EV to the same Enterprise IT project.

Program Management Report

Deltek has their annual Program Management Highlights report. Worth the down load.

The key findings around Earned Value, processes related to program success. The big findings are around the use of a Program Management Office as a direct bill to the program. 41% of all the respondents utilize program controls for their work.

2 out of 3 firms reported cost management and cost controls as the most important discipline to planning and scheduling.

Performance Management shows that applying  EV beyond just the required compliance guidance. One interesting measure was the 19% average margin using EVM versus 11% margin for firms non using EVM. For A&D firms using EVM, they reported a 5% higher margin. The biggest benefit came from consulting services using EVM, with a 16% higher margin.

Classic PM processes like PMBOK lead the way in 70% of the firms. More sophisticated metrics like DCMA 14 point assessments reported higher profitability.

More EV and Agile Confusion

From AccuRev

May 9, 2011 In a recent Dr. Dobbs' report, IT expert Scott Ambler claimed that an earned value management, or EVM, strategy is not necessary for Agile software development projects.

EVM helps organizations track their schedule and budget results throughout the life of a project. By comparing actual outcomes to those planned, the idea is that EVM enables team members to gather information that can help to steer the project. It is also meant to enable project managers to determine the percentage of expected value that has been earned at a given point in time.

Ambler claimed that, for teams using a traditional waterfall software development model, EVM is "pure hogwash," since the value of a waterfall-designed project doesn't come into being at all until the project is completely finished.

While Agile software developers take a "much less risky" approach by producing potentially consumable solutions in each iteration of development, some have suggested that it is more compatible with EVM. According to Angler, this is not the case.

"Because agile provides much greater openness and visibility to stakeholders, artificial measures such as EVM typically prove to be overhead at best, whose only value is to cater to the dysfunctional bureaucrats infesting many organizations," he said.

In addition to software development, Agile is now used for a range of other tasks. According to a recent ITWire report, it may be possible to reduce business intelligence costs by up to 50 percent with the help of Agile.

First Things, First

In the EV world, validation of the processes, either formally or self-validation is the starting point for credibly apply EV to a project, a program, or across all programs in a company. One of the assessment questions is obvious. Are the people in the organizations, from management down to those responsbile for managing the work, trained to use Earned Value?

No, then get them trained.  It takes all the challenge out of applying EV - or any process for that matter, Scrum, RUP, CMMI (I know this is not a process) - if people are trained. But more importantly, management is trained and signs off on the process. There is a signature block on the EVM System Description (either in the Advanced Agreement or the post award agreement) for senior management.

To do otherwise simply lays the ground work for failure of both EV  and the project using it. And then lays the groundwork for the un-informed to come along and say "see EV doesn't work." "Senior management is mis-using EV." "Engineers aren't getting any value out of EV."

Don't do stupid things on purpose.

Let's take a closer look.

• Earned Value measures progress as "physical percent complete" against the planned percent complete." This "value" is earned minimally in large government contracts monthly. Many projects make this measurement weekly, even on large complex, software intensive projects. Here's an example Weekly Earned Value Method.
• The notion that in "traditional waterfall software development ... the value does not come to the end," is seriously misinformed. First FAR 34.2 and DFAR 252.234-70002 call out "periodic measures of performance" for projects. The Contract Performance Report (DID 81664A) calls outs monthly reporting of EV performance.
• Earned Value should be seen as a measure of the prodictivity of the budget assigned to the work. With this measure, the forecast of the total budget's performance is developed.

So the notion that projects are managed this way is actually "against the law," the Federal Acquisition Regulation. So maybe a bit of homework would have turned this little fact up.

Now let's look at another seriously misinformed notion.

• I wonder if Scott has actually worked on a software intensive EV program. One that produced the CPR monthly or even bi-weekly on 1/2 billion to billion dollar programs. I get the sense Scott is making this stuff, has some bone to pick, or is just a curmudgeon.
• It turns out of course Earned Value, using Work Packages, with standard durations (crossing only one accounting period), with tangible evidence of physical progress to plan (the WP deliverable) are nearly identical to Scrum Iterations, at the planning and execution level.
• I love to quote "it may be possible." Lot's of things are possible, and when you add "may" that pretty much opens the universe to possibilities.

So what's the problem here?

When we get vocal and highly visible voices speaking about topics ut their area of expertise it probably doesn't really matter. Unless the voices have a platform to confuse those actually needing help.

• DoD's IT budget is something around $36B.
• EV is part of this procurement process.
• Successful deployment of IT in DoD is not a poster child.
• DoD OSD has initiative in the NDAA Section 804 to provide (2)(A) early and continual involvement of the user, (2)(B) multiple, rapidly executed increments or releases of capability, and (2)(C) early, successive prototyping to support evolutionary approach.
• More details can be found at recent NDIA C4ISR meeting.
• Finally While Agile software developers take a "much less risky" approach by producing potentially consumable solutions in each iteration of development, some have suggested that it is more compatible with EVM. According to Angler, this is not the case. I'd ask for references. If we're looking for an example of Pure Hog Wash, this is a prime example.

When there is simple misinformation being proffered by thought leaders it's troubling at best. At worse it's just plain old counter productive. I'd invite Scott to use some of his travel budget and come visit some software intensive sites to see how "agile development processes," and Earned Value are used weekly.

Maybe some discussion with those actually doing the work of integrating agile with EV might provide Scott with insight on how this works, why it is critically important to government procurement and enterprise IT, and maybe, just maybe provide a mechanism for improving the credibility of those voices claiming things that just are true.

Want To See Business Value?

The confusion between "Earned Value" and "Business Value," is common. It's wrong of course, but common.

Here's a way to discover the "business value" view of a project.

Business Model Generation shows how to model the elements of the business that generate value. With this model, the "value" to the business of the outcomes of a project can be connected with the work effort and productivity of that work effort using Earned Value.

With these two "values" all the confusion, mis-information and general whining about EV and it's not measuring "business value" can be ended and everyone can get back to work generating value for both side of the equation - for the customer and for the project.

Agile and EVM - Part Two

There are many voices in the market place speaking about agile and earned value management can be integrated. I am one. John Goodpastuer has good things to say. Paul Solomon. Mark Infinti. And some good presentations from the European 2010 EVA Conference. As well the Defense Acquisition University is a good resouce for EV.

But there is a critically important and subtle concept not well understood outside the EV community. There is a major difference between applying the formulas of Earned Value to a project and actually Doing Earned Value on a project.This difference is many times skipped over in the pursuit for "agile" EV, EV light, or EV without all the trappings of EV.

EV is not really about calculating the formulas, although they are important. It is about all the other activties around the formulas. The formulas are actually in only a few of the 32 criteria of EV.

Let's start with the definition of Earned Value used by those of use working the in Earned Value domain, guided by the Earned Value specification - ANSI-748B.

The criteria in color at the 11 minimal criteria needed to successfully manage a project using Earned Value. It might be said these are the criteria needed to manage a project period. Without this information you woudl not be able to determine if the project was performing to plan.

The remaining 22 criteria are part of a "validated" Earned Value Management System (EVMS) defined in ANSI-748B, guided by FAR 34.2 and DFAR 252.234-7002 and the NDIA Earned Value Management Intent Guide.

First, the full blow Earned Value management is only applicable to projects $20M or greater for government procurement subject to the FAR, DFAR, and GAO A-11 Part 7. If your project is not greater than $20M, or you have been directed through a contarct, then the motivation for EV is less. Not that it should be much less, but still less. EV as a principle is very useful. As a practice, not everyone is ready to step up to the rigor and discipline needed for success.

Next, the calculation of the formulas used in EV can be applied to any project, no matter the size. In the complete absence of 748B. These formulas are certainty useful as a starting point. If and this is a big IF, they are used in the way 748B prescribes. This includes:

• Maintaining a baseline throughout the project's period of performance is part of Earned Value
• Having some structure to assign costs. This is usually a Work Breakdown Structure. Without this the "blended" project performance can be easily hidden by "summing" the EV numbers.
• Budget should be in some unit meaningful to the decision makers. Story Points are probably not it. Dollars is common and logically the best.

Since the customer should - if they are at all sensible - be asking about total project cost and total project duration, along with the incremental delivery of "business value."

Finally, do not confuse "business value" with the "Earned Value" in Earned Value. See yesterday's post. The value in EV is Budgeted Cost for Work Performed (BCWP)(EV). It is the "earned budget." That is, the percentage of the budget - the Planned Cost - that has been "earned" at the point in time the measurement of physical percent complete (or some tangible measure of progress) was taken. So don't fall for the un-informed voices claiming Earned Value's "value" is not business. Of course it's not. Never was. Never will be. It's bogus to even suggest it.

Use both "Business Value" and "Earned Value" in the ways they are designed to be used. The way the "instruction manual" tells you to use them:

• Business Value - connected in some with the strategy, mission, vision, business balance sheet. The Balanced Scorecard is a good place to start. Value Stream Maps work well in iterative and increment environments, where "deliverables" are produced along the way.
• Earned Value - read the Gold Card

Business Value and Earned Value are NOT the same

No matter how often it is said, Business Value and Earned Value are not the same value. Earned Value's value is the Budgeted Cost for Work Performed (BCWP). The value is earned by completing the measured percentage - preferrably 100% - of the value of the work budgeted - the Budget Cost of Work Scheduled (BCWS).

BCWP = BCWS x Percent Complete (or some other form of tangible evidence of progress)

The value of business value of a strategic and operational assignment of value to the business. When there two terms are confused, mixed, or just complained about, both sides of the equation loose.

Here's how to connect them from the top donw, using Vision, Mission, Strategic Objectives, Performance Goals, Critical Success Factors, and Key Performance Indicators. It's the KPI's where the EV metrics live. The other metrics are business centric and have units of measures that are business focused. These are called Measures of Effectiveness in the Systems Engineering world. The KPI's have Measures of Performance along with the EV metrics.

Use this approach and ignore the voices that claim EV value is not Business value and the comments that EV of no interest to IT projects. It turns out EV is directly connected to methods like Scrum, where measures of physical percent complete are embedded in the process. These voices are unlikely speaking from hands on experience connecting business value with Earned Value on actual projects.

This approach of connecting busines value with Earned Value works, it is currentlyworking, and will work once you get past the rhetoric.

Agile and Earned Value Slide Share

I really don't like self promotion for the simple reason that it diminishes the credibility of the promoter. But our inside sales suggested I do this.

The presentation Successfully Integrating Agile and Earned Value got recognized this week as being talked about on LinkedIn more than anything else on SlideShare right now.

So What? Who Cares?

There is still a huge way to go to "connect the dots" between Agile and Earned Value. From the NDAA Section 804 efforts to correcting the mis-informed messages about how Earned Value works in software development.

This includes:

• Connecting iterations with Work Packages on monthly or bi-monthly boundaries
• Using physical percent complete in agile as the same physical percent complete in EV
• Using Planning Packages as future iteration place holders

The reason for this is simple and complex at the same time. In the government procurement domain, Earned Value is mandated by FAR 34.2, FAR 52.234-4,  and DFAR 252.234-7002. Those in the commercial world could care less. But in fact as citizens they should. The IT budget for the US DoD is something like $87B. The NDAA Section 804 initiative is attempting to introduce concepts like Making Acquisition Measurable.

When there is discussion of "scaling" agile beyond the small to medium projects, here's an opportunity to actually do it, in a highly visible and controlled manner.

Another example is "in the news" CIOs Site Trouble With Agile Development. And Improving the Initiation of Acquisition Activites for Automated Information Systems.