Tag: Communication

Avoiding Communication Gaps

Information is critical to successful change in organizations. How information is communicated can either significantly propel or break down a project. Business Analysts have a critical role in facilitating and influencing communication to impacted areas of the organization. Without a communication skillset, Business Analysts risk being the weakness in the linkage system organizations need for synchronized transformation.

Here are some communication gaps to avoid as a BA practitioner:

  1. The “Barrel Ahead” BA

Each organization has its own pace and comfort zone. When working with stakeholders and business partners, it is important to understand all aspects involved in a potential change. This includes awareness of culture, capacities, readiness, and even other initiatives that are also on the move that may pose distraction or compete for resources. An essential aspect of communication for Business Analysts is listening. Effective listening includes reserving judgment and knowing your audience to form appropriate responses to encourage engagement.

A Business Analyst that is only focusing on pre-conceived outcomes of initiatives poses a risk to not only the stakeholders but to the ultimate success of the outcome. Rushing through steps can also create risks of knowledge gaps and missed requirements.

Pace is significant to initiative success, from framework to implementation. “Tunnel vision” and a too-rapid approach to simply reach the finish line can be easily identified by stakeholders in poor communication, which can then break down engagement and crack the important foundation of trust.

Advertisement

  1. The “Non-Organization Structure” BA

Every organization has a different blueprint of business areas, information, and involved systems. Resources can exist in physical forms such as a database or library, or be integrated within individual knowledge or entire business units. It is important for Business Analysts to understand the organizational landscape so communication can be appropriately deployed. Being an effective Business Analyst includes being able to “bridge” organizational areas, and knowing their structure, purpose, and goals helps to create a solid base for communication.

Not taking the time to understand or learn about the organizational structure can be a risk to the governance approach of a project. Creating and sending communication to the wrong decision-maker can not only create problems within an initiative, but it can also create inter-organizational conflict.

  1. The “Isolated Island” BA

Teamwork is essential to successful change. This is likely why “Elicitation and Collaboration” are paired together in the BABOK. Having stakeholders and business partners appropriately engaged moves the collective pieces of the organization successfully through changes. Having the correct approach to stakeholder communication can set the stage for continuous involvement and support.

While some organizations have Business Analyst roles in various layouts, whether you are on a team of same titles or spread out as a function within various areas, it is important to keep a level of connectivity with all business partners. Business Analysts do their best when they keep avenues of collaboration active with well-fed communication. Active communication helps to reinforce organizational awareness and also creates proactive project efficiencies. Approaching initiatives as a single-ownership can erode stakeholder engagement, as teams may see goals overshadowed by interest in individual portfolio rather than a true business need.

More Than the Destination

Informed stakeholders are comfortable stakeholders. From the start of planning the Business analysis approach to evaluating solutions, communication is essential for teams to successfully meet and satisfy business needs.

Facilitating a collaborative, informed, and trusted environment will help the organization get the most out of not only the outcome but the journey.

Turn your specifications into living, digital documentation

Digital transformation requires the use of new tools and new ways of working – also for business analysts. We often facilitate this for other groups of people, and we should be ready to look at our own habits and preconceived notions as well and embrace new mindsets and tools. This article offers a take on what ways of working could look like for the digital business analyst.

Collaboration is becoming increasingly digital, and this also gives business analysts many opportunities to work smarter and better. That is, if you are ready to let go of documents and spreadsheet, and instead embrace digital tools for wikis, notes and backlog management. With a wiki tool, you can easily build your requirements documentation using webpages in a tree structure. Your first pages describe your scope. Each of those pages can then be broken into details on several pages that branch out. If you are familiar with mind maps, you will see that this is basically the same structure. In fact, a mind map can be a great first sketch of how to structure the content of the wiki.

Advertisement

