Skip to main content

Tag: Communication

Best of BATimes: How to Facilitate Successful Process Mapping Sessions

Process mapping is often the first step in business process improvement. It is a necessary activity that provides a baseline from which improvements can be measured and is the key to identifying and localizing opportunities for improvement. Therefore, it is important that facilitators capture the right information to help steer process improvement initiatives in the right direction.

 

To have successful mapping sessions, facilitators must possess the ability to lead (steer the direction of meetings), manage people (deal with conflicts and diversions), and persuade participants to open up and share the knowledge they possess.

This can be challenging when dealing with large groups and complicated processes. To help to ensure that you have a successful process mapping session, follow the guidelines outlined below.

 

Be Aware of Scope Creep

Off-topic or side conversations can lead to the kind of scope creep that takes time away from the original goals set for the meeting. It can also lead to the capture of irrelevant data. It is easy to get off topic in any meeting. When conducting process mapping sessions, additional challenges exist.

Mapping sessions are designed to bring SMEs and various groups together to document how tasks are performed. However, these sessions often serve as a learning experience revealing for the first time details about a process and its challenges. Because each participant may have a different level of understanding about the process, this can contribute to extended discussions about issues. These discussions can be enlightening and sometimes necessary, but can also get the meeting off-topic. For example, let’s say group A is using a manual process to calculate input for a step and it is revealed that group B is utilizing a tool that could be implemented by group A. This tool could eliminate the need for the manual process. This, of course, sparks an interest for group A and leads to a discussion about the tool rather than the overall purpose for the meeting. These types of side or off-topic conversations often happen as process issues are revealed. The facilitator must have the ability to put a time limit on these discussions and be able to determine the difference between relevant and irrelevant conversation to protect the goals of the meeting. Remember, process mapping sessions are not for solving problems – they are for the purpose of identifying and documenting potential problems.

 

Mapping sessions can also get off topic by the compulsion of participants to document processes as they “should be” and not how they exist in its current state. Mapping sessions typically begin by documenting the “As Is” or “Current State” process to identify opportunities for improvement and then end in the design of the “To Be” or “Future State” process after teams solve problems. Although it is a great sign when participants recognize during meetings better ways to do things, it is counterproductive to prematurely document the “Future State” before establishing a baseline for the improvement effort. It is the job of the facilitator to identify when this shift occurs and get back on course.

 

Capture the Right Amount of Information

As a facilitator you must be able to determine the right level of information to capture. Whether you are capturing too much or too little information – both extremes can be a waste of time and not address the overall purpose of the project.

Process mapping standards identify Level 0 or the steps identified in a SIPOC as the starting point for most mapping efforts. SIPOCs (Supplier, Input, Process, Outputs, Customers) are used to identify roles, inputs and outputs and high-level steps of a process. (To learn more about SIPOCs see the article “The Four Agreements You Need to Have a Successful Process Mapping Session”)

It is best to start with a high-level map (Level 0) and identify what topics need to be fleshed out from there. Additional levels can be mapped accordingly (see Figure 1). The various levels can be described as follows:

  • Level 0 – high-level core steps of a process listed in six steps or less.
  • Level 1 – drills down from the core steps and describes the steps involved in a process at the next level.
  • Level 2 – describes the step-by-step details of a process.

You may need to drill-down further to uncover bottlenecks and inefficiencies of a process, but it is important to get input from SMEs about relevancy of the data being captured and regularly compare project goals against your process mapping efforts to help make sure that you are steering the meetings in the right direction.

gaillard July21 1Figure 1 – Levels of Process Maps

 

Make Sure the Right People Are In the Room and/or Available For Participation

There is nothing like being in the middle of a successful mapping session that suddenly stalls because no one in the room knows exactly what happens in the next step! If this situation occurs, you simply do not have all the right people in the room. The SIPOC reveals your suppliers and customers or those representative groups that should be in the meeting. However, sometimes the right individuals are not chosen to participate. Instead, managers and/or process owners are chosen to represent departments when actual processors should be in the room or available for contact during the meetings. Often sponsors are reluctant to release critical resources from core work, but it is well worth it to lobby with sponsors to provide the proper representation for the mapping session to capture information correctly.

 

Advertisement

 

Proactively Address Conflict

Business professionals who attend meetings regularly have first-hand knowledge of how unproductive meetings can be when attendees are disruptive. Conflict that exists between individuals, departments and/or organizations can make its way into your process mapping session and prevent you from capturing critical details of a process or impede progress.

