Your Developer Keeps Missing Deadlines: What to Do

• You’re eight weeks in, the launch date has moved twice, and every status update sounds like the last one. The slip itself tells you nothing about who’s at fault.

• Before you decide anything, ask for four things in one written message: the scope, the change log, a working build you can open, and a new date with its risks named.

• No scope document with explicit exclusions and no acceptance criteria means the delay is structural. Replacing the developer reproduces it, several months later.

• Some of the signals point at you. Late approvals, reopened decisions, and features added without moving the date are the most common, and the hardest to see from the inside.

• It’s the developer when you hear about slips after they’ve happened, when the same item has been almost done across three status updates, and when nobody can name the blocker.

• Then re-baseline, restructure, or replace. Replace is the one people reach for first and the one that needs the most evidence behind it.

People in this position search some version of “my developer keeps missing deadlines” and land on ten pages listing the warning signs of a bad agency. That’s the wrong question. The real one is whether the delay is coming from the people building it, from a scope nobody nailed down, or from decisions you haven’t made yet. Those three look identical from the outside, and they need completely different responses.

Start with the base rate, because it changes how you read your own situation. Bent Flyvbjerg and Alexander Budzier’s analysis of 1,471 IT projects, published in Harvard Business Review in 2011 and posted by the authors on arXiv, found an average cost overrun of 27 percent. Running over is ordinary. What isn’t ordinary is the tail: one project in six overran cost by 200 percent on average, and schedule by almost 70 percent.

So the slip isn’t the signal. What separates a project that lands three weeks over from one that never lands is whether anyone can tell you why, in specific terms. A team that can name the cause is managing a delay. A team that can’t is discovering one, a week at a time.

Stop asking whether you’re behind. You already know. Ask why, then judge the answer. Everything below is how to do that when you can’t read the code yourself.

Send one message, and ask for it in writing. Don’t book a call for this. A call gives everyone room to reassure you and produces nothing you can re-read on Thursday. Ask for four things:

• The current scope document, including what is explicitly excluded from it.

• Every change requested since work started, with what each one did to the date.

• A working demo of what’s finished, running in a browser or on a phone. Not screenshots, not a walkthrough, not a percentage.

• A new date, plus the two or three things most likely to move it again.

What comes back matters less than how fast it arrives and how specific it is. A team that has this material sends it inside a day, because it already exists and they use it. A team that doesn’t will send a summary instead, and the summary will describe effort rather than output. That gap takes no technical skill to read, and it is the most useful thing you can measure this week.

The problems practitioners actually report sit upstream of the build. In a survey of 228 companies across 10 countries, published in Empirical Software Engineering and posted by the authors on arXiv in 2016, nearly half of respondents, 48 percent, named incomplete or hidden requirements among the five most critical problems they face, more than any other item on the list. Communication breakdowns between the project team and the customer came next at 41 percent, then moving targets at 33 percent. That survey only asked about requirements problems, so it can’t tell you how often capability is the cause. What it does show is how much goes wrong before anyone writes a line of code.

From your side of the table it looks like three ordinary irritations. Ask what’s explicitly out of scope and you get a shrug, or a feature list that reads like a sales email. Handoffs bounce, because nobody wrote down what “done” means, and each round trip costs days. The date resets to two more weeks with nothing attached to explain what moved, which isn’t an estimate, it’s a guess being repeated.

If all three are true, replacing the developer changes nothing. The next team inherits the same undefined scope, produces the same drifting date, and does it months later with a restart cost attached. Write the boundary down now, for the work that’s left, and put two or three sentences of acceptance criteria against every remaining deliverable.

That’s also an argument about how the contract is shaped. When a vendor bills by the hour, an underestimate turns into your invoice. When a vendor owns the outcome for a fixed number, the same underestimate is theirs to absorb, which is why they write the scope down properly before quoting anything. That’s the side we’re on, and you can see the shape of it on our services page: scope gets defined before a number gets attached to it. The longer version is in the piece on contract structure and scope creep.

