Skip to main content

Tag: Facilitation

Encouraging Collaboration and Resolving Conflicts with Mockups

All business analysts have (or will) attend the same meeting with stakeholders so disagreeable that if you put an orange between them, they would immediately disagree on its color. If these stakeholders cannot bridge their disagreement, a great approach is to collaborate with the stakeholders to create lo-fi visual mockups.

When done correctly, BAs can use mockups to engage stakeholders in a collaborative learning exercise that includes the following elements:

  • Visual elements to depict subjects such as roles, actions, and relationships.
  • Auditory elements when discussing these topics.
  • Reading and writing elements when documenting discoveries and agreements.
  • Kinesthetic elements when modifying the placement and relationships of visual elements.

These are the styles identified in the VARK model of learning. Using this multi-sensory approach in a collaborative learning exercise can be bring together stakeholders, even if they have different learning styles.

 

Advertisement

 

Mockups can depict anything related to the business change – software screens, tables and fields in a database, or process flow diagrams. By collaboratively creating these items, BAs can engage stakeholders in a shared journey of discovery. During this journey, BAs can introduce new data points and information to gently transition stakeholders from entrenched “I-know-best” positions to the more neutral territory of shared learning. This additional territory can yield discoveries in terms of requirements and solution approaches. And sometimes, it can identify previously unknown common ground for adversarial stakeholders.

I participated in a real-world example of using mockups in this manner. During an elicitation session, two stakeholders adopted opposing views that involved a simple workflow. Each stakeholder had something of a point – stakeholder #1 argued that the solution should require completing a specific task before continuing; stakeholder #2 argued that finalizing that task later allowed for more flexibility.

 

I had mockups depicting a workflow for a related and similar process. These mockups were simple slides with screenshots and text boxes calling out the user workflow. I quickly made copies of those mockups to depict each stakeholder’s approach. Each stakeholder was able to instruct me on tweaking their mockup as needed; then, using the mockup as a visual aid, the stakeholder could articulate their approach more effectively. By comparing them side-by-side, it was easier for both stakeholders to see the validity and shortcomings of each. During our discussions, a third approach emerged, which we were quickly able to mockup. The stakeholders negotiated from their combined shared learning experience and agreed that this third approach would satisfy their requirements.

This real-world example of resolving stakeholder conflict with mockups reinforces the importance of the visual:

  • Stakeholders could more easily understand the relationship between their disparate requirements when mocked up.
  • Stakeholders could better appreciate alternative user workflows as the mockups clarified it.
  • Stakeholders could envision and agree upon a compromise solution when mocked up.

The mockups clarified the merits and obstacles of each approach and made the third (compromise) choice obvious. Even if the stakeholders had not agreed on the compromise solution, the depictions provided by the interim mockups would have clarified their point of disagreement and made their conflicting priorities clear.

Even in requirements, a picture is worth a thousand words.

The Better Meeting Manifesto – Stop Having Terrible Meetings!

Terrible meetings are an unfortunate feature of modern working life.  It doesn’t have to be this way: read on to find out how you can take a stand and achieve better meetings for all!

 

Encountering a terrible meeting in the wild

Most of us have suffered through a terrible meeting.  You know the scenario.  A group has assembled in an airless meeting room in response to a calendar invitation.  The AV equipment is faulty, so the unlucky person with the controls has spent the past 10 minutes trying to connect to the remote attendees.  Everyone else is making small talk or discussing the previous meeting.  When the equipment finally cooperates, you all realise that the meeting organiser isn’t in attendance.  Undeterred, you check the meeting invitation – only to find it unhelpfully blank.  The group makes a valiant attempt to progress things; however, you can only get so far with the main person missing.  The meeting finishes early; the group sighs and agrees to reconvene another day.

 

Then there is the alternative, more insidious variant.  At first glance, things begin well: the meeting logistics are on point, the right people are in the room, and you received the outline ahead of time.  Yet once the meeting starts, issues soon become apparent.  There are too many items for discussion.  Due to aggressive timeboxing, there is little scope for more than brief comments regarding each.  People grow increasingly frustrated with the lack of opportunity for input, the schedule drifts, the meeting overruns and several agenda items are never reached.  The group makes little progress; the attendees are sentenced to a re-match to address the same material the following week.

 

Regrettably, these experiences are far from rare.  Is it little wonder, then, that we sometimes find it hard to get our stakeholders to make time in their diaries for yet another meeting?

 

Trojan horse meetings: a false solution

To combat meeting aversion, some session organizers resort to subterfuge.  One such ploy is the classic Trojan horse maneuver: book meetings into the calendar under the guise of something more palatable.  Often, the decoy is a workshop.  For example, a document sign-off meeting might be billed as a ‘requirement sign-off workshop’, even though the session is less about facilitated qualitative review and more about sitting around a table together to agree that the ensuing work can proceed.  A stakeholder interview to elicit information about a particular aspect of their role might appear in the calendar as a ‘process workshop’.  A team meeting might become a ‘team workshop’, and so on.

 

Superficially, this tactic can bear fruit – at least in the short term.  So why do people feel more positive about workshops over meetings?

 

  • Meeting fatigue

The first reason is novelty, pure and simple.  People want respite from busy calendars booked up with tedious and unproductive meetings.  Workshops are attractive because they generally feature interactive activities instead of the usual dry discourse.  Even the mere hint of this variety can suffice to lure stakeholders into believing they are in for a welcome change.

 

  • Productivity by association

A workshop is a facilitated intervention that seeks constructive input from all attendees to achieve a defined output.  In positioning their meeting as a workshop, the organiser aims to appropriate the qualities of focused, engaged participation and demonstrable productivity from the workshop format and confer them upon their meeting session.

 

Unfortunately, the aspiration of engagement and productivity will only get you so far.  Without good facilitation, a meeting will still be terrible no matter how you dress it up.  Worse: a bad ‘workshop-but-actually-a-meeting’ experience might harm your work by putting stakeholders off attending workshops in the future.

 

Advertisement

 

Another way

Rather than deflecting attention from the problem, it’s time to take a long, hard stare at the meetings in our lives.  Faced with a wilderness of terrible meetings, how can we act to change things for the better, no matter which end of the calendar invitation we are on?

 

  1. Make meetings pointy

All meetings should have a clearly defined purpose and intended outcome.  No point?  No meeting.


As the organizer:

If you are responsible for setting up a meeting but cannot answer the questions ‘Why are we meeting?’ and ‘What should we have achieved by the end of the meeting?’, this is a sign that you should reconsider.  Is a meeting necessary, or might there be another way to work with your stakeholders (e.g. using your organisation’s preferred collaboration tool)?  Don’t be afraid to postpone or cancel a meeting if circumstances change.

 

As an attendee:

Your time is as valuable as anyone else’s.  Invitations are not obligations.  If you receive a vague meeting invitation, contact the organizer and politely ask them to clarify the meeting’s purpose.  A helpful sentence to use is ‘Please could you confirm what will be covered in this meeting so that I can prepare?’ – it helps you sound engaged while also acting as a prompt for the organizer to step up their game.

 

  1. Energize and engage

Meetings can’t always be fun, but don’t make them any more painful than they have to be.  Start with the intended outcome and take active responsibility for getting there.

 

As the organizer:

A great tip from BA guru Angela Wick is to ‘verb-noun’ your meeting titles to set the intention for the session outcome: instead of ‘Requirements Review Meeting’, try ‘Finalise Requirements for Procurement’.  It instantly puts your attendees into a more active mode of thinking which will carry into the meeting itself.  Set a clear schedule with realistic timings and manage the session actively to keep things on track.  Don’t let people doze off: check in frequently with all attendees (particularly those attending remotely) to ensure that everyone feels involved and has the opportunity to provide input, even if it’s just a quick thumbs-up/thumbs-down vote.

 

As an attendee:

It might not be your meeting, but you are part of it – and its success or failure.  Help things go smoothly by doing any necessary pre-work ahead of time and coming to the meeting prepared.  Be fully present and listen actively – nobody wants to recap points made five minutes ago because you were not paying attention.  Consider whether your comments contribute usefully to the intended outcome before speaking.  Where you can, support the facilitator.  For example, can you help by relaying remote attendees’ comments to the room?

  1. Master your meeting modes

Following the recent pandemic, many of us continue to work flexibly between the office and home; meetings now frequently mix face-to-face and remote attendance.  These ‘hybrid’ sessions can be tricky to get right, but it’s not impossible.  With a bit of planning, you can be a meeting mode superstar.

 

As the organiser:

Meet your stakeholders where they are.  If people are uncomfortable with coming into an office space, forcing an in-person meeting will result in no-shows.  Save face-to-face for the times you truly need it and focus on providing a good experience online for everything else.  Be aware that attendees may decide to group up and attend online from the same room, so give specific instructions if your planned activities require each person to have separate access to a computer.  Design for online: take full advantage of the synchronous and asynchronous collaboration tools available through the applications at your disposal.  Get equipment warmed up in plenty of time, ready to get going when the meeting starts.  And whatever you do: don’t apologise or make excuses!  You’re about to lead a fantastic online session, after all.

 

As an attendee:

If you are attending in person, don’t forget to acknowledge and address any people attending remotely.  As a remote attendee, be mindful of your audio input.  Use a quality headset with a good microphone if you work in a shared office environment – and be prepared to mute yourself when you aren’t speaking to minimise disruption.  Nothing is worse than hearing background noise or someone thundering away at their keyboard.

 

What tips and tricks have you found to tackle the tyranny of terrible meetings?  I’d love to hear your thoughts!

The Courage to Try Something Old – Part 2: Scribing

In the previous article I wrote about the importance of facilitating requirements meetings and why it can take courage to do so. In this article I’ll discuss another skill that has fallen in and out of favor over the years—scribing.

Many ancient societies valued scribes. Scribes typically were at the center of all activities and highly regarded in the areas of government, law, military, and religion. Today’s scribes are not so universally regarded, particularly in our world of PMs and BAs. Effective scribes should be at the center of requirements activities, but most often they are not. We’re often in the back of the room or off to the side. We’re not always introduced in virtual meetings. Many organizations view scribes simply as passive note-takers and unfortunately that’s how many scribes view themselves. But I have found that scribes are essential to the success of the project.

 

What is a scribe and what does a scribe do? A scribe is the role that provides documentation, either formal or informal, and anyone can play that role. PMs, BAs, facilitators, business owners, QA analysts, programmers—it doesn’t matter what the title is. Any time we’re documenting our PM or BA work we’re scribing.  Our output can include recaps of sponsor and other stakeholder meetings, requirements (models, textual, etc.), assessments, gap analyses, and business cases to cite just a few.

 

What skills does a scribe need? Like every effective PM and BA, the scribe has to create structure from chaos. That’s not easy so scribes need a variety of skills, such as listening, absorbing, clarifying, and writing. But perhaps most important is critical thinking, which comprises many skills including:

  • Conceptualizing – grasping what’s being discussed because we have enough context[i]
  • Applying – taking what we know from our experience and using it in new situations.
  • Synthesizing – absorbing lots of information, processing it, and making sense of it immediately.[ii]
  • Evaluating – knowing what’s important and what’s not, what works and what doesn’t.[iii]

 

Advertisement

 

Why do we need scribes? Documentation is important if for no other reason than because it saves time. We cannot possibly remember all the salient topics of our project and requirements meetings. Documentation helps prevent revisiting and revisiting again all the important decisions already made and who should complete which action items and by when.

 

How much courage does it take to scribe?  Why in the world would it take courage to scribe? Because the most common scribing pitfalls relate to courage. I am often asked questions such as these:

  1. What if the PM and/or team thinks it’s a waste of time to have a scribe?
  2. What should I do when the facilitator wants to “take notes,” but in the end, much of the meeting is lost because the notes are too sketchy?
  3. What should I do when I’ve been told to sit in the back and be silent when I take notes? Most of the time I have questions or want to clarify what’s been decided, but I’m told that asking questions will take too much time.
  4. What should I do when I’m asked to distribute the documentation in an unreasonable time frame?
  5. I know it’s important to recap the highlights of my scribing output at the end of the meeting, but we never seem to have time. Our discussions always run over.

 

If we are too timid to address these issues, we will be less useful not only to our project team, but the entire organization. But it takes courage to tackle them. We need to be effective at influencing, and courage is a main component of influence. We need to ensure that everyone understands the importance of both scribing and the scribe role, and it takes courage to point these out. It takes courage to speak up about the risks of not having scribes in organizations that don’t value them. And to link an unsatisfactory product delivered to stakeholders to effective scribing. And because it takes time to be an effective scribe, we need to advise including scribing tasks in project planning.

Finally, as scribes we need to be neutral and not have a vested interest in the outcome of the meeting. As we know, the person with the pen has the power and can rewrite the project’s history. Let’s not sneak in a couple of our or our sponsor’s favorite requirements, or conveniently forget any because it’s easier than seeking a scope change. And there’s no need to document every conversation– the key items like decisions and action items will do. When done well, scribing is a thing of beauty. When not, it might well be tossed out with other old but necessary techniques—definitely not in the interest of either the project or the organization.

[i] This often comes from past experience and is one of the reasons I’m not in favor of “neutral” scribes
[ii] This is one of my favorite scribe skills because it is essential in a requirements workshop where there’s so much happening at the same time.
[iii] louisville.edu/ideastoaction/about/criticalthinking/what for the 4 basic concepts

Just because you are in the minority doesn’t mean you are wrong!

Speak to any group of BAs, and they will empathize with the frustrations of a familiar experience: you have spotted a potential problem on the horizon, but you’re struggling to convince teammates and stakeholders that it needs addressing (or even that it exists at all).  Argh!  So why don’t people believe us, and how can we help them see what we see?

 

The unique BA perspective

Even if you work collaboratively with a range of stakeholders, the nature of the BA role makes you something of a solo operator.  You are often the only one of your kind assigned to a multi-disciplinary project team, and – while you will be consulting widely with others – the analysis input of your role comes from you alone.  Working at the interface of many sources of information puts you in a unique position to see things others can’t.  It is both a blessing and a curse: while you can add value by making inferences and drawing conclusions that aren’t obvious to the folks on the ground, your insights are not always readily received when those folks are preoccupied with other lines of endeavor.  You want to share your findings to help improve outcomes; they want to get on with their work without the BA derailing it.  You may not be a specialist in their area, so why should they believe you?

 

The best of times

If you have good working relationships with your team or stakeholders, a carefully timed question or constructive conversation is all you need.  Project professionals are often keen problem-solvers like you.  If you need to spend more time unpacking each other’s points of view, you can resolve most queries amicably with a chat around a whiteboard.  Be mindful that specialists won’t necessarily welcome direct challenge from a non-specialist: in these situations, you may find it beneficial to cast yourself in the ‘apprentice’ role.  Ask your specialists to help you, the interested non-specialist, understand the matter at hand by walking you through an explanation; you can then cannily insert your leading questions at the appropriate point.  You may, of course, have misinterpreted something and be flat-out wrong – so be prepared for that eventuality!

 

The worst of times

Sometimes, however, that initial conversation doesn’t cut it.  You’re still sure that you’re on to something – the discussions haven’t disproven your theories – but you cannot get others to consider, let alone understand, your way of thinking.  You feel like the prophetess Cassandra of Troy from Greek mythology: fated to see the future and obliged to speak the truth, yet never to be believed.  So what’s a BA to do – why isn’t the message getting through?

 

Advertisement

 

Understand the problem

As with any analysis, the key is to identify the root cause of the issue.  It’s easy to take it personally when your concerns are dismissed without consideration but don’t automatically assume malice.  There are lots of reasons why people may not be responding as expected:

  • You might not have communicated your ideas as clearly as you thought.
  • You communicated clearly but caught them on a bad day.
  • People with other viewpoints outrank or outnumber you – people tend to be swayed by power or a majority.
  • They might not feel secure in what they are doing and don’t want to be challenged by any ideas that could throw things off balance.
  • They may lack the contextual knowledge or technical aptitude to understand your ideas.
  • They have different priorities (or different agendas!).
  • You might not be their ‘preferred sender’.

The last point can be incredibly frustrating.  Sometimes, despite you doing absolutely everything else right, you are just not the person to whom your audience is willing to listen.

 

Formulate your plan

Once you’ve figured out what’s going on, it’s time to get a communication action plan together.

  1. Identify your target person or people.

To achieve your desired outcomes, who do you need to persuade to consider your point of view?  Sometimes, this isn’t the person you think of first.  Is there another individual whose voice is more likely to carry weight with your ultimate target?  If so, it may be better to channel your energy into helping this individual understand your concerns and letting the message travel forward via them instead.

  1. Curate your materials and your messaging.

Cut the waffle: what are the key points you need to communicate?  And how are you positioning your message?  If the presentation format you’ve used so far hasn’t worked, try something new: can you package things up differently?  People often respond favorably to visual material if it helps them get to grips with something less familiar.  Sometimes a diagram can make all the difference.

  1. Build your coalition.

Are there others who understand your perspective and could help influence the conversation with your target person or people?  More people saying the same thing can add credibility to your message through endorsement and weight of numbers.

  1. Pick your moment.
    Timing is everything. Your message is unlikely to land well if you try to share your thoughts in the middle of an unrelated but all-consuming disaster, for example!  Aim to create appropriate time and space for a calm, focused discussion.
  1. Be prepared to play the long game.

It may take several attempts to land your ideas, particularly if you have had to involve other people to help deliver your message.  Consider the overall impact of your interventions on your target person or people.  How will the sequence of interactions be experienced from their point of view?

Once you have the above in place, you can initiate your plan.  Good luck!

 

Know when to hold and when to fold

