1  Requirements and Stakeholder Management

In most data mining and data warehousing courses, the starting point is usually a clean database or a supervised learning algorithm such as decision trees or logistic regression. However, in the real world, analytical projects do not begin with data ready to be processed. They begin with a business need, a vague question, or an operational problem expressed by people who do not necessarily understand algorithms or dimensional modeling.

The success of a data project is not measured by the accuracy of the model (for example, an AUC of 0.95), but by the economic or strategic impact it generates for the organization. Therefore, the initial phase of any successful data project, Business Understanding (the initial phase of the CRISP-DM methodology that we will study later in the course (Chapman et al. 2000)), is the most critical. Before writing the first line of code or importing modeling libraries, we must deeply understand what the organization seeks to solve. To execute this successfully, it is essential to master communication with stakeholders (interested parties) and translate their qualitative needs into structured quantitative technical problems.

1.1 Identification of Stakeholders

Definition (stakeholder or interested party). According to the Community Tool Box framework from the University of Kansas (Center for Community Health and Development, University of Kansas 2023), a stakeholder is any person, group, or organization that can be affected by a project, or that can directly or indirectly influence its development and success. This definition builds upon the classic stakeholder theory proposed by Freeman (1984) and widely adopted in modern project management.

In analytics and data mining projects, identifying stakeholders makes it possible to understand who will use the results, who might be affected, and who has the capacity to guide or decide the project’s direction. Following the identification and analysis techniques described by Bryson (2004), stakeholders can be studied using two complementary criteria: their relationship with the organization and their role within the project.

1.1.1 Classification by Relationship with the Organization

One way to classify stakeholders is based on their relationship with the organization responsible for the project.

Stakeholders by Relationship with the Organization

Organization

Internal Stakeholders

Part of the organization and directly participate in its decisions, processes, or activities.

Owners
Shareholders
Executives
Employees

External Stakeholders

Not part of the organization, but may be affected by or influence its activities.

Customers
Community
Suppliers
Government
Banks
Authorities

1.1.2 Classification by Role in the Project

This second classification does not replace the previous one. The same stakeholder can be internal or external while simultaneously being primary, secondary, or key.

Stakeholders by Role in the Project

Analytical Project

Primary

Directly receive the benefits or consequences of the project results.

Examples:
end users, customers, and operators.

Secondary

Indirectly affected because the project modifies their processes, responsibilities, or environment.

Examples:
IT teams, DBAs, and legal department.

Key

Have authority, influence, specialized knowledge, or funding capacity over the project.

Examples:
sponsors, executives, and regulators.
Important: categories can overlap. A key stakeholder can also be primary or secondary, depending on how they participate in the project.

1.1.3 Example: An International Airport

In the operations of an international airport, internal stakeholders can be identified, such as the airport authority, security personnel, and operational managers; and external stakeholders, such as passengers, airlines, suppliers, ground transportation companies, government agencies, and investors.

If an analytical system is developed to predict delays, passengers, pilots, and operators could be considered primary stakeholders; service providers and ground transportation companies, secondary stakeholders; and the airport authority, regulatory bodies, and project sponsors, key stakeholders.

The classification depends on the scope of the project and how each actor is affected or can influence decisions.

1.2 Stakeholder Analysis: The Power vs. Interest Grid

To manage expectations efficiently and prevent a lack of alignment from derailing a data project, the Power vs. Interest Grid (also known as the Influence/Interest Matrix) is used. Originally proposed by Mendelow (1981) and adopted as a standard stakeholder management practice by the PMBOK Guide (Project Management Institute 2017), this tool classifies stakeholders on a grid based on two key dimensions:

  1. Power (Influence): The ability to change the project direction, allocate resources, approve deliverables, or cancel it entirely.
  2. Interest: The level of attention and concern the stakeholder has regarding the impact of the project on their area.

Below is the strategic alignment matrix diagram for data analytics projects:

High Power
Low Power

