I’ve watched too many executives sign contracts based on timelines that looked aggressive but achievable. Six months later, the project is bleeding budget, the team is burned out, and the vendor is explaining why “unforeseen complexities” pushed the delivery date.
The timeline was never realistic. It was designed to win the deal.
Here’s the uncomfortable truth: only 29% of IT projects deliver the expected results on time and within budget. The rest are either late, over budget, missing features, or outright failures.
You can spot an unrealistic timeline in 30 minutes if you know what to look for. The physics of software delivery don’t lie. Sales pressure does.
The $66 Billion Problem
McKinsey and the University of Oxford analyzed more than 5,400 IT projects. The total cost overrun? $66 billion. More than the GDP of Luxembourg.
66% of enterprise software projects exceed their budgets. A third blow past their schedules. Almost 20% fail to deliver the promised benefits.
These aren’t small projects run by inexperienced teams. These are enterprise initiatives backed by serious money and vendor commitments.
The pattern is clear. Vendors compress timelines to close deals. Executives approve them because the alternative feels like admitting defeat before starting. Then reality hits.
What Physics Looks Like
Software delivery follows predictable patterns. When you ignore them, the project suffers.
Staffing levels tell you everything. A vendor promises to deliver a complex integration in four months with a team of three developers. Do the math. Assume each developer works 160 hours per month. That’s 1,920 hours total.
Now subtract meetings, code reviews, documentation, bug fixes, and testing. You’re left with maybe 1,200 productive hours. If the scope requires 3,000 hours of work, the timeline is fiction.
I ask vendors to walk me through their resource allocation. How many hours per week is each key resource committed to this project? If the lead architect is allocated at 20%, that’s a red flag. Critical decisions will wait for their availability.
Part-time key resources kill timelines. You can’t compress critical path activities when the people who need to make decisions are only available two days a week.
Dependency Sequencing: The Invisible Bottleneck
Most timelines I review treat dependencies like suggestions. They show overlapping work streams that can’t actually happen in parallel.
You can’t finalize the API design while the data model is still being debated. You can’t start integration testing before the authentication layer is built. You can’t run user acceptance testing while developers are still fixing core functionality.
I look for critical path realism. What has to happen first? What can’t start until something else finishes? How much buffer exists between dependent tasks?
When I see a Gantt chart with every task starting the day the previous one ends, I know the vendor is selling optimism. Real projects have delays. Equipment arrives late. Key people get sick. Requirements need clarification.
Zero buffer means guaranteed delays.
Integration Complexity: Where Timelines Go to Die
Every integration point is a risk. The more systems you need to connect, the more time you need for testing, debugging, and handling edge cases.
I ask vendors to list every integration. Then I ask how many hours they’ve allocated for each one. If they say “two weeks for all integrations,” I know they’re guessing.
Each integration has its own timeline:
- Discovery: Understanding the existing system’s API, data formats, and authentication requirements
- Development: Building the integration layer
- Testing: Verifying data flows correctly under normal and edge-case conditions
- Debugging: Fixing the inevitable issues that emerge
- Performance tuning: Ensuring the integration doesn’t create bottlenecks
Multiply that by the number of integrations. Add time for coordinating with the teams that own those other systems. Factor in the reality that those teams have their own priorities and timelines.
If the vendor hasn’t accounted for this, the timeline is marketing.
Testing Windows: The Truth Detector
Testing reveals whether a timeline is grounded in reality or sales pressure.
I look at how much time the vendor allocated for:
- Unit testing: Does each component work in isolation?
- Integration testing: Do the components work together?
- System testing: Does the entire system function as expected?
- User acceptance testing: Does it meet the business requirements?
- Performance testing: Can it handle the expected load?
- Security testing: Are there vulnerabilities?
If testing is compressed into the final two weeks, the vendor is planning to ship problems. Unrealistic deadlines lead to stress, burnout, decreased morale, reduced productivity, and increased errors.
Compressed testing means deferred problems. You’ll find the bugs in production instead of before launch.
Red Flags You Can Spot in 30 Minutes
When I review a proposed timeline, I look for these warning signs:
1. Undefined discovery phase
If the vendor jumps straight into development without allocating time to understand your current systems, workflows, and requirements, they’re guessing. Discovery isn’t overhead. It’s how you avoid building the wrong thing.
2. Overlapping critical paths
When the timeline shows multiple critical activities happening simultaneously without acknowledging the dependencies between them, the vendor is ignoring physics.
3. Part-time key resources
If your lead architect, senior developer, or technical decision-maker is allocated at less than 80%, expect delays. Critical decisions will wait for their availability.
4. No buffer for unknowns
Every task ends exactly when the next one begins. There’s no room for the inevitable surprises that emerge in software projects.
5. Generic task durations
Everything takes exactly two weeks. Or one week. Or one month. When every task has a round number, the vendor hasn’t done the detailed planning required for accuracy.
6. Testing as an afterthought
Testing is compressed into the final weeks with no time allocated for fixing what testing reveals. This guarantees a choice between delaying launch or shipping problems.
7. No time for rework
The timeline assumes everything works perfectly the first time. Real projects require iteration, refinement, and fixing mistakes.
The Brooks’s Law Problem
When a project starts falling behind, the instinct is to add more people. This makes things worse.
Fred Brooks documented this in The Mythical Man-Month. Adding resources to a late software project makes it later. New team members need time to understand the codebase, the architecture, and the requirements. Existing team members lose productivity training them.
Communication overhead increases exponentially. A team of three has three communication paths. A team of six has fifteen. A team of ten has forty-five.
More people means more coordination, more meetings, and more opportunities for miscommunication.
When a vendor promises to solve timeline problems by adding staff, they’re revealing they don’t understand software delivery physics.
What Realistic Estimation Looks Like
Accurate estimation requires historical data and honest uncertainty acknowledgment.
Three-point estimation combined with historical velocity data provides 85-90% accuracy. This method accounts for uncertainty while using past performance for calibration.
I ask vendors to show me their estimation methodology. Do they have data from similar projects? Have they adjusted for the specific complexities of this engagement? Are they transparent about the uncertainty ranges?
When a vendor gives me a single date with no range, no confidence interval, and no acknowledgment of variables, I know they’re selling certainty they don’t have.
The Questions That Reveal Truth
You can evaluate a timeline by asking these questions:
“Walk me through your critical path. What has to happen in sequence?”
This reveals whether they’ve thought through dependencies or just stacked tasks on a calendar.
“How many hours per week is each key resource allocated to this project?”
This exposes part-time resource problems before they become delays.
“What happens if we find a major issue during integration testing?”
If they don’t have an answer, they haven’t planned for the inevitable problems.
“Show me how you estimated each major task.”
This separates detailed planning from guesswork.
“What similar projects have you delivered? How did actual timelines compare to initial estimates?”
Historical performance predicts future results better than promises.
“Where have you built in buffer for unknowns?”
If there’s no buffer, there’s no realistic planning.
The Cost of Getting It Wrong
Unrealistic timelines don’t just cause delays. They create cascading problems.
Rushed development produces technical debt. Shortcuts taken to meet impossible deadlines become permanent fixtures that slow down future work. Compressed testing means bugs reach production. The cost of fixing them multiplies.
Teams burn out. Your best people leave. The institutional knowledge walks out the door with them.
Vendor relationships deteriorate. Trust erodes. The project becomes adversarial instead of collaborative.
Market opportunities close. The competitive advantage you were building disappears while you’re still fixing problems.
An unrealistic timeline costs more than money. It costs momentum, morale, and market position.
What to Do With This
You don’t need to become a project manager to evaluate timelines. You need to ask the right questions and recognize the patterns.
When a vendor presents a timeline, spend 30 minutes examining it through the lens of physics instead of optimism. Look at staffing levels. Trace the critical path. Count the integration points. Measure the testing windows. Check for buffer.
If the timeline fails these tests, push back. Ask the vendor to revise it based on realistic resource allocation and dependency sequencing. If they resist, you’ve learned something valuable about how they operate.
The timeline that wins the deal isn’t always the timeline that delivers the project. Your job is to distinguish between them before you sign.
Physics always wins. Sales pressure never does.
