The Money Files

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 going to reflect reality as you progress through the project. But early on in the project you may not have enough information to estimate 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 your project 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.

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.

Demographics

• 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.

Experience

• 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.

Employment

• 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.

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.

The Arras People Project Management Benchmark Report is out and 2015 is the 10^th anniversary of this important study into the state of the industry. One of the interesting snippets of information in the 40-page report is a peek into how the recruitment pipeline breaks down because the people involved aren’t using the same criteria to assess candidates.

The person hiring has very different views of what makes a great candidate for a PM role to the project management professionals who may be involved in the hiring process. Let’s say I’m the hiring manager. I have certain views as to what makes a great project manager, but I don’t want to sift through CVs and interview candidates alone. Project management is a team sport, so I bring one or two of my trusted senior project managers into the loop for the purposes of recruiting. They have a different view of what the person should be good at to excel in the job.

So far, so clear. Let’s look at where the differences of opinion are between hiring manager and peer.

Professional body membership

Hiring managers seem to put a greater emphasis on membership of professional bodies like PMI and APM than project managers involved in the recruitment process. Over 50% of recruiters say it’s important compared to only 29% of peers.

Continuous professional development

Should project management candidates show evidence of improving their skills over the years through continuous professional development? Over 50% of their peers believe that they should. Less than a third of hiring managers thought it was an important element for someone’s application.

Soft skills training

Project management is a lot about managing stakeholders and getting the soft skills right on a project goes a long way to achieving that. Over one in five hiring managers doesn’t believe it’s important but only 8% of peers would agree. Nearly 60% of peers think that their prospective colleagues should be able to demonstrate that they’ve done some soft skills training but only 15% of hiring managers would rank that as important on an application.

PPM accreditation

We’ve seen how professional body membership is viewed by both groups. What about credentials and certificates in project management subjects? This is one area where both hiring managers and the project managers involved in recruitment seem to have a similar view. Over 75% of recruiters and peers agree that PPM accreditation of some sort is essential for candidates.

Why does it matter whether the people involved in recruitment agree or not? A healthy debate is the result of not agreeing, and that can make for better hiring decisions.

Well, it can. But it can also result in posts not filled because managers can’t agree on who to recruit. It results in good candidates not getting a look in because they are weeded out at an early stage when actually they may well have the skills to do the job. That’s not to say that either hiring managers or peers are ‘wrong’ in their assessment of what it takes to do the role. I’m only highlighting that some candidates won’t make it past the first filter because of who is doing the filtering. If they had made it past and were subject to that healthy debate, the hiring team may end up with a different perspective on their application.

The disconnect in the recruitment supply chain, as Arras calls it, also creates problems when dealing with third party recruitment agencies (like Arras). That’s another viewpoint. They are specialist, and know what the market wants, but it’s still a third pair of eyes reviewing CVs and applying their own filters about what important skills and qualifications a candidate should have.

How do we fix this problem? I don’t think we can. It’s normal for people in different posts to have different opinions of a role – it’s normal for different people to have different opinions. Instead, all we can do is be open to the fact this is happening and make sure we really discuss a candidate’s strengths and weaknesses in the round before writing them off. Otherwise we’ll be left with vacancies we can’t fill and projects that can’t be delivered, and that’s no good for anyone.