I’ve spent nearly three decades watching IT projects collapse.
Not because the technology was impossible. Not because the team was incompetent. Not because requirements changed halfway through.
The failure was already there. In the contract. In the plan. In the assumptions everyone agreed to without reading closely enough.
Here’s what nobody wants to admit: most IT project failures are preventable, and the evidence sits right there in the documents you signed months before the first line of code gets written.
The Numbers Don’t Lie About What We’re Missing
According to the Project Management Institute, only one in every 200 IT projects meets all three success measures: on time, on budget, and delivering intended benefits.
One in 200.
Projects that fail to meet one or more measures exceeded their budgets by 75%, overran their schedules by 46%, and generated 39% less value than predicted.
The cost of unsuccessful development projects in 2020 reached an estimated $260 billion. That number has grown by 46% since 2018.
But here’s the part that keeps me up at night: 75% of respondents think their projects are doomed to fail from the start. They feel it. They know it. And they sign anyway.
The Real Problem Hides in Plain Sight
I’ve reviewed hundreds of contracts over the years. Statements of Work. Master Services Agreements. Project plans that look impressive in PowerPoint.
The patterns repeat.
A PwC Global Survey found that 32% of project failures trace back to poor estimation during the planning phase. Nearly 37% fail because of unclear goals. Another 66% of organizations report frequent delays caused by unclear requirements.
This isn’t a technology problem. This is a documentation problem.
The vendor writes a proposal that sounds confident. The internal team doesn’t have the project management depth to spot the gaps. Legal reviews the contract for liability, not for deliverability. Procurement checks the budget numbers.
Nobody asks the harder question: Can this actually be done the way it’s written?
What I Look For When I Read Your Documents
When I assess a project before it starts, I’m not looking at the technology stack. I’m looking at the structure of the promises being made.
I review:
- Statements of Work that define scope
- Master Services Agreements that set governance
- Proposals and estimates that commit to timelines
- Project plans that map dependencies
- Acceptance criteria that determine “done”
- Jira backlogs when they exist
I’m looking for the preventable failure modes.
The places where the language creates impossible conditions. Where the timeline assumes perfect execution. Where acceptance criteria conflict with technical reality. Where governance gives all the power to the people with the least context.
Research shows that projects with documented requirements before development starts are 50% more likely to succeed than those without them.
But having requirements isn’t enough. They need to be clear, complete, and connected to realistic delivery assumptions.
The Warning Signs Most People Ignore
Kappelman, McKeeman, and Zhang identified 53 early warning signs for IT project failure. A clear top 12 emerged.
Half were people-related:
- Lack of top management support
- Weak project manager
- No stakeholder involvement
The other half were process-related.
The problem? We’re terrible at identifying these signals early. And when we do spot them, we rarely respond before the problems compound.
I see this in contracts all the time. The SOW describes a project manager role, but the governance structure strips them of decision-making authority. The timeline shows aggressive milestones, but the acceptance process requires three layers of approval with no defined SLA.
These contradictions don’t resolve themselves. They become the project.
Why Communication Failures Start on Page One
80% of project failures are attributed to poor communication and collaboration.
But communication doesn’t break down during standups. It breaks down when the contract uses vague language that everyone interprets differently.
I’ve seen vendors and clients argue for months about what “substantial completion” means. I’ve watched teams debate whether a feature is in scope because the SOW said “user management” without defining what that includes.
The contract is the first communication artifact. If it’s ambiguous, everything that follows will be ambiguous.
When I review documents, I look for precision. Not legal precision. Operational precision. Can two people read this sentence and build the same thing?
The Hidden Cost Nobody Calculates
The biggest cost isn’t the budget overrun. It’s the momentum you lose.
Failed implementations delay automation initiatives. They push back expansion plans. They stall customer experience improvements. They derail M&A activity.
The real money evaporates in the business performance that never materializes.
17% of large IT projects fail so badly they threaten the existence of the company. And 70% of organizations suffered at least one project failure in the past 12 months.
You can recover from a budget overrun. Recovering from 18 months of lost competitive advantage is harder.
What Makes This Assessment Different
I don’t compete for delivery work.
This isn’t vendor validation. It’s not legal advice. It’s not project management. It’s not contract negotiation.
This is an opinion-based advisory assessment grounded in real project experience.
I tell you what I see in the documents. I point out the failure modes. I explain why certain language creates risk. I show you where the plan diverges from realistic delivery.
Then you decide what to do with that information.
Most organizations don’t have internal PM depth to catch these issues. The people signing the contracts aren’t the people who will execute them. The people executing them aren’t empowered to push back on what was promised.
That gap is where projects die.
Who Needs This Kind of Review
You need this if you’re an executive or founder about to sign a major services agreement.
You need this if you’re a CIO, COO, or program sponsor without a strong internal project management team.
You need this if your legal and procurement teams are excellent at contracts but don’t have deep project delivery experience.
You need this if you’ve been burned before and want to understand why before it happens again.
The Question You Should Ask Before You Sign
Can this actually be delivered as written?
Not “Is this a good vendor?” Not “Is this a fair price?” Not “Did legal approve it?”
Can the thing described in these documents actually happen the way everyone expects?
Because if the answer is no, you’ll find out eventually. Usually when you’re six months in, 40% over budget, and the vendor is pointing to page 23 of the MSA to explain why what you thought you were getting isn’t what they thought they were building.
I’ve been doing this long enough to spot those moments before they happen.
The failure is already there when you sign. But you can still choose not to sign.
