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

Deep Dive: Project Scope Management Part 3: Define Scope

Make or Buy Decisions [Video]

The Project Manager’s Budget Checklist

3 Ways to Create a Project Budget [Video]

Deep Dive: Project Scope Management Part 2: Collect Requirements

Deep Dive: Project Scope Management Part 3: Define Scope

Categories: scope

define scopeIt’s time for part 3 of our journey through the Scope Management Knowledge Area from the PMBOK Guide®-- Sixth Edition. Today, we’re looking at the Define Scope process.

Check out the previous parts:

The Define Scope process happens early in the project so that everyone has clarity on what the project is supposed to deliver. Unclear scope means unclear expectations. And that nearly always leads to confusion, dissatisfaction and conflict on the team.

So take the time to actually define what is in and out of scope – that’s what this process is all about.

Define Scope Process

This is the third process in the Knowledge Area. We are still in the Planning process group.


The inputs have changed slightly from the Fifth Edition, but it doesn’t feel major. The inputs to this process are:

  • Project management plan – instead of the scope management plan.
  • Project charter – which was there before.
  • Project documents – again we see the generic terminology that can basically include anything about the project. In this case, we’re talking really about the assumptions log, requirements documentation and the risk registers, as there can be useful things included in there that need to be transferred to the project scope.
  • Enterprise environmental factors – this wasn’t there before and covers things like infrastructure that might affect what systems you can install, marketplace conditions, staffing and culture.
  • Organisational process assets – this was previously on the list so is not a change. It refers to items like historical information and lessons learned that could shape the scope, along with any internal relevant policies and procedures.

The objective of this process is to create the scope statement. You are trying to take the requirements from the previous process, prioritise and review them and make a final list of what you will actually be delivering as part of this process.

It is different from the Collect Requirements process because you may have collected requirements that you cannot deliver (or choose not to deliver) in this phase. The work that you are currently doing may not extend to all the requirements that were discussed and documented. You may have to prioritise what you can deliver.

It’s the final list of requirements, plus anything else that needs to be considered and included, that ends up as your scope statement.

Tools & Techniques

Not much has changed with tools and techniques. We have:

  • Expert judgment
  • Data analysis
  • Decision making
  • Interpersonal and team skills
  • Product analysis.

Alternatives generation and facilitated workshops have dropped off the list. However, interpersonal and team skills is pretty broad and would cover running a workshop, or any kind of meeting.

Data analysis is also a broader technique than what was there before. Alternatives generation is one way of analysing data, but not the only the option. We’re seeing throughout this refresh that the terminology, tools and techniques have got broader to allow for more tailoring and personalising. I’m of the opinion that’s a good thing.


There are no new or changed outputs to this process.

We still have the project scope statement and the project document updates.

The objective at the end of the process is to have a statement of scope. It should include what’s in scope, what’s specifically excluded from scope, and anything else you feel the need to document to ensure everyone is on the same page about what is going to be delivered.

Scope statements come in various formats, and while you’ll be able to find templates, and may even have one from your PMO, feel free to tweak and amend the document so it suits the needs of your project.

Aim for your scope statement to be really detailed, so that people can’t misinterpret what is going to be delivered. Think about what users, processes, tools, technologies, policies and so on are going to be impacted or changed as a result – and which ones won’t.

You can also include items for the scope of future phases (useful so they don’t get forgotten). However, these should be reviewed and revised at the point that the future phase is initiated, just in case the business has moved on and the scope items are no longer relevant.

Next time I’ll be looking at the fourth process in this Knowledge Area: Create WBS.

Pin for later reading:

project scope management define scope

Posted on: September 10, 2019 08:59 AM | Permalink | Comments (1)

Make or Buy Decisions [Video]

Categories: procurement

make or buy decisions

Your project needs things. But should you buy them, or make them yourself?

It’s a big decision, and one that affects lots of industries and deliverables. My experience has mainly been make or buy in the software world. Should we develop our own software, or buy a tool that is known to be best in class?

With software particularly, there are a lot of considerations. Cost. How easy it will be to interface any off the shelf product with your existing architecture. Supporting it once it’s built and installed. Managing upgrades. So many questions!

While this video doesn’t have all the answers, it might help clarify the big picture for you so you can start a confident conversation with your management team about the things you need to procure for your project.

For more information on project procurement and what you should be considering, check out this article.

