Earned Value Analysis is great on paper. However, I'm having difficulty using it for programming projects that tend to change dramatically from week to week.

For example, a milestone is "complete test plan 2 on accounting package", however, in the first half hour of the test plan, the tester discovered an unrecoverable bug. Fixing the bug is 3+ weeks worth of work that was never in the work break down structure. The programmer says, "oh yeah I forgot to include that task" when we made the task list.

So, how do you handle this? Do you create the chart so that your project is now a month behind schedule and a month over cost because the WBS was incomplete? Hard to swallow when the entire project is 6 weeks long. Or, do you adjust the planned value to include this new 3 weeks worth of work thus creating a new project plan?

To further extend the question, how do you handle disagreements about the meaning of a work item. The programmer says it's done. The stake holder explains why the three legged cat is missing a leg and the programmer says, oooh you wanted 4 legs?? Well, that's going to take an additional 3 weeks. The new cat will have more value with the extra leg... but the project will take 3 weeks longer than estimated. How do you handle this?

5 Answers 5


That is called a variance. It is not a missing task. It is work in scope but not planned. This means you cannot claim EV on that package until the extra effort is finished.

You will accrue an unfavorable SV and CV.

The four legs example is iffy. If you had explicit requirements about the three legs, then you have a change. Add it and strike a new baseline. If not, you have an issue. Likely, you will have extra effort and more bad variances.


David is correct, you simply have variances that will be unfavorable.

Here's part of the problem as I see - you're trying to use EV, which assumes (and requires) an accurate level of detail in work package breakdown, and an understanding and agreement on what 'done' looks like. As long as you have situations where you're arguing about three-legged cats, EV will be worthless as it will ALWAYS be unfavorable due to that addition of new tasks.


Not entirely sure if this answers your issue. When I add items in my software projects, I add them into a separate level 1 roll up (Agilers might call it a "Backlog"). In this way, I can see the items being discovered after the requirements were approved and of course their effort estimates. The reason I like this is that MS Project (2016) has a canned report showing the total effort (BCWS) for the defined project and the value of items being added throughout the project. The report shows them side by side, but I think the entire project file's EVM calculations will be thrown off from the approved requirements.

(I purposefully don't use the term baseline for "approved requirements" so as not to cause confusion with baseline calculations).

The easier way to account for new items is through baseline reporting. Take the approved requirements and plan and set your baseline. Then when you add new items, set the reporting date and a new baseline. Don't overwrite an existing baseline, create a new one. Then click (in MS Project 2016), Project Ribbon -> Click Calculate Project (optional i think) -> Then click Project Information -< Project statistics. From there you can see the comparison of the initial baseline to the current plan. EX. Initial baseline finish was 12/10/16. But in adding new requirements with their estimates, the project is extended to 12/15. The Project Statistics will account for that extension if you set a new baseline and ensure your reporting date is correct.


This is an X:Y problem. You don't have new tasks, you've got problems in scope planning and estimation/WBS development.

1) The work isn't scoped correctly - the WBS & WBSD should explicitly address the number of legs for the cat (assuming that the cat's number of legs is important). This is a planning problem. When you analyze variance, you should consider the impact of this on future planning. If this happened to me, I'd revise my planning process for future project/sprints/planning efforts.

2) The work isn't estimated correctly. Estimation of work packages has an innate high variance. The reason we pay these people so much is because their work is complicated and includes a lot of surprises. Bugs get discovered. Technical debt undermines progress. Good project managers recognize this and ask for estimation in ranges/confidence intervals, and continuously track the variance. Some developers will consistently underestimate work packages; others will overestimate. A good project manager will track the estimation variance and adjust estimation variance for future projects.

How do you handle changes in planned value? (which is the way I'd phrase your original question) First, you use a configuration management process to assess the impact of the changes on the project and ensure that relevant stakeholders are aware of the change and have the option to assist in managing the change and second you re-assess the rest of the project plan in the light of the change. Scrutinize that plan to see where else the estimation and/or scoping are questionable, and adjust the confidence interval of those sections of the plan.

Key summary points

1) Subsequent plans & estimation should benefit from earlier plans and estimation (that is one of the points of lessons learned and variance measurement). Bad project managers "pad" the schedule; good project managers apply lessons learned from prior projects to improve the probability that the outcome will be within the estimate.

2) As the team progresses through the project, the confidence intervals will narrow. Good project managers are constantly revising estimates, and the confidence interval can be a huge leading indicator of risk. If a finished project requires 12 work packages, and each work package is estimated within 80%, then the confidence interval for the entire project is huge (which is why monte carlo is so powerful). But when the first work package is delivered, the confidence interval should collapse inward - both because the confidence interval of a delivered work package is zero, and because what you learned from the variance can be applied to the confidence interval of all subsequent work packages.

3) I forget who said that the key skill of a project manager is setting up the conversations with the technical experts so that they automatically give you the information you need to manage the project - establishing your information needs so that sharing that information seems friction free. A good PM is always alert to any event that might alter the quality, schedule, cost, or completion probability of the project and is constantly listening to the project team for evidence.


You are measuring 'earned value'. How are you measuring 'value' ?

For example, your milestone 'test completed' is not value. Only working software can be value.

Therefore projects often measure 'value' as 'the time it takes to build it'. But these are two different things. If my product delivers $1000 in sales to you, than its value is $1000. Regardless of the time it takes me to build it for you.

Earned Value lets you deliver high value items first. But when you use it to simply slice a project, pretending that the parts have value, it does not work.

From there we can start to track interesting things. How long does it take me to deliver $1000 to you? How accurate are my estimates per workitem? These are the things you need to track in order to become predictable.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.