Keep Satisfied

High Power, Low Interest. Engage at key security, legal, and IT touchpoints to avoid late blockages.

Manage Closely

High Power, High Interest. Sponsors and key business leaders. Strategic project partners.

Monitor

Low Power, Low Interest. Minimal communication effort. Passive progress tracking.

Keep Informed

Low Power, High Interest. Operational model users. Provide valuable feedback.

Low Interest
High Interest

1.2.1 Quadrant Management Strategies

  • High Power, High Interest (Manage Closely): Must actively participate in project planning phases, validate intermediate deliverables, and receive regular progress reports.
  • High Power, Low Interest (Keep Satisfied): Engage at critical checkpoints. It is essential to ensure that the project complies with security, governance, and cloud governance regulations.
  • Low Power, High Interest (Keep Informed): Keep them enthusiastic and informed about how the model will ease their work. Requesting early feedback is vital.
  • Low Power, Low Interest (Monitor): Passively monitor with general communication.

1.3 Scope Definition and Translation of Business Questions

One of the most frequent errors in analytics projects is accepting a business question as originally phrased and immediately starting to work with the data. Expressions such as “we want to prevent customers from leaving” or “we need to increase sales” convey a legitimate concern, but they do not yet constitute an analytical objective.

The analyst’s role is not solely to extract data or build models. They must also act as a translator between business needs and the organization’s analytical capabilities. This involves transforming a general concern into a concrete, measurable question tied to a decision.

Scope definition—or scoping—is the process by which the following are clarified:

  • the problem to be solved;
  • the decision to be taken based on the result;
  • the population or unit of analysis;
  • the relevant time frame;
  • the success metrics;
  • operational constraints;
  • and the expected delivery format.

Only after establishing these elements does it make sense to evaluate what data is available and what methodology could be used.

This translation is the starting point for any analytical project. Once the business need is understood, the team can study the available data, prepare it, perform the analysis, evaluate whether the results answer the original question, and, when necessary, deploy a solution into production. Therefore, scope definition is not a formality prior to analysis: it is the stage that guides all subsequent decisions.

1.3.1 From Business Problem to Analytical Objective

A qualitative question must pass through several layers of definition before becoming a technical objective. The goal is not to replace stakeholder language with statistical jargon, but to build a shared specification that connects analysis with concrete action.

1. Need
Business question
“We want to prevent customers from leaving.”
→
2. Refinement
Analytical translation
Define churn, population, time horizon, variables, and expected action.
→
3. Specification
Quantitative objective
Estimate which customers have the highest probability of cancelling their subscription in the next 30 days.

In this example, the outcome of the process is not yet the selection of an algorithm. Deciding in advance that XGBoost, Random Forest, or any other technique will be used can restrict the analysis before understanding the problem. The methodology should be chosen after confirming the objective, reviewing the data, and establishing how the solution’s utility will be evaluated.

1.4 Iterative Refinement Through Questioning

A stakeholder’s initial question rarely contains all the necessary context. Therefore, scope definition should be treated as an iterative conversation rather than a single-pass questionnaire.

A useful strategy is to move forward layer by layer. Each response allows for formulating a more precise question, detecting assumptions, and returning to the stakeholder to validate understanding. The cycle ends when both parties can clearly articulate what will be analyzed, what it will be used for, and how a useful outcome will be recognized.

Objective Refinement Cycle
Each response generates a more specific question and a new validation opportunity.
LAYER 1
Context
What situation prompted the request?
→
LAYER 2
Decision
What decision will change with the analysis?
→
LAYER 3
Measurement
What metric represents the expected outcome?
→
LAYER 4
Scope
To whom, when, and under what constraints does it apply?
→
LAYER 5
Validation
Does this formulation represent the true need?
↺ If ambiguities, unconfirmed assumptions, or new constraints appear, return to the corresponding layer and reformulate the objective.

1.4.1 Strategies for Asking Better Questions

