What a Real Software Project Scope Looks Like (And Why Estimates Change)

A Nigerian company publishes a Request for Proposal for an ERP system. Shortlisted vendors are asked to submit a fixed-price bid. The client selects the lowest bid. Nine months into a twelve-month project, the bid price has been exceeded by 60%. The client believes the vendor misled them; the vendor believes the client's requirements changed beyond what was agreed.

Both are partially right. The fixed-price bid was always fiction — because the requirements were not sufficiently specified to produce a reliable estimate at bid stage. The fiction served the procurement process. It did not serve the project.

This scenario is common in Nigerian enterprise software procurement and is almost always more painful than it needs to be. Understanding what happens to estimates and why provides a framework for managing projects in a way that produces better outcomes for both clients and development partners.

The Uncertainty Curve in Software Projects

At the beginning of a software project, requirements are defined at a high level. "We need an inventory system that integrates with our accounting system, manages multiple warehouse locations, and provides real-time stock visibility." This description sounds clear enough to build.

What is not yet known: the exact number of warehouse locations and how their processes differ; the specific accounting system and the constraints of its integration API; the number of stock movements per day and the performance requirements; the user roles and what each role needs to do; the reporting requirements and in what format; the exception-handling workflows when stock discrepancies occur; the mobile device requirements for warehouse staff.

Each unknown is a scope item that, when discovered during development, either fits within the original estimate (if the developer made assumptions that turned out to be correct) or does not (if the assumption was wrong or the requirement is more complex than assumed).

The software industry's Cone of Uncertainty (originated by Barry Boehm and later popularised by Steve McConnell) describes this empirically: at the initial concept stage, estimates have a range of 0.25× to 4× the actual effort — meaning a project estimated at 100 person-days could actually require anywhere from 25 to 400. The range narrows as requirements are understood, design decisions are made, and the project is specified in detail.

A fixed-price bid prepared before detailed specification is a number picked from within a wide cone. It is not wrong because the estimator was incompetent; it is imprecise because the information required for precision does not yet exist.

The Discovery Phase

The correct structural response to estimation uncertainty is a discovery phase: a defined, time-boxed, paid engagement prior to full project commitment, during which the scope is specified to sufficient detail that a reliable estimate is achievable.

A discovery phase for a mid-size Nigerian business software project (6–12 months estimated development) typically:

Duration: 3–6 weeks Output: A detailed specification document including:

User stories for all major workflows (As a warehouse manager, I need to record a goods received note against a purchase order, matching received items to PO line items and flagging discrepancies)
Data model (what entities exist, their attributes, their relationships)
Integration requirements (which external systems, what data flows, what API access each provides)
Non-functional requirements (performance targets, user volume, availability requirements)
Wireframes or UI mockups for complex screens
An initial estimate based on the specified scope, with identified risk areas
A phased delivery plan

The business value of discovery: The discovery output, properly done, allows the client to:

Confirm that the specified system is what they actually want (it frequently reveals unstated assumptions on both sides)
Identify which requirements are essential (phase 1) versus valuable (phase 2) versus nice-to-have (phase 3)
Receive a reliable estimate that reflects actual scope
Go to market with a specification that competing vendors can bid against accurately

The discovery phase costs 5–15% of the expected total project cost. The cost is justified because it reduces the probability of the 60% overrun scenario from common to unusual.

Why Requirements Change After Discovery

Even a thorough discovery phase does not eliminate scope change, because requirements genuinely evolve:

Business changes during development: A 9-month project overlaps with nine months of business operation. The business's context changes — a new product line requires features not anticipated, a new strategic partner requires a new integration, a regulatory change requires compliance features that did not exist at discovery.

User feedback changes requirements: Once users interact with a working prototype or an early release, they identify needs they could not articulate from a description. "I didn't realise I would need to do X until I saw the screen — it's actually critical to my workflow." This is not a failure of the discovery phase; it is the fundamental challenge of specifying software for users who have not used it yet.

Technical discoveries: Development sometimes uncovers constraints that were not apparent from specification. An integration API that was documented to support a feature turns out not to work that way in practice. A performance requirement is only achievable with a different architecture than was planned. These are risk items that domain expertise can identify during discovery but cannot always fully eliminate.

Good scope change vs. scope creep: Not all scope change is equivalent. Changes driven by genuine business need or by user feedback that reveals a legitimate gap are good scope change — the system is being improved. "Scope creep" in the pejorative sense is the gradual accumulation of small additions that were never core requirements, each individually small, collectively significant. Managing the distinction requires a change request process that categorises and prices each change explicitly.

The Change Request Process

A change request process prevents the ambiguity that creates disputes:

Any requirement not in the agreed specification is raised as a change request
The development team estimates the additional effort
The client approves or declines the change, with explicit cost and timeline approval
Approved changes are added to the agreed scope and reflected in the project timeline

The change request record — a log of every addition, with approval evidence — creates mutual clarity. At the end of a project, both parties can trace every line of cost to either the original specification or an approved change.

This process feels bureaucratic during a collaborative project. It is invaluable when an overrun dispute arises, because the record shows whether the cost increase was the developer adding unrequested complexity or the client adding requirements beyond the original agreement.

Honest Framing for Fixed-Price vs. Time-and-Materials

Fixed-price contracts transfer scope risk to the developer. If the developer under-estimated, they absorb the cost overrun. This incentivises either over-pricing (to build in contingency) or under-delivering (cutting features to meet the budget). Neither serves the client.

Fixed-price works well when the scope is genuinely fixed and well-specified. For most software projects before discovery, it does not.

Time-and-materials contracts transfer scope risk to the client. The developer charges for actual hours worked, plus materials. Overruns are the client's responsibility. This creates cost uncertainty for the client and requires trust that the developer works efficiently.

T&M works well when the relationship is trusted and the client has strong project oversight. It is risky for clients with limited technical oversight capability.

Capped T&M: A hybrid — time and materials billing within a defined budget cap, with change request approval for budget overruns. Gives the developer flexibility to execute efficiently and gives the client cost certainty, with an agreed process for budget adjustments when scope changes.

For most Nigerian business software projects, the recommended structure: discovery phase at fixed price, followed by phased development at capped T&M with defined phase deliverables and phase-exit approval before the next phase begins. This gives both parties maximum information at each decision point and minimises the risk of large disagreements at project end.

How to Write a Software RFP That Gets Useful Responses — Getting better proposals from software vendors
Staff Augmentation vs Full Project Outsourcing — Choosing the right engagement model
Technical Debt: Measuring, Managing, and Selling It to the CFO — Managing scope and quality trade-offs