Frozen specifications are a myth
Then, slowly, I came to realize that the most useful service I was performing for my client was helping him decide what he really wanted.
Fredrick P. Brookes, The Design of Design
In the world of project management, there is a common doctrine: do not start until the specifications are “frozen”. However, seasoned product developers know that nothing could be further from the truth. In reality, the very process of documenting specifications brings a clarity that often unveils new insights, rendering those original specs obsolete almost as soon as they are documented.
In fact, if specifications do not change during a development project, it is often a red flag that something critical is being overlooked. The challenge isn’t preventing change—it’s managing the inevitable evolution of the product.
1. Flexibility by design
To navigate changing requirements, you must avoid freezing your design too early. The secret lies in freezing only to the extent required to keep moving forward. Sometimes, the wisest move you can make is to defer a design decision until more data is available.
The approach to design flexibility depends on your domain:
- Architecture vs. Detail: Dividing the effort into “Product Architecture” and “Detailed Design” is a time-tested, robust approach.
- Modularization: Freeze the interfaces between modules early within the overall architecture, but leave the internal details of those modules flexible until requirements are fully crystallized.
- Hardware vs. Software: In modern electronics, the trend is to use general-purpose hardware and allocate user-specific functions to software. Concepts like Software Defined Vehicles (SDV), Networks (SDN), or Radio (SDR) are now architectural imperatives.
2. Anticipate the Pivot
With experience, teams learn where the “tectonic plates” of a project are most likely to shift. Most customer-induced changes relate to how the end-user interacts with the product—the User Interface (UI) or Human Machine Interface (HMI).
The Strategy: Separate the HMI from the “Machine Core”. By using non-dedicated, software-intensive HMI devices, you can achieve a totally different User Experience (UX) through software alone, without touching the difficult-to-change hardware core.
With experience, design teams learn to anticipate where changes are most likely. While specifics vary by domains, a general observation holds: Most customer-induced changes often relate to how the end-users would interact with the product, the” User Interface” (UI), or “Man Machine Interface” (MMI), “Human Machine Interface” (HMI). As technology advances, “Machine Human Interface” (MHI), for “Autonomous Machines” become increasingly relevant. How will the autonomous car decide to hand over controls to the human driver, waking them up or notifying the passengers when they arrive? Separating “HMI” from the “Machine Core,” is a frequent practice, especially with non-dedicated software-intensive HMI devices The same HMI device can be used in different domains, with “User Experience” (UX) changes achieved through software.
3. Manage and Control Required Changes
Product designs evolve during the design phase due to technical hurdles or evolving requirements. Later, during manufacturing, changes may be required due to component obsolescence or field feedback.
To prevent this evolution from turning into chaos:
● Document the “Know-Why”: It is vital to track the rationale behind every change. Understanding why a change was required is as important as the change itself.
● Authorization and Impact: Follow established organizational protocols to ensure every change is authorized and its impact on cost and schedule is communicated to stakeholders.
● Transparency: Always alert customers about areas that are difficult to change without incurring major costs or schedule impacts.
Case Study: The Presidential Acceptance Test
I once led a team developing professional audio systems for large-scale installations like stadiums and airports. We adopted a modular approach to reduce lead times.
These modules were used for the first time, for sound re-enforcement system at the venue of a major international sports event.
Just three days before a prestigious inauguration ceremony at the hands of the President, the organizing committee had a sudden realization: the forest of microphones from various broadcast agencies looked unsightly. They demanded we provide individual feed to all agencies through our system.
The Solution: Because we had modularized the system and anticipated last-minute changes by providing extra output channels during the build, we were ready. The “impossible” request was solved with simple cable re-routing and an update to the site records.
Summary and Key Take Aways
- Embracing uncertainty is not a hindrance; it is a strategic opportunity for innovation.
- Combat Uncertainty with Flexibility: Recognize that “frozen specs” are a myth.
- Modularize the Architecture: Freeze interfaces early, but keep modules adaptable.
- Anticipate the UI: Build your HMI to be independent of the core.
- Control the Evolution: Vigilantly track and document the “Know-Why” behind every required change.
I’d love to hear your thoughts:
In your domain and your projects, what strategies do you adapt to avoid projects being derailed by shifting requirements?
Share your comments, questions, or “last-minute” war stories in the comments below!