Several inquiry strategies can be combined during this cycle:

  1. Ask about context before asking about the solution.
    Instead of starting with “what dashboard do you need?”, it is better to ask “what situation motivated this request?”. This avoids confusing delivery format with the problem to be solved.

  2. Connect analysis with a decision.
    Questions such as “what would you do differently if you had this information?” help determine if the analysis will have a concrete application. If no decision is attached, the request may still be too broad.

  3. Turn ambiguous concepts into operational definitions.
    Terms like active customer, churn, success, profitability, or underperformance can mean different things across departments. The analyst must ask how they are practically observed and calculated.

  4. Define population, timeframe, and level of detail.
    It is necessary to specify whether analysis will be conducted by customer, transaction, product, store branch, or region, as well as establishing the relevant historical window and future horizon.

  5. Explore constraints and actionability.
    Detecting a pattern is not enough if the organization cannot act upon it. Ask what interventions are available, their cost, and how many cases the team can handle.

  6. Reformulate and validate.
    After listening to responses, the analyst should summarize the shared understanding: “So, what we need is…”. This reformulation allows the stakeholder to correct misinterpretations before investing time in analysis.

1.4.2 Example of a Refinement Conversation

Suppose a stakeholder presents the following need:

“We want to prevent customers from leaving.”

The conversation might progress as follows:

  • Context: What recent behavior indicates that a churn problem exists?
  • Definition: What exactly does it mean for a customer to “leave”: cancel, stop purchasing, or remain inactive?
  • Population: Does the issue affect all customers or a specific segment?
  • Horizon: How far in advance do we need to identify the risk?
  • Decision: What action will be taken when a customer is flagged as high-risk?
  • Capacity: How many customers can the retention team contact each week?
  • Success: How will success be measured: churns prevented, revenue retained, or campaign ROI?
  • Validation: Is the priority to identify as many potential churners as possible, even if it leads to some false positives?

After this iteration, the original question might be reformulated as follows:

Analytical Objective: Identify weekly monthly-subscription customers with the highest probability of cancelling over the next 30 days, using their activity over the last 90 days, to prioritize up to 2,000 contacts for the retention team. The solution will be evaluated on its ability to identify actual cancellations and on revenue retained through intervention.

This formulation establishes a target population, observation window, prediction horizon, operational capacity, and metric of business value. From here, the team can evaluate data availability and compare candidate methodologies.

1.5 Examples of Business Question Translation

Stakeholder Question Analytical Translation Possible Methodology
How can we increase average order value in the online store? Identify products that tend to be purchased together and evaluate which combinations could be used in recommendation systems during checkout. Association rules—Apriori or FP-Growth—evaluated via support, confidence, and lift.
How do we prevent customer churn in monthly subscriptions? Estimate cancellation probability during the next 30 days based on recent activity, aiming to prioritize retention interventions. Supervised classification models evaluated with metrics aligned with operational capacity and intervention costs.
We want personalized campaigns, but don’t know how to group customers. Identify customer clusters displaying similar recency, frequency, monetary value, and purchasing patterns. RFM segmentation and clustering techniques like K-Means or DBSCAN, paired with profile interpretation.
We need to know if end-of-year discounts worked. Estimate the net margin effect of discounts and isolate it from seasonal shifts or concurrent factors. Causal inference or quasi-experimental analysis, depending on control group availability and historical data.

These methodologies are starting points, not automated decisions. The final choice depends on data quality, underlying assumptions, and how the results will be operationalized.

1.6 The Data Request Process

Once the objective is validated, the agreement should be recorded. The Data Request is the formal mechanism through which business units communicate a need to the analytics team and document context, scope, and success criteria.

Definition — Data Request: A formal process, typically represented via an intake form or ticket, that captures business needs and key details to evaluate, prioritize, and execute an analytical project.

The request ticket does not replace conversation with the stakeholder. Its function is to preserve agreements reached during refinement and minimize subsequent ambiguity.