It’s important to uncover potential problems that may arise during a mapping session and proactively respond prior to the meeting. How can you prepare for these types of challenges before the meeting? Implement tools from change management principles and conduct a simple/modified risk or change readiness assessment prior to the session. Knowing beforehand the challenges groups face with their processes and/or between groups will help you prepare a response and manage behaviors in the meetings.

Here are five important things you should know prior to a meeting. Ask these questions of each sponsor and/or process owner:

  1. Do you support this initiative?
  2. What concerns, if any exist about this effort?
  3. Do your SMEs have the time and energy to participate in this effort?
  4. Are SMEs motivated to participate in the mapping activities?
  5. Do you have good relationships/rapport with external groups that will enable your team to work efficiently during the mapping sessions?

If conflict exists, it is best to deal with it openly and honestly. Start with the sponsors. Reiterate the overall project goals, restate the purpose and stay passionately neutral during the process. Taking a side will cause other sides to shut down and you will lose engagement immediately preventing the accurate capture of data. Transparency about the process and having courage to address problems will allow facilitators to meet the goals of the mapping session.

 

Structure Meetings to Have the Least Impact on SMEs and Groups

Process mapping sessions that are lengthy and continuous can lead to waning support. There are a few ways to construct meetings to keep participants engaged. Facilitators can hold “Cross-functional Meetings” or “Functional Meetings”. Each type has its pros and cons, but each can address issues surrounding participant engagement.

  • Cross-functional Meetings – this type of meeting gathers all teams from across functions to participate in the same full or half day workshops to map out processes.
  • Functional Meetings – allows functional groups to gather independently to map processes related to the functions they perform. If there are six groups involved in a process, six separate meetings will be held to capture the processes of each function. The individual functional maps are consolidated to create one overall map of the process and then presented at a review meeting where all SMEs and groups will gather to review and approve the final process map.

See Figure 2 for the pros and cons of each meeting type.

gaillard July21 2

In summary, strong facilitation is the key to holding successful process mapping sessions. But the real measure of success is how effectively the data captured is utilized in the overall process improvement initiative. If the identification of problems using process maps leads to lasting change that reduces costs and increases profits – you held a successful mapping session. And in that case, congratulations!

 

Published: 2015/07/15

 

The Tyranny of the Algorithm

A while ago, I noticed that some people changed the way that they were writing LinkedIn posts. Rather than writing in sentences and paragraphs, everything would be written in this weird separated way with everything spaced out in a really unnatural way.  Then certain other common patterns appeared (e.g. using PDFs documents with multiple pages, or ‘carousels’ as some people call them).  Video was huge, then not huge, and so the trends fluctuated.  Some of the formats seemed really good and useful… others… not so much (we’ve probably all clicked on the occasional ‘click bait’ LinkedIn post…).

I gather one of the reasons that people post in particular ways is to get maximum exposure, and to do this you have to pander to the algorithm.  It is, after all, the algorithm that will decide how many people see your post…  and not all posts are created equal.  Those that get more ‘engagement’ will be seen by more people (and, very likely, get even more engagement).  Yet the algorithm decides what counts as ‘engagement’.

There’s nothing inherently wrong with this. LinkedIn is a private enterprise, it can (I suppose) run its operations however it chooses. But take a step back for a moment, and let’s make a hypothesis here:

 

The algorithm has changed the way people write content and interact with others on LinkedIn

I’m making no moral judgment here, and the way that people write and engage with each other has adapted over the years. But let’s follow this to its logical conclusion: social media algorithms have the ability to influence the style and formats in which people communicate. It decides what content gets seen (and doesn’t get seen). Again, as users we might be OK with that. But I hope that there is someone within those companies asking a whole set of ethical questions…

 

Avoiding Biases and Unintended Consequences

In particular, it’s important to consider whether algorithms might lead to bias, and might inadvertently disadvantage or affect particular groups or stakeholders, or whether they might have other types of unintended consequences. For example, I’d imagine that the LinkedIn algorithm probably aims to keep people on the site for as long as possible, and serve them up relevant adverts. But when people learn its nuances, they start to ‘game’ the algorithm, meaning that some folks are more likely to get their content seen than others. Presumably, LinkedIn eventually learns about this too, and adapts the algorithm, and the process repeats.

 

Yet unintended consequences like this aren’t limited to IT or algorithms. Nor are biases  (there are plenty of well-documented cognitive biases that affect people too). Crucially this is an area where BAs can help ask some of the difficult questions, and get beyond (or at least highlight) potential issues.

 

