It’s always interesting comparing how other PMs manage projects.
Let’s now see how we collected stakeholder expectations on a real project.
It’s a software development project. It’s a large project for the fast-paced project life cycles we have.
It was interesting to see that our clients were large enterprises. It has been involved in software development for many decades.
But that’s exactly how they do it.
Get My Scope Management Plan Template
Access the Scope Management Plan Template that I use in my projects.
It can be used for work by being adapted to your needs. It can also help you learn Scope Management.
Get the Template
Phase 1: Waiting for stakeholders
There are many layers of stakeholders who can provide requirements.
It begins with the department’s high-level visions and goals.
However, the business unit is still the primary source for product requirements. These are the champions for a product. They determine the direction of the product.
(Note: We are not referring to end-users who use this product on a daily or weekly basis.
We had to wait three weeks before we could communicate with the business unit.
They are very organized. They have priorities.
We had five meetings in the end spread over four days.
During this period, we had the task of obtaining and clarifying all stakeholder requirements.
What did my project team do during that period?
It’s a huge project. There’s always something important in the Backlog. We have already clarified the matter but put it off until a later time.
Phase 2: 4-hour Meetings
I have worked with clients from many countries.
They all have different preferences.
These clients enjoyed solving problems online.
Sorry for not getting the details. You will understand that I am unable to share the details due to NDA. For project managers, this is always the case. Be ethical and professional.
My team and I find sitting in an online meeting for 4 hours a bit excessive. It’s just the way they do business.
A large number of participants were also present:
There are several business analysts, technical experts, and managers.
People from the business speak. They don’t give any “requirements” nor “specifications”. They simply describe what you need. It’s a bonus that they stick to a User Story style of speaking.
All of us are thus capturing the life-style requirements.
You might be asking, “Why don’t you record such sessions?” Security reasons. They are also time-consuming to review later.
It’s much more efficient to do it right away.
Slide decks were used to create the first part of the requirements. It was wireframes. They shared a vision for the user interface.
Second, we gathered a lot of requirements in the form:
“As an administrator, click here to see a chart …”
“If I click on the chart, I want to view more details… but we don’t know in what format. You will need to make recommendations. ”
“This screen should contain all information about the entity. To drill down into more details, we can click on any chart.
Most cases, it is not possible to use business requirements as-is.
We now have the next phase.
Stakeholders may not be aware of the risks associated with unclear requirements. Phase 3: Requirements Specification
We met for half a day to listen and gather high-level information.
We have half an hour to describe what we heard.
We must identify conflicting or unclear requirements. We must provide a list with questions and discussion points for tomorrow’s meeting.
We must also verify the technical feasibility. At a minimum, at a high-level. We must identify the limitations of existing solutions.
During this phase, many subject matter specialists brainstorm all that. There are many external experts who can help.
Business analysts try to understand and structure requirements.
Technical experts quickly proof concepts.