1.6.1 Key Elements of a Data Request Ticket

  1. Main Problem or Question
    What situation needs to be understood, solved, or improved?

  2. Business Context
    Why did this need arise, and why is it relevant now?

  3. Expected Action or Decision
    What will be done differently based on the result?

  4. Population and Scope
    Which customers, products, transactions, regions, or time periods are included?

  5. Success Metrics
    How will the business determine if the analysis was useful?

  6. Known or Suggested Data Sources
    Are there existing tables, files, systems, or third-party providers with relevant data?

  7. Delivery Format
    Is an exploratory analysis, report, dashboard, prioritized list, experiment, or embedded model required?

  8. Validation Lead
    Who will sign off on definitions, results, and downstream decisions?

  9. Constraints and Risks
    Are there timelines, privacy concerns, budget limits, operational capacities, or data quality risks?

  10. Target Decision Date
    By when must the results be delivered to remain actionable?

1.7 Conclusion

The quality of an analytical project depends heavily on the quality of the originating question. An ambiguous goal can produce technically sound but useless analysis; a well-defined goal enables coherent selection of data, metrics, and methods.

Defining scope means building a shared understanding between the stakeholder and data team. To achieve this, analysts must ask, listen, reformulate, and validate iteratively. The result is not merely a technical question, but an explicit bridge between data, decisions, and business value.

1.8 Practical Case Study: Alignment at TheLook eCommerce

Imagine you are hired as the Lead Data Analyst at TheLook eCommerce (the recurring case study used throughout this course). The Marketing Director approaches you with the following request:

“I need a report with all customers and everything they buy because women’s clothing sales fell this month and we want to launch a discount.”

If you act reactively, you will write a heavy SQL query, export a multi-gigabyte CSV with millions of rows, and email it. This is a direct path to project failure: the stakeholder will fail to open the file due to size limits, or spend hours filtering Excel without extracting clear conclusions.

1.8.1 The Strategic Alignment Conversation

  • You (Analyst): “To refine the data extraction, what is the target of the discount campaign? Are we looking to win back inactive customers, or encourage active buyers to try higher-margin categories?”
  • Director (Stakeholder): “We want to encourage customers who regularly buy designer dresses to explore our new high-margin luxury accessories line.”
  • You (Analyst): “Great. Instead of exporting all customers, I will pull a focused report on high-frequency buyers in the women’s/dresses category. I will also run an association rule model to identify which accessories are most commonly bought alongside dresses to suggest targeted bundles.”

Outcome: You saved technical effort from extracting entire databases, delivered a high-impact analysis targeting high-margin conversions, and aligned business expectations from day one.

1.9 References

