Breaking the Cycle of Budget Overruns: Root Causes of

I. Inadequate Technical Requirements: Requirements Engineering—The Bedrock of Product Development

Requirements Engineering (RE) is the starting point of product development. Its output establishes the project's objectives and serves as the foundation for all subsequent work. Every design iteration must revolve around these requirements, and the final design must validate against them. Ultimately, the success of a product is measured by its degree of requirement fulfillment.

The core task of RE is to translate the Voice of the Customer (VOC)—encompassing users, regulations, and internal manufacturing—into objective, quantified engineering language. This process is divided into three critical stages:

1.1 Requirements Elicitation: Finding the "Full Set"

The first step is elicitation. The central challenge is: Can we identify all requirements without omission?

• Goal: Identify the complete set of requirements, not just explicit ones.
• Methodologies & Tools:
  • Iceberg Model: Visually deriving latent requirements below the surface.
  • Kano Model: Scientifically categorizing requirements into Basic, Performance, and Excitement factors to define priorities.
  • Personas & User Journey Maps: Simulating real-world scenarios to uncover needs that customers themselves may not have realized.
• Output: Rationalized requirement specifications covering not just functionality, but also environmental factors like temperature, humidity, vibration, and misuse scenarios.

1.2 Requirements Development: Quantified Description and the 4C+4 Principles

This involves describing elicited needs in a quantified, standardized, and clear format.

• Core Principle: Requirement descriptions must not contain the implementation method. For example, state "The system shall respond within 3 seconds," rather than "The system shall use XX chip."
• Quality Standards (4C+4): High-quality requirements must be:
  1. Complete: Covering all scenarios and boundaries.
  2. Correct: Accurately reflecting user intent and physical laws.
  3. Consistent: No logical conflicts between requirements.
  4. Clear & Unambiguous: Only one interpretation possible.
• Tool-Aided Quality: Utilizing Natural Language Processing (NLP) tools or Requirement Quality Checklists to automatically scan for vague terms (e.g., "fast," "roughly") to ensure precision.

1.3 Requirements Management: Change Control and Bidirectional Traceability

Managing requirements throughout the lifecycle involves rigorous change and version management.

• Structured Control: In modern R&D, Word or Excel cannot handle the complexity of traceability. Professional tools (e.g., Jama Connect, IBM DOORS Next, Polarion, Codebeamer) are mandatory.
• Core Values:
  1. Automated Requirements Traceability Matrix (RTM): Tools generate links from "User Needs → System Requirements → Design Elements → Test Cases." Any broken link triggers an immediate alert.
  2. Impact Analysis: When a requirement changes, the tool highlights affected downstream design and testing, forcing an evaluation of the cost of change and preventing arbitrary "gut-feeling" decisions.
  3. Baseline Management: Recording every change history to ensure the ability to revert to any previous state.

Cost Analysis: Data shows that RE investment determines project survival. If RE investment is below 4% of the total budget, overruns often exceed 120%. If increased to 15%, overruns can be controlled within 20%.

II. Deficient Systems Engineering: Global Collapse from Local Optimization (The Vasa Syndrome)

When quality issues arise and departments shift blame (e.g., hardware, mechanical, and software teams all claiming their parts are qualified), the root cause is usually a lack of Systems Engineering (SE). Without top-level architecture design, interfaces become blurred, and performance gaps create "vacuum zones" where no one is responsible.

2.1 Historical Lesson: The Sinking of the Vasa

In 1625, Sweden built the Vasa, intended to be the most powerful warship of its time.

• Initial Architecture: Planned with a single gun deck—a feasible architecture for stability given the technology.
• Local Optimization Compromising the Global System: The King demanded a second gun deck for superior firepower (local optimization).
• Lack of System Assessment: This change met a single metric but ignored coupling effects:
  • Center of Gravity (CoG) Imbalance: Rising CoG destroyed stability.
  • Architectural Failure: The original hull structure could not support the new weight distribution.
• The Result: In 1628, the Vasa capsized after sailing only 1,300 meters. The primary cause was the lack of a systems engineer to perform "Architectural Suitability Verification."

2.2 Implications for Modern R&D

