Skip to main content

Author: Sarah Mullen

Sarah Mullen, MBA, CBAP is a Senior Business Analyst in the hospitality industry. Her career started in Operations before moving into Business Analysis and Product Management. She has over 13 years of experience as a BA and is currently working to learn more about Strategic Business Analysis. Her profile is available on LinkedIn.

The Three Cs of Business Analysis

Recently I returned to work from an extended leave and was immediately thrown into the deep end of the pool with an assignment on the next phase of a major project. There was hardly time to get my bearings before needing to elicit requirements and write user stories, much less be able to understand how the product owners want the product to function. As a result of my rapid reintroduction to the project, I came to quickly appreciate the Three Cs of Business Analysis: Connection, Communication, and Collaboration.

1. Connection

Building connections is one of the most important things a business analyst can do. Forming relationships with stakeholders, development and QA teams, product owners, and many other individuals is vital to reaching a good output. I had the benefit of previously working with many of the same individuals, which made it much easier to jump back in quickly, as I already had those established relationships. However, for those individuals with whom I had never worked, the lack of time to build those connections has made it more challenging to understand their processes and how I can contribute to help them perform their jobs more effectively.


Obviously, the longer you are with a company, the more time you have had to establish and strengthen connections with those stakeholders around you. Even something as simple as a quick chat in the breakroom or reaching out with a simple question goes a long way in deepening those relationships, which makes life much easier when you need to work with those individuals on a project. Connections are resources of information, and the more resources you have, the easier it is to obtain information when you need it.


2. Communication

Whether you have good relationships or are just getting to know your stakeholders, establishing good communication practices is a top priority. Each stakeholder may prefer to receive communication via different methods, so understanding the best way to communicate questions or information with each individual is something that should be established early in your relationship. Some stakeholders prefer email, some do better with IM, others need direct communication via a meeting; and if you attempt to communicate with someone in a less-than-desirable method, there may be delays in obtaining the needed information. I have dealt with product owners who rarely respond to emails but will respond to an IM within an hour; I have also known other stakeholders who are the exact opposite.


In my case, since I had previously worked with many of those stakeholders, I already had a good idea of how best to collaborate. This made it much easier to quickly jump back in and get the answers I needed to my questions. For those individuals with whom I had never worked, we’re honestly still figuring it out. Obviously, whether you are co-located also makes a big difference in establishing relationships and best practices for how to communicate. Being able to walk to someone’s desk vs having to send a meeting invite does matter and can make it more challenging to get started.




3. Collaboration

The third C is what completes the circle…collaboration. We can build connections and learn how to communicate with those individuals, but it will all be for naught unless we collaborate. The Webster’s definition of collaboration is simple but explains exactly what we need to do: “To work jointly with others or together especially in an intellectual endeavor.” As business analysts, our job is to bring stakeholders and team members together, which means we must be the bridge that allows all interested parties to be part of the discussion. Now, what that looks like in reality can mean many different things depending on the scenario. It could look like:

  • A requirements elicitation session with stakeholders
  • Working with UX designers and product managers to understand how the design will allow the requirements to be met
  • Meeting with developers/testers to review stories and understand the level of effort
  • Reviewing the level of effort with product owners to determine priorities


Being part of the collaboration discussion with stakeholders on a project, as well as simply facilitating the discussion so various stakeholders can collaborate amongst themselves, are both tasks we perform as business analysts. If decisions are made in a silo without that collaboration, the result can be missed requirements, incorrect implementation, and dissatisfied clients. We must collaborate in order to understand the big picture and how requirements fit within the design and how the implementation functions, so we can ensure the client receives the intended outcome.


Forming connections, establishing good communication practices, and collaborating with all individuals involved in a project are three of the key pieces to building a successful product. They also make it much easier to float when you’re thrown into the deep end of the pool on an inflight project!

When “Solutioners” are the Decision Makers

Have you thought about X? What about if Y happens? Are you sure that approach will solve Z?

These are all questions that business analysts should ask daily. However, one of the biggest challenges we face is when the decision maker for a project is a solutioner. While “solutioner” is a term one of my teammates recently coined, I feel that it is completely appropriate to define someone who has a desired solution already planned, and stated, before we’ve even had a chance to start analysis.

The IIBA defines business analysis as “the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders.” This means that for a business analyst to truly conduct business analysis, we need to start with the problem or need, not the solution.

I’ve lost count of how many times I’ve been given an assignment, told what the solution is going to be (e.g. build a new application or product), and then told to do business analysis. How am I supposed to define needs and recommend solutions if you’ve already decided what we’re going to do? It’s frustrating to say the least. Understanding the real problem that needs solving and how stakeholders, processes, or products are impacted makes it much easier to find a solution that will actually solve that problem, rather than just putting a band-aid on the symptom.

Unfortunately, there is no one-size-fits-all approach for how to handle the problem of not understanding the problem. A lot depends on your relationships with the decision maker and other stakeholders or team members, your level of experience, the urgency of the initiative, and many other variables. However, there are some key Do’s and Don’ts that can help in your endeavor to get to the root of the issue:


  1. DO develop relationships! I cannot stress this enough. The better relationships you have with key stakeholders and decision makers, the easier it is to convince them to let you do your job of analyzing the situation, rather than going straight into to developing the suggested solution. Having good relationships with decision makers also means you know what you’re getting into from the start. If I know going into a project which stakeholders are going to be pushing for a specific solution vs. those who are more open-minded, I can frame my initial questions and discussion points with that in mind in order to steer us down the path of problem solving rather than solutioning.
  2. DON’T forget about the users who do the work. Quite often, the decision maker is not the actual end user of the application or product. This can mean that a decision to change a process or application can make things worse for the user who does the work every day. By understanding what the end user is doing, why they do it, and what their challenges are, it can be easier to explain to the decision maker why they may want to spend the effort to understand the true problem.
  3. DO move forward with root cause analysis. It’s a BA’s job to conduct a root cause analysis and understand current state, so by moving forward with that analysis you are only doing what you’re supposed to do. Even if you have to spend extra time conducting analysis while also eliciting requirements, it will be worth it in the end because you will have a better understanding of the problems users face, even if the decision maker chooses what you feel to be a less than optimal solution.
  4. DON’T be afraid to push back. If you are being pressured to document requirements or write user stories before you feel the proper level of analysis has been done, then don’t be afraid to say so. Obviously be respectful, but it is okay to say no if you feel it is the correct response. However, be prepared to back up your argument and try to provide estimates for the remainder of your work, if possible. As analysts, we should be comfortable with seeing all sides of an issue and understanding when to raise a flag when we see a problem. Which brings me to my last point:
  5. DO bring the facts and ask! Explain to stakeholders what your role is as a business analyst, and how you can bring value to the project by understanding current problems and how they impact various roles or applications. Stakeholders or decision makers don’t always understand what a BA can do, so sometimes you can get what you need by simply explaining your process and how you can help. Tell them what you intend to do, when you intend to do it, and pledge to provide status updates as you go. By providing updates about what you’ve learned and giving alternative solutions to the problem, and you may just be able to persuade the solutioner to find a different solution, or even confirm that the original solution is still the best route to take.

Ultimately, convincing a solutioner to choose a different solution comes down to your relationship (or lack thereof) with that person and understanding how to use your instinct and expertise about the problem to know how far to push. Those are factors that get easier with more experience and longevity with your organization. But in the end, don’t be afraid to speak up and educate those decision makers in the value of analysis and understanding the true business needs; you just may be able to turn a “solutioner” into a “problem solver.”