How to Collect Stakeholder Requirements (Real-life Example)

It’s always interesting to compare how other PMs manage projects, isn’t it?

So, let’s see how we collected stakeholder requirements on a real project.

It’s a software project. Rather big for a fast-paced project life cycles that we have.

Interesting to notice that our clients were from a large enterprise organization. It did software development for many years already.

Yet, that’s how they do it.

Phase 1: Waiting for Stakeholders

There are many layers of stakeholders that provide requirements.

It starts with high-level goals and visions of a department.

Even so, the primary source of product requirements is a business unit. These are the champions of a product. They decide where the product’s heading.

(Note that we are not talking about end-users who use the product on a daily basis)

We had to wait for three weeks for an opportunity to communicate with that business unit.

They have tight schedules. They have priorities.

In the end, we had around five meetings spread within four working days.

During this period, we had to collect and clarify all the stakeholder requirements.

What did my project team do during this period?

It’s a big project. There is always something important in the Backlog to choose from. Something we already clarified but postponed for a later date.

Phase 2: 4-hours Meetings

I worked with different clients from different countries.

All of them have different preferences.

These clients liked to solve problems in online meetings.

By the way, sorry for missing out the details. As you understand, I cannot share them due to NDA. As for a project manager, that’s always the case. Be mindful of ethical and professional behavior.

For my team and me, sitting on a 4-hour online meeting is a bit too much. For them – it’s the way of doing business.

Moreover, there was quite a list of participants:

Several business analysts, several technical experts, some managers.

Why?

Well, people from the business just speak. They don’t give you “requirements” or “specifications.” They describe the need. It’s a bonus if they at least stick to a User Story type of speaking.

Thus, all of us are capturing the requirements in life mode.

If you wonder, why don’t we record such sessions? First of all, security reasons. Second, no one has time to review them later.

So, it’s more efficient to do it on the spot.

The first part of requirements came from a slide deck. It’s was some wireframes. They explained a vision of the user interface.

Second, we collected a bunch of requirements in the form of:

“As an administrator, if I click here I will see a chart…”

“If I click on the chart I want to see more details… well, we are not sure in what format. You will need to come up with recommendations. “

“On this screen, we should see all the information about this entity. We can click on any chart to drill down further into details.”

In most cases, you can’t use requirements from business as is.

Therefore, we have the next phase:

Phase 3: Requirements Specification

We had a half a day meeting to listen and collect high-level information.

Now, we have half a day to specify what we heard.

We need to identify unclear or conflicting requirements. We need to provide a list of questions and discussion points for tomorrow’s meetings.

Also, we need to check the technical feasibility. At least at a high level. We need to identify the limitations of existing solutions.

So, during this phase, many subject matter experts brainstorm all that. We have a lot of external ones who provide support.

• Business Analysts try to break down and structure requirements.
• Technical experts do quick proofs of concepts.
• Designers try to visualize the elements on a conceptual level.

Keep in mind, that we only have four days and that much hours.

What happens after?

Well, the business unit goes on with their priorities. They think they provided all the necessary details. We can work them out.

So, here is the catch:

We are interested in using their availability more then they do.

Why?

Once you start digging, you will find out a lot of inconsistencies.

Phase 4: Questions and Answers

“Could you please clarify this area a bit more.” – It’s not the biggest problem here.

It’s much worse to hear something like, “We didn’t think about it. We don’t know.”

Sometimes it may mean we need to revisit the fundamental concepts behind the business need. Sometimes it says we need another four hours to discuss it.

The vision in stakeholder’s head is usually different from what we understand.

That is why it is important to reframe the business needs in terms of real product or service. You need to visualize requirements as much as possible.

Not for you but for them.

This time we even had to have two Q&A sessions in parallel. This way, we were able to focus on different aspects of requirements in more details.

Does the work on collecting stakeholder requirements finish here?

No, not even close!

After these several days of intense work, we developed our own champion for the business need.

Our business analysts and designers can specify requirements further without the business unit.

So, we will get in touch with the business unit for sure. But only on some severe topics or problems.

Later in the process, the business will have to read through all the specifications and acceptance criteria. They need to verify that it’s what they want to get.

Phase 5: Developing Solutions

Another interesting fact about this case:

We analyzed all the requirements and available solutions. In the end, we concluded that it’s much more cost efficient to use a ready-made third-party solution.

Therefore, we had to hand-off this part of the project to another team. Including all the work we did on specifying the requirements.

Why?

Well, for the good of the client and his business. It paid off later.

Conclusion: Stakeholder Requirements

As you can see, processes in project management can have different forms. Quite often they can be messy and unstructured.

Always keep in mind that you work with real people. Some of them are busy and influential characters.

You need to adjust to their style of work. You simply don’t have authority over them. Still, you need to work with them for the benefit of a project.

Also, I recommend to read:

Project Stakeholder Management: Identification, Analysis, Register

---

Do you want to become a Project Manager? Or are you an Accidental PM and you want to become a professional? If YES – click the button below and sign up to my free training.