The Money Files

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

We all know that in agile methods, time is time-boxed. Iterations are the way work is managed. Time is fixed. But does that mean you don’t need to spend any effort thinking about time management? Not at all.

There are a number of different agile artifacts that influence and shape the project team’s approach to managing time on the project. They start with the product roadmap and get progressively more and more granular until you end up at the sprint backlog. If we’re talking sprints, we’re talking Scrum, but you can see how this approach is relevant for other agile methods too.

While there is a lot of flexibility in the ‘what’ in agile, the ‘when’ is pretty strictly controlled.

What are your top tips for managing time on agile projects? Do you use any other artifacts to help the team stay on track? Share them in the comments below!

Risk management processes affect more than simply risk. Or rather, the impact of project risk management runs far deeper than just helping you plan for what might happen. There are lots of other reasons to do risk management too – and in this video I’m exploring 3 more reasons why you might want to take a bit more time to do risk management because poor risk management has consequences.

The topics discussed in today’s video are:

1. The impact of risk on managing budget overspends
2. How risk management can mitigate against unhappy stakeholders
3. And how risk management can address issues of reputation management.

Watch the video for more on these! Hopefully it’s a slightly different way of thinking about the value of doing risk management, and something you can get your stakeholders to buy into.

For more on this topic, check out last time’s video where I looked at another 3 impacts of risk management on the wider business.

Pin for later reading

The UK Government’s Infrastructure and Projects Authority has released some cost estimating guidance as a best practice approach for infrastructure projects and programmes. It’s actually pretty interesting, and very easy to see how it translates to smaller projects as well. Despite the picture on the front being clearly of a major construction site, there’s plenty in here that would apply to any project.

One of the principles I found interesting was the idea of front-end loading. The guidance says:

Robust planning, design and preparation in the early stages of a project’s lifecycle are essential in driving successful delivery.

Can’t disagree with that.

Front-end loading isn’t about front-loading cost. You don’t have to plan to spend early in the project (unless that is the right thing to do). Instead, it’s all about making sure there is a robust and sensible approach to planning for spending.

I think the point of this principle is to make it clear that planning is important – just in case any stakeholders want the work to start straightaway. The more effort you put into planning upfront, the more likely it is that you’ll be able to hit those plans.

The first initial period of the project is crucial because it’s all about setting objectives, choosing a solution and building a set of requirements that everyone agrees on. You can’t create accurate cost forecasts based on misconceptions and no clear idea about what the project is actually supposed to deliver. (And the same goes for time estimates too.)

Plus there’s that much-used theory of the cost of change: it’s easier and cheaper to make changes early. By the time you get to the end of the project, so much has already been completed that doing a change can be very difficult and costly.

The more you know about a project, the less likely it is that there will be major changes later on. Of course, you can’t ever predict the future, but on a large capital build project, I expect there is a degree of certainty once the base requirements have been nailed down.

Getting external stakeholders involved at this time is also helpful. They can provide information for assumptions, help identify constraints, and basically give you a lot of data that could help form better estimates.

The guidance talks about making sure that uncertainty in estimates is identified so it can be removed, and that’s part of what you are doing in this step. It’s fine to not have all the detail and to create a broad-brush budget during the early stages, but ultimately you are going to have to refine estimates later.

If an estimate includes a degree of uncertainty, identifying that early helps you work to remove the risk. You can build risk mitigation into the plans and as soon as risk is removed (or managed to the level considered appropriate) that gives you more information to refine the estimates.

Interestingly, the guidance talks about an expectation that 3% to 5% of the project’s total cost is expected to be spent before work begins – specifically construction work, but I suppose we could extrapolate that to any project.

The IPA blog talks about projects that have a focus on front-end loading seeing savings of up to 20% on budget and being delivered 10-15% faster. That’s quite a statement to pass to a sponsor who just wants you to get going!

This initial burst of funding is for the planning and initiation phase. It gives you permission to spend some money and time before you really get going, just so you can work out what needs to be done. It might feel counter-intuitive to spend the project’s budget before the budget is really approved, but that’s no different to the concept of building a prototype or doing a pilot before committing the rest of the time and money to a larger piece of work.

The implications for other projects

If you don’t do a good job of front-loading effort and planning, you might end up working on the wrong projects. Put the time into a business case and decent estimating, and you get a lot of information about project viability. What might have looked good at the high level might be less attractive once you’ve gone to the next level of detail.

How do you feel about front-loading? I tend to do this as much as possible, but I do know from my mentoring clients and the project managers I talk to that there is often quite a lot of push back from executives who don’t consider planning to be that important. Let me know in the comments about how you handle it!

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