The Money Files

A blog that looks at all aspects of project and program finances from budgets and accounting to getting a pay rise and managing contracts.

About this Blog


Recent Posts

A project budgeting calendar

5 Tips for Better Project Estimates

5 Facts from Project Management Accounting

What does the average project manager look like?

When timetracking blocks efficiency

A project budgeting calendar

Categories: budget

I could have also called this post: What money stuff do you do when?

I should start by saying that it’s difficult to give you a complete rundown of what project budgeting activity needs to happen when in the month or whenever in your project, because each company is different. So this article will cover what I think is common practice based on the project managers I work with and coach.

Project start up

At the beginning of the project, before the ‘doing’ of the work starts, you should:

  • Work out what budget you need.
  • Agree budget and tolerances with those in authority.
  • Agree contingency funds and the process for accessing them.
  • Negotiate any big purchases or put arrangements in place with suppliers.

Remember to write all this stuff down as part of your project initiation documentation.

Project delivery

During the activity part of the project where you are completing project work and achieving targets towards your deliverables you should be:

  • Raising purchase orders and issuing them to vendors
  • Approving invoices
  • Reviewing contract terms and supplier's performance against the contract
  • Completing internal processes to get suppliers’ bills paid.

Each month on the project

Every month you should be updating your project records and doing the following:

  • Track what orders have been raised and received.
  • Approving any cross-charges from other departments or projects.
  • Review what you’ve spent.
  • Review what you plan to spend.
  • Panic if there is a discrepancy against your actual budget – just kidding. Work through any discrepancies and reforecast as necessary.

Every couple of months on the project

Every so often – I’d do this every two months on shorter projects and every three on longer ones – review these bigger ticket items to see what your status is:

  • Review tolerances and get them changed if they no longer seem appropriate.
  • Review spending on your contingency budget and check your forecasts, ‘handing back’ any money that you no longer need, for example when a particular risk has passed.

If your project falls over the year end financial accounting period you should also be preparing for anything that you might need to do in order to satisfy the internal processes around that. For example, managing accruals. If you’re lucky, someone will do this for you!

Project closure

At the end of the project you should:

  • Tie up any contracts and draw the arrangements to a close.
  • Migrate any project-related contracts or purchasing agreements that will be maintained long-term to an operational business team who can manage them day-to-day after project closure.
  • Prepare a final statement of your project budget.
  • Let everyone know that the project is over. No more cross-charges!

What else would you add to the list? Let us know in the comments.

Posted on: April 14, 2015 09:34 AM | Permalink | Comments (4)

5 Tips for Better Project Estimates

Categories: estimating

When it sometimes feels that estimating is nothing more than a guess, how can you improve your results? Better project estimates means you are more likely to hit your deadlines and budget. It’s easier to manage stakeholder expectations because you aren’t constantly telling them you’re running late. It’s easier to motivat eyour team because they know what’s coming up instead of living through shifting milestones every week.

Here are 5 tips for better project estimating.

1. Work to an accuracy level

Make it clear how accurate your estimates are. The more accurate they are, the more likely they are goig to reflect reality as you progress through the project. But early on in the project you may not have envough informatiion to estimte with any degree of accuracy. That’s fine, as long as everyone knows.

There are three broad ways of talking about the accuracy of your estimates.

a) Rough Order of Magnitude (you’ll see this shortened to ROM). It’s huge. It’s a range between -25% and +75% accurate. It’s really rough.

b) Budget estimate. This is between -10% and +25% so a range of 35%. That gives you plenty to narrow down your estimation. Note that you’ve got less to go under than over (as with the ROM).

c) Definitive estimate. Don’t let the terminology faze you: definitive still means you have a range of -5% for +10%. That’s still gives you a bit of wiggle room, but it’s about as definitive as estimates get.

Whichever range you use (or if you invent your own and use a range particular to yourprojet as I have occasionally done) you must make sure that your stakeholders understand how you’re using the numbers. An estimate of $50k doesn’t mean you’ll hit $50k when it’s an estimate within a range. I’d advise that you always include the from and to figures of your range when presenting any numbers, to make sure that everyone is clear about what you mean.