The wiki structure allows your documentation to grow dynamically without you losing the overview. This structure is very well suited for agile development. If you focus on establishing the scope first, you will soon have some documentation that is accurate, though it is high level. You can describe the scope of your initiative first, and sign that off with your stakeholders. Based on that, you can discuss deliverables with your developers, and establish your backlog with features or epics. The features or epics can then be prioritized with your stakeholders. You can then detail out the requirements on your wiki, and the team can break down the user stories based on the wiki. This means, that while your scope is fixed and signed off, your detailed requirements get fixed and signed off incrementally in the same pace as the team is developing. I have experienced this to be a good way to be able to handle scope creep (because I have the scope to keep the requirements in check) and to avoid analysis paralysis and requirements rot. Because it is digital, I can create links from my backlog items to the relevant parts of the specification.

The basic concept can be illustrated like this:

Why not just add my requirements to the backlog items, and avoid all the linking? Well, because I want my documentation to describe my product holistically, including its context. And I want my backlog to describe the increments that the product is built in. So I need both.  I can then communicate, what my product is and does without also having to communicate the increments it was built in, which is completely irrelevant to most of my stakeholders. I can easily share a wikipage with a link or present it in a meeting. This means fewer powerpoints to produce.

Once the product is built, I no longer need the backlog – my documentation is what describes the product. And with that documentation established at the very early stages of the product development phase, I can communicate what the product looks like through its whole life cycle, from the birth of the idea to the decommissioning of the product. Each page is automatically version controlled, which makes the change control much more granular, and changes easy to manage without keeping extensive change logs. In some digital tools, you can even set up approval workflows to make sure that the right people sign off on changes. I like to think of it as the DevOps mindset implemented in requirements analysis.

You can add any kind of content. A webpage has no limits when it comes to content – pictures, text, tables, links, and attachments. Your documentation can contain much more than a traditional requirements specification, such as personas, test data, samples of production data and other types of examples. Because of the tree structure, I always know which objective or process a detailed requirement supports. Obviously, various kinds of diagrams play an important role. Traditionally, you would argue that you must do your modelling using a modelling or BPMN tool. The reason for this is that your models can then be reused by others. In theory, this is true. However, I have never experienced this reuse in my 15 years as a business analyst.

Over the past couple of years, I have practiced using pen and paper for visualizations, and I have integrated this into my ways of working. It is a great way to work because it helps me focus and process information. It is also free of the constraints a computer program sets when you create digital visualizations. To my own surprise, this approach is very compatible with digital documentation. Simply take a photo or scan a drawing and add the image to the page. It can then be enriched with text for elaboration. This is particularly useful when describing scope, features or epics and application landscape. Digital and analogue are not contradictory, but complementary.

I have recently published two articles on BA Times related to using pen and paper, which provide some tips for getting started:

Start your visual facilitation journey with letters

The icon library: My favorite analogue tool

Critical Skills Needed for Project Success

Part 1 – Elicitation

This article is the first in a series I’ll be writing about critical skills that all project managers (PMs) and business analysts (BAs) need for success. We need these skills regardless of the type of project we’re on, the industry we’re in, the technology we use, or the methodology we follow. Each of these skills requires a combination of what are commonly called hard skills with those needed to work effectively with others.

This first article is about elicitation. It seems easy. After all, what’s so difficult about asking stakeholders questions? Elicitation, of course, is far more than the questions we ask. When all is said and done, it’s about learning. We learn what our stakeholders want, what they need, and hardest of all, what they expect by asking really good questions and listening to what they have to say with great attention. It’s tricky, though. We can’t do what I did early in my career when I tried to develop a list of requirements by introducing myself and asking what the stakeholders’ requirements were, what they really needed, and what they expected by the end of the project. Simply put, we won’t learn enough to create an end product that they’ll be happy with.[i]

What makes the elicitation process so hard? Here are several pitfalls.


Advertisement

Common Pitfalls

#1 – Missed expectations

Expectations are requirements, but they’ve never been stated. Therefore, we cannot get expectations by asking about them. Our stakeholders don’t think to mention them, and we don’t think to ask about them. I didn’t know about hidden requirements early in my career when I asked the questions like those noted above. Another problem– my focus was specifically on the future state solution. I asked for the features and functions, documented them, and got stakeholder approval. Then the development team built the final product according to the specifications with the inevitable result—a lot of stakeholder complaints.

#2 – People fear the future state.

