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

The Evolving Landscape of Benefits Realisation

5 Challenges of Integrating Sustainability into Project Plans

Challenges that arise from implementing alternative metrics

Stakeholders: how to improve engagement

How to reduce your project’s carbon footprint


accounting, agile, ai, appraisals, audit, Benchmarking, benefits, Benefits Management, Benefits Realization, books, budget, business case, carnival, case study, Change Management, checklist, collaboration tools, communication, competition, complex projects, config management, consultancy, contingency, contracts, corporate finance, Cost, cost, cost management, credit crunch, CRM, data, debate, delegating, digite, earned value, Energy and Utilities, Estimating, events, FAQ, financial management, forecasting, future, GDPR, general, green, Human Resources PM, insurance, interviews, it, IT Strategy, Leadership, measuring performance, merger, methods, metrics, multiple projects, negotiating, news, Olympics, organization, outsourcing, personal finance, pmi, PMO, portfolio management, presentations, process, procurement, productivity, Program Management, project closure, project data, project delivery, project testing, prototyping, qualifications, quality, records, recruitment, reports, requirements, research, resilience, resources, risk, ROI, salaries, Scheduling, scope, small projects, social media, software, Stakeholder, stakeholders, success factors, supplier management, team, Teams, timesheets, tips, training, transparency, trends, value management, vendors, video, virtual teams, workflow


What is BCF analysis?

Categories: productivity, Scheduling

You know all those baselines you save in Microsoft Project? All the snapshots of your plan you keep just in case? Well, they are hugely useful for looking at to compare actual performance against forecast, so dust them off and let’s start using them.

BCF stands for Baseline-Current-Future and it’s a way of looking at comparative schedules. As a schedule control tool, it’s easy to use, easy to understand, and it’s a useful way of discussing project progress and performance with the team without having to go full earned value.

Plus, it’s not much work for you as the project manager, as you probably already have the details available.

Here’s how to do it.

bcf analysis

The process

First, take the baseline Gantt chart. This will be the latest saved version of your Gantt chart that is an approved baseline. I know software tools can keep baselines saved in the software, but I do tend to keep a separate version of the whole file saved with the date in the filename, just so I have a back up of exactly how the plan looked at the point of the last official review.

You’ll also need an up-to-date position for what is happening right now, so if you don’t have team members entering data in real-time, you might have to give them some notice to get their data into the tool.

Then, you’ll need the future scheduled dates; what you anticipate the rest of the schedule will look like. This is your forecast, and will be the information in your schedule for the dates that haven’t yet happened. Just give them a quick review to make sure they are still accurate and reasonable before you take them as finalised for this exercise.

Compare the baseline against the current and future positions. You can do this with a table that shows the milestones, or a Gantt chart that shows the various different bars on the same chart so people can see slippages and changes.

Talk to the team

When you have prepared your analysis of the baseline and current/future position, circulate the comparison for discussion.


  • Does the future schedule look OK?
  • Do we understand why the dates have changed since we baselined the project?
  • What assumptions have we made and do these need to change now?
  • What future changes do we anticipate based on what we see about past performance?
  • Who else needs to be involved in this discussion?
  • What steps should we take next?

And anything else you think is helpful to ensure that the discussion is productive and you get what you want out of it – which should be increased confidence in your future scheduled dates.

You’ll probably find that there have been some changes that have not yet been reflected in the schedule. There might also be some interesting takeaways about why things changed. Feed these into the lessons learned documents – in fact, it might be valuable to have this discussion on scheduling as part of your pattern of retrospectives.

Schedule analysis is a useful tool to understand what happened and take from that some actions or learning that would help you do things differently in the future. In addition, it helps with being able to set expectations for stakeholders so they have the confidence that the schedule is deliverable and the team are onboard with what they need to do when.

What other tips do you have for using project baselines? Let us know in the comments!

Posted on: May 16, 2023 08:00 AM | Permalink | Comments (6)

3 Tips for when your to do list is full of important things

Have you got too much on your To Do list? What about the backlog – is everything in the ‘must do’ category? What about your project prioritisation process? How many projects are top priority, even when you’ve applied what should be reasonable and weighted criteria designed do rank projects based on importance?

Yes, I’ve been there. Everything is important and stakeholders want it all tomorrow.

We all know that isn’t possible, and in most cases, isn’t even desirable. Some of those ‘tomorrow’ dates will be totally arbitrary, and based on the shadow of a promise instead of fact-based, schedule-driven expectations.

But when a senior person asks you to do something, or your trying to guide the team through a prioritisation exercise, how can you manage all the things to do? Here are 3 tips for reframing your workload and helping stakeholders see what’s possible based on capacity and priority.

1. Go back to the ‘why’

What’s the benefit of doing the task, project or of delivering that feature? What’s the rationale behind it and the user impact? Think about how you can measure the success of the deliverable and what return it will provide. That doesn’t have to be a financial return, it could be a social impact return, customer satisfaction improvements or something else.

Understanding the reason for doing the task and what comes out the end of it will give you greater insight into priority. The project that has the largest return is normally worth doing over the project that has a small return. The automation task that you’ve been putting off setting up is going to free up resource time longer term, and that’s worth more to you than something tactical.

2. Yes, but…

When stakeholders are pushing for their tasks to be at the top of the list, ask for their help in prioritising. Say you can do the work, but at the expense of something else. What stops, or gets delivered later?

“Yes, I can take that on, but it means postponing delivering XYZ that you also asked for, until next week. Are you OK with that?”

“Yes, we can do that, but we’ve got a lot of other changes to work on first, so we won’t get to it until next month.”

The onus is on them to support the prioritisation effort, and it helps make them aware of the impact of juggling priorities – especially when their request impacts another stakeholder’s expectations.

