Almost no IT project finishes when it was planned to. It's not bad luck or a lack of talent: it's the way we underestimate time and, above all, how we manage it. After more than two decades running IT in Argentina, at Novatium we see the same causes repeat, the same warning signs ignored, and a concrete difference when time is managed as part of the service.
Ask any company when the last time an IT project finished exactly on the promised date was. The answer is usually an uncomfortable silence, followed by a smile.
It's not a problem of one particular industry. It's structural. And after more than twenty years watching projects start, slip, and —sometimes— reach a good outcome, at Novatium we learned that the delay almost never shows up where you look for it.
Time isn't underestimated out of optimism. It's underestimated by design.
The easy explanation is that we're too optimistic when we plan. That's true, but it's only the surface. The deeper problem is that we estimate the time for visible work and ignore the time for invisible work: the validations that depend on third parties, the integrations that “should just work,” the accesses that take weeks, the decisions left waiting on someone who was on vacation.
That invisible work is almost never measured, and yet it's what weighs the most. A good estimate isn't the one that assumes everything will go well: it's the one that reserves an explicit margin for dependencies and the unexpected. As a rule of thumb, a project that doesn't set aside at least 15% or 20% of its time for what doesn't depend on the technical team isn't estimated: it's gambled.
That's why a project doesn't fall behind the day a server goes down. It falls behind much earlier, in all those hours no one counted because they weren't in the plan.
The four causes we see repeat
- Scope that grows in silence. Every “while we're at it, let's add this” seems minor. Added up, they redefine the project without anyone having moved the delivery date.
- Dependencies that aren't managed. The technical team can be excellent, but if it depends on a third party that responds whenever it can, the schedule is set by the slowest link, not the fastest.
- Estimates with no margin for the unexpected. You plan for the scenario where everything goes well. And in real operations, something always turns out different from what was expected.
- No clear owner of time. When everyone owns the project, no one owns the deadline. And what has no owner stretches.
Five signs your project is already behind, even if it shows “on schedule”
Delay rarely announces itself. It builds up quietly and only becomes visible when there's no margin left. These are the early signs worth watching before the schedule confirms it:
- There are tasks blocked waiting on third parties —and that block is taken as “normal” instead of being treated as an active risk.
- The team starts working on assumptions because definitions are still missing. It moves forward, yes, but on a base that may have to be redone.
- Small tasks get added that don't formally change the scope. No one signs a change, but the project being executed is no longer the one that was planned.
- Progress is measured by finished tasks, not by milestones met. You can be “80% done” on tasks and 40% on the milestones that really matter.
- The final date stays intact even though the buffers are already used up. If the contingency margin was spent in the first half and the date didn't move, the delay already exists: it just hasn't been declared yet.
None of these signs is technical. They're all about management. And that's the most important distinction: a one-off delay is solved with effort; a structural problem repeats project after project, always for the same reasons. If the delay keeps showing up with different teams and different technologies, the problem isn't estimation. It's the model used to manage it.
How time is managed when it's part of the service
The difference between a project that stretches out of control and one that slips little and warns in time isn't in the technology. It's in the management model. And that model rests on concrete decisions:
- A single owner of the deadline, distinct from the technical lead. Someone whose job is to protect the date, not execute the tasks.
- Dependencies managed formally: identified at the start, with an owner and a committed date from each third party, and follow-up before they block, not after.
- Scope controlled with judgment: every new request is accepted, but its impact on time is made visible. It's not about slowing the business down, but about making the decision to add something a conscious one.
- Weekly indicators that look at milestones and buffers, not just closed tasks: how much margin is left, which dependencies are at risk, what deviations appeared. Deviations are caught while they can still be corrected.
When time is treated as a variable that is measured and governed —and not as a promise made at the start and forgotten— the project stops surprising you. Not because there are no surprises, but because there's a model that anticipates, contains, and communicates them.
The question worth asking your IT provider
Here's the point that matters most. A good IT provider doesn't just execute tasks and report progress. It manages dependencies, risks, timing, and communication so the client gets something worth more than speed: predictability.
That's why, rather than asking “will you finish on time?” —a promise that's easy to make and hard to keep— it's better to ask how the project is managed: Is there an owner of the deadline, in addition to the technical lead? How are dependencies with third parties identified and tracked? What happens, specifically, when the delay depends on someone who is neither you nor the provider? What indicators will you see each week, and do they show milestones and margins or only closed tasks?
The answers to those questions separate the provider that “does the task” from the partner that takes ownership of the outcome. The next time an IT project runs late, before asking what failed technically, it's worth asking something different: was someone actually managing the time, or were we simply waiting for it?
Because most of the delays that cost a lot weren't technical. They were predictable. It's just that no one was watching them.
If your IT projects tend to stretch longer than planned, let's talk.
Let's talk about how to manage the time of your IT projects.