This major pitfall is hard to overcome for many reasons. Some stakeholders are comfortable with their current state and don’t want to learn or train on the new processes and automation. Others are concerned for their jobs. Still others have a stake in the existing ways – perhaps they were part of its development or a known expert on its use. Whatever the reasons, the fear of the future state can make elicitation difficult.

#3 – The time trap

Many of us are often under so much pressure that we don’t have time to dig deep. We gather some high-level requirements, but we don’t have time to uncover the expectations. And even if we have time, which is rare, many of our stakeholders don’t. Many are available for an initial set of sessions, but interest wanes as the difficult detailed meetings drag on.

So, what can we do? Here are 3 tips for successful elicitation.

Tips for Successful Elicitation

Tip #1 – Use a variety of elicitation techniques

The first tip for uncovering expectations is to use a variety of elicitation techniques. That’s because each technique that we use uncovers a different aspect of the requirements. Here are some examples.

  • Process modeling. This has always been one of my favorite techniques. It documents how people get their jobs done. But as with all elicitation, it’s not easy. For example, one of the most difficult aspects about process requirements is that stakeholders argue over where to begin and where to end and how the processes fit together. Using different process models helps avoid this contention. SIPOCS (suppliers, inputs, process, outputs, customers) help narrow the scope of each model and swim lane diagrams help visualize how the processes fit together.
  • Data modeling. Process modeling is great, but people need information to get their work done. Data modeling helps us figure out what information supports each process step. It also provides business rules and is invaluable on our AI initiatives.
  • Use cases. These models help us understand how our stakeholders want to use the final product. They provide not only the scope, but all the functionality of the solution. And use cases, if completed thoroughly, turn into test cases.
  • Prototypes show what the final solution will look like.
  • Brainstorming yields the power of the group, while one-on-ones often reveal what stakeholders really think.

Tip #2 – Ask context questions

A context question is one that surrounds the solution that we’re building. While we do need to ask questions about the  solution’s features and functions, such questions do not provide the complete picture.

I like to group context questions into four categories of questions:

  1. These questions relate to what’s happening outside the organization and include questions like demographics, language, weather, technology, and compliance/regulatory. These may or may not apply to the project. If they do, we need to understand their effect on our work.
  2. These pertain to how ready the organization is to accept the final product. The bigger the change, the more issues there usually are. We need to know, for example, which stakeholders will be on board, which will resist the change, and what needs to be done to prepare the organization for the change.
  3. We need to ensure that the business problem we’re solving and the proposed solution align with the organization’s goals and objectives.
  4. These context questions are usually those about the current state.

Tip #3 – Know when to use open-ended, closed-ended, and leading questions

Open-ended questions allow the respondents to expand their thoughts. We ask open-ended questions any time we want to learn more. For example, we ask these questions when we’re just beginning an effort, during brainstorming, and when we need to get all the issues out on the table, etc.

Closed-ended questions are forced-choice questions. They have the answers embedded in the question itself, sometimes explicitly as in a survey question, or implicitly. I like to ask closed-ended questions when stakeholders are all over the board and we need them to focus. For example, given all these issues we’ve identified, if you had to choose 10, which would they be?

Leading questions are not questions at all. They sound like questions, but they’re really our opinions stated in the form of a question. “This is a pretty cool feature, isn’t it?” My least favorite leading question is one we often hear: “Have you ever thought about…solution.” Again, it’s not a question. It’s us presenting our opinion rather than asking what our stakeholders think. What’s wrong with that? Remember we’re in the middle of elicitation, which is about learning. Presenting our solutions during elicitation cuts off exploration because we’re telling rather than learning. Later, after we’ve completed elicitation and analysis, whether it’s for the whole project or a smaller part, we can make a thoughtful recommendation.

To summarize, effective elicitation is critical to the development of a final product that our stakeholders are happy with. Elicitation is not easy. There are several pitfalls which are difficult to overcome. But if we follow the tips provided in this article, we will deliver a product that our stakeholders actually like and want to use.

[i] I use the terms solution, final product, and end product synonymously. It’s the solution to the business problem we’re solving. It’s also the product or product increment being produced at the end of the project, project phase, or iteration.

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.

Meeting Expectations When It Comes to Meetings

