“Whoa, there! Slow them horses down.” Managing Meetings Before They Start

Reigning-In the Meeting Madness by Robert Lewis (Illus. ©Susan Hellard)

Reigning-In the Meeting Madness

You’re in the heat of a requirements session. The stakeholders are all there, excited over the prospect of finally getting a solution to their problem. They’ve come prepared with every issue they currently face, and how they want to solve them.

The energy is electric. Everyone, from top executives down, starts tossing out ideas and suggestions in an adrenaline fed frenzy. You’re furiously taking notes, trying to keep up with the pace.

“Yeah. That’s good,” someone says. Then a new voice chimes in, “Oh … What if we … ?”

That’s when you need to pull on the reigns, and shout, “Whoa!”

When managing a meeting, the Business Analyst needs to be able to maintain control, and keep the participants focused on the purpose and goals of the meeting. Maintaining control, and effectively managing meetings, doesn’t take place solely within the context of the meeting, it begins before the meeting starts.

So, where should you begin to make your meeting more effective?

Start at the most obvious place … the agenda.

Meeting Management – Let’s Start at the Very Beginning

Whenever a number of people get together, the complex mingling of diverse personalities creates a unique group dynamic. Sometimes that dynamic works well, and other times … well … not so much.

Effective meeting management, leading to productive, focused, meetings, takes place when all the right participants come together, with the knowledge of what they need to accomplish, and why they need to accomplish it.

A quality agenda should be your first, and most important, step for effectively managing a meeting.

In a recent study conducted by ShoreTel, more than half the respondents felt that an agenda was necessary for an effective meeting, yet 85% of respondents weren’t creating a detailed agenda to clearly define the scope of the meeting.[2]

When you create your agenda, it’s important to think about the 3W’s of the meeting:

  • Who
  • What
  • Why

Who Should Attend the Meeting

Limit the number of participants of the meeting to prevent it from getting out of control.

You don’t need to invite every stakeholder that is a part of a project, just the defined, representative, stakeholders of groups that are integral to the purpose of the meeting. For that matter, you don’t even need to inform stakeholders that are not integral to the meeting about the meeting at all.

If, during the course of the meeting, a topic or issue comes up that requires input from a group not represented, put the topic aside and follow-up on it separately, or in a different meeting.

What is the Purpose of the Meeting

Before you schedule a meeting, you need to be clear about what you want to accomplish. If you don’t know what the purpose of the meeting is, the participants will be confused as well.

To make sure the participants fully understand the purpose of the meeting, and allow them to properly prepare for it, do the following:

Define an Understandable Goal

Set a goal for the meeting, and communicate the goal to all the participants before you meet. The goal sets the scope of the meeting so participants understand what is to be achieved. Make sure the goal is concrete, and attainable within the time allotted. If you schedule a meeting for one hour, you probably won’t achieve a vague goal like, “Redesign Forms.”

If the overall goal is too big to be accomplished in one meeting, cue the participants in to the fact that you will schedule several meetings by stating that this is just one of several meetings. You might even title the meeting, “Redesign Accounts Payable Forms – Part 1.”

Create the Detailed Agenda

Create a list of agenda items detailing what you plan to cover. It can help to list agenda items as questions, rather than statements. Questions engage the participants to begin thinking about what they need to do in order to prepare for the meeting. For example, instead of stating, “List fields missing from current forms,” you could pose that as questions, such as, “What fields are missing from the current forms? Why are the new fields needed?” Questions like these will trigger the participants to begin looking at the current forms to see what fields they have, and think about what fields they really need, and why.

Define Each Participant’s Role in the Meeting

By each agenda item, list the participant that is expected to be prepared to discuss that topic. Defining each participant’s role allows them to know how they should prepare for the meeting, and what they will be expected to discuss.

If a participant isn’t prepared, don’t force them to guess about things, or try to do their research right there in front of everyone else. First of all, being put on the spot may be embarrassing. Secondly, you will likely get incomplete information. Finally, it will slow the meeting down, and the other participants will become less focused.

Don’t allow a participant that is unprepared to be “publicly shamed.” Tactfully tell them that you’ll follow up with them later, or cover their portion in the next meeting. Then move on.

Send any Background Materials

Send any background materials to the participants ahead of time so they can prepare for what will be covered. Sending the materials that are to be discussed places additional parameters around the meeting, and further defines the scope of the meeting. For example, send copies of the specific forms that you need to cover so the participants understand exactly what they need to look at to prepare.

