How to manage deadlines in software development

Software deadlines rarely slip for mysterious reasons. They slip because a date was promised before anyone knew enough to promise it, because the scope grew while the date stayed put, or because a problem was found in the last week that could have been found in the first.

So the short answer is this: estimate in ranges and commit only once the requirements are clear, break the work into small pieces that include the invisible work, decide up front whether the date or the scope gives way, show working software regularly, and write down every change with its effect on the date. This guide covers each of those, for clients and project managers who want a delivery date they can rely on.

Why software deadlines slip

Most late projects share a handful of causes:

• The date came before the detail. A launch date was agreed at the idea stage, when nobody could know how big the work really was.
• The scope grew and the date did not move. Each extra feature looked small on its own, but nobody added them up.
• The invisible work was left out. Testing, data migration, deployment, app store review and handover take real time and rarely appear in the first estimate.
• Problems surfaced late. When the client first sees the software a week before launch, every misunderstanding lands at once.
• Waiting on others. Feedback, content, test accounts and access to third-party systems all arrive later than planned.

None of these is a developer working too slowly. They are planning problems, which is good news: planning can fix them.

Estimate in ranges, then commit

An early estimate is a range, not a number, and the range is wider than most people expect. In his Cone of Uncertainty, Steve McConnell shows that an estimate made at the initial-concept stage can turn out anywhere from a quarter of the real effort to four times it. Once the product is defined, the range narrows to between half and double; once the requirements are complete, to between two-thirds and one and a half times.

The practical lesson is to match the commitment to the stage. Give a range at the idea stage, and a firm date only after the requirements and the main screens are agreed. McConnell also notes that most of the narrowing happens in the first 20 to 30 per cent of a project's calendar time, so a short, paid discovery or feasibility study before committing is time well spent.

Break the work down, including the invisible work

Large tasks hide their size. Break the work into pieces of no more than a few days each, and have the people who will do the work estimate them. Then add the items that are easy to forget:

• testing, and fixing what testing finds;
• data migration from the old system;
• integrations with payment gateways, ERPs and other third parties, including waiting for their test access;
• deployment, monitoring and backups;
• app store review, for mobile apps;
• documentation, training and handover.

A list like this often adds weeks to a first estimate. Better to find them on paper than in the final fortnight.

Decide what moves: the date, the scope or the team

When work takes longer than planned, something has to give. Agree in advance which one it will be.

• Fixed date, flexible scope. Rank every feature as must, should or could. The must-haves ship on the date; the rest follow in the next release. This suits launches tied to an event, a season or a regulation.
• Fixed scope, flexible date. Everything must be there, so the date moves when the work takes longer. This suits systems that are useless until complete, such as a replacement for an old ERP.
• Adding people. Usually the weakest option late in a project. Fred Brooks put it bluntly in The Mythical Man-Month: "adding manpower to a late software project makes it later", because new people need time and attention from the ones already working.

Make progress visible every week or two

The surest way to protect a deadline is to show working software often. Short sprints of one or two weeks, each ending with a demo, turn a vague "it's going well" into something the client can click through. Misunderstandings then surface in week two rather than week twelve, while they are still cheap to fix.

Keep every task in one shared tracker, such as Jira, so anyone can see what is done, what is in progress and what is blocked. A simple chart of work completed against work remaining shows within a few sprints whether the date is realistic.

Write down every change

Changes are normal; unrecorded changes are what sink deadlines. When a new request arrives, write it down with its effect on the date and the cost, and agree it before work starts. The same applies to delays on the client side: late feedback, content or access move the date just as surely as extra features do, and recording them keeps the conversation factual rather than personal.

Keep a buffer, and use it honestly

Padding every task quietly makes estimates meaningless. Instead, estimate each task honestly and hold one shared buffer at the end of the project. Report how much of it has been used at every review. A buffer that is half gone halfway through is fine; one that is gone a third of the way in is an early warning.

Warning signs that a deadline is at risk

• Tasks stay "almost done" for several days.
• Demos are postponed, or show slides instead of software.
• The number of open bugs keeps rising late in the project.
• Decisions wait days for answers.
• Requirements are still being discussed after development has started.

Any one of these is worth raising the same week. A date moved early, with a reason, is a planning decision; a date missed on the day is a broken promise.

How we handle deadlines at CodeLabs

Every project starts with a free scoping call, followed by a written proposal with the scope, timeline and a fixed quote. Payments are tied to milestones such as kickoff, design approval and delivery, so progress and payment move together. We build in iterative sprints with regular demos, so clients see working software throughout and can change direction early rather than at the end.

Our pages on custom software development and the SDLC methodologies we use explain more about how we plan and deliver.

Questions people ask

How do you estimate a software project?

Break the work into tasks of a few days each, have the people doing the work estimate them, add testing, deployment and other invisible work, and express the result as a range. Narrow the range into a firm date once the requirements and main screens are agreed.

Should we fix the date or the scope?

Fix the one that matters more to your business, and say so at the start. Event and regulatory launches usually fix the date and rank features by priority; replacements for core systems usually fix the scope and let the date move.

What should we do when a deadline is going to slip?

Say so as soon as you know, with the reason and the options: drop or defer lower-priority features, move the date, or accept a smaller first release. Early, specific news gives everyone choices; late news leaves none.