Constructive cost model

Key Points

• Model-based technique that converts software size and rated cost drivers into effort, duration, and staffing needs.
• Useful early in planning when detailed task breakdowns are incomplete, and as a cross-check for bottom-up estimates.
• Works best when calibrated with organizational historical data and consistent sizing methods.
• Often implemented via spreadsheets or estimation tools to speed scenario analysis and documentation.

Purpose of Analysis

Provide a defensible forecast of people resources and timing for software projects based on objective drivers. Support staffing, budgeting, and schedule commitments, and enable trade-off discussions.

• Quantify effort to guide staffing levels and skill mix.
• Estimate schedule to sequence hiring and onboarding.
• Run what-if scenarios to evaluate scope, quality, or team capability changes.
• Document the basis of estimate to align stakeholders and manage expectations.

Method Steps

• Select the model variant appropriate for your context (e.g., Basic, Intermediate, or COCOMO II post-architecture).
• Choose a consistent size measure such as KLOC or function points and convert to the input required by the model.
• Rate scale factors and cost drivers (e.g., complexity, reliability, team capability, tools) with the help of SMEs.
• Compute effort using the model or tool and derive duration and staffing profile from the calculated effort.
• Calibrate coefficients with organizational historicals when available, or use published defaults with caution.
• Adjust for non-development work (QA, DevOps, PM, rework) and apply contingency based on risk.
• Review results with the team, compare to bottom-up estimates, and iterate as scope and assumptions firm up.
• Record assumptions, driver ratings, and calibration values in the basis-of-estimate document.

Inputs Needed

• Preliminary scope, architecture, and major components or epics.
• Software size estimate in KLOC or function points, ideally by component.
• Rated cost drivers and scale factors such as product complexity, required reliability, platform constraints, team capability, experience, tools, and process maturity.
• Historical productivity, calibration constants, and comparator projects.
• Resource constraints, hiring limits, calendar assumptions, and key milestones.
• Risk assessment and quality targets that influence driver ratings.

Outputs Produced

• Total effort in person-months, optionally broken down by component or phase.
• Estimated duration and major milestone timing.
• Average and peak staffing levels, with a ramp-up and ramp-down profile.
• Role and skill mix to inform hiring or vendor sourcing.
• Sensitivity analysis showing impact of key drivers and size uncertainty.
• Basis-of-estimate package capturing assumptions, ratings, and calibration.

Interpretation Tips

• Treat results as a range, not a single point; present optimistic, most likely, and conservative scenarios.
• Average staffing is not the plan; convert to a realistic staffing curve aligned to phases and calendars.
• Validate the estimate against similar past projects and a quick bottom-up or three-point check.
• Revisit driver ratings when scope, quality targets, or team composition change.
• Explain which drivers have the highest leverage to support informed trade-off decisions.

Example

Assume a new internal system estimated at 50 KLOC with nominal drivers, using a basic COCOMO approach for early planning.

• Effort: ≈ 2.4 × (50)^1.05 ≈ 146 person-months.
• Schedule: ≈ 2.5 × (146)^0.38 ≈ 16.6 months.
• Average staffing: 146 ÷ 16.6 ≈ 9 FTE, planned as a curve (e.g., ramp 3 → 8 → 12 → 5 across phases).
• If reliability is rated higher than nominal, effort may rise ~15%, to ≈ 168 person-months, increasing peak staffing or extending schedule.
• Translate FTEs into roles (e.g., 1 architect, 6 developers, 2 testers, 1 DevOps, 1 BA/PM spread) and align with hiring lead times.

Pitfalls

• Using imprecise size inputs or mixing sizing methods without reconciliation.
• Misrating cost drivers due to optimism or lack of SME involvement.
• Ignoring non-development effort such as testing, automation, DevOps, documentation, and rework.
• Assuming constant staffing rather than a phased ramp, leading to unrealistic plans.
• Relying on uncalibrated coefficients or outdated benchmarks when better local data exists.
• Applying the model to non-software work without adaptation or complementary methods.

PMP Example Question

While estimating resources for a new software product, the project manager wants a technique that converts size and cost-driver ratings into effort, schedule, and staffing to support early hiring decisions. What should the manager use?

1. Analogous estimation.
2. Constructive cost model.
3. Resource smoothing.
4. RACI analysis.

Correct Answer: B — Constructive cost model.

Explanation: COCOMO is a parametric model that turns software size and driver ratings into effort, duration, and staffing. It supports early resource planning and scenario analysis. The other options do not provide model-based staffing forecasts.