The Money Files

In this part of my occasional series on program cost management, inspired by The Standard for Program Management (Fourth Edition), I’m talking about 9 financial management tasks that you should expect to do as a program manager.

1. Identifying changes

First up, be aware of what might be coming over the horizon to influence the budget baseline and what factors are leading to changes. This is basically being aware of what might create a change so you can be on the look out for any changes. It’s proactive listening and always considering what a course of action might do to your budget.

2. Monitoring for impacts

Part of the daily work of a program manager is keeping your eye out for any environmental factors that might impact the program overall, and budget changes are part of that. These could be environmental factors like changes in regulation, access to skilled resources from the local hiring pool, or access to the right technology – anything that could have an impact on the budget.

3. Managing changes

What happens after you scout the horizon for things that might change your program budget? You find things. Part of a program manager’s tasks is to manage those changes. The change could be to scope, to the schedule, to the resource profile, procurement plan, or anything else, and we have to play back what impact that is going to have on the budget and build in the changes.

4. Monitoring cross-project impacts

As I mentioned in my last article, part of my role as a program manager is being able to shift funds between pots to ensure the overall program goals are met. That’s what this task is all about: monitoring the impact of what happens when costs are reallocated and making sure that overall the program components are balanced – or at least as balanced as they can be.

I mentioned cross-project impacts in the heading, but programs often include an element of BAU work and that can just as easily be affected by changes.

5. Monitoring supplier contracts

Some suppliers might be contracted at a program level, so it’s the program manager’s job to ensure that suppliers get paid in line with their contracts. With one supplier I worked with, we had contractual milestones in place. When each milestone was reached, another stage payment was due.

Part of my work was ensuring Finance was aware that a stage payment was due so they could have the right amount in the bank accounts ready to pay when the time came.

6. Earned Value Management tasks

If your program uses earned value management, you will work with control account owners, project managers and other experts on the team to make sure EV practices are implemented and adhered to. Part of the role will also be making sure everyone can interpret the outputs of EV reports and manages their part of the schedule accordingly.

7. Dealing with over and underruns

It’s unlikely that your program will be perfectly on budget every month because that would rely on your estimates being perfect and no ‘real life’ happening during the work. It’s more likely that you’ll be a bit under or a bit over.

Part of the program manager’s role is to manage within that tolerance and to advise and support project managers on the program to do the same.

8. Working with stakeholders

Another big part of program management is communication and engagement with stakeholders around changes. The sponsor, customer, client and governance groups (including auditors) need to have access to transparent information around the program’s financial measures. You have to provide that.

9. Managing within tolerance

Finally, the main, most obvious part of the role is to manage the program’s spending within the levels expected. You may have set tolerance at individual component level, or there may be other ways you are managing to within the expected parameters. These should be clear, so everyone knows how the work is being tracked.

And, if you spot that you are not managing within the parameters and boundaries set, then as the program manager it’s your role to take steps to get back on track, whatever those actions might look like.

Or perhaps this article should be called: 5 pitfalls that can happen when EVM is not implemented the way it should be!

Here are 5 things that can go wrong when an organisation chooses to implement Earned Value Management as a way of working for project performance tracking.

1. There is low organisational support

Possibly: there is no organisational support outside of the PMO. EVM is very much an enterprise-type solution so everyone needs to be on board. The whole organisation needs to know what it means for them as individuals and as a team – and you should try to bust the myth that it’s all complicated maths.

In reality, most of the tools now do all the heavy lifting for you, so there’s no need to be hands on with the maths. However, the project delivery teams are going to need to understand the inputs and outputs to the formulas so they can interpret what the numbers are saying. That’s the secret: it’s making sure the wider team understands that the move to EVM is all about creating a set of essential measures to track performance and improve project control.

2. Thinking of EVM data as the answer

EVM data is simply a representation of current project performance. It’s not a decision in itself. It’s not a set-in-stone forecast that tells you what is definitely going to happen.

The team can still adapt and change, mixing up what they do to shape future performance, preferably in a positive way. The data should be seen as decision support information, helping the team make the right choices about what to do next in order to get the best results for the project.

3. There are poor or no decision-making processes

Pitfall #2 brings us on to this one: EVM implementations struggle when the organisation has poor (or no) decision-making processes. There should be some way of managing decisions as part of project control. Decisions and management responses to situations should be structured and repeatable, not knee-jerk. Proactive action taking is better than reactive ‘let’s just do something and cross our fingers’ type decisions.

EVM data is good, and helpful, and informative but if the project leadership team don’t have the power or ability to do anything with it, then the data is just a set of pretty reports no one ever looks at. Decision makers should be looking for patterns, documenting decisions made and their outcomes so that future decisions can be shaped by today’s lessons learned and building credibility by using the information to improve project performance in meaningful, predictable ways.

4. Limiting EVM to a small group

