A fixed price is reliable only when the work is clearly defined. A client may explain the result they want while leaving important details unclear, such as quantities, responsibilities, review limits, required inputs, or special conditions. An hour estimate is also difficult to trust when it is not connected to specific deliverables and known assumptions.
Scope definition and estimation therefore need to be developed together. The scope explains what the project includes; the estimate explains the work required to deliver it. Together they create the project baseline: the agreed scope and estimate used as the reference for pricing, deadlines, revisions, and later changes.
This baseline is used directly by the Project Decision tool, where it supports project economics, workload planning, deadline evaluation, and later project reviews.
1. Develop scope and estimation together
A fixed-price estimate is only as reliable as the scope behind it. Estimating before the work is clearly defined creates uncertainty, weakens pricing decisions, and makes disagreements more likely once the project begins.
Broad project descriptions rarely provide enough information to estimate accurately. Statements such as “prepare a market analysis,” “develop a training program,” or “design a website” describe an intention, not a scope detailed enough to estimate. Before assigning hours, convert those broad ideas into clearly defined deliverables that can be counted, reviewed, and accepted.
This definition process answers questions such as:
- What exactly will be delivered?
- How many deliverables or repeated units are included?
- What details and requirements must each deliverable meet?
- What assumptions already exist?
- What inputs or responsibilities belong to the client?
- How will completion be verified?
Once those questions are answered, estimating estimating the work becomes a clear process instead of a rough guess.
Scope and estimation depend on each other
Scope definition and estimation should develop together rather than as separate activities. As the project becomes more clearly defined, the estimate becomes more reliable. Likewise, estimating often reveals missing assumptions, undefined deliverables, hidden work, or unresolved risks that require additional clarification.
Use the estimate to check whether the scope is complete, not only to calculate hours. If the estimate is difficult to explain, the scope probably needs more detail.
The same number of hours can describe different projects
Suppose two professionals each estimate 120 hours for what appears to be the same project.
| First estimate assumes | Second estimate assumes |
|---|---|
| Five deliverables | Eight deliverables |
| One revision round | Three revision rounds |
| Client-supplied materials | Research included |
| A documented approval process | No defined approval process |
Both estimates may make sense on their own, yet they describe different projects. The difference lies in the scope, not in the arithmetic.
Every refinement to the scope improves the estimate, and every refinement to the estimate tests whether the scope is complete. Developing both together produces estimates that are easier to explain, easier to defend, and easier for clients to understand before work begins.
2. Define the project outcome
Begin with the result the project is intended to create. A detailed task list is not enough if the purpose of the work remains unclear. Defining the outcome first helps ensure that the scope, deliverables, and estimate support the result the client actually needs.
Clarify the problem being solved
Identify the current condition, why the project is needed, and who is affected. Separate the underlying problem from the client’s first proposed solution.
For example, a request for a new report may actually reflect a need to reduce preparation time, improve data accuracy, or support a recurring management decision. A request for training may reflect inconsistent processes, repeated errors, or dependence on one experienced employee.
Understanding the underlying problem does not mean taking responsibility for every business result. It means defining the project around the need it is intended to address rather than around an initial solution that may still be incomplete.
Describe the expected result
State what should be different when the work is complete. Describe the result in a way that can be checked.
For example:
- A findings report has been delivered and approved.
- A recurring workflow can be completed using the agreed process.
- A validated dataset is available in the required format.
- A campaign package is ready for use.
- A training program has been delivered to the agreed participants.
- A set of page layouts has been reviewed and approved.
The expected result should describe the condition created by the project, not merely the activities performed during it.
Define success and completion criteria
Success criteria describe the business, operational, or user result the project is designed to achieve. Completion criteria define the specific work you must deliver, verify, and obtain acceptance for.
They may be related, but they are not the same.
| Type | Example |
|---|---|
| Success criterion | The client can prepare the required monthly performance report using the agreed process and source data. |
| Completion criterion | The reporting template, documented process, validation checklist, and training session have been delivered and accepted. |
The success criterion describes the client’s expected result. The completion criterion describes what you must deliver and what remains within your control.
Questions to resolve:
- What problem or opportunity caused the project?
- Who will use, review, approve, or maintain the result?
- What should be different when the project is complete?
- What must be delivered, and how will completion be confirmed?
- Which desired outcomes depend on factors outside your control?
3. Define clear and measurable deliverables
Deliverables convert a general outcome into specific items that can be counted, reviewed, accepted, and estimated. They should be clear enough that both you and the client can tell whether each item has been delivered as agreed.
Use a complete deliverable description
A useful deliverable definition may include:
- Type:report, document, analysis, design, campaign asset, training session, video, illustration, dataset, product entry, page, screen, integration, or another identifiable output.
- Quantity:the number of deliverables, items, repeated units, or sessions included.
- Required details:required format, dimensions, length, level of detail, quality requirements, delivery method, or technical needs.
- Included variations:alternate versions, formats, languages, audience groups, scenarios, or exceptional cases that must be covered.
- How completion will be confirmed:approved files, checked results, completed sessions, delivered documents, passed tests where needed, or written client approval.
Replace broad descriptions with specific deliverables
Broad project labels rarely provide enough information for a reliable estimate. Make them specific by defining the quantity, required details, client-provided inputs, and what must happen before the work is considered complete.
| Broad description | Clearer definition for estimating |
|---|---|
| Market analysis | One written analysis covering three agreed market segments and five named competitors, using the approved data sources, plus one findings presentation. |
| Campaign materials | Twelve final graphics in two agreed formats, using client-supplied copy and brand assets, with two included revision rounds. |
| Data preparation | Clean and validate 2,000 client-supplied records against the agreed field rules, document unresolved exceptions, and deliver the validated dataset in the agreed format. |
| Training | Two remote sessions of 90 minutes for up to eight participants, including preparation and one agreed reference document. |
| Website design | Four approved page layouts in desktop and mobile formats, using client-supplied content and brand assets, with one clickable review prototype. |
Make sure deliverables do not overlap
Clarify what is included in each deliverable so the same work is not estimated more than once. If a research report already includes data review, analysis, and charts, do not estimate those activities again as separate deliverables unless they represent additional work. Apply the same rule across project types: if a training module includes preparation and supporting materials, or a web page includes design and testing, estimate those activities separately only when they extend beyond the defined deliverable.
4. Break the project into phases and estimable work
Phases describe how the project will progress from initial clarification to final acceptance. A work breakdown then decomposes the deliverables and supporting work until the remaining items can be estimated with reasonable confidence.
The phases do not need to be identical for every project. Use only those that reflect the actual work, and adapt their sequence when activities overlap or proceed in parallel.
- 1. Discovery
Clarify the expected result, requirements, limits, people involved, available information, and unanswered questions.
- 2. Planning
Define the approach, schedule, responsibilities, key dates, required inputs, and how completion will be approved.
- 3. Production
Research, analyze, write, design, prepare, configure, or create the agreed deliverables.
- 4. Review
Prepare review materials, collect combined client feedback, implement included revisions, and confirm decisions.
- 5. Verification
Check accuracy, quality, completeness, required behavior, and whether the agreed requirements have been met.
- 6. Delivery
Prepare the final outputs, supporting documentation, transfer or handoff, training where included, and final client approval.
- 7. Support
Provide any specifically included post-delivery assistance, correction period, or help the client begin using the delivered work.
Build a work breakdown structure
Decompose each deliverable and its supporting work until every work item has a clear purpose, expected output, main inputs, dependencies, and completion condition. The objective is not to create the longest possible task list. It is to expose work that would otherwise remain hidden inside a broad project label.
- 1. Outcome: the business or user result the project is meant to achieve.
Define why the project exists.
- 2. Deliverables: the concrete outputs the client will receive.
Define what the client will receive.
- 3. Estimable work: the activities required to produce, review, and complete those deliverables.
Define how the deliverables will be produced and verified.
Project breakdown: from outcome to estimable work
What business result are we supporting?
Example outcome: Improve onboarding conversionWhat will be delivered?
Example deliverables: Report · recommendations · presentationWhat work is required?
Example work items: Research · analysis · writing · reviewStop decomposing at a useful level
A work item is usually ready to estimate when its expected output is clear, its main inputs and dependencies are known, and the remaining uncertainty is small enough to express as a credible value or range.
Break the item down further when its parts require different skills, depend on different information, are handled by different people, or have different finish points. Stop when adding more detail would take extra time without making the estimate meaningfully more accurate.
5. Select and combine estimation methods
No single estimation method works equally well for every project. Choose the approach that best matches the available information, the structure of the work, and the level of uncertainty. Many projects benefit from combining multiple methods rather than relying on only one.
For example, repeated work may be estimated parametrically, while unfamiliar or high-risk work may require bottom-up or three-point estimation. Historical projects can then be used to validate whether the overall estimate remains reasonable.
Bottom-up estimation
Best for: well-defined projects where deliverables, supporting work, and acceptance criteria can be decomposed into individual estimable items.
Break the project into individual work items, estimate each item separately, and combine the results into a total project estimate. Because each significant activity can be explained and reviewed, this approach usually provides the highest transparency and is often the preferred method for fixed-price projects.
Analogous estimation
Best for: projects that closely resemble work completed previously.
Compare the project with historical projects that were genuinely similar, not only in visible deliverables but also in scope, complexity, quality expectations, client involvement, available inputs, revision conditions, constraints, reviewers or decision-makers. Adjust the estimate for the differences that materially affect effort.
Historical comparisons are most valuable when supported by documented estimates and actual effort from completed projects.
Parametric estimation
Best for: Projects with many comparable units that require similar effort, such as records, reports, illustrations, sessions, product entries, or page layouts.
Estimate a representative unit and multiply it by the required quantity. When different categories require materially different effort, estimate them separately instead of applying a single average across all units.
Three-point estimation
Best for: Work with significant uncertainty or variability where a single estimate could create false precision.
Estimate optimistic, most likely, and pessimistic effort values to make uncertainty explicit and understand the range of possible outcomes before agreeing to a fixed price.
Historical tracking
Best for: Improving future estimates through completed project data.
Record planned and actual effort so future estimates can rely on objective evidence instead of memory alone.
Combine methods when appropriate
Large projects rarely fit a single estimation technique. Different parts of the same project may benefit from different methods depending on how predictable the work is.
Example: Combining estimation methods
Research, planning, and custom analysis
ParametricRepeated reports, records, sessions, or page layouts
Three-pointHigh-uncertainty work
Combining methods allows each part of the estimate to reflect the nature of the work instead of forcing every activity into the same estimation approach.
6. Build Estimated work
The visible deliverables rarely represent all of the work required to complete a project. Every estimate should include both the effort that produces the deliverables and the supporting work needed to plan, review, verify, communicate, and complete them successfully.
Omitting supporting work is one of the most common reasons fixed-price estimates become inaccurate. These activities may not always be visible to the client, but they still consume time and must be included in the total estimate.
Separate visible deliverables from supporting work
A deliverable may require 30 hours of visible production, yet the project may also include planning, meetings, reviews, quality verification, documentation, communication, and delivery activities. Estimating only the visible production understates the true effort required to complete the work.
Estimated work = Identified included work + Remaining estimated work
Treat supporting work as a normal part of the project rather than as unexpected overhead. If the work is necessary to deliver the agreed result, it belongs in the estimate.
Commonly overlooked work
Projects often underestimate effort because supporting activities are remembered only after work begins. Review your estimate for work such as:
- Discovery, research, and requirement clarification.
- Project planning, scheduling, coordination, and internal communication.
- Organizing source materials, files, versions, and working documents.
- Reviewing, cleaning, converting, validating, or preparing content and data.
- Meetings, follow-up, approvals, and client communication.
- Internal quality review, verification, corrections, and final checks.
- Documentation, training, delivery preparation, handoff, and acceptance.
- Administrative work, invoicing, and any agreed post-delivery support.
Not every project includes every activity, but every estimate should explicitly consider them before finalizing the total effort.
Review the estimate before committing to a price
Before calculating a fixed price, review the complete estimate one final time. Confirm that every required activity has been considered, every supporting task belongs somewhere in the estimate, and no significant work remains implied rather than identified.
A realistic estimate is not the one with the fewest hours. It is the one that most completely represents the work required to deliver the agreed outcome.
7. Estimate meetings, revisions, and custom work items
Deemzo's Project Scope inputs show how part of Estimated work is explained through meetings, revision rounds, and repeated items. They help you check whether those details match the total estimate.
Meetings
Estimate the complete work created by a meeting, not only the scheduled call. Consider preparation, attendance, notes, follow-up, task updates, and the number of team members whose time is included in your estimate.
Meeting hours = Meetings included × hours per meeting
If a one-hour meeting normally requires 20 minutes of preparation and 20 minutes of follow-up, a reasonable hours-per- meeting value may be 1.67 rather than 1.00. Use the value that reflects your actual project work.
State the expected duration, purpose, participants, format, and whether preparation and follow-up are included. An undefined “meeting” is difficult to estimate reliably.
Define the meeting frequency
The number of meetings included should reflect how the project will actually be managed. Agree on the meeting schedule before estimating the total.
Some projects require weekly progress meetings, while others are organized around project phases, coordination checkpoints, management updates, or specific decision points. The chosen frequency should match the project's workflow rather than a standard template.
When the meeting schedule is defined in advance, both parties have a clearer expectation of the communication process. The important point is to define the frequency explicitly before estimating the total number of meetings included.
Additional meetings requested outside the agreed schedule can then be evaluated as potential scope changes instead of being treated as implicitly included.
Examples of meeting schedules:
- Weekly status meetings
- One meeting per project phase
- Monthly management meetings
- Kickoff and final handoff only
- Decision meetings at key project points
- Meetings scheduled on request up to the agreed limit
Revision rounds
A revision round should represent one coordinated cycle of review, consolidated feedback, implementation, and validation. It should not silently include unlimited comments, separate feedback from multiple reviewers, or changes that introduce new requirements or additional deliverables.
Revision hours = Revision rounds included × hours per revision
State the expected size and type of changes, the number of deliverables reviewed together, the number and alignment of reviewers, and whether feedback clarification, implementation, internal review, and confirmation are included. Without these definitions, a revision round is difficult to estimate reliably.
Define when revision rounds occur
The number of revision rounds included should reflect how deliverables will actually be reviewed and approved. Agree on the review points before estimating the total revision effort.
Some projects include one revision round after each deliverable, while others provide revisions only at specific phases, milestones, or approval points. The chosen structure should match the project's workflow and the number of items that require client review.
When the revision process is defined in advance, both parties have a clearer expectation of when feedback will be requested, how it should be submitted, and how many implementation cycles are included. The important point is to define explicitly what triggers a revision round before estimating the total number of included rounds.
Additional revision rounds, fragmented feedback, or changes requested after approval can then be evaluated as potential scope changes instead of being treated as implicitly included.
Examples of revision structures:
- One revision round for each deliverable
- One revision round at the end of each project phase
- Two revision rounds before final approval
- One consolidated revision round for all related deliverables
- Revision rounds at predefined project milestones
- Revision rounds requested as needed up to the agreed limit
Custom work items
Use custom work items for repeated units that help explain the project baseline. Typical examples include reports, validated records, illustrations, training sessions, product entries, page layouts, or other countable deliverables.
Custom work item hours = Included units × hours per unit
State exactly what one unit represents, what work is included, and what assumptions were used to estimate its average effort. A clearly defined unit produces more consistent estimates and makes scope changes easier to identify.
Choose Hours per Unit carefully
Hours per unit is an average, not a promise that every unit will take exactly the same time. Base it on comparable work, a sample, historical records, or a bottom-up model of a typical unit.
Split categories whenever different groups require materially different effort. For example, standard records and exception records, simple illustrations and complex illustrations, or standard page layouts and custom page layouts may each require separate averages instead of one value that hides meaningful differences. Avoid averaging units with significantly different complexity, since this reduces the accuracy of the estimate.
8. Understand Deemzo's scope breakdown
The Project Scope section shows how Estimated work is explained by the work you identify explicitly, such as meetings, revision rounds, and custom work items. Any remaining effort is grouped as Remaining estimated work.
The complete definition of Estimated work, Identified included work, Remaining estimated work, and the calculation rules used by the tool are documented in the Project Decision Documentation.
When the breakdown exceeds the total
If Identified included work exceeds Estimated work, the estimate is inconsistent. Review the total estimate, the unit assumptions, and check whether any work has been counted more than once.
Increase Estimated work only if the original estimate genuinely omitted work. First adjust duplicated work or unrealistic unit values.
9. Avoid double counting
Double counting occurs when the same effort is included in more than one part of the estimate. This inflates the total estimate without adding new scope and makes it difficult to explain how the final price was calculated.
| Overlap | How it happens | Correction |
|---|---|---|
| Meetings counted twice | Meeting time is inside project management and also entered as an Meeting included item. | Separate meeting work from the remaining project-management estimate or keep it only in one category. |
| QA repeated | Testing is included in every deliverable's Hours per Unit and again as a full testing phase. | Keep unit-level checks in the unit and estimate only shared or final QA separately. |
| Revisions inside production | The production estimate already includes expected revisions, and revision rounds are added again. | Remove the revision allowance from production or treat it only as part of the unit estimate. |
| Coordination overlap | Project management, coordination between the people involved, and follow-up describe the same activities under different names. | Clarify what belongs in each category and count every activity once. |
| Shared setup repeated per unit | One-time setup is embedded in every page or product estimate. | Estimate one-time setup separately from repeatable unit work. |
Check that every activity is counted once
Verify that each activity has a clear place in the estimate and that no work is counted more than once.
- 1. List every major work activity in plain language.
- 2. Identify where each activity appears in the estimate.
- 3. Confirm that shared work is counted once.
- 4. Confirm that each repeated unit excludes one-time setup unless intended.
- 5. Reconcile Identified included work with Estimated work.
Reconciliation is the final quality check for the estimate. It confirms that the scope is complete, every required activity has been included, and no work has been counted twice.
10. Document assumptions, exclusions, and dependencies
A fixed-price estimate is valid under stated conditions. Those conditions should be visible before the price is accepted, not discovered only when the project begins to deviate.
Assumptions
Assumptions describe conditions used to build the estimate. Write them specifically enough that their failure can be recognized and discussed.
The following are the key assumptions used when estimating the project.
The client provides the agreed source materials, content, data, or other required inputs by the agreed date and in the required format.
Required files, locations, equipment, accounts, credentials, permissions, or other necessary resources are available when needed.
Questions, review requests, and approval decisions receive a response within the agreed number of business days.
One authorized decision-maker provides consolidated approval or feedback unless a different review process has been agreed.
The client's processes, systems, equipment, facilities, data, and working conditions behave as described during estimation.
Named source materials, templates, brand assets, reference documents, photography, code, or other reusable resources can be used as agreed.
External vendors, data providers, platforms, printers, venues, specialists, subcontractors, or other third-party services remain available under expected conditions.
Exclusions
Exclusions identify work that the estimate does not cover. They are most useful when they address items a reasonable client might otherwise expect to be included.
The following items are examples of excluded work.
- additional deliverables, quantities, formats, languages, versions, or work beyond the agreed scope
- research, content creation, photography, data preparation, migration, asset creation, or other work not explicitly listed
- third-party fees, licensing, travel, printing, procurement, venue costs, platform subscriptions, or similar external expenses
- work caused by inaccurate client-provided information, unavailable inputs, or conditions different from those assumed during estimation
- ongoing maintenance, operational support, additional training, or work requested after formal acceptance unless specifically included
Dependencies
Dependencies affect both effort and sequence. Identify who or what must provide an input before work can begin or continue.
| Dependency type | Examples |
|---|---|
| Internal | Specialist availability, internal review, shared resources, or another team's deliverable. |
| Client | Content, access, feedback, decisions, approvals, legal review, or source files. |
| Third party | External vendors, data providers, platforms, printers, venues, specialists, or subcontractors. |
| Sequential | Work cannot begin until an earlier decision or deliverable is complete. |
| Parallel | Activities can proceed together only when resources and inputs are available. |
Once these elements have been defined, they should be documented clearly in the client proposal. The guide on writing a fixed-price proposal explains how to present scope, deliverables, assumptions, exclusions, responsibilities, pricing, and revision rules consistently.
11. Separate effort from duration and communicate confidence
Effort versus duration
Effort is the amount of work required. Duration is the calendar time needed to complete that work based on the hours you can actually work, the order of the tasks, waiting time, and client reviews
A 100-hour project does not automatically require two calendar weeks. At 20 available project hours per week, the estimated work alone requires approximately five weeks, before considering holidays, feedback cycles, waiting periods, or unavailable dependencies.
This guide establishes the work estimate. The guide on planning project capacity, timeline, and deadlines explains how estimated work translates into a realistic schedule based on available capacity, sequencing, dependencies, and calendar constraints.
Estimation confidence
Estimation confidence shows how reliable the estimate is based on the information currently available.
Communicate how much evidence supports the estimate. Confidence should reflect the completeness of the inputs, familiarity with the work, stability of assumptions and dependencies, and reliability of historical comparisons.
The work is familiar, required inputs are complete, dependencies are known, and reliable historical data is available.
The main deliverables and work are understood, but some details, reviews, assumptions, or dependencies remain variable.
Important requirements, inputs, constraints, approval conditions, methods, or dependencies are still unresolved.
Confidence describes the strength of the estimate, not the importance of the project. A high-priority project can still have low estimation confidence when essential information remains unresolved.
Use ranges and contingency honestly
Contingency is extra time or cost included to cover specific uncertainties within the agreed scope.
A realistic range communicates uncertainty more honestly than a narrow value unsupported by evidence. The range should reflect identifiable variation in the work, not an arbitrary percentage added without explanation.
Before committing to a fixed price, decide how the remaining uncertainty will be handled. You may clarify the scope further, include a documented extra time or cost for specific risks, separate optional work, divide the project into phases, or complete a discovery stage before pricing the uncertain work.
Contingency should protect against defined uncertainty within the agreed scope. It should not be used to absorb unlimited changes, undefined deliverables, or work outside the approved baseline.
The work estimate is only one part of deciding whether the project makes sense. The schedule also depends on your available time and anything the project must wait for. The final price should cover your minimum hourly rate, outside costs, and the uncertainty you agree to take on. Learn how to establish that economic threshold in the guide on choosing your minimum hourly rate.
12. Update the estimate without losing the baseline
Revise the estimate when important new information changes the work required. The update should not replace or erase the original baseline, because the difference helps explain what changed, why it changed, and how the revised estimate was produced.
Common update triggers
The following situations are examples of changes or discoveries that may require reviewing the estimate.
- a deliverable, quantity, format, quality requirement, or acceptance condition changes
- discovery reveals new requirements, constraints, risks, or necessary work
- the client changes the approval process, responsibilities, or decision-makers
- source materials, data, access, available resources, or working conditions differ from the documented assumptions
- a dependency, supplier, process, tool, platform, data source, or external service changes
- the project enters a new phase with better information or reduced uncertainty
Preserve the agreed baseline
Preserve the original outcome, deliverables, quantities, meetings, revisions, assumptions, exclusions, responsibilities, dependencies, and estimated work. Record the date and basis of the approved estimate so later versions can be compared against the same reference point.
Review proposed additions or changes separately before adding them to a new agreed version. In Deemzo, the Current Project remains visible while a separate scenario calculates the impact of proposed changes.
Did the scope change, or was the estimate inaccurate?
Compare the current work required with the original agreed scope. If the client requests new or different work, the scope has changed. If the work is unchanged but takes more or less effort than expected, the original estimate was inaccurate. If the estimate was based on missing or incorrect information, document the cause separately.
When the client requests additional or changed work, the guide on managing scope creep and project changes explains how to evaluate the effect on effort, price, capacity, and deadlines before incorporating the change into the project.
13. Scope estimation checklist
Use this review before treating the estimate as the approved project baseline.
- The underlying problem, intended outcome, the people who will use, review, approve, or maintain the result, and success criteria are understood.
- Completion criteria distinguish the work you must deliver and verify from broader outcomes that may depend on factors outside your control.
- Deliverables have defined types, quantities, specifications, included variations, and acceptance evidence.
- It is clear what belongs in each deliverable, so the same work is not counted twice.
- The project has been divided into phases or work packages that expose supporting and otherwise hidden activities.
- Each work item has been broken down to a level that supports a reliable estimate without unnecessary detail.
- The selected estimation methods match the structure of the work, available evidence, and remaining uncertainty.
- Estimated work includes all effort required to plan, produce, review, verify, communicate, deliver, and complete the project.
- Meetings include preparation, attendance, notes, and follow-up where applicable.
- Revision rounds have a defined process, feedback condition, and limit on the work included.
- Custom works items use comparable units and credible Hours per Unit.
- Identified included work is a breakdown of Estimated work, not additional effort added to it.
- Remaining estimated work reasonably represents the remaining baseline effort.
- Shared preparation, revisions, verification, meetings, coordination, and other activities are not counted more than once.
- Assumptions are specific, clear, and connected to the conditions used to prepare the estimate.
- Exclusions address work, costs, or responsibilities the client might otherwise reasonably expect to be included.
- Client, internal, outside-provider, and timing dependencies are documented where relevant.
- Estimated effort has not been confused with calendar duration or available weekly capacity.
- The estimate has a stated confidence level and, where uncertainty is is significant.
- The date, information, assumptions, and conditions supporting the baseline are documented.
- There is a defined process for evaluating changes, updating the estimate, and preserving the original baseline.
To see how a complete scope estimate is converted into a finished project evaluation, review the fixed-price project examples.
14. Frequently asked questions
What should be included in Estimated work?
Estimated work should represent all effort expected to complete the approved project baseline, not only visible production. Include planning, research, communication, meetings, revisions, coordination, verification, documentation, delivery, handoff, administration, and other known project work.
Should meetings and revisions be added on top of Estimated work?
No. In Deemzo, meetings, revision rounds, and custom work items identify portions of Estimated work. They help explain the estimate but are not automatically additional hours above it. Adding the same effort again would create double counting.
What is Remaining estimated work in Deemzo?
Remaining estimated work is the portion of estimated work not represented by identified meetings, revision rounds, or custom work items. It may include discovery, planning, production, project management, verification, documentation, delivery, administration, and other necessary project work.
Which estimation method should I use?
Use the method that best matches the available information, structure of the work, and remaining uncertainty. Bottom-up estimation is useful for well-defined work, analogous estimation helps when records from similar completed projects exist, parametric estimation suits repeated units that take similar time, and three-point estimation helps when uncertainty is significant. Combining methods is often stronger than relying on only one.
How much contingency should I add to a project estimate?
There is no universal percentage. Add contingency only for specific uncertainties that may occur within the agreed scope. Consider how reliable the estimate is, what the project depends on, how unfamiliar the work is, and what happens if it takes longer than expected. Contingency should not replace clearer scope or cover unlimited changes and undefined work.
How do I estimate a revision round?
Define one complete review cycle, combined client feedback, included changes and final check. Estimate the likely amount of change and consider the number of reviewers involved. A revision round should not silently include feedback from separate reviewers, new requirements, additional deliverables, or work beyond the agreed revision conditions.
What should I do when the scope is too uncertain to estimate confidently?
Clarify the scope further, separate uncertain work, conduct paid discovery, estimate the project in phases, use a realistic range, or choose a pricing model that does not require you to absorb unknown effort under one fixed fee. A precise number is not reliable when the underlying work remains undefined.
When should a project estimate be updated?
Update the estimate when deliverables, quantities, specifications, assumptions, dependencies, approval conditions, responsibilities, available inputs, working conditions, or required work change, and when discovery reveals material new information. Preserve the original baseline so the cause and effect of each revision can be identified clearly.
Ready to define your project scope?
Enter Estimated work, Meetings included, Revision rounds, and Custom work items in Project Decision. Use the breakdown to review whether the estimate is complete and internally consistent.
Open Project Decision