Analytics Processes, Projects and Technology Stack

Introduction

Business analytics is not simply the use of software to produce charts or predictive models. It is a managed process that connects an organisational question to evidence, analysis, decision, action and learning. Successful analytics projects therefore require more than technical skill. They require problem framing, stakeholder engagement, data management, appropriate methods, documentation, governance and reliable deployment.

This chapter examines CRISP-DM and related analytics lifecycles, project planning through agile experimentation, reproducibility, and the technology stack supporting modern analytics. It also explains how business intelligence platforms, programming environments, cloud services and specialist analytics roles fit together.

Learning Objectives

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

1. Explain the stages and logic of CRISP-DM.
2. Compare CRISP-DM with agile, OSEMN and data-product lifecycles.
3. Translate a business problem into an analytics problem and measurable success criteria.
4. Plan an analytics project using experiments, milestones, documentation and risk controls.
5. Explain reproducibility, version control, data lineage and model monitoring.
6. Distinguish the roles of BI platforms, programming tools, databases and cloud services.
7. Describe the responsibilities and collaboration patterns of an analytics team.
8. Evaluate ethical, operational and governance issues in analytics deployment.

1. From Business Question to Decision System

An analytics project begins with a decision, not a dataset. A retailer may ask, “Can we predict demand?” The more useful question is, “How can better weekly demand estimates reduce stockouts without creating excessive inventory?” The second formulation identifies a decision, a time horizon, constraints and a potential business outcome.

A useful chain is:

Business objective → decision question → analytical task → data product → operational action → measured outcome

For example:

Analytics success should be defined at several levels. Technical success may involve forecast error or classification accuracy. Business success may involve profit, service level or time saved. Adoption success concerns whether users trust and act on the output. A technically accurate model that is ignored by decision-makers is not a successful analytics product.

2. CRISP-DM: A Practical Analytics Lifecycle

CRISP-DM, or Cross-Industry Standard Process for Data Mining, is a widely used framework with six connected phases:

1. Business understanding
2. Data understanding
3. Data preparation
4. Modeling
5. Evaluation
6. Deployment

The framework is iterative rather than strictly linear. Evaluation may reveal that the original business objective is unclear; data preparation may expose the need for new data; deployment may reveal that users need a simpler output.

Figure: CRISP-DM is an iterative lifecycle in which feedback can return the project to an earlier phase.

2.1 Business Understanding

This phase establishes the organisational context. The team identifies stakeholders, decisions, constraints, benefits, risks and the definition of success. A project charter should record:

• the business problem and its causes;
• the decision owner and intended users;
• scope, exclusions and assumptions;
• available resources and deadlines;
• technical and regulatory constraints;
• baseline performance; and
• measurable success criteria.

A vague objective such as “improve customer analytics” should become a testable objective such as “reduce monthly voluntary customer churn by 5% within six months, subject to retention-offer costs remaining below a specified limit.”

Success criteria may include a business metric, a model metric and an operational metric. For a churn project, these might be retention value, recall among high-value customers, and the percentage of cases successfully delivered to account managers.

2.2 Data Understanding

Data understanding involves collecting initial data, describing its structure, exploring distributions and identifying quality problems. Analysts investigate missing values, duplicate records, inconsistent definitions, outliers, sampling bias and leakage.

A data dictionary should define fields, units, valid ranges, ownership, sensitivity and update frequency. Analysts must ask whether a variable was available at the time the decision was made. A feature recorded after a customer cancelled a service may predict churn extremely well but is unusable for prospective intervention; this is target leakage.

Exploratory analysis should combine summary statistics, visualisations and domain knowledge. Descriptive statistics alone cannot establish causation. A relationship between two variables may reflect confounding, selection effects or a time trend.

2.3 Data Preparation

Data preparation commonly consumes a large proportion of project time. Activities include joining sources, correcting types, handling missingness, constructing variables, filtering records and splitting data for evaluation.

Preparation must be performed in a way that prevents information from the evaluation set entering the training process. For example, the mean used to impute missing training values should be calculated from the training data and then applied to validation and test data. Otherwise, evaluation can be optimistically biased.

The project should preserve raw data where permitted, create documented transformed datasets and record each transformation. Data quality rules should specify what happens when a rule fails: reject the record, quarantine it, correct it or alert an owner.

