Budgets, Timelines & Resources

"How long will this take?"

Monday morning standup, six months ago. The VP of Product turns to Marcus, the project lead, and asks the question every PM dreads: "How long will the new checkout flow take?"

Marcus does what every PM does. He thinks about it for three seconds, adds a mental buffer, and says: "About 3 months."

Three months later, Marcus is back in front of the VP. "We need 2 more months."

The VP's face goes blank. "You said 3 months." Marcus scrambles: "Well, we didn't account for the payment provider migration, and the design team was pulled onto the rebrand for six weeks, and QA found 47 critical bugs in the—"

But the VP has already stopped listening. Trust is broken. The budget is blown. And the worst part? Marcus knew at week four that 3 months was impossible. He just didn't say anything because he hoped the team could make up the time. They couldn't. They never can.

This is the most common conversation in project management. And it happens because estimation is treated as a guess instead of a discipline.

Estimation techniques: five tools for your toolbox

There is no single "right" way to estimate. Different situations call for different techniques — and the best PMs use several together as a cross-check.

1. Analogous estimation (the "last time" method)

You look at a similar past project and use it as a baseline. "The last mobile app we built took 4 months and cost $120K. This one is similar in scope, so let's start there."

When to use it: Early in the project when you have limited detail but have done something similar before.

Accuracy: Rough — within 25-50% of actual. Better than a gut guess, worse than a detailed estimate.

The catch: No two projects are truly identical. The last app did not have real-time chat, your senior developer just quit, and the client is twice as indecisive. Analogous estimates need adjustment.

2. Parametric estimation (the math method)

You identify a measurable unit of work and multiply. "$500 per page x 50 pages = $25,000." Or: "Each API endpoint takes 3 days to build. We need 20 endpoints. That is 60 developer-days."

When to use it: When work is repetitive and you have reliable per-unit data.

Accuracy: Good — within 10-25% — IF your per-unit cost is based on real data, not wishful thinking.

The catch: Not all pages (or endpoints, or features) are equal. A simple "About Us" page is not the same as a dynamic pricing calculator. Parametric works when units are truly comparable.

3. Three-point estimation (the PERT method)

Instead of one number, you generate three:

• O = Optimistic (everything goes perfectly — best case)
• M = Most Likely (realistic, based on experience)
• P = Pessimistic (everything that can go wrong does — worst case)

Then you apply the PERT formula: (O + 4M + P) / 6

This weights the most likely scenario heavily while accounting for risk in both directions.

Example: Building a search feature.

• Optimistic: 2 weeks (the API is clean, no edge cases)
• Most Likely: 4 weeks (typical complexity, a few surprises)
• Pessimistic: 10 weeks (the data is a mess, requirements change twice)

PERT estimate: (2 + 16 + 10) / 6 = 4.7 weeks

Notice how the pessimistic case pulls the estimate higher than the "most likely" alone. That is the point — it forces you to account for risk instead of ignoring it.

4. Bottom-up estimation (the detailed method)

You break the project into every individual task, estimate each one, and add them up. This is the most accurate method — and the most time-consuming.

When to use it: During detailed planning when you have a Work Breakdown Structure.

Accuracy: Best — within 5-15% — because you are estimating small, concrete tasks instead of vague phases.

The catch: It takes significant effort. And it creates a false sense of precision. Just because you estimated 847.5 hours does not mean it will take 847.5 hours.

5. T-shirt sizing (the rough planning method)

You categorize work as S, M, L, or XL without attaching specific numbers. "The login system is a Medium. The recommendation engine is an XL."

When to use it: Roadmap planning, sprint planning poker, or when you need a quick relative comparison without committing to exact numbers.

Accuracy: Deliberately imprecise — that is the feature, not the bug. It prevents false precision and keeps conversations focused on relative effort.

There Are No Dumb Questions

"Which method should I use?"

Use at least two and compare. If analogous says 4 months and bottom-up says 8 months, you have a problem to investigate — not a number to average. The gap between methods tells you where your assumptions are weakest.

"What if my boss just wants a single number?"

