Hide this madness

BA Basics Series Part 1 – Meeting Best Practices

This post is part one in a series of articles designed to assist readers who have recently started working in a Business Analyst role. The articles will help readers to learn a few of the basic tricks of the trade that will hopefully make their experiences as a BA more productive and rewarding.

One of the true “bread and butter” activities of all business analysts is facilitating meetings. It’s where BAs discover system requirements, resolve issues, review work products and generally interact with project stakeholders and development teams.

For people new to BA work, facilitating requirements meetings or workshops can be one of the more daunting aspects of the job, especially with a large group of participants. As with all challenging activities, practice will improve your skills immensely. However, there are a number of best practices you can employ to make your meetings go better, many of which have nothing to do with how you handle the actual discussions.

The amount of preparation required for a meeting will of course depend on the nature of the discussion. A half hour clarification of a requirement requires very little advance work compared to a half-day requirements workshop with 15 stakeholders. However, all meetings have a few basic preparation and execution best practices that will go a long way to helping you achieve a better result in your stakeholder interactions:

Before The Meeting:

1. Set Aside Adequate Time for the Discussion(s)

Make sure you give your participants enough time to cover the targeted subject matter, and avoid scheduling meetings at the last moment. Always try to be considerate of your stakeholders’ time. For example, choose a set of smaller meetings over a longer workshop if your participants’ time is extremely limited. They will thank you for it, and will likely be less distracted and more helpful during the sessions.

2. Clearly State the Purpose and Goals of the Meeting on the Invite.

Avoid vague descriptions like “Brainstorm System Requirements”. Focus the meeting purpose to be the desired outcomes of the session. For example: “Identify User Groups, Working Environments and User Personas for the Realtor Management System”

Avoid vague descriptions like “Brainstorm System Requirements”. Focus the meeting purpose to be the desired outcomes of the session.

3. Include an Agenda and any Related Meeting Notes or Materials with Your Meeting Notice

Take 5 minutes to write an agenda. Just do it ;)
If the meeting is a followup, or part of a related series, then include notes from the previous sessions for reference.

4. Prepare Some Basic Questions and Circulate Them in Advance

Unless your meeting specifically requires participants to be unprepared (like a usability test for example), its always a good idea to include a set of basic questions that cover the subject of the discussion. It does not mean you need to provide every question you were thinking of asking, just enough to get the participants in the right frame of mind for the discussion. 5-10 questions seems to work fine; usually high level open-ended questions are best. For example,

  • Who are the primary users of the system?
  • Please describe their working environment?
  • What are the primary activities each user will perform on the system?

Unless your meeting specifically requires participants to be unprepared (like a usability test for example), its always a good idea to include a set of basic questions that cover the subject of the discussion.

5. Make Sure the Meeting Venue has the Required Tools

If you are unfamiliar with the meeting venue, then try to learn more about it in advance of the session. Make sure the location has what you need such as whiteboards, flip charts and projectors. If the venue is located in another city, then ask someone who works there to check for you.

6. Invite the Key Stakeholders / Decision Makers

This is one of the trickiest areas of preparation, and your control of this aspect is often restricted. If a project is well under way, you will typically know who your key stakeholders are and will be able to make this decision yourself. However, It can become problematic with brand new projects, especially with a new client. It is not uncommon to be asked to run a first requirements meeting with all of the project’s business groups stakeholders assembled in a single room for a day long session. If this occurs, then encourage your new client to send only the key, empowered representatives for each business group as opposed to entire teams. As everyone knows, the productivity of a meeting will generally deteriorate as the number of participants increases.

During The Meeting

1. Relaxed Chit Chat Before the Meeting Starts is a Good Thing :-)

I like to encourage some relaxed banter and joking around before a meeting begins. It relaxes the participants and helps them to switch gears from their last activity. If some of the participants do not know each other, then make sure everyone is introduced.

2. Review the Purpose and Agenda of the Meeting

Just take a couple of minutes to recap the purpose and agenda of the meeting so everyone is on the same page. For large meetings/workshops, its also a good idea to do formal introductions and set some ground rules such as no e-mail during the meeting and a “parking lot” for problem areas.

3. Designate Several Scribes and Avoid Recording Devices

Depending on the type of meeting, you may not be able to take notes. If you are facilitating a large group, then typically the only notes you will have will be the stuff you write down on whiteboards or flip charts. Make sure you have at least one person in the meeting who is the scribe. For large important meetings I prefer there to be two scribes in order to capture more than one person’s perspective on discussions.

