Estimating, scheduling and budgeting essentials

0:00 Estimates are forecasts under uncertainty

'How long will it take?' It's the question every project manager dreads, because any single answer is wrong. Say eight weeks, and it becomes a promise. Say 'it depends', and you sound evasive. The way out isn't a better guess. It's a better kind of answer: a range, a most likely value, and the one or two uncertainties that drive the difference. In this lecture you'll learn the main estimation techniques, how three-point PERT estimates work, how estimates become a schedule and a budget, how agile teams estimate and budget differently, and how to counter the planning fallacy. By the end, you'll be able to present an estimate that is honest, useful and hard to turn into an unrealistic commitment.

0:52 Why it matters

Why does this matter? Because estimates become commitments, whether you intended them to or not. A single-point estimate hides the uncertainty that everyone involved actually knows is there. And people are systematically optimistic about their own work, which is called the planning fallacy. It isn't a character flaw; it's how human judgement works when we imagine the task going well and forget the interruptions, rework and waiting. So the professional response is to estimate in ranges, to use more than one technique, and to be explicit about what drives the uncertainty. That turns an estimate from a promise you'll break into a forecast you can manage.

1:38 The concept: techniques

Here are the main techniques. Analogous estimating scales from similar past work: 'the last payments feature took twelve weeks'. It's quick, and only as good as the similarity. Parametric estimating multiplies a rate by a quantity: forty screens at three days each. It works when you have reliable rates. Bottom-up estimating asks the people doing the work to estimate detailed tasks and adds them up. It's more accurate, but it tends to miss the things nobody listed, like reviews, approvals and integration. And three-point estimating captures uncertainty directly with an optimistic, a most likely and a pessimistic value. Think of it like planning a journey: you know the usual time, the best time with empty roads, and the worst case with an accident on the motorway. Using two or three techniques and comparing them is far more reliable than trusting any one.

2:40 Three-point PERT

The PERT formula gives an expected value from three points: E equals O plus four times M plus P, all divided by six. It weights the most likely value most heavily, but lets the extremes pull the answer. An approximate standard deviation is P minus O, divided by six. Here's the key insight. In real work, the pessimistic tail is usually much longer than the optimistic one. Things can go a little better than expected, but they can go a lot worse. So the expected value usually lands later than the most likely value. That's not pessimism. It's arithmetic. And it's exactly why plans built by adding up most-likely estimates tend to finish late: they ignore the skew.

3:31 Worked example one: integration testing

Let's work the example from the lesson. Integration testing. Optimistic: ten days. Most likely: fifteen. Pessimistic: thirty-two, because integration testing is where hidden problems surface. Expected: ten, plus four times fifteen, which is sixty, plus thirty-two. That's a hundred and two, divided by six: seventeen days. Standard deviation: thirty-two minus ten is twenty-two, divided by six, about three point seven days. So the expected duration is two days later than the most likely, because of that long pessimistic tail. If you'd planned fifteen days, you'd be late more often than not. Now, a caution. Adding standard deviations across tasks isn't straightforward, because tasks aren't independent. For whole-project confidence levels, Monte Carlo simulation, which the project controls course covers in depth, is the better tool.

4:25 Worked example two: a London payments feature

Now the realistic example from the lesson. A fictional fintech in London estimates a new payments feature. The analogous estimate, from a similar feature last year: twelve weeks. The team's bottom-up estimate: nine weeks. Why the gap? When the project manager walks through the bottom-up, it excludes security review and regulatory sign-off, because the developers estimated only the work they do themselves. Three-point estimates on those uncertain items add around two weeks. So the project manager presents: most likely eleven weeks, with a realistic range of ten to fourteen weeks; the main uncertainty is the timing of regulatory sign-off. The sponsor agrees a target date at thirteen weeks, with a clear escalation point if sign-off hasn't started by week eight. Notice what happened: the conversation moved from 'why so long?' to 'what can we do about sign-off?'.

5:25 Watch me do it: PERT and a schedule in a sheet

Let me set this up in a spreadsheet. One row per uncertain task, with optimistic, most likely and pessimistic columns. Expected is O plus four M plus P, over six. Standard deviation is P minus O, over six. Then I sum the most likely values and the expected values along the critical path, or the sequence of tasks that drives the end date. In this example, most likely adds up to forty-one days and expected adds up to forty-seven. That six-day gap is the planning fallacy made visible. I present it honestly: most likely forty-one working days, expected forty-seven, and a planning range of roughly forty-four to fifty-five depending on how the uncertain items land. Then I list the two tasks with the largest spread, because those are where attention and contingency should go.

6:23 Budgeting, agile budgeting and the planning fallacy

From estimates to budget: add up the work estimates, add contingency for identified risks, and hold management reserve for unknowns, usually controlled by the sponsor. Agile teams often budget differently: a stable team is funded over a period, say a quarter, and the question becomes which outcomes deliver the most value within that capacity, with regular checkpoints to continue, pivot or stop. Both approaches need honesty about uncertainty. To counter the planning fallacy, compare with reference classes, meaning what similar projects actually took, run a pre-mortem where the team imagines the project finished late and lists why, and always present ranges. The common mistakes: single-point estimates, estimates made without the people doing the work, forgetting reviews and approvals, and padding every task secretly instead of holding visible contingency.

7:19 Recap and try this now

Let's recap. Estimates are forecasts under uncertainty, so treat them that way. Use more than one technique, analogous, parametric, bottom-up and three-point, and compare them. The PERT formula gives an expected value that usually lands later than the most likely, because real work has long pessimistic tails. Build the schedule from logic and the budget from estimates plus visible contingency and management reserve, and present a most likely value, a range and the key uncertainty. Counter optimism with reference classes and pre-mortems. Your try-this-now: produce three-point estimates for five uncertain tasks on a project you know, calculate the PERT expected values, and present a date range with the one uncertainty that matters most.