The Money Files

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

Given the type of work that normally happens in an agile project – yes, we’re talking IT development – it’s common that the largest overhead is normally the team. People cost money because we have to pay their salaries. All the while they are tied up on a project they aren’t doing other projects. Those other projects could be more valuable to the organization. So it does matter how people spend their time.

If you are asked to cut the time of an agile deployment, how can you do it? If we’re focusing on staff costs, there are two main ways: increasing velocity (i.e. working more efficiently and doing more in less time) or decreasing scope (i.e. doing less so you finish earlier).

The infographic below shares a bit more about these two options.

What are your top tips for cutting costs in an agile project without cutting quality? Are there other techniques you use? Share them in the comments below!

Poor risk management can impact your project and massively affect your business more broadly as well. In this video, I discuss 3 impacts of less-than-optimal risk management which you might not have considered:

1. Poor user adoption
2. Not getting the full business case benefits
3. Delays to delivery.

Interested in finding out why risk management can affect those areas of your project and what you can do about them? There’s more in the video!

You can switch subtitles on if you are in a place where you can’t have the sound up or have other reasons to want to use closed captioning: Simply click the little icon at the bottom of the video that looks like a square with dots in, and the subtitles will automagically appear for you.

Pin for later reading

If you’ve been following along with my monthly dive into The Practice Standard for Earned Value, you’ll know that I’ve been picking up a lot of tips along the way.

I’ll be honest – I don’t work on projects that use EV. However, that’s not to say that I can’t learn from the standard, and pick out things that apply to my non-EV projects. For example, last month I looked at the process around performance measurement methods, and it was good to refresh myself on different ways of tracking progress like discrete effort, apportioned effort and level of effort.

Those are tools I can use to think about progress tracking on any project, because you should know how you are going to measure success before you start, regardless of whether EV is part of your toolkit or not.

The Establish Performance Measurement Baseline is where we take all the scope, schedule and cost baseline info and blend it all together to create an integrated baseline from which to track performance.

It’s the guide against which we’ll measure ourselves and our project to ensure we are on track. I said last time that performance measurement methods was the most important part of the whole EV journey – now I’m not so sure. This integrated baseline is the starting point for project control, and what can we do if we don’t have that?

Perhaps I need to rethink my priorities and put this baseline at the top of the tree for EV components. (In reality, it’s all important, I guess.)

Inputs

There are four inputs to this process:

• Scope baseline (includes an approved version of the scope statement, WBS and WBS dictionary – basically, the full set of signed off scope docs)
• Integrated Master Schedule (we made this a few processes ago)
• Project budget
• Risk register.

The first three are pretty obvious, but what is the risk register doing in there? Aha – it’s all part of a holistic, robust way of looking at the work. The project plan includes the tasks, but the risk register includes another set of tasks: your risk management activities that help you implement the risk responses (and the budget required for those).

EV is a truly rounded way of looking at project scheduling, so it’s important to acknowledge that if the team are off doing risk mitigation work (or trying to optimise for opportunity risk), they aren’t delivering tasks from the ‘main’ project schedule. And you need to account for that time and effort. And budget. So it’s important that your risk activity is taken into consideration for the baseline.

What to do

There is a lot of work to do to integrate everything. Let’s hope that in real life software can do a lot of the heavy lifting for you. However, the standard sets out the steps that need to happen, regardless of whether your IT tools can make short work of doing them.

First, the team integrates all the different elements together. Take the scope, the schedule, the cost baselines and blend them all together with the risk response plans. You might not have all the detail for the full duration of the project, so do what you can with what you have – the rest can be progressively elaborated later as you get closer to the deliverables and know more about what is expected.

Next, check you’ve got your project budget base and management reserve figures.

Finally, create the performance measurement baseline. Blend the schedule and budget information together. It’s a time-phased view of what needs to be done and how much it costs.

Outputs

The outputs from this process are:

• The performance measurement baseline – which you just created, so no surprise there
• Project funding requirements updates – you might have had to make some decisions about budgets as part of creating the baseline. If so, consider what impact that has on funding and what you need to update
• Project document updates – if you decided anything different to what was in your documents, or identified new risks etc, you might have some updates to do in a range of documents. This is pretty standard project management practice; just keep everything updated and you’ll be fine
• Revised contract decisions – if there are any
• Formal acceptance – this is important! You’re creating a shared understanding of what the project is doing and how you will measure progress. Everything needs to be aligned and there can only be one version of the truth, for clients, the internal team, budget-holders and senior leadership. That’s why the acceptance is important.

There’s a lot that goes into this step, and a lot more covered by the standard than I can fit in here, with regards to this process. Take the time to get this right because it shapes everything else to come and how reliable your reporting is going to be. Remember, that’s why we are doing all of this, because the reports from EV are helpful and let us course correct as soon as possible to give us more chance of completing the project on time, on budget and to the desired scope.

Next time, I’ll be looking at the next process in the earned value management standard, which is analysing project performance. Now we’ve created that baseline, the next step is to get the project going and track our work against it.

Pin for later reading