I have often thought it interesting that within most organizations, if you ask the question “who is responsible for regulatory compliance” you will get a clear cut answer. There is usually a legal or compliance team, and often a named individual who is responsible and accountable. Ask “who is responsible for the ethics of this product or project?” and (outside of some very specific domains) you’ll likely get a blank stare. Or, you’ll get a word-soup answer that boils down to “we’re all responsible”.  And when everyone is responsible, too often nobody steps up to ask the hard questions.

 

Advertisement

 

The Ethical Imperative

This is a space where BAs can add significant value. As BAs we’ll be used to conducting stakeholder analysis, thinking in terms of the different stakeholders or personas who will be impacted by a particular proposal. We can extend this thinking by asking “who isn’t here around the table, who is missing from these conversations, and how can we ensure they are represented?”.

We can ask the difficult, but important ethical questions, and ensure that the projects and products that are progressed by the organization are in line not only with its strategy but also its values. If there’s a strategy-execution divide in many organizations, that’s nothing compared to the values-execution divide! (We’ve probably all had experiences with organizations that say they ‘put the customer at the heart of what they do’ that… definitely don’t actually do that!).

 

Often, as BAs, we are able to take a step and ask “what is the impact of this”, and “what does success look like for X stakeholder group?” and “how does that vary from what the Y stakeholder group thinks?”.  By taking a holistic view, balancing different viewpoints and putting an ethical lens on things, we can hopefully reduce the risk of inadvertently introducing bias or unintended consequences.

This involves us having the courage to ask bold questions and keep ethics firmly in mind. If we don’t, there’s a real danger that the ethical dimension will get missed. A situation that I’m sure we’re all keen to avoid!

Avoid The “Saying/Doing” Gap

Elicitation is a core part of business analysis, and there are a vast array of elicitation techniques at a BA’s disposal. However, if you’re like me (and most BAs) you probably have a few favorite techniques that you gravitate towards. For me, I’ll often start with interviews and workshops, using document analysis to gain context and perhaps some observation to see how things really work.

 

While it’s completely natural to have frequently-used techniques, it’s important not to forget that other elicitation techniques exist. It is very easy to fall into a rhythm of reverting to a particular set of techniques irrespective of the context, project or situation being examined. This could lead to a situation where other techniques might have proved more efficient or effective. In particular, it’s important to use an appropriately varied set of techniques to avoid the ‘saying/doing’ gap…

 

People Often Do Things Differently In Reality

As any experienced BA will tell you, asking someone to describe how they do their work will often give you a very different result to going and seeing them do their work. There are often parts of the process that are so obvious to the people undertaking the work that they don’t even think about mentioning them. Imagine if someone asked you to describe the act of driving a car… you might explain the steps of opening the car door, putting the key in the ignition, checking mirrors and accelerating away. You probably wouldn’t mention putting on a seatbelt, or closing the door… but these are things that are very important! If we are wanting to understand an as-is process, we’ll often want to understand those ‘seatbelt’ moments too.

 

There’s also the tricky subject of exceptions and unofficial workarounds. Sometimes there will be exceptions that the designed process never really catered for, so workarounds have emerged. These workarounds might not be documented anywhere, or if they are documented they might be documented in an informal way. Knowing about these workarounds (and the exceptions that cause them) is important too—any new process really ought to cater for these situations without a workaround being necessary.

 

All of this points towards the need for a mixture of elicitation techniques.

 

Advertisement

 

Use a Mixture of Elicitation Techniques

Interviews and workshops are excellent techniques for understanding stakeholders’ perspectives on a situation and asking probing questions. Yet if we are going to gain a broader understanding of the situation, it’s important to mix and match our techniques. There are also some techniques that might not traditionally be thought of as elicitation techniques that can be brought into the mix too.

 

Here are just a few examples for consideration:

 

  • Analysis of Reports, Data & MI: What does the data show you about the process? When are the peaks? How many queries go unanswered? What are the most common queries from customers? Why are those the most common queries? What are the uncommon situations that might be causing exceptions or problems?
  • Observation, Sampling & Surveys: Observing colleagues undertaking their work can help us understand how the work really works, but requires a good level of rapport (else people might revert to the ‘official’ process rather than what they actually do). It isn’t always possible to do this, so sampling can be useful. In a call center where calls are recorded, if (with the relevant legal permissions) you can gain access to call recordings, you can potentially sample elements of a process and see how things are done. Or, you might issue a survey to the relevant customers or internal stakeholders. Sometimes giving people some time to reflect (rather than asking for an instant response in a one-on-one interview) can be useful.
  • Document analysis: A very broad technique, but looking at things like process models, procedures, exception reports and so on can prove useful. Of course, there is often a gap between how a process is written and how it is actually executed, but documentation is a good starting point.
  • Correspondence or sentiment analysis: This is really a particular type of document analysis, but if you are looking to improve a customer-facing process, why not look at some of the correspondence that customers have written about it? What do they like and dislike? Look at complaint logs, which elements are they complaining about? After all, complaints are a potential source of innovation, when they are filtered and used as input to process improvement. If your company has a social media team, perhaps they are capturing suggestions that have been submitted via these channels also.

 

