4 Different Types of Estimating
I’m loving PMBOK7. It’s far more pragmatic and helpful than previous versions, although speaking to other project management professionals (and trainers) they are reporting that students feel like they need the process stuff too, so they can actually get the work done.
I think I’m lucky in that I’ve got my personal ways of working kind of figured out, and over the years have built the confidence to tailor what I do to fit the project, and also the amount of time I have to spend on it.
I’m working on a lot of capex initiatives at the moment, so estimating projects for proposals is always top of mind. I turned to PMBOK7 to see what it had to say about estimating.
The book says there are 4 different aspects of estimating, each affected by where we are in the project lifecycle.
Range refers to how close you can get to what might be the final estimate figure. For example, in the early stages of the project lifecycle you probably don’t have a lot of detail about the tasks and therefore you might not be able to get close to some of your estimates.
Using ranges is useful because it helps present information when you still don’t have all the details. You can state a range like “between £80k and £120k”. As you get more information, you should be able to narrow the range, such as, “between £95k and £110k”. Eventually, you might be able to pinpoint an exact price.
To be honest, the exact price is often where we start from in capex, procurement-led projects, as the supplier provides a quote early on.
Accuracy is how correct the estimate is; how close to being “true” it is. A supplier quote – provided you have given the correct scope – should be pretty accurate. An estimate from the IT team about how long it is going to take to connect the asset might not be very accurate at all if they’ve never worked with this technology before. If it’s something they do regularly, they can give you an accurate estimate.
Precision is about how precise (obviously) an estimate is, or needs to be. Delivery dates for kit are often not precise at the beginning of a project, but as the stock comes in and suppliers can be more precise about when it will be shipped, the date estimates become more precise.
Confidence levels are useful to include in your estimates, and are especially useful for influencing culture. In my experience, they are helpful when you are working with experts who are reluctant to commit to timescales and dates. You can ask, “How confident are you that you can complete the work within a week?”
The more experience they have at doing that kind of work, the more confident they should be in their numbers. The more robust the estimating, the more confident they should be. Guesstimates have a low level of confidence.
Explicitly mentioning the confidence levels when communicating to senior stakeholders can make uncertainly more obvious to them. I’m sure we’ve all worked with stakeholders who, when you say, “some time during the month” expect it to be delivered on working day 1.
Not all projects will need all of these factors built into their estimates, and as your project progresses through the lifecycle, the way you create estimates will change. It’s worth bearing these factors into consideration so you can adjust and communicate about your estimates as you go.
James Lea, founder of Project Science, spoke at EVA 26 earlier this year. He talked about the psychology of estimating. “People,” he said, “are just as important as the techniques and data.”
He went on: “Plans and estimates are built by and used by people. Psychology matters.”
The talk was very interesting, and here’s what I took from it.
He started by asking us our experiences of estimating and the emotional responses we had at the time. Think about your own experience of estimating. Did you feel:
That’s all (unfortunately) normal, and we all nodded along as he talked.
Challenge how will estimates be used
James talked about how we should challenge how estimates should be used. “Uncertainty drives variable reactions in our teams,” he said. “It drives emotions and responses.” If you are open about how estimates are going to be used and how they should be used, that can help people feel more comfortable with the process.
Make estimating positive
How can we enable our teams to experience planning and estimating as a positive, creative experience? Instead of the stressful, “I suppose I can give you a number,” experience that it is mostly?
It’s hard for an organisation to accept that it doesn’t know the answer, and that can sometimes lead to a poor experience of the estimating process for the people involved.
Here are some ways he suggested we could turn the experience into a positive one:
Creating a route to predict the future
James talked about asking the question about whether we have a route to predict whether the estimate is a robust one or not. We need to understand what is in and out of our control. Where things are out of our control, accept that and track it.
Estimates are only a guess without a map of how you got there and a set of viable routes.
We often hear that people can’t estimate where there is no historical data. Well, data science should make it easier now to estimate from past performance and the vast tracts of data we store about projects. If leaders can give teams the data, in a way that helps with estimating, that should make our estimates better.
Building defensible plans
James talked about showing your workings and documenting the bases of estimates. Steve Wake, the conference chair, shared his thoughts too, namely that the audit office regularly says people don’t know the basis of estimate and therefore the best ‘proof’ that your estimates are good is that you can justify them.
He talked about bounding your plans carefully, describing the world around the estimate as well as the estimate itself to provide rigour.
He suggested we quantify and compare with data science, applying risk appetite to the delivery methodology to round out what we know.
That, and the other points discussed, are ways to shape the emotional response and create a safe space for people to estimate their work.
What do you think? Let me know in the comments below.
At the EVA conference in London in March, I had the pleasure of listening to Gary Hill, Co-chair of PsACE, the Public Sector Advisory Community for Estimating. He was talking about the importance of estimating and how the community helps shape the professional estimating done on public sector projects in the UK.
The purpose of the group is to simplify, standardise, systemise and professional project estimating process and capability across the public sector. He shared their vision, which is to bring together experts across government and client organisations to promote leading practice in estimating, underpinned by an ethos of trust and collaboration. I like how he talked about leading practice instead of ‘best practice’ because as we all know, there isn’t one definitive best practice for pretty much anything in project management.
He talked about how the community started in April 2019 when someone reached out to him and asked for help with something. “It started over coffee and turned into a beer,” he joked. The community sets out to address the problem that many project managers have in all aspects of our work: where do you go for advice, how do you know if that advice is any good and who says it’s good anyway?
To find out where good practice was in the public sector the community carried out a benchmark of 7 government departments where they measured good practice. Surprise, surprise, no department was good at everything.
Today, the community is sponsored by IPA, the Infrastructure and Projects Authority, which Gary said gives the community’s work more weight and more chance of making things stick. They really started to gain traction when they were mentioned in a government select community discussion, and membership started to grow.
It’s a volunteer-led community and Gary shared the common problem that many volunteer-led communities have: everyone wants to get involved because it’s a good idea, but everyone has a day job to do so it’s hard to get people to take on jobs.
Next up on the agenda for PsACE is to write to each permanent secretary in the UK government and ask them to support the community’s work, so that’s a large piece of stakeholder engagement to do.
In terms of what they actually do, Gary explained that PsACE was involved in providing input to the IPA estimating guide, and was represented on the committee preparing British Standard 202002 for Project Controls.
There are current workstreams covering:
Last month I looked at what you need to consider when setting up programme financial management, drawing on The Standard for Program Management, Fourth Edition (2017).
Today I wanted to write some more about financial planning at programme level (as we would spell it here in the UK), again, using The Standard as the foundations but sharing my experience as well.
The financial management plan for a programme
The Standard talks about having a financial management plan which is made up of:
This all fits into the overall programme management plan, but could be a separate document.
The document is supposed to outline a lot of information about how money will be managed during the work. It should go into detail about:
In addition, as with all plans, you should include how the budget is going to be approved and what that authorisation process looks like.
In my experience, we did not have all this written out, although we did have a Finance team who were very much on the ball and probably had considered it without making it my job (thank you, wonderful Finance Manager!). In addition, the detailed technical budgets, which represented most of the cost (aside from staff) were put together by the technical architect, and were comprehensive. By the time it was my turn to look after the numbers, the paperwork seemed solid and it was very much a tracking exercise. I can’t take too much credit for the planning effort.
We were using international resources so the currency issue was very much relevant, and so was the risk reserve because we were doing something new to us with a high degree of uncertainty.
To be honest, I’m not sure we had a formal process for risk reserves either. Contingency had been added to the budget, but we did not allocate budget to risk management activities on a per risk basis. Given the scale of the investment, that was probably a mistake! I don’t recall any terrible dramas happening as a result of not having funding assigned in that way, even when the programme timeline was extended.
Contract payment schedules were documented in the contract instead. Our legal team bound up the contract and relevant schedules into little A5 booklets and I had one that sat on my desk and became my go to reference for all things to do with service level agreements, contract expectations and when I had to approve certain milestones to issue payments.
One time, I issued the payment notification and requested the funds be paid, but I had not warned Finance such a large request for cash would be coming so the actual payment was delayed a few days. That taught me I needed to start my process earlier so that Finance had notice that a large payment was due as part of our contract schedules.
Planning at a programme level feels harder because there is generally a bit more uncertainty, the timescales might be longer than your average project, more people are involved, and the numbers are higher. However, it’s never one person’s job. As you come together as a team, experts can provide their input to make sure the final result is something the governance team, finance team and programme management team can be confident with.
Project costs feels like a topic I’ve revisited many times over the course of writing this blog (can you believe I started it in May 2010?) and today I want to use my monthly video to go into the differences between direct and indirect costs and fixed and variable costs. They are terms new project managers might get confused about and we hear them thrown around in discussions. What do they mean for projects?
In this video I share a few examples of each so you can get a feel for how these might play out for your work. If you want a text-based post to refer back to, then this article on 5 types of project cost also includes some information on the topic.
Do you have different definitions or examples to share? Leave a comment under the video as this community is better for all the different voices in it!