• Irrational Architecture: Leading to incomplete performance coverage (e.g., failing to include stability as a core system metric).
• Interface Vacuums: Poor integration between sub-systems creating ownership gaps.
• Delayed Discovery: Systemic flaws are often found late in development or during mass production, where the cost of correction is astronomical, leading to total budget collapse.

III. Insufficient Risk Identification and Response: From "Pro Forma" to "Comprehensive Sets"

Risk identification includes technical, process, and cost risks. For international projects, it must also account for cultural conflicts and communication risks. Without robust identification, effective mitigation strategies are impossible.

3.1 Challenges in Forward Development

Many companies are transitioning from reverse engineering to forward development. It is vital to recognize that unknown risks in forward development are significantly higher, which is why its development costs are greater. Inadequate risk identification leads to insufficient budget reserves, which worsens the financial status when problems surface late.

3.2 The FMEA Pitfall: Depth vs. Page Count

FMEA (Failure Mode and Effects Analysis) is a standard tool for risk identification. However, many organizations fall into "formalism":

• The Status Quo: FMEA reports are often just a few pages, covering only obvious, common failure modes while missing complex system-level interaction risks.
• The Benchmark: Global leaders produce FMEA reports spanning thousands of pages, representing a comprehensive set of risk thinking:
  • Extreme Granularity: Analyzing every component, operating condition, and even potential human error.
  • Wide Coverage: Deep analysis of multi-part coupling, hardware-software interactions, and chain reactions in extreme environments.
  • Dynamic Updates: FMEA is a living document that must incorporate new insights and test data continuously.

Conclusion: The difference in the "thickness" of an FMEA is essentially the difference in the depth of risk cognition. Only by achieving "total coverage" can companies avoid the massive resource drain caused by unforeseen late-stage issues.

IV. Misunderstanding Technical Cause-and-Effect: Addressing Symptoms vs. DRBFM Application

Without deep analysis, a problem might appear solved but will likely recur. To truly understand technical cause-and-effect, the DRBFM (Design Review Based on Failure Mode) methodology must be applied.

4.1 Step 1: Impact Analysis

• Core: Identify changes in physical behavior and their impact on functionality resulting from a design change.
• Analysis: How does the change affect physical dimensions (force, heat, electricity, material properties)? How do these changes propagate? Avoid the Vasa mistake of seeing only the benefit (firepower) while ignoring the side effect (CoG).

4.2 Step 2: Risk Identification

• Core: Systematically explore secondary side effects beyond the obvious risks.
• Analysis: Will the change trigger a chain reaction? Will it induce new failures under extreme conditions? Break the limitation of "treating the symptom" and fill the blind spots in risk cognition.

4.3 Step 3: Problem Solving

• Core: Solve potential failures by analyzing the causal chain.
• Analysis: Dive into the underlying physical mechanisms to build a complete Cause-Effect Chain. Trace from the phenomenon back to the mechanism, then to the root cause. Only by understanding "why it happens" can a failure be fundamentally eliminated, preventing recurring costs.

V. The Solution: Front-Loading the R&D Effort

The core strategy is to implement "Front-Loaded" R&D—investing more effort early to reduce "firefighting" later.

Implementation Plan:

1. Prioritize Requirements: Significantly increase investment in early-stage elicitation, development, and management. Move resources into the 15%+ healthy zone to ensure control and traceability.
2. Architecture First: Learn from the Vasa. Before any major change, perform System-Level Architectural Suitability Verification to prevent global collapse from local optimizations.
3. Comprehensive Risk Sets: Move beyond superficial FMEAs. Strive to build a risk identification system that covers the entire landscape with no blind spots.
4. Causal Insight: Use the DRBFM three-step method to dissect design differences. Turn technical understanding into a core competency to ensure problems are solved at the root.
5. Strategy-Driven:
   • Start high-effort tasks as early as possible.
   • Clarify technical bottlenecks in advance.
   • Make "Risk-Based Decisions" to avoid schedule passivity caused by indecision.

Conclusion

While R&D budget overruns are common, they are not inevitable. By solidifying the foundation of Requirements Engineering, strengthening the top-level perspective of Systems Engineering, pursuing comprehensive risk identification, and gaining deep causal insights, enterprises can minimize budget deviations and achieve high-quality delivery.