I’ve watched too many executives sign vendor contracts based on confidence rather than evidence.
The vendor presents a timeline. The board expects certainty. You’re caught in the middle, trying to determine if what you’re being sold is actually deliverable.
Here’s the uncomfortable truth: only 35% of projects worldwide finish successfully, meeting all goals and timelines. That means 65% fail to deliver as promised.
This isn’t about vendor honesty. Most vendors believe their own timelines. The problem is structural. They’re optimizing for winning the contract, not for accurate forecasting.
I’m going to show you how to evaluate software delivery feasibility before you commit millions of dollars and your company’s strategic timeline to a proposal that looks good on paper but collapses under scrutiny.
The Real Cost of Taking Vendor Timelines at Face Value
When you accept a vendor’s timeline without interrogation, you’re not just risking schedule slippage.
You’re risking everything downstream from that decision.
Large IT projects typically exceed their budget by nearly 50% and their scheduled timelines by 7%, often delivering 56% less value than initially projected. This isn’t an outlier. This is the pattern.
12% of project investment is lost due to poor performance. That amounts to trillions annually. Most of that waste stems from accepting vendor timelines at face value without interrogating the underlying assumptions.
The vendors aren’t lying to you. They’re presenting best-case scenarios as baseline expectations. They’re glossing over dependencies. They’re assuming perfect resource allocation. They’re ignoring the coordination costs that always emerge in complex software development.
Your job is to see through the optimism and assess what’s actually deliverable.
The Five Questions That Expose Unrealistic Timelines
1. How Did You Map Dependencies?
Most vendor proposals treat software development as a series of independent tasks that can be completed in sequence or parallel.
That’s not how software works.
Research shows that resource dependency contributed to 26% of project failures, while task dependency contributed to 12% of project failures. Yet many vendor proposals gloss over dependency mapping entirely.
When you review a proposal, demand to see the dependency map. Ask specifically:
- What external systems does this project depend on?
- Which internal teams need to provide input or approval?
- What third-party integrations are required?
- Which tasks cannot start until other tasks are complete?
- Where are the critical path bottlenecks?
If the vendor can’t show you a detailed dependency map, they haven’t done the analysis required to give you an accurate timeline.
2. What’s Your Actual Team Velocity on Comparable Projects?
Vendors love to talk about their “experienced teams” and their “proven methodologies.”
That’s marketing language. You need data.
Team velocity varies dramatically based on experience, domain knowledge, and team composition. A team with deep proficiency will complete tasks faster than an inexperienced team, but most vendor proposals don’t provide concrete velocity metrics from comparable past projects.
Ask for specifics:
- What was your team’s actual velocity on the last three projects similar to this one?
- How many story points or features did they complete per sprint?
- What was the variance between estimated and actual completion time?
- Can you show me sprint reports from those projects?
If they can’t provide historical velocity data, they’re guessing. And you’re being asked to bet millions on that guess.
3. How Are You Accounting for Part-Time Resource Allocation?
This is where most timelines fall apart.
Vendors often propose staffing models where senior architects or specialized engineers are allocated at 20% or 30% to your project. On paper, this looks efficient. In reality, it’s a coordination nightmare.
Part-time allocation creates:
- Context-switching costs that reduce effective productivity by 20-40%
- Scheduling conflicts that delay critical decisions
- Communication overhead that compounds with each additional part-time resource
- Knowledge silos when key people aren’t available when questions arise
Distributed teams require 10-25% additional time depending on timezone differences. Same-timezone remote teams need 10-15% extra. Multi-timezone teams need 20-25% additional time.
Ask the vendor:
- Which resources are full-time versus part-time on this project?
- What other projects are your part-time resources committed to?
- How are you accounting for context-switching costs in your timeline?
- What happens if a part-time resource becomes unavailable?
If they haven’t built buffer time into their estimates for coordination costs, their timeline is fiction.
4. What Buffer Did You Include for Known Unknowns?
Industry experts recommend adding 20-25% buffer time on top of estimates for factors like people getting sick, third-party vendors being slow to respond, bureaucracy, and misunderstandings.
Most vendor proposals present best-case scenarios without adequate buffers.
Here’s what I’ve learned: vendors who are confident in their estimates include explicit buffers. Vendors who are trying to win on timeline present aggressive estimates without contingency.
Ask directly:
- What percentage buffer have you included in this timeline?
- Where specifically have you allocated that buffer?
- What assumptions are you making about resource availability?
- How are you accounting for scope clarification and requirements refinement?
If they haven’t included explicit buffers, they’re planning for perfection. And perfection never happens in software development.
5. What’s Your Track Record on Scope Management?
78% of projects experience scope creep, often leading to failure. This isn’t an exception. This is the norm.
The question isn’t whether scope will change. The question is how the vendor manages scope change when it inevitably happens.
Ask about their process:
- How do you handle change requests?
- What’s your average scope increase on projects similar to this?
- How do scope changes impact timeline and budget?
- Can you show me examples of how you’ve managed scope creep on past projects?
Vendors who have mature scope management processes can show you data. Vendors who wing it will give you vague assurances about “agile flexibility.”
The Documentation Test: Separating Real Planning from Sales Theater
Here’s a simple test that reveals whether a vendor has done real planning or just sales theater.
Projects with documented requirements before development started were 50% more likely to succeed than those without. This directly contradicts the agile mythology many vendors promote about “figuring it out as we go.”
Ask to see:
- Detailed technical specifications
- Architecture diagrams with integration points identified
- Risk register with mitigation strategies
- Resource allocation plan with named individuals
- Dependency map with critical path analysis
If the vendor can’t produce these documents before you sign, they haven’t done the planning required to give you an accurate timeline.
The proposal should include specifics, not generalities. “We’ll use agile methodology” is not a plan. “We’ll conduct two-week sprints with daily standups, sprint planning on Mondays, and retrospectives on Fridays, with the following team structure” is a plan.
Red Flags That Signal Timeline Trouble
Some warning signs are obvious. Others are subtle. Here’s what I watch for:
Obvious red flags:
- The vendor can’t explain how they arrived at their timeline
- They’re significantly cheaper or faster than other bidders
- They promise aggressive timelines without contingency plans
- They minimize the complexity of integration points
- They’re vague about team composition and resource allocation
Subtle red flags:
- They emphasize their process over their track record
- They can’t provide references from similar projects
- They’re reluctant to commit to specific milestones with deliverables
- They deflect questions about past project performance
- They use conditional language when discussing timelines
66% of organizations report frequent project delays caused by unclear requirements. When vendors are vague upfront, they’re setting you up for inevitable schedule slippage.
What Good Looks Like: The Characteristics of Realistic Proposals
After reviewing hundreds of vendor proposals, I can tell you what separates realistic timelines from wishful thinking.
Realistic proposals include:
- Explicit assumptions documented in detail
- Historical velocity data from comparable projects
- Named resources with verified availability
- Detailed dependency mapping with critical path identified
- Buffer time explicitly allocated (15-25% minimum)
- Clear scope management process with change control
- Risk register with probability and impact assessment
- Milestone schedule with specific deliverables
Vendors who have done real planning can walk you through their assumptions. They can explain why they allocated specific time to specific tasks. They can show you how they accounted for dependencies and coordination costs.
They don’t just tell you the timeline. They show you how they built it.
The Framework: Your Pre-Signature Evaluation Process
Here’s the framework I use to evaluate software delivery feasibility before signing any contract.
Step 1: Demand the dependency map
No dependency map means no real planning. If they can’t show you how tasks interconnect, they haven’t thought through the complexity.
Step 2: Verify historical velocity
Ask for sprint reports from their last three comparable projects. Calculate their actual velocity versus estimated velocity. That variance tells you how much to discount their current estimates.
Step 3: Audit resource allocation
Map out every part-time resource. Calculate the coordination overhead. Add 20-25% to any timeline that relies heavily on part-time or distributed resources.
Step 4: Stress-test the assumptions
List every assumption in the proposal. Ask what happens if each assumption is wrong. If the timeline collapses when any single assumption fails, the plan is too fragile.
Step 5: Compare to industry benchmarks
40-50% of software projects are completed later than scheduled. If this vendor’s proposal assumes they’ll beat industry averages without explaining how, they’re selling you optimism, not realism.
Step 6: Require contingency planning
Ask what happens when the timeline slips. How will they recover? What’s their escalation process? Vendors who have thought this through have answers. Vendors who haven’t will deflect.
The Conversation You Need to Have Before You Sign
I’m not suggesting you become a project manager or a software architect.
I’m suggesting you ask the questions that reveal whether the vendor has done the work required to give you an accurate timeline.
The conversation should go something like this:
“I appreciate the proposal. Before we move forward, I need to understand how you built this timeline. Walk me through your dependency analysis. Show me your historical velocity data from comparable projects. Explain how you’re accounting for part-time resource allocation and coordination costs. Tell me where you’ve built in buffer time and why you chose that percentage.”
If they can answer those questions with specifics, you’re dealing with a vendor who has done real planning.
If they deflect or give vague assurances about their “proven process,” you’re being sold confidence instead of competence.
The Bottom Line
89% of US business decision-makers are concerned about the on-time delivery of software. That anxiety reflects hard-earned experience with vendor overpromises.
You can’t eliminate risk in software development. But you can dramatically improve your ability to assess whether a proposed timeline is realistic or wishful thinking.
The framework I’ve outlined isn’t about being adversarial with vendors. It’s about being rigorous in your evaluation.
The vendors who can answer these questions are the ones who have done the planning required to deliver on their promises. The vendors who can’t are the ones who will come back in six months asking for more time and more money.
Your job is to know the difference before you sign.
Because once you commit to a timeline that was never achievable, you own the consequences. The vendor will blame scope creep or changing requirements or unforeseen complexity. But the real problem was visible from the start.
You just needed to know what questions to ask.