When EVM is implemented, we talk about it being a whole enterprise thing, and that everyone needs to understand what it is and the value it brings to the organisation (as discussed in Pitfall #1 above). But making it ‘a whole enterprise thing’ actually goes far wider than a communication campaign.

When EVM is implemented, it’s important that the whole team is able to see, input, act on and engage with EVM numbers. They should be responsible for their part of the system. In other words, it’s not a good idea to limit the people with hands on experience to a small sub-group of project practitioners in the organisation. It’s ineffective to ask project managers to provide time sheet information, for example, to the gatekeepers who then load it into the system and provide monthly reports in PDF format.

That leads to a couple of problems. Practitioners feels like they aren’t truly included in the EVM and will probably disengage from it. For them, it becomes one more set of data points to submit to someone else for reporting; something that happens outside of their sphere of influence (or interest). It also creates a culture of auditing, where individuals feel that their work is dissected by people who lack hands on experience. EVM shouldn’t turn out to be a ‘them’ and ‘us’ experience in practice. For best results, it really does need to be a whole team process with plenty of input from everyone. Basically, it needs to become ‘how we do business round here’.

5. Not creating a common vocabulary

Of all the various aspects of project management that require specialist jargon, is EVM the worst? I think it could be. There are all the acronyms (PV, EV, SPI, etc) and formulas. There are control accounts and control account managers (which must make control accounts very important if they have their own managers), plus the terminology that goes along with the WBS.

The benefit of all this jargon is that when it is understood by everyone, it provides a common and clear way of talking about the same things. You avoid the misunderstanding of schedule vs plan, for example, because there is a common language with terminology that means the same thing to everyone. That’s powerful. It’s also good for decision making because clarity of understanding helps execs make the right call.

Next month I’ll be looking at a few more pitfalls from EVM implementations that are not done in the best possible way, but meanwhile I’m interested in your views. What have you seen go wrong with EVM rollouts in the organisations where you have worked? Let us know in the comments!

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

I get it – if you don’t use earned value on your projects, you might be wondering what you can takeaway from The Practice Standard for Earned Value.

That was my view too, having never worked on a project where earned value was a necessary part of how we measured performance. However, there are lots of project tracking and performance management tips you can pick up from the standard. As with all things project management, tailoring is the answer. You can choose to apply some of the tools and techniques from the EV canon and ignore the ones that don’t work for you (like last month’s dive into creating the performance measurement baseline, which I can’t imagine doing unless the project/client demanded it).

The process we are looking at today is Analyse Project Performance. Unsurprisingly, as you can tell from the name, it’s the process of comparing what we said we would do to what has actually happened, with a view to understanding the current status and taking corrective action where appropriate.

You’ll need to do this regardless of whether you use EV on your project or not – admittedly, you won’t have a performance management baseline to use if you aren’t in an EV environment, but part of project management for any type and size of project is doing that comparison and making adjustments accordingly.

We do that so we can capitalise on opportunities, mitigate against variances, take action and keep the project on track, as well as predict where we are going to end up if things continue as they are.

Top tip: These analyses are best done by EVM software. These days, when tools are so advanced and the state of project management tech is so good, there’s no need to work out variances by hand. Reduce the likelihood of human error and draw on your IT systems to do all this analysis for you.

Inputs

There are just two inputs to this process:

The project management plan – in particular, the performance measurement baseline that was put together in the previous step. There will be other bits of the plan that are useful as well, like variance thresholds if they are documented (they should be)

Work performance information – because you use this to compare to the plan and see if you are where you thought you would be.

Work performance information in this process is more than simply asking people what they’ve done or taking a look at timesheets. This is where the maths part of EV kicks in: you’re looking at planned value, earned value, actual cost and budget at completion, those staple calculations of an EV management system.

I could write whole articles about those formula, so I won’t go into detail about those. For now, know that you’ll need to get project performance data from your software tools and know how to interpret the formula.

What to do

So what does it look like to work through this process and analyse project performance?

We can break it down a bit.

What you’re doing is looking at the variances and performance indices. Look at schedule and cost variance, and work out the schedule performance index, cost performance index and the to complete performance index.

When I say ‘work out’, I mean (hopefully) press a button in your software and get a report that does the maths for you, presenting you with an easy-to-read dashboard or data sheet that gives you the information. You can work it all out by hand, and it’s really helpful to know how to work out the formulas and what they are for, but over in the real world, let’s rely on software tools to speed things up.

The indices will tell you if you are ahead or behind schedule and budget.

That’s good to know, but alone, it’s not really very helpful. We also need to do some forecasting.

What that means is we use the EV data to forecast performance forward, giving us information about what things will look like when the project is complete. Again, that’s useful data to help stakeholders understand how the project is going and what actions might be necessary to address any variances.

Estimate to complete, estimate at completion, variance at completion and the to complete index are the useful formula here.

Finally, you can look at percentage comparisons and trend analysis to help you work out what might happen in the future given past performance. It’s all useful data, but the key thing that jumps out at me is that there is no narrative; no context. You’ll need to add the story to help people understand the ‘why’.

Outputs

The outputs from this process are:

Performance measurement methods

Funding forecasts and trends

Correct and preventive actions – what to do once you’ve deciphered the information and worked out what that means for you.

Typically, you’ll be looking at graphs and tables, and a lot of numbers. What’s really important is that whoever is looking at the numbers understands what they are looking at, what they represent and what they mean for the project. That might mean doing some team training about EV so that everyone starts from the same common language.

There is a ton of detail in The Practice Standard along with a worked example, so if some of these terms don’t mean much to you, or you want to see some ‘real’ graphs that explain what all this is about, I highly recommend checking out the standard for a more in-depth explanation of this process, because most of what we typically think of as EV is this step.

This is the time in the process where you compare planned performance (the performance measurement baseline) to current performance. Some variance is to be expected because life happens and changes are part of managing the work. However, the management skill is in balancing the work to address any variances and bring the project back within metrics to show it is in control.

Next time, I’ll be diving into the next process in the earned value management standard, which is maintaining the performance measurement baseline.

Pin for later reading

I get it – if you don’t use earned value on your projects, you might be wondering what you can takeaway from The Practice Standard for Earned Value.

That was my view too, having never worked on a project where earned value was a necessary part of how we measured performance. However, there are lots of project tracking and performance management tips you can pick up from the standard. As with all things project management, tailoring is the answer. You can choose to apply some of the tools and techniques from the EV canon and ignore the ones that don’t work for you (like last month’s dive into creating the performance measurement baseline, which I can’t imagine doing unless the project/client demanded it).

The process we are looking at today is Analyse Project Performance. Unsurprisingly, as you can tell from the name, it’s the process of comparing what we said we would do to what has actually happened, with a view to understanding the current status and taking corrective action where appropriate.

You’ll need to do this regardless of whether you use EV on your project or not – admittedly, you won’t have a performance management baseline to use if you aren’t in an EV environment, but part of project management for any type and size of project is doing that comparison and making adjustments accordingly.

We do that so we can capitalise on opportunities, mitigate against variances, take action and keep the project on track, as well as predict where we are going to end up if things continue as they are.

Top tip: These analyses are best done by EVM software. These days, when tools are so advanced and the state of project management tech is so good, there’s no need to work out variances by hand. Reduce the likelihood of human error and draw on your IT systems to do all this analysis for you.

Inputs

There are just two inputs to this process:

The project management plan – in particular, the performance measurement baseline that was put together in the previous step. There will be other bits of the plan that are useful as well, like variance thresholds if they are documented (they should be)

Work performance information – because you use this to compare to the plan and see if you are where you thought you would be.

Work performance information in this process is more than simply asking people what they’ve done or taking a look at timesheets. This is where the maths part of EV kicks in: you’re looking at planned value, earned value, actual cost and budget at completion, those staple calculations of an EV management system.

I could write whole articles about those formula, so I won’t go into detail about those. For now, know that you’ll need to get project performance data from your software tools and know how to interpret the formula.

What to do

So what does it look like to work through this process and analyse project performance?

We can break it down a bit.

What you’re doing is looking at the variances and performance indices. Look at schedule and cost variance, and work out the schedule performance index, cost performance index and the to complete performance index.

When I say ‘work out’, I mean (hopefully) press a button in your software and get a report that does the maths for you, presenting you with an easy-to-read dashboard or data sheet that gives you the information. You can work it all out by hand, and it’s really helpful to know how to work out the formulas and what they are for, but over in the real world, let’s rely on software tools to speed things up.

The indices will tell you if you are ahead or behind schedule and budget.

That’s good to know, but alone, it’s not really very helpful. We also need to do some forecasting.

What that means is we use the EV data to forecast performance forward, giving us information about what things will look like when the project is complete. Again, that’s useful data to help stakeholders understand how the project is going and what actions might be necessary to address any variances.

Estimate to complete, estimate at completion, variance at completion and the to complete index are the useful formula here.

Finally, you can look at percentage comparisons and trend analysis to help you work out what might happen in the future given past performance. It’s all useful data, but the key thing that jumps out at me is that there is no narrative; no context. You’ll need to add the story to help people understand the ‘why’.

Outputs

The outputs from this process are:

• Performance measurement methods
• Funding forecasts and trends
• Correct and preventive actions – what to do once you’ve deciphered the information and worked out what that means for you.

Typically, you’ll be looking at graphs and tables, and a lot of numbers. What’s really important is that whoever is looking at the numbers understands what they are looking at, what they represent and what they mean for the project. That might mean doing some team training about EV so that everyone starts from the same common language.

There is a ton of detail in The Practice Standard along with a worked example, so if some of these terms don’t mean much to you, or you want to see some ‘real’ graphs that explain what all this is about, I highly recommend checking out the standard for a more in-depth explanation of this process, because most of what we typically think of as EV is this step.

This is the time in the process where you compare planned performance (the performance measurement baseline) to current performance. Some variance is to be expected because life happens and changes are part of managing the work. However, the management skill is in balancing the work to address any variances and bring the project back within metrics to show it is in control.

Next time, I’ll be diving into the next process in the earned value management standard, which is maintaining the performance measurement baseline.

Pin for later reading