Personally, I am not a fan of using recording devices for meetings. I believe it reduces the inherent trust needed for requirements discussions. It’s important that stakeholders be able to say how they really feel about areas of discussion such as problems with current systems or business processes. If they know they are being recorded, they tend to clam up for fear of being “quoted” to more senior managers. If you feel you really must use one, then make sure you get permission up front. Recording people without their knowing it will make your new career as a BA a very short one ;-)

It’s important that stakeholders be able to say how they really feel about areas of discussion such as problems with current systems or business processes. If they know they are being recorded, they tend to clam up for fear of being “quoted” to more senior managers.

4. NEVER Presuppose Any Outcomes

This is a common mistake made by many analysts simply trying to streamline or speed up a meeting. They may, for whatever reason, postulate some outcomes in the meeting materials, saying something like “It seems based on our e-mails that these are the key areas we need to implement”. Even if the intentions were honourable, this approach is a mistake because participants immediately feel that decisions are being made without their input, and its a sure way to make them decide not to participate in the rest of the meeting.

5. Record and Display Shared Discussions / Decisions

Given point 4 above, decisions or discoveries should ideally be made during meetings, not before them, and those ideas should be recorded as the meeting proceeds and be displayed for everyone to view during discussions. Use white boards or flip chart pages that can be stuck to the walls in a meeting room. Be sure to have copies of all white board diagrams when you leave the meeting – I often use a phone camera for this if the organization permits it. Your scribe(s) should also try to capture diagrams in their notes, since phones do get lost or broken.

6. Be Adaptable to the Evolving Shape of the Meeting

One of the most enjoyable things about requirements meetings is their lack of predictability. As a general rule, the broader the scope of a meeting’s subject matter, the less predictable the direction of discussion will be. For this kind of material, adaptability and flexibility are a must. A carefully prepared set of questions can be rendered useless in the first 5 minutes of discussion, forcing you to think on your feet while steering the discussion down this unexpected path.

If it’s clear the planned meeting agenda/questions are no longer valid, raise this with the group and decide on the best next steps for continuing the meeting. Never stubbornly go through an agenda and a list of prepared questions if they have become irrelevant.

7. “Park” Problem Items

It is very common for a group to get caught up in a detailed discussion on a very complex problem or a point of view that the participants feel strongly about but cannot agree upon. It’s good to let these discussions occur for a while, as they stimulate thought and may come to resolution during the meeting. However, if a particular topic appears unresolvable, or could possibly eat up most of the meeting time at the expensive of more important areas of discussion, then its a good idea to “park” these items for a follow-up meeting.

8. Managing Rants and Stories

Another common scenario in meetings is the ranter or story teller that wastes a lot of meeting time on unrelated subject matter. Once again this is an area that requires you to make a personal judgement call.

I recall a meeting on a very complex subject matter with the one and only person in a client’s organization that understood the topic. Just as the meeting was getting started, this person began ranting about some earlier meeting in the day, clearly upset about something that had occurred. She began relating the story to everyone at the meeting, and clearly it was going to take her 5-10 minutes to get through it all. I had the option of steering her off the topic, but my instinct said not to. So I let her tell the story and all the other meeting participants empathized with her when she was done. Clearly, she felt much better after getting this out of her system, and then she was happy to focus on the meeting, which turned out to be very productive. She even apologized for the rant at the end of the discussion.

So its really a judgement call; all I can say is sometimes these diversions are worth it because they settle the meeting participants and also help to establish some personal relationships within the group. This is especially valuable if the person is critical to the success of the project.

Sometimes [...] diversions are worth it because they settle the meeting participants and also help to establish some personal relationships within the group.

9. Recap Key Points and Takeaways

Always try to end the meeting by recapping the major discussion points / decisions and takeaways. It frames the discussion and the follow up tasks for the participants, and reinforces that the meeting has been productive and useful.

After The Meeting:

1. Assemble and Circulate the Consolidated Meeting Notes

Consolidate the meeting notes if there was more than one person taking notes. Thank the participants for their involvement in an e-mail and include the meeting notes, decisions, follow up tasks and next steps.

2. Store Meeting Notes in the Project Portal or Versioning System

This is important for requirements traceability and project knowledge transparency. Its also a nice backup against a lost or broken computing device.

By incorporating some or all of these guidelines into your meeting strategies, I am confident you will have more enjoyable, productive meetings which ultimately means your team will build more useful and effective software.

Add a comment

Comment feed
The better to greet you with
No one will ever see this
Your pride and joy
The reason this comment form exists

The crew behind ASOT

We're a team of interactive, software, and business intelligence experts skilled in the design, construction, and management of online enterprise systems.

Visit The Jonah Group site

Get in touch with us