Your Software PM Mentor

Software Project Management Insights

  • Start Here
  • Get The Book
  • Get The Course
You are here: Home / Project Management Blog / Scope Management / How to Collect Stakeholder Requirements (Real-life Example)

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.

Get My Scope Management Plan Template

Get access to the Scope Management Plan Template I use on my projects.

You can use it for work by adapting it to your needs. Or it can help you learn Scope Management.

Get the Template

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 on 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 the 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:

"In most cases, you can't use requirements from business as is" Nizhebetskiy Dmitriy
Moreover, stakeholders may not understand the risks of unclear requirements

Phase 3: Requirements Specification

We had 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 many hours.

What happens after?

Well, the business unit goes on with its 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 the 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.

Get My Scope Management Plan Template

Get access to the Scope Management Plan Template I use on my projects.

You can use it for work by adapting it to your needs. Or it can help you learn Scope Management.

Get the Template

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.

I also recommend reading:

  • Featured Article: How to Become an IT Project Manager Without Experience
  • Next in the series: Ultimate Guide on How to Create a Robust Work Breakdown Structure
  • Previous in the series: How to Collect Stakeholder Requirements (Real-life Example)
In this article, you will see an example of how to collect stakeholder requirements. It comes from real-life project management experience. You will learn that the process of collecting and specifying requirements may be not that structure. Read the article to learn more!
Tweet
Share
Pin212
Share
212 Shares

Written by Dmitriy Nizhebetskiy
Categorized: Scope Management

For New and Experienced Project Managers:

Online Course to Help You Boost Your Project Manager’s Career

Project Management | Leadership | Career Development

Get The Course

About Dmitriy Nizhebetskiy

My goal is to help you become a capable Project Manager and Leader with skills and knowledge that work in the real world.
With 10+ years of experience as an IT Project Manager, I'm still an active Agile PM. That's why all articles, videos, and career development tips come from the front line, not some academic books. Learn More Here.

Comments

  1. Gabriel Morales says

    December 9, 2018 at 4:38 AM

    Meeting stakeholders’ exigences is, on the long run, worth all the time and effort devoted to it once you get the thing. This is the only way to make sure that your team’s work will hit the goal.

    However there is nothing more annoying that getting blurry and out of time “feedback” from an important chairperson you were really trying to involve in the process, by all the possible ways.

    Reply
    • Dmitriy Nizhebetskiy says

      December 11, 2018 at 12:32 PM

      Yes, so true. Both points are valid and a PM will face them for sure.
      That’s why it is so important to build relationship and engagement with your stakeholders.

      Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

  • LinkedIn
  • Youtube
  • All Articles
  • Course Area

© 2015–2022 Project Management Basics AÜ | Terms of Service | Privacy Policy | Refund Policy | Contacts