Why projects fail before they begin

The Most Expensive Assumption in Project Management

The most dangerous phrase in project management is: “This should be straightforward.” In our experience delivering complex data and technology programs, that single assumption – made at project initiation – is responsible for more budget overruns, missed deadlines, and strained client relationships than any technical failure that follows.

Projects do not fail at the finish line. They fail at the starting line – when teams commit to a delivery plan without fully understanding what the project actually involves. Complexity that is invisible in Week 1 does not disappear. It surfaces in Month 4, when schedules are locked, budgets are spent, and stakeholder patience is wearing thin.

Consider an engagement we delivered for a client. The objective was to automate a manual, Excel-based monthly reporting process – time-consuming, error-prone, and costly in person-hours at every month-end close. The solution appeared well-defined: consolidate data from source systems into a central Datamart, identify the missing reporting attributes, bring them in, and build automated reports on top. The project was scoped at seven months.

It took nearly twice that. At roughly double the budget. And only the data layer was completed.

“The question is never whether complexity exists. The question is whether you find it in Week 1 – or Month 7.”

What Complexity Looks Like When You Start Peeling the Onion

The initial project brief described a narrow, well-bounded scope. What it did not – and could not – capture was the underlying complexity hidden beneath the surface. That complexity only became visible once the team began the real work of discovery.

Within the first weeks of delivery, several realities emerged that had not been surfaced during scoping:

• Data did not come from a single source. Multiple systems fed the excel reports, each with its own logic, ownership model, and data quality profile – none of which had been mapped.
• Key attributes were derived, not stored. Several required reporting fields were calculated values dependent on relationships between other attributes, requiring transformation logic rather than simple data movement.
• Granularity mismatches created model complexity. Certain attributes existed at different levels of detail than others, requiring structural changes to the existing data model that had not been anticipated.
• Identical names masked different meanings. Attributes that appeared in multiple reports under the same name were, in fact, distinct data elements with entirely different business definitions.
• Existing data did not match business expectations. Several attributes already present in the Datamart held values inconsistent with what the client expected to see in their reports, generating additional scope for items that were assumed complete.

Each discovery, individually, was manageable. Collectively, they compounded into a project that bore little resemblance to the one that had been scoped and priced. The team was not dealing with the project they planned for. They were dealing with the project that actually existed.

Complexity Understood Is Complexity Managed

None of this is an argument against taking on complex projects. Complexity is inherent in any meaningful technology or data program – it cannot be eliminated. But it can be understood early, planned for deliberately, and managed effectively. The teams that deliver complex projects successfully are not the ones who encountered less complexity. They are the ones who saw it clearly before they started.

When complexity is surfaced upfront, three things become possible that are not otherwise:

Realistic Planning Grounded in Reality

A plan built on accurate complexity is a plan that can actually be executed within schedule and within budget. Timelines reflect what the work genuinely involves. Budgets account for the real scope. Resource requirements are sized to the actual challenge. Milestones are achievable because they were set with full information. This is not pessimism – it is precision. And precision is what separates projects that deliver from projects that disappoint.

Risk and Challenge Identification Before They Become Crises

Complexity that is understood becomes a list of known risks. Known risks can be assessed, prioritized, and planned around. You can build contingency for the data quality issues you expect to find. You can schedule stakeholder alignment sessions before the conflicting definitions surface mid-sprint. You can identify the governance gaps and address them before they block your delivery pipeline. Risk that is seen in Week 1 is a planning input. The same risk discovered in Month 5 is a project crisis.

Client Confidence Built on Honest Expectations

When clients understand the complexity of what they are undertaking, they are partners in navigating it – not audiences for a failure they did not see coming. Transparent conversations about complexity at initiation build the kind of trust that survives difficult moments in delivery. Clients who feel informed and respected become advocates. Clients who feel blindsided become adversaries.

The Pre-Discovery Investment: Small Cost, Outsized Return

The practical implication of all of this is a structured pre-discovery phase before any delivery commitment is made. In data and technology programs, this means investing dedicated time – typically two to four weeks – to understand the landscape before scoping the journey.

A rigorous pre-discovery effort should address:

• Source system assessment: Where does the data actually come from? How many systems are involved? What are the data quality profiles and known issues?
• Data definition validation: Do stakeholders agree on what the data means? Are there naming inconsistencies, conflicting definitions, or derived fields that require transformation logic?
• Model and architecture review: Does the existing data model support the reporting requirements, or will structural changes be needed?
• Stakeholder and ownership mapping: Who owns the data? Who has authority to approve definitions and validate outputs? Are those individuals available and prepared for that role?
• Risk and assumption log: What are we assuming to be true that we have not yet verified? What would change the scope and plan if those assumptions proved wrong?

A pre-discovery phase does not guarantee a perfect project plan. No plan survives delivery intact – new complexity will always surface as work progresses. But it shifts the team from reactive to proactive. It means that when new complexity emerges – and it will – the team has a foundation robust enough to absorb it, and a client relationship strong enough to have an honest conversation about it.

In our experience, a well-executed pre-discovery investment consistently returns ten to twenty times its cost by preventing the scope creep, rework, and delivery failures that come from planning against an incomplete picture. The goal is not a frictionless project. The goal is a project where friction is anticipated, planned for, and navigated – rather than absorbed as a surprise.

Sannish Kamat

Author

Follow us on