The prompt
Score 10 of 10, Excellent
Use it when You need task and project estimates that show a realistic range and a figure you can commit to, instead of one optimistic number.
- {{project_summary}}
- {{audience_and_decision}}
- {{unit}}
- {{history}}
- {{task_estimates}}
Full prompt and why it works
Prompt
Project: {{project_summary}} Who the estimate is for and what they will decide: {{audience_and_decision}} Unit of estimate: {{unit}} Past experience with similar work, if known: {{history}} Tasks, with the team's best case, most likely and worst case for each (or a note if not yet estimated): """ {{task_estimates}} """ Task: Turn the team's estimates above into a three-point estimate for each task and for the whole project, for {{audience_and_decision}}. I need a range and a figure we can commit to at a stated level of confidence, so that nobody plans around the best case. Format: 1. Task table with the columns Task, Best, Likely, Worst, Expected, Spread. Expected = (Best + 4 × Likely + Worst) ÷ 6. Spread = (Worst - Best) ÷ 6. One decimal place. 2. Totals: the sum of the expected values and the combined spread: the square root of the sum of the squared spreads. Show the arithmetic. 3. Commitment levels: the total at roughly 50%, 84% and 98% confidence (the expected total, plus one and plus two combined spreads), with a sentence saying these assume the tasks are independent, which they often are not, so treat them as a guide. If past experience shows estimates running over, add one line with the total at that rate, kept separate from the team's figures. 4. Widest tasks: the three with the largest spread, and what would narrow each (a trial run, a decision, a supplier's answer). 5. Not estimated: tasks with missing numbers, listed for the team rather than filled in. A good estimate is one the sponsor can commit to knowing how likely it is to hold, and that the team recognizes as their own numbers. Example of one task row's form only, with invented numbers: "Data migration | 4 | 6 | 14 | 7.0 | 1.7" Requirements: - Use only the team's numbers. Do not change an estimate you think is unrealistic; flag it with your reason instead. - If a worst case is lower than the likely case, or a best case higher, flag the row and keep it out of the totals until the team fixes it. - Keep the team's unit, and do not turn effort into calendar time unless I gave the hours per day people have. - Under 400 words, plus the table. If some tasks run in parallel, note that the project's duration depends on its longest chain of tasks, not the total, and ask which tasks overlap if that is not clear.
Variables
- {{project_summary}}
- One or two sentences on the project, for example "moving our client records to a new CRM by March".
- {{audience_and_decision}}
- For example "the sponsor, who must confirm the go-live date".
- {{unit}}
- For example "person-days of effort" or "working days".
- {{history}}
- For example "our last migration took 40% longer than estimated". Write "none" if unknown.
- {{task_estimates}}
- One line per task: name, best, likely and worst case, in the unit above.
Why it works
- What good looks like. The formulas for expected value and spread are given, with the arithmetic shown, so every number in the estimate can be checked.
- What to avoid. The team's numbers are never changed, only flagged, and confidence levels come with the warning that tasks are rarely independent.
- If unsure. Rows where the worst case is below the likely case, and tasks with no estimate, are held out of the totals and sent back to the team.