Bishop, Christopher M. 2006. Pattern Recognition and Machine Learning. Information Science and Statistics. Springer.
Breiman, Leo. 2001. “Random Forests.” Machine Learning 45 (1): 5–32. https://doi.org/10.1023/A:1010933404324.
Breiman, Leo, Jerome H. Friedman, Richard A. Olshen, and Charles J. Stone. 1984. Classification and Regression Trees. Wadsworth International Group.
Fawcett, Tom. 2006. “An Introduction to ROC Analysis.” Pattern Recognition Letters 27 (8): 861–74. https://doi.org/10.1016/j.patrec.2005.10.010.
Fisher, Ronald A. 1936. “The Use of Multiple Measurements in Taxonomic Problems.” Annals of Eugenics 7 (2): 179–88. https://doi.org/10.1111/j.1469-1809.1936.tb02137.x.
Friedman, Jerome H. 2001. “Greedy Function Approximation: A Gradient Boosting Machine.” Annals of Statistics 29 (5): 1189–232. https://doi.org/10.1214/aos/1013203451.
Gauss, Carl Friedrich. 1809. Theoria Motus Corporum Coelestium in Sectionibus Conicis Solem Ambientium. Friedrich Perthes und I.H. Besser.
Golub, Gene H., and Charles F. Van Loan. 2013. Matrix Computations. 4th ed. Johns Hopkins University Press.
Han, Jiawei, Micheline Kamber, and Jian Pei. 2011. Data Mining: Concepts and Techniques. 3rd ed. Morgan Kaufmann. https://doi.org/10.1016/B978-0-12-381479-1.00001-0.
Hastie, Trevor, Robert Tibshirani, and Jerome Friedman. 2009. The Elements of Statistical Learning: Data Mining, Inference, and Prediction. 2nd ed. Springer Series in Statistics. Springer. https://doi.org/10.1007/978-0-387-84858-7.
Hoerl, Arthur E., and Robert W. Kennard. 1970. “Ridge Regression: Biased Estimation for Nonorthogonal Problems.” Technometrics 12 (1): 55–67. https://doi.org/10.1080/00401706.1970.10488634.
James, Gareth, Daniela Witten, Trevor Hastie, and Robert Tibshirani. 2021. An Introduction to Statistical Learning with Applications in R. 2nd ed. Springer Texts in Statistics. Springer. https://doi.org/10.1007/978-1-0716-1418-1.
Kimball, Ralph, and Margy Ross. 2013. The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling. 3rd ed. Wiley.
Kohavi, Ron. 1995. “A Study of Cross-Validation and Bootstrap for Accuracy Estimation and Model Selection.” Proceedings of the 14th International Joint Conference on Artificial Intelligence (IJCAI) 2: 1137–43.
Legendre, Adrien-Marie. 1805. Nouvelles méthodes Pour La détermination Des Orbites Des Comètes. Firmin Didot.
Minsky, Marvin, and Seymour Papert. 1969. Perceptrons: An Introduction to Computational Geometry. MIT Press.
Murphy, Kevin P. 2012. Machine Learning: A Probabilistic Perspective. MIT Press.
Novikoff, Albert B. J. 1962. “On Convergence Proofs for Perceptrons.” Proceedings of the Symposium on the Mathematical Theory of Automata (Brooklyn, NY) 12: 615–22.
Pedregosa, Fabian, Gaël Varoquaux, Alexandre Gramfort, et al. 2011. “Scikit-Learn: Machine Learning in Python.” Journal of Machine Learning Research 12: 2825–30. https://jmlr.org/papers/v12/pedregosa11a.html.
Powers, David M. W. 2011. “Evaluation: From Precision, Recall and f-Factor to ROC, Informedness, Markedness and Correlation.” Journal of Machine Learning Technologies 2 (1): 37–63. https://arxiv.org/abs/2010.16061.
Provost, Foster, and Tom Fawcett. 2013. Data Science for Business: What You Need to Know about Data Mining and Data-Analytic Thinking. O’Reilly Media.
Rosenblatt, Frank. 1958. “The Perceptron: A Probabilistic Model for Information Storage and Organization in the Brain.” Psychological Review 65 (6): 386–408. https://doi.org/10.1037/h0042519.
Saito, Takaya, and Marc Rehmsmeier. 2015. “The Precision-Recall Plot Is More Informative Than the ROC Plot When Evaluating Binary Classifiers on Imbalanced Datasets.” PLOS ONE 10 (3): e0118432. https://doi.org/10.1371/journal.pone.0118432.
Sokolova, Marina, and Guy Lapalme. 2009. “A Systematic Analysis of Performance Measures for Classification Tasks.” Information Processing & Management 45 (4): 427–37. https://doi.org/10.1016/j.ipm.2009.03.002.
Stone, Mervyn. 1974. “Cross-Validatory Choice and Assessment of Statistical Predictions.” Journal of the Royal Statistical Society: Series B 36 (2): 111–47. https://doi.org/10.1111/j.2517-6161.1974.tb00994.x.
Vapnik, Vladimir N. 1998. Statistical Learning Theory. Wiley.