52.7% of software projects blow their budget – by an average of 189%

Not because teams are incompetent. Not because the project manager dropped the ball. But because the plan everyone relied on was a fiction from day one.

Anyone who’s sat through a Gantt chart presentation knows the feeling: color-coded bars, clean dependencies, a deadline that looks like a promise. The thing radiates control. And that’s exactly the problem.

What’s glowing on that screen isn’t a plan. It’s a bet. A bet that nothing significant will change over the next few months. No new requirements. No sick days. No surprises. In an industry that’s essentially made of surprises.

Three assumptions that destroy every project plan

The failure rates for IT projects are well documented by now. The Standish Group CHAOS Report has shown the same pattern for years: only about 16% of software projects finish on time and on budget. 78% get hit by scope creep – the slow, silent growth of requirements that nobody planned for.

Even more striking: Oxford and McKinsey studies show that 17% of large IT projects go so far off the rails that they threaten the survival of the entire company. These aren’t academic footnotes. That’s one in every six projects.

Behind these numbers are three assumptions baked into every traditional project plan – assumptions that almost never hold up:

Assumption 1: Completeness. The plan captures what needs to be done. In reality, you probably know about 60% of the actual requirements at project kickoff. The rest surfaces along the way – through client feedback after the first prototype, through technical dependencies that only become visible during implementation, through a market shift that turns the feature set upside down. A Gantt chart has no room for that. It only knows what was known on the day it was created.

Assumption 2: Linearity. Task A finishes, then Task B begins. In practice, tasks run in parallel, block each other, get reprioritized. A developer waits for an API spec that’s still sitting with the client. The designer needs content that won’t exist until sprint 3. The clean sequence in the chart only exists on screen.

Assumption 3: Control. Whoever has the plan has control. But a plan that’s outdated after two weeks controls nothing. It just creates a feeling of control – which is more dangerous than having no plan at all. Because then teams work against a reality that no longer exists. Daniel Kahneman called this the “planning fallacy” – the systematic tendency to underestimate effort and overestimate one’s control over a project. It’s not individual failure. It’s a cognitive bias baked into every Gantt chart ever created.

The gap between the plan and the desk

In most agencies and IT service companies, planning lives in a different world than execution. The project manager maintains their plan in Excel or MS Project. Developers work in Jira tickets. Communication runs through Slack. Time tracking happens somewhere else entirely.

Four systems that know nothing about each other.

The project manager looks at the plan and sees green. The developer looks at their board and sees red. The CEO asks in the weekly standup how things are going and gets a diplomatic answer somewhere in between.

57% of failed IT projects cite communication gaps as the primary cause. But the word “communication” obscures what’s really going on: the systems used for planning and the systems used for working are separate. What the plan says and what reality shows drift apart – a little more each day. Until eventually nobody looks at the plan anymore, because everyone knows it has nothing to do with what’s actually happening.

This isn’t just a tool problem. It’s a structural one. When planning and execution live in separate systems, the project manager becomes a human synchronizer – someone who spends half their working day transferring information from one system to another. Studies suggest project managers spend up to 60% of their time on coordination rather than decision-making. That’s not leadership. It’s data logistics.

And then Excel fills the gap. Because when the official tool fails, the spreadsheet steps in. Flexible, quick to set up, accessible to everyone. And just as quick to spiral out of control. One wrong cell reference, one forgotten row, one colleague working in an old version – and the “overview” becomes a blind flight.

For a single project, that might still work. But an agency with 15 parallel client projects doing capacity planning in Excel? That’s like an airline coordinating flight schedules on paper napkins.

What air traffic controllers do better than project managers

The comparison sounds extreme. It’s not.

An air traffic controller at a major airport coordinates dozens of aircraft simultaneously – each with its own schedule, route, and constraints. Planes get delayed. Weather changes. Emergencies happen. And yet it works. Not perfectly, but remarkably well.

How? Certainly not with a Gantt chart created at six in the morning that’s supposed to hold for the rest of the day.

Air traffic control works because it’s built on three principles that are almost always missing from project planning:

Real-time visibility. Controllers see where every aircraft is at all times. Not where it should be according to the plan – but where it actually is. In agencies, by contrast, nobody often knows exactly what a specific developer is working on right now. The plan says sprint 3, feature X. Reality says: hotfix for client Y, who escalated last night.