Set the Boundaries for the Meeting

Include a list of topics that won’t be discussed in the meeting to be sure participants know the boundaries of the discussion. For example, “This meeting will focus only on form changes. Changes to current processes affected by these form changes will not be discussed at this time.” This boundary further solidifies the scope of the meeting to keep it focused.

Why is the Meeting Needed

In addition to communicating the goal of the meeting, you need to communicate to the participants why the goal needs to be accomplished.

No one likes to think that they are being asked (read that as “forced”, if you will) to do something that has no importance.

If the participants know why the goal of the meeting needs to be accomplished, it gives them an understanding of how the meeting factors into the project as a whole. It’s through this understanding that the participants can realize how their effort, before, during, and after the meeting, affects the work of others, and why their participation is important.

Some organizations are still looking at a meeting free environment as the panacea to wasted time. The real truth is that meetings are seen as productive[3], and can be an essential tool to achieving success.

Productive meetings, though, don’t just happen, they are planned out.

Taking the time to create a quality agenda will help you manage meetings that are organized, and in which everyone participating has a purpose for being there, they know what they are trying to accomplish, and why they are meeting at that time.

 

References

Main illustration ©Susan Hellard. More Info: http://arenaillustration.com/portfolios/susan-hellard/

  1. International Institute of Business Analysis. “Introduction.” A Guide to the Business Analysis Body of Knowledge. Vol. 3. Toronto, Canada: IIBA, 2015. p30.
  2. ShoreTel. “Misconception #8”. Takeaways from the Shoretel Build a Better Meeting Challenge: 10 Common Misconceptions About Meetings. San Franciso, CA, 2016. p11. https://www.shoretel.com/sites/default/files/BuildABetterMeeting-FindingsEbook_0.pdf.
  3. ShoreTel. “Misconception #2”. Takeaways from the Shoretel Build a Better Meeting Challenge: 10 Common Misconceptions About Meetings. San Franciso, CA, 2016. p5. https://www.shoretel.com/sites/default/files/BuildABetterMeeting-FindingsEbook_0.pdf.

Gimme Dat Ding

Gimme Dat Ding. Managing Expectations.

Managing Stakeholder Expectations

“Do you also want …?”
“Adding that shouldn’t be a problem.”
“What if it also did …?”

These phrases all have one thing in common… We have all said them, and have lived to regret it.

As a Business Analyst, an important task is working with stakeholders to elicit solution requirements. The challenge faced by the BA is balancing the solution’s needs with stakeholder’s wants, keeping them in line with the scope of the project, and managing the stakeholder’s expectations of what what will be delivered.

Easy peasy, right?

According to A Guide to the Business Analysis Body of Knowledge v3:

“The business analyst is responsible for eliciting the actual needs of stakeholders—which frequently involves investigating and clarifying their expressed desires—in order to determine underlying issues and causes.”[1]

Requirements are not just what the stakeholder is asking for, they are what is needed to achieve the goal of the project, adhere to business rules and comply with regulations.

You don’t need to promise the stakeholders that you will deliver a pie-in-the-sky answer to all of their problems. You don’t even need to promise that it will have slick graphics, pop-ups, and snazzy sliding accordions (unless those are appropriate to the needs of the solution.)

You do need to promise that a solution will be delivered that will satisfy the requirements to properly address the problem. That includes things like performing calculations accurately, storing and retrieving data correctly, and functioning without errors.

Management is also counting on you to analyze the stakeholders needs, and align those needs with the scope, timeline and budget of the project.

Separation Anxiety

We’ve all heard the phrase:

“One person’s trash is another person’s treasure.”

It is often very difficult for stakeholders to understand the difference between “Needs” and “Wants”. To complicate the situation even more, different stakeholders will have different ideas of what they consider a Need. To effectively negotiate each group’s Needs and Wants, the BA needs to understand who the stakeholders are, and how the solution will impact them.

Needs and Wants can be defined in many ways, depending on the problem being worked on, but here is my general take on them.

Need:
Something that is required for the stakeholder or solution to accurately, and properly, perform or complete an action, calculation, or transaction, and cannot be accomplished through any other means. This must be satisfied for the solution to be accepted.

Want:
Something that is preferred, but is not required for the stakeholder or solution to accurately, and properly, perform or complete an action, calculation, or transaction, and could be accomplished through some other means. This does not have to be satisfied for the solution to be accepted.

In your requirements document, list and prioritize each requirement from the stakeholders. Label each requirement as “Need” or “Want”. Needs, of course, would be the highest priority items to work on. Wants, conversely, will be the lowest priority items to work on.

When you estimate the project, calculate the effort for Wants along with the Needs. Estimating both will allow you to break the effort down based on just the Needs, just the Wants, and the Needs + the Wants.

The Wants are your discretionary items that can be cut to keep the project on schedule and/or within budget. Having an estimated effort for the Wants will support your conclusions, and enabled you to shift prioritized items more easily.

Use this list as a guide so all parties can clearly see what will, may, or won’t be part of the solution.

For example:

Requirement Need Want Priority EOW
1.1 Ability to save both a billing address and a mailing address for a customer. X 1 2.5
1.2 Billing address to be required. X 1 0.5
1.3 Mailing address to be optional. X 1 0.5
1.4 Clicking a button will automatically populate the mailing address information with the billing address information. X 5 1.0

This method is a simplified version of the MoSCoW technique.

MoSCoW stands for:
Must Have
Should Have
Could Have
Won’t Have

(The “o”s don’t stand for anything, but they do help to make it a catchy acronym.)

Very briefly, with the MoSCoW technique, requirements are prioritized, and worked on, in order of greatest value (Must Have) to least value (Could Have). Won’t Have items are not included in the plan at all.

The technique is designed to focus effort on delivery of all the Must Have requirements. The Should Have and Could Have requirements are the discretionary requirements to be removed if the solution is in danger of falling behind schedule.

Regardless of the method you use to define the Needs and Wants, It’s imperative to set the expectation upfront that not all items may be delivered given the time and resources allocated. When the stakeholders understand this, from the beginning, it becomes easier to prioritize each requirement, and acquire approvals.

Development can then move forward on the Needs, spending the lion’s share of time making sure they are rock solid. If time permits, some Wants can be added, provided any added testing or issues they may introduce don’t negatively impact the project schedule.

In the end, it is your responsibility to be sure that the goal of a fully functioning solution is delivered on time, within budget, and with all the stakeholders Needs met.

Understanding all of the different stakeholders, recognizing their unique needs, and effectively eliciting their requirements in order to separate Needs from Wants, will enable you to achieve your goal.

References

Hammond, A. and Hazlewood, M. (1970). Gimme Dat Ding [Recorded by The Pipkins]. On A-Side [SINGLE] UK: EMI Columbia (DB8662); US/Can: Capitol (2819).

  1. International Institute of Business Analysis. “Introduction.” A Guide to the Business Analysis Body of Knowledge. Vol. 3. Toronto, Canada: IIBA, 2015. p3.

Fortunately, I keep my feathers numbered for just such an emergency

Fortunately, I keep my feathers numbered, for just such an emergency ~ Foghorn Leghorn

Foghorn Leghorn knew the importance of planning for emergencies. Like Foghorn, the Business Analyst needs to think about both the issues at hand, as well issues and opportunities that may not be immediately evident.

The Business Analyst needs to observe and understand the organization’s overall strategies, goals, and capabilities. The BA needs to use this “big picture” knowledge to be vigilant about analyzing processes that could not only negatively impact a new or existing system, but might also add unseen value.

Being vigilant doesn’t mean being a naysayer, or a prophet of doom. Being vigilant means keeping up to date with emerging trends, experimenting with new ideas, and staying on top of changes, even in areas outside of your responsibility. (The latter is where a good Change Management policy can help.)

The ultimate court of appeal is
observation and experiment… not authority.
~ Thomas Huxley

Use your knowledge of your industry, your organization, and your personal experiences, to guide you in looking for potential problems. Even if a problem has not been identified, you, as the BA, should be looking for potential gaps, and working through processes that could be used to resolve them.

If you notice something that may be a problem, work with the appropriate group to raise the issue, and discuss it. Don’t pull a Chicken Little and run screaming that disaster is imminent. It is likely that it may turn out that there is no issue, or the solution may be simple.

If you see a missed opportunity, presenting your idea can be more difficult. You must be respectful, and be prepared that the stakeholders may not be ready to adopt the idea. Even if the idea receives a positive response, be sure that it is the proper time to implement it. You don’t want to be the cause of scope creep.

If your idea isn’t well received, or it isn’t the right time, keep it in your back pocket. Don’t lose track of what you learned while playing around. The time to implement will arrive, and you can bring it up again.