Business Analysis: Defining the Future State (TO BE)

2025-06-21 19:31 Business analysis

How do you do, fellow kids.

Let’s continue diving into business analysis, and today’s topic is the next stage — defining the future state (TO BE). Logically, this follows after studying the current state (AS IS).

A quick reminder (which you can also find in the initial article of this series): we’re still working within the context of strategy analysis/discovery. This means that the future state isn’t defined in terms of “here’s the system we need to build,” but rather in terms of the client’s strategy — i.e., why and where they want to go with the project they brought to us.

Important: yes, I’m repeating myself, but it’s necessary — since this is part of discovery, this stage, just like the previous one, only makes sense when this whole phase is relevant to the project. And how do we know if it is? The BA lead, project manager, and other “big people” who can scope our work on the project will indicate this. Plus, quite often, the client themselves might hint (subtly) that we’re wasting time instead of actually working on requirements.

In essence, this is the stage where we elaborate business requirements. Sure, if you study BABOK, you’ll find a whole bunch of fancy terms you can add here: change strategy definition, gap analysis, organizational readiness assessment, resource planning, etc. But let’s keep it real and leave those advanced, rare projects to the pros — especially considering that we’re talking about a middle-of-the-road IT business analyst. Remember, the goal of this series is to provide a straightforward guide that works in most cases. For the fancy business techniques (although I doubt they fit most IT projects), that’s BABOK territory.

So, once we’ve understood the business needs and the context around them at the previous stage (i.e., we grasped the client’s “AS IS” situation with all its problems and desires), it’s time to define where exactly they want to get to. This is done in the form of business requirements, as mentioned earlier.

Business requirements are goals that serve as indicators of fulfilling the client’s business needs.

How does this work in practice? Usually, clients don’t come to us IT contractors with a bare-bones formulation of their business needs like “I have high costs on manual request processing.” Instead, clients come with a project to develop or improve something. But at this stage, it’s best to treat this proposed solution as “hypothetical.” As analysts, if we’re doing strategic analysis, we should step away from that solution and focus on studying the AS IS and defining desired outcomes from the solution.

The current stage (defining TO BE) isn’t explicitly marked here, and the diagram describes the entire strategy analysis process as a whole, but it’s useful to understand that we usually base our work on the client’s proposed solution — while keeping in mind that the outcome of discovery can be a new solution, more effective than what the client originally brought. That’s the power of business analysis at this stage.

Back to business requirements:

1) Business requirements are formulated as the client’s goals (whether an individual or an organization), for example: “Reduce client request losses by 80% within one month after the solution’s release.” So, in this text, you’ll see the term “business goal” used interchangeably with business requirement.

2) Business requirements answer the question: “Why is this solution needed in the first place (whatever it might be)?”

3) Business requirements are NOT the same as business needs. Business needs are the sources of business requirements (and therefore, in any documentation, they must be explicitly traced to each other). Business needs describe what is currently wrong (problems) or what the client would like to achieve (opportunities), for example: “I have excessive weight.” Business requirements, however, are presented as precisely formulated planned outcomes: “Lose 15 kg within 6 months.”

4) It’s better to keep business goals abstracted from specific solutions to avoid mental bias. At this stage, it’s especially important, since we still don’t have a solution — we don’t know which one the client will choose. That’s why we do this work step-by-step. Later, when the solution is chosen, we can fine-tune business goals and their parameters based on that particular solution. For example, at the end of strategic analysis, once we know what exactly we’re doing and the scope, we can clarify and supplement goals: “Reduce client request losses by 80% (after double-checking that it’s realistically achievable through the website solution we selected) within one month after releasing the MVP of the website (taking into account the time needed for promotion and adoption of that MVP with its set of features).”

5) The key indicator of a well-defined business requirement is its compliance with SMART criteria.