Proactive conflict detection. When two aircraft are on a collision course, the controller sees it minutes ahead – not at the moment of impact. In project planning, you typically notice resource conflicts only when two projects need the same senior developer at the same time. Then it’s improvisation, escalation, apologies. And some client waits.

Flow over master plan. Air traffic control doesn’t plan the entire day in the morning. It manages flow – continuously, in real time, with short horizons. Not “these 47 planes land today in this order,” but “the next three landings are these, and then we reassess.” That’s conceptually closer to iterative sprint planning than to a Gantt chart.

A company running 30 simultaneous projects without centralized prioritization is like 30 planes trying to land on the same runway at the same time. It doesn’t need a better plan. It needs a control tower.

And here’s the irony: most agencies have perfectly capable project managers. But they hand them tools built for a static world and expect results in a dynamic one. That’s like giving air traffic controllers a street map instead of a radar screen – technically a map, practically useless for the job.

Planning that breathes with reality

The answer isn’t to plan better. The answer is to plan differently.

Static planning assumes you can predict the future. Living planning accepts that you can’t – and builds on that acceptance.

Tickets over milestones. When the smallest planning unit is an actual work package – with an owner, effort estimate, status, and context – then the plan stays current automatically. A new requirement becomes a ticket. A bug becomes a ticket. A scope change reshuffles tickets. Plan and reality are the same thing, because the plan is made of real work, not abstract bars.

Capacity in real time, not as an assumption. On paper, the team has 400 hours per week. In practice, after vacations, sick days, meetings, and support, it’s maybe 280. Anyone planning with the theoretical number overloads the team. Anyone who sees actual availability – updated daily, per person – can make realistic commitments. That’s the difference between “we’ll get it done” and “we’ll actually get it done.”

Rolling sprints over annual plans. Instead of mapping out the entire project from start to finish, you plan week by week. What’s the most important work this week? Who has capacity? Where are the blockers? It sounds like less control – but it’s more. Because the plan reflects current reality, not assumptions from three months ago.

Consider this: a mid-sized agency with 35 employees switched from quarterly project planning to weekly sprint cycles in 2023. The effect wasn’t that they planned less – it’s that the plans were accurate. Before, they’d plan in January what should happen in March, then wonder why reality didn’t cooperate. After, they’d plan on Monday what happens this week, based on actual capacity and real priorities. Client complaints about missed deadlines dropped by a third. Not because the team worked faster. But because they were finally working on the right things.

Agencies that work this way consistently report the same outcomes: less coordination overhead, more focused teams, project managers working with real data instead of gut feeling. Not because they have better tools, but because their planning system stopped fighting reality.

Goldratt called this the difference between local efficiency and system efficiency in his “Theory of Constraints.” A Gantt chart optimizes locally – each task has its place, its duration, its dependency. But it doesn’t see the system. It doesn’t see the bottleneck blocking three other teams. It doesn’t see the overloaded senior developer juggling six projects at once. Living planning makes the constraint visible – and that changes everything.

From control tower to cockpit

Leadtime follows exactly this logic. The planning chain works like an air traffic control system: from strategic overview down to individual task lists, connected end-to-end, updated in real time.

At the company level, leadership sees all projects at once – prioritized by business value, not by gut instinct. At the team level, the pipeline distributes work based on actual capacity, updated daily, broken into 15-minute increments. And at the individual level, every developer sees exactly what’s next – no asking around, no searching, no wondering “what should I actually be working on?”

Priorities change? The system updates automatically. A project becomes urgent? Two clicks, and the pipeline redistributes. No manual reshuffling, no stale spreadsheets, no “but the plan says otherwise.”

This isn’t planning theater. It’s operational control.

The plan is dead. Planning lives.

Dwight D. Eisenhower – who wasn’t just a president but also coordinated the largest military operation in history – reportedly said: “Plans are useless, but planning is indispensable.” He didn’t mean you should stop planning. He meant the value lies in the process, not the document.

That’s the lesson for digital service companies in 2026. It’s not the perfect plan that makes the difference. It’s a planning process that lives. That adapts. That’s connected to the work actually happening.

Gantt charts were built for a world where little changes. IT services are the opposite of that. When your planning process is designed around change instead of against it, you stop fighting reality – and start working with it.

We built Leadtime because we were tired of maintaining plans that were obsolete three days after kickoff. Not because we have a better crystal ball – but because we stopped needing one.