Business Problem Framing and Stakeholder Analysis

Introduction

A business analytics capstone project begins before data are collected, software is selected, or models are trained. It begins with a decision that matters. An organisation may be experiencing declining customer retention, inefficient inventory, delayed service delivery, rising fraud, or weak workforce planning. These situations are not yet analytics problems. They are organisational conditions that must be translated into a form suitable for systematic investigation.

Business problem framing is the disciplined process of converting an organisational challenge into a clear problem statement, research questions, analytics objectives, decision criteria, and measurable indicators of success. Stakeholder analysis complements this process by identifying the people and groups who influence, use, experience, or are affected by the project.

Poor framing creates predictable problems: irrelevant data collection, technically impressive but unusable models, disagreement about success, and recommendations that cannot be implemented. Strong framing establishes a shared understanding of the problem and connects analytical work to organisational decisions.

Learning Objectives

By the end of this chapter, you should be able to:

1. Distinguish symptoms, problems, causes, decisions, and analytics tasks.
2. Develop a precise and evidence-based business problem statement.
3. Translate a business problem into research questions and analytics objectives.
4. Identify, classify, and prioritise stakeholders.
5. Apply systems thinking and logic models to complex organisational problems.
6. Define decision criteria, constraints, assumptions, and measurable success indicators.
7. Recognise ethical, governance, and implementation risks in problem framing.
8. Evaluate the quality and feasibility of a proposed capstone problem.

1. From Organisational Challenge to Analytics Problem

1.1 Symptoms, problems, causes, and decisions

A symptom is an observable indication that something may be wrong. For example, “monthly cancellations have increased” is a symptom. A problem is the undesirable condition that requires attention, such as “the organisation is losing profitable customers because preventable service failures are not being identified early.” A cause is a mechanism that contributes to the problem, such as delayed complaint resolution or unsuitable pricing. A decision is an action or choice that the organisation must make, such as which customers should receive retention interventions.

These categories should not be confused:

An analytics project should not automatically accept the first explanation offered by a stakeholder. “We need an artificial intelligence system” is a proposed solution, not a problem definition. The analyst should ask: What decision will the system support? Who will use its output? What action follows from a prediction? What evidence would change the decision?

1.2 Descriptive, diagnostic, predictive, and prescriptive questions

Business questions can be grouped according to the type of knowledge required:

• Descriptive: What happened? What is happening? For example, which product categories have the highest return rates?
• Diagnostic: Why did it happen? For example, are returns associated with delivery delays, product defects, or customer segment?
• Predictive: What is likely to happen? For example, which accounts are at high risk of cancellation next quarter?
• Prescriptive: What should be done? For example, which intervention is expected to reduce cancellations at acceptable cost?

These categories are related but not interchangeable. A predictive model may estimate risk without establishing causation. A dashboard may describe performance without explaining its drivers. A prescriptive recommendation requires knowledge of feasible actions, constraints, and likely consequences.

1.3 A high-quality problem statement

A useful problem statement is specific enough to guide investigation while remaining open to evidence. It normally identifies:

• the organisational context;
• the affected population, process, or asset;
• the undesirable outcome and its magnitude, where known;
• the decision or performance gap;
• the time period and scope;
• the consequences of inaction; and
• the evidence currently available and its limitations.

A practical structure is:

In [context], [affected population or process] is experiencing [measurable undesirable condition] during [time period]. This affects [organisational outcome] and creates a need to decide [decision]. The project will investigate [relevant drivers or evidence] within [scope and constraints].

For example:

Between January and December 2025, the regional service centre experienced a rise in average resolution time from 36 to 51 hours. The increase has reduced customer satisfaction and breached service-level commitments. Managers need to determine which operational factors are associated with delay and how staffing or case-allocation decisions could reduce resolution time without increasing cost.

This statement does not prematurely assume that staffing is the cause. It also identifies a decision and measurable outcome.

2. Stakeholder Analysis

2.1 Who is a stakeholder?

