Pre-Activation Estimation Guideline
Department
Summary
PM playbook for producing estimates before project activation: how to deliver an indicative range (Sales step 3-4) and a detailed breakdown (Sales step 8-9). Two methodologies — top-down for the indicative range; PERT 3-point per task for the detailed breakdown. Closes with a calibration loop so estimates get sharper over time.
Table of Contents
Purpose
This guideline defines how a PM produces pre-activation estimates so Sales can present defensible numbers to the client and Account Management can produce defensible proposals. It covers two distinct moments in the lead-to-deal flow: a fast top-down indicative range, and a rigorous PERT-based detailed breakdown.
| Outcome |
|---|
| Two reproducible methodologies that produce estimates Sales can quote, Account Management can defend, and Delivery can later compare against actuals. |
Prerequisites
Before using this guideline, review:
| # | Document | Purpose |
|---|---|---|
| 1 | Scope Definition & Price Assessment Guideline | The Sales playbook that calls into this guideline at steps 3-4 (indicative range) and steps 8-9 (detailed breakdown). |
| 2 | Delivery Production & Resource Allocation Guideline | The post-activation execution playbook that consumes the detailed breakdown produced here. |
| 3 | Privacy & Data Handling Guideline | No client/contact PII in Asana; secure storage + link only. |
| 4 | Official Docs Format Guide | If this guideline ever needs updating, keep formatting consistent. |
Scope
This guideline covers pre-activation estimation owned by the PM: from receiving a Sales request for an indicative range, through delivering the detailed breakdown that becomes the basis of the final proposal. Post-activation estimation (atomic tasks with DoD, sprint planning) is covered by the Delivery Production & Resource Allocation Guideline.
| Includes | Excludes |
|---|---|
| Indicative range methodology (budget range, timeline range, scoping fee suggestion) | Post-activation atomic task planning (see Delivery Production guideline) |
| Detailed breakdown methodology (per-task hours, timeline, assumptions, risks) | Final proposal writing (Account Management) |
| Calibration loop (recording actuals after projects ship) | Pricing math (markup, cost basis — see Bottom-Up Pricing) |
Definitions
| Term | Definition |
|---|---|
| Indicative range | The early estimate produced before the client commits anything. Output: a budget range, a timeline range, and a suggested scoping fee. Wide confidence band is acceptable. |
| Detailed breakdown | The rigorous estimate produced after the client pays the scoping fee. Output: per-task estimates by role, total hours, timeline, assumptions, risks. Basis for the final fixed-price proposal. |
| Scoping fee | The small fee the client pays after seeing the indicative range, to commission the detailed breakdown. Defined in the Sales playbook (Step 7). |
| PERT estimate | Weighted three-point estimate per task: (Optimistic + 4 × Likely + Pessimistic) / 6. Approximates the expected value of a beta distribution. |
| σ (sigma) per task | Standard deviation per task: (Pessimistic - Optimistic) / 6. A measure of uncertainty for one task. |
| σ across the project | Combined uncertainty across all tasks: √(Σ σ²). Variances of independent estimates add; standard deviations don’t. |
| Confidence band | The range around the PERT estimate that captures a given probability. 80% band: PERT ± 1.282 × σ. 90% band: PERT ± 1.645 × σ. |
| Reference class | A set of past Kiluth projects similar enough to the new one that their actuals anchor the new estimate. Stored in estimation-actuals.csv (workspace) and grows as projects ship. |
| Productive hours per day | Default 6. Actual focused output time per working day, not clock hours. Used to convert hour estimates into manday estimates for the client-facing timeline. |
| Discovery buffer | Additional hours added to the PERT estimate to account for unknowns at quote time. Scales with the count of explicit unknowns, not as a flat percentage. |
Operating Model
| # | Operating Model |
|---|---|
| 1 | Asana is the system of record for work tracking, approvals, and handoffs. |
| 2 | Use checkpoints and decision points: don’t move forward until the previous step is “done”, and branches are explicit. |
| 3 | Handoff order: upstream defines handoff artifacts/exit criteria; downstream defines execution after handoff. |
| Outcome |
|---|
| At any time we can answer: which estimate is in flight, who owns it, what “done” means, and where the artifact lives. |
When this guideline applies
This guideline is invoked by the Sales playbook at two distinct points. PM should know which methodology Sales is asking for based on which Asana request task is assigned.
| Trigger | Methodology | Output | Typical effort |
|---|---|---|---|
| Sales creates Asana task “Request indicative range” and assigns PM | Phase A: Indicative Range | Budget range + timeline range + scoping fee | 2-4 hours |
| Sales creates Asana task “Request detailed breakdown” and assigns PM (after scoping fee is paid) | Phase B: Detailed Breakdown | Per-task estimates, total hours, timeline, assumptions, risks | 1-3 working days depending on project size |
Phase A: Indicative Range Methodology
What you’ll do: Produce a fast top-down estimate so Sales can present a budget range, a timeline range, and a suggested scoping fee to the client. Wide confidence is acceptable at this stage — the goal is to set expectations, not to commit.
Step 1: Read the scope sign-off
Prerequisites: The Asana task “Request indicative range” exists and is assigned to PM; the description contains a link to the scope sign-off proof (see Sales playbook Step 2).
Process:
| Action | |
|---|---|
| 1 | Open the scope sign-off proof linked from the Asana task. Read it end-to-end. |
| 2 | Note explicit deliverables, deadlines, and budget signals captured by Sales. |
| 3 | Note ambiguities or open questions that you cannot resolve from the sign-off alone. |
Checkpoint: You can describe the engagement in one paragraph without going back to the sign-off.
| Outcome |
|---|
| You understand what is being asked for at a level sufficient to anchor a top-down estimate. |
Step 2: Find reference projects
Prerequisites: Step 1 is complete.
Process:
| Action | |
|---|---|
| 1 | Open the estimation-actuals.csv file in the workspace (departments/delivery/artifacts/estimation-actuals.csv). |
| 2 | Find 1-3 past projects that resemble the new one — same domain, similar scale, similar client type. |
| 3 | Note their actual hours and the post-mortem notes for what went off. |
| 4 | If the file is empty or contains no similar projects, record this explicitly in the indicative range artifact. |
Why this matters: Reference projects anchor the estimate in evidence, not imagination. First-principles estimates are reliably off by 2-3×; reference-class anchoring closes most of that gap.
| Outcome |
|---|
| You have 1-3 anchor projects whose actuals inform the range, or an explicit note that no analog exists yet. |
Step 3: Identify scope-driving factors
Prerequisites: Step 2 is complete.
Process:
| Action | |
|---|---|
| 1 | Identify the 3-5 factors that most strongly drive the engagement’s effort (e.g. number of integrations, system count, channel count, content production responsibility, language scope, hosting decisions). |
| 2 | For each factor, note whether the new engagement is at the lower, typical, or upper end of what the reference projects faced. |
| 3 | If a factor is unknown at this stage, mark it as an unknown — it becomes input to the discovery buffer in Phase B if the engagement proceeds. |
| Outcome |
|---|
| You have a small set of named factors that explain why this engagement sits at a particular point in the range. |
Step 4: Produce the range
Prerequisites: Steps 1-3 are complete.
Process:
| Action | |
|---|---|
| 1 | Anchor on the closest reference project’s actual hours. |
| 2 | Adjust up or down based on scope-driving factors from Step 3. |
| 3 | Express the result as a range: [low — high] hours, with a ratio of roughly 1.5× to 2× between low and high (wider if unknowns are large). |
| 4 | Convert to a budget range using the team’s day rate (see Scope Definition & Price Assessment Guideline for current rates by role). |
| 5 | Convert to a timeline range using the planned team size and 6 productive hours per day. |
| 6 | Suggest a scoping fee proportional to the complexity of the detailed breakdown work the PM will do in Phase B — typically 5-10% of the lower bound of the budget range. |
| Outcome |
|---|
| You have three numbers Sales can present: budget range, timeline range, scoping fee. |
Step 5: Deliver the artifact and close the task
Prerequisites: Step 4 is complete.
Process:
| Action | |
|---|---|
| 1 | Write a short artifact (one page or less) summarizing: engagement description, scope-driving factors, reference projects used, the budget range, the timeline range, the scoping fee suggestion, and key assumptions. |
| 2 | Store the artifact in secure storage with restricted access. |
| 3 | Add the artifact link to the Asana task. Do not paste PII into the task. |
| 4 | Return the task to Sales (reassign / mark complete per your team’s Asana convention). |
| Outcome |
|---|
| Sales has the range artifact linked in Asana and can proceed to present to the client (Sales playbook Step 5). |
Phase B: Detailed Breakdown Methodology
What you’ll do: Produce a rigorous PERT-based per-task estimate that Account Management can turn into a fixed-price proposal. Triggered after the client has paid the scoping fee, so the PM is expected to spend meaningful effort here.
Step 1: Read the indicative range and updated scope
Prerequisites: The Asana task “Request detailed breakdown” exists and is assigned to PM; scoping fee is confirmed paid; the description links to the indicative range artifact from Phase A and any updated scope notes from the client conversation that followed.
Process:
| Action | |
|---|---|
| 1 | Re-read the indicative range artifact you produced in Phase A. |
| 2 | Identify what has changed in scope since then (client refinements, new requirements, dropped features). |
| 3 | Re-confirm the reference projects from Phase A are still the closest analogs given the updated scope. |
| Outcome |
|---|
| You are working from the latest scope, not the original sign-off. |
Step 2: Decompose into features
Prerequisites: Step 1 is complete.
Process:
| Action | |
|---|---|
| 1 | List every feature, module, page, or atomic deliverable as a separate row in your working document. |
| 2 | If a feature is too vague to estimate in three numbers, break it down further or move parts of it to an explicit unknowns list. |
| 3 | For each feature, capture a short notes field for assumptions specific to that feature. |
| Outcome |
|---|
| A complete feature list where every row is something a developer or designer would recognize as one unit of work. |
Step 3: Three-point estimate per feature
Prerequisites: Step 2 is complete.
Process:
| Action | |
|---|---|
| 1 | For each feature, estimate Optimistic hours (everything goes right, no surprises). |
| 2 | Estimate Likely hours (normal day, normal bugs, expected friction). |
| 3 | Estimate Pessimistic hours (Murphy strikes — undocumented API, scope creep within the feature, unexpected dependency). |
| 4 | Compute the PERT estimate per feature: (O + 4 × L + P) / 6. |
| 5 | Compute σ per feature: (P - O) / 6. |
| 6 | Sum the PERT estimates across all features for the project total. |
| 7 | Compute σ across the project: √(Σ σ²) — sum of squares of per-feature σ, then take the square root. |
Why be honest about Pessimistic: It is the most-skipped, most-load-bearing number. Optimism in Pessimistic is the single most common cause of estimates that under-quote by 50% or more.
| Outcome |
|---|
| You have a PERT total (in hours) and a project-level σ (in hours). |
Step 4: Add buffers
Prerequisites: Step 3 is complete.
Process:
| Action | |
|---|---|
| 1 | Apply a QA buffer of 20% of the PERT total (default; adjust for projects with unusually heavy QA needs). |
| 2 | List explicit unknowns at quote time — things the client has not yet decided, or technical questions still open. |
| 3 | Apply a discovery buffer of 5% of the PERT total per unknown listed. Five unknowns means a 25% discovery buffer. |
| 4 | Sum: Final hours = PERT + QA + Discovery. |
Why discovery scales with unknowns: Risk is a function of what we don’t know, not of how much code we write. A 100-hour project with five open architectural questions is much riskier than a 100-hour project with none. Tying the buffer to the unknowns list also creates pressure to resolve unknowns rather than just absorbing them.
| Outcome |
|---|
| You have a Final hours number that includes QA and discovery. |
Step 5: Compute confidence bands
Prerequisites: Step 3 is complete (σ available).
Process:
| Action | |
|---|---|
| 1 | Pick the confidence target appropriate for the engagement. Default: 80%. |
| 2 | Compute the low end of the band: PERT − z × σ. |
| 3 | Compute the high end of the band: PERT + z × σ. |
| 4 | The z value depends on the confidence target chosen — see Method (for the curious) for the exact values. |
| Outcome |
|---|
| You have a confidence range around the PERT total that Account Management can use to defend the quote. |
Step 6: Convert to mandays and timeline
Prerequisites: Step 4 is complete.
Process:
| Action | |
|---|---|
| 1 | Divide Final hours by 6 productive hours per day to get mandays. |
| 2 | Divide mandays by the planned team size to get calendar working days. |
| 3 | Add typical coordination overhead (kickoff, weekly reviews, handoffs) to produce the timeline range. |
Why 6 productive hours per day: Tracked attention data across knowledge workers converges on 4-6 hours of real focused output, not 8. Quoting against 8 productive hours per day reliably produces timelines that slip. The client pays for the calendar; Kiluth quotes against the realistic delivery cadence. |
| Outcome |
|---|
| You have a mandays total and a calendar timeline range. |
Step 7: Document assumptions and risks
Prerequisites: All prior steps are complete.
Process:
| Action | |
|---|---|
| 1 | List explicit assumptions that drive the estimate (e.g. brand assets supplied by the client, hosting decisions, language scope). |
| 2 | List unknowns from Step 4 with a one-line note on each. |
| 3 | List key risks — things that could materially change the estimate if they materialize. |
| 4 | Note that if any assumption is contradicted at activation, the estimate should be re-run before the contract is signed. |
| Outcome |
|---|
| Account Management has the context needed to defend the number against client pushback and identify when scope changes warrant a re-estimate. |
Step 8: Deliver the artifact and close the task
Prerequisites: Steps 1-7 are complete.
Process:
| Action | |
|---|---|
| 1 | Write the detailed breakdown artifact: per-feature table with O / L / P / PERT / σ, total PERT, σ across project, QA buffer, discovery buffer, final hours, confidence band, mandays, timeline, assumptions, unknowns, risks. |
| 2 | Store the artifact in secure storage with restricted access. |
| 3 | Add the artifact link to the Asana task. Do not paste PII into the task. |
| 4 | Return the task to Sales (reassign / mark complete per your team’s Asana convention). |
| Outcome |
|---|
| Account Management has the breakdown linked in Asana and can proceed to write the final proposal (Sales playbook Step 10). |
Calibration loop
The methodology gets sharper over time only if estimate-vs-actual is recorded after every shipped project. Without this loop, the framework is theatre.
When a project ships
Process:
| Action | |
|---|---|
| 1 | Open departments/delivery/artifacts/estimation-actuals.csv in the workspace. |
| 2 | Append one row capturing: project ID, date estimated, date completed, estimator, one-line description, domain tags, estimated PERT hours, estimated 80% confidence low and high, actual hours, variance percentage, post-mortem notes. |
| 3 | Commit and push the change. |
Why this matters: After ~10 entries, the data can answer “which kinds of work do we systematically underestimate?” and “which feature types have the widest variance?” — and the next estimate gets sharper.
| Outcome |
|---|
| The reference-class corpus grows; future estimates anchor on real Kiluth actuals, not imagination. |
Method (for the curious)
The math is standard project-estimation literature. None of it is novel. Most software engineers haven’t read it.
| Concept | Detail |
|---|---|
| PERT 3-point estimation | Weighted mean: (O + 4·L + P) / 6. Approximates the expected value of a beta distribution. Invented by the US Navy in 1958 for the Polaris missile program. |
| Per-task σ | (P − O) / 6. Under the beta-distribution assumption, the span from optimistic to pessimistic covers approximately 6 standard deviations. |
| Project-level σ | √(Σ σ²) across features. Variances of independent estimates add; standard deviations don’t. |
| Confidence band z-values | 50%: 0.674. 80%: 1.282. 90%: 1.645. 95%: 1.960. Standard normal distribution quantiles. |
| Discovery buffer scales with unknowns | A flat percentage buffer punishes well-scoped projects and rewards vague ones. Scaling with explicit unknowns ties the buffer to what we actually don’t know, and creates pressure to resolve unknowns before quoting. |
| 6 productive hours per day | Across decades of attention-tracking studies, focused knowledge work converges on 4-6 hours of real output per day, not 8. |
If you want to go deeper: Steve McConnell, Software Estimation: Demystifying the Black Art (2006); Daniel Kahneman, Thinking, Fast and Slow (the chapter on “the outside view”); Tom DeMarco, Slack and Peopleware.
Checklist (PM Use)
Before returning the estimate task to Sales, verify:
| Checklist | |
|---|---|
| 1 | ☐ Reference projects were consulted (or absence noted explicitly) |
| 2 | ☐ Scope-driving factors are named, not implied |
| 3 | ☐ For Phase B: every feature has Optimistic / Likely / Pessimistic numbers, not just a point estimate |
| 4 | ☐ For Phase B: Pessimistic was filled in honestly, not as Likely + 10% |
| 5 | ☐ QA buffer is applied |
| 6 | ☐ Discovery buffer is applied; unknowns are listed individually |
| 7 | ☐ Confidence band is stated explicitly, not just the point estimate |
| 8 | ☐ Mandays use 6 productive hours per day, not 8 |
| 9 | ☐ Assumptions, unknowns, and risks are listed with one-line context each |
| 10 | ☐ Artifact is stored in secure storage and linked from the Asana task; no PII in the task |
Related / Next
| Document | Purpose |
|---|---|
| Scope Definition & Price Assessment Guideline | The Sales playbook that calls this guideline at steps 3-4 and 8-9. |
| Delivery Production & Resource Allocation Guideline | Post-activation execution — consumes the detailed breakdown produced here. |
| Privacy & Data Handling Guideline | No PII in Asana; secure storage + link only. |
| Official Docs Format Guide | Formatting rules if this guideline needs updating. |