Of course there are many other elicitation techniques too, these are just a few examples. But crucially, initiatives usually benefit from a mixture of elicitation techniques, some of which require synchronous stakeholder input, some of which require asynchronous stakeholder input (and therefore gives reflection time), and some of which initially don’t require stakeholder input at all (e.g. document analysis).

 

With a breadth of elicitation techniques, we gain a broad understanding of the current situation (and future needs). This helps ensure we deliver a valuable solution to our stakeholders.

 

Best of BATimes: Business Analyst vs. Business Analytics Professional: What’s the Difference?

A business analyst and a business analytics professional are not the same. Very often, people get confused about these 2 terms.

 

Many times, they are used interchangeably. Few start-ups and organizations also seek out a business analyst when they are actually in search of a business analytics professional. Among the analytics enthusiasts who are searching for a job in business analytics, this causes huge confusion. So, it would be better if the difference between a business analyst and a business analytics professional is well-known.

 

Who is a business analyst?

As defined by IIBA(International Institute of Business Analysis), the business analysis is a discipline of determining the business needs and identifying the solutions to business problems.

A business analyst coordinates between a client and the technical team. A client can be either the internal team that is required to work with the technical team or external, with the requirements to solve a particular problem. The technical team has the ability to either deliver a service or build a product.

The business analyst makes sure that the service or product provided by the technical team meets the client’s present requirements. He/she collaborates with the external and internal stakeholders in the implementation as well as design of the service or product.

 

Who is a business analytics professional?

A business analyst doesn’t work with data and is mostly concerned about processes and functions. On the contrary, reporting and data are the key components of a business analytics professional’s job.

Let us consider 3 major elements that help us in understanding the difference between a business analyst and a business analytics professional.

 

Analytical problem solving skills

The business analysts utilize different techniques to analyze the problem and determine the solution. They conduct thorough analysis and deconstruct the solution or problem by making use of various methods. Few examples of this include decision models, business process models and use cases.

On the other hand, business analytics executives use logical thinking, predictive analytics and statistics to solve the business problems.

Let us consider 2 examples that state the way in which the business analytics executives solve the business problems.

  • If a continuous stream of loan applications are being received by a particular bank, the business analytics professional will develop and implement a model to give a recommendation on which loan applications that bank must lend to.
  • From a catalogue launch, if a manufacturer of home-goods wants to predict the expected profits, a framework will be applied by the business analytics executive to work on the problem and develop a predictive model to provide recommendation and results.

 

Advertisement

 

The capability to tell story with data

The business analytics professionals must be in a position to share the insights they derive from raw data. They must share the insights in a way that is clearly understandable to the end stake holder as most of the times, the end stakeholder will be a non-technical and/or business-centric person. They shouldn’t use technical jargons while communicating and must present the insights in the simplest possible way. The stakeholder can be an internal or external client. Most of the times, they are business professionals with zero technical background and the authority to take decisions rests with them. The business analytics professionals are very good story tellers and they make use of advanced tools like Ds.js, R and Tableau to share their findings or story to the end stakeholders.

On the other hand, the business analysts are good communicators and they make use of excel, word and PowerPoint to create visual models like wireframe prototypes or work-flow diagrams. They are also good at creating technical documentations. But, they don’t develop custom dashboards making use of modern data visualization tools like business analytics executives do.

 

Programming skills

A business analytics professional works with structured data and utilizes SQL in order to retrieve data from databases. He/she will write SQL queries to analyze and extract data from the transactions database and develop a set of visualizations if the management requires some advanced metrics about their company.

The analytics professional will also have a good expertise on the data science programming languages like Python, Julia, Hadoop and so on. He/she is good at visualizing, analyzing and manipulating data.

A business analyst, on the other hand, has nothing to do with data. Their focus is more on the functions and processes. The significant business analyst value propositions incorporate the calibration and testing, IT re-engineering, process, model requirements, KPIs(Key Performance Indicators), vital pain points, context and business value maps. A business analyst possesses strong knowledge in development frameworks such as SLDC. He/she makes use of Excel to perform quantitative calculations and analysis. The programming skills are not used by the business analysts to perform calculations.

 

