Project Management

The Money Files

A blog that looks at all aspects of project and program finances from budgets, estimating and accounting to getting a pay rise and managing contracts. Written by Elizabeth Harrin from

About this Blog


Recent Posts

3 Ways To Be More Strategic As a Project Manager

Introducing The Public Sector Advisory Community for Estimating

Setting Up Programme Budget Tracking

Quick Tips for the Testing Phase

Programme Management: Planning Your Finances

3 Ways To Be More Strategic As a Project Manager

Strategic thinking is one of those skills that gets tossed around as something project managers should have. But how can you be more strategic in a practical way? I’ve been thinking a lot about this recently, and here are 3 things I think you can do as a project manager or leader of a project delivery function to try to bring more of the ‘strategic’ into the way you work.

1. Get involved with business cases and proposals

First, lobby to get involved with business cases and proposals. The more delivery expertise we have involved in the initial stages of a project, the more likely it is that the project will be able to actually hit its goals.

Have you ever been involved with a project where you’ve been handed something to do and the sales people have made promises that you can’t deliver on? Then you’ll know what I mean!

When project people are involved in business cases, in my experience you’re more likely to end up with a timescale that’s achievable and a resource plan that reflects the real amount of resources likely to be consumed by the work.

It’s even better if you can lobby for a seat at the table when the 3-year plans are being drawn up, so your top level project people, like the Head of PMO, get involved in creating the strategy in the first place. That provides a real insight into what initiatives are coming and how the delivery teams can help.

2. Use the project assurance function as a check mechanism

Project assurance is a way of checking that what you think you can do is actually achievable. It’s their job to pick apart your plans and proposals and apply a sense of real-world pragmatism. They can also help identify whether there are any resource gaps, strategic holes or other issues that you haven’t seen.

After all, as a project manager I’m sometimes so close to the information that I can’t see the bigger picture enough to realise that this project will clash with something that someone else is working on – but project assurance has the bigger picture and can point that out.

If you don’t have a project assurance function, ask a colleague for their opinion and talk them through the plans, asking them to basically pull them apart. Ideally, to be able to add some strategic oversight to your plans, this should happen around the time of the business case or PID. By the time you’ve got to creating a schedule you’ll be looking for a different kind of peer review.

3. Share what you know – but only what you know

My third tip is something I learned from Tony Meggs, Chief Executive of the Infrastructure and Projects Authority in quite an old article now that he wrote for Project magazine, but it has stuck with me. He said: Only announce what you know.

We know this in theory, so it’s not news to you, I’m sure. However, many project managers are ‘encouraged’ to share dates before we are ready, or pushed into committing to dates publicly before we have all the information to support the fact we can deliver to them.

So, if you want to be a strategic operator, only share what you know to be achievable. That goes for delivery methodologies as well. Meggs talked in the article about not committing to anything unless you know it to be true, including how the work would be delivered. If you are going to partner with someone and there’s a robust contract in place, by all means announce it. But don’t announce your intentions before they are fixed in stone because if it doesn’t happen you’re then having to walk back on the messaging and that can be damaging.

We can do this as project managers on a small scale, by giving our teams the space to come up with the best methods and timescales before we announce them to sponsors, but also on a strategic level, by ensuring there is a communications plan in place that supports the bigger picture messaging for the project, programme or even the portfolio.

Do you do any of these already? How are they working out for you? Let us know in the comments!

Posted on: May 17, 2022 04:00 AM | Permalink | Comments (2)

The role of the CCB

Do you have a formal Change Control Board (CCB)? If not, this is the perfect time of year to be thinking about levelling up your processes and putting new ways of working in place to formalise the way change management is done across projects, programmes and the portfolio.

A Change Control Board is simply a group of experts that represent different organisational departments and who oversee both the process of change management and the different changes being put forward.

At a project level, your CCB is a group of people who know the project well and who can assess project-related changes, but at some point if your project is making changes to the live environment, like most IT and business change projects do, the change will need to be submitted to the wider, department or organisational CCB.

The role of the CCB is to:

  • Assess the change
  • Approve the change – in my experience, if the project team and project sponsor has already approved the change, there are few reasons why the CCB would then block a change
  • Schedule the change
  • Keep records about changes.