We’ve all heard of SMART — and even if not in the context of business analysis, probably from self-help courses where people define their points A and B, formulate SMART goals for world domination, and launch balloons into the sky. While I don’t want this article to feel like that, SMART is a useful technique for business requirements.

SMART stands for five main principles that ideally characterize business requirements:

S — Specific. The goal should indicate a concrete result, not an abstract phrase you can’t touch. Sometimes analysts slip here. Not “Improve efficiency,” but “Reduce process time.”
M — Measurable. The goal should have a clear indicator to tell at any point whether it’s achieved or not. This can be a quantitative metric or something that answers “goal met or not.” Examples: “Increase profit by 20%” or “Get the first service order.” Sometimes it’s an artificial metric invented for the goal, especially when it’s hard to quantitatively measure qualitative change: “Achieve an average customer service rating of at least 8 out of 10 over a year.” The metric can also be a range: “Reduce document processing costs by 20-40%.”
A — Achievable. Realistic. This means that when we hear a goal like “Make a million dollars from the product,” as analysts we should critically assess it and encourage the client to justify its feasibility, rather than blindly recording what’s said. We’re designing solutions based on goals, and what we invest in the solution should lead toward the goal, not into a dead end.
R — Relevant. The goal should be relevant to the business need it’s linked to. Simple: goals must flow from business needs. “Generating revenue from product sales” doesn’t directly translate into a goal like “Achieve a 5 out of 10 usability score for the app.” Indirectly, maybe, but not directly.
T — Time-bound. There must be a time indicator limiting the goal’s deadline. For example, “Within one month after the solution is launched.”

Important: SMART is not mandatory (especially for M, A, and T). I recommend striving for it within reason. If you hit a wall, better to let it go and just have a goal that clarifies why we’re all here. A clear example is product monetization. The client may not have a business plan or specific expectations about how much the product will earn. If they do — great. If not, you can talk it over and maybe help form something, but that effort might go nowhere if the client is okay with the investment risk themselves. “Make money on the product” — clearly understanding and keeping this goal in focus throughout the project is already much better than nothing.

So, to recap: we need to take business needs from the previous stage and transform them into business requirements here. And of course, record them somewhere, because we should document information from every stage outside of our heavily loaded brains. A typical artifact for this is the Vision and Scope document — specifically the part that corresponds to this stage of business analysis. There’s a discussion of what such an artifact contains in another article.

Important: by Vision and Scope, I don’t mean a Word document. Think of it as a collection of information from strategy analysis, maintained wherever convenient/where the team works/where the client wants. It can be a Word doc, Google doc, a set of logically connected pages in Confluence, notes in Notion, or even data in an RMS system if you’re really serious. In other words, just because we’re all Agile now doesn’t mean we skip documenting discovery outcomes in some form, and don’t use “We don’t write Vision and Scope because we do Scrum!” as an excuse to pat yourself on the back with a smoothie.

If we look at the typical contents of Vision and Scope (smart people have already suggested sections important for strategy analysis), what else can we develop at this stage besides business requirements?

It’s not always obvious when exactly to work on these next points, but let’s say: start now, and revisit them as discovery progresses (because our business analysis stages aren’t a strict waterfall).

First, there’s the concept of success metrics.

Often, business requirements alone seem insufficient to evaluate how valuable our developed solution is to the client. Besides the solution itself, there can be many factors influencing the achievement of business goals, plus business goals may be far in the future compared to the solution’s development and deployment. That’s where defining success metrics for the solution on the path to business goals helps: what indicators show that the solution is driving progress toward the business requirements over time?

I’ve already covered success metrics in another article, but here’s a quick recap. Suppose I’m the author of a business analysis course, delivering it as a solution to the client. What might be the client’s business goal? For example, “Get a job as an IT BA within six months with a salary of at least $300.” Can I, as the solution provider, be sure that the course itself will bring the client to that goal? No, of course not. Achieving such a business goal depends on other “projects” the client undertakes: actively sending resumes, taking a technical prep course, improving English to level X. There’s also external context beyond my control, such as the number of job openings. Success metrics help both the client and the solution provider (if they care) assess how well the solution contributes to achieving the business goals — so they can understand what might be wrong and adjust as needed.

