Maintaining the Performance Measurement Baseline in Earned Value Management

Email Notifications

SHARE
Request to reuse this

The Standard for Earned Value sets out an approach for scope management with the goal of maintaining the performance measurement baseline. You need to keep the integrity of the baseline, otherwise there is no point in having it to measure against.

And given that change happens, you need a plan for dealing with those changes. I was interested in finding out why there needed to be a separate scope management process in the Standard. Perhaps you manage change differently if the project uses EV methods?

I suspect you don’t – but you do need a way to tie scope changes back into the time and cost baselines so your EV metrics don’t go off track.

Read along with me as I dig into this Chapter of the Standard and uncover what’s different about managing scope in the world of earned value (it’s Chapter 10, if you are interested).

Inputs

There are four inputs to this process:

• The project management plan – in particular, the performance measurement baseline and the integrated change control process
• The performance measurement baseline. So important they mention it twice – in the plan above and in its own separate called out line!
• Change requests – because we’re talking about what happens when a change happens
• The integrated change control system – this is the process for change control. Is a process really another input to a process? I get that having a way to evaluate project changes is important if you want to evaluate a project change. Let’s assume this relates more to the tech, decision making framework etc.

So what do you have to do with those inputs?

What to do

There are three main things that need to happen as part of this process.

First, the change should be analyzed. The Standard suggests that a Change Control Board is convened to do that. I think the CCB is a really useful group and we relied on it in my last job. Our CCB looked at operational and project changes so the team could see the impact of ‘normal’ changes as well as the project-related ones.

I think this really needs to be done, at least at an introductory level, before the CCB gets together – otherwise what will they talk about? In reality, all these things have to happen in a logical order because you might approve the change but then need to do the analysis of what happens to the project in terms of the work.

For example, you need to update the baseline and the WBS to incorporate the change. The tasks to be done are added to a work package, and in EV, the process for doing that is a bit counter-intuitive. The Standard explains you close the current work package and move the money to the new work package, along with the new budget for the new tasks. The rationale for this is to maintain the integrity of the cost variance while removing any schedule variance. Create a new control account and carry on.

Then, the cost and schedule baseline need to be revisited. That improves the correlation between the work to do, and the baselines for budget, scope and time.

All in all, there is a surprising amount of work required for handling a scope change in an EV setting. No wonder you get the impression that it’s hard to make changes and that there needs to be adequate planning up front to avoid extra tasks arriving later.

Outputs

The outputs from this process are:

• Performance measurement baseline updates (let’s hope you have the tools and support to make this part easy)
• Project management plan updates (review the WBS and dictionary, plus anything else)
• Change request status updates (update the change system to note what was approved/rejected etc).

I read this chapter and was surprised. I mean, not surprised that you have to do scope control or update the baseline, but surprised at the admin involved in re-aligning all the different aspects of the performance measurement baseline. I suppose I knew that it needed to be done hypothetically, but I had never unpicked what it would look like to have to do that work.

I have a new respect for schedulers and project control managers.

Not only do you need to deal with the change and incorporate the decision to do it into the work (which all projects need to be able to do), there’s an added level of admin required to maintain the integrity of the EV reporting.

The Standard says, for example, “Budget must never be transferred simply to eliminate variances.”

Well, back in the day, I did exactly that. On a project (where we were not using EV), our overall capex budget was set. I had the flexibility to move money around within the different capex lines, as long as overall we stayed in budget. So I did. It meant the difference between hospitals receiving the kit they needed to work efficiently or not, and it was never large sums of money. The budget remained overall balanced, and no one really minded how it was distributed as long as everyone got what was needed and we knew where the cash was going.

I learned a lot about budget tracking from that project and I quite enjoyed it. I’m not sure I would have enjoyed it as much if I had had to incorporate EV reporting as well.

There’s a worked example in the book, so if all this doesn’t really make sense to you, or you can’t see the flow of the changes, that’s helpful.

Pin for later reading