Conclusion

It is evident from the above that both these functions are extremely important for a successful business model. From the business decisions it automates as well as enables, the value of analytics can be derived. Every time, a business analyst will first begin with the business questions but not with data. They are also the domain experts who manage the project from the beginning till the end.

On the other hand, a business analytics professional begins to solve the business problem making use of data first. He/she cares about the retrieval of data, format of data and source of data. Data is the raw material for a business analytics professional.

A business analytics professional and a business analyst work closely to make sure the final project is delivered successfully. This explains the difference between a business analyst and a business analytics professional.

 

Posted on: 2017/12/27

Deconstructing the Stress Factors in the Business Analyst Role

Over my years as a professional, I have come to realize that the title of Business Analyst (BA) is a heavy one. How each organization defines the role can be completely different. A BA in Company C may be a requirements scribe, whereas a BA in Company D wears many hats: process analyst, project manager proxy, test validator, etc. Whichever way the role is defined, I think stress has plagued many of us who call Business Analysis our profession. If you have found yourself feeling anxious or overwhelmed at any point during your career in business analysis, you are not alone. There are many factors that can play into that feeling. I want to deconstruct a few of the typical stressors here and offer some potential solutions.

 

1. Not understanding the area of study:

BAs are often on the fringes of the business. It is analogous to being a window cleaner.  As each pane gets cleaned, we can see a little more into the room in front of us, but we are still only seeing a portion. Each pane reveals a bit more about the room, but the entire picture may still elude us. We are on the outside looking in. Not having the full picture of the business, its processes, or its business drivers can leave a Business Analyst feeling inadequate and uninformed.

As a BA, questions are your friend (like your squeegee on the dirty window). I have been guilty of feeling like I was asking too many questions. What I realized is that if I don’t ask my second follow-up question, which may lead to a third follow-up question, I risk not gaining the knowledge that I need to understand the business to write better requirements.

Feeling anxious because we don’t know the business is stressful, but not asking enough questions to get the understanding we need will cause more stress later. If you have 100 questions, don’t stop at number 99. Ask all 100. If you find that the participants are getting a little impatient with your questions, gently remind them that you are trying to understand them as an outsider looking in. Once you gain a better understanding, your perspective changes, and you are no longer looking through smudged windowpanes.

 

2. Large complex projects:

If you have been on projects with multiple stakeholders, then you may feel pressure before you even type the ‘r’ in requirements. It can be daunting to start a new project. You may be working in a new department with all new faces. Unfamiliarity coupled with complexity can be intimidating. In instances like this, it is important to build alliances.

Find project team members that you can trust. Relationship building is so important to your success as a BA and will also go a long way in helping alleviate some of your stress. It can be nice to have a friend when you are on the fringes.

 

Advertisement

 

3. Requirement Elicitation is not one size fits all:

For those who do not practice Business analysis, gathering requirements may seem like a simple task. You find out the need, and you write it down. It is not at all that simple. Different stakeholders require different elicitation methods. Some stakeholders are very forthcoming with information. Others can be more guarded or may simply not know how to express the need. Interviewing may work for some. Passing e-mails back and forth may be more appropriate for others.

The key here is to really take the pulse of your stakeholder population (a personality assessment of sorts). Understand their optimal mode of communication and how you can best work within the confines of that. Also, do not neglect your best mode of working as well. Finding the proper balance between stakeholder and BA methods of working will be key to helping alleviate stress.

Do not feel pressured to use an elicitation technique that is not a good fit. We do not want to simply check boxes on the list of deliverables; we want to add true value.

 

4. Feeling pressured by deadlines:

Every project comes with a start and end date. BAs often occupy a few task lines on that project schedule, and the pressure to meet those deadlines can feel immense. We don’t want to be the ripple that causes the project timeline to shift.

As BAs, we often take the deadlines given to us and work to fit within them. If we do not understand the business, the project is complex, and we don’t know what elicitation method to use when starting a project, then how can we be tied to a deadline?

Speak up when you feel that timelines are not realistic. Open and honest conversations can be uncomfortable but can also be wholly necessary when the quality of work is on the line. The timeline may not shift because you raised a concern, but I guarantee you will feel a little less pressure when you have been open and honest and raised your hand.

 

This is not an exhaustive list; it is just some of the key things I noticed in my career as a previously stressed and anxious BA. In the end, it is important to remember that your success as a Business Analyst rests in part on your ability to perform the job well. Different stress factors can become obstacles to your performance. Understanding those factors is the first step in tackling them. Apply different techniques to alleviate the stress. You will thank yourself.