3  Strategy: What Problem to Solve

Before an organization launches a project, before budgets are approved, before teams are assembled, something important must happen. Someone must determine whether the project should exist at all. This determination happens during what we call the Conception Phase of the Software Development Life Cycle.

If you are preparing for the ECBA certification, you should know that this material goes beyond what the exam covers. However, understanding strategy analysis makes you a more complete Business Analyst, which is why I include it in this course.

3.1 The Business Analyst’s View of the Software Development Life Cycle

Figure 3.1: The SDLC consists of eight phases. Business Analysts are most heavily involved in Conception, Initiation, and Analysis.

Look at Figure 3.1 showing the complete life cycle. It begins with Conception and flows through Initiation, Analysis, Design, Development, Testing, Deployment, and finally Maintenance. Each phase builds on what came before.

The original model, often called Waterfall, shows these phases as a linear sequence. Work flows from one phase to the next like water flowing downhill. Agile approaches reorganize this flow into shorter cycles, but the same fundamental activities still occur.

What matters for this chapter is understanding that everything starts with Conception. This is where organizations decide what problems are worth solving.

3.2 The Conception Phase

The Conception Phase is where the SDLC truly begins. An idea or concept is evaluated, and if it passes scrutiny, a proposal is put forward.

Senior Business Analysts typically handle this phase because it requires experience and judgment. The work involves evaluating business needs and problems before committing organizational resources. Getting this phase wrong means wasting time and money on projects that should never have started.

The Business Analyst’s role during conception includes developing a problem statement that clearly articulates what issue the organization faces, performing feasibility analysis to determine whether proposed solutions are realistic, preparing option analysis to compare different approaches, conducting impact analysis to understand how changes will affect the organization, and developing cost-benefit analysis to justify the investment.

3.3 Creative Thinking: Where Strategy Begins

Strategy analysis does not start with spreadsheets and formal documents. It starts with creative thinking.

What does it mean to think creatively in a business context? It means becoming an agent of change. It means challenging the status quo rather than accepting things as they are simply because they have always been that way. It means seeing situations from different perspectives, including perspectives that might initially seem wrong or unusual.

Let me try an exercise with you. Imagine nine dots arranged in a three-by-three grid. Your task is to connect all nine dots using only four straight lines, without lifting your pen from the paper.

Most people struggle with this puzzle because they unconsciously assume they must stay within the boundaries formed by the dots. But no such rule exists. The solution requires extending lines beyond the apparent boundaries of the grid.

This exercise illustrates a crucial point. We often limit ourselves with assumptions we do not even realize we are making. Effective strategy analysis questions these assumptions. When someone says “we cannot do that,” a good Business Analyst asks “why not?” When everyone agrees on an approach, a good Business Analyst asks “what alternatives have we not considered?”

3.4 What Is Strategy Analysis?

Strategy analysis encompasses the business analysis activities that help organizations identify business opportunities and determine the best investment path forward. This work focuses especially on implementing new business and technical solutions.

When does strategy analysis occur? It happens during the pre-project phase, before formal project work begins. This timing is critical. Once a project starts, momentum builds. Resources get allocated. People develop attachments to particular approaches. Making changes becomes increasingly difficult and expensive. Strategy analysis happens early precisely so organizations can make better decisions when flexibility is greatest.

What occurs during strategy analysis? Business requirements for future project investment are identified and documented. These requirements are defined at a high level, focusing on goals, objectives, and needs rather than detailed specifications. Investigative activities determine why a project is being requested and what metrics will indicate success.

3.5 The Five Activities of Strategy Analysis

Figure 3.2: Strategy analysis follows a logical sequence of five activities, though in practice you may iterate between them.

Strategy analysis follows a logical sequence of five activities (Figure 3.2). Think of these as steps, though in practice you may move back and forth between them as you learn more.

The first activity is defining the business need. The second is assessing capability gaps. The third is determining the solution approach. The fourth is defining the solution scope. The fifth is developing the business case. Let me examine each one.

3.6 Defining the Business Need

The business need is the problem an organization wants to address or the opportunity it wants to capture, along with the desired outcome. This sounds simple, but expressing business needs clearly is surprisingly difficult.

Consider this example. A department manager says “we need a new reporting system.” Is that a business need? Not really. It is a proposed solution. The business need might be something like “we cannot make timely decisions because we lack accurate information about inventory levels.” The reporting system is one possible solution to that need, but there might be others.

Defining the business need properly matters because it opens up possibilities. If you define the need as “we need a new reporting system,” you have already narrowed your options to different reporting systems. If you define the need as “we need accurate inventory information for timely decisions,” you might discover that fixing data entry errors would solve the problem without any new system at all.

Several techniques help define business needs effectively.

Benchmarking involves understanding what competing enterprises are doing. If your competitors can produce financial reports in two days while yours take two weeks, that gap might indicate a business need.

Brainstorming generates insights and options through collaborative idea generation. Gathering people from different areas of the business often surfaces needs that no single person would identify alone.

Business rules analysis identifies changes needed in the policies that guide the organization toward its goals and objectives. Sometimes business needs stem from rules that no longer make sense.

Focus groups bring together stakeholders to identify and discuss problems. The group dynamic often reveals issues that individual interviews might miss.

Functional decomposition converts business goals into achievable objectives and measures. By breaking down high-level goals, you can identify specific needs that must be addressed.

Root cause analysis determines the underlying source of a problem. This technique deserves special attention.

3.7 Root Cause Analysis: The Five Whys

Figure 3.3: The Five Whys technique traces a problem back to its root cause by repeatedly asking “why” until the underlying issue is revealed.

When problems occur, organizations often rush to fix symptoms rather than causes. A customer service team might hire more staff to handle complaints without asking why complaints increased in the first place. A warehouse might add overtime shifts to meet shipping deadlines without understanding why shipments fell behind.

The Five Whys technique (Figure 3.3) provides a simple but powerful approach to finding root causes. You start with a problem and ask “why” it occurred. Then you take that answer and ask “why” again. You continue until you reach a root cause that, if addressed, would prevent the problem from recurring.

Here is an example:

Problem: Computers are breaking down at work, slowing our productivity.

Why are computers breaking down? Because they are overheating.

Why are they overheating? Because the cooling fans are not working properly.

Why are the fans not working? Because they are clogged with dust.

Why are they clogged with dust? Because nobody has cleaned them.

Why has nobody cleaned them? Because there is no maintenance schedule.

Root cause: Lack of a computer maintenance schedule.

Notice how different this root cause is from the original symptom. If we had simply replaced the broken computers, we would have spent money but not solved the underlying problem. New computers would eventually overheat too. By identifying the root cause, we can implement a maintenance schedule that prevents the problem from recurring.

One important note: each “why” question must relate directly to the previous answer. Do not jump to unrelated topics or probe into personal matters that distract from finding the actual cause.

3.8 Root Cause Analysis: The Fishbone Diagram

Sometimes problems have multiple contributing causes that interact in complex ways. The Five Whys works well for linear cause-and-effect chains, but some situations require a different approach.

Figure 3.4: The Fishbone Diagram provides a visual framework for exploring multiple potential causes organized by category.

The Fishbone Diagram (Figure 3.4), also called the Ishikawa Diagram or Cause and Effect Diagram, provides a visual framework for exploring multiple potential causes. The diagram looks like a fish skeleton. The problem statement sits at the head. Major categories of causes branch off the spine like bones. Specific potential causes attach to each branch.

Common categories include Policies, Procedures, People, Technology, Methods, Materials, Environment, Measurement, and Machinery. Not every diagram uses all categories, and you might create custom categories that fit your specific situation.

The power of the Fishbone Diagram lies in its structured approach to brainstorming. Instead of randomly listing potential causes, you systematically consider different categories. This reduces the chance of overlooking something important.

3.9 Writing a Problem Statement

Once you understand the business need and its root causes, you should document it in a problem statement. A well-written problem statement gives everyone a shared understanding of what needs to be solved.

A good problem statement follows a simple structure:

The problem of [describe the problem] is affecting [identify who is affected] the impact of which is [describe the consequences] and a successful solution would [describe the desired outcome].

Here is an example:

The problem of getting to work late is affecting my professor, the students, and the university. The impact is the professor may lose his job. A successful solution would help the professor keep his job.

This format forces clarity. You must name the actual problem, not a proposed solution. You must identify specifically who suffers from it. You must explain why it matters. You must describe what success looks like.

3.10 Assessing Capability Gaps

The second strategy analysis activity asks a crucial question: Can the business meet its need using its existing structure, people, processes, and technology?

Sometimes the answer is yes. An organization might already have the capabilities it needs but not be using them effectively. Other times, the answer is no, and new capabilities must be developed or acquired.

Several techniques help assess capability gaps.

Document analysis involves reviewing existing materials to understand the current state. What do existing reports, procedures, and system documentation tell you about current capabilities?

3.10.1 SWOT Analysis

Figure 3.5: SWOT Analysis examines internal Strengths and Weaknesses alongside external Opportunities and Threats.

SWOT Analysis (Figure 3.5) identifies how current capabilities and limitations match up against influencing factors. SWOT stands for Strengths, Weaknesses, Opportunities, and Threats.

Strengths and Weaknesses are internal factors that the organization can control. Opportunities and Threats are external factors that the organization must respond to.

3.10.2 PESTLE Analysis

Figure 3.6: PESTLE Analysis examines six categories of external macro-environmental factors.

While SWOT focuses on internal factors, PESTLE Analysis (Figure 3.6) considers macro-environmental external factors that may affect your capacity to achieve the future state.

PESTLE stands for Political, Economic, Social, Technological, Legal, and Environmental factors. Some organizations add Ethical to create STEEPLE.

3.11 Determining the Solution Approach

The third activity determines how the new capabilities will be created or acquired. Options might include buying a commercial off-the-shelf solution, designing and building something yourself, restructuring existing processes, or adding people.

The goal at this stage is to understand enough about potential solutions to create the business case. You do not need to select the final solution yet, but you need to understand the viable options.

Every evaluation should include the option of doing nothing. This provides a baseline for comparison. Sometimes doing nothing is actually the best choice, but you cannot know that unless you explicitly evaluate it.

Assumptions and constraints that affect each solution option should be identified to help decision-making. For example, two constraints might be: the solution must be implemented by year-end, and the solution cannot exceed $100,000.

3.12 Defining the Solution Scope

Solution scope defines which new capabilities a project or iteration will deliver. You want stakeholders to understand which new capabilities an initiative will deliver, what will not be covered, and what dependencies must be met for the solution to succeed.

Clear scope prevents misunderstandings that derail projects. When stakeholders have different expectations about what is included, conflict is inevitable.

3.13 Developing the Business Case

The business case describes the justification for the project in terms of the value to be added to the business as a result of the deployed solution, compared to the cost to develop and operate the solution.

Several techniques support business case development.

Decision analysis includes cost-benefit analysis to compare the costs of implementing a solution against the benefits to be gained.

Estimation forecasts the size of the investment needed to deploy or operate the proposed solution.

Risk analysis assesses risks that may impact the solution and the costs and benefits associated with it.

Vendor assessment evaluates potential vendors if purchasing or outsourcing is being considered.

3.14 Case Example: The University Parking Problem

State University had a parking problem. Students, faculty, and staff complained constantly. Some mornings, people circled lots for twenty minutes seeking spaces. The initial response was predictable: a proposal to build a new parking structure costing fifteen million dollars.

Before committing that much money, the university asked a Business Analysis team to conduct strategy analysis.

Defining the business need: The problem was not “we need more parking.” It was “members of our community cannot reliably access campus when they need to.” This reframing opened possibilities beyond adding concrete.

Root cause analysis revealed several factors: Parking demand peaked between 9 AM and 2 PM, but spaces sat empty early morning and late afternoon. Some permit holders rarely came to campus but held permits “just in case.” The university bus system was unreliable, making driving more attractive.

Capability gap assessment showed: The university already had underutilized resources. Evening classes had ample parking. Satellite lots with shuttle service were unpopular but available. A nearby shopping center had excess parking during weekday mornings.

Solution options generated: Building the parking structure was one option. Others included adjusting class schedules to spread demand, implementing dynamic pricing, partnering with the shopping center, improving shuttle frequency and reliability, and offering incentives for carpooling.

The business case showed: The parking structure would take three years to build and require a significant increase in permit fees. Several lower-cost alternatives could be implemented within months.

The decision: The university implemented a pilot program combining schedule adjustments, a partnership with the shopping center for overflow parking, and improved shuttle service. Total cost was under $500,000.

The result: Parking complaints dropped by over 70%. The parking structure was never built.

This example illustrates why strategy analysis matters. Without careful analysis, the university might have spent fifteen million dollars on a solution that was not needed. By understanding the real problem and evaluating multiple options, they found a better path forward.

Now that you understand how organizations decide what problems to solve, let us move on to how Business Analysts plan and organize their work once a project begins.

3.15 Review Questions

1. During which phase of the SDLC does strategy analysis primarily occur?

   1. Development phase
   2. Testing phase
   3. Pre-project or Conception phase
   4. Deployment phase

2. When using the Five Whys technique, each “why” question should:

   1. Probe into personal motivations
   2. Relate directly to the previous answer
   3. Change topics to explore different perspectives
   4. Always lead to a technology solution

3. What is the purpose of including “do nothing” as an option in solution approach analysis?

   1. To make decision-makers feel they have choices
   2. To ensure the decision to proceed is explicit and justified
   3. To delay projects that seem too expensive
   4. To satisfy regulatory requirements

4. Which analysis technique focuses on external macro-environmental factors?

   1. SWOT Analysis
   2. Five Whys
   3. PESTLE Analysis
   4. Fishbone Diagram

5. What distinguishes a business need from a proposed solution?

   1. A business need is always more expensive
   2. A business need describes the problem; a solution describes how to fix it
   3. A business need comes from management; solutions come from IT
   4. There is no meaningful difference

NoteAnswer Key

1-c, 2-b, 3-b, 4-c, 5-b