Herding Cats

Quote of the Day

How many legs does a dog have if you call the tail a leg? Four. Calling a tail a leg doesn't make it a leg
- Abraham Lincoln

The notion that we can rename things and then assume they are the same doesn't work, just like Lincoln said. The notion of measuring progress with the passage of time and calling it Earned Value, doesn't mean we're doing Earned Value.

Doing Agile without doing Scrum, XP, Crystal, or DSDM is not doing agile.

How Not To Do Earned Value

The LinkedIn forum The Project Manager Network - #1 Group for Project Managers which I sometimes wonder if that is actually the case, has a conversation going on around project failure. A Master's student asked about project failure modes. That led to the use of Earned Value. One participants made some pretty boneheaded statement around EV:

1. (EV) It's a tool and anyone who thinks it is an actual depiction of real progress is fooling themselves.
2. Percent complete, unless 100%, is at best an educated guess.
3. I've heard of the 0/100 and the 0/50/100 methodologies. I disagree with the 0/100. If you are trying to accurately portray progress, it is best to develop a set of standard credits, for example when doing drawings or, actual measurement such as in construction. Each activity has a value from which percent complete can be derived. 
4. An equipment general arrangement drawing is a good example (percentages shown are individual contributions) - using 40 hrs/drawing as the allowance (we get)...

5% (2 hrs)for applying the border and title
20% (8 hrs) for defining the area - boundaries and overall dimensions
30% (12 hrs) for showing all the equipment
5% (2 hrs) for the drawing being checked
10% (4 hrs) for it being Issued for Approval
15% (6 hrs) for it being Issued for Bid
15% (6 hrs) for it being Issued for Construction.
100% = 40 hrs. 

So, silly me, I responded that determining physical percent complete was a straight forward process once you have Quantifiable Backup Data or measures of Physical Percent Complete, or even better, Technical Performance Measures. Let's look at each concept

1. EV, when percent complete is measured in tangible units of physical percent complete is a depiction of real progress. Why because the progress is physical percent complete. It's a tautology.
2. Percent complete is NOT an educated guess, it is tangible proof. This is call Quantifiable Backup Data. Bring the number of drawings to the table you said you were going to do on the day you said you were going to do them, and you'll get the prorated share of the earned value for the total drawing package. Bring 8 of the planned 10 on the day you planned to produce 8 and you'll get 80% of the total work package for producing 10 drawings.
3. 0/100 is best, all others skew the performance. The last piece of that concept is actually correct. For a 10 drawing package, with each drawing weighted the same, that is 10%, 5 drawings, completed on the planned day, gets you 50% physical percent complete.
4. No we go straight into the ditch. Progress is NEVER measured with the passage of time except in Level of Effort work. The actual costs (ACWP) is interesting to cost accounting, but it tells us nothing about the progress of the project except how much money we have spent compared to our budget. If the assigned (apportioned) value were all there was, then OK. But the conversation included the number of hours, and there where the problem starts.

Then the final come back from the OP.

If you're doing a drawing and it takes 40 hours to do the drawing and no two drawings are alike, how do you determine what percentage complete you are? When estimates of the work to be completed are put together, they will estimate X drawings at 40 hrs/drawing. They will have different standards by discipline. Will a person ever report 41% complete on a drawing? Most likely not. It will be shown as 40%. Collectively all the drawings may be 41%, but not individual. No matter how you look at it, it is still an estimate.

First measuring progress to plan by the number of hours consumed is called Level of Effort. Second LOE is a very poor measure of anything other than the passage of time and consumption of resources.

In the end the poster was insistent that ANSI-748-B is just a guide, and doing EV was a local issue. No doubt that is true in his domain. But as a practitioner of EVM using ANSI-748-B for programs subject to DCMA Validation, as well as engagements with the DOD office that own the Earned Value Management processes for the DOD, I'd be laughed out of the room with an approach like that.

For a summary Earned Value in a Nutshell using a similar drawing example.

So Here's The Way TO Do Earned Value

1. Using the WBS define the Work Packages that produce the deliverables for the program
2. Assign an Earned Value Technique to each of these Work Packages - 0/100 for the individual tasks inside the Work Package is the absolute best. You're either done with the task or you are not. Weight the tasks if you want, but sum up the "done ones" and compare that to the total work and compute a percent complete.
3. Sequence these Work Packages in an Integrated Master Schedule
4. Assign budget (BCWS) to each of the Work Packages
5. Collect the actual costs to perform the work (ACWP)
6. Compute the Earned Value (BCWP) using a simple formula BCWP = BCWS x Physical Percent Complete.
7. Compute Cost and Schedule variance. Make management decisions based on these and take corrective actions to get back to GREEN.
8. Repeat step 5, 6, and 7 every month at a minimum, more often if possible.

That's all there is - essentially - for doing Earned Value Management. Of course if you read ANSI-748-B, the NDIA Earned Value Management Intent Guide, and the DCMA Intent Guide, there is a lot more.

You Can't Make Stuff Up

OK, you can. But if you do, it makes having a conversation about EV much harder. 

Related articles

What is Earned Value?

Definitions, Yes They Are Important

In Earned Value, Money Spent is Not a Measure of Progress!

Rings of Success

Earned Value says its Name

Issues with Deploying Earned Value Management

Learning Is Now More Important Than Knowledge

When I encounter a "subject matter expert," I've now learned to assess if this person is a "knowledge holder," or a "learning individual." This is what informed that "learning." This came to my from a friend and neighbor who is a graduate of the University of Chicago in economics and spoke at this conference. 