This is the section a vendor pitching you a rescue has no reason to write, so here it is. In PMI’s Pulse of the Profession 2018, practitioners naming the primary causes of failed projects put a change in the organization’s priorities first at 39 percent, a change in project objectives second at 37 percent, and inaccurate requirements gathering third at 35 percent. Inexperienced project manager came in at 22 percent, and team member procrastination at 13 percent. In that same 2018 survey, 52 percent of projects completed in the prior twelve months had experienced scope creep, up from 43 percent five years before that.

Those are project professionals reporting on projects in general rather than clients reporting on software vendors, and they picked up to three causes each, so none of it converts into a clean split of blame. It still points one way. The causes that get named most often sit on the client’s side of the table, in decisions and priorities, not in the build.

So run the same check on yourself. Over the last two months:

• How long did your approvals actually take? A two-day review that took nine days, four separate times, is a month of the delay you’re angry about.

• Did you reopen a decision that had already been made and built against?

• Did you add anything? Not a whole feature necessarily. A field, a report, a second user type, a “while you’re in there.”

• When you added it, did the date move? If it didn’t, somebody quietly agreed to absorb it, and that absorption is where the schedule went.

• Is there content, an access credential, or a third-party account they’ve been waiting on since June?

None of that makes the delay acceptable. A vendor who lets scope grow without renegotiating the date is failing at their job, and “you kept changing things” is only an answer if they said so at the time. But if three of those five land, this isn’t a competence problem. It’s a project nobody is managing, which has a different fix.

These genuinely point at the team building it, and every one is observable without technical judgment.

• You find out a date slipped after it slipped. A team in control tells you the week before. A team that isn’t tells you on the day, or waits for you to ask.

• The same item has been almost done across three status updates. Almost done is a status that should last days.

• You’ve never seen it run. Weeks of screenshots and descriptions with no build you can open yourself is the most reliable warning sign here.

• Questions come back as reassurance. You ask what’s blocking the payments work and you’re told they’re on it and it’s a priority. A team that knows what’s wrong can name it in one sentence.

• It moved fast, then stopped. A build that produced visible progress for six weeks and almost nothing since has usually reached the part that needed real design decisions. Ask what changed. A vague answer there deserves more of your attention than the missed date does.

One combination outranks the rest: the scope is documented, nothing material changed, and the date still moved. No scope excuse, no change log to point at, just a wrong estimate. Once is estimating. Three times is a pattern, and it’s the only pattern on this page with no innocent explanation.

Every honest diagnosis lands on one of three moves. Pick the one that matches what you found, not the one that matches how angry you are.

• Re-baseline. The scope is written, changes are logged, you can open a working build, and the date moved because the work was harder than estimated. Agree one new date against the existing scope, with a written list of what would move it again. Nothing structural needs to change.

• Restructure. No scope document, no acceptance criteria, or a change log that reads like a second project. Stop feature work. Spend two weeks defining what’s left in writing, with exclusions and acceptance criteria per deliverable, and treat that as its own piece of work with its own deliverables. It’s the option nobody leads with, because a rewrite or a takeover is easier to sell than two weeks of writing down what’s left. It’s also what we do before quoting anything, which is why it’s the one we’d test first.

• Replace. The scope is documented, nothing material changed, you still can’t open a working build, and the answers you get are reassurance rather than specifics. That combination is the only one that justifies switching mid-build. It’s also the one people reach for first, on the strength of the missed date alone.

Switching costs more than the invoice suggests. A new team inherits code they didn’t write and decisions nobody recorded, and their first weeks go into re-deriving what the last team already knew. Credentials, environments and half-finished integrations all get handed over by people with no reason to be generous about it. Do it when the evidence supports it, not because you’re three weeks into being angry.

If the evidence is still contradictory, an independent software build second opinion should give you three things before anyone proposes a takeover: what works now, what is blocking the next useful release, and whether the safer move is to keep the current team, change the plan or replace them. A review that assumes it will win the rebuild is another sales call, not an independent diagnosis.

If you do replace, the vetting matters more the second time, because you now know exactly which questions you failed to ask. Those are in how to identify the right development partner, and the scope section is the one to read before you sign anything else.

Send the four asks today, before you talk to anyone about replacing anyone. Forty-eight hours of that will tell you more than another month of status calls.