2. Document your assumptions

Estimates are created from your assessment of the situation or task at hand. Your assessment is based on certain assumptions: it has to be because it hasn’t happened yet.

When you say a task will take 12 hours include the assumption that you’re expecting Claire to be allocated to this work: an experienced resource who has done this kind of work many times before. When you then get Joan allocated to the task – and she’s never done it before – you’ll be able to explain why the estimate has to be revised. An inexperienced resource is likely to work more slowly and need more time to check the work than someone who knows what they are doing.

3. Avoid optimism bias

Sometimes estimators are overly optimistic because they feel positive about the work that is coming up and they feel they can work around any risks. Sometimes there is pressure to hit a certain budget so estimates are forced optimistically low to make the numbers look good. Both those scenarios are dangerous because you end up with an unrealistic estimate before you’ve really started.

Be realistic. If you feel that the team has been too optimistic about what they can achieve, then review the figures or use another estimating technicque to bring some balance to the calculations. If that makes the numbers fit badly with the intended budget, consider reducing the scope instead.

4. Go low

High-level task breakdowns aren’t a good fit for estimating. You want detail. You want the smallest level of detail possible, actually. If there is no work breakdown structure for the project yet then think about waiting until one exists before trying to pull together the cost and time estimates.

Using a task list that is too high level results in missing out activities that may be costly. You can’t assume that your contingency fund will cover this when it’s your own estimating practice that caused any overspend: you’d be better off keeping contingency for true oversights.

So on the subject of contingency…

5. Include contingency

It’s tempting to strip contingency from the estimates at task level and then add it back in at a phase or project level. In fact this is a valid way to handle contingency, and may well be your preferred approach. However, when you add it in like this it’s still there. The problems come when you report or try to work to the estimates without contingency.

This makes your project look cheaper for your stakeholders. It might seem like a good thing, but how pleased are they going to be when you come in over budget having spent contingency that they didn’t understand was there?

Make sure your project estimates do include contingency and be explicit about how this is managed within your estimates: within each individual task, at a phase level, at the project level overall or some other way.

Want more on estimating? Here’s a video on the 4 pitfalls of project estimating.

Posted on: April 08, 2015 09:23 AM | Permalink | Comments (7)

5 Facts from Project Management Accounting

Categories: accounting

Posted on: March 27, 2015 09:20 AM | Permalink | Comments (0)

What does the average project manager look like?

Categories: recruitment, reports

The Arras People Project Management Benchmark Report contains a useful snapshot summary of responses by job title this year. It means we can take a look at what an ‘average’ project manager looks like, if there is such a thing. Bear in mind that the survey is mainly targeted at UK project managers although there were a fair few responses from those working outside the UK.

Let’s meet our average PM.


  • He is male: 75% of the project managers responding to the survey are male (and that figure has stayed broadly the same for as long as I can remember reading this annual report).
  • He works in the UK.
  • He is aged between 35 and 59.
  • He has at least one degree (a Bachelor’s degree) and is quite likely to have a Master’s too. Most likely his higher degree is in project management or is an MBA.


  • He has more than 10 years of experience in this role…
  • …and considers himself a practitioner rather than an expert or a foundation/junior member of the team based on his assessment of his education, professional accreditations and experience.
  • He has domain knowledge as well as project management knowledge.
  • He is PRINCE2 certified with further accredited training courses in leadership and managing people.
  • He holds membership to a professional body.
  • He’s aware of Agile but not using it and doesn’t hold any Agile certifications. That’s probably because his company doesn’t use Agile.


  • He works in the private sector.
  • He’s an employee, not a contractor or self-employed.
  • He earns between £40,000 and £49,999 a year: the average salary for respondents was £47,180 in the UK.
  • He leads new product development or service transformation projects.
  • He has no direct reports.
  • His span of control is less than 10 people.
  • His budget responsibility is either significant (£5m to £10m) or nothing at all.