In our business - project and program management - there are lots of "knowledge" providers, assessors of knowledge, frameworks for measuring our knowledge. What is needed now is how to learn to make better decisions about our projects. This is not going to happen without a decision making framework for the core principles, practices, and processes for project management. The current Bodies of Knowledge, self-proclaimed providers of better BOKs and assessment tools, authors (I'm one of them), and experts in the field, all need to reassess what we are doing to increase the Learning abilities, beyond the just the possesion of knowledge and the dispensing of this knowledge to others. 

How can we actually learn to improve our probability of succes. The Decision Scientist for project success - as suggested here - needs to have art, science, and the scale to provide actionable information for the decision makers for the project.

We have most of the data we need, what we don't do is make decisions on this data, or even know how to make decisions with this data. We report it, but don't use it to make decisions. Numbers matter, but leadership needs to use the numbers. 

Related articles

Competency Model For Project Managers

Forecasting Future Performance

Forecasting involves making projections about future performance on the basis of historical and current data.

The chart below is a synthetic (same as fake) Cost Performance Index at the program level 2½ years. The area on the right is the forecast of possible values of the CPI given the historical behaviour, with tuning parameters and smoothing functions.

The next step is to use real program performance data over some realistic period of time - say 4 year - and use H-W (or a similar forecasting tool), to confirm that a less that complete assessment, say take 2 years of data, forecast a 6 month value, and see of the actual 2 year, 6 month value come out close the to the forecast.

This is all done in R, with very simple commands, once the time series for the CPI is formatted and partitioned properly.

Related articles

Earned Value says its Name

What is Earned Value?

What is Earned Value in Nut Shell?

Managing Your Project Performance Using 2nd Grade Class Concepts

Calculating "Earned Value"

Shim Marom has a nice series of posts about Earned Value. It this post he provides the calculation of Earned Value, or Budgeted Cost for Work Performed. 

BCWP = BCWS x Percent Complete

Shim, then mentions that many times it is difficult to determine Percent Complete.

Here's where to start

This approach is independent of applying Earned Value. It should be used for all project work. 

• The first step is to acknowledge that measuring progress to plan cannot take place through measuring the passage of time or consumption of money. Those measures just measure the passage of time and consumption of money. Those are useful measures, but they have little or nothing to do with the progress of the project.
• The agile world is quite proud of establishing "working software" as a measure of progress. Of course like all "new and innovative" things, it's been done before. 1978 TRW, One Space Park, Building O6, was my first series software development project out of grad school. The measure of progress to plan was - and still is - the compliance with the Planned delivery of a technical capability on the Planned day, for the Planned budget.
• Yep, that's how you measure Percent Complete. You plan what tangible evidence you will bring to the table to show that what you are working on actually works as planned. 
• In today's world these are called Technical Performance Measures and they are part of a larger group of measures needed to show the project is making progress as planned.

Below are the other measures of performance.

• Mission Need - why are we building this project? What are we trying to accomplish with the outcomes of the project? State that in terms of a strategy. Balanced Scorecard is a nice simple way to do that for the project. Here's some Notes of Balanced Scorecard, that can be used to develop one for your project. Skip to page 51 to see how measures of the project itself are used to connect the dots between strategy and tactics.
• Measures of Effectiveness - are the 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. They are stated in units meaningful to the buyer. They focus on capabilities independent of any technical implementation. They are connected to Mission Success.
• Measures of Performance - characterize the physical or functional attributes relating to the system operation, measured or estimated under specific conditions. These are attributes that assure the system has the capability and capacity to perform. They are an assessment of the system to assure it meets the design requirements that satisfy the Measures of Effectiveness.
• Key Performance Parameters - represent the capabilities and characteristics so significant  that failure to meet them can be cause for reevaluation, reassessing, or termination of the program. KPP's have threshold values that characterize the major drivers of performance that are considered Critical to Customer. 
• Technical Performance Measures - are attributes that determine how well a system or system element is satisfying or expected to satisfy a technical requirement or goal. TPMs assess the design process, define compliance to performance requirements, identify technical risk. TPMs are limited to critical thresholds and include the projected performance of the deliverables to stay within those thresholds.

So when asked what is the percetn complete, take out the KPP's and TPM's and look at your delivered product to see if it is compliant with the planned values? Do ot weigh the proper amount for this point in the project, Does it go fast enough? Does it have the planned reliability? Can it process the transactions properly at the right rate. Does it provide the planned storage capacity.

Does it do what you planned it to do on the planned day you said it would, for the planned budget?

That's how you determine your physical percent complete. Here's a way to lay out those high level measures that will show where you need to assign these measures

Related articles

Integrating Cost, Schedule, and Technical Performance Measures

Principles of Project Dynamics

What is Earned Value?

Deterministic versus Stochastic Trends in Earned Value Management Data

What is Earned Value in Nut Shell?

Came across (through Google agent) a nice short description of what is Earned Value. It's from a British construction firm. The phrasing is a bit off for our domain, so I'd like to clean it up. Let's start with a simple and s imple minded project. 

• We have a construction project and our efforts are in the design shop, making drawings for construction, from requirements.
• We have 4 weeks to produce 20 drawings for the project.
• Each drawing is the same level difficulty and therefore should take to same effort and duration (Cost and Schedule).
• We have a plan to produce these drawings at an equal pace, over the 4 weeks, 20 drawings total, 5 drawings per week for 4 weeks.
• We have a budget of $1,000 for all 20 drawings, with a budget per drawing of $50 each drawing.
• 'We assume that one person is doing this work, and that person is available 100% over the 4 week period of performance.

Earned Value has three components for our project:

• Planned Value - the budgeted cost for the planned outcomes for the work efforts at the time of assessment. This budget profile is linear, $250 per week for the 4 weeks, to produce 5 drawings each week, costing $50 each.
• Earned Value - the assessed value of the work accomplished at the time of assessment.
• Actual Cost - the actual cost of the work performed to at the time of assessment.

Notice the at the time of assessment statement. This is critical. If we plan to spend $1,000 as the total budget for the work over a 4 week period, this is the Planned Value, the Budgeted Cost for Work Scheduled or BCWS. This is the budget to produce our outcome. When we assess the performance of our efforts, we do that at a point in time. This point has a cummualtive budget and we need to assess our cummulative performance, and our cummulative actual costs all at the same time.

At the half way point (week 2), our plan says we should have spent 50% of our budgeted cost (BCWS = $500 at this point in time). This is naive of course, but makes our calculations simple. This means that after 2 weeks of work, we planned to have spent $500.

We assume - again naively - that over the course of the 4 week, the ACTUAL value of the product - the drawings - we are producing is growing linearly. So at the 2 week point, our product should be worth 50% of the Planned Cost or $500. This is the Earned Value. We essentially earn our budget in this simple minded example.

So now the 2 weeks has come, it's Friday of the second week of our 4 week deliverable. We planned to spend $500 and to earn $500 of value. At our status meeting, here's where we are:

• BCWS = $500. This is the planned budget to date at this point in the project - 2 weeks in.
• BCWP = let's assess our progress toward earning value for that invested budget.
  • To earn our $500 we had to produce 10 drawings at the end of 2 weeks
  • We only produced 8 drawings, not the planned 10.
  • Our BCWP = BCWS x "percent complete" = $500 x (8/10) = $500 x 0.8 = $400
  • So we only earned $400 instead of the planned $500
  • Our BCWP = $400

During those two weeks, we spent $50 per drawing on the first 7 drawings, just like we planned. But on the 8^th drawing we spent $70 because it was harder. Which is also the reason we didn't get to finish the 9^th and 10^th drawings. So for the first 7 drawings that were produced we spent (7 x $50) and for the 8^th drawing we spent $70 for a total of $420 for 8 drawings.

Now we can compute some indicies

• The actual for the cost for the 8 drawings was $420 
• ACWP = $420
• The planned cost for the 10 drawings was $500
• So at the end of the week, we are under budget by $80
• But we didn't produce the planned 10 drawings,but only 8 drawings for that $420

So let's do some claculations using Earned Value formula.

• We can calculate our Cost Variance (CV) - the difference what we planned to spend and what we spent.
  • CV = BCWP - ACWP = $400 - $420 = ($20)
  • So for the work we did do, we had an unfavorable cost of $20
  • No only did we not do the planned work, we had an unfavorable cost to do it
• Let's calculate the Schedule Variance (SV) - the difference between when we planned to produce the first batch of drawings - the 10 at the end of the 2nd week and when we will actually produce the 10 drawings
  • SV = BCWP - BCWS = $400 - $500 = ($100)
  • So for the planned work we are unfavorable to schedule by $100
  • Not only are we unfavorable to cost, we are also behind schedule

That's all interesting, but the real value in Earned Value is the ability to forecast the future. The first forecast calcualtion is our Estimate At Completion. This our estaimate of how much this project is going to cost when we are do, if we don't change anything

• First let's calculate the Cost Performance Index
• CPI = BCWP / ACWP = $400/$420 = 0.95
• EAC = [ACWP + (Budget at Completion - BCWP)]/CPI = [$420 +($1000-$400)]/0.95 = $1073
• If we keep going at the planned rate, we're going to over run by $73

But that's not the real problem, let's see how late we are going to be. 

• The Schedule Performance Index (SPI) = BCWP / BCWS = $420 / $500 = 0.84
• We had planned 4 weeks, 20 working days, so the forecast completion can be calculated with the SPI
• Estimated completion duration = Planned Duration / SPI = 20 days / 0.84 = 23 days
• We're going to be days late and $73 over budget if we don't make any changes.

Here's the quick summary:

• At the end of 2 week - half way through - we're missing 2 planned drawings.
• We spent more than planned for the 8 we did deliver.
  • For the 8 drawings we should have spent $400. $50 each x 8
  • But we spent $420, because the last drawing cost $70, instead of the planned $50
• We produced fewer drawings than we planned
  • We were suppose to produce 10 drawings in the first 2 weeks
  • But we only produced 8 drawings in that same period of performance
• We prodced less than planned and spent more for those we did produce than we planned
• We are now late - 8 drawings instead of 10 - and we're over budget - $420 instead of $400
• If we don't do anything, we'll be over budget by $73 and late by 3 days

So what can we do?

• We can catch up by producing more drawing for less cost
• We can keep on schedule and spend more money
• We can keep on budget but be late
• There is no way to get back on budget and get back on schedule, unless we produce the remaining drawings for less than we had planned and at the same time produce more drawing than we planned in the remaining weeks.

This is what Earned Value can tell us. No other method can do this.

This is the Value of Earned Value

In Earned Value, Money Spent is Not a Measure of Progress!

It is common in the Agile world and other domains at times to state that Earned Value. One example of this misunderstanding comes for a site I had not heard of before. 

Here is the descriptions used for an "Agile" project management method.

The description of Earned Value goes like this

Nope, This is Not Earned Value

The three variables of Earned Value are

• Planned Value or Budgeted Cost for Work Scheduled (BCWS) - this is the planned cost for the work that will be performed in the future. This budget is assigned to planned work, usually in dollars, but it can also be in hours. This planned work has a planned period of performance. This is the budget spread, that is the amount of budget planned for each time period over the period of performance for the planned work. The variable is not calculated it is defined.
• Actual Cost or Actual Cost for Work Performed (ACWP) - this is how much was spent on the work. Collecting this cost can be at the end of the total period of performance, or along the way. The measure of the ACWP at each collection point is then compared to the BCWS at that same point in time. Comparing these two measures BCWS - ACWP gives the Cost Variance (CV) of the work to date or at the end of the period of performance. This variable is not calculated it is measured.
• Earned Value or Budgeted Cost for Work Performed (BCWP) - this is the value of the work produced to date. This is compared to the Planned Value of the work that SHOULD have been produced to date. The best way to calculate this variable can be calculated as BCWP = BCWS x "physical percent complete."

So where did the author of the post go wrong?

• Earned Value is not how much budget and time "should" have be spent. That is BCWS. That's the planned spend at any point in time.
• Here's the Gold Card that shows how Earned Value works.

For Agile Projects, What Can Earned Value Provide?

In fact if you're doing agile and doing it right, Earned Value provides little value (so to speak). However, if you doing Earned Value projects, and want to add Agile, that is straightforward. Here's how.

In the end "earned value" can make use of Agile. But "earning" the value is NOT the measure of the passage of time and consumption of money or resources, as suggested by the poster. It is the measures of the "value" produced by the consumption of resources and passage of time. 

That is if we invested $100 and did that over a week, did we get a $100 in value from that investment? A simple way to calculate that measure is to ask what percent complete were we at the end of the week?

If we were only 90% complete, when we had planned to be 100% complete, but had spent out $100, then we are only 90% of our planned schedule progress, but are 100% of our planned budget. So we are 10% late and 10% over budget.

Deterministic versus Stochastic Trends in Earned Value Management Data - Update

Trending is a critical tool in forecasting the future performance of a project. "We've be doing this well for awhile now, what's going to happen in the future?" is a very common question for project management to ask of the "project controls" staff.

Two indices in Earned Value are the Cost Performance Index (CPI) and Schedule Performance Index (SPI). They are calculated from the Earned Value Management numbers of BCWP (Budgeted Cost of Work Performed), BCWS (Budgeted Cost of Work Scheduled) and ACWP (Actual Cost of Work Performed). This post is not about Earned Value, but about statistical analysis of Earned Value numbers. You can find good tutorials on EVM in several places, including A Gentle Introduction to Earned Value.

What is critical is the forecast for where the project is going with the information from the past. In the standard approach static information is used to compute a forecast of the future. This information is a cumulative measure of CPI/SPI for all past  periods and the current period of performance. Together these are used in a linear formula to forecast future performance - again in a linear, non-probabilistic manner.

All of this has lead me to think about the probabilistic processes needed to improve the credibility of  project performance measures. I discovered through our BioChem son, the programming system R. R is a functional programming language and system for statistics and probability. 

Along with R the US DOD has rolled out an XML format for capturing the monthly Integrated Performance Management Report. The time series of CPI and SPI are available monthly in electronic readable form. With this data forecasting using R and the myriad of tools can be done.

Using a simple functional command line,

will produce a nice picture of the time series data with forecast value at defined confidence levels.

The next step is to do this on actual project performance data (using SPI/CPI) and see what can be reveiled about future performance.

The problem to be solved is simple:

• The current Earned Value Management reporting hides all the variances at the work package and control account level through the cumulative reporting. The data is there, it is just not reported.
• The current period data also cumulates the variances from the work packages and then adds that data to the past reporting.
• There is not assessment of the statistical nature of the underlying data, so the result is a scalar, linear report of a underlying stochastic process, hiding all the real drivers by ignoring the variances and summing to the top. In Darrell Huff's How to Lie with Statistics, this is a recommended practice.
• There is no adjustment of the future forecast for the past probabilistic behaviour. Let alone risk, technical performance, measures of effectiveness, and compliance with Key Performance Parameters (but JROC and program). There is just a  linear projection of the future from the rolled up past, hiding the variances, and ignoring all the excursions that created those variances.

Mathematically this means that what drove the variances in the past is assumed to no longer be driving the future. Those sources of variance are washed out. This may be the case from corrective actions for the Epistemic uncertainties (uncertainty due to lack of knowledge). But the Aleatory uncertainties (uncertainty due to randomness or luck) that drive the variances are not subject to corrective actions. They are baked into the system and no amount of new knowledge or corrective effort is going to make them go away.

This is simply bad data analysis in any discipline I've ever worked, except program controls.

Background Materials

This idea started with Eric Ducker's paper and presentation at ICEA titled, "Performing Statistcal Analysis on Earned Value Data."There are some other sources as well:

• Improving Traditioal Earned Value Management by Incorporating Statistical Process Charts
• The Contribution of EVM to Project Success on Contracted Efforts
• Earned value management insights using inferential statistics

Related articles

What is Earned Value?

The Very Notion of Probabilistic Modeling is Lost on most Projects

Complex Problems Require Better Solutions

There is a class of responders on the forums that continue to seek simple and simple minded solutions to complex problems. Claiming the problems can be solved with simple solutions. Of course those solutions cannot be demonstrated with any credibility outside of a limited domain. Let's start with Mencken

For every complex problem there is an answer that is clear, simple, and wrong.  - H. L. Mencken

In the project domain most of the problems start with poor estimates of cost and schedule. Hollmann starts it off  http://lnkd.in/vjf4X4. Bent Flyvbjerg takes a more radical view, calling estimators liars , but I chalk that up to a language barrier.

The core problem starts with the politics of estimating. Rarely do the buyers of the project know what it should cost. So when they hear a number that is larger than their expectations, they reject the number. They signal to the sellers what they expect to pay for something. This expectation can come from poor knowledge or simply a naive understanding of the problem, or worse a public promise that simply can't be kept. 

But a second problem exists. That across domains, there is the wrong headed belief that one domain has the solution to another domains problems. We need to break the loop we're stuck thinking that problems are only found in other domains and making the ill-informed suggestions that "if you just did it my way," there would be no problem. There is a fundamental issues with managing complexity and managing in the presence of uncertainty. We want it to be simple, it is not, but since it is hard, people don't want to actually work hard on the solution. Instead seeking simple and may times "simple minded" solutions - buy this tool, use my excel spread sheet, dumb down the processes.

So What Is The Solution

First is to recognize that ALL domains have similar problems. Cost and Schedule estimates have been discussed for many decades. Lots of literature leads us back to the singular source - the political will to search for the credible estimate, even if that means not starting the project. Or better yet, to start the project knowing the estimates are flawed.

One provocateur voice in our community suggests that PMs that take on project with poor estimates should be held criminally liable for the results. This of course is laughable, but it demonstrates the complete understanding of the problem and the solution.

This approach reminds me of Pauli's quote when presented with a nonsensical submission from a student.

They were worse than wrong because they could not be proven wrong. Famously, he once said o: Das ist nicht nur nicht richtig, es ist nicht einmal falsch! "Not only is it not right, it's not even wrong!"

Thus is where we are now. Not much in the form of research and questioning, lots of pontificating about how the other guy is all messed up, and if you'd only do it my way, you'd have your solution. Reminds me of the current US political problems. Do it my way. Of course that doesn't work, because we have complex - wicked - problems, and there is no single way. Mencken was right, and he was right long before any of the current problems.

We may be doomed to repeat history with first recognizing the problem is us.

Project Controls is the Basis of Project Management

Shim Marom has a great blog post about a conversation around using Earned Value Management. The exchange is typical of those not starting with the Project Controls paradigm for managing projects. I attribute this typical exchange to missing information about how projects get to be successful. PMI has not done a good job around project controls, AACEI lives and breaths the notion, Agile has something to say, but leaves many gaps, and most of the ad hoc approaches to managing the expenditure of other peoples money in pursuit of a product have little to say.

It's been said before, but Shim's post needs as many voices as possible. If we want to show up on or near the planned time, at or near the planned budget, with something that has a hope of working, we need a method of planning work and controlling cost.

Here's are 11 activities that contribute to that goal on the non-technical side of the project. The odd numbering system will be revealed at the end

1. Define the deliverables – what does the customer want? Do we know this at a level of detail so we and the customer will recognize it when it arrives?
2. Define who is going to produce these items – do we have the people needed to produce them? Do we know the skills needed to do this work? Do we know something about how this work effort is going to be organized?
5. Put these two thing together - so the people on the project know who is doing what. Who is accountable for producing the outcomes of the project? How will they communicate this to the customer? 
6. Plan the sequence of work – so everyone is not doing anything and everything out of order. Einstein's quote that the purpose of time is to keep everything from happening at once is applicable here. 
7. Define when you need things to be produced – what day do I need something? The order of the deliverables is usually important to the assembly of the parts of the product. Spoilage is actually an issue when developing software, since emergent requirements many times result in rework.
8. Figure out how much money you’ll need for producing things – do we have enough time and money to produce what was asked for at the time it is needed? If you're spending other peoples money, you'll likely have to explain how much money you need and when you need it. Open checkbooks are rare these days.
16. Capture how much you spent – who spent what on what outcome at what time? The people giving you the money, will probably like to know what you spent it on.
23. Determine if there is a difference between what you planned and what you spent – why did we not follow our plan? When spending other peoples money, they like to know you've got their interest at heart. This can be done with a budget versus actuals discussion. Just like any business process (or even in life), having and budget and trying to stay on budget is a demonstration that you're trusted to spend the money.
25. Add up all these variances – do we have enough time and money remaining to do what the customer wants? This is a quetsion you probably ask yourself every month as you're paying bills. Same goes for managing other people's money on your project. The surprise of we have no more money (or time) is unpleasant in all circumstances.
26. Take action to stay on budget and schedule – either way, yes or no, what should we do about it. If we're on budget and on schedule, what do you need to do to keep it that way? If you're off budget or schedule, what are you going to do to get back?
28. Implement you actions – with the knowledge from #26 do it, Project Management is a verb, do something about the variances.

These 11 activities are simply good project management. These are what project managers should be doing on the Programmatic side of the project. The Technical management of the project can be done in a variety of ways, and of course they will influence the programmatic side. Add to that the people management and you've got the picture of what a project manager should be doing.

By The Way these 11 activities are numbered from the 32 Guidelines of ANSI-748-B - Earned Value Management. So when you hear someone say - we can't do EVM on our project or EVM is a waste of time in our domain usually spoken by the IT folks and even by the senior thought leaders of IT, ask yourself - are these 11 activities missing? If so, what's the chance your project is in the ditch and you don't even know it?

So You Want To Work In Program Planning and Controls?

The domain we work in is unique in some ways compared to the general roles of a Project Manager. First is the "management" of the project or program is done by a specific set of people. The Program Manager and the Control Account Managers. The "program controls" function provides oversight and insight to those people.

There are specific roles on the PP&C (Program Planning and Controls) side of the program. Here are the questions we ask when interviewing someone for that role:

Planning

1. Integrated Master Plan

• Speak about your experience with Integrated Master Planning
• Tell where on the web you'd find information about Integrated Master Planning
• What information do you have at your disposal on guidance for developing the IMP?
• Name 5 possible Program Events in the IMP?

2. Integrated Master Schedule

• What DID defines the creation and use of the IMS?
• What are the three levels of the IMS mandated by this DID?
• What does the DID say about a Schedule Risk Assessment>

Earned Value Management

3. Control Account Plan

• What information is contained in the CAP?
• Who participates in the development of the CAP?
• Who typically owns the CAP?
• With the CAP in hand what would the person do next?

4. Work Package

• What is a Work Package?
• What does the Work Package produce?
• What does the Work Package contain?

5. Earned Value Execution, in you experience ...

• Where are the labor cost rating numbers typically kept in an Earned Value Management System?
• Where the non-labor costs typically kept?
• How and where are subcontract dollars usually recorded?
• What is the impact of starting work?

Monitoring and Control

6. Performance Measures

• What would be the preferred measure of task performance in the EV sense?
• How would you construct a performance measurement system at the Work Package level?
• How would you do the same at the Control Account level?
• What would you say is the best performance indicator for forecasting future performance?

7. Performance Reporting

• What is contained in Format 3 of the IPMR?

Programmatic Risk

8. Duration Estimating

• From your experience, what would be a way of capturing task durations?
• Speak about the possible errors that you might encounter in the method you have used.
• Speak about the statistical independence, coupling, and Merge Bias in activity networks.
• Can you remember what the PERT formula is?
• Speak at bit about the concept of Monte Carlo Simulation
• In what DID is Monte Carlo Simulation (MCS) (Schedule Risk Analysis (SRA)) called out?
• Have you applied SRA/MCS to an IMS? If so, what tool have you used?
• Where is the Monte Carlo of the Monte Carlo Simulation located?

9. Technical and Programmatic Risk Management

• Where would you find information on the DoD Risk Management processes?
• Name the four options for handling Risk.
• What is a Five-By chart and how would you label the axis?
• Where on the chart is the GREEN portion most often found?
• Could you speak to why multiplying the probability of occurrence with the impact might have problems?
• What tools have you used or heard of for managing the named risks in the IMS? 
• Have you applied those tools in the past?

10. Critical Path Analysis

• Speak about programmatic risk and the critical path?
• How do activities get on the critical path?
• What is meant by near critical path?
• What is the impact of Level of Effort activities on the Critical Path?

Microsoft Project

11. Building the IMS

• What would be your advice on the least risky way to build an IMS down to the Work Package and Task Activity level?
• How would you construct unique labels (symbols) for deliverables, outcomes of Work Packages, Milestones, dependencies or any other items that need to be distinguished from the standard work effort?
• Show how you can “profile” the assigned labor level for a resource beyond the single assignment in the Resource assignment field for the task. For example how would you assign 100% to the first three weeks of a ten week task, then 50% for the next 3 weeks, and back to 100% for the last five weeks?

12. Microsoft Project Demonstration

• Why would you not want to use the WBS field in MSFT Project for WBS data?
• How would you make a dependency connection between to activities in two separate project files?
• What is the field length limit in a predecessor or successor field?

These and similar question will bring out the level of experience on the PP&C side of the project. These of course are not related to the other aspects of "managing" the project. But when someone says, "I've got experience managing projects," this is one place to start to see if "providing performance visibility" to the project has been one of those experiences.

Managing Your Project Performance Using 2nd Grade Class Concepts

Our daughter is a 2^nd grade student teacher this semester. On her board is a poster. It is the framework for the learning process used in the district. I visited today and read in small groups to the cutest 2^nd graders on earth. During lunch I saw this poster and it dawned on me - this is exactly what we need for the weekly program status meeting. If it works for 2^nd graders, it'll work for Control Account Managers and project participants accountable for project performance.

Every Tuesday the CAMs meet with PP&C to figure out where we are, where we are going, how we're going to Keep it GREEN.

1. Focus Question - from the statused IMS taken last Thursday, you all have your physical percent complete and actual or estimated actuals. So what specific questions should we be asking of each other this week to keep the program GREEN? This usually includes:
   • What is coming due?
   • What dependencies are there between CAMs for the coming dues?
   • Are this going to show up on time?
2. Prediction - with the statused IMS what is the forecast for next week, next month, the next quarter, or the next deliverable?
   • What is the confidence in the dates and cost as well as the technical performance?
   • What activities must be in place to maintain or improve this confidence?
3. Plan - we have a Plan (IMP) and a Schedule (IMS). Planning is a verb, the Plan is the outcome.
   • Is the Plan still credible?
   • If not, what changes need to be made to the Plan to return it to be credible?
   • If we make these changes, what are the impacts for the future?
   • How will these changes increase the probability of success for the project?
4. Data - we have Earned Value data, actual costs, indirects, procurement commitment:
   • What does this data tell us?
   • What forecast does this tell us?
   • What management actions will be needed with this data to keep the project GREEN?
5. Claims and Evidence - when we forecast, do we have evidence of the credibility of the forecast?
   • Past performance is a good predictor of future performance
   • Reference class modeling provides statistical models of future performance
   • What are the confidence intervals on each forecast?
6. Conclusion - what did we learn from last week, last month?
   • Did we make our forecast the last time?
   • NO, what did we get wrong?
   • How do we not make the same errors?
   • How do we improve our chances of getting better?
   • YES, what did we learn that can be applied to this week, month, quarter
7. Reflection - at the end of the meeting, what did we get that wasn't there before we started?
   • Communications clarity
   • Forecasting clarity
   • Risk retirement clarity

Integrating Cost, Schedule, and Technical Performance Measures

In the previous post, the new IPMR DID instructs us to integrate cost, schedule, and technical performance.Here's some more advice.

Now the bigger question. Where is the similar advice for IT projects. Agile starts down this road, but needs a broader capabilities statement. PMBOK based PM doesn't have much to say if anything around this. Home grown PM processes are usually simple and obvious check lists.

It Can't Be Any Clearer Than This

If you're going to have any hope what so ever of being successful with your project, here is some advice. Only with this integration can you know the answers to the 5 Immutable principles of project management.

1. What does DONE look like? - define the needed capabilities in Measures of Effectiveness and Measures of Performance in units meaningful to the decision makers.
2. How are you going to get to DONE? - construct a plan showing how you are going to assess the increasing maturity of the deliverables and a schedule showing the order of the work needed to produce these deliverables, and the measures of Technical Performance needed to assure these deliverables meet the needs of the customer.
3. What Resources are you going to need along the way? - resource load the Integrated Master Schedule - or what ever artifact you are using to show the path to completion.Show the profile (demand and capacity) for each resource.
4. What Impediments will you encounter along the way? - without a risk management plan and a risk management process to support the plan, showing how you are going to handle each risk, you're going to be late, over budget, and your gadget probably isn't going to work.
5. How are you measuring progress to plan? - this measure needs to be in units of physical percent complete. This measure needs to be adjusted for compliance with the Techncial Performance Measures, and this measure must be probabilistically risk adjusted for the variances in performance.

This text in the picture is taken from the new Integrated Program Management Report (IPMR), DI-MGMT-81861.

Rings of Success

Olympic Rings featured in nearing everywhere these days. Those rings represent the 5  parts of the world which now are won over to Olympism and willing to accept healthy competition. While there is much talk about the projects of the Olympics, some difficulties and many successes, there are other rings that must be connected for project success:

1. Risk - all project elements have risk. Cost and Schedule risk are a starting point. These can be addressed through straight lists of risks, their probability of occurrence, impacts, costs to mitigation and residual impacts after mitigation. Most approaches to risk management assume an independent association between the risks. That is they are decoupled risks, existing on their own. Many times this is not the case. What is Program Controls? speaks to some of the complexity of integrating technical risk with programmatic risk and addressing the coupling issues that are ignored in the Monte Carlo Simulators of project duration and their resulting cost models.
2. Cost - the olde phrase time is money is tossed around without any real consideration for what that means. What is the relationship between time and money. Where is that relationship defined? What are the statistical attributes of that relationship and its impact on the probability of success for the project. This must be addressed through a cost modeling system. SCEA is one place to start.
3. Statement of Work - What Does DONE Look Like? The SOW is one place to look. Assuming it is written properly. But Statement of Objectives, Concept of Operations, Scenarios, Use Cases, and Performance Work Statement are also places to look. Without a clear and concise collection of deliverables
4. Technical Performance Measures - define what DONE looks like in units of measure meaningful to the decision makers. TPMs involve a technique of predicting the future value of a key technical performance parameter of the higher-level end product under development based on current assessments of products lower in the system structure.
5. Work Breakdown Structure - describes the products or services to be delivered by the project, how they are decomposed and related. At the end of the tree of the WBS, is usually the Packages of Work that produce these outcomes. Without a properly formed WBS, you cannot determine what done looks like in any meaningful way. A typical mistake is to develop a WBS based on work types - design, code, test. This simply states the effort not the result.
6. Integrated Master Plan / Integrated Master Schedule - The IMP is the Plan for the delivery of a set of Capabilities from the project and describes the increasing maturity of these capabilities through Significant Accomplishments and their Accomplishment Criteria. The Integrated Master Schedule describes the sequence of work, usually in Work Packages needed to produce the deliverables for the Accomplishment Criteria.
7. Performance Measurement Baseline - brings the cost, schedule, and outcomes together in one place, puts this under change control, and measures progress to plan through assessments of Physical Percent Complete, and forecasts future performance (Estimate At Completion and Estimate to Complete) using Earned Value Management.

Putting This All Together Through the Tangible Evidence

Each of the Rings are represented by tangible evidence in the form of a document. I can hear the agilest now, no documents. Well sorry, in the domain we work, we need evidence that you do in fact have a SOW, a Risk Plan, an IMS, a cost basis of estimate, a Technical Performance Management plan and other items that show the project is planned properly, being managed properly, and measured properly.

Here's the top level connections...

Quote of the Day

You cannot manage what you cannot measure... and what gets measured gets done

- Bill Hewlett, Hewlett Packard

Without a performance measurement system, you'll not be able to tell if your project is actually performing to plan. Without a plan that defines the performance measurement goals, you'll not be able to tell is your performing to plan. Both the plan and the measures are needed.

So What Does A Plan Look Like With Performance Measures?

• It is deliverables based
• Each deliverable has a cost and schedule target
• Each deliverable has a technical performance measure target
• There are mechanisms to measure cost, schedule, and technical performance on periodic bounds.
• These bounds are short enough to determine the project is not performing as planned and short enough to take corrective actions to get the project back in schedule, cost, and technical performance.

And What Is A Good Paradigm For Measuring These Things?

Why of course Earned Value Management integrated with Technical Performance Meaasures.

 

The Train Wreck for all Projects Starts With These Problems

There are many reasons projects and programs fail. It is assumed that requirements are unclear, change can't be managed, sponsors aren't on board, and the plethora of other problems found in projects. But those problems are pretty much traceable to immature projects or projects - especially IT projects - in general that are low on the maturity curve.

How about projects (or programs) that are more mature on the technical and managerial side? Projects where the participants actually know what done looks like in some credible measure, know how to produce the outcomes, and generally are competent in what they do.

Why do these projects get in trouble - and they do all the time. Here's a list of sources of the Train Wreck for mature projects.

1. Inattention to budget responsibilities - management and technical leaders don't keep an eye on the budget. Spending hot can not be recovered. You spend to much for an outcome, and you're over budget, which dilutes the business value of that deliverable. You can never make it up, unless you redefine the value.
2. Work authorizations not always followed - the plan needs to be followed. Even in the agile world, the stories agreed to for the iteration need to appear as a result of that iteration. No rearranging the work. In the agile world this is even more important. Producing the business value in the planned order to meet the business need. In other domains, dependencies between produced outcomes is critical for distributed activities.
3. Lack of an Integrated Management System - connecting all the project performance information in one place is critical to providing visibility to management. This means everything that takes place needs to have units of measure meaningful to the decision makers.
4. Baseline fluctuation and frequent replanning - if you can't stick to the plan, you can't measure your progress. This does not mean blindly following a plan. But if you have a plan and you don't follow it, you're just wasting your time. If you need to change the plan - for a good reason - then do so. But record these changes so you can go back and calibrate your performance.
5. Current period and retroactive changes - no cooking the books and making problems go away by changes history.
6. Improper use of Management Reserve - MR is for unknowns within scope. No using MR to cover your mistakes.
7. EV techniques that don't reflect actual performance - if you're not measuring physical percent complete in units meaningful to the decision makers, than you're wasting your time. The EV numbers won't be credible. You have to measure tangible evidence of progress to plan not someones opinion of progress - Show me.
8. Lack of predictive variance analysis - all numbers in the baseline are random numbers. Without understanding the variances of each class of number (reference class models) and the correlations (causality) between the numbers, you'll never get a handle on why things are going wrong.
9. Untimely and Unrealistic Latest Revised Estimates - stop changing the forecasts and get a handle on what is really happening. Standdown if you have to, but get it right for some period of time before proceeding.
10. Progress not monitored in a regular and consistent manner - how long are you willing to wait before you find out you are late? Sample progress at least at ½ that time period, otherwise when you find out you're late it's too late to do anything about it.
11. Lack of vertical and horizontal traceability cost and schedule data for corrective action - vertical traceability shows how the products are increasing in maturity. Horizontal traceability shows how you're actually doing work to increase that maturity. Both are needed for success. This is the purpose of the Integrated Master Plan and Integrated Master Schedule.
12. Lack of internal surveillance controls - left alone all processes degrade. Who's watching those doing the work?
13. Managerial actions not demonstrated using Earned Value - management has to walk the walk every week. Not just watch others. Management has to manage using the numbers. Only the numbers talk. No other evidence is acceptable.

Issues with Deploying Earned Value Management

On the EVM LinkedIn site there is a post from a supplier of EV services (one of those infomercials) about the problems with deploying Earned Value. Now I'm not one to comment on business development types posting on public forums, because one of the main purposes for things like LinkedIn is the maintain contact with other professionals and potential clients in our industry.

But this post seemed to be missing something that is common in today's world of selling solutions. The message starts with a list of problems. Obvious problems at times. Lame problems some times - doctor doctor it hurts when I do this. Then stop doing that. The Rocky Flats poster says ...

Don't Do Stupid Things On Purpose

... is always my favorite, when I encounter descriptions of bad management masking as real problems.

I responded with the following to the 10 reasons EVM Fails. By the way EV (Earned Value) is the numbers from the formulas, EVM (Earned Value Management) are the management actions using these numbers, and EVMS (Earned Value Management System) is the collection of software and processes that implement the Earned Value Management. This is a detail, but it may be insight into the understanding or misunderstanding of how EVM actually works using an EVMS.

Anyway here's my response:

No doubt there are problems. The issue is, every problem needs a solution scaled to the ability of the organization to absorb the solution. When I see problems listed without the first level of solution I'd suggest it doesn't serve our community in ways that showing how to address or at least start to address the problem would.

All the problems listed have simple solutions. So perhaps for each of those, a starting point solution would be the next step in your efforts to introduce EV to organizations. 

Here's my list:

1. Lack of management commitment - build a fee or profit maintenance case for using EV to address uncontrolled growth of EAC. Think about money. Use Gerry Mcquire Show me the money.
2. Management doesn't assign proven performers - use Ray Stratton's EVM maturity assessment book as a start.
3. CAMs don't accept responsibility for CSP - get new CAMs. Really, this is unacceptable for any business. If assigned to a job and you say I'm not doing this. You need to have another job. If you're not qualified, get trained. If you're not capable, get help. If you just don't want to do it, get another job.
4. Management doesn't hold CAMs accountable - the managers better look for work somewhere else - really the role of management is to manage. They have no business managing if they can't perform their fundamental role in the business. Management is a VERB.
5. Poorly documented processes - this is common actually. But there are numerous process flow charts for EVM on Google. Look for DOE System Descriptions for the laboratories (LANL, Sandia, Oak Ridge, etc.) copy them put them on the wall.
6. Poorly trained teams - buy Rays book, download the PMI EVM guide, find the Booz Allen DOE training from the DOE site, sign up and get the EVM for Dummies from DelTek, loads of free sources, attend the College of Perfomance Management EVM World or the Integrated Program Management conferences.
7. Using unproven tools - EVM is not about tools (EVMS) in the beginning. It's about people and processes. EV can be done on a white board. Tools make it easier, and maybe better.
8. Management accepts excuses for bad performance - this is a failure to communicate as Luke was told. There is no excuse for this excuse.
9. Inaccurate data in the system - now this is a REAL problem. It's a problem on billion dollar programs we work as well. The only way out of this is brute force corrective actions. Continuous vigilance of the integrity of the data is required. This is really hard work for every user of EV, it never ends.
10. Lack of commitment (again) - well it's time to own up to the role of management isn't it. This is a lame excuse and will only be corrected when management is held accountable for their actions. If they're not committed, don't even start, move one, do it another way. This is like saying I can't loose weight, because I really can't stop eating jelly donuts for breakfast. Really? As our HR director (a women) is fond of saying, come on guys, put your big boy pants on and deal with the problem.
    

The list from TenSix is a good start - for the most part - but if we keep pointing out the problem, without some set of solutions, nothing is going to change, in fact it is going to get worse. Actionable outcomes are the basis of change. And even more important pointing out the obvious solutions is not all that useful either. If the solutution was simple, the problem would have been solved long ago.

So when you're starting to think about EVM, try the phrase we use when selling the idea of EVM to firms just starting to enter the domain requiring or desiring EVM,

It provides actionable outcomes in units of measure meaningful to the decision maker, to increase the probability of program success.

If they buy that, start solving the other issues in the list, if not, find a place where there are better managers.

Now my responses are simple and possibly  simple minded. So that means the real answers are hard and require dedication, commitment, resources, talent, experience, good processes, deep knowledge and the ability to develop soultions to fit the need of the domain and context. Tools are nice, but tool vendors sell tools not solutions. So in the end face the facts that this is real work.

As another colleague from a major defense contractor says - There is no such thing as EVM Lite. There is only EVM RIGHT. You don't have to have all 32 Guidelines in place and working on day one. But you'd better have the 11 Earned Value Guidelines in place and working, or you're not doing your job as a program controls person. Then the next challange is to deploy these on real projects. But then you'll encounter other problems. Problems around the business of running the business with EVM.

If we keep looking for - and getting - simple solutions to complex problems, we're going to be disappointed. Time to put your big boy pants on.

Definitions, Yes They Are Important

Just finished reviewing my notes from a DAU course on Earned Value and the validation of Earned Value Management Systems (EVMS). In the first hours of the first day, there is a slide that admonishes the students to:

• Use precise terminology
• Use the correct terms

This is because many times terms are used interchangeably and many times incorrectly

For programs applying Earned Value Management

• Earned Value Management Systems (EVMS) - a company's management system and related sub-systems that establishes the relationship between the cost, schedule, and technical aspects of the work. Measures progress objectively with earned value metrics; accumulates actual costs; allows for analysis of deviations from plans; allows for forecasting achievement of milestones and contract events; allows for forecasting estimates costs; and provides for discipline in incorporating changes to the baseline in a timely manner.
• Earned Value Management - a program management tool that integrates work scope, schedule, and cost parameters of a program, in a manner providing objective performance measurement and management.
• Earned Value - the valie of completed work. The same as Budgeted Cost for Work Performed (BCWP).

Who Cares?

Here's why. There are many voices out there how misuse these words. Some are well placed voices, working for brand name computer firms, with platforms that people listen to.

The classic is the complaint that EVM can;t be used on IT projects because it does not measure business value produce by the project. This of course is not only wrong - see the third bullet - it is uninformed. Because of this misinformation, there is now a group of software developers that have come to believe that EVM is not the right tool, simply because of this serious mistake in understanding.

So Here's The Replacement

Earned Value Management is a close fit with the development of software in the agile paradigm. Planning the outcomes in a planning session, assigning costs to the development of the outcomes with the Budgeted Cost of Work Schedule (BCWS) is simple - how may people do you have on this iteration? How much do this cost your firm? How many hours for the iteration x (Salary + Overhead + G&A + Fringe + Cost of Money)? This is your budget for the work that is to be performed.

Someone has to pay. Your firm pays if it is an internal project. Your customer pays if it is external.

What's the schedule - the period of performance for this work? In agile (Scrum) it is the duration of your iteration, the release cycle, the epic, or what ever you want to call the longest period of performance for your work efforts.

Now the reason for Earned Value Management

When the number of story points is defined in the planning session, these might be considered the measure of physical progress to plan, so let's consider them so for the moment. As the iteration progresses, these story points are earned when they result in 100% Physical Percent Complete - the perfect agile term - Working Software (according to the definition and units of measure of working).

The formula (the simplest one) for Earned Value is EV = BCWS x Physical Percent Complete.

In the agile world the Physical Percent Complete is either 0% or 100% for each story and its assigned Story Points. This notion of defining the value the Earned Value up front and then earning it is both an Agile notion and an Earned Value Management notion. What is missing from the Agile notion is the Budget for earning that value. But not problem, almost all Scrum teams have fixed resources assigned during the iteration, so the budget is the number people times their burdened cost.

In the End

Ignoring for the moment the notion of AgileEVM, EVM Lite, and any other made up term - there is ONLY EVM RIGHT - the principles of Earned Value Management are universally applicable to all projects, for the simple reason that project management performance measurement is about:

• Defining what done looks like
• Build a plan to get to done
• Allocating resources to produce th work that delivers the product or service
• Handling the risk encountered along the way
• Using tangible evidence of progress to plan from the work performed to deliver the products or services.

Earned Value Management is about measuring physical progress to plan. It is a natural process of iterative and incremental development. Don't let those supposed experts tell you otherwise. EVM is not about measuring business value. That's another measurement - usually a Capabilities Based Planning, some form of business modeling, or even a monetized Balanced Scorecard approach.

Earned Value Management is about measuring the performance of your development work in units that are meaningful to the decision makers. Story Points have no unit of measure meaningful to the decision makers. Consumption of money is meaningful, Story Points are just an ersatz representation for money.

What is Earned Value?

Earned Value Management is a method of measuring the performance of work efforts that have been budgeted and the work planned in a time phased manner.

Earned Value should be named Eraned Budget - you earn your budget for the work.

Why is Earned Value unique in the world of project management?

• Performance is measured by tangible evidence of progress to plan
• Future performance is based on past performance, adjusted for productivity, risk, and technical complexity
• The efficiency of the work is the basis of performance measurement, rather than the passage of time and consumption of resources.

Applying Earned Value is simple

• Define the work in units of measure meaningful to the decision makers. What is the tangible evidence that the produced product or service meets the needs ot the buyer?
• Define the budget and time phasing needed to produce this outcome, or incremental versions of the outcome.
• Perform the work during the planned period.
• Measure the physical productivity from the work effort. The Physical Percent Complete.
• Compare the planned Physical Percent Complete with the actual Physical Percent Complete
• Compare the planned budget for reaching the planned Physical Percent Complete with the actual cost of reaching the actual Physical Percent Complete.

With these numbers calculate the Earned Value for the work performed to date:

With this result - the cost variance and the schedule variance - you can now forecast the future performance of your project. This means that when someone asks how are we doing? Or asks, when will we be done? Or even better, how much will this cost when we're done? You can answer with a definitive set of numbers in units meaningful to the decison maker.

Numbers like:

• If we keep going like we're going, we'll be 87 days late
• If we keep going like we're going, we'll be $102,000 over budget

These types of answers are not available, when you measure progress to plan with the passage of time and consumption of money. While agile suggests that it is doing Earned Value, it does not measure the cost of doing the work, nor does it measure the pre-defined phsyical percent complete in units of techncial performance.

Earned Value provides you with insight into the physical progress to plan, in units of measure you can use to make adjustments to the project to keep on schedule, stay on budget, and provide visibility to the increasing maturity of the products or services your project is delivering.

Here's the next level of understanding Earned Value in Five Easy Pieces.