How it works

In our CCB, the functional lead or the project manager had to present the change. We had to talk about what it was, why it was useful and what it solved, and then make the case for whether it was a priority fix or not. If the change was considered a priority, it could go in the same day (mostly). If it wasn’t, it could be packaged up with a bunch of other small changes and go in the next release.

That made it easier to communicate changes to the end users.

Discussing the change

First, the change should be analyzed and discussed to see whether it has impacts beyond what the project team can comment on. The 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 it’s important that the CCB is made up of a cross-organisation group. It’s too common for changes (especially IT changes) to go in and for there not be a full understanding of the business impact somewhere else down the line. Complex ERP systems like SAP make that more likely, so a group of functional consultants getting together to discuss changes before they happen is a good thing.

I’ve had some changes rejected by the CCB because they didn’t have enough information to make an informed decision, or because something else was going on and they needed to wait on that, or because there was a change freeze. There might be many reasons why your change doesn’t go through.

Scheduling changes

The CCB can also schedule changes. There are normally scheduled windows to put changes in, especially in the live IT environment. That helps the support teams and the users know what is going to be different and what to look out for when they next log in.

Scheduling as a team also ensures that conflicting changes don’t get put in on top of each other. For example, if my project is updating the list of available categories in one part of the system, and another team is also updating that part of the system but taking away the category feature (that’s a bit extreme, but you see what I mean) then those conflicting changes can be discussed and overseen in an appropriate way.

It might involve putting them live in a particular order, or prioritising the changes so that one piece goes in this time and the additional change is put in next time.

I remember being told a story of a change in a data centre where engineers were working on cabling and flooring on both sides of a server stack. Without the support of flooring on both sides, the server stack toppled over! That’s the importance of making sure that changes are managed in a scheduled and sensible way.

We also had an emergency change procedure for anything that could not wait until the next release. On the SAP projects, for example, mostly things could be scheduled in a batch and changes pushed through on a fortnightly basis. But sometimes it was important to fix an issue straightaway without waiting until the next release. For example:

  • Bug fixes
  • Issues that affected customers
  • Changes that went in and then didn’t work as expected.

All of these are emergency fixes to live systems that wouldn’t be appropriate to delay, and they are all issue-related, not nice-to-have features.

How does your CCB work?

Posted on: February 15, 2022 04:00 AM | Permalink | Comments (2)

Who gets involved in project contracts? [Infographic]

Q1 tends to be a time when new budgets are approved and that means we’re starting to see requests for contracts with suppliers trickle through the PMO. It always takes a few weeks for budgets to get released, even if the intention is to start the work in January. By February, project teams are ready to get started, knowing that any further delay in the admin is going to put pressure on their ability to deliver by the dates from the business case. And that’s why all the supplier agreements seem to be floating around at the moment.

The infographic below talks about the major groups/people involved in putting together and approving supplier contracts for new third parties, but it’s the same people involved in renewing deals and reviewing an existing supplier to see if we want to give them more work.

 As with any internal process, this is probably a bit specific to certain environments and types of contract, and you might not see all of these roles in your business.

Equally, there might be some other key positions that have a part to play – I know that in one set of contract negotiations for a multi-million software project, my project sponsor attended every conversation, along with the technical architect. And just as well they did too: it created a great sense of common purpose and everyone was on the same page from the beginning.

Take the suggestions below as a starting point for opening up the conversation with your colleagues if you are creating new supplier agreements, so you can make sure the right people are involved from the start.

Read more about who gets involved in contracts.

Posted on: February 08, 2022 04:00 AM | Permalink | Comments (2)

3 Barriers to Effective Benefits Management [Video]

Benefits realisation management is one of the hardest things to do in a project setting (in my opinion) and in this video I explain why. I talk about three things that make it harder and give you a few tips on what you can do instead to help get over some of the challenges. The three things are:

  • Low skill levels
  • Poor integration
  • Poor processes.

Watch the video below and then let me know whether you’ve seen any of these challenges in your organisation!

There is more detail in this article: 5 Barriers to Effective Benefit Realisation that draws on information from Carlos Serra’s PMI presentation on the topic.

Posted on: December 07, 2021 04:00 AM | Permalink | Comments (0)