One of the more difficult things to accept as a BA is that things don’t always go how you think they should, even if you have the truth on your side.  It’s a great feeling when your suggestions are recognized, valued, and help shape the work to come, but it’s equally likely that you will hear: ‘Yes, I understand what you are saying, but we have to do it X way because of Y.’  Don’t feel disheartened if this happens to you.  If you have managed to get people to understand your point, no matter the eventual outcome, you have done your job.  You have identified a potential issue, surfaced it for consideration by the appropriate stakeholders, and enabled an informed decision to be made in consequence.  There is one less unknown in the project landscape; it’s time to let that point rest.  Onward to the next challenge!

The Strawman: When a Wrong Makes a Right

Sometimes, the easiest way to find out what someone really wants is to show them what they don’t want.

The strawman approach is frequently used by business analysts – sometimes knowingly, and sometimes not. Actively inviting stakeholders to engage with and criticize an inaccurate reflection of requirements can provide insights that greatly speed up the requirements elicitation process. However, it can also be a risky approach.

This article describes that strawman approach, its potential pitfalls, and tips for using the approach to support productive requirements elicitation.

What is the Strawman Approach?

You may have heard of a strawman argument – an argument that distorts an opposing stance to make it easier to attack [1].

In business analysis, a strawman can be created by presenting knowingly incorrect, incomplete or distorted requirements to stakeholders in order to provoke a response. This is usually done in the form of a model or prototype solution, providing a visual representation that stakeholders can engage with and refute. The idea is that the way stakeholders respond to the inaccurate strawman will inform more complete, coherent and representative stakeholder requirements.

Stakeholders often find it difficult to articulate their requirements. They can be vague when it comes to specifying their wants (I want a bright color…), yet very specific when it comes to specifying what they don’t want (…but not pink!) This is because people often find it easier to specify their wants and needs in opposition to something. In such cases, presenting an inaccurate or incomplete model/prototype representation of requirements as a strawman can provoke a strong response from stakeholders, creating a better understanding of what they don’t want, and providing a starting point for conversations about what they do want.

 

Advertisement

 

The Pitfalls of the Strawman Approach

While the strawman approach can be a powerful requirements elicitation technique, the approach should be used with caution. Some of the potential pitfalls associated with using a strawman include:

  1. Impact on your credibility: When done right, presenting a strawman to stakeholders can make a business analyst appear open, co-operative, and responsive to stakeholder needs. However, presenting something that is clearly wrong can also impact a business analysts’ credibility, leading some stakeholders to question the analyst’s abilities.
  2. The strawman becomes the answer: The point of the strawman is that it isn’t accurate! You want stakeholders to refute it and provide information that will allow you to change and/or improve it. However, in cases where stakeholders really do not know what they want, they may not challenge the strawman. This could lead to the strawman (either in part or whole) becoming the answer.
  3. The business analyst can feel exposed: Presenting a strawman is not an easy thing to do. It takes a degree of professional courage to produce a piece of work and present it, only to have it criticized – even if that was the intention.
  4. Some stakeholders are too nice: Some people find criticism difficult and may be unwilling to say what they really think about a strawman, particularly when they are being asked to criticize it in a group setting.

Tips for using the Strawman Approach

The following are a few tips to consider when using a strawman to elicit requirements:

  • Do you research. Make the ‘strawman’ as accurate as possible. Differentiate between elements of the strawman that are based on known, more accurate requirements, and those that are ‘best guesses.’
  • Know your stakeholders. Think about how your stakeholders might react to the strawman. Think about how you present the strawman to different stakeholder groups. Consider presenting the strawman to ‘friendly’ stakeholders 1-on-1 to get feedback to improve it, prior to exposing it to more influential stakeholders and/or a larger group.
  • Acknowledge it is a strawman. Sometimes acknowledging what you are presenting is a ‘strawman’ will give stakeholders the permission they need to constructively criticize it.
  • Don’t rely on it. The strawman approach should not be used as a primary requirements elicitation approach, but rather a tool that may be deployed to elicit those more subjective requirements, engage a particular stakeholder group, or as a check for validating what you know and what you don’t.
  • Clearly label your strawmen. Once in the wild, the strawman can obtain a life of its own, being reproduced and/or discussed in unintended places. Therefore, it is important to clearly label, store and/or otherwise indicate the strawman is a draft, prototype or experiment.
  • Don’t take is personally. Remember, the stakeholders are reacting to and criticizing what is presented to them – not you personally!

 

Reference
[1] Strawman Arguments: What They Are and How to Counter Them – Effectiviology, www.effectiviology.com/straw-man-arguments-recognize-counter-use/