The Money Files

Every so often I do a roundup of questions that I’ve been asked, relating to the topic of this blog – project budgeting. Let’s dive in to some more of your questions about project budgeting!

What’s the best tool for managing your project budget?

It depends!

Unfortunately, there’s no simple answer to this. The answer depends on how your company expects budgeting to happen.

Many companies rely on Excel to track and report project budgeting. I have an Excel spreadsheet myself that tracks invoices and purchase orders, as well as current budget and forecast. We have a corporate template so all projects track the same thing, although because it’s Excel it is possible for project managers to amend the spreadsheet and personalise it. There is some latitude to track what’s important to this particular project. For example, sometimes I need to track spending in different currencies or with different tax rates, and not all projects at my company require that.

So – while I can’t give you a one-size-fits-all answer to this question, the answer lies in your PMO or Finance department. Talk to them about their requirements. Do they want you to enter data in your project management software (that’s the main alternative to spreadsheets) or do they have another way they want you to track your budget?

If there is no corporate standard, you have the latitude to work it out yourself. Spreadsheets are the easiest to get started with. Ask another project manager what they do, or search projectmanagement.com for templates.

How much contingency should I add?

This question comes up a lot!

And unfortunately, again there isn’t a simple answer. You might have organisational standards about how much contingency gets added to a budget. But in my experience, that isn’t the case. Project managers are largely left to their own devices and are expected to work out contingency themselves.

You should ask yourself:

• How risky is this project?
• Have we done something like this before that gives us confidence in the estimates?
• How certain are we that we’ve got all the tasks on the plan?
• Have we got the full requirements or might something else come up later that absolutely needs to be done?
• Do we have confidence in our supply chain?

The answers to these questions will help you work out whether you need to be generous with contingency or whether you can cut it back a bit.

The riskier the project, the more different it is from things your company has delivered in the past, and the level of confidence you have in the whole thing determine the contingency.

A reasonable starting point is 10% on the whole project budget. Cut it down for areas where you have confidence – like project initiation and close down, where the tasks are relatively standard and you can estimate the work more accurately. You might need to boost up contingency on project areas where you are doing unique work that hasn’t been done before and where your estimates are basically guesses.

Always make your contingency explicit in the budget and explain to your sponsor why it’s in there.

What’s a project budget summary?

It’s just the headlines of the budget. For example:

• The overall budget number – how much money your whole budget is
• How much you’ve spent so far
• Some text to provide narrative about whether you are on track or not.

That’s it.

You use the budget summary in your project status reporting. It goes in the box about project budget update (or whatever your similar section on your report template is called). All it’s for is to give the project sponsor and the wider stakeholder group the short version of where the project is with its spending. They don’t care if you’ve spent £3.50 this month on stationery suppliers for team members on the road. They only want to see the big picture, and the summary statement gives them that.

If you feel that the total + current spend + narrative doesn’t give them enough information (or they are constantly asking you for more detail) then provide what’s necessary. They may want estimate to complete or some other type of information. Ultimately your project reporting should deliver what they want to know about the project, so ask them if your summary is hitting the right points and if not, switch it up.

I’ve done other Q&A articles before. If you enjoyed this one, check out the other instalments in this series.

See Part 1 here

See Part 2 here

See Part 3 here

See Part 4 here

See Part 5 here

See Part 6 here

See Part 7 here

See Part 8 here

And if you have questions for me, please drop me a message! I’d love to feature your question in an upcoming article.

Pin for later reading:

We need to measure project performance to see if the project is on track.

The graphic below shares some ideas on the different ways you can measure work performance. None of these suggestions is better than any other – they are all appropriate for different projects, environments and levels of project management maturity.

Do you use any of these approaches to measure progress on your projects? Why (or why not)? Let us know in the comments section below!

If infographics aren’t you thing, you can get almost the same information (with perhaps a teeny bit more detail) over at this article:

7 Contract Terms You Should Know

It’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:

• Plan Scope Management
• Collect Requirements

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.

Inputs

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.

Outputs

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:

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:

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…

Equipment

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.

Taxes

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

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: