Skip to main content

Tag: Facilitation

M_SSING Context

Have you ever had a conversation where the context was missing? Have you considered going the extra mile so that everyone has the same viewpoint?

Let us look at the scenario below:

*Person A and B are looking for the same flour brand at a grocery store.

At a grocery store:

Person A: Hello! Would you know in which aisle can I find ABC brand flour?

Store employee: I am sorry, we are out of that brand.

Person A: Thank you!


Advertisement

*END OF CONVERSATION 1*

At a grocery store:

Person B: Hello! Would you know in which aisle can I find ABC brand flour?

Store employee: I am sorry, we are out of that brand.

Person B: Thank you! Would you know if there are other brands of flour? I need the flour for a craft project.

Store employee: Aisle 15 is where you can find all the brands of flour. Any brand would work since you need it for a craft activity. If you would like, feel free to check aisle 20 for craft supplies.

Person B: Thank you so much!

*END OF CONVERSATION 2*

One requirement yet different experience. For a fruitful conversation, all the participants must have the same understanding. The team must work based on the same set of assumptions. How can you ensure the team is on the same page? Start by asking questions. It is second nature for a business analyst (BA) to ask questions. Asking questions merely to extract information does NOT help uncover the detailed requirements. As a result, lack of details could often lead to misinterpretation and miscommunication.

Here are a few ideas that can get everyone on the same page and their benefits:

1. Provide a brief background about why you are asking the questions.

E.g., Instead of asking the stakeholder what is the current billing process? You can ask, “I would like to understand how is billing done? What are the pain points? What are the components of the process that would need to stay in the new application? Comprehending the as-is state will help understand the gaps and offer solutions.

2. A Business analyst (BA) can ask contextual questions to stakeholders. Stakeholders must reveal details without holding information.

Tip: Share these questions ahead of a conversation with a stakeholder. The stakeholders can organize their thoughts and come up with a list of questions if needed.

Bonus:  A BA can offer alternative solutions if they have the same background as the stakeholders.

3. Providing context paves the way for sharing real-world examples by stakeholders. These use cases aid, everyone, on the team in visualizing the user’s world. Based on the second conversation above, it is evident that there are more use cases to flour than cooking.

4. Let us change gears from the stakeholders and talk about the team. When team members have the same context, they can ask questions amongst themselves to strengthen their understanding.

Conclusion:

Next time around, be it any conversation, make a conscious attempt to explain why you need what you need? That helps the other person understand your perspective and intent. After all, one term can have multiple meanings depending on the context used. The context can change the entire landscape of the conversation.

“For me, context is the key – from that comes the understanding of everything.” – Kenneth Noland.

Oblivious or Attentive

I was once demoing the specific functionality of an application. I was looking forward to my favorite part of the meeting: Q&A, but to my surprise, no one uttered a word.  My mind was racing with questions: Was my delivery crystal clear that there were no questions?  Was no one paying attention? Why the silence? Should I have approached the demo differently? I earned great accolades relating to the demo. Yet, the silence was bothering me. When an attendee is quiet, does this translate as unplugged from the conversation? Or are they employing active listening? Let us analyze why the disconnect happens in the first place. Here are a few reasons:

  • Lack of a meeting agenda
  • The facilitator is over-communicating
  • Right people not in the meeting
  • The facilitator is deviating from the scope of the meeting
  • Attendees double-booked at the same time
  • Attendees distracted by things unrelated to the meeting
  • An email could have sufficed instead of a meeting
  • Topic covered in a previous meeting

 What would I do when I am not engaged in a meeting? I may:

  1. Multitask
  2. Stay quiet during the entirety of the meeting
  3. Browse on my smartphone
  4. Turn off my camera

 What would I do if I am engaged in a meeting? I may:

  1. Ask contextual questions based on the topic
  2. Volunteer to work on the action items
  3. Share one-off use cases or exceptions
  4. Assist in decision making
  5. Turn on my camera

Advertisement

What next?

The cues listed above are not a perfect indicator of engagement during a meeting but watch out for them. What strategy can you adopt during the next demo/meeting? As business analysts, we are Change Agents, experiment with the ideas mentioned below to lead the change:

  • Use virtual whiteboards and invite attendees to collaborate by sharing their ideas
  • Co-present instead of having one team member presenting through the meeting
  • Ask an open-ended question and ask every attendee to articulate their responses
  • Ask for votes from every attendee or create a survey with many options so that everyone can pick one

Conclusion:

Next time watch for those subtle or clear clues during a meeting. Lead meetings that best fit the target audience and are within the scope of the meeting agenda. It is motivating when attendees are not forced but are looking forward to the rendezvous.

“One of the greatest gifts you can give to anyone is the gift of attention” – Jim Rohn.

The icon library: My favorite analogue tool

With the growing use of agile practices and design thinking, there is also a growing awareness of the importance of working visually. If you are an inexperienced drawer, this is can be a major barrier for starting with sketch noting, visual facilitation and graphic recording. In this article, I recommend establishing an icon library to document your learning and growth as a visual practitioner.

