A leadership team decides it’s time to modernize.
They kick off a requirements-gathering process.
Stakeholders are interviewed. Documentation is produced.
A requirements document lands on the table, forty pages long.
Everyone feels like real work has been done.
Most of the time, it hasn’t. What’s sitting in that document is not a set of business requirements. It’s a detailed description of how the organization works today. And those are fundamentally different things.
This confusion is one of the most common and most expensive mistakes I see in transformation work. It doesn’t announce itself. It shows up quietly, in the form of implementations that technically deliver what was asked for and still fail to move the organization forward.
What processes actually are.
A business process is a description of how work gets done today. It captures the steps, the sequence, the handoffs, the tools, and the people involved. Process documentation is valuable. It creates shared understanding, surfaces inefficiency, and gives you a baseline to measure change against.
But a process is descriptive, not prescriptive. It tells you what is. It does not tell you what needs to be true for the organization to achieve its strategic goals.
When a leadership team asks "what are our requirements" and the answer comes back as a process map, something has already gone wrong. The question has been answered at the wrong level. The organization has described its current state when what it actually needs is clarity about its desired future state.
What requirements actually are.
A business requirement is a statement of what the organization needs to be able to do, achieve, or support in order to execute its strategy. It is outcome-oriented, not activity-oriented.
Here is a simple way to see the difference.
A process statement sounds like: "The finance team currently reconciles accounts at month-end using a combination of the ERP export and a manual Excel tracker, with final sign-off from the controller within five business days."
A requirement statement sounds like: "The organization needs to close its books within two business days of month-end with a single source of financial truth that does not require manual reconciliation."
The first describes today. The second defines the standard the future state must meet.
The difference seems subtle until you sit in a vendor selection meeting and realize that every feature being evaluated is being mapped against the current process rather than the future requirement. That is when a forty-page requirements document becomes a very expensive anchor.
When leadership couldn’t answer the simplest question.
I was brought into an engagement where an organization had already spent several months in discovery for a major platform implementation. They had process maps. They had stakeholder interviews. They had a requirements document that their project team was genuinely proud of.
Early in my assessment, I asked the executive sponsor a straightforward question: what does success look like 18 months after go-live? Not in terms of the system being live, but in terms of what the organization can do that it cannot do today.
There was a long pause.
The answer that came back was a list of features the new platform would have. Not outcomes. Not capabilities. Features.
When I pushed further and asked what strategic goal this implementation was in service of, the conversation stalled. Different members of the leadership team had different answers. Some were focused on efficiency. Some were focused on reporting. One was primarily concerned with audit readiness. Nobody had reconciled those into a shared definition of what the organization actually needed.
What they had documented thoroughly was how the organization currently operated. What they had never asked was whether that operating model was the right foundation to build on.
The implementation moved forward. It delivered the features on the list. Eighteen months later, the efficiency gains were modest, the reporting was marginally better, and the leadership team was already discussing what the next system upgrade would need to address.
The process documentation had been excellent. The requirements work had never actually happened.
Why leadership is the root cause, not the symptom.
It is easy to point at the project team, the business analyst, or the implementation partner when this goes wrong. And sometimes those parties do share responsibility.
But in most cases, the confusion between processes and requirements starts at the top. Leadership initiates the work, approves the scope, and then steps back and assumes the discovery process will surface what the organization needs. It often does not.
discovery process will surface what the organization needs. It often does not.
Discovery surfaces what the organization does. Translating that into what the organization needs requires a strategic conversation that only leadership can have. It requires being able to answer questions that are uncomfortable to sit with:
What is this organization trying to become in the next three to five years?
What does our operating model need to look like to support that?
Where are the gaps between where we operate today and where we need to operate tomorrow?
What would a future-state process need to do that our current one does not?
If leadership cannot answer those questions before discovery begins, the discovery process will default to documenting the present. That is not a failure of the project team. It is a failure of strategic clarity, and it sits squarely with the people accountable for strategy.
The sequence that changes the outcome.
Getting this right does not require a longer or more expensive process. It requires doing things in the right order.
Start with strategy. Before any discovery work begins, the leadership team needs to align on what the organization is trying to achieve and what operational capabilities it needs to get there. This is not just a workshop activity. It is a leadership accountability exercise.
Then define future-state requirements. What must be true about how the organization operates to support that strategy? These are your requirements. They are forward-looking, outcome-based, and owned by leadership.
Then document current-state processes. With requirements in hand, process documentation becomes genuinely useful. You are not just mapping what you do. You are comparing what you do against what you need to do, and identifying the specific gaps that the transformation must close.
That sequence matters. When organizations invert it, which most do, they end up optimizing for the current state rather than designing for the future one. The implementation succeeds on its own terms and falls short of its strategic purpose.
Clarity is not a deliverable. It is a precondition.
Every transformation program I have seen struggle with adoption, scope creep, or disappointing ROI has shared a common starting point. The organization moved into execution before it had genuine alignment on what it was trying to achieve.
Process documentation creates the illusion of that alignment. Forty pages of current-state mapping feels like progress. It is organized, detailed, and thorough. But it is answering the wrong question.
The right question is not how do we work. It is what do we need to be able to do. And that question belongs to leadership, not to the project team, and not to the implementation partner.
Get that answer first. Everything else becomes significantly easier when you do.