Pin for later reading:

make or buy project management decisions

Posted on: September 06, 2019 01:24 PM | Permalink | Comments (2)

The Project Manager’s Budget Checklist

Categories: budget

budget checklist

I’m often asked: “What do I need to include in a budget?”

I figured it was time to put together a list of what should be included when you are putting together your project budget. So here goes…


Record any goods you need to buy. Record what you need to hire and the duration you’ll need it for. All these things should be in your procurement plan, so use that as a reference. Make sure you’ve put everything from your procurement plan into your budget.

Consumable supplies

Consumable supplies are different to equipment because they are things that get used up. For example:

  • Printer paper and toner
  • Food
  • Raw materials used in testing e.g. if you were manufacturing bricks, you’d need ‘test’ sand, concrete etc (I’m not actually sure what goes into a brick) and these would get used up during the test process.

Again, check the procurement plan to make sure that you’ve included everything you said you would need to buy.

Essentially, the difference between equipment and consumables is the difference between capex and opex.

External staff

Many projects rely on external resources, either from a manufacturer/supplier e.g. to help you install and set up new equipment, or as consultancy resource to do a particular skill e.g. requirements analysis.

Look at the equipment and supplies you need, and see if any of them have the requirement to rely on their own resource – if so, you will need to budget for the people to come with the goods.

Consider what services or skills are required, and whether or not you have them in house. If not, you should budget for buying in those skills e.g. test manager, specialist developer, auditor, health and safety expert, lawyer etc.

If you have to hire people from overseas, or have contractors who will charge in a different currency, read this article on how to manage multi-currency budgets.

Internal staff

Companies vary in how they account for internal staff. You may be expected to cross-charge a department for using internal resource on your project. Or you might be able to use the people “for free”. Check what your internal rules are.

Budgeting for internal staff is one of the hardest things to do on a project, in my opinion. You aren’t charged for their person at their salaried rate, so you’ll need to find out the appropriate charge to budget for.


Make sure your project budget includes applicable taxes at the relevant rate. Often, suppliers provide estimates without taxes included, and if you don’t increase the quote amount by the tax amount, you’ll find your budget is wrong.


Expenses relate to the costs for the people involved. Whether you are using internal staff, external staff or a mixture of both, they will likely incur some expenses for travel and accommodation. For example, if a supplier attends a meeting at your office, they will most likely charge for their travel to that destination, and hotel accommodation if they need to stay over, and meals.

Some companies also (or instead of) charge a ‘per diem’ which is a daily fee to offset incidentals that consultants away from home incur. It may include a meal allowance, newspaper, laundry etc, but instead of invoicing you directly for all of these incidental costs, the company charges you a flat rate per person per day.

Contingency/Risk management budget

Contingency funds are there to offset risk. Contingency planning can be in the form of time or money. Time also costs money, so either way, make your contingency explicit in the budget.

Management reserves

As well as contingency, it’s also worth including management reserves if you can. This is a figure put aside to deal with unknowns. However, you’ll also hear people refer to management reserves as the ‘contingency budget’ because sometimes they don’t know the difference, or because in their organisation, ‘contingency’ really does mean ‘money put aside in cases of emergency and we don’t know if we’ll use it up but it’s nice to have just in case.’

If you aren’t clear on the preferred jargon of your business, ask the question. Make sure you and your finance team (and sponsor) are talking about the same thing.

Read more about the difference between management reserves and contingency.

Watch this video for tips on how to reduce your project budget.

Pin for later reading:

budget checklist

Posted on: August 21, 2019 08:59 AM | Permalink | Comments (2)

3 Ways to Create a Project Budget [Video]

Categories: budget

create a project budget

My favourite way of creating a project budget is to first ask how much money I’ve got, and then go from there :)

I know it’s not the best way – or even the most ‘project management-y’ way – but sometimes it’s worth cutting to the bottom line and using that as a starting point. What a waste of time costing out a project beautifully only to have executives tell you to try again, and make the number 50% less. Let’s just start with where we are supposed to end up!

However, that’s only one way to create a budget, and, as I say, is hardly best practice. In this short video, we’ll look at 3 more reliable ways to build out your project costs so you can establish how much your project budget will be overall.

For more background on how to create a project budget, this article will help you get your thoughts together before you dive in.

Pin for later reading:

create a project budget

