Skip to main content

Tag: Communication

Turn your specifications into living, digital documentation

Written by Line Karkov on . Posted in Articles.

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

Written by Elizabeth Larson on . Posted in Articles.

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

Written by Divya Kishore on . Posted in Articles.

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

Written by Jake Thompson on . Posted in Articles.

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.

Analyse Your Stakeholders

Written by Richard Larson on . Posted in Articles.

As a business analyst, aren’t you a bit like a translator? Your job is not just to interpret data, but to interpret it from the perspective of a businessperson and for the good of a specific business project. You are the middleman between sets of data and stakeholders in a business, and no matter what their educational backgrounds may be, those stakeholders are relying on you to deliver information that they can use to inform their next move. It’s up to you to communicate what might be rather abstract information in a meaningful, relevant way. Remember that word — communication — because as a business analyst, you are a professional communicator.

If you want to be a great communicator, it’s of paramount importance that you understand your audience. Forget the numbers for a second. Think about your stakeholders. If your job is to communicate with them, then for you to perform your job properly, they’ve got to be able to communicate right back, and be comfortable doing so. That means you need to be able to share bad news and be capable of disappointing people gracefully. It also means they need to be able to take that bad news and that disappointment, so they can work with it and mold it into success. Without honesty and transparency, your title isn’t Business Analyst. It’s Yes Man. There’s a time and place for Yes Men, but this isn’t it.

Speaking of titles, let’s set those aside. Your stakeholders may be your employers, but they’re also people. Shocking, right? Just like you, they will feel much more confident communicating with someone they feel a connection to. So to prime yourself for a successful project cycle, be sure to know your stakeholders. Or, if you prefer, analyse them.

Advertisement

Qualities of a Stakeholder

Think about the ground-level qualities of your stakeholder. Where do they live? This is important because you may need to account for time zone differences. Which medium do they prefer for communication — email, phone, video conference, in-person, or even text? What’s their experience like? Get a feel for your stakeholder’s level of experience, both generally and in relation to the specifics of your assignment. Have they been involved in similar projects in the past, and, if so, are they keen to offer their own insights? Don’t assume every suit is a novice with money; they may very well be just as knowledgeable as you, but, for reasons you’re not paid to understand, they’d rather not do what you’re doing. All the better.

Then comes the business side of things. How formal is your stakeholder? Not everyone is into casual communication in the workplace, especially when it comes to inter-hierarchical communication. Yet some will be put off by a rigid presentation. You have to get a grip on the amount of formality expected from you, if for no other reason than the need for you to be taken seriously and be understood as a communicator. While you’re at it, try and pinpoint exactly what level of authority a stakeholder possesses. While you must always be respectful to your employer (and they should be the same), you have to have some understanding of which decisions can be made by whom, otherwise you might find yourself unsure of who to turn to when project-halting issues rear their heads.

There’s always a shot-caller. Don’t shy away from a quasi-Machiavellian approach. Recognize that, in any profit-seeking organization, some parties are less dispensable than others, whether it’s due to their social standing within a group, aggression and energy, or sheer ability as a money maker. Identify the shot-caller and determine how their requirements of you may differ from their peers.

Peripheral Qualities

With the formality and infrastructural concerns out of the way, try a little bit to get to know your stakeholders’ personalities. Think of these as qualities you wouldn’t talk openly about in a work email, but that would still help you in how you decide to deal with your stakeholders.

Sometimes, your job might shift from translator to mediator. It’s not really in the job description, but, at the end of the day, you might be the only one in the room who can bridge the gap not only between information and business decisions, but between all the different arbiters of those business decisions. Stakeholders don’t always get along with each other or see eye to eye, and even those with deep, time-honed business relationships will bicker — sometimes childishly. Don’t be afraid to step in and resolve some differences, appropriately of course, if it means consensus can be reached and the project can pick up and keep moving. Of course, to do this the right way, listen to the room and note the relationships you see. Just like you analyse individual stakeholders, try to analyse the group.

You’ll find, after some time working together, that you can identify if a stakeholder is able to act on their feet confidently or if they are the type to ruminate before making big decisions. Keep in mind which one you’re speaking to, because it will have no small effect on how you proceed. Plan ahead for situations where you might get a committed decision later, or even sooner, than you had hoped.

And finally, this one’s important in today’s global, interconnected business world: culture. You will likely find yourself dealing with people from all backgrounds. People from different countries, different religions, and different upbringings. If you’re working abroad and you’re the odd one out, get a feel for the customs and norms of the native culture. That’s Traveling 101, isn’t it? If your stakeholders can see you’ve made even a slight effort to participate in their culture, it will be much easier to develop mutual trust and willingness to understand and work with one another. At the very least, you may avoid saying something embarrassing.