Some projects run smoothly. They get planned, built and delivered more or less when we said they would, no drama. It happens, and more often than the industry's reputation would have you believe.
But the other thing happens too. Projects that start with a clear date and, along the way, keep stretching. Not because of any disaster, but because of a pile of small things that, one after another, push the finish line a little further out. After quite a few years doing this, we've seen the same reasons come up again and again. And almost none of them have to do with anyone doing a bad job.
The scope changes along the way
This is the most common one. You start a project with an idea of what it needs to do and, as you watch it take shape, new ideas appear. “While we're at it, could we add…?” “Now that I see it, this would make more sense the other way.”
There's nothing wrong with wanting to improve the product as you go; often those changes are spot on. But each one has a cost in time, and a handful of “small additions” can move the delivery by weeks without anyone consciously deciding to. The problem isn't changing your mind, it's not spelling out what that change costs.
Decisions get put off
Sometimes development is left waiting. A piece of copy still needs confirming, a design needs approving, there's a choice to make between two options, an access to be granted. Things that look minor and that, until they're resolved, leave part of the work on pause.
One decision delayed by three days is nothing. Ten decisions delayed by three days each, across a project, are weeks. And usually they're invisible, because they don't show up anywhere: the project just moves slower than it could.
There isn't always a clear point of contact
The projects that work best tend to share one thing: someone on the other side who decides. A person who knows the business, can answer quickly and has the final say when there's a choice to make.
When that role isn't clear, because decisions go through a lot of people, or because nobody quite feels like the owner of the project, every question takes longer to resolve. It's nobody's fault in particular; it's a lack of structure that shows up directly in the schedule.
Estimating well is hard (and anyone who says otherwise is bending the truth)
The start of a project is when you know the least about it. And, paradoxically, it's when you're asked for an estimate. You make it with the information available, with experience and common sense, but it's still a forecast about something that doesn't exist yet.
There are complexities that only surface once you're inside: an integration that looked simple on paper and turns out not to be, an edge case nobody had pictured, an old system that behaves strangely. It's not that the estimate was done badly; it's that estimating is, by its nature, approximating.
So, can this be avoided?
Partly, yes, and that's why we're telling you. Many of these factors can be kept in check: pinning down the scope properly at the start, making it clear who decides, marking which changes go in now and which go to a second phase, and being honest with estimates instead of promising impossible dates.
It can't always be removed entirely, because a project is a living thing and sometimes you have to adapt. But if we had to boil it down to one idea: projects don't run long for lack of effort or skill, but for lack of conversations at the right time. The ones you have at the start, when you can still decide calmly, and the ones you have during, when something changes and it's worth putting it on the table straight away.
We learned this by doing projects, not by reading it in a manual. And it's probably the most useful thing we can offer: not the promise that nothing will ever go sideways, but the habit of seeing it coming and saying so in time.
