Thirteen years of auditing software projects lead to a clear conclusion: projects don't fail because of bad luck, they fail because of thirteen mistakes that are
They are repeated. Four are planning-related (open scope, wrong team, impossible deadline, faith-based budgeting). Four are execution-related.
(No tests, no documentation, technical debt from day one, decisions by consensus). Five are governance issues (no clear owner, committees)
(No decision-making, vague metrics, no acceptance criteria, constant change without prioritization). Detecting these issues in the first two weeks prevents the 90% (a Spanish tax code).
of the cost.
The literature on software project management is saturated with best practices. What's lacking is honesty about mistakes. After thirteen years of auditing stalled or failed projects, we've identified thirteen errors that are repeated in almost every case. Knowing them by name allows us to detect them in the first two weeks, when they can still be corrected at a reasonable cost. Detecting them in month six costs between 5 and 20 times more.
We group them into three categories: planning errors, execution errors, and governance errors.
Error 1 · Open scope signed as closed. The contract says “CRM implementation” but doesn’t specify which modules, integrations, or level of customization. Each party believes they signed a different scope. The discussion about what’s included and what’s not starts in month three and never ends. Solution: sign scope by module with explicit deliverables.
Error 2 · Wrong equipment for the project type. Hire Big
Four for a quick MVP is inefficient. Hiring a freelancer for a
A regulated critical system is risky. Hiring a senior boutique for a
Small jobs are expensive. The choice of provider determines the outcome.
than any methodology.
Error 3 · Impossible deadline signed due to commercial pressure. The client needs
“"For June" because he has a confirmed announcement. The supplier
He signs knowing it's impossible because he needs the contract. The project
It's scheduled to be released in September, the announcement falls through, and everyone blames each other.
Solution: estimate honestly and reject the impossible.
Error 4 · Faith-based budgeting. Estimates of “more or less”
This” without a breakdown of milestones, without contingency, and without criteria for change.
When the project deviates by a 30% in month two, there is no way to
To determine if it is reasonable or catastrophic. Solution: detailed estimate by
module with signed buffer.
Error 9 · No clear project owner at the client. Projects
where “the project is about technology but also about operations, also
"of marketing and also of sales." When everyone is an owner,
Nobody is. Decisions are postponed, deliverables are delayed.
They remain unvalidated and the project slows down. Solution: a single
responsible with real authority from day one.
Error 10 · Committees without decision-making power. Bi-weekly meetings
with fifteen people where no one has the power to make decisions that
They matter. They serve to inform, not to decide. Solution: meetings of
separate decisions from information meetings, with signed power of attorney.
Error 11 · Vague or absent metrics. “That it works well and users are happy” is not a metric. Without objective metrics, the decision to
“"It's finished" depends on the mood of the person taking it. Solution: metrics declared before the first commit, measured weekly.
Error 12 · No signed acceptance criteria. The project enters testing without an agreed-upon definition of "accepted." The
Endless discussions about whether bug X is blocking or not. Solution: signed acceptance criteria at the beginning of the module, before starting it.
Error 13 · Constant change without prioritization. Each week the client adds new requirements without removing any from the backlog. The project grows without
Neither the timeframe nor the budget should increase. It will eventually explode. Solution: a signed policy of changes where adding is possible, but it requires removing something.
or extend the deadline and budget.
The first two weeks of a project are the most important. If three or more of the thirteen errors are detected during that period, the project is at risk.
at risk, and we must stop before moving forward. Five questions you can ask in a 60-minute meeting:
If the answer to three or more is “no” or “not at all”, you have to stop and
resolve before moving forward.
No, but the cost is significantly reduced when problems are identified early. A perfect project doesn't exist. A well-managed project is one that detects errors in weeks, not months.
In our experience, error 1 (open scope) and error 9 (no clear owner) are the most expensive because they amplify all the others.
Not on their own. A poor agile implementation can become "scrum without discipline" and reproduce all the same mistakes under a different name. Discipline matters more than methodology.
There are tools (SonarQube, CodeClimate) that provide objective metrics. The important thing is to measure it from day one, not to discover it in month six.
When the estimated cost of completion exceeds the expected value of the deliverables, it's an uncomfortable but sometimes necessary decision. We've recommended this to clients who hired us for audits.
Yes, that's exactly the function. A 10-day audit with TCG covers the thirteen errors and delivers a short report highlighting the most critical ones for the specific project.
An honest diagnosis: what can be salvaged, what needs to be rewritten, what needs to be stopped. Sometimes moving forward with extra effort is more expensive than redoing part of it.
The decision depends on the specific case and should be made with an external perspective.
Software projects don't fail because of the technology chosen or bad luck. They fail because of a predictable combination of errors.
Planning, execution, and governance. Knowing the thirteen errors by name allows you to detect them in time and correct them while they are still present.
It's possible. If your project identifies three or more issues, an external audit is advisable before investing further resources.
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