2.4 Modeling

Modeling includes selecting an analytical method, training it, tuning parameters and comparing alternatives. Method selection should follow the decision context. A transparent scoring rule may be preferable to a complex model when explanations, auditability or rapid action are important.

A baseline is essential. For forecasting, a baseline might predict that next period equals the current period. For classification, it might always select the majority class or use a simple business rule. A complex model should demonstrate value beyond this baseline.

Data should generally be divided into training, validation and test sets. The training set estimates model parameters, the validation set supports method or hyperparameter selection, and the test set provides a final estimate of generalisation performance. The test set should not be repeatedly consulted during development.

2.5 Evaluation

Evaluation has two dimensions. Technical evaluation asks whether the model performs adequately on appropriate unseen data. Business evaluation asks whether the output supports a worthwhile and feasible decision.

For binary classification, a confusion matrix distinguishes true positives, false positives, true negatives and false negatives. Common measures include:

Here TP is the number of correctly identified positive cases, FP is the number of negative cases incorrectly classified as positive, and FN is the number of positive cases missed. Precision is useful when false alarms are costly; recall is important when missing a positive case is costly. These measures assume clearly defined positive and negative classes and should be interpreted with the relevant class prevalence.

For numerical prediction, mean absolute error is:

where n is the number of observations, yᵢ is the observed value and ŷᵢ is the prediction. MAE has the same units as the target and is less affected by large errors than mean squared error. The choice of metric should reflect the costs of different errors.

Evaluation should also consider fairness, stability, interpretability, latency, security and operational cost. A model can be statistically strong but inappropriate if it systematically disadvantages a protected group or cannot be maintained.

2.6 Deployment

Deployment means making analytical results available for use. It may involve a dashboard, scheduled report, application programming interface (API), embedded model, automated workflow or decision-support process. Deployment also requires ownership, access control, monitoring, documentation, training and a rollback plan.

A model is not “finished” when it is released. Data distributions, customer behaviour and business policies change. Monitoring should cover data quality, input drift, output drift, model performance where labels become available, service availability and user adoption. A documented threshold should specify when investigation, retraining or withdrawal is required.

3. Related Lifecycles and Agile Experimentation

CRISP-DM provides a useful structure, but it does not prescribe detailed project-management practices. Teams often combine it with agile delivery. Agile analytics uses short cycles, prioritised backlogs, stakeholder reviews and incremental releases.

An analytics backlog may contain data-access tasks, exploratory questions, feature experiments, dashboard components, validation activities and governance work. Each item should have an acceptance condition. For example: “Produce a weekly demand baseline for the top 100 products, with documented data lineage and error measured on the last eight weeks.”

An experiment should specify:

• hypothesis;
• intervention or analytical change;
• data and comparison method;
• success metric;
• time period;
• risks and stopping conditions; and
• decision rule after completion.

The OSEMN framework—Obtain, Scrub, Explore, Model and iNterpret—emphasises the practical flow of data work. Data-product lifecycles add user research, interface design, deployment and continuous improvement. A machine-learning operations (MLOps) lifecycle extends the process with automated testing, model registries, deployment pipelines and monitoring. These frameworks are complementary, not mutually exclusive.

Agile does not mean abandoning planning or documentation. It means planning at different levels: a strategic outcome, a near-term release and a next experiment. Teams should maintain a project charter, decision log, data dictionary, experiment register, code repository, model card or method note, and deployment runbook.

4. Reproducibility and Project Quality

Reproducibility means that an analysis can be rerun and produce the same result, or that differences can be explained. It requires more than saving a final spreadsheet. Important practices include:

• version-controlled code and documentation;
• explicit package and runtime versions;
• stable random seeds where appropriate;
• controlled data snapshots or documented source queries;
• parameterised scripts rather than manual steps;
• automated data and model tests;
• recorded assumptions and decisions; and
• separation of development, testing and production environments.

Reproducibility has levels. A result may be computationally reproducible in the same environment but not portable to another environment. It may be analytically reproducible if the method is clear but the original data are unavailable. Confidentiality and privacy may prevent sharing raw data, so secure access and synthetic or aggregated data may be needed.

Quality assurance includes checks for schema changes, duplicate keys, impossible values, unexpected null rates, target leakage and changes in class balance. A simple control such as “revenue must not be negative unless the transaction is a documented reversal” can prevent serious downstream errors.

5. The Analytics Technology Stack

An analytics stack is the set of technologies used to collect, store, transform, analyse, communicate and operationalise data. The exact architecture depends on scale, latency, security and organisational capability.

Business Intelligence Platforms

BI platforms support reporting, interactive dashboards, self-service analysis, semantic modelling and governed distribution. They are especially effective for descriptive and diagnostic questions: what happened, where, when and how performance compares with a target.

A semantic layer defines common measures, dimensions and business rules. Without it, different departments may calculate “active customer” or “profit” differently. BI governance should distinguish certified datasets from personal or exploratory content, define refresh expectations and manage access to sensitive information.

Dashboards should be designed around decisions rather than decoration. A useful dashboard identifies the audience, action, frequency, exceptions and definitions. Excessive charts, unclear filters and delayed data can reduce rather than improve decision quality.

Programming and Analytical Tools

SQL is fundamental for querying and transforming structured data. Python and R support data preparation, statistical analysis, visualisation and machine learning. Notebooks are valuable for exploration and communication, but production workflows should generally be converted into tested, parameterised code.

Spreadsheets remain useful for small-scale analysis and scenario modelling, but they create risks through undocumented formulas, manual copying, weak access control and version confusion. Their use should be proportionate to materiality and risk.

Cloud Services

Cloud platforms provide elastic compute, managed storage, databases, orchestration, identity management and machine-learning services. Benefits include rapid provisioning and integration. Risks include uncontrolled expenditure, inappropriate permissions, vendor dependence, data-residency issues and configuration errors.

Cloud architecture should apply least-privilege access, encryption, environment separation, cost budgets, logging, backup and recovery testing. “Cloud” is not itself a governance strategy; accountability remains with the organisation.

6. Analytics Roles and Team Design

Analytics work is usually interdisciplinary. A product owner or business sponsor defines value and prioritises decisions. A domain expert explains processes and constraints. A data analyst explores information and communicates findings. A data engineer builds reliable data pipelines. A data scientist develops statistical or machine-learning models. A BI developer creates governed reports and dashboards. A machine-learning engineer operationalises models. A data steward supports definitions, quality and governance. Security, legal and risk specialists may be essential for sensitive applications.

One person may perform several roles in a small organisation, but the responsibilities must still be explicit. A responsibility assignment matrix can identify who is responsible for performing work, accountable for the result, consulted for expertise and informed of progress.

Effective teams establish a shared vocabulary, regular demonstrations, peer review, documented decisions and clear escalation routes. Technical teams should not assume that users understand model limitations; business teams should not treat analytical outputs as unquestionable facts.

7. Applied Case: Retail Stockout Reduction

The following is a fictional illustrative case.

Background and Problem

A regional supermarket chain experienced frequent stockouts in high-demand products. Store managers received a weekly spreadsheet, but it contained too many items and did not distinguish urgent exceptions. The sponsor wanted to reduce stockouts without substantially increasing inventory.

Analysis

The team defined the decision as: which product-store combinations should receive expedited replenishment each week? The baseline stockout rate and inventory cost were documented. Data sources included point-of-sale transactions, inventory records, purchase orders, promotions, store calendars and supplier lead times.

During data understanding, the team found that inventory records were sometimes updated after physical counts. It also discovered that a proposed feature—whether a product was marked as unavailable—was recorded after a stockout and therefore created leakage. That feature was excluded.

Approach and Solution

The team used CRISP-DM in three-week agile cycles. The first cycle produced a baseline based on recent sales and current inventory. The second added promotion and lead-time information. The third compared a transparent risk score with a more complex model. The final solution produced a ranked exception list rather than an opaque automatic order.

The evaluation used a time-based holdout because future decisions must predict later periods. Technical measures included recall of stockout events and the number of false alarms. Business measures included stockout rate, inventory value and manager response time. Store managers reviewed the results before deployment.

The solution was published through a governed BI dashboard and a scheduled exception file. A data-quality test alerted the data engineering team when inventory freshness exceeded the agreed threshold. Managers could record whether an exception was actionable, creating feedback for later improvement.