An icon library is my repository of the icons and symbols that I have used. I have it so that I can reuse icons by simply looking them up. And yes, it is in an analogue format. In fact, it is a notebook with each page divided into six squares and room for a name for the icon.

The icon library is my box of LEGO bricks. They are the building blocks, that I use when creating visual content. To work efficiently, it helps to actually think if it as a box of LEGO bricks. Meaning, when drawing I have what is available in my icon library. I can use color, size, and the relation to other elements in the visualization to convey meaning. I can also combine icons and thereby create new ones. In that respect, I can use it as a constraint that forces me to think more creatively. While building with LEGOs you usually do not have the option to just go out and get new bricks. You use what is available.

The senior LEGO designer Søren Dyrhøj advices to copy other people´s LEGO models with the bricks you have available. Because when you copy, you are practicing the skills you need to create something original. The same goes for visualizations. When you get started, do not worry about coming up with something unique. Look around you and use what you see; imagery used by your company and established modeling techniques, and do not be ashamed to look icons up online.

Advertisement

When I am not under pressure to deliver, I do take the time to come up with new icons and symbols while creating visualizations. I try to always have the discipline to add them to my icon library then. When I start working with new subject matters or domains, I always make sure to invest some time in coming up with icons and metaphors that I can use for visual content. Also, when I start engaging with a new group of end users, I create an icon for that user. Usually, 70-100% of the drawings I use, are from my icon library. The LEGO metaphor is also one that I have used several times before in different contexts. It is suitable for topics concerning IT architecture consisting of “building blocks”, and for illustrating collaboratively creating a product. Another reason why I like it is because it also refers to my cultural heritage as a Dane (LEGO is a Danish design icon that we are very proud of).

Sooner or later, it is highly recommended to learn from a professional visual practitioner. There are many options for training available, and several books on the topic. This will familiarize you with a visual alphabet, which will take your skills to the next level and enable you to create original content. I personally recommend the book “UZMO – Thinking with your pen” by Martin Haussmann, who is one of the pioneers in graphic facilitation. His bikablo concept is very useful and easy to learn.

Working visually in analogue formats can be a truly liberating experience because you are completely free of the constraints built into digital tools. It can also improve the way you process and present information when you get rid of the abstraction level of the keyboard, and thereby have a closer connection with your content. With the right approach established – e.g. having an icon library – you can work just as efficiently as when using digital tools.

Where To Start with an Entity Relationship Diagram

In my previous article An Entity Relationship Diagram Isn’t Just For Database Design I talked about the usefulness of Entity Relationship Diagrams.

Richard Larson did an excellent overview of some of the more technical considerations when putting together an ERD For The Love Of Data

But one of my colleagues recently asked me for help, as they hadn’t done one before and weren’t even sure where to start. If you’ve no experience of putting together an entity relationship diagram, it can be quite daunting to take that first step.

As a consequence, I’ve put this together for the benefit of those who fall more into that “where do I start?” category, and to explain how you might start to document your ERD.

Continue reading

4 Tips for Running Effective Workshops

Business Analysis has to do with understanding clients’ needs and trying to offer value through the products you deliver to them. Customer is the final judge and the more the product we develop for them is fulfilling his needs the more he will be happy.

Workshops are a common method for requirements gathering and elicitation. It’s one of the best ways to ensure effective and bidirectional communication between stakeholders and reach consensus on a topic. However common pitfalls can prevent from having the results you want.

Four tips are presented:

  1. Have a specific agenda

You have to define the specific purpose of the workshop. May the purpose varies from a high level capturing of needs to a specific finalization of an integration. After clarifying the purpose then you have to develop specific expected outcomes per area. As time constraints exist is crucial to have the answers you want at specific questions you have. Having a logical sequential discussion flow will prevent from limitless philosophical discussions without any conclusion at the end.

  1. Get the right people involved

Identify the key stakeholders that have knowledge on the area of interest, decision making authority and influence. Try to have a list of participants knowing what every participant can contribute. The right mixture of participants is the one that will lead to final conclusions that are approved and will close as much open points as possible.

Advertisement

  1. Pose the right questions

Making the right questions at the right time is crucial. A specific question may clarify things out, give to the customer another perspective that has not think about and contribute to having specific agreed points at the end of the workshop and reduce open points.

  1. Have evaluation criteria

Workshop results has to be agreed and confirmed by every participant. Before having something finalized in the workshop results make a quick evaluation using predefined acceptance criteria. Technical feasibility, usability and cost are some common evaluation criteria

Facilitating a successful workshop for sure needs experience and may be challenging. However the proper preparation, the clear scope and purpose. Lacking of previous insightful preparation of a workshop can lead to its derailment in the sense of giving space to expression of wishful thoughts that are neither specific nor feasible. On the other hand, dogmatic obsession with the narrow capabilities of the system can prevent the development of potential functions and features that are easy to implement and provide value.