Below are a few simple guidelines for facilitating stakeholder participation in requirements. As with any guidelines, these should be tempered according to the business analysis practitioner, the stakeholders, the effort at hand, and the general environment.
1. Select relevant topics, according to
attendees. If you want to get
(and keep) your stakeholders engaged, avoid inviting them to meetings where
only a small percentage of the content is relevant for them. Rather than having an all-day meeting (for
example) where each stakeholder has 2 of 6 topics pertinent to his role, divide
the meeting topics across multiple shorter meetings. Maybe hold 3 separate meetings - each having
2 relevant topics for its participants.
2. Establish meeting guidelines and protocol early on. In addition to promoting a safe environment in which everyone can fulfill their respective roles, having guidelines also helps to keep the meeting on topic. For example, you may tell stakeholders they should not hesitate to ask clarifying questions during the meeting. You may further advise them that questions which cannot be answered right away (or that take the meeting off topic for more than 2 minutes) will be placed on a list for follow up outside of the meeting. If you discuss this approach up front, participants can feel free to ask questions. At the same time they fully expect the business analysis practitioner to rein the discussion back in, if a question takes the group too far off topic.
3. Inform participants of their expected roles. Clearly explain to your stakeholders what it is you expect them to do, in terms of requirements (and specifically with regard to requirements meetings). Reiterate the expected roles at each session, as needed. For example, you may have certain stakeholders who are the subject matter experts responsible to help define an automated process, whereas other stakeholders (perhaps those who manage the areas involved with the process) are expected to review and approve. Establishing, clearly communicating, and reiterating these roles sets the stage to have the process (and supporting requirements) defined by those who have the knowledge and right perspective to do so. It also facilitates approval by those who have the responsibility and proper authority.
4. Display your meeting accomplishments. When meeting with a group of stakeholders it is helpful to display (during the meeting) what is discussed and especially what is decided. Regardless of the specific technique used to later specify requirements (user stories, use cases, process models, statements, etc.), displaying key discussion and decision points during the meeting
2. Establish meeting guidelines and protocol early on. In addition to promoting a safe environment in which everyone can fulfill their respective roles, having guidelines also helps to keep the meeting on topic. For example, you may tell stakeholders they should not hesitate to ask clarifying questions during the meeting. You may further advise them that questions which cannot be answered right away (or that take the meeting off topic for more than 2 minutes) will be placed on a list for follow up outside of the meeting. If you discuss this approach up front, participants can feel free to ask questions. At the same time they fully expect the business analysis practitioner to rein the discussion back in, if a question takes the group too far off topic.
3. Inform participants of their expected roles. Clearly explain to your stakeholders what it is you expect them to do, in terms of requirements (and specifically with regard to requirements meetings). Reiterate the expected roles at each session, as needed. For example, you may have certain stakeholders who are the subject matter experts responsible to help define an automated process, whereas other stakeholders (perhaps those who manage the areas involved with the process) are expected to review and approve. Establishing, clearly communicating, and reiterating these roles sets the stage to have the process (and supporting requirements) defined by those who have the knowledge and right perspective to do so. It also facilitates approval by those who have the responsibility and proper authority.
4. Display your meeting accomplishments. When meeting with a group of stakeholders it is helpful to display (during the meeting) what is discussed and especially what is decided. Regardless of the specific technique used to later specify requirements (user stories, use cases, process models, statements, etc.), displaying key discussion and decision points during the meeting
·
Equips stakeholders to
give feedback by agreeing with (or correcting) what is posted
·
Helps to keep the
meeting on topic
·
Provides participants
with a sense of accomplishment
5. Honor stakeholders’ time. Besides participating in the project at hand
(and specifically requirements meetings), most stakeholders have a normal job
to continue. Showing respect for a
stakeholder’s time increases the chances of that stakeholder actively
participating in your meeting next time around.
Here are some ways to respect stakeholder time
·
Schedule enough time
to accomplish your agenda
Note: You
don't want to send stakeholders away feeling like they failed at accomplishing
the meeting objective. So, be careful
about over packing your agenda. Who wants to be a part of something that makes
them feel like they failed at accomplishing the goal?
·
Share the agenda in
advance
·
Start on time
·
End on time (a little earlier
if possible)
6. When longer meetings are necessary,
provide scheduled breaks and refreshments. As much as you may try to avoid longer
meetings, you may have to go that route occasionally. When longer meetings are necessary, it is
important to remember that we all have biological needs. Not accounting for those needs can result in
uncomfortable stakeholders who are even more eager to get out of a meeting than
usual. This is an easily removable obstacle that can be addressed by simply
planning ahead for scheduled breaks and providing refreshments.
These are just a few things to keep in mind as you try to
engage stakeholders in your requirements sessions. Applying these guidelines probably will not result
in a stampede of stakeholders trying to force their way into your meetings. However, it does address some of the common
pitfalls that cause stakeholders to disengage during the meeting (or not show
up at all).
Do you want to learn more about those soft skills and human skills
that will assist you with engaging your stakeholders? If you are interested, you don’t want to miss
the 2013 Project World & World Congress for Business Analysts. Join me there to gain (or enhance) related
skills that will benefit you, your organization, and your stakeholders. Register today at http://bit.ly/13jM72A. I hope to see you in Orlando!
Belinda Henderson,
CBAP, PSM
No comments:
Post a Comment