For instance, I might propose a success metric: “Complete the course with a final score of at least 70%.” For me, that’s a marker that the solution is helping move toward the business goal. If this metric isn’t met, then in my opinion, the course isn’t helping achieve the original goal and something should be changed — either in the solution itself or in how it’s used.

Important: defining success metrics is not mandatory. If nothing besides the solution and context affects business requirements much, and you see no value in forcing artificial metrics, don’t suffer over it. Ask yourself and the client: are business goals enough, or would it be useful to develop additional metrics to understand how well the solution supports those goals?

Let’s now talk about business risks. Again, I’ll borrow the definition from the previously referenced article on discovery: business risks are things that might go wrong in achieving the goal, even with a working and ready-made solution. In other words, they’re factors that could negatively affect the applicability of the solution in reaching business goals.

As I’ve already mentioned, implementing the solution is rarely the only factor determining whether the goal will be achieved. So, if there’s anything else that could impact success, the next logical questions are: What exactly? And how?

For instance, in the earlier example related to training, a business risk might be: “The market could run out of business analyst vacancies,” or “Due to personal circumstances, the client might not be able to fully engage with the course to the extent necessary to achieve the defined success criteria.”

Risks might arise from market competition — for example, if competitors roll out more useful features, tipping the scales in their favor. Or from user behavior — users may resist adopting the solution. Or from regulatory changes — the government might issue a regulation that restricts something within the domain. And so on.

Important: risk isn’t just a hypothetical probability abstracted from the context. Take “The market may run out of business analyst jobs” — that might be a general possibility at any given time. But we only consider it a risk when there are actual signs pointing to it. For instance, during an IT market downturn, this could be valid. During a boom, with evident hiring activity, it’s not practical to treat it as a meaningful risk.

Here’s what needs to be done when working with business risks:

Document them — a table will do.
Try to assess the following aspects (ideally together with the client): a) Probability of the risk materializing. b) Impact on achieving business goals if it does occur. This can be done qualitatively (minor, moderate, significant) or quantitatively (e.g., on a 10-point scale).
For the main risks (those with the highest combination of likelihood and impact), help the client define a risk management policy. This is key — proactively managing risks adds real value.

Example risk management policies (continuing with the Course example):

Avoidance (eliminating the uncertainty causing the risk):

Let’s say there's a risk: “The client might not engage fully with the course because a month-long vacation in Hawaii was planned during the course period.” Once identified, this should be discussed with the client — this vacation could seriously impact the success criteria. A reasonable decision might be to reschedule the vacation, or at least recommend doing so.

Transference (shifting responsibility): Using the same risk, I as the provider might add a clause in the contract stating that the client won’t receive a certificate if they miss X sessions. The certificate, of course, is a defined success criterion. Whether this policy is optimal is a separate issue, but it's an available approach.

Mitigation (reducing the probability or impact of the risk): For example, “The client may not be able to participate effectively in online sessions due to poor internet.” Reducing probability: recommend the client secure a reliable internet connection with specific specs ahead of time. Reducing impact: include course session recordings in the solution and provide them to the client.

Acceptance — we acknowledge the risk and move on.

Recommendations for handling business risks:

1) Extract risks while gathering any information during the discovery phase. Pay attention to stakeholders’ wording. Phrases like “if,” or “it’s possible that,” especially when referring to things outside your team’s control, are red flags.

2) After formulating business needs and requirements (and later, the solution concept, scope, external dependencies, etc.), take a step back. Look at everything critically: what might go wrong in terms of achieving business goals? Important: for everything not directly part of the solution, remember this: as an IT business analyst, your role is to assist, not to take responsibility. In a typical IT project, unless responsibilities are narrowly defined, neither you nor your team is accountable for the business needs, goals, success criteria, or risks. Most likely, the contract will cover only the final deliverable and its characteristics — not business transformation or its outcomes. You do all this so that: a) The solution has real value, not just something the client dreamt up randomly, b) You help the client become aware of things they likely hadn’t considered before.

3) Also — this applies to any phase of analysis — always identify assumptions in the information you’re working with. These are not facts, but hypotheses, which often underpin other strategic analysis elements. An assumption is a statement you’re unsure about. It may be due to:

Unavailable info (e.g., the client’s SME quit and is unreachable).
Inherently unverifiable info (e.g., the business goal is based on a hypothesis that 15,000 users will install the app).
Lack of time or interest (e.g., no one wants to do market research, so you assume users need the product).

Assumptions are situational. They’re not like business goals or risks, which objectively exist — we might just not know them yet. Assumptions may or may not exist — it depends on how much information has been clarified. That’s why it’s crucial to document them: they can eventually be resolved. Periodically review and try to eliminate them.
For example, suppose the course business goal is based on the assumption that the client will begin studying within a month. But I’m unsure, because they’re hesitant. Then in the “Vision and Scope” section, I might write:

AS-1: The client will start studying within one month.

And in the business goal section, I’ll add: “See AS-1.”

How to elicit all this information:

The overall approach doesn’t differ from what we covered in the previous article. We still use standard elicitation techniques: interviews, workshops, surveys, etc. So, definitely refer to that article for tips on organizing collaborative work. Here are additions specific to this stage:

Key questions to ask the client (but present in them in a wrapped and empathetic way):

What is the desired outcome once the solution is implemented?
How will we know that the goal has been achieved?
When will we measure the results — what’s the timeline?
Would it help to define additional metrics to evaluate progress toward business goals?
Imagine the solution is already in place — what else could go wrong and interfere with achieving those goals?

Important: unlike in the AS IS phase — where we mostly extract information — here we’ll need to help the client develop it. We still start with inquiry, but we also need to be ready to guide, suggest, and generate ideas. Since clients often won’t have business goals, success criteria, or risks clearly defined, here’s how to help:

1) Explain why you’re doing this work:

It ensures you develop a solution focused on real impact.
It helps us maintain focus on the true purpose of the project — future decisions will be based on this.

Proactively include these explanations in your meeting agendas.

2) Blend written and verbal communication more freely at this stage. Writing often helps clarify thought and refine how you guide the client.

3) If the client is struggling, here’s how to help:

Provide examples of business goals, success criteria, and risks. Examples make everything more concrete.
Give direction: “We identified these business needs... so logically the goal should reflect whether we’ve addressed them.”
Offer suggestions, but do so after giving the client space to think. If they’re stuck, then step in with your ideas.

A sample (though condensed) dialogue that might happen at this stage with a client who doesn't fully grasp what's going on yet:

Mr. Anderson, as you’ll recall, we previously identified the reason for starting this project — what we referred to as a business need: a high rate of lost service requests. Now we’re suggesting we reframe this into concrete project goals. Here’s how that helps us: … (Here we refer to the earlier stated rationale for defining goals.) If you agree that this makes sense, do you perhaps already have some goals in mind, even if only loosely defined?

Nope, haven’t really thought about that, but I do get why it’s important.

Okay, let’s think through it together. Since we’re building off the business need, it’s logical to assume the goal — let’s call it a business requirement — is to reduce the number of lost service requests by implementing a solution. Sound good? Anything else to add?

Yep, agreed. We do need to eliminate those losses.

Awesome! Now, to make this a strong, well-defined goal, we need to attach a metric that will help us measure success, and also add a time frame. Any ideas?

Uhh… I guess the main point is that requests are no longer being lost…

Exactly! You’re on the right track, as always. Let’s dig into this: you mentioned that currently about 5% of requests are lost because they come in through too many different channels, which makes it hard to consolidate them all without error. Since we’re talking about an IT solution to manage these requests, a logical assumption is that we’ll consolidate all incoming channels — which should reduce the chance of human error. Would you agree?

