Software project estimating: effort, dependencies and risk

Start with testable deliverables

Define the behavior to ship, supported systems, migration responsibility, test environments and acceptance evidence. “Integrate the API” hides authentication, mapping, failure handling, data quality, deployment and support. Start with the software integration template, then replace its tasks and assumptions with the actual system boundaries.

Give tasks ranges for the same scope

For each task, estimate an optimistic, most likely and pessimistic duration in consistent units. These describe ordinary variation in delivering the defined work, not three different feature sets. Use the PERT calculator to inspect a single range, and read the PERT and Monte Carlo comparison before combining ranges into a project estimate.

Draw the dependency path before summing effort

Imagine five working days of interface design followed by two parallel implementation tasks lasting six and nine days. A three-day integration test must wait for both. The deterministic path is 5 + max(6, 9) + 3 = 17 working days with separate capacity for the parallel tasks. Total task effort is 5 + 6 + 9 + 3 = 23 person-days. If one person performs everything, the parallel assumption no longer holds.

Uncertain parallel branches introduce another issue: the branch that finishes last can change between outcomes. Read dependencies and deadline confidence. The full app models declared dependencies but does not automatically solve resource leveling; represent resource constraints in the plan rather than assuming unlimited staff.

Check capacity against the planned window

Three people over 20 working days at eight hours per day and 70% availability provide 336 project hours. A 400-hour plan does not fit even before dependency delays. Use the capacity calculator and repeat the check for the specialist role. Its calculated duration is a resource-only bound, not a promised completion date.

Model named risks without duplicating task ranges

A vendor schema change may be a separate event; ordinary debugging belongs in the task range. Record the event probability, conditional severity and owner. Include any cost caused by a delay explicitly. Compare a mitigation with the expected-value calculator, but use the simulated distribution to reason about a reserve. An expected risk cost does not provide P80 coverage.

Quote and promise from the same version of the plan

Choose a cost basis and target margin, then check deadline confidence for the corresponding scope and staffing assumptions. Do not add individual task P80s and label the sum a project P80. Read why task P80s do not add up, and use the app setup guide for a connected model.

Method references

The GAO Cost Estimating and Assessment Guide covers technical baselines, work breakdowns, assumptions and risk analysis. Its companion Schedule Assessment Guide explains why schedule and cost effects need to be considered together. The examples on this page are original illustrative calculations.

These guides were prepared with AI assistance. Examples are illustrative calculations checked against the calculator code, not client case studies or market benchmarks.