How Long Will My Software Project Take? Reading Estimates Honestly
Nobody can tell you accurately how long a software project will take at the idea stage, and anyone who gives you a single confident date in the first meeting is guessing. Software-estimation author Steve McConnell found that estimates made at the initial-concept stage can be off by a factor of four in either direction, and that is the best case, for skilled estimators. The honest answer is a range that narrows as discovery and requirements settle the scope.
So the useful question is not “how long?” but “what range, based on what assumptions, and when can we use the first part?”
The short answer
- Early estimates are ranges, not dates. At the idea stage the range can span sixteen-fold from low to high.
- The range narrows as decisions get made: a defined product, completed requirements, approved designs.
- Duration depends on the number of workflows, integrations, data migration, two-language content and how fast you decide.
- A good estimate lists its assumptions, its exclusions and the inputs it needs from you.
- To finish sooner, build less in the first version. Adding people late usually makes it later.
“A single date at the first meeting isn’t an estimate; it’s a sales technique. Ask for a range and the assumptions behind it, and expect the range to narrow as you make decisions.” — Abdulqader Wahiba, founder and CEO of ZAWAT
Why early estimates are so uncertain
At the start, almost everything that determines the size of the work is still unknown: which features, how each one behaves, what the exceptions are, what the data looks like, which systems it must connect to. The estimate cannot be more certain than the project it describes.
McConnell’s “Cone of Uncertainty”, set out in a 2010 Construx white paper, shows how the error narrows as a project moves through its milestones:
| Point in the project | Estimates can range from | To |
|---|---|---|
| Initial concept | 0.25× | 4× |
| Approved product definition | 0.5× | 2× |
| Requirements complete | 0.67× | 1.5× |
| User interface design complete | 0.8× | 1.25× |
Two lines from the paper are worth remembering. The cone “represents the best case accuracy it’s possible to have”, so careless estimating does worse. And “it isn’t possible to be more accurate; it’s only possible to be more lucky.” McConnell’s advice to organisations is to “avoid making commitments until the Cone has been reduced”.
The good news is that the cone narrows early. McConnell notes that “significant narrowing of the Cone occurs during the first 20-30% of the total calendar time for the project”. That is what a discovery phase and proper requirements buy you.
What actually drives the duration
- Number of workflows. Each distinct process the system supports, such as ordering, approvals or invoicing, adds design, building and testing.
- Integrations. Every connection to accounting, a payment gateway, WhatsApp or a government portal brings its own documentation, testing and surprises.
- Data migration. Cleaning and moving old records runs alongside the build and often finishes last. Moving your data into a new system explains why.
- Two languages. Arabic and English interfaces, content and reports need building and checking in both directions.
- Your decisions and inputs. Answers to questions, approvals of designs, content, test data and staff time for testing all sit on the project’s critical path. A week waiting for a decision is a week added to the end.
- Testing and launch. User acceptance testing, training and the switch from the old way of working take real time, and they are the first things squeezed when a schedule slips.
What a trustworthy estimate looks like
Abdulqader Wahiba recommends asking for three things with every estimate: the range, the assumptions behind it, and the first date you can use something. Beyond those, look for:
- Phases with milestones you can see working, not just a final delivery date.
- Listed exclusions, such as data migration, content or third-party fees, so you know what is not in the number.
- Your inputs, named and dated: what the supplier needs from you, and by when.
- A plan to re-estimate once discovery and requirements are complete.
- Contingency shown openly, rather than hidden in padded tasks.
Be wary of the opposite signs: one date and no range, no questions about your data or integrations, and no mention of what happens if your decisions arrive late.
Fixed date, fixed scope or fixed price: choose which one moves
Time, scope and cost are linked. You can fix one or two, but not all three without quality paying the difference. If the launch date is immovable, for example because of a regulatory deadline, fix the date and let scope flex: decide in advance which features can follow in a second release. If the scope is non-negotiable, accept that the date is a range. What custom software really costs covers the price side of the same trade-off.
How to finish sooner without cutting quality
- Build a smaller first version. The fastest way to an earlier launch is less to build. Scoping the first version shows how to choose.
- Decide quickly. Name one owner who can answer questions within a day or two.
- Start the data work in week one. It is almost always slower than expected.
- Defer non-essential integrations. A nightly export can stand in for a live connection in version one.
- Don’t add people late. Frederick Brooks observed in 1975 that “adding manpower to a late software project makes it later”, because newcomers take time from the people doing the work.
When a project is already running late
Ask for an updated range, the reasons for the slip and what is still unknown. Then choose consciously between moving the date, reducing the scope of the first release, or both. Lateness that nobody explains, demonstrations that stop and a supplier who goes quiet are warning signs; rescuing a stalled software project covers what to do if it gets that far.
Frequently asked questions
Why do software projects so often run late? Mostly because commitments are made while the scope is still uncertain, and the uncertainty is then discovered during the build. Late decisions, growing scope and slow data migration add to it.
Can I get a fixed price and a fixed date? For a well-defined scope, yes, and the supplier will price in the risk. At the idea stage, fixing both usually means either a padded price or a reduced scope later. Fix them after discovery, when the uncertainty is smaller.
How long does a typical business system take? It depends on the workflows, integrations and data involved. ZAWAT’s own guidance is that a focused website may take a few weeks and a full platform longer, with a realistic timeline and milestones agreed before work starts. Be sceptical of any precise figure given before the scope is defined.
Should the contract include penalties for late delivery? Penalties can focus attention, but they also push suppliers to pad estimates or cut testing. Milestones tied to working software, with payment against each, usually protect you better.
Does an agile approach make projects slower? No. Agile working delivers usable software in short cycles and lets you change priorities as you learn. It does not remove the uncertainty; it exposes it earlier, which is when it is cheapest to deal with.
Sources: Steve McConnell — Software Development’s Cone of Uncertainty (Construx white paper, 2010) · Frederick P. Brooks Jr., The Mythical Man-Month (Addison-Wesley, 1975)
Want an estimate you can actually plan around? ZAWAT’s approach to custom software begins with discovery, so the range you plan on is based on your real scope. Book a call.