Does any of this sound like you? Nearly 45% of the respondents to the Arras survey identified as project managers so this is data from a very representative sample.

Let’s have a look at some of the outlier responses and create a different sort of project manager.

The outlier

  • The outlier is a woman.
  • She’s under 24 with a PhD and membership of a professional body that isn’t PMI or APM.
  • She has hardly any experience and works in defence.
  • She has no domain expertise alongside her project management knowledge.
  • She manages a team of between 8 and 10 and earns either under £25k or over £75k. She manages budgets of £501k to £1m.

This really doesn’t sound likely as a profile, does it? It’s a collection of the least common responses from people in the survey, but it doesn’t hang well together as a pen portrait of an atypical project manager. I could extrapolate from this that the ‘average’ project manager I constructed above from the most common responses to the survey is also not a particularly accurate profile.

Statistics are useful – in this case they help set salaries and responsibilities for people in professional project management positions. But they need to be considered in context.

Get a copy of the survey and see the details for yourself here.

Posted on: March 25, 2015 10:45 AM | Permalink | Comments (4)

When timetracking blocks efficiency

Categories: timesheets

The second edition of Shortcuts to Success: Project Management in the Real World is now out and I had to ditch several great case studies from the updated manuscript. I thought you might be interested in this one: it describes what happens when project managers and timesheets don’t see eye to eye.

Luke Reader has worked for project managers who handed him a list of tasks for the week.  A typical list would include the hours completed for each task and the estimated time needed to finish each one already filled in.  Despite the good intentions of his project managers he did not find working with timesheets in this way very effective.

‘Timesheets can put a barrier between the project manager and their understanding of what’s happening,’ Reader says.  ‘It also annoys the team by treating them as a production line rather than intelligent people who can usefully participate in managing their workload.’

Reader has witnessed at firsthand how using rigid time recording can back-fire, and as an IT project manager himself, has developed a more effective way of handling the work of his own team.  ‘The problem with timesheets on their own,’ he says, ‘is that the team soon learn that rather than say, “This task is late, I mis-estimated”, they invent new tasks such as a test cycle or a further review.  These are then written on the timesheet in an attempt to show how hard they are working even though the overall work is behind.  The project manager cannot tell what the genuine issues are.  And while the project manager can go back and challenge things, it means another cycle of going back to people – and time passes, which is something you don’t have on projects.’

Having learnt from the mistakes of others Reader now takes a pragmatic approach to managing his team’s time.  ‘For me, timesheets are a mechanism to allow contractors to get paid, internal and external billing to take place, and sometimes for company management to get an idea of what their staff do all day,’ he says.  ‘So as a project manager I make timesheets as simple as possible, ideally just having one task like “Work on Project X”, and I manage the people via discussion using the project schedule as the reference.’

I’ve worked on projects where I used timesheets and on those where I haven’t. When we have tracked time, all resources have done it, not just technical teams. Sometimes my timesheet has had one bucket task on, such as when I was loaned from one business unit to another. My ‘official’ business unit didn’t much mind what I spent the days doing as long as they were able to internally cross-charge for my time. A timesheet helped them do that, but it only needed one task on which was basically ‘work for XYZ department as required’.

On the other hand, I’ve had to put together quite detailed timesheets to cover the range of tasks that my project team did from very technical work to business process redesign and all the project management related stuff too. It’s time consuming but very enlightening. Even if you don’t intend to track time long term or have the requirement to do so, I’d recommend that as a time management task you give it a go at least once. We found that the whole team spent the most time on the task called ‘non-productive work and travel’. Not good! But at least having that identified meant that we could do something about it.

If you’re looking for more advice on tracking time on your projects there are more tips on timesheets in a Q&A here.

Posted on: March 16, 2015 08:26 AM | Permalink | Comments (7)

"The one thing that can solve most of our problems is dancing."

- James Brown