A stakeholder is an individual, group, or institution that can affect the project, is affected by it, has a legitimate interest in it, or controls resources and information relevant to it. Stakeholders may include executive sponsors, operational managers, analysts, employees, customers, suppliers, regulators, technology teams, data owners, and communities.

Stakeholders differ in their interests and forms of influence. A data protection officer may have high authority over permissible data use but no interest in the commercial objective. Front-line employees may have limited formal authority but extensive process knowledge and may experience the greatest operational impact.

2.2 Stakeholder identification

Begin with the decision rather than with a generic organisational chart. Ask:

1. Who owns the decision?
2. Who supplies or controls the data?
3. Who understands the process being analysed?
4. Who will use the output?
5. Who will implement the recommendation?
6. Who bears risks or unintended consequences?
7. Who can approve, block, or challenge the project?

Stakeholders should be identified through interviews, project documentation, process maps, data inventories, and consultation with the sponsor. Snowball questioning—asking each interviewee who else should be consulted—often reveals less visible groups.

2.3 Power-interest analysis

A common prioritisation method classifies stakeholders by relative power and interest:

This matrix is a starting point, not a substitute for judgement. A stakeholder’s apparent power may change during implementation. For example, a front-line team with low formal authority may determine whether a new process is actually adopted.

Other useful dimensions include legitimacy, urgency, expertise, proximity to affected people, and ability to provide data. A stakeholder register should record the person or group, role, interests, influence, expected contribution, concerns, communication needs, and proposed engagement method.

2.4 Stakeholder conflict and negotiation

Stakeholders may define success differently. A finance director may prioritise cost reduction, a service manager may prioritise response time, and employees may prioritise workload fairness. These are not merely communication problems; they are competing objectives.

The analyst should make the conflict explicit and seek agreed decision criteria. A project might define a feasible solution as one that reduces average resolution time by at least 10%, does not increase monthly operating cost by more than 3%, and does not reduce the proportion of cases meeting accessibility requirements. Making trade-offs visible improves both governance and credibility.

3. Research Questions and Analytics Objectives

3.1 From problem statement to research question

A research question expresses what the project seeks to learn. It should be answerable using available or obtainable evidence and should connect to a decision.

Weak question: “Can machine learning predict customer churn?”

Stronger question: “Which observable customer and service factors are associated with cancellation within the next 90 days, and how accurately can risk be estimated early enough to support a cost-effective retention action?”

The stronger version specifies the outcome, time horizon, decision use, and practical timing.

A capstone may use a hierarchy of questions:

• Primary question: What central issue will the study answer?
• Descriptive sub-question: What is the current pattern or baseline?
• Explanatory sub-question: Which factors are associated with variation?
• Predictive sub-question: How accurately can the outcome be estimated?
• Decision sub-question: What action is justified under stated constraints?

Questions should avoid implying causality unless the design can support causal inference. The terms “causes,” “effect,” and “impact” require stronger evidence than “associated with” or “predicts.”

3.2 Analytics objectives

An analytics objective converts a research question into a deliverable or analytical task. Effective objectives are specific, measurable, achievable, relevant, and time-bounded, although the familiar SMART formulation should not be applied mechanically.

Examples include:

• establish a baseline for average resolution time by service centre and case type;
• identify process variables associated with cases exceeding 48 hours;
• develop and evaluate a risk-ranking model using historical data available at case assignment;
• compare proposed intervention options against cost, service, fairness, and implementation criteria;
• produce a dashboard and operating recommendation for the service manager.

An objective should name the population, outcome, time frame, evidence, and intended use where possible. “Analyse the data” is not an adequate objective because it does not specify what will be produced or why.

3.3 Scope, assumptions, and constraints

Scope defines what is included and excluded. It may specify business units, geography, products, time period, customer segment, process stage, or outcome. Constraints may include limited historical data, missing fields, privacy requirements, staff capacity, system integration, budget, and project duration.

Assumptions should be recorded rather than hidden. Examples include:

• historical records reasonably represent the process under study;
• the outcome definition is consistent across reporting periods;
• data available at the time of a decision do not include future information;
• the proposed intervention can be implemented within the stated resource limits.

A useful distinction is between an assumption that can be tested and a limitation that cannot be removed within the project. Both must be communicated to decision-makers.

4. Systems Thinking and Logic Models

4.1 Why systems thinking matters

Organisations are systems of interacting processes, people, technologies, incentives, and external conditions. Optimising one measure may worsen another. For example, reducing call duration may improve productivity statistics while lowering first-contact resolution and increasing repeat calls.

Systems thinking encourages the analyst to examine:

• inputs and resources;
• activities and process stages;
• outputs;
• outcomes and longer-term impacts;
• feedback loops;
• delays and bottlenecks;
• unintended consequences; and
• boundaries between the focal system and its environment.

A problem should therefore be framed at the level of the decision system, not just the data table.

4.2 Logic models

A logic model connects resources to results:

Inputs → Activities → Outputs → Short-term outcomes → Longer-term impacts

For a workforce scheduling project:

• Inputs: historical demand, staff availability, scheduling rules, budget.
• Activities: forecast demand and construct shift recommendations.
• Outputs: schedules and exception alerts.
• Short-term outcomes: improved coverage and fewer understaffed periods.
• Longer-term impacts: lower waiting time and improved customer satisfaction.

A logic model helps distinguish what the analytics team controls from what it merely influences. A model can produce a forecast, but it cannot guarantee an outcome if managers do not implement the recommendation or if external demand changes.

4.3 Causal caution

A logic model expresses an intended pathway, not proof of causality. If the project claims that an intervention causes improvement, it needs an appropriate evaluation design. Possible designs include controlled experiments, quasi-experiments, interrupted time series, matched comparisons, or carefully justified before-and-after analysis. Observational associations can inform hypotheses and predictions but may be confounded by unmeasured factors.

5. Decision Criteria and Success Indicators

5.1 From analysis to decision

Analytics becomes valuable when it changes a decision or improves the quality of an existing decision. Decision criteria specify how alternatives will be judged. They may include:

• expected financial value;
• service quality;
• operational feasibility;
• implementation time;
• risk and compliance;
• customer or employee experience;
• fairness and accessibility;
• explainability and auditability; and
• resilience under changing conditions.

Criteria should be agreed before results are seen where possible. Otherwise, stakeholders may move the goalposts in response to inconvenient findings.

5.2 Quantitative indicators

A success indicator should have a clear definition, numerator and denominator where relevant, population, time frame, data source, and target. For example, service-level compliance may be defined as:

The indicator is meaningful only if “eligible case,” “resolved,” and “target time” are defined consistently. A percentage has no value if the denominator changes without explanation.

For a project intended to reduce average resolution time, a simple relative improvement measure is:

Here, the baseline mean and post-intervention mean must use comparable populations and time periods, and lower values must genuinely represent improvement. If the baseline is 51 hours and the post-intervention mean is 45 hours:

This calculation describes change; by itself it does not establish that the project caused the change.

5.3 Model-performance criteria and business criteria

Technical metrics should not replace business success indicators. A classifier may have high overall accuracy while missing the cases that matter most. Depending on the decision, relevant measures may include precision, recall, calibration, ranking quality, cost-weighted error, or service-level impact. The selected metric must reflect the consequences of false positives and false negatives.

For example, if a retention team has capacity to contact only 500 customers, a ranking model may be evaluated by the value generated among the top 500 cases, not merely by its overall accuracy. A project should also state the performance threshold required for action and what happens when the threshold is not met.

6. An Integrated Framing Workflow

A practical capstone workflow is iterative rather than strictly linear:

1. Discover the decision context. Interview decision owners and review performance evidence.
2. Describe the current state. Establish definitions, baselines, process boundaries, and known variation.
3. Map stakeholders. Identify authority, expertise, impact, data access, and concerns.
4. Construct a problem statement. Separate symptoms from causes and decisions.
5. Develop a logic model or system map. Identify mechanisms, feedback, and unintended effects.
6. Formulate research questions. Ensure each question can be answered within the scope.
7. Specify analytics objectives. Link each objective to a deliverable and decision use.
8. Define criteria and indicators. Agree targets, constraints, trade-offs, and measurement rules.
9. Check feasibility and ethics. Assess data quality, privacy, fairness, security, and implementation capacity.
10. Validate with stakeholders. Revise the framing before substantial modelling begins.

A framing document should normally contain the context, problem statement, decision owner, stakeholders, research questions, scope, assumptions, data sources, logic model, success indicators, risks, and governance arrangements.

7. Illustrative Case: Reducing Missed Appointments

Background

The following is a fictional illustrative case. A community health network reports that 18% of scheduled outpatient appointments are missed. Managers believe text reminders will solve the issue, but they do not know whether missed appointments are concentrated in particular services or whether reminder timing is the main driver.

Problem

The initial statement—“The organisation needs an AI model to predict no-shows”—is solution-led. Interviews reveal that missed appointments create unused clinical capacity, delay care, and increase administrative work. Patients may face transport, work, language, accessibility, or scheduling barriers. The actual decision is how to allocate limited reminder and support resources without unfairly burdening particular groups.

A revised problem statement is:

The network has experienced an 18% outpatient no-show rate over the last six months, with substantial variation by clinic and appointment type. Missed appointments reduce capacity and may delay patient care. Managers need evidence about the factors associated with non-attendance and guidance on which reminder or support actions are feasible, effective, and equitable.

Stakeholders

The stakeholders include the clinical operations director, clinic managers, scheduling staff, clinicians, patients, the information governance officer, the data engineering team, and community-access representatives. Patients and front-line staff have high interest and important contextual knowledge, even though they may have less formal decision power than the director.

Research questions

1. What are the baseline no-show rates by clinic, appointment type, lead time, and patient communication preference?
2. Which factors observable at the time of scheduling are associated with non-attendance?
3. Which reminder or support options are operationally feasible and ethically acceptable?
4. How should limited intervention capacity be allocated while monitoring access and fairness?

Logic model

Inputs include appointment records, reminder history, communication preferences, transport information where lawfully available, and staff capacity. Activities include descriptive analysis, risk estimation, stakeholder review, and a pilot of alternative reminders. Outputs include a baseline report, a transparent prioritisation rule, and a pilot evaluation. Short-term outcomes are improved attendance and reduced unused capacity. Longer-term impacts may include improved access and continuity of care.

Decision criteria

The proposed approach must:

• reduce the no-show rate by a pre-agreed absolute amount during the pilot;
• remain within communication and staff-capacity limits;
• comply with health-data and privacy requirements;
• avoid using sensitive characteristics as unjustified exclusion rules;
• provide an understandable reason for prioritisation; and
• monitor whether some patient groups experience reduced access or excessive contact.

Approach and outcome

The team first creates a data dictionary and confirms that reminder status refers to messages actually sent, not merely scheduled. It establishes a baseline by clinic and checks missingness and inconsistent appointment codes. Rather than deploying an opaque model immediately, the team proposes a transparent risk-ranking rule based only on information available at scheduling. A small pilot compares standard reminders with enhanced reminders offering translation and rescheduling links.

The pilot evaluation compares attendance rates for comparable groups and records contact burden, rescheduling, complaints, and subgroup outcomes. The project does not claim that a risk score alone causes improvement. It evaluates the complete intervention pathway: identification, contact, patient response, and operational follow-through.

Learning points

The case illustrates five principles. First, the important question concerns a decision, not a technology. Second, stakeholder analysis identifies barriers that administrative data may not show. Third, a logic model clarifies how analysis is expected to produce change. Fourth, success includes equity, privacy, and feasibility as well as attendance. Fifth, problem framing should be revised when new evidence challenges the initial assumption.

8. Ethical, Governance, and Implementation Considerations

Problem framing determines what is measured and whose interests count. Analysts should consider privacy, lawful basis for processing, data minimisation, purpose limitation, access controls, retention, and secure handling. Sensitive personal data require particular caution, especially in health, employment, credit, education, and public-service settings.

Fairness should be considered before modelling, not only after deployment. Relevant questions include: Which groups may be underrepresented? Could a proxy variable reproduce discrimination? Are errors distributed unevenly? Will an intervention restrict opportunity or increase surveillance? Is there a process for human review, appeal, and correction?

Stakeholder consent is not a substitute for legal compliance, and legal compliance is not proof that a project is ethically acceptable. Governance should specify accountability, documentation, model or rule review, incident management, and monitoring after implementation.

Implementation risk is also a framing issue. A recommendation may fail because staff lack time, systems cannot integrate, incentives conflict, or the proposed action is too complex. Analysts should therefore engage implementers early and define what will happen when data are missing, predictions are uncertain, or the recommended action is unavailable.

9. Common Errors and Best Practices

Common errors

• Starting with a preferred technology rather than a decision.
• Treating a symptom as an established cause.
• Defining a problem so broadly that it cannot be completed in a capstone.
• Ignoring stakeholders with low formal power.
• Using vague outcomes such as “improve efficiency.”
• Measuring model performance without assessing business impact.
• Including information that would not be available at decision time.
• Presenting association as causation.
• Failing to define the denominator, baseline, or time period.
• Treating stakeholder agreement as evidence that the framing is true.

Best practices

Use plain language and operational definitions. Maintain a decision-to-data traceability table showing how each question links to data, analysis, output, and action. Record alternative explanations. Validate the framing with both decision owners and people affected by the decision. Establish a baseline before selecting a target. Treat privacy, fairness, and implementation as design requirements. Revisit the framing when data-quality checks or stakeholder evidence reveal that the original assumptions were wrong.

Chapter Summary

Business analytics begins with a well-framed organisational decision, not with a tool or algorithm. A strong problem statement distinguishes symptoms, problems, causes, decisions, and analytics tasks. Research questions convert the problem into answerable inquiries, while analytics objectives specify practical deliverables.

Stakeholder analysis identifies authority, interest, expertise, data control, affected groups, and implementation responsibility. Power-interest mapping helps prioritise engagement, but low-power stakeholders may possess essential knowledge or bear significant consequences. Systems thinking and logic models connect inputs, activities, outputs, outcomes, impacts, feedback, and unintended effects. They also prevent analysts from assuming that a model automatically creates business value.

Decision criteria and success indicators make expectations measurable. Indicators require clear definitions, comparable populations, appropriate denominators, baselines, targets, and time periods. Technical model metrics must be connected to operational, financial, ethical, and implementation outcomes. Finally, privacy, fairness, governance, and feasibility must be addressed during framing rather than treated as afterthoughts.

Key Terms

Problem framing: Converting an organisational challenge into a structured decision and analytics inquiry.

Stakeholder: A person or group that affects, is affected by, or has a legitimate interest in a project.

Symptom: An observable indication of an undesirable condition.

Problem statement: A precise description of the condition, context, consequences, and decision need.

Decision owner: The person or group accountable for acting on project findings.

Analytics task: A defined analytical activity intended to support a decision.

Descriptive analytics: Analysis of what happened or is happening.

Diagnostic analytics: Analysis of possible reasons or drivers of an outcome.

Predictive analytics: Estimation of likely future or unknown outcomes.

Prescriptive analytics: Analysis of recommended actions under constraints.

Research question: An answerable question that guides investigation.

Analytics objective: A specific analytical deliverable linked to a research question and decision.

Scope: The stated boundaries of a project.

Assumption: A proposition accepted provisionally and subject to testing where possible.

Systems thinking: Analysis of interactions, feedback, boundaries, and consequences within a system.

Logic model: A representation linking inputs, activities, outputs, outcomes, and impacts.

Decision criterion: A rule or standard used to compare alternatives.

Success indicator: A measurable sign that a desired result has been achieved.

Baseline: The reference condition against which change is assessed.

Stakeholder register: A structured record of stakeholder roles, interests, influence, concerns, and engagement needs.

Review Questions

Short Answer Questions

1. Distinguish a symptom from a business problem and provide an example of each.
2. What is the purpose of a stakeholder register?
3. Explain the difference between a predictive and a prescriptive analytics question.
4. Why must the denominator of a performance indicator be defined?
5. What are the main components of a logic model?

Long Answer Questions

1. Explain how an organisational challenge can be transformed into a problem statement, research questions, and analytics objectives.
2. Compare the power-interest matrix with a broader stakeholder analysis that includes legitimacy, expertise, and impact.
3. Discuss how systems thinking can prevent unintended consequences in an analytics project.
4. Explain why technical model performance and business success are not equivalent.
5. Discuss the ethical and governance issues that should be considered before analysing personal data.

Analytical / Application Questions

1. A retailer reports that returns have increased by 20%. Develop a problem statement, three research questions, two analytics objectives, and four possible success indicators. State any assumptions.
2. A university wants to predict which students may withdraw. Identify at least six stakeholders, classify their interests and influence, and propose an engagement plan that addresses privacy and fairness.
3. A call centre wants to reduce average handling time. Construct a brief logic model and explain how reducing handling time could unintentionally affect service quality. Propose decision criteria that balance efficiency and customer outcomes.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a business problem from an analytics task?

A. A business problem is always a statistical hypothesis.

B. A business problem describes an undesirable organisational condition, while an analytics task specifies analysis that may support a decision.

C. A business problem is the software selected for analysis.

D. A business problem is identical to a dashboard requirement.

Correct Answer: B. A business problem describes an undesirable organisational condition, while an analytics task specifies analysis that may support a decision.

Question 2

Which question is primarily predictive?

A. What was the monthly cancellation rate last year?

B. Why did cancellations increase in March?

C. Which accounts are likely to cancel within the next 90 days?

D. Which retention action should managers implement?

Correct Answer: C. Which accounts are likely to cancel within the next 90 days?

Question 3

In a power-interest matrix, a stakeholder with high power and high interest should generally be:

A. Monitored with minimal communication.

B. Kept informed but not consulted.

C. Managed closely.

D. Excluded from project decisions.

Correct Answer: C. Managed closely.

Question 4

Which element belongs directly in a logic model between activities and outcomes?

A. Outputs

B. Stakeholder power

C. Model accuracy

D. Research paradigm

Correct Answer: A. Outputs

Question 5

A service process has a baseline mean resolution time of 51 hours and a post-intervention mean of 45 hours. What is the approximate relative improvement?

A. 6.0%

B. 8.5%

C. 11.8%

D. 15.3%

Correct Answer: C. 11.8%

Question 6

Which statement about observational association is correct?

A. It always proves that one variable causes another.

B. It can support prediction but does not by itself establish causation.

C. It is irrelevant to business analysis.

D. It eliminates the need for stakeholder validation.

Correct Answer: B. It can support prediction but does not by itself establish causation.

Question 7

Which feature makes a success indicator more meaningful?

A. It uses an undefined percentage.

B. It changes its denominator each reporting period.

C. It specifies the population, time frame, definition, and data source.

D. It is selected only after stakeholders see the results.

Correct Answer: C. It specifies the population, time frame, definition, and data source.

Question 8

Why should analysts distinguish information available at decision time from future information?

A. To prevent leakage that would make evaluation unrealistically optimistic.

B. To increase the number of variables in the dataset.

C. To guarantee causal inference.

D. To avoid defining the target outcome.

Correct Answer: A. To prevent leakage that would make evaluation unrealistically optimistic.

Question 9

Which is the strongest research question for a capstone project?

A. Can artificial intelligence solve customer service?

B. What is the best algorithm in the world?

C. Which observable factors are associated with delayed resolution, and how can findings support feasible staffing decisions?

D. Can all business problems be predicted?

Correct Answer: C. Which observable factors are associated with delayed resolution, and how can findings support feasible staffing decisions?

Question 10

Why should low-power, high-interest stakeholders not be ignored?

A. They always control the project budget.

B. They may possess important process knowledge and experience project consequences directly.

C. They automatically approve data use.

D. They replace the decision owner.

Correct Answer: B. They may possess important process knowledge and experience project consequences directly.