Outcome

In the pilot, the chain observed fewer stockouts and no material increase in inventory cost. The result was treated as evidence from a controlled operational pilot, not as proof that the model would work indefinitely. Continued monitoring was required because promotions, supplier reliability and customer behaviour could change.

Learning Points

1. The business decision determined the analytical design.
2. Data leakage can arise from operational timing, not only from coding errors.
3. A ranked, explainable output may be more useful than full automation.
4. Data-quality monitoring is part of deployment.
5. User feedback can improve both adoption and future analytical work.

8. Ethics, Governance and Responsible Deployment

Analytics projects may involve personal, confidential or commercially sensitive information. Governance should address lawful purpose, necessity, transparency, retention, access, security and individual rights according to applicable law and organisational policy. Data minimisation is preferable to collecting every potentially useful variable.

Fairness requires examining whether data, labels, processes or decisions disadvantage groups. Removing a protected attribute does not guarantee fairness because other variables may act as proxies. Teams should define the relevant fairness concern, measure outcomes across appropriate groups and involve affected stakeholders. There is no universally correct fairness metric; trade-offs must be documented and justified.

Explainability is context-dependent. A customer-service prioritisation system may require actionable reasons, while a research model may require technical documentation. Human oversight should be meaningful rather than a nominal approval step. Automated decisions need appeal, correction and incident-management procedures where appropriate.

Generative AI can assist with code drafts, documentation, query formulation and summarisation, but outputs require verification. Confidential data should not be entered into an unapproved service. Teams must check fabricated references, insecure code, copyright concerns, bias and accidental disclosure. AI assistance does not transfer professional accountability to the tool.

9. Contemporary Best Practices and Limitations

Modern analytics increasingly combines analytics engineering, data contracts, automated testing, feature stores, model registries, observability and responsible-AI controls. Data contracts specify expected fields, types, freshness and ownership between producers and consumers. Observability makes pipeline failures and unusual data behaviour visible.

Nevertheless, no lifecycle removes uncertainty. Business objectives can conflict; data can be incomplete; causal effects may differ from predictive associations; metrics can be gamed; and deployment can change the environment being measured. A mature analytics function treats models as components of socio-technical systems rather than isolated mathematical objects.

Best practice is therefore to:

• start from a consequential decision;
• define value, constraints and ownership;
• establish a baseline;
• use appropriate temporal and experimental validation;
• document data and assumptions;
• design for monitoring and failure recovery;
• involve users and affected groups;
• control access and protect sensitive information; and
• review whether the deployed system continues to create net benefit.

Chapter Summary

CRISP-DM provides an iterative structure for moving from business understanding through data understanding, preparation, modeling, evaluation and deployment. Its value lies in linking technical work to organisational decisions rather than treating modeling as an isolated activity. Agile experimentation complements CRISP-DM through short cycles, prioritised backlogs, explicit hypotheses and incremental delivery.

Reliable analytics depends on reproducibility, version control, data lineage, testing, documented assumptions and monitoring after deployment. BI platforms communicate governed measures and support decisions, while SQL, Python, R and cloud services support transformation, analysis and scalable operations. Analytics teams combine business, data, engineering, governance and communication skills. Ethical deployment requires privacy, security, fairness, transparency, human oversight and continuous review.

Key Terms

CRISP-DM: An iterative six-phase framework for data-mining and analytics projects.

Business understanding: Definition of the organisational problem, decision, constraints and success criteria.

Data understanding: Examination of data sources, structure, quality, distributions and limitations.

Data preparation: Cleaning, integrating and transforming data for analysis.

Data leakage: Use of information unavailable at decision time, causing overoptimistic evaluation.

Baseline: A simple reference method against which a more advanced approach is compared.

Validation set: Data used during development to select methods or tune parameters.

Test set: Held-out data used for a final estimate of generalisation performance.

Deployment: Making an analytical output available for operational use.

Reproducibility: Ability to rerun or explain an analysis consistently.

Data lineage: Record of data origins, transformations and destinations.

Business intelligence: Technologies and practices for reporting, dashboards and governed analysis.

Semantic layer: Governed definitions of measures, dimensions and business rules.

