The Planning performance domain in PMBOK 7 covers all things relevant to making sure the project is adequately planned. We want to address all the work required to deliver whatever the project is delivering, and to do so in an organised, thought-through way.
Planning for the financial aspects of your project is covered by this domain.
Budgeting is the obvious one: as part of putting together the early steps of getting our project off the ground, we need an idea of how much it is going to cost. That means taking info from the task and work estimates and using that to create a cost estimate.
Building out the cost baseline forms part of the project planning activity and then it’s used to track against. Project performance can be measured against the baseline, in the same way you do for tracking schedule activities. In fact, combine cost and time schedules help you phase the spending. Even if you don’t go ‘full EVM’, a phased budget is helpful for the finance team to manage cash flow and for the project team to track whether work is broadly happening at the expected pace.
Knowing how you are going to manage the finances is also useful and worth working out at this point. For example, how often are costs going to be reviewed? What contingency reserves are going to be put aside and how will the team access those? What’s the process for getting purchase orders raised and invoices approved for payment? Do you have access to a management reserve and if so, who is going to approve using that funding?
Most of my projects involve buying things from suppliers. Whether it’s something small or a multi-million pound deal, procurement activities are a big part of what we do.
It’s important to spend time in the project planning phase thinking through how procurements will be managed. Will you have a dedicated procurement professional to manage the contracts and run point with suppliers? Who is going to manage supplier relationships? What’s the process from choosing a supplier and negotiating a price to actually getting the contract signed off and the order raised? I know from personal experience that this process is easier said than done!
If you have someone managing the contracts on your projects, they will need to know what the project needs to buy, when the team needs it for, what the lead times are likely to be and a lot more. Given that at the moment the lead times on all kinds of equipment and building materials seems to be extending – our own build project at home has been delayed – and the price of materials is rising – it’s really important to be all over the numbers, process and plan for this aspect of your project.
There’s more to the Planning domain than simply thinking about the money and contractor relationships, but these aspects are essential if your project involves procurement work. It’s all too easy to get sucked into scope discussions and deadlines and milestones – because executives want to know when the project will get delivered, not who in Finance is going to be processing the requisitions.
So this is just your friendly reminder to make sure you allow adequate time in the planning stages of your project to factor in the finance planning – and that it’s an ongoing activity for each stage, and as your project evolves.
Programmes (as we spell program here in the UK), are made up of various different projects and often BAU elements or non-project components too. The programme budget needs to reflect two things.
First, it should include all the costs relating to the components. These could come from detailed project budgets, contracts and the work involved in costing out the deliverables, outcomes and outputs that make up the programme overall. This aspect is going to make up most of the budget.
Second, it should include the costs involved in running the programme. These are most likely to be resource costs and any other operational support costs such as the fees involved with hiring a location to work from during the programme and things like that. This aspect is a not insignificant amount but in my experience it’s normally less than the costs of the projects.
The exact split of component costs and programme management overheads is going to depend on your exact project and how you account for people’s time.
The two schedules that come out of the cost budgeting for a programme are:
These two terms sound very similar so let’s briefly look at what they mean.
The programme payment schedule is about money in. It relates to the dates and milestones where funding will be made available. These could be payments from the client, or your internal decision points or gates where funding will be released for the next phase of work.
The component payment schedule is about money out. It relates to when contractors, sub-contractors and suppliers are going to be paid. I see it as a summary of the contractual payment dates as most of my supplier contracts for large projects in the past have a milestone-driven payment schedule. When the milestone is reached and signed off, the payment can be made to the vendor.
The milestones tend to be linked to delivery e.g. completion of design, delivery of functionality etc. When a component is completed, the component-related budget can be closed off.
Both of these schedules provide info to the programme budget baseline. The baseline will need to be revisited regularly if my experience is anything to go by. Prepare a forecast, review the estimates and actuals, and update as and when you need to, with the approval of whatever governance processes you have in place.
Then make sure any changes are trickled through to the relevant budget lines, and any other documentation is updated.
The programme and component schedules might be called schedules, but they aren’t the same as your main programme (or project) schedule. That represents the timeline of work; what we often call the project plan (even though technically speaking it is not the project plan – that’s a separate document made up of lots of plans…).
The budget-related schedules are timelines in their own right, and you could put the milestones or key dates into your main schedule. Personally, I think that’s confusing, but it’s up to you. I prefer to put payment dates in my normal calendar, with a note the week or so before to make sure I have the paperwork in place to get the milestone approved.
I also use that early warning action to let Finance know that a big payment will be due, and the supplier’s sizeable invoice will be coming through for payment. Having once been caught out by trying to get a large invoice paid at short notice, I’ve learned the lesson of giving my colleagues in Finance plenty of time for their approvals and related Treasury tasks.
Do you have any other tips for managing the different aspects of a programme budget?
The Standard for Program Management (Fourth Edition) talks about how to track program financial metrics once your financial management plan is up and running. I thought it would be worth comparing the guidance to what I’ve done as a program manager to see how I measure up – and you can compare your own practice to what’s in the Standard too.
Program financial management, as a refresher, is defined in the Standard as:
Activities related to identifying the program’s financial sources and resources, integrating the budgets of the program components, developing the overall budget for the program, and controlling costs during the program.
Once you’ve got the program going, your work as a program manager shifts to tracking the money and making sure you are on track.
Spoiler alert: I’ve never used earned value to do this in real life, although I’m well aware of the benefits of doing so on projects and programs.
I think the techniques you use for tracking very much rely on your organisational culture and maturity levels, and I’ve not worked anywhere where EV is considered part of the way things were done. If you’ve got experience working in an EV environment, let me know how that goes in the comments.
The program manager’s role shifts to monitoring spending and controlling spending, ensuring what is being paid out is in line with the budget. In my experience, as a program manager, I’ve had a fair amount of latitude to move money between ‘pots’ (or projects) to ensure the overall goals of the program are met. And I have to say, I’ve enjoyed being able to make those decisions.
What I haven’t enjoyed is the financial scrutiny. I know we need governance on programs, and I’m all for it, but sitting in a meeting having to present the numbers has always been uncomfortable for me. Not because I don’t believe in the numbers, but because I’m normally presenting to people with an accounting background and honestly they could dance rings around me if they wanted to pick holes in my maths. So I have to put extra effort into making sure I can justify how numbers are put together.
My top tip is to make sure you keep detailed records of how you came to land on certain figures. For example, on a program I’m working on at the moment, we track committed spend, forecast and then actual “out-the-door” spend. But there are a couple of other strands within the program that are accounted for separately (don’t ask, it’s just the way it works best) so I have to make sure I’m clear as to what’s in and what’s out of the numbers so I can justify them every month and make sure we are reporting to the PMO on a consistent basis.
Because trust me, if I didn’t, I’d forget from month to month what the basis of calculation was and report something that wasn’t internally consistent and that I couldn’t justify reliably. Which would be bad.
Governance serves a purpose: it makes sure that a program is operating within approved cost limits and challenges programs that are forecasted to go out of those budget targets. Then the organisation can decide if it wants to continue with the program or not.
I’ve luckily never worked on a program that has been cancelled because of financial issues – but I imagine that is largely luck and the kind of programs I have been involved with rather than any skilful cost management on my part.
My experience of program cost management has been very similar to managing large project budgets: the skills are the same, and business acumen comes into play too. I think that having the bigger picture and goals in mind helps. What do you think?
James Lea, founder of Project Science, spoke at EVA 26 earlier this year. He talked about the psychology of estimating. “People,” he said, “are just as important as the techniques and data.”
He went on: “Plans and estimates are built by and used by people. Psychology matters.”
The talk was very interesting, and here’s what I took from it.
He started by asking us our experiences of estimating and the emotional responses we had at the time. Think about your own experience of estimating. Did you feel:
That’s all (unfortunately) normal, and we all nodded along as he talked.
Challenge how will estimates be used
James talked about how we should challenge how estimates should be used. “Uncertainty drives variable reactions in our teams,” he said. “It drives emotions and responses.” If you are open about how estimates are going to be used and how they should be used, that can help people feel more comfortable with the process.
Make estimating positive
How can we enable our teams to experience planning and estimating as a positive, creative experience? Instead of the stressful, “I suppose I can give you a number,” experience that it is mostly?
It’s hard for an organisation to accept that it doesn’t know the answer, and that can sometimes lead to a poor experience of the estimating process for the people involved.
Here are some ways he suggested we could turn the experience into a positive one:
Creating a route to predict the future
James talked about asking the question about whether we have a route to predict whether the estimate is a robust one or not. We need to understand what is in and out of our control. Where things are out of our control, accept that and track it.
Estimates are only a guess without a map of how you got there and a set of viable routes.
We often hear that people can’t estimate where there is no historical data. Well, data science should make it easier now to estimate from past performance and the vast tracts of data we store about projects. If leaders can give teams the data, in a way that helps with estimating, that should make our estimates better.
Building defensible plans
James talked about showing your workings and documenting the bases of estimates. Steve Wake, the conference chair, shared his thoughts too, namely that the audit office regularly says people don’t know the basis of estimate and therefore the best ‘proof’ that your estimates are good is that you can justify them.
He talked about bounding your plans carefully, describing the world around the estimate as well as the estimate itself to provide rigour.
He suggested we quantify and compare with data science, applying risk appetite to the delivery methodology to round out what we know.
That, and the other points discussed, are ways to shape the emotional response and create a safe space for people to estimate their work.
What do you think? Let me know in the comments below.
At the EVA conference in London in March, I had the pleasure of listening to Gary Hill, Co-chair of PsACE, the Public Sector Advisory Community for Estimating. He was talking about the importance of estimating and how the community helps shape the professional estimating done on public sector projects in the UK.
The purpose of the group is to simplify, standardise, systemise and professional project estimating process and capability across the public sector. He shared their vision, which is to bring together experts across government and client organisations to promote leading practice in estimating, underpinned by an ethos of trust and collaboration. I like how he talked about leading practice instead of ‘best practice’ because as we all know, there isn’t one definitive best practice for pretty much anything in project management.
He talked about how the community started in April 2019 when someone reached out to him and asked for help with something. “It started over coffee and turned into a beer,” he joked. The community sets out to address the problem that many project managers have in all aspects of our work: where do you go for advice, how do you know if that advice is any good and who says it’s good anyway?
To find out where good practice was in the public sector the community carried out a benchmark of 7 government departments where they measured good practice. Surprise, surprise, no department was good at everything.
Today, the community is sponsored by IPA, the Infrastructure and Projects Authority, which Gary said gives the community’s work more weight and more chance of making things stick. They really started to gain traction when they were mentioned in a government select community discussion, and membership started to grow.
It’s a volunteer-led community and Gary shared the common problem that many volunteer-led communities have: everyone wants to get involved because it’s a good idea, but everyone has a day job to do so it’s hard to get people to take on jobs.
Next up on the agenda for PsACE is to write to each permanent secretary in the UK government and ask them to support the community’s work, so that’s a large piece of stakeholder engagement to do.
In terms of what they actually do, Gary explained that PsACE was involved in providing input to the IPA estimating guide, and was represented on the committee preparing British Standard 202002 for Project Controls.
There are current workstreams covering: