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

What does it take to be a high earner in PM?

Align projects to strategy to maximise returns

A project budgeting calendar

5 Tips for Better Project Estimates

5 Facts from Project Management Accounting

What does it take to be a high earner in PM?

Categories: salaries

Posted on: April 24, 2015 10:08 AM | Permalink | Comments (0)

Align projects to strategy to maximise returns

The fourth annual Global PPM survey from PwC highlights the fact that organisations use subjective information to make decisions about what projects go forward. That’s a kind way of saying that the executive team choose projects based on organisational politics and personal agendas rather than on what’s best for the company. As a result, many businesses start projects that should never have got off the ground.

Just over three quarters of C-suite execs feel that their projects are aligned to strategy, which is quite high (although you’d expect it to be 100%, otherwise why are you bothering to work on the project?). However, only 72% of project and programme managers – the ones who are actually doing the work – agree that there is a coherent relationship between the objectives of the programme and the company strategy. About one in ten employees report that projects receive budget approval but do not necessarily align to strategy in any noticeable way.

The story gets even worse when you look at PwC’s objective maturity assessments. By their reckoning, only 62% of programmes have a mature or established link to strategy.

And this is an improving situation!

While it’s pretty dire that so many projects are undertaken without a clear link to how they are going to help the business in any way, it did used to be worse.

PwC report that in 2012 as many as 30% of an organisation’s programmes were in some way conflicted with the overall business strategy. One in five didn’t have a correlation between the project portfolio and business strategy. So it is better today.

There is still a long way to go though.

What is the cost of getting it wrong?

The exact cost in money terms is going to depend on what projects and programmes your business kicks off that have no tangible link to business results. Of course, they might still be of use in some way, but that will be through accident rather than design. They might deliver some benefits, but another project might have delivered more benefit. That’s where data comes into the project selection process. As the report’s authors say, guessing is not a strategy for success.

They also talk about removing the option for people to game the system and using methodical approaches to prioritising and selecting projects. You only have a limited amount of money to invest. Make sure it’s being invested in the right projects.

What you can do about it

It’s fine to say that CEOs should be more strategic, have multiple planning horizons and be closer to the delivery teams, but project managers, programme managers and portfolio office managers can’t really influence how the CEO operates. This is what you can do.

Stop reporting on the past and focus on the future. The PwC survey shows that the two main focus areas for PMOs (and by extension, project managers) are reporting (63%) and monitoring (54%). To move up the maturity curve, focus on more proactive portfolio optimisation services. What can you do to spot trends and predict benefits instead of reporting on what has already happened?

Choose projects objectively. Use decent data to draw conclusions about which projects should go forward and which should be shelved. Use objective checklists and review projects thoroughly. No more organisational politics and directors’ pet projects, although I appreciate that is easier said than done. If you are a project manager, ask the questions: has your project been through the approval process and if not, why not?

Stop projects. If a project isn’t going to deliver the benefits, speak up. Recommend that it’s cancelled, or at least stopped for a bit to see if anything can be salvaged. You know your project best, and you’ll know if there is no visible link to anything strategic. If you want to be known as a project leader, act like a leader and have the difficult conversations.

Solicit new ideas for projects. Don’t rely on the old routes for project proposals, because those old routes are probably the directors who are used to skipping through the approval process and having their bright ideas delivered. Go out to your business colleagues and solicit ideas for projects. Make it easy for people to put forward suggestions so your pipeline of ideas is always full. The more you have to choose from, the easier it will be to choose the high-value ideas.

Get the right people on the team. One of the reasons, in my experience, why projects don’t get stopped is that the project team don’t know enough about the business area they are working in to be able to provide that level of consultancy. Get the right people on to the project team so you don’t have that problem. Second business experts to the project full time or part time so that you’ve always got a deep link to operational practice. They will be able to help you identify whether you’ve got a problem or whether the project is moving towards delivering something of value.

It is hard to get it right every time. Sometimes we don’t have the power to stop projects or influence those above us in the hierarchy to make the right decisions. But nothing gets better if project managers, programme managers and portfolio managers don’t try. We should adopt the attitude that projects should and do align to strategy and then be surprised when they don’t. It should simply be ‘how we do business round here’. If we don’t ask the right questions, we run the risk of working on low value, unstrategic initiatives that aren’t even delivering tactical benefit. What’s the point of that?

Posted on: April 20, 2015 06:06 AM | Permalink | Comments (4)

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 (8)

5 Facts from Project Management Accounting

Categories: accounting

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

"The most exciting phrase to hear in science, the one that heralds new discoveries, is not Eureka! (I found it!) but rather, 'hmm.... that's funny...'"

- Isaac Asimov