Data warehouse: Structured analytical storage designed for integrated querying and reporting.

Data lake: Storage environment that can retain data in varied formats, often before structured transformation.

MLOps: Practices for developing, deploying, monitoring and maintaining machine-learning systems.

Model drift: Change in data or relationships that reduces model relevance or performance.

Data contract: An agreed specification for data structure, quality, freshness and ownership.

Data steward: Person responsible for supporting data definitions, quality and appropriate use.

Stakeholder: Person or group affected by, responsible for or interested in an analytics project.

Review Questions

Short Answer Questions

1. What are the six phases of CRISP-DM?
2. Why is a business baseline important in an analytics project?
3. Distinguish a validation set from a test set.
4. What is data leakage, and why does it matter?
5. Name two responsibilities of a data steward.

Long Answer Questions

1. Explain how a vague business objective can be translated into a decision question, analytical task and measurable outcome.
2. Compare CRISP-DM with agile experimentation and explain why organisations often use both.
3. Discuss the role of reproducibility, version control and data lineage in professional analytics.
4. Explain how BI platforms, programming tools and cloud services contribute different capabilities to an analytics stack.
5. Discuss the ethical and operational requirements for deploying an analytics model in a customer-facing setting.

Analytical / Application Questions

1. A bank wants to predict loan default, but the proposed dataset includes a field entered only after collection action begins. Identify the problem, explain its effect on evaluation and propose a validation approach.
2. A hospital dashboard has accurate measures but is rarely used by clinicians. Analyse possible causes and design an improvement experiment with a hypothesis, metric and decision rule.
3. Design a concise CRISP-DM project plan for reducing delivery delays in an online retailer. Include stakeholders, data sources, baseline, evaluation method, deployment channel and monitoring controls.

Multiple Choice Questions with Answers

Question 1

Which CRISP-DM phase focuses primarily on defining the organisational problem and success criteria?

A. Business understanding

B. Data preparation

C. Modeling

D. Deployment

Correct Answer: A. Business understanding

Question 2

What is the main purpose of a baseline model?

A. To guarantee perfect predictions

B. To provide a simple reference for judging added analytical value

C. To replace business validation

D. To eliminate the need for a test set

Correct Answer: B. To provide a simple reference for judging added analytical value

Question 3

A variable recorded only after a customer cancels a service is used to predict cancellation. What problem is most likely present?

A. Underfitting

B. Data leakage

C. Cloud elasticity

D. Low precision caused by class balance

Correct Answer: B. Data leakage

Question 4

Which measure is calculated as TP ÷ (TP + FP)?

A. Recall

B. Accuracy

C. Precision

D. Mean absolute error

Correct Answer: C. Precision

Question 5

Which tool is most directly associated with querying and transforming structured relational data?

A. SQL

B. SVG

C. A model card

D. A data contract

Correct Answer: A. SQL

Question 6

Why should a test set generally not be repeatedly consulted during model development?

A. It prevents data storage

B. It can lead to overfitting decisions to the test data

C. It always contains missing values

D. It cannot be used for numerical targets

Correct Answer: B. It can lead to overfitting decisions to the test data

Question 7

Which component most directly provides governed definitions of measures such as revenue and active customer?

A. Semantic layer

B. Random seed

C. Confusion matrix

D. Container registry

Correct Answer: A. Semantic layer

Question 8

Which practice best supports reproducibility?

A. Saving only a screenshot of the final chart

B. Performing undocumented manual spreadsheet edits

C. Version-controlling code and recording environment details

D. Changing the data preparation steps for each run

Correct Answer: C. Version-controlling code and recording environment details

Question 9

What is a primary purpose of post-deployment monitoring?

A. To ensure that models never require review

B. To detect data changes, performance decline and service failures

C. To remove the need for stakeholder involvement

D. To guarantee causal conclusions from predictions

Correct Answer: B. To detect data changes, performance decline and service failures

Question 10

In the illustrative retail case, why was a ranked exception list preferred to immediate full automation?

A. It prevented any use of historical data

B. It supported explainable human action while limiting automation risk

C. It made evaluation impossible

D. It required no data-quality controls

Correct Answer: B. It supported explainable human action while limiting automation risk