Nobody sets out to be three months late. It happens one revised estimate at a time, and each individual revision sounds entirely reasonable when you hear it.
The problem is that by the fourth "two more weeks", you no longer have a way to tell whether the project is behind but healthy or behind and stuck. Those two situations look identical from the outside and require completely different responses. This article is about telling them apart, quickly, without needing to be technical.
Why the same estimate keeps arriving
Start with the mechanism, because it explains repeated slippage without anyone having to be lying to you.
The revised estimate is produced by the same team whose last estimate already turned out to be wrong. They are not a neutral party checking the work. They are inside it, and their view of what is left is filtered through what they currently understand about the system, which is exactly the thing that was incomplete last time as well.
Unfinished software also conceals its own state. A feature that is ninety per cent done by any internal measure, lines of code, screens built, hours logged, can still have its hardest and least visible part unstarted. The remaining ten per cent is disproportionately the integration, the edge case, the part that only reveals itself once two half-built pieces are connected. That is why the last ten per cent so often takes as long as the first ninety.
And each new estimate anchors on the last one. A team under pressure to explain a miss revises downward from where they previously said they would be, rather than re-deriving the number from nothing.
This is not a UAE problem or a small-supplier problem. The US Government Accountability Office, writing about federal programme estimating, describes the same dynamic and is careful to name it as overoptimism rather than misrepresentation: managers believe their own original estimates and do not allow enough for scope change, delay and risk [1]. The same guidance notes that risk analysis conducted by a group independent of the project manager has a better chance of being unbiased [1]. That is a government body, writing about government programmes, describing precisely the pattern you are experiencing.
The four questions
These separate a supplier who has a project from one who has a problem they have not yet mapped.
What is demonstrably working right now, in an environment I can see? Not described. Shown, on a device or a URL you control, not a screen share of a developer's own machine.
What is the full list of remaining items, individually named? Not "a few more features". A list specific enough that both sides could tick items off it independently, without needing to agree what a phrase means.
Which of those items has never been started? This is the most diagnostic of the four, because "in progress" and "not started" get flattened into the same status line by teams under pressure. Almost all schedule surprise lives in that flattening.
What is blocked, and on whom? A blocked item with a named owner, a client decision pending, a third-party approval outstanding, a design not signed off, is a project. A blocked item with no named owner is usually not blocked at all. It is simply not started, described more comfortably.
A supplier who can answer all four with specifics has a troubled project, which is a recoverable situation. A supplier who answers in generalities has a problem they have not mapped, and the vagueness tells you more than anything reassuring they said alongside it.
Behind but healthy, or behind and stuck
Some variance is normal. Software work involves discovering things that could not have been known at quoting time, and a supplier who never slips is either padding heavily or building something trivial. So the question is not whether a project has slipped. It is whether each slip has bought you a clearer picture.
A healthy late project has a remaining-items list that gets shorter and more specific every time you ask. Month one it says "payments and reporting". Month two it says "refund handling, the failed-payment retry, and the monthly export". The scope of the unknown is shrinking even while the date moves. That is a team learning the system and telling you what they found.
A stuck project has a list that stays the same length and the same vagueness however often you ask. "Payments and reporting" in month one is still "payments and reporting" in month three, possibly with "just some polish" added. Nothing has been resolved. The date moves without any corresponding gain in knowledge, which means the same surprise that caused the first slip is still sitting there, undiscovered.
The other reliable tell is what happens between conversations. On a healthy project, things you saw last month still work this month and there is more alongside them. On a stuck project, the demonstration you were shown in month one has quietly stopped working, because the underlying pieces kept being rearranged and nobody was checking. If you are shown something and it breaks, that is not embarrassing, it is the most useful five minutes of the meeting.
Act on the second miss, not the fourth. The first is normal variance. The second tells you the estimating process itself is not producing better information, and that is precisely the point to ask the four questions rather than accept another date. Waiting until the fourth costs you two more months and gives you nothing you did not already know.
Ask to see it, not to hear about it
A status update is a description chosen by the person giving it, calibrated, consciously or not, to sound acceptable. A demonstration is a fact.
Ask how it is going and you get an account. Ask to watch the checkout flow complete a real payment against a test card, on a URL you control, and you get something that either happens or does not. The second is nearly impossible to fake convincingly for more than a few minutes. The first can be sustained for months.
This is why a percent-complete figure is weak evidence. It is self-reported by the party being measured, with no external check. It conflates effort spent with value delivered. And it resets silently, because a supplier can honestly report ninety per cent two months running if the definition of the remaining ten per cent keeps quietly moving. GAO's guidance says as much directly: percent complete should rest on quantifiable underlying measures, and where it cannot, it is too subjective and something more objective should be used [1].
NASA's readiness scale makes the same distinction for hardware and makes it unusually cleanly. Its lower levels describe principles observed, reported and studied on paper. Its trusted levels require the thing to be demonstrated actually working in conditions that matter, with the top level reached only once a technology has been proven on a real mission [2]. That framework was built for space technology rather than software procurement, but the underlying line is identical: reported and demonstrated are different states of knowledge, and only one of them is evidence.
US federal digital-service guidance applies the same principle directly to software, instructing that contracts and reviews be structured around frequent working deliverables rather than multi-month milestones, and that suppliers be held to delivered software rather than narrative reports [3][4]. Those are US public-sector sources rather than UAE rules, and we cite them for the principle rather than any obligation.
So replace the status call with a demonstration date. Ask for the most important unfinished piece, shown running, within five working days.
Be specific about what you want to see, because a vague request gets a vague demo. Name the thing that matters commercially: a customer completing a booking, an order reaching the warehouse system, an invoice generating with the right tax treatment. Then ask to see it done once with data you supply on the day, rather than a rehearsed run with prepared inputs. That single condition, your data, on the day, is what separates a demonstration from a presentation.
If the answer is that the environment is mid-migration, or an API key expired, or the test data was reset, that is fine, and it should come with a date for when the demonstration will happen instead. A reason with a date is a project. A reason that keeps moving is an answer.
It might be your fault, and nobody will tell you
This section deserves genuine weight, because these causes are common and the person best placed to name them has the weakest incentive to.
Decisions that take weeks. A design choice or a business-rule clarification goes out and sits unanswered while the team either blocks on it or guesses and has to redo the work when the answer arrives.
No single approver. Three stakeholders with three opinions and nobody empowered to break the tie produces the same delay as silence, then adds rework when the informal compromise is overruled by whoever was not in the room.
Scope added without the date moving. A small addition agreed verbally in a meeting, with nobody updating the plan, is scope creep no matter how reasonable it was in isolation.
Content and access not supplied. Copy, images, brand assets, API keys, sandbox credentials, a working test account with the third-party system. These are frequently yours to provide, frequently the actual blocker, and almost never visible to you as development work.
Feedback in fragments. One review returned as three messages over five days, each revising the last, costs considerably more than the same feedback delivered once and complete.
A supplier who needs the relationship to continue will rarely say "this is late because you have not approved the design in three weeks", even when that is exactly true, because it reads as blaming the client. So ask instead: what, from our side, is the biggest thing slowing you down right now? A supplier with nothing to hide can usually answer that specifically.
Ask it before you ask anything about their side. It changes the whole shape of the conversation, from an audit into a joint problem, and it costs you nothing if the answer turns out to be nothing. It also gives you the one thing you can fix immediately and unilaterally, which on a late project is worth more than anything you can ask somebody else to do faster.
What you can actually do
Five options. There is no sixth that returns you to the original plan.
Cut scope. You get something real, sooner. It usually means renegotiating price too, because the original figure assumed the original list. Cut whole features rather than trimming each one, since half-built features carry the cost without the benefit.
Move the date. Often the least damaging option, and useful only if the new date is credible. A new date from the same estimator, revised down from the last one, is the same guess wearing different clothes. Insist it arrives with the four answers attached.
Add money. Helps only when the constraint is genuinely capacity. It does nothing for a blocked decision, an undiscovered integration problem, or a team that does not yet understand what it is building.
Add people. The instinct most likely to backfire. New team members need the undocumented context the original team accumulated over months, and someone already making progress has to stop and supply it. GAO's guidance puts the caution plainly: when too many people work on the same thing communication tends to break down, and careful analysis should precede adding staff [1].
Change supplier, or stop. Both are legitimate. Understand that a new team inheriting a half-built system can take longer than building fresh, and that a takeover review is its own engagement. Our guide on changing development agency covers that process, including the order of operations around access and notice. Stopping is a commercial decision rather than a failure of nerve, and it is the right one when the four questions come back empty twice.
Put the reset in writing
Not contract wording, and not legal advice. A revised plan should contain named deliverables specific enough to demonstrate, a date against each one rather than a single end date, a plain statement of what has been cut, and what happens if the new date is missed.
That last item matters most and gets skipped most. Not a penalty, which is a contract question for a lawyer, but a stated next step: another demonstration checkpoint, a further scope cut, or a decision to stop. Agreeing that now, while both sides are calm, is far easier than inventing it under pressure a second time. For the underlying contract mechanics, acceptance criteria, payment structure and termination, see our guide on reading a software proposal.
If you cannot tell whether the answers are true
An independent technical review starts from around AED 4,000 with us. That is the same starting figure as our codebase takeover review, because the scope is comparable: getting the current build running, establishing what is genuinely demonstrable, and checking the remaining-items list against what has been paid for. Final pricing depends on scope, and that is our own commercial figure rather than a market rate, since no official body publishes rates for this work.
It does not mean you are leaving your supplier, and it is worth telling them that rather than commissioning it quietly. A review that confirms the project is behind but fundamentally sound is a good outcome for everybody, including them.
Before you spend anything, though, send the email. Ask for a demonstration of the most important unfinished piece within five working days, and ask which remaining items have never been started. Those two questions cost nothing and will tell you more than the last three months of status calls.
References
- US Government Accountability Office, GAO Cost Estimating and Assessment Guide (GAO-09-3SP)
- NASA, Technology Readiness Levels
- US Digital Services Playbook
- TechFAR Hub, planning for agile
- SKIMBOX, changing your development agency in the UAE
- SKIMBOX, how to read a software proposal
The GAO, NASA and USDS sources above are US federal government publications concerning large public programmes. They are cited for the underlying principles, which apply broadly, rather than as rules governing private software contracts in the UAE.