Posted on: August 14, 2019 08:59 AM | Permalink | Comments (4)

Deep Dive: Project Scope Management Part 2: Collect Requirements

Categories: scope

collect requirements

It’s time for part 2 of our journey through the Scope Management Knowledge Area from the PMBOK Guide®-- Sixth Edition. Today, it’s the turn of the Collect Requirements process. This process happens early in the project so that everyone has clarity on what the project is supposed to deliver. It also has the output of the requirements traceability matrix, which, if you are working on a project with many requirements and moving parts, is really helpful.

I’ve only used the matrix properly on one project – much of what I do doesn’t require a full traceability matrix. So don’t feel you have to use one if it will not make your life easier and add value to the whole process.

Collect Requirements Process

This is the second process in the Knowledge Area. The term ‘collect’ doesn’t sit very well with me. I know, from talking to business analyst friends, that the language has moved towards ‘eliciting’ requirements.

Requirements aren’t simply lying around waiting to be collected. There needs to be some active involvement in finding them, understanding them and collating them into a format and structure that can be used by the project team. You could argue that elicitation is only part of this process, but personally, I prefer to talk in the round about eliciting requirements.


The inputs have changed from the Fifth Edition, but not substantively. The inputs to this process are:

  • Project management plan (instead of the requirements management plan, scope management plan and stakeholder management plan, all of which are part of the larger project management plan.
  • Project charter (which was there before).
  • Project documents – nice and generic. Can include pretty much anything that could be useful for requirements elicitation but a starting point to look would be the lessons learned register, the stakeholder register and the assumptions log.
  • Business documents, which again covers a wide range of paperwork but PMI means the business case, I believe. As this is created outside of the formal project lifecycle i.e. before the project existed, it can’t technically be counted as a project document, but frankly I think that’s splitting hairs.
  • Agreement – contract-related project paperwork is, I think, what the PMBOK Guide® is getting at here. Any agreements you have would include requirements for products and/or the project management requirements.
  • Enterprise environmental factors (how did they manage to forget these the first time?) – covers things like infrastructure that might affect what systems you can install, culture and environment that the project needs to operate in.
  • Organisational process assets – covers things like historical information and lessons learned that could shape the requirements, along with any internal relevant policies and procedures.

The objective of this process is to create the requirements documentation – in other words, to arrive at a position whereby everyone has a clear understanding of the agreed project scope.

Tools & Techniques

While the list of tools and techniques looks quite different, I don’t think they are substantively different.

The new tools and techniques for the Sixth Edition are:

  • Expert judgment
  • Data gathering
  • Data analysis
  • Decision making
  • Data representation
  • Interpersonal and team skills
  • Context diagram
  • Prototypes.

Tools that have dropped off the list include:

  • Interviews
  • Focus groups
  • Facilitated workshops (all of which fit under interpersonal and team skills, with an overlap into expert judgment – you’d get an expert facilitator involved, for example, for a facilitated workshop)
  • Group creativity techniques
  • Group decision making techniques (which fits under ‘decision making’)
  • Questionnaires and surveys
  • Observations
  • Benchmarking
  • Document analysis (these last four fit under data gathering and analysis).

You can see why I think the lists are different, and yet… not really that different.

These are all things you can do to elicit requirements and gain consensus on what really should be in the scope of the project. You wouldn’t want to use them all, but you would pick and choose different tools and techniques to ensure you were making progress towards getting that final list.


There is nothing new in the outputs to this process.

At the end of working through this process, you’ll have the requirements documentation and the requirements traceability matrix prepared and written (and approved). There’s nothing formal that defines what format your requirements documentation should be in. I tend to use work package description documents, product breakdown structure documentation, and sometimes simply a list of bullet points. You could use user stories.

Your requirements paperwork can be as detailed and formal as you like. Do what’s required based on the level of commitment you seek to get and the need to be specific at this point in the project. Trends and tailoring is something we’ll come to at the end of this process, but remember it applies the whole way through – you can make the process as big or small, as simple or involved as you want to.

Next time I’ll be looking at the third process in this Knowledge Area: Define Scope.

Pin for later reading:

collect requirements

Posted on: August 08, 2019 08:59 AM | Permalink | Comments (6)

"My goal is simple. It is complete understanding of the universe, why it is as it is, and why it exists at all."

- Stephen Hawking



Vendor Events

See all Vendor Events