Project Management: Budget, Time and Risk
Estimating with three points, the probability of meeting a date, contingency, risk scoring and decision gates.
Plan around the questions
A prototyping project is a sequence of questions, each answered by a build and a test (see The Prototyping Process and Its Stages). A plan lists them in order of risk, with who does what, how long it takes, what it costs and what decision follows. It need not be elaborate: a one-page schedule and a budget are enough for most projects, provided they are honest.
- List the tasks and their dependencies: which cannot start until another finishes.
- Find the critical path: the longest chain of dependent tasks. Delay it and the project is delayed; tasks with slack can run in parallel or move.
- Do the risky tasks first and put the safe ones in the slack.
- Overlap work: write the firmware on a dev board while the case is built.
- Keep the plan short and visible, and update it every week.
Estimating time with three points
People estimate the typical case and forget the bad ones. A three-point estimate asks for an optimistic time (a), a most likely time (m) and a pessimistic time (b), and combines them: expected time = (a + 4m + b) ÷ 6 and standard deviation σ = (b − a) ÷ 6 (the PERT method). Over a chain of tasks the expected times add, and the variances add.
Worked example: a seven-task critical path (weeks)
| Task | Optimistic a | Most likely m | Pessimistic b | Expected | σ |
|---|---|---|---|---|---|
| Requirements | 0.5 | 1.0 | 2.0 | 1.08 | 0.25 |
| Mock-up and user feedback | 1.0 | 2.0 | 4.0 | 2.17 | 0.50 |
| CAD and simulation | 2.0 | 3.0 | 6.0 | 3.33 | 0.67 |
| Prototype build | 3.0 | 4.0 | 8.0 | 4.50 | 0.83 |
| Testing | 2.0 | 3.0 | 6.0 | 3.33 | 0.67 |
| Second iteration | 3.0 | 5.0 | 10.0 | 5.50 | 1.17 |
| Pilot build | 3.0 | 4.0 | 8.0 | 4.50 | 0.83 |
| Total (critical path) | 24.4 | 1.99 |
- The most-likely times add to 22 weeks, but the expected total is 24.4 weeks: the pessimistic tails pull it up. The standard deviation of the total is √(Σσ²) = 1.99 weeks (the variances add, so the total is relatively more certain than each task).
- Tasks with a long tail (the second iteration: 3 to 10 weeks) dominate the uncertainty: look for ways to reduce their risk first.
People tend to under-estimate by a third or more: if you think a task takes 20 hours, plan for 30 (the “planning fallacy”). The three-point method forces you to think about what could go wrong.
The probability of meeting a date
Worked example: can we finish in 26 weeks?
- The expected total is 24.4 weeks with σ = 1.99 weeks. For a deadline of 26 weeks: z = (26 − 24.4) ÷ 1.99 = 0.80; the probability of finishing in time is Φ(z) = 79 %.
- A date of 28 weeks gives 96 %. For a 90 % chance, quote 27.0 weeks; for 95 % quote 27.7 weeks. The buffer beyond the expected time is 2.5 weeks.
- At $400 a week of project cost, protecting a 90 % date means budgeting $1 019 more than the expected case, or removing the risks that stretch the tails.
- The usual mistake is to promise the expected date (a 50 % chance) as if it were certain.
Budget and contingency
Worked example: a prototype budget
| Item | Cost |
|---|---|
| Mock-ups and materials | $150 |
| CAD / software licenses | $0 |
| Prototype 1: parts and boards | $600 |
| Prototype 2 (iteration) | $800 |
| Test equipment and consumables | $400 |
| Services (machining, casting) | $700 |
| Pilot build (50 units) | $3 200 |
| Subtotal | $5 850 |
| Contingency (25 %) | $1 463 |
| Budget | $7 313 |
- A contingency of 25 % is normal for a first prototype project (10 % for a well-understood job, 30 % or more for a new technology). Spend it only with a reason.
- Include your own time at a real rate, even if nobody pays it: the cost of the project is the cost of the effort too (see Sourcing, Services and Outsourcing).
- Track the budget against the plan every week: money spent is easier to measure than progress.
Risk register
A risk register lists what could go wrong, how likely it is, what it would cost and what you will do about it. The expected value of a risk is probability × impact.
Worked example: five risks
| Risk | Probability | Impact | Expected cost | Response |
|---|---|---|---|---|
| Snap-fit hook breaks in testing | 40 % | $600 | $240 | Test early; use PETG; spare design |
| Supplier delivers late | 30 % | $1 500 | $450 | Second supplier; order early |
| EMC test fails | 35 % | $3 000 | $1 050 | Pre-compliance; filters planned |
| Key chip out of stock | 20 % | $2 500 | $500 | Alternate part on the board |
| Scope grows | 50 % | $1 200 | $600 | Change control; gate reviews |
| Expected total | $2 840 | Compare with the contingency of $1 463 |
- The expected cost of all risks is $2 840, about 49 % of the base budget: the contingency of $1 463 covers the expected value but not a bad year, so it is prudent to reduce the largest risks (the EMC test: do pre-compliance early).
- Review the register every week: retire the risks that have passed and add the new ones.
Decision gates
| Gate | Criterion to pass | Decision |
|---|---|---|
| G1 Concept | Requirements written; riskiest question chosen | Go / change the question |
| G2 Proof of concept | The core idea works on a breadboard or mock-up | Go / pivot / stop |
| G3 Works-like | Meets the key requirements in tests (see Testing) | Go / iterate |
| G4 Pilot | Cost and yield on target; tests passed | Release to production |
- Agree the criteria before the build, so that the decision is not made by enthusiasm.
- Be ready to stop or change direction: the sunk cost is gone; only the future cost and value matter.
- Keep gates light for a small project: a page and a conversation.
People, tools and communication
- Name an owner for each task and for the project; shared ownership means no ownership.
- Know what you cannot do and get a specialist early (EMC, compliance, tooling) rather than late.
- Keep one source of truth: a repository for CAD, firmware and documents; a shared task list.
- Meet briefly and often: a ten-minute weekly review of the plan, risks and budget.
- Write decisions down with the reason: an email or a log entry is enough.
- Tell the customer or sponsor early when the date moves: the earlier the more options.
Habits that keep a project on track
- Time-box every task and decide before you start what “done” means.
- Finish the riskiest thing first.
- Say no to features until the core works (scope creep is the commonest cause of delay).
- Measure progress by tests passed, not by effort spent.
- Keep a spares kit of the common parts, so that a failure costs minutes and not a week.
- Review at the end of each build and of the project: what to repeat, what to change.
Troubleshooting
| Problem | Likely cause | Try |
|---|---|---|
| The project is always late | Estimates use the typical case; no buffer | Three-point estimates; quote the 90 % date; reduce the long-tail tasks |
| Budget overrun | Hidden costs, scope growth, respins | Track weekly; keep contingency; change control |
| Scope keeps growing | No fixed requirements | Write requirements and gate criteria; log every change request |
| Nobody knows the status | No plan or no review | A one-page plan and a weekly ten-minute review |
| Surprises late in the project | Risky questions left until last | Rank by risk; test the riskiest first |
| Team disagreement on direction | No agreed gate criteria | Agree the criteria in advance; decide with data |
Related
- Prototyping Techniques: the overview of this guide.
- The Prototyping Process and Its Stages: stages and iterations.
- From Prototype to Production: the end of the plan.
- System Integration: project stages for a machine or plant.
FAQ
How do I estimate how long a prototype will take?
Make a three-point estimate (optimistic, likely, pessimistic) for each task, combine them as (a + 4m + b) ÷ 6, and add them along the critical path.
What is the critical path?
The longest chain of tasks that depend on each other: it sets the minimum duration of the project, and any delay in it delays the end.
How much contingency should I include?
About 10 % for a well-understood job, 25 % for a first prototype project and 30 % or more for something new.
What is a decision gate?
A checkpoint with agreed criteria where you decide to go on, change direction or stop, so that the project does not drift.
Why do projects overrun?
Estimates are made for the typical case, risks are ignored and the scope grows. Three-point estimates, a risk register and change control address all three.
References
- Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide) (three-point estimating, risk).
- Malcolm, D. G. et al., “Application of a technique for research and development program evaluation” (PERT), Operations Research 7 (1959).
- Cooper, R. G., Winning at New Products, Basic Books (stage-gate); Kahneman, D. and Tversky, A. on the planning fallacy.
Last reviewed: October 2026. The estimates, costs and probabilities are an example: use your own tasks and rates. The normal approximation is a guide.