A project budgeting calendar
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:
Remember to write all this stuff down as part of your project initiation documentation.
During the activity part of the project where you are completing project work and achieving targets towards your deliverables you should be:
Each month on the project
Every month you should be updating your project records and doing the following:
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:
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!
At the end of the project you should:
What else would you add to the list? Let us know in the comments.
5 Tips for Better Project Estimates
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.
5 Facts from Project Management Accounting
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.
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.
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.
When timetracking blocks efficiency
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.