Give them a range: "Based on our analysis, this will take 14 to 18 weeks, with 16 as the most likely." If they insist on one number, give the higher end and explain why. Under-promising and over-delivering builds trust. Over-promising and under-delivering destroys it.

Building a budget: where the money actually goes

Every project budget has four layers. Most PMs only think about the first one.

Layer 1: Direct costs

These are the costs you can tie directly to project work.

Layer 2: Indirect costs

These are the costs that keep the lights on but do not tie to a specific task.

Layer 3: Contingency reserve (10-15%)

This is your buffer for known unknowns — risks you have identified but cannot quantify exactly. "We know the API integration might have issues. We do not know how bad." The contingency reserve is controlled by the PM and drawn upon when identified risks materialize.

Layer 4: Management reserve (5-10%)

This is the buffer for unknown unknowns — things you could not have predicted. A pandemic. A vendor going bankrupt. A surprise regulatory change. The management reserve is controlled by the sponsor or executive, not the PM. You need approval to touch it.

Building a timeline: from tasks to Gantt charts

A timeline is not a list of dates. It is a visual representation of what happens when, who does it, and what depends on what.

Gantt charts: the PM's most iconic tool

A Gantt chart is a horizontal bar chart where each bar represents a task. The length of the bar shows duration. The position on the timeline shows when it starts and ends. Lines between bars show dependencies.

Notice how some tasks can run in parallel (user research and backend setup) while others must wait (frontend build cannot start until both design and backend are ready). This is the essence of project scheduling.

Milestones: your progress checkpoints

Milestones are zero-duration markers on the timeline that represent key achievements. They are not tasks — they are the moments when you can say "this phase is done."

Good milestones are specific and verifiable:

• "Design approved by stakeholders" — not "design phase"
• "MVP deployed to staging environment" — not "development done"
• "All critical bugs resolved" — not "QA complete"

Dependencies: the invisible chains

There are four types of task dependencies:

90% of dependencies are Finish-to-Start. But knowing the others exist prevents you from over-constraining your schedule.

Buffer: where to put the padding

Beginners add buffer to every task. "Design will take 3 weeks, but I will tell the team 4." The problem? Buffer hidden inside tasks gets consumed invisibly — Parkinson's Law says work expands to fill the time available.

Better approach: Keep task estimates honest and add a project-level buffer at the end or before critical milestones. A 12-week project might have a 2-week buffer. If nothing goes wrong, you finish early. If things slip, you absorb it without moving the final deadline.

<strong>Rule 1: Estimate tasks honestly.</strong> Do not pad individual tasks. If design takes 3 weeks, say 3 weeks.

<strong>Rule 2: Add buffer at the project level.</strong> Put a buffer block before the final deadline — 15-20% of total duration.

<strong>Rule 3: Protect the buffer.</strong> The buffer is not free time. It is insurance. Do not let scope creep eat it in week 2.

<strong>Rule 4: Track buffer consumption.</strong> If you have burned 80% of your buffer at 50% of the timeline, raise the alarm now.

Resource management: people are not interchangeable

A "resource" in PM-speak usually means a person. And people are not fungible — you cannot swap a backend developer for a frontend developer any more than you can swap a plumber for an electrician.

The three questions of resource planning

1. Who do you need? What skills, what seniority, what domain expertise?
2. For how long? Full-time for the whole project? Part-time for two sprints? One day for a security review?
3. When do you need them? A UX researcher in week 1 is critical. A UX researcher in week 10 is useless.

Brooks's Law: the mythical man-month

In 1975, Fred Brooks published The Mythical Man-Month, and the central insight still holds: adding people to a late project makes it later.