Determining Measurement Methods in Earned Value Management

Categories: earned value, process

measurement methods

Reading The Practice Standard for Earned Value might not be everyone’s idea of a fun way to spend the afternoon, but I’ve been really trying to understand how EVM works in practice this year. Today, I’m diving into the Determine Measurement Methods process because it seems – to me, at least – that this is probably the most important part. How do we know what to measure and if we are doing it right?

I think EV management software probably takes a lot of the measurement heavy lifting off the project team, but you still have to know enough about what’s going on under the hood to be able to make intelligent, informed decisions and explain what you’re seeing to other people.

This process is where you choose the right method of performance measurement and progress evaluation for each of your work packages.

Who does this? You, as the project manager, should take an active role in leading on facilitating the process, with input from the control account manager who has the detailed knowledge of what measurements would actually work in practice.

In other words, you can’t be taking these decisions by yourself. As you aren’t the expert in doing the work or tracking the work, it’s someone else who has to tell you what’s reasonable for measurement. You can inform and support this, providing tips and ideas when they don’t know what to say, but ultimately I would prefer to be guided by the expert’s decision once we’ve discussed and agreed.


There are five inputs to this process:

  • Requirements documentation (paperwork like contract requirements, any technical and business requirements, non-functional requirements and so on)
  • Statement of work (this describes the outputs of the project)
  • 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.

These last two are the most important, in my view. You use the IMS and the budget together to create a phased view of how the money relates to the tasks. That’s the backbone of EV.

What to do

With those inputs on your desk, you’re good to go.

The task to do is to determine how you are going to measure progress for each work package.

There are a number of different ways to measure progress, and you can’t really rate them in order of priority or importance because they all have their pros and cons. It’s most important to choose one that relates closely to the work you are doing and will give you the most appropriate, most accurate way of understanding how the work is going.

Typically, you’ll end up choosing one of these:

  • Discrete effort (for tasks with a specific, measurable output)
  • Apportioned effort (for tasks that support tasks that can be measured by discrete effort e.g. the project management overhead for a project)
  • Level of effort (for tasks where the other types of measurement don’t really work).

You can choose whatever measurement approach works for you, the control account manager and the project, but it needs to be something tangible and documented so everyone can see what ‘progress’ means and how it is tracked. You have to be pretty sure about your approach because changing it halfway through the project when you realised you picked the wrong one is going to mess up your EV reporting.

So how do you decide?

Think about what the work is and what the most appropriate way of measuring it would be. For example, how long is the work going on for? You may choose weekly measurement instead of daily measurement if you’ve got to be tracking over a longer period of time.

How risky is the work? Do you need to be totally on top of it with detailed tracking hourly? For low risk tasks that wouldn’t be appropriate.

If your organisation has guidelines, then use them so projects can be compared.


The outputs from this process are:

  • Performance measurement methods – no surprise here, you’ve just created them
  • Control Account Plan updates.

So what are you doing when you update the control account plans? The documents are created already, and now all you have to do is drop in the performance measurement method that you’ve decided on.

You’ll also want to add in the period over which the progress is tracked, so is that weekly, monthly or some other time period. And what unit you are measuring in: hours, days, money, widgets created or anything else that makes sense for your project.

The point of this project is to come up with ways of tracking progress that are objective, accurate and timely. It sounds hard, but if you think about it, you’ll come up with some ways of measuring that work for you. And if you can’t, perhaps you need to be a little bit more creative or get some expert help in working out how to track – or perhaps EV isn’t appropriate for this project, if there are a lot of tasks that can’t be tracked in an objective way. Because if you can’t track it, you won’t be getting a lot of value out of the EV reporting, which rather defeats the purpose of setting up tracking mechanisms in the first place.

Remember, pick something sensible that works, that the control account manager can work with, and that is documented clearly so everyone knows how progress is being measured. That’s all this process is about. Hopefully, over time and with some experience, this part becomes standard and very easy, as you can lift parts of control account plans from other projects to use on this one.

Next time, I’ll be looking at the next process in the earned value management standard, which is establishing the performance measurement baseline.

Pin for later reading

Posted on: June 23, 2021 09:00 AM | Permalink | Comments (2)


Vendor Events

See all Vendor Events