The Money Files

I have an electronic copy of the PMBOK® 7^th edition, so from time to time I open it up to check on something. Recently, I’ve been looking at different ways to forecast as we’ve got some work on that needs to be planned out.

There are 6 quantitative forecasting options called out in the Guide. These are as follows.

Estimate to complete (ETC)

This is top of the list and the one I personally use the most often. It works even if you are not in a full, compliant, earned value management environment. The risk here is that we assume past performance is indicative of future performance, and honestly, why wouldn’t you? Unless you know something is definitely going to change measurable performance, you would assume that work is going to continue at broadly the same rate. Just jot that down as an assumption so it’s transparent to everyone.

Estimate at completion (EAC)

For me, this goes hand in hand with ETC. It’s calculated by taking the actuals and adding the ETC, so again, while it comes under the umbrella of earned value acronyms, it’s completely accessible to those who don’t work in EV setting.

Variance at completion (VAC)

As forecasting tools go, this gives interesting data. It’s the measure that shows the amount of forecasted budget over or under at the end of the project, and it’s one most project sponsors will be interested in: “Will we have any cash left to do anything else when we’re finished?”

To-complete performance index (TCPI)

I have never had the opportunity (or reason) to use this forecasting metric. Perfect for those of you working with earned value day in, day out, it’s the cost performance required to meet whatever management target you’ve set for the work. It’s a ratio, so I think it is less meaningful to execs who are used to see tangible numbers of days or money.

Regression analysis

Now more and more tools are introducing AI features, it is possible to access regression analysis more easily. Perhaps you’ve got access to an AI-powered tool that will crunch these numbers for your automatically, removing the need for statistical knowledge.

The output allows you to predict performance going forward based on what has happened in the past, so it’s arguably more grounded than other guesstimates!

Throughput analysis

The final forecasting technique mentioned is throughput analysis. This looks at the number of items completed in a fixed time, so it’s useful for teams measuring features completed, velocity and story points. You can compare the output to those of other teams, although I’d be wary about comparing teams unless they work on very similar products or services. It wouldn’t be fair to judge a team on their throughput when dealing with very complex features against the performance of a team that has higher throughput but lower complexity.

However, the team can compare its performance against itself: that would be a worthwhile exercise. Ideally, you’d want to see that the learnings from retros have been fully incorporated and, more importantly, that the changes have actually made a difference.

Which of these are most used for your project forecasting? Let us know in the comments below!

OK, the title of this blog post is a bit misleading. I don’t think I could count how many different ways there are to do estimating, I’m sure there are plenty of tools and techniques I’ve not used in my work as a project manager.

But there are some high level options for thinking about, presenting and sharing estimates with key stakeholders, and that’s what I wanted to dive into today.

I’m drawing on what PMBOK 7 says about different types of estimating, so you can refer back to that for more information. The guide talks about 5 different approaches to estimating, without mandating that any particular approach is used at any particular time – that’s up to you as the project manager to assess and choose the right estimating technique.

Deterministic/Probabilistic

Deterministic estimates are those that represent a single point. For example, 16 months, or $5,250. These are the easiest to understand but (I think) the hardest to come up with unless you have a lot of past project data and simple tasks that repeat.

Probabilistic estimates – why is that so hard to type?? – a those that represent a range. This is what I use most often in the thinking, even though when putting plans together we rarely represent the range in the schedule visually. This type of estimate often includes three factors:

The estimate itself with a range e.g. $5,250 +/- 10% or 16 months +1 month/-1.5 months.

This represents a weighted average based on several possible outcomes (like when you work out a three-point estimate with the most likely, optimistic and pessimistic outcomes), alongside what the range will be for the work. The result is often calculated by scheduling algorithms, but you can work it out manually, or even use professional judgement to make your best guess, as long as people know that’s all it is.

That brings us to the second factor: confidence.

A probabilistic estimate includes a confidence factor that represents how confident you are in the numbers. A 99.9% confidence factor would mean you’re pretty sure this is exactly how it is going to turn out. A 60% confidence factor – not so much.

Thirdly, if you are using computer programs to simulate scenarios and calculate estimates, you will also have a probability distribution, that shows the data and the range.

Absolute/Relative

Absolute estimates give you a specific number that stands alone. A deterministic estimate can be absolute. An example would be that to buy one machine costs £12,000.

Relative estimates are figures that only make sense in the context of other data. For example, buying more than one machine would be cheaper, but we don’t know how much by as the procurement team hasn’t finished the negotiations yet.

A better example, and the one in the PMBOK® Guide, is planning poker for agile estimating. Story points and T-shirt sizing help teams size the work in relation to other pieces of work but alone, “XL” doesn’t mean much to anyone else.

Flow-based

The final flavour of estimating talked about in PMBOK 7 is flow-based estimating. This type of estimating is useful where you know the flow of the work: the throughput and cycle time. If you know how many items of work can be completed in a particular time period (throughput) and how long it takes one item to go through the process (cycle time) then you can estimate how long it will take for a number of items to be completed, assuming other factors like sizing are taking into account in the calculations.

Regardless of how you do estimating, the data is only useful if people are bought into how it has been calculated and what the effort, duration or cost represents for them. Get the team involved in working out estimates and providing the assumptions that they are based on. Remember to adjust for risk, build in contingency where it makes sense to do so, and to keep estimates under review until such time as your confidence levels are sky high… which is usually once the work has been delivered and the task can be marked as complete!

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

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

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

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

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:

• Under pressure?
• Worried about how the numbers would be used?
• Unsupported by colleagues
• Unsure what the estimate was for?

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:

• Develop the models
• Turn the work of an individual into the work of a team with reviews
• Use the past as a guide to future performance
• Frame everything as a change
• Refine the estimates.

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:

• People capability: creating a course on estimating
• Data platform: collating data for benchmarking
• An advisory panel: to provide deep dive reviews of papers and initiatives
• Guidance for Senior Responsible Owners: to help SROs understand estimating
• Group conference: to bring together the community for a conference
• Leading practice: to identify leading practice and launch a maturity assessment.

I found it really interesting to see what a grass roots effort could do, and how powerful it is when experts come together with a common goal of simply wanting to share knowledge and do things better.

Gary shared his vision for the community, and I think it seems hugely realistic given the momentum behind PsACE at the moment. He talked about how the long-term goal is to align policy, data and expertise to encourage informed decision making to achieve more predictable outcomes. That’s something worth striving for, don’t you think?

Do you have a community like this where you work, in your industry? Let us know in the comments!