Gathering requirements for a complex ERP project with a grain of salt

The bigger the ERP project, the more we should use this approach when gathering requirements - to take a grain of salt.

By that I mean, as experienced Business Analysts, we should stay objective when hearing pain points and requirements from our business stakeholders. We should really understand the business processes and why the stakeholders do things the way they do. Because:

1. The current state and the requirements told by the stakeholders may be due to current limitations.
2. What they are not complaining about is not necessarily the gold standard process. They are just used to it.

‍

Typical challenges in a project with high complexity

In my recent project about ESG (Energy Sustainability Governance) data project, the current process involves 4 different teams of different functionalities of a big real estate management company. Here are the challanges that I faced while gathering requirements:

1. There was not one SME that knew the entire current state of all teams. Many sessions with the stakeholders were required to piece together the puzzle because people didn't know how much to share, which resulted in one team's process steps being discovered when talking with another team.
2. There is not an official owner of 2 process streams because each real estate property has developed their own way of working over decades. Everyone tries to optimize the process in different ways, which means complexity. Moreover, the processes have been being improved for the last 20 years, so a lot of context may have been lost - people inherit processes from predecessors without questioning.
3. Stakeholders were hesitant to speak on the standardized needs as they were aware their process may not be the same as other properties.
4. Stakeholders may give requirements to address someone else's process because they have pain points that are the byproducts of upstream processes.

For this level of complexity, it is easy to fall into the trap of designing a solution that only solves the surface-level issues, has unnecessary features, or does not optimize the new process.

‍

Business requirements gathering starts with current state

Whenever a stakeholder comes to you with solid requirements, BE SUSPICIOUS. Take a step back and ask yourself if that looks like solutioning. Of course, they know their process and pain points best. However, that solutioning is limited to their subjective understanding of the big picture and their technical knowledge.

I would always start with documenting the existing process of each team, and plot them on a swim-lane business process blueprint. All pain points and edge cases are also plotted on the blue print. If all stakeholders can agree on the current state mapping for their own swim lane, especially when their process is not standardized across their peers at other properties, we are off to a good start. Additionally, this also gives them the confidence that the project team understands the big picture and the nuances of each property.

The current state process steps and pain points are what fuel business requirements. Therefore, it's essential to get these elements accurately and objectively documented in the beginning.

‍

Crafting non-priming business requirements

The golden rule in ideation workshops for innovation is to not prime team members in a specific path, to allow for idea diversity. Priming can happen like this in a brainstorming session: A question is posed, and the first person says something - automatically everyone tries to expand around that idea, losing out on millions of other possibilities.

This also applies in creating the best solution for optimizing processes. The wording of the business requirements need to be high level enough to not restrict the thinking of the solution architects, or to not dictate the solution itself.

To craft good high-level requirements and enable team members to build the best solution, provide context. People can do what they are told, but will do their best when they understand the purpose. Everyone on the team, especially the solution architects should understand why stakeholders are doing things the current way, and what they are trying to achieve.

Key takeaways

1. Start with current state and pain points. Be cautious when stakeholders give you solid requirements.
2. Understanding the purpose and writing business requirements at a high enough level enables the best solution design.