The Money Files

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!

Once you’ve ticked ‘mitigate’ as your risk management approach, you then have to think up ways to actually do that. What could you do to make the impact or likelihood of the risk less? Here are 4 options for reducing the risk – they won’t work on every risk, but they are general directions to consider when you’re wondering what to do to lighten the load for the project. And they are pretty easy to implement too, so that’s a bonus.

1. Start small

One of the easiest risk mitigation strategies is to start small. Consider prototypes, models, pilots. Think about how you can avoid a big bang launch and deliver results incrementally instead.

This works well as an approach if your project is using new technology, a new supplier, or is changing something sensitive, like a business critical process.

It doesn’t always work: on one large project I worked on we planned to deliver site by site, rolling out the new software and processes to groups at a time. But it didn’t work: for accounting reasons we had to maintain the integrity of the financial records and go big bang.

However, as a starting point, doing test runs and phased delivery is a good approach to mitigating all kinds of risk.

2. Schedule testing time

How many projects have you worked on where you’ve had enough time for testing? I’m embarrassed to say that plenty of my projects have ended up with testing time being squeezed.

As a project manager, you can control the schedule and double the amount of testing time planned (or whatever allocation of testing you feel appropriate, given input from the people involved in the work). That should give you long enough to wheedle out the bugs, which is another way of mitigating go live risks.

3. Add contingency to the schedule and budget

Explicit contingency is ‘extra’ time that is designed to offset risk: the risk of not knowing what you are doing, or whether it will work!

Manage uncertainty by adding a buffer to the duration of scheduled activities (or at phase level) and also to the budget.

I prefer contingency to be explicitly called out as an additional 10% of the budget and appropriate length for schedule contingency. Document what your approach will be in your schedule management plan and financial management plan.

4. Understand the guardrails for the project

Guardrails are like boundaries; tolerances for what freedom of action you have on the project. When you know where you have wiggle room and where you do not, you can make better decisions. Ultimately, your course of action to mitigate a risk should become easier because you know where you can save time and effort and where you cannot, because doing so will push you outside the guardrails.

When you’re working out what is the best course of action for a risk, think about where those boundaries lie and what options you have to work within them. That can help you decide whether your course of action requires an escalation or whether the team can manage without input from other layers of governance.

The right approach for risk mitigation depends on what the risk is, the risk appetite of your project and organisation, and what resources you have available to you. However, the above ideas are a starting point. What other common approaches do you use to mitigate project risks? Let us know in the comments!

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.

If you’ve been working in project management for some time, you might be familiar with the idea of variance. However, new project managers, or those who haven’t had to prepare financial information about their projects before, might find the idea a bit harder to get their heads around. Keep reading – this is for you!

I was speaking to one such project manager recently. While she had a ton of experience, she hadn’t needed to provide financial information for her projects as it wasn’t part of her stakeholders’ expectations. When the costs are mainly internal resource, many companies don’t require project managers to work that out in money terms. We tend to just estimate in days or some other unit of time and that’s good enough.

However, there will come a point in your career where you will most likely be asked to start crunching budget numbers for your projects. As you move into environments with greater levels of project management maturity, for example, it becomes more important to track things across projects in a standard way.

Budgets for money are the same in principle as budgets for time: you still need to work out how much you need and how much you are using, just like you would for time tracking on a project where you are only estimating in person hours/days. There’s another ‘however’ coming though…

However, in many organisations, including those where I have worked, it isn’t always necessary to track time. You create a project estimate at the beginning that states how many hours etc are needed from a resource in order to secure that resource, but after that, people are simply expected to manage their own time and the project is expected to conclude on the day you said it would. Timesheets don’t feature.

So, moving from this loose ‘we make a guess at how long things will take and go from there’ environment to one where you are expected to submit project reports with variance figures each week can be quite a challenge!

Luckily, the maths is not complicated and while it might seem daunting (especially if the numbers are big), variance is easy to track.

Budget variance

Here’s how to calculate budget variance.

Variance = Actuals + forecast – budget

In other words, you add up what you’ve spent so far with what you still have left to go, and compare that the original approved budget. The difference is the variance and shows whether you are under or over spent.

At the very beginning of the project the actuals are zero as you haven’t done anything yet. Each reporting period, simply pop the actuals into the right column and adjust the forecast down. Assuming you are on track, that is!

If you aren’t on track to hit your original estimates, you should be reforecasting the still-to-do work and noting those figures in the forecast column. Forecasts can change for lots of reasons including:

• The team created estimates that were based on assumptions that haven’t held true
• The team wasn’t very good at estimating
• More work has been added to the project as the result of a change request
• Work has been removed from the project as the result of a change request
• Resources have changed and now you are working with someone less experienced who will take longer to do the tasks
• Something else!

If you keep your forecast and actuals columns up to date, the rest is easy!

Tolerance

Normally there would be some tolerance agreed for the variance. For example, being under or over by 10% of the budget is OK but anything over that needs escalating to management or a change request etc.

Setting tolerance with your project sponsor will prevent you from having nightmares every time your project report says you are a few percentage points over budget.

How to get started

Make a spreadsheet that has the various columns. The simplest way is to have one column per field (actuals, forecast, budget, variance) and note the figures overall. As you get comfortable doing that, you might want to break them down by month to get a better idea of how things are tracking over time.

Once you’ve played with your project’s figures and have put together a spreadsheet to track them yourself (I recommend doing that instead of starting from someone else’s template so you can see how they fit together and what sums sit behind the columns) then you’ll get used to working out the numbers in this way.

I’m not a maths whizz by any means and I can manage it, so I’m sure you can too!

Budget “overs” are a way of filling the gaps in your budgeting process and acting as a safety net for when things go wrong, right?

Not exactly.

Management reserves and contingency reserves are two very specific types of “extra” money in your project budget. They both have distinct roles to play in helping the business achieve the deliverables in line with the forecasted expenditure.

In this infographic I summarise the differences between these two different types of funding. Personally, I think contingency reserves are the more useful as they are tied to a specific event so they help improve risk management as well. What do you think?

You can read more about some of the ideas on this infographic in this article.