Why Most Projects Fail Before Coding Starts (The Left Side of the V)
By A. Perico
7 min read
Most problems in engineering projects are created before development even begins—during system definition.
Why Most Projects Fail Before Coding Starts
Most teams still act as if engineering risk begins when coding begins. That is one of the most expensive misunderstandings in delivery. By the time code becomes visible, many of the critical decisions have already been made, often without being treated as decisions at all. Scope boundaries, stakeholder tradeoffs, operational assumptions, verification intent, and system behavior have already started to harden. If that work is weak, development is not building a system. It is building interpretations.
The reason this confusion persists is simple: code is visible, demos are visible, sprint velocity is visible. Early system definition is much quieter. It looks slower. It produces fewer screenshots. But visible activity is not the same as control. The left side of the V-model exists because the most consequential mistakes are usually introduced before implementation, not during it.
The part most teams underestimate
The left side of the V is often misread as paperwork. It is not. It is the phase where the organization decides what problem it is solving, for whom, under which constraints, with which operational logic, and how success will later be judged. If those decisions are fuzzy, late, or fragmented across teams, development fills the gap with assumptions.
NASA puts it directly: “While the most dramatic impacts of the analysis and optimization activities associated with systems engineering are obtained in the early stages, decisions that affect cost continue to be amenable to the systems approach even as the end of the system lifetime approaches.”
NASA Systems Engineering Handbook, Program and Project Life Cycle
That is the point many software organizations still resist. Early system definition is not about formality for its own sake. It is about moving the hard thinking to the point where alternatives are still cheap, interfaces are still negotiable, and misunderstandings have not yet been compiled into architecture and code.
What the left side is supposed to produce
At a minimum, the left side should leave the team with a stable answer to several questions. What problem are we solving? Who are the relevant stakeholders? What does the system need to do in its operational context? Which constraints are real and which ones are only habits? What will count as verification and what will count as validation? If those answers do not exist in a shared and usable form, the program is already loading risk into implementation.
NASA’s early life-cycle guidance is useful here because it does not describe vague alignment rituals. It describes concrete engineering outputs. In Pre-Phase A and Phase A, the work includes identifying stakeholders, capturing expectations, developing and baselining the Concept of Operations, drafting system-level requirements, defining preliminary verification and validation approaches, and performing trade studies before the design hardens.
NASA emphasizes that in Pre-Phase A it is important “to develop and mature a clear vision of what problems the proposed program will address, how it will address them, and how the solution will be feasible and cost-effective.”
That sequence matters. Teams that skip directly to implementation usually do not skip system definition. They relocate it into code reviews, defect triage, interface debugging, and emergency clarification meetings. The work still happens. It just happens later, with worse information and at higher cost.
What failure looks like in real projects
In practice, weak left-side work shows up through patterns that are easy to recognize. Requirements arrive late. Use cases are incomplete. Operational assumptions are spread across meetings. System boundaries are unclear. Interfaces are treated as details to be solved during implementation. Development starts anyway because something can always be built.
That is how responsibility inversion happens. Development teams begin writing the requirements the system team should have produced. Testers start constructing behavior expectations from experience rather than from an agreed system definition. Validation slowly turns subjective because there is no stable artifact left to validate against.
I have seen this in both automotive and commercial environments. A proof of concept becomes a product before anyone finishes defining the system. A UI mock-up becomes the de facto requirement because it is more visible than the specification. A backlog becomes the scope baseline because no one can connect work items back to system intent. None of these moves look catastrophic on day one. They become catastrophic when integration exposes incompatible interpretations that are now expensive to reverse.
Why the bill arrives late
The most dangerous thing about weak early definition is that it often does not fail immediately. Teams can continue shipping visible work for quite a while. The cost arrives later through rework, interface churn, test instability, and expensive changes to baselined design decisions.
NASA is explicit about that transition point: “significant design changes at and beyond Phase B become increasingly expensive.”
This is why the phrase ‘we will figure it out during development’ is not pragmatic in most serious systems. It is usually just a decision to move ambiguity into a more expensive phase. The multiplier is not always the same across domains, but the pattern is stable: the later the clarification, the greater the coordination cost and the smaller the available design freedom.
Trade studies should come before hard design
One of the clearest symptoms of weak left-side execution is when trade studies are performed after architectural direction is already emotionally fixed. At that point, the study is no longer shaping the design. It is rationalizing it.
NASA’s guidance is unambiguous: “Trade studies should precede—rather than follow—system design decisions.”
That line matters because it separates real systems engineering from process theater. The point of early analysis is not to delay implementation indefinitely. The point is to make sure alternatives are assessed while the organization can still choose among them without tearing up a mature design baseline.
This is not an argument for heavyweight process
The usual objection is that all of this sounds like big-company overhead. Sometimes that objection is fair. Poorly implemented systems engineering can absolutely become document production detached from real delivery. But that is not an argument against early system definition. It is an argument against bureaucracy that does not improve decisions.
NASA explicitly frames tailoring this way: the goal is to “obtain the desired benefits while eliminating unnecessary overhead.”
NASA Systems Engineering Handbook, Tailoring and Customization
The distinction is important. The left side of the V does not require massive documentation. It requires enough explicit system definition to keep implementation from inventing the system in fragments. For a smaller product, that may be a concise problem statement, key stakeholders, main operational scenarios, system boundaries, critical constraints, and an agreed verification approach. For a larger or safety-critical system, the depth and rigor should rise accordingly.
Even agile practice points in the same direction when it is applied seriously. Agile Alliance describes value in having an explicit contract for what ‘done’ means and notes that this reduces misunderstanding, conflict, and rework. That principle scales beyond sprint closure. Explicit shared criteria reduce ambiguity. Ambiguity does not create agility. It creates downstream interpretation cost.
Agile Alliance notes that an explicit Definition of Done “limits the cost of rework once a feature has been accepted as ‘done’” and “limits the risk of misunderstanding and conflict.”
What actually works
The practical answer is not to demand perfect requirements before any line of code exists. That standard is unrealistic and often dishonest. The practical answer is to define enough of the system early enough that implementation is guided by intent rather than by local interpretation.
- Define the problem, not just the feature list: the team needs a shared understanding of the mission, operational context, and constraints.
- Capture the main use cases and interfaces: unclear boundaries and interactions create hidden system behavior later.
- Baseline early verification and validation thinking: if success criteria are undefined, teams will optimize for output instead of correctness.
- Run trade studies before architectural commitment: analysis after the fact is usually justification, not engineering.
- Tailor the rigor, not the intent: eliminate unnecessary ceremony, but do not eliminate explicit system definition.
If these elements exist, development can move quickly without guessing what the system is supposed to become. If they do not exist, the speed is mostly an illusion. The project is only moving ambiguity downstream.
Final thought
Most projects do not fail because developers wrote poor code first. They fail because the organization made weak system decisions early and then allowed code, tickets, and tests to absorb the consequences.
The left side of the V is not where progress slows down. It is where the system becomes explicit enough for progress to mean something.