Sometimes, a company’s operational needs are compiled into requirement specifications, which play an established role in preparing for a project (see, for example, logistics industry guidelines, note: it is in Finnish). These requirements may be mapped out through a series of workshops or meetings where the future processes are conceptualized—either independently or with the help of a facilitating consultant.
The requirements specification document often contains valuable and relevant material, but in my experience, it is rarely perfect. Below are key issues related to this topic, based on three decades of working in the field.
Limited Scope of Requirements
Usually, not everyone is invited to the meetings—only selected key personnel. It might be just part of a department or only the head office team if departments are spread across multiple locations. As a result, only this group’s knowledge makes it into the requirements, while other organizational insights are left out.
If everyone is invited, the result may not be much better. Some people experience performance anxiety and won’t speak up in larger groups, while others dominate discussions—sometimes aggressively so. As a result, the ideas of skilled but quieter individuals may get overlooked.
Needs or Wishes?
The list of “requirements” often includes all kinds of nice-to-have features—some found in current tools, others inspired by competitor demos, or just random ideas that pop into people’s heads. While nice, these features may not be particularly critical for business operations. By “critical for the business,” I mean features that increase sales, improve customer service, boost efficiency by reducing manual work, or otherwise deliver tangible benefits—something that positively impacts the bottom line.
One of the most important success factors is keeping the pilot project focused by limiting its scope. These kinds of ideas are often best saved for later development phases .
Example: If a price difference between a product’s purchase price and its invoice can be handled in two equally valid ways—Option A or Option B—neither may bring special business value. However, if finance staff are used to Option A and define it as a “requirement,” Option B (which would work just as well) might be dismissed for no real reason.
Contradictory Requirements
Some needs may directly conflict with one another. For example, a function might be expected to be both automated and flexible. This might be possible in rare cases but usually isn’t.
Example: A production team might want received materials to be immediately visible to production for critical batch processing to begin. At the same time, the quality team might demand that all incoming materials go through inspection before use. Both might write their needs in ambiguous terms (e.g., “real-time inventory tracking” and “quality control upon receipt”) so the contradiction isn't obvious at first glance. Only upon further analysis does the conflict become clear.
Missing “obvious” requirements
Some operational practices are so obvious within a company that no one thinks to write them down. Suppliers may also consider these things obvious—but their understanding of what's “obvious” can be completely different.
While it’s frustrating to list such basics in a requirement document, the intended operational logic must somehow be communicated to the supplier—perhaps not through specifications but through a demo of current processes to make the “obvious” visible. This is a sensible approach, but it also means the requirement list will be incomplete by definition.
Complex Indirect Requirements
When operational models are developed—i.e., changed—as part of a system project, the impact ripples in many directions. No one can foresee all the indirect consequences in advance. As a result, many of these needs never make it onto the requirement list.
Classic example: Master data, like the material register. Modern ERP systems often support multiple methods for each product: purchasing, in-house production, inter-unit transfers, etc. The selected method is usually stored in the material's data per business unit. The more complex the system, the more indicators and control fields are needed—SAP material master has over 100 fields (per business unit).
Managing such a system can become complex, especially if the old system only had a few options. Or it was managed by just one person. The new system might require many people across departments and units to manage data in a coordinated and accurate way, taking into account field dependencies. Yet this maintenance topic is hardly ever included in the original requirements list.
One of the most common reasons SAP projects fail is the inability to set up master data correctly. Conflicting control data can disrupt the supply chain entirely—an outcome as inevitable as the first snowfall surprising drivers each winter. These requirements often emerge indirectly and unexpectedly.
Indirect requirements are also highly product-dependent and can only be anticipated at a very high level early on.
The curse of history
Legacy systems sometimes contain hidden features or logic that no one understands anymore. The system might “mysteriously” make the right decisions in certain situations—logic no one remembers to specify for the new system.
Worse yet, these features may be completely invisible—implemented in the backend, not on any screen or register. The original developers may have left the company or been laid off. What’s left is a black box that works—but no one knows how. Even the most diligent consultant isn’t going to start digging through the source code of the old system to uncover this logic.
The result
The end result is a requirement list that includes unnecessary, conflicting, and biased needs—yet still misses key elements. It’s often said half-jokingly that the best system for meeting the requirements is the current one (assuming we forget why it’s being replaced).
"No system is ever as perfect as it is the day before it’s replaced."
“Plans are worthless, but planning is everything”
This seemingly contradictory statement is attributed to Eisenhower and encapsulates the point well.
If I compare a project's initial requirement list with post-project analyses on what turned out to be critical to success, they rarely match. Roughly speaking, half the listed requirements were unnecessary, and half of the critical ones were missing.
The real project risks are the things that weren’t seen upfront but became critical during execution. As the saying goes: “The devil is in the details.” These are the reasons why projects—and their budgets and timelines—tend to grow during implementation.
According to Gartner over half of ERP projects fail to achieve their goals. While there are many reasons for this (which I’ll cover in future blog posts), requirement specifications are undeniably one of the most challenging aspects.
So yes, requirement specifications are a good starting point. Thoughtful planning helps. But the original plan never gets you across the finish line—likely a lesson also familiar on the battlefield.
