We’ll begin our business analysis journey from the second stage of the scheme mentioned in the previous article — analyzing the current situation (AS IS). Why not start with planning? Because we’ll discuss business analysis planning at the end of the cycle, after we’ve covered all the typical stages — to avoid brain overload from too much unfamiliar terminology and processes.
So, we begin our magic by studying the AS IS — that is, “how things currently are” at the client’s side (the person or organization who is ready to pay us). Why do we do this? The answer is simple: to understand the reasons why the client is willing to invest money into the project. But again, why? They’re willing, so let them pay — we wouldn’t complain. Yes, that approach works and is used by many. But let’s recall any interaction we had with sellers (not counting, say, buying bread). Wasn’t it more valuable when the seller acted as a consultant, trying to understand what and why we were looking for, attempting to solve our problem rather than just blindly selling what we came for?
In IT development, this is even more critical — IT investments are often very large. Contractors get paid significant sums for their work, and mistakes in projects, especially strategic ones, can be costly and painful for the budget. Throughout the IT project, an “analyst-helper” (who strives to solve the client’s problems) is far more valuable than an “analyst-forwarder” (someone who just passes information from the client to the development team).
Important: Recall the message from the previous article — AS IS analysis, being part of strategy analysis/discovery, is relevant only when that phase is applicable to the project. Always check with your BA lead, project manager, or any other person who can outline the scope of your responsibilities and the role of business analysis on the project. Also, pay attention to the client’s reaction to the tasks you propose or try to perform — it’s possible the client doesn’t see the point in you digging deep as a consultant and doing anything beyond direct development (just as we don’t like sellers pushing unrelated conversations when we know exactly what we want to buy).
So, we begin our magic by studying the AS IS — that is, “how things currently are” at the client’s side (the person or organization who is ready to pay us). Why do we do this? The answer is simple: to understand the reasons why the client is willing to invest money into the project. But again, why? They’re willing, so let them pay — we wouldn’t complain. Yes, that approach works and is used by many. But let’s recall any interaction we had with sellers (not counting, say, buying bread). Wasn’t it more valuable when the seller acted as a consultant, trying to understand what and why we were looking for, attempting to solve our problem rather than just blindly selling what we came for?
In IT development, this is even more critical — IT investments are often very large. Contractors get paid significant sums for their work, and mistakes in projects, especially strategic ones, can be costly and painful for the budget. Throughout the IT project, an “analyst-helper” (who strives to solve the client’s problems) is far more valuable than an “analyst-forwarder” (someone who just passes information from the client to the development team).
Important: Recall the message from the previous article — AS IS analysis, being part of strategy analysis/discovery, is relevant only when that phase is applicable to the project. Always check with your BA lead, project manager, or any other person who can outline the scope of your responsibilities and the role of business analysis on the project. Also, pay attention to the client’s reaction to the tasks you propose or try to perform — it’s possible the client doesn’t see the point in you digging deep as a consultant and doing anything beyond direct development (just as we don’t like sellers pushing unrelated conversations when we know exactly what we want to buy).
Let’s put the goal of this stage into official language: the goal is to understand the client’s business needs and their context (the reasons, scale, impact, etc.).
Business Needs are the problems or opportunities the client has, which drive the change. Change is a term from BABOK and its Business Analysis Core Concept Model, meaning, roughly, the moves the client intends to make and is ready to finance. We, as contractors, help the client implement this change by delivering a solution that supports it.
Business Needs are the problems or opportunities the client has, which drive the change. Change is a term from BABOK and its Business Analysis Core Concept Model, meaning, roughly, the moves the client intends to make and is ready to finance. We, as contractors, help the client implement this change by delivering a solution that supports it.
Important points:
- Business needs are formulated as the needs of the client (whether an organization or an individual, depending on who approached us). These are not the needs of the market, or a specific user Bob, or other stakeholders, no matter how important they may be. It’s always the needs of the person or organization paying us.
- Business needs reflect the reasons behind what our team will eventually develop, improve, purchase, or configure. It’s important not to confuse client business needs with the needs of individual stakeholders. To avoid drowning in terminology, here’s an example: suppose we talk to a department head at the client’s company who struggles with controlling employee work. If we bluntly ask this person about their needs, they might give us two types of info: a) The company’s efficiency suffers due to insufficient employee control; b) The control process is inconvenient for the manager, who has to ask each employee about their daily work. The first sounds like the project’s core reason and motivation for investment, while the second is probably the manager’s personal pain, which we may also address later, but not at this stage or as a root cause of the project.
- Business needs are not requirements in the analyst’s information model. Requirements look to the future (TO BE) and concern the solution our team will deliver. At this stage, we’re not talking about solutions yet — it’s too early. Needs describe the current state (AS IS) and are expressed as problems or opportunities.
Examples of business needs:
- Ivan approached us wanting a personal website with info about himself and his career achievements. His business need, expressed as a problem he currently faces and seeks to solve, might be: insufficient awareness among his target audience about Ivan and how impressive he is.
- We have an internal automation project within our own company to develop an office lunch ordering system. The company’s business need as a client might be: loss of employee loyalty due to the lack of a convenient office dining system.
- A brilliant startup founder came to us with an idea to develop a new social network with unique features. The startup’s business need, expressed as an opportunity, could be: generating profit through paid features for users of the new social network.
- A non-IT example: in my business analysis course, I always try not to skip this stage and ask the client (i.e., the course buyer) about their business needs before purchase. Why do they need the course? If I get a response like “to acquire IT BA knowledge/skills for further employment as a junior BA in Belarus” (framed as an opportunity), I can confidently confirm that our online BA course is a good fit and proceed. If there are mismatches between business need and desired solution, I try to highlight that to ensure the client understands them. For example, do they only need theoretical knowledge? There’s a cheaper course focused on theory with minimal practice. Does BA mean working with data? That’s BI analytics, not analysis, and the course is not about that. Is it for mid/senior levels? Our course targets beginners, though it has some advanced features. Not in Belarus? Here are risks and variations in understanding what an IT BA is in different countries.
Now, what does it mean to “understand the context behind the needs”? It’s hardly enough when Ivan from the example above tells us simply: “insufficient awareness of the target audience about Ivan and how cool he is.” Our task later is to help Ivan develop a solution that truly solves this problem. To do that, we need to study this need thoroughly. What does Ivan do? Who is his target audience? Where are they? What do they currently know about Ivan, and as a result of what actions? Why does Ivan need greater awareness? How does he know the audience is currently unaware? What is the meaning of life?
By exploring these questions, we immerse ourselves in the client’s business. We study their business domain (subject area; often much more complex than these examples — imagine Ivan is a company providing mortgage services in Uganda), compile a glossary of domain terms, study their organization (if not an individual), its processes, architecture, technologies, policies, as well as the surrounding context (e.g., government policies in that industry).
By exploring these questions, we immerse ourselves in the client’s business. We study their business domain (subject area; often much more complex than these examples — imagine Ivan is a company providing mortgage services in Uganda), compile a glossary of domain terms, study their organization (if not an individual), its processes, architecture, technologies, policies, as well as the surrounding context (e.g., government policies in that industry).
Important: We do all this not for the sake of accumulating information itself. Studying the context is aimed at clarifying business needs, because that is our goal at this stage. Don’t blindly apply trendy Internet or BABOK techniques designed for comprehensive organizational and process analysis. In IT business analysis, our ultimate goal is to facilitate high-quality IT solution delivery. We are not business transformation specialists or consultants. Study only what clarifies business needs. Once you believe you understand them and the surrounding AS IS, stop. Study the rest only when there is a clear necessity.
Having understood what we need to get out of this stage, let’s talk about how to do it. In the previous note, I explained that the main goal of this cycle is to provide a quick start guide for working at each stage.
First, analyzing the current state is, like most analyst work, about working with information — in this case, information about the client’s business needs and their context. Working with information, if we recall and slightly extend the wisdom of our beloved Mr. Wiegers, involves: extracting it from those who hold it (or from places where it is hidden), analyzing it (removing the unnecessary, systematizing, bringing to a quality form), documenting it (if it needs to be recorded for future use — which is less often than you might think), and then verifying and managing it further (keeping it usable and up to date). We’ll touch on the main points of this below.
First, analyzing the current state is, like most analyst work, about working with information — in this case, information about the client’s business needs and their context. Working with information, if we recall and slightly extend the wisdom of our beloved Mr. Wiegers, involves: extracting it from those who hold it (or from places where it is hidden), analyzing it (removing the unnecessary, systematizing, bringing to a quality form), documenting it (if it needs to be recorded for future use — which is less often than you might think), and then verifying and managing it further (keeping it usable and up to date). We’ll touch on the main points of this below.
It’s no secret that the core task at this stage is to dig this information out of its sources — both obvious and hidden deep in minds or documents. The simplest starting point is to ask. Ask whom? Obviously, the client or their representative — for example, the contact person assigned to represent the company’s interests on this project. Usually, this is the first stakeholder we engage with.
How to ask? As analysts, we know about interviews (written, oral, face-to-face, remote), workshops, and surveys. Choose whatever suits you. Usually, the analyst starter pack is an interview with recording and a pre-sent agenda (topics list). We inform the interviewee what we’ll be asking about, then schedule and begin excavating the items mentioned earlier. Several meetings and additional communications are usually needed to complete the stage.
How to ask? As analysts, we know about interviews (written, oral, face-to-face, remote), workshops, and surveys. Choose whatever suits you. Usually, the analyst starter pack is an interview with recording and a pre-sent agenda (topics list). We inform the interviewee what we’ll be asking about, then schedule and begin excavating the items mentioned earlier. Several meetings and additional communications are usually needed to complete the stage.
Example questions, in their “bare” form (no wrapping):
- What are the reasons for starting this project?
- What is wrong with the current situation? What opportunities do you see from the project?
- Why do these problems occur?
- How do the target processes work now?
- What impact do the stated problems have?
Important tips:
1) Clearly communicate to the client why you’re doing this work — naturally, in terms of value for them and the project. I mentioned above that the client might be skeptical about such work. So, your approach should be something like:
1) Clearly communicate to the client why you’re doing this work — naturally, in terms of value for them and the project. I mentioned above that the client might be skeptical about such work. So, your approach should be something like:
- We’d like to start by understanding the reasons behind the project.
- This will help us avoid wasting your and our time in the future.
- The better we understand the business needs and context, the more likely we are to deliver the right solution.
2) Avoid conducting such communication purely in writing. At this stage, you’re gathering a large volume of information, mostly through open-ended questions (“Tell me how your process X is organized”). The client will hardly be thrilled by the prospect of writing all this down in emails.
Like with any information elicitation, there are many tips and best practices that help do this more effectively and with less burden on the client. Let’s consider the key ones:
Like with any information elicitation, there are many tips and best practices that help do this more effectively and with less burden on the client. Let’s consider the key ones:
1) Agendas and meeting minutes (follow-ups). Don’t underestimate the usefulness of these tools. At this stage, they are especially valuable because:
So, before the meeting or call, send the client an email with the following details:
After the meeting/call, send the client an email containing (below is not a full “standard” follow-up template, just the useful core for most situations):
- The client needs to clearly understand what we want from them, what we’ll be asking, and why — they will likely need to prepare for the conversation and possibly invite others.
- The chaos collected from open questions will need to be organized (cleaned from “noise”) and you will have to ask the client to confirm your final understanding — at this stage, it’s easy to misunderstand domain terminology and the essence of what’s happening overall because for the client this will be their first “visit to a psychotherapist,” and they might dump a sea of words on you, where you need to avoid drowning.
So, before the meeting or call, send the client an email with the following details:
- Purpose of the meeting
- When and where (of course, include necessary links and instructions, e.g., how to connect to the online session)
- Duration
- Who needs to attend (explain to the client that they may invite others if they find it helpful in the context of the discussed topics)
- Agenda (list of discussion topics with as much detail as you think valuable to communicate in advance)
- Accompanying materials and action plan for preparation (usually not very relevant for AS IS discussions but include if needed)
After the meeting/call, send the client an email containing (below is not a full “standard” follow-up template, just the useful core for most situations):
- Key points from the information gathered during the meeting (filtered through your understanding and presented clearly), asking them to correct or confirm your comprehension.
- Summary of next steps — especially if any were mentioned during the meeting (“You, client, will check with employees about…; we will start working on…; next meeting scheduled for…”) Ideally, follow the formula “who, what, when.”
2) Record the meeting. Preferably with participants’ consent. Plan in advance how you will technically do this (set up Zoom parameters, test screen recorders like Bandicam, prepare a phone recorder, etc.), how you will ask for permission to record (don’t forget to justify and “sell” this in terms of value), and what you’ll do if the answer is no. Is it worth recording? Yes, definitely, don’t skip it (both recording and reviewing afterward):
a) At this stage, the client gives you golden information. Missing a need because you had to both take notes and keep the conversation going is a poor outcome. The analyst must carefully handle information. Sometimes a single word extracted from the chaos can be a clue that leads to uncovering another need or important aspect.
b) No one likes to repeat themselves. An analyst is expected to minimize repetition. This is especially important at this stage — both because of the importance of the information for the entire project and because this is when you are still establishing your image with the client. We all miss things sometimes, but the simplest solution is to record and carefully listen later.
a) At this stage, the client gives you golden information. Missing a need because you had to both take notes and keep the conversation going is a poor outcome. The analyst must carefully handle information. Sometimes a single word extracted from the chaos can be a clue that leads to uncovering another need or important aspect.
b) No one likes to repeat themselves. An analyst is expected to minimize repetition. This is especially important at this stage — both because of the importance of the information for the entire project and because this is when you are still establishing your image with the client. We all miss things sometimes, but the simplest solution is to record and carefully listen later.
3) Use active listening:
a) During the meeting, guide the interviewee in the right direction: explain at the start what you want to hear (i.e., repeat what was in the agenda), and gently correct the course if you see you’re getting irrelevant information.
b) Make sure you understand the information correctly as you go: ask clarifying questions, paraphrase complex points for confirmation (“Let me try to put what you said in my own words…”; “Did I understand correctly that…?”).
c) Keep the interviewee engaged: show your own interest, sprinkle moderate emotional reactions, smile, wave.
a) During the meeting, guide the interviewee in the right direction: explain at the start what you want to hear (i.e., repeat what was in the agenda), and gently correct the course if you see you’re getting irrelevant information.
b) Make sure you understand the information correctly as you go: ask clarifying questions, paraphrase complex points for confirmation (“Let me try to put what you said in my own words…”; “Did I understand correctly that…?”).
c) Keep the interviewee engaged: show your own interest, sprinkle moderate emotional reactions, smile, wave.
4) Remember the information elicitation funnel (this is the process you need to go through to say you’ve truly elicited information, not just “asked and listened”):
a) Open questions: gather everything the person is willing to say on the topic (“Tell me the reasons for starting the project.”) ->
b) Closed questions: clarify unclear points and dig deeper into what you want to know (“So this affects…? What else does it affect? Who handles this process in your organization?”) ->
c) Confirm correctness of understanding: paraphrase and reflect key points back to the person (“Did I get it right that the key reason is …, but there’s also this aspect that should be considered?”) ->
d) Confirm the whole picture: summarize all obtained information in your own coherent form (“Let’s summarize: the project is driven by these three business needs: … Is that all? Anything to add?”).
Points c and d can be covered in the meeting minutes, i.e., documented in writing after the conversation.
a) Open questions: gather everything the person is willing to say on the topic (“Tell me the reasons for starting the project.”) ->
b) Closed questions: clarify unclear points and dig deeper into what you want to know (“So this affects…? What else does it affect? Who handles this process in your organization?”) ->
c) Confirm correctness of understanding: paraphrase and reflect key points back to the person (“Did I get it right that the key reason is …, but there’s also this aspect that should be considered?”) ->
d) Confirm the whole picture: summarize all obtained information in your own coherent form (“Let’s summarize: the project is driven by these three business needs: … Is that all? Anything to add?”).
Points c and d can be covered in the meeting minutes, i.e., documented in writing after the conversation.
5) Don’t forget the importance of precise terminology — glossary:
a) Whenever you encounter unknown terms or multiple/vague meanings of familiar words, ask immediately to confirm you understand the meaning they assign to them.
b) Record definitions (not necessarily during the meeting) and reflect them back to the client to confirm shared understanding. There are many cases where work went in the wrong direction because of differing interpretations of terms.
a) Whenever you encounter unknown terms or multiple/vague meanings of familiar words, ask immediately to confirm you understand the meaning they assign to them.
b) Record definitions (not necessarily during the meeting) and reflect them back to the client to confirm shared understanding. There are many cases where work went in the wrong direction because of differing interpretations of terms.
6) Try to communicate in the interviewee’s language:
Avoid overloading with IT or business analysis jargon. You can either use the terms but immediately explain what you mean, or replace them altogether with simpler words (e.g., instead of “Now we will discuss business needs underlying change and solution,” say “Let’s talk about the reasons for the project”). Generally, I recommend following the “Explain clearly and simply” approach rather than “Wrap it smartly so they see how awesome I am” — the latter has value only in very narrow cases.
Avoid overloading with IT or business analysis jargon. You can either use the terms but immediately explain what you mean, or replace them altogether with simpler words (e.g., instead of “Now we will discuss business needs underlying change and solution,” say “Let’s talk about the reasons for the project”). Generally, I recommend following the “Explain clearly and simply” approach rather than “Wrap it smartly so they see how awesome I am” — the latter has value only in very narrow cases.
7) Don’t forget to proactively provide context.
Finally, captain obvious says: everything you’ve elicited must be documented — information must not live only in your head. The final goal is to record it in your own words, i.e., not a stenography of the original chaos but reformulated and structured (organized by topics) information. Use whatever tool you like or the one used on the project for storing project information: Word or Google docs, Confluence pages, or for quick note-taking, mind maps (by the way, don’t neglect this option — it’s an excellent way to keep structured notes during discussions and afterwards). The structure of the document/page is not critically important — there is no widely accepted template for information from this stage.
You can also use two useful visual models (both for collaborative drawing during conversations and for preparing visuals afterwards, but with subsequent client confirmation):
- Business domain model — helps to structure and solidify understanding of the subject area.
- Ishikawa (fishbone) diagram — if you need to dig into the root causes of a business need. Build it combined with the “5 Whys” technique.