Meetings. The conglomerated work effort to bring about the grouping of individuals to converse and discuss topics of relatable interest at a given point of time. In mere words, meetings are one of the several crutches of work in business analysis that endeavors to accomplishing our goals. Whether you relish them or dread them, meetings are compulsory. Open your calendars and assuredly you will see on a daily or weekly basis that you have a concentrated number of meetings spanning numerous projects. Or, if you are one of the lucky ones, your meetings can be far and few in between. My personal record in the marathon of meetings has been eight meetings in a workday, all different, varying projects and spanning four hours of the day. When I converse with people outside of work and inform them of my longwinded hours of speaking or listening in on meetings, they give me an incredulous look and with care: “How do you get any work done?”

Some of us may admit that we have faced this question and own to some self-truth: we may not be wholly paying attention to the meeting. Answering emails, preparing for the next meeting; perhaps, you stepped out for a quick cup of coffee, with the camera off as a preventive measure. In the virtual world that we found ourselves transitioned to by the public health pandemic that is COVID-19, it has allowed ourselves to grant meeting liberties we would not possess if we were meeting in the office. However, authentically, we should be setting our expectations and meeting them when it comes to these meetings to effectively achieve our objectives. So, when I was posed with this question, I took some time to reflect, and born was this article. How do we meet our expectations when it comes to meetings to make them effective and to get “work done”? For myself, it has become a set of principles to follow as a guideline when it comes to these sessions. These fall into timing, focusing, documenting, and communicating.


Advertisement

There are only so many hours in the working week that we can accomplish what we want to, and it never feels like there is enough time. Meetings can be an impairment to our limited time in the week, miring our stacked to-do list. However, it does not always have to be this way! The first tenet to the meetings is to appropriately time them. Timing with effectiveness is everything when it comes to the foundation of a meeting. Consider, when scheduling one, an honest effort of how much time the meeting should take. If you know it will take an hour, schedule an hour, persist to keeping to an hour, and be pleasantly surprised if your meeting is shorter than anticipated! Timing effectively is not a skill learned overnight; nevertheless, it is one that can be continually improved upon through best practice.

Additionally, focus on meetings comes in two forms: preparation and execution. I have found that being prepared for meetings can strike chords in the efforts of delivering an effective meeting. Rudimentary in nature, necessary by necessity. Know your subject, what your objective is and how you are going to achieve said objective. Execution will then follow shortly thereafter; and keeping your meeting attendees focused is baked into this. Too often, “meeting creep” can set in and suddenly your hand is forced to reschedule or schedule more meetings to impair your effective timing. Avoid the divergence by preparation and keeping on track, for both yourself and attendees.

When it comes to documenting, a wise person in the IT realm when I had been in my secondary education, once told me to “document everything.” At the time, it made no sense. Now, it means truly that: responsibly document everything when it comes to meetings. Whether it be sharing your screen with a running document or the old-fashioned pen and paper, meeting minutes and notes are the core aspect to documenting the action items and deliverables in projects. It serves it’s purpose to be able to say who, when, where, what, why and how someone was able to do something in a project when it was documented during a meeting of said project. One does not, nor must not, transcribe every word; yet glean a holistic enough perspective to highlight the key points with enough information for reference.

The tried-and-true adage that “communication is key,” is not just for relationships in our personal and professional lives. It is true for meetings. The ability to communicate with transparency and effectually is the last rounded effort of the lexicon that promotes a synergized meeting. Go back to your preparation and execution from the “focus” principle and translate that into the communication you are delivering. Instead of meager words forming together sentences that might satisfactorily achieve the objective, aim for the exceeding and deliver on what your best work is each time, and your meetings will thank you.

Meetings. The word may forever be ingrained into our brains as a hallowed term in the business analysis field or ring us full of trepidation. Yet, if we remind ourselves of the tenets homed in on this article, we may find that meetings are not as tripe and dismaying as they are. They are a major source of our work and should be treated no differently than any of our other aspects of efforts. We hold ourselves accountable for the work we deliver as business analysts and the work outputs of meetings are equivalent. Spend the little amount of time it takes to accomplish these items, in no order, and experiment with how much more you can further your meetings. You may find that your work is completed in a timely, or even early, fashion.