Analyzing Complex Requirements and Difficult Discussions with Stakeholders

In business analysis, technical solutions may be required, whether for digital transformation projects or simply process improvements required by leadership.

In many scenarios, you will not be creating something new, but rather making adjustments and changes that are aligned with the strategic solution. However, it is not always in the interest of stakeholders who have been working in a certain way for years to change the way they work and have to learn something new.

There is a saying in Brazil that goes:

You don’t change a winning team

Unfortunately, this does not apply here, as changes in tactics are constant and being prepared for them is no longer a competitive advantage; it is homework for the entire company.

With that, here are some possible approaches to dealing with these situations:

Stakeholders with years of experience in the company who refuse to change

Human beings will always have a tendency to seek comfort and security, and knowing this is the first step. In other words, it will not be easy, no matter how open to change they may be.

So, in your first requirements gathering meetings, be clear about your objective and avoid beating around the bush. No one likes the feeling of being misled.

Be a good listener. Sometimes they may complain and whine about why this exists. These are the escape mechanisms that people may use in these situations. If it makes sense, take notes on their complaints. This indicates that you care and can bring good insights to the next session.

Be consistent. If the issue is not clear in the first conversation, create a cadence but avoid long meetings. Your commitment will have rewards and build trust with your audience.

Dealing with complex requirements

In addition to the difficulties of engaging stakeholders, there are technical requirements that are essentially complex. One mistake I have made a few times is to write user stories and start development work without design or prototyping. Often, in the eagerness to deliver, autopilot can take away the clarity of what really needs to be done.

Here are some points to consider:

Understand as much as possible about the requirements before any development work, but respect the agreed deadlines. Clarification with users may be necessary, and this is normal. Align expectations of what will be delivered. Not everyone likes surprises. There is no argument against data! Knowing the data generated and used by the process is fundamental to measuring the impact of the requirement, as well as its relevance. With the proper knowledge about the requirement, it is time to prepare the user stories and order them by priority, together with the Product Owner or project sponsor (if any), as well as align the product strategy. Ensure that the development team works in accordance with the stories prioritized by the Product Owner for the current sprint, nothing more! Present the deliverables of the current sprint to the stakeholders to validate the requirement, but make sure that their validation is in line with the Product Owner’s vision. This is a simplified version of what we can do in the face of complex requirements and discussions with stakeholders. There are countless scenarios and several other actions that can be taken, but based on my experience, this is a good starting point.