Why? Because new team members need to be onboarded (consuming existing team members' time), communication overhead increases exponentially (a team of 4 has 6 communication channels; a team of 8 has 28), and the work often cannot be parallelized ("9 women cannot have a baby in 1 month").

The formula: n(n-1)/2 where n is team size. Every person you add does not just add capacity — they add complexity.

Resource leveling: stop overloading your people

Resource leveling means adjusting the schedule so that no person is allocated to more than 100% capacity. If your designer is assigned to three projects and each expects 50% of her time, that is 150%. Something has to give — and it will be quality, deadlines, or her sanity.

Practical steps:

• Map each person's allocation across all projects (not just yours)
• Flag anyone above 80% utilization (you need slack for meetings, email, and unexpected work)
• Shift non-critical tasks to periods when the person has availability
• If nobody has availability, you have a staffing conversation, not a scheduling one

There Are No Dumb Questions

"If adding people makes things worse, what do you do when a project is late?"

You have four options: reduce scope (cut features), extend the timeline (move the deadline), improve efficiency (remove blockers, automate, simplify), or accept lower quality (ship with known issues — sometimes the right call). Adding headcount is the last resort, and only works if the new people can work on truly independent tasks that require minimal coordination.

"Is the 'multiply by pi' thing serious?"

Semi-serious. Studies consistently show that software estimates are 2-3x optimistic. The pi multiplier (3.14x) is a tongue-in-cheek acknowledgment that developers estimate the coding time but forget about testing, deployment, documentation, code review, meetings, bug fixes, and the three times the requirements will change. The structured techniques above are better than multiplying by pi. But multiplying by pi is better than taking the raw developer estimate at face value.

Tracking and reporting: are we on track?

You have a budget, a timeline, and resources allocated. The project starts. Now what? You measure relentlessly.

Burn-down charts

A burn-down chart shows work remaining over time. The y-axis is remaining work (in hours, story points, or tasks), the x-axis is time. An ideal line slopes steadily downward. Reality is always bumpier.

What the chart tells you:

• Line tracking below ideal: You are ahead of schedule.
• Line tracking above ideal: You are behind — investigate now.
• Flat line: No progress. Something is blocked.
• Line going UP: Scope is being added faster than work is being completed. Emergency.

Budget vs. actual

Track spending against the plan at regular intervals. A simple table works:

The variance column is your early warning system. Small overruns in week 3 become catastrophic overruns by week 12 if left unchecked.

The traffic light status report

The simplest executive reporting format. For each dimension, assign a color:

• Green: On track, no action needed.
• Yellow (Amber): At risk, action plan in place, monitoring closely.
• Red: Off track, escalation needed, decisions required.

Executives love this format because they can scan it in 10 seconds. If everything is green, they move on. If something is red, they know exactly where to focus.

When to re-plan vs. when to push through

Not every problem requires a new plan. But some problems demand one. Knowing the difference is a core PM skill.

The decision framework is simple: Can you recover within your existing buffer and contingency, or has the foundation shifted? If you can recover, push through with adjustments. If the foundation has shifted, stop and re-plan — continuing on the old plan is just organized wishful thinking.

When you re-plan, do it openly. Call a meeting. Show the data. Present the new reality and the new plan. Stakeholders respect a PM who says "the situation has changed and here is our updated path forward" far more than one who silently hopes things will get better.

Back to Marcus and the VP

Marcus told the VP "about 3 months" after thinking for three seconds. He knew at week four that the estimate was impossible, but he said nothing and hoped the team could make up the time. They could not. If Marcus had used a structured estimation technique — even a simple PERT estimate combining optimistic, likely, and pessimistic scenarios — the original number would have included a buffer. And if he had tracked progress with a burn-down chart and reported the variance early, the VP would have heard "we need more time" at week four, not month three. Estimation is not clairvoyance; it is discipline. And bad news delivered early, with options, builds trust. Bad news delivered late destroys it.

Key takeaways

• Use structured estimation techniques — analogous, parametric, PERT, bottom-up, or T-shirt sizing. Use at least two and compare results.
• Budgets have four layers: direct costs, indirect costs, contingency reserve (10-15% for known unknowns), and management reserve (5-10% for unknown unknowns). Cutting the reserves is borrowing from your future self.
• Gantt charts visualize what, when, who, and dependencies. The critical path determines minimum duration. Add buffer at the project level, not per task.
• People are not interchangeable. Brooks's Law: adding people to a late project makes it later. Resource leveling prevents burnout. Team communication channels grow as n(n-1)/2.
• Track relentlessly: burn-down charts for progress, budget-vs-actual for spending, traffic light reports for executive communication.
• Re-plan when the foundation shifts. Push through when buffer absorbs the impact. The worst option is doing neither — silently hoping a broken plan will fix itself.