3. Draw the line

One of the techniques we used in my old job was to maintain a list of changes and projects in priority order. We had a prioritisation model that everything was fed into, and the output was a ranked list of work.

Then we applied estimates to the work and reviewed the capacity of the team. That told us how much work we could take on as a department and what was next in line for when there was availability to pick up something else.

It was a spreadsheet, and it literally had a line under the work we could do. Everything under the line didn’t get worked on.

If someone expects their work to take priority, it needs to go through the prioritisation route. Sharing the list (and the line) with stakeholders helps them visualise why you can’t simply do it – even if it’s a small thing.

“Yes, that’s fine, it will take longer than normal to work its way through testing because of the volume of work the team has on at the moment. Oh, you need it sooner? Let me share the higher priority items with you if this takes precedence, so you can see what other stakeholder commitments we’d need to drop to do this more quickly. Perhaps you could talk to those stakeholders to agree the overall priorities? I’ll put a call in.”

What else do you do to help protect your time and prioritise your work? Let me know in the comments!

Posted on: March 14, 2023 09:00 AM | Permalink | Comments (2)

Programme Budgeting: Creating Schedules

Categories: budget, Scheduling

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:

  • The programme payment schedule
  • The component payment schedule.

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? 

Posted on: August 10, 2022 08:00 AM | Permalink | Comments (1)

5 Reasons to Crash Your Schedule [Video]

Your sponsor has asked you to get the work done faster… who hasn’t been in that situation?! That’s one reason why you may want to crash your project schedule, but there are others. In the past, I’ve written about 7 reasons to crash the schedule, and in this video, I pick out my top 5 to discuss in more detail. I talk about schedule compression (obviously), when part of the project has the potential to put the overall project at risk, when you’ve got a fixed deadline, when the team is needed for other work and when there’s a general delay which affects your ability to hit your expected deadlines. Crashing can help in all of those situations, used sensibly. Engage professional judgement before you go for it!

What are your thoughts on crashing? Personally, I try not to do it too often because it’s a lot of effort and it doesn’t always give you the results you were expecting, but it is a useful skill in the toolbox for predictive project managers, so it’s worth knowing when you would consider to use the technique.

Posted on: February 01, 2022 04:00 AM | Permalink | Comments (3)

Developing the Schedule in Earned Value Management

Categories: earned value, Scheduling

The Practice Standard for Earned Value sets out the Develop Schedule process, which is simply a way of turning all the stuff in your WBS into a workable plan with timescales. Basically, it’s time to turn the WBS into a Gantt chart.

I guess you could use earned value for non-Gantt chart scheduling, but I can’t get my head around how that would work (tell me in the comments if this is something you do!).

The Practice Standard doesn’t go into loads of detail about how to make a project schedule, as there are other places you can go for that information – like the Practice Standard for Scheduling and also the PMBOK® Guide. However, the particular earned value bits of scheduling are covered in the EV standard, and especially this process.


There are two inputs to this process:

  • The scope baseline
  • The resource breakdown structure.

The scope baseline is more than just the WBS. It also includes the scope statement and the WBS dictionary, so it’s the full set of documents about project scope and the full understanding of what the scope is. It’s the exact spec to a level of detail that allows someone in the team to get the work done.

The resource breakdown structure is the comprehensive guide to who is working on the project as well as the other, non-people, resources required to get the job done.

What to do

The Practice Standard is light on the ‘how to schedule’ element, as I mentioned above, but from a specifically EV perspective, here’s what to take into account:

  • Create the schedule in a scheduling tool.
  • Make sure dependencies are noted and accounted for, using the scheduling features of your tool
  • Manage the relationship with the budget by setting up whatever you need to in the system that will manage that relationship. This might mean setting up control accounts in your accounting software or however you are tracking the budget figures for the project.

This last part is particularly important because it’s the way the schedule and budget relate that drives the EV calculations. You need the same dates, milestones, assumptions and resources set up in each so the measurement is consistent between both systems. In other words, you need to be sure that the work being done is accurately accounted for so that you are working out the right planned value.

Finally, get your project schedule approved the normal way and it then becomes the schedule baseline, against which you can track progress and monitor performance.


The output for the Develop Schedule process is only the integrated master schedule, as you would expect.

The ‘master’ part of the IMS, as I understand it, is a way of referring to the fact this is the top level project schedule. The control account managers may have detailed sub-plans for their parts, and you might have intermediate level plans, depending on how complicated the project is. But the IMS – the master schedule – is the full picture of everything required to get the project done.

Dealing with changes

As with any aspect of project management, we have to allow and account for what happens when things change. It’s great to have the IMS as your overarching master schedule and performance measurement baseline, but it’s unrealistic to think that we’ll deliver everything perfectly to plan because that isn’t what happens in real life.

So, we need to use the change control process as and when needed, to make sure the whole thing stays aligned to actual performance. That’s not to say you’ll be re-baselining the project every day, but you will keep the schedule up to date with real progress to compare back to the original baseline, and then re-baseline if and when that becomes appropriate.

If you make schedule changes, you also need to consider what that means for the project budget. When using EVM, you can’t get away from the fact that the two need to align – that’s the point of this way of project tracking, after all.

The IMS exists as a way to outline what the team is planning to do and it gives you the logic for measuring performance. It’s important to get it as good as it can possibly be because it’s what future progress will be measured against and it’s used for calculating future outcomes – and you should want those to be as accurate as possible.

Next time, I’ll be looking at the next process in the earned value landscape, which is establishing the budget.

Pin for later reading

Posted on: April 20, 2021 07:00 AM | Permalink | Comments (3)

"I don't care to belong to a club that accepts people like me as members."

- Groucho Marx