Yep!

Okay, then would it be realistic to aim for zero losses — complete elimination? Or should we allow for a bit of wiggle room, since we can’t completely eliminate the human factor? Maybe reducing the loss rate to 1% is more feasible?

Yeah, that sounds reasonable.

Great. Then our final goal could be: reduce the number of lost service requests to 1% within… What kind of timeline are we looking at? Do you have any constraints or expectations on that? If not, here’s a suggestion: since this is an IT solution, there will be an adaptation period for the administrator. Would it make sense to aim for full adoption one month after launch, and then track request loss over the following month? Does that seem logical to you?

Makes sense, I agree.

Perfect. So our final goal is: reduce the number of lost service requests to 1% within two months. Now, let’s move on to so-called success criteria. These help us… (Refer to the earlier rationale for success criteria.) In the context of this particular business goal, it might seem unnecessary to define additional criteria — after all, we can just measure the goal in two months — but still, based on our logic above, one possible criterion could be: “All client-facing channels for submitting requests are fully replaced by the new system.” What do you think?

Yes, we’ll do that and make sure it’s working.

Cool. Now, let’s consider what could go wrong, even if the solution itself is solid. Will the admin be able to fully master the new IT system? How will you notify clients about the new request submission process? Could they still try calling directly? Anything else that comes to mind?

Yeah, the admin will definitely manage. We’ll redirect all clients to the website to submit requests. But you’re right, someone might still call directly.

Okay, then let’s formalize that into risk statements… (You can probably see where this is going from here.)

What can help at this stage in terms of techniques?

1) A fairly obvious technique — Business Objectives Model.

Why is it “obvious”? Essentially, it’s just a mind map that visually shows the traceability from business needs to business goals — and later, as the project progresses, to the scope elements of the solution that enable those goals. In other words, just keep in mind that this is something you can map out visually and present to stakeholders. A standard mind map works great for this.

2) Lean Canvas. This technique goes beyond just the current and previous stages, but it’s worth mentioning now. In essence, Lean Canvas covers nearly the entire discovery process, minus the definition of the solution scope. It's also conceptually simple: you bring a visual canvas with key information blocks to a workshop and collaboratively fill it out step by step. This gives you a ready-to-use framework for discussing everything mentioned earlier — in a visual and structured way.

Although “ready-to-use” might be an overstatement, as Lean Canvas is designed for mass-market products, not custom solutions. So let me clarify how to reinterpret it for broader applicability, particularly for business analysis in bespoke development contexts:

“Problems” should be reinterpreted (or even renamed) as “Business Needs” or “Problems/Opportunities”, rather than as user-centric issues — it’s too early in the business analysis phase to focus on user problems.
“Customer Segments” should be reinterpreted/renamed as “User Classes”, or better yet, “Stakeholders”. We'll discuss stakeholder analysis in the article on business analysis planning.
“Unique Value Proposition” can be reframed as “Stakeholder Values” — i.e., the value that the future solution will provide to each group of stakeholders. Again, this is a bit premature, since we don’t yet have a solution.
“Solution” — as already noted — is premature to define. That’s for later stages.
“Channels”, “Unfair Advantage”, “Revenue Streams”, and “Cost Structure” — all of these can be removed. They are either irrelevant or far less important in custom development projects.
“Key Metrics” can be renamed to “Business Goals and Success Criteria”.
Add new sections instead of the removed ones — sections that are relevant to strategic analysis in our context. At this stage, one such addition could be a “Business Risks” section. Other useful sections will emerge in later stages.

To reiterate: this is a conceptually simple technique. We a) identify the key information categories relevant to the discovery phase, b) organize them on a visual canvas, and c) run a workshop — one of the most effective methods for extracting requirements — to gather input from all stakeholders on these key areas.