2. Data Science Lifecycle and Problem FramingIntroduction: From Organisational Concern to Analytical WorkData science projects rarely begin with a dataset and a clearly specified algorithm. They usually begin with an organisational concern: declining customer retention, inefficient operations, unreliable demand forecasts, excessive fraud losses, or uncertainty about a strategic decision. The central challenge is to convert that concern into a well-defined analytical problem whose answer can support action. This conversion is more difficult than it appears. An organisation may ask, “Can we use machine learning to reduce customer churn?” Yet this question leaves several matters unresolved. What counts as churn? Which customers are in scope? How far in advance must risk be identified? What action will follow a prediction? How much will an intervention cost? What level of accuracy is useful? A technically impressive model may therefore fail because it solves the wrong problem, measures the wrong outcome, or cannot be integrated into organisational decisions. The data science lifecycle provides a disciplined way to move from an initial business or social need to data collection, analysis, modelling, deployment, evaluation, and learning. Problem framing gives direction to every stage. It establishes the decision context, identifies stakeholders, defines the unit of analysis, formulates analytical questions and hypotheses, specifies measurable outcomes, and makes constraints explicit. Two widely used lifecycle perspectives are CRISP-DM—Cross-Industry Standard Process for Data Mining—and OSEMN, commonly expressed as Obtain, Scrub, Explore, Model, and iNterpret. They are not rigid recipes. Rather, they are mental models that help teams structure uncertain, iterative work. This chapter examines these frameworks and connects them to professional project planning, responsible practice, and contemporary AI-enabled workflows. Learning ObjectivesBy the end of this chapter, you should be able to: 1. Explain why problem framing is central to successful data science. 2. Describe the stages, logic, and iterative character of CRISP-DM and OSEMN. 3. Translate an organisational challenge into an analytical question, hypothesis, target variable, and measurable outcome. 4. Distinguish descriptive, diagnostic, predictive, and prescriptive questions. 5. Identify stakeholders, decision points, units of analysis, constraints, and assumptions. 6. Develop a practical data science project plan with evaluation criteria and milestones. 7. Recognise common failure modes, ethical risks, governance requirements, and deployment considerations. 8. Apply lifecycle thinking to a realistic organisational case. Why Problem Framing Determines Project ValueA data science project creates value only when its outputs improve a decision, process, service, or understanding. The relationship can be represented as: Organisational situation → Decision → Analytical evidence → Action → Outcome A project may fail at any link. If the organisational situation is misunderstood, the wrong decision is addressed. If the evidence is poorly measured, the analysis is unreliable. If the output does not reach the decision-maker at the appropriate time, it produces no action. Finally, even a correct action may not improve outcomes if external conditions or implementation constraints are ignored. Problem framing therefore asks five foundational questions: - What decision or action needs support?
- Who will use the result, and when?
- What outcome indicates success?
- What information is available or can be obtained ethically and legally?
- What constraints determine whether a solution is feasible?
A useful distinction is between a business problem and a data science problem. “Late deliveries are increasing” is an organisational observation. “Estimate the probability that an order will be delivered late at the time of dispatch, so that high-risk orders can be rerouted” is a data science formulation. The second statement specifies timing, prediction target, intended intervention, and operational purpose. Problem framing should also avoid premature solutionism. Requests such as “build a neural network,” “use generative AI,” or “create a dashboard” describe possible technologies, not necessarily the underlying need. In some settings, a policy change, improved data entry, a simple rule, or a process redesign may be more effective than a complex model. The Main Forms of Analytical QuestionThe type of question determines the type of evidence required. Descriptive questions ask what has happened or what is happening. Examples include: How many claims were submitted last quarter? Which regions have the highest defect rates? Descriptive analysis commonly uses aggregation, visualisation, and summary statistics. Diagnostic questions investigate why a pattern occurred. For example: Why did cancellations increase among new customers? Diagnostic analysis may involve segmentation, comparison groups, root-cause investigation, and causal reasoning. Correlation alone does not establish cause. Predictive questions estimate an unknown or future outcome. Examples include: Which accounts are likely to default within 90 days? What will next month’s demand be? Predictive models must be evaluated on data that represent future or unseen cases. Prescriptive questions examine what action should be taken under specified objectives and constraints. For example: Which inventory should be reordered, and in what quantities? Prescriptive analytics may use optimisation, simulation, decision analysis, or policy rules. These categories can be combined. A project may describe current performance, diagnose its drivers, predict future risk, and recommend interventions. However, each additional stage introduces assumptions and potential sources of error. A Lifecycle View of Data ScienceA lifecycle is preferable to a linear “data in, model out” view because projects evolve through feedback. Data exploration may reveal that the target is poorly defined. Modelling may expose leakage or missing variables. Deployment may show that users cannot interpret the output. Monitoring may reveal that the environment has changed. A responsible team returns to earlier stages rather than concealing these discoveries. CRISP-DM: A Business-Oriented Process ModelCRISP-DM consists of six connected phases: 1. Business understanding 2. Data understanding 3. Data preparation 4. Modelling 5. Evaluation 6. Deployment #### Business understanding This phase establishes the organisational objective, project scope, stakeholders, constraints, assumptions, and success criteria. It should produce a clear problem statement and a preliminary project plan. A project charter is useful because it records the purpose, decision owner, expected value, risks, resources, and approval boundaries. The team should identify whether the objective is to reduce cost, increase revenue, improve safety, reduce waiting time, detect risk, allocate resources, or generate knowledge. It should also specify what will happen after the analysis. A prediction without a response mechanism may have little practical value. #### Data understanding The team identifies available data sources, their ownership, collection processes, granularity, quality, temporal coverage, and access restrictions. Initial exploration examines distributions, missingness, duplicates, outliers, inconsistent categories, and relationships between variables. Data understanding often changes the original problem definition. A data dictionary should document variable meanings, units, permissible values, collection dates, and known limitations. Teams must distinguish between data that are technically available and data that are valid for the proposed decision. #### Data preparation Data preparation includes selection, integration, cleaning, transformation, feature construction, labelling, and partitioning. It is often iterative and resource-intensive. Preparation decisions must be reproducible: the same transformations applied during training should be applied during testing and production. Care is required to prevent data leakage, in which information unavailable at prediction time enters the model indirectly. For example, using a post-discharge billing code to predict whether a patient will be readmitted would produce an unrealistic estimate if that code is not available when the discharge decision is made. #### Modelling The team selects techniques, constructs baselines, trains candidate models, tunes parameters, and records assumptions. Model choice should reflect the target, data structure, required interpretability, latency, cost, and risk. A simple baseline—such as a historical average, majority class, linear model, or established business rule—provides an essential reference point. #### Evaluation Evaluation asks whether the model solves the organisational problem, not merely whether it achieves a high technical score. It includes statistical performance, robustness, subgroup behaviour, calibration, interpretability, operational feasibility, and compliance. The final evaluation should be conducted on data not used to fit or tune the model. #### Deployment Deployment may involve a report, dashboard, batch scoring process, application programming interface, workflow integration, or human decision-support tool. Deployment also includes documentation, user training, access control, monitoring, incident response, and a plan for retirement or retraining. In many projects, deployment is the beginning of organisational learning rather than the end of the project. OSEMN: A Practical Analytical WorkflowOSEMN describes five activities: - Obtain: acquire data from databases, files, sensors, APIs, surveys, experiments, or permitted external sources.
- Scrub: clean, standardise, validate, join, and document data.
- Explore: investigate distributions, relationships, anomalies, patterns, and possible biases.
- Model: apply statistical, machine learning, optimisation, or simulation methods.
- iNterpret: explain results, communicate uncertainty, connect findings to decisions, and identify implications.
OSEMN is particularly useful for teaching and hands-on analytical work because it highlights the practical movement from raw data to interpretation. Unlike a strictly sequential workflow, it assumes repeated movement between activities. Exploration may require obtaining additional data; interpretation may reveal that the model target is inappropriate; scrubbing may need to be revised after modelling. CRISP-DM begins explicitly with organisational purpose and deployment, whereas OSEMN gives strong emphasis to the analytical craft of obtaining, preparing, exploring, modelling, and interpreting data. In professional projects, the two can be combined: use CRISP-DM to govern the project and OSEMN to organise detailed analytical tasks within the data and modelling phases. Constructing a Precise Analytical SpecificationA well-framed project can be expressed through an analytical specification. This is not a mathematical formula alone; it is a shared agreement between domain experts, analysts, engineers, managers, and governance stakeholders. Define the decision and interventionState the decision that the analysis will support and the action available to the decision-maker. For example, “Customer success managers will contact accounts predicted to have a high probability of cancellation within 30 days.” The intervention should be realistic, affordable, and ethically acceptable. Specify the unit of analysisThe unit of analysis is the entity represented by one row or one observation: a customer, transaction, patient visit, machine-hour, loan application, or store-day. Confusing units can produce invalid conclusions. A customer-level model, for example, should not mix customer-level labels with transaction-level predictors without careful aggregation. Define the target and prediction horizonThe target variable is the outcome to be estimated or explained. Its operational definition must include a time window and inclusion rules. “Churn” might mean no transaction for 60 consecutive days after a customer has completed at least one purchase. The prediction horizon states when the estimate is made and how far into the future it refers. Formulate hypothesesA hypothesis is a testable proposition grounded in domain knowledge. For example: “Customers who experience two unresolved service incidents within 30 days have a higher probability of cancellation in the following 60 days.” Hypotheses guide feature selection and analysis, but they should not become assumptions treated as proven facts. Exploratory work may generate hypotheses, while confirmatory analysis tests pre-specified hypotheses. When many relationships are searched, the risk of finding apparently significant results by chance increases. Analysts should distinguish exploratory findings from validated evidence. Establish measurable success criteriaSuccess criteria should cover at least four dimensions: - Technical: discrimination, error, calibration, stability, or forecast accuracy.
- Business: cost reduction, revenue increase, service improvement, or risk reduction.
- Operational: response time, throughput, availability, and integration feasibility.
- Responsible-use: fairness, privacy, transparency, security, and auditability.
For an imbalanced fraud problem, accuracy may be misleading. Precision, recall, false-positive cost, detection delay, and financial loss may be more appropriate. Metrics must be selected before evaluation is manipulated to favour a preferred result. Record constraints and assumptionsConstraints may include budget, deadline, data access, privacy law, computational capacity, interpretability, fairness requirements, staffing, and maximum tolerable error. Assumptions may concern data stability, label accuracy, customer behaviour, or the availability of an intervention. Recording them makes later disagreement visible and supports risk management. Planning the ProjectA project plan should connect activities to deliverables and decision gates. A typical plan may include: 1. Problem charter and stakeholder agreement. 2. Data inventory, access approval, and quality assessment. 3. Exploratory analysis and target validation. 4. Baseline construction and modelling experiments. 5. Independent evaluation and responsible-use review. 6. Pilot deployment, user feedback, and monitoring design. 7. Production release or a documented decision not to deploy. The plan should identify dependencies, owners, resources, risks, and criteria for stopping. A “no-go” outcome can be valuable when evidence shows that the expected benefit is too small, the data are inadequate, or the intervention is unsafe. Project management should distinguish a minimum viable analytical product from a final production system. A rapid baseline may test whether the problem is worth pursuing. Productionisation requires additional engineering, security, documentation, testing, governance, and support. Practical Applications Across OrganisationsIn healthcare, lifecycle thinking can support readmission risk estimation, but the target definition, clinical workflow, patient consent, fairness, and human oversight are critical. In manufacturing, sensor data may be used for predictive maintenance; the model must account for changing operating conditions and the cost of unnecessary maintenance. In banking, credit risk models require documentation, explainability, validation, and compliance with relevant regulation. In retail, demand forecasting must consider promotions, stockouts, holidays, and supply constraints. In public administration, models may assist resource allocation, but due process, transparency, and protection from discriminatory impact are essential. The same algorithm can therefore have different requirements in different contexts. A small forecasting error may be acceptable for a marketing campaign but unacceptable in a safety-critical control system. Project framing is the mechanism through which these contextual differences become explicit. Illustrative Case Study: Reducing Missed Service AppointmentsBackgroundThe following is an illustrative case. A network of outpatient clinics observes that a proportion of scheduled appointments are missed without cancellation. Missed appointments reduce capacity utilisation, delay care, and increase administrative costs. Situation and problemClinic managers initially request “an AI model to predict no-shows.” The data science team reframes the request: estimate, 48 hours before an appointment, the probability that the appointment will be missed, so that the clinic can send an appropriate reminder or offer a rescheduling option without disadvantaging patients who face access barriers. The unit of analysis is the scheduled appointment. The initial target is binary: missed appointment versus attended or cancelled in advance. The prediction horizon is 48 hours before the appointment. Stakeholders include patients, clinicians, scheduling staff, administrators, data engineers, compliance officers, and the service management team. Analysis and hypothesesThe team hypothesises that prior missed appointments, appointment lead time, reminder history, travel distance, appointment type, and scheduling time may be associated with non-attendance. These variables are reviewed for ethical appropriateness. Sensitive attributes are not automatically used as predictive features; however, protected-group information may be needed for fairness evaluation. Data understanding reveals inconsistent appointment statuses and a policy change that altered how cancellations were recorded. The team therefore creates a data-quality report and excludes periods with unreliable labels. It also discovers that a field entered after the appointment contains the final attendance status and must not be used as a predictor. Approach and solutionThe team first establishes a baseline using the historical no-show rate by clinic and appointment type. It then compares a calibrated logistic regression model with a tree-based model. The evaluation uses a time-based holdout set to approximate future use. Because staff capacity is limited, the decision threshold is chosen according to the number of patients staff can contact, not simply according to the threshold that maximises accuracy. The intervention is designed as a pilot. High-risk appointments receive an additional reminder and a convenient cancellation or rescheduling link. The system does not automatically penalise patients, restrict access, or label them as irresponsible. Staff receive guidance that the score is decision support, not a definitive judgement. OutcomeThe pilot is evaluated through operational and service measures: attendance rate, successful rescheduling, staff workload, reminder delivery, false-positive burden, and differences in outcomes across patient groups. If the intervention improves attendance but disproportionately burdens a group or produces excessive unnecessary contacts, the project must be revised rather than declared successful solely on the basis of a model metric. Learning pointsThe case illustrates that the difficult work was not selecting an algorithm. It involved defining the target, preventing leakage, aligning the prediction horizon with the intervention, choosing a threshold under resource constraints, and protecting people from harmful interpretations. It also demonstrates why deployment and evaluation must include the social and operational system surrounding the model. Common Failure Modes and LimitationsA frequent mistake is beginning with a preferred technology. This can lead to unnecessary complexity and obscure the actual decision. Another is treating a vague organisational objective as a measurable target without consulting domain experts. Poor labels, missing data, inconsistent definitions, and changing data-generating processes can undermine even sophisticated methods. Data leakage, selection bias, survivorship bias, confounding, and temporal leakage are especially serious risks. Random train-test splitting may be inappropriate for time-dependent data, repeated observations, or grouped entities. A model can also appear accurate because it learns institutional practices or historical discrimination rather than the underlying phenomenon. Overemphasis on a single metric is another failure. A model with excellent area under the receiver operating characteristic curve may have poor calibration or unacceptable precision at the operating threshold. Similarly, a statistically significant association may have little practical importance. Deployment introduces additional limitations. Users may ignore, overtrust, or misunderstand predictions. Data pipelines may fail. Behaviour may change in response to the model, creating feedback loops. Concept drift may reduce performance as markets, policies, or populations change. Monitoring should therefore include data quality, prediction distribution, outcome performance, subgroup effects, system availability, and user behaviour. Ethics, Governance, and Professional ResponsibilityData science teams have responsibilities beyond predictive performance. They must establish lawful and proportionate data use, purpose limitation, access control, retention rules, and secure handling. Individuals should not be subjected to opaque or consequential decisions without appropriate explanation, review, and recourse. Fairness is context-dependent. It may concern equal error rates, equal access to beneficial interventions, calibration, or avoidance of unjustified disparate impact. No single fairness metric resolves every conflict. Teams should involve affected stakeholders and document why a particular standard is appropriate. Governance should cover data provenance, consent or lawful basis, model documentation, version control, validation, approval authority, audit trails, incident management, and change control. Model cards, data sheets, risk registers, and decision logs can make assumptions and limitations visible. Human oversight must be meaningful: a nominal human approval step is inadequate if staff lack time, information, authority, or training to challenge the system. Professional integrity also requires communicating uncertainty. Analysts should not present estimates as facts, claim causation from association without suitable design, or conceal negative results. A well-founded decision not to deploy is a legitimate outcome of data science. Contemporary DevelopmentsModern data science lifecycles increasingly incorporate automated machine learning, cloud data platforms, feature stores, experiment tracking, continuous integration, and model operations. These technologies improve reproducibility and scalability but do not eliminate the need for framing or governance. Automation can accelerate a poorly defined project just as efficiently as a well-defined one. Large language models and generative AI are being used for data documentation, code assistance, synthetic-data exploration, natural-language interfaces, and interpretation support. Their outputs require verification because they may generate incorrect code, fabricated explanations, privacy risks, or hidden biases. Retrieval, access controls, evaluation suites, and human review are necessary when generative systems interact with organisational data. Data-centric approaches place greater emphasis on label quality, coverage, provenance, and representativeness rather than treating model architecture as the main source of improvement. Decision intelligence and causal machine learning also encourage teams to connect predictions with interventions and counterfactual questions. These developments reinforce the central lesson of the lifecycle: technical capability must remain subordinate to a clearly justified purpose. Best Practices for Lifecycle-Based ProjectsEffective teams generally follow several principles: - Begin with a decision and an intervention, not an algorithm.
- Involve domain experts, data owners, users, and affected communities early.
- Define the unit, target, time horizon, and success metrics in writing.
- Build a transparent baseline before pursuing complex models.
- Separate exploratory discovery from confirmatory evaluation.
- Use time-aware or group-aware validation where appropriate.
- Track data lineage, transformations, experiments, and model versions.
- Evaluate technical, business, operational, and fairness outcomes together.
- Design deployment, monitoring, and rollback before production release.
- Treat uncertainty, limitations, and non-deployment decisions as part of professional reporting.
Chapter SummaryThe data science lifecycle provides a structured yet iterative path from organisational need to useful and responsible analytical action. CRISP-DM links business understanding, data understanding, preparation, modelling, evaluation, and deployment. OSEMN emphasises obtaining, scrubbing, exploring, modelling, and interpreting data. Together, these frameworks show that data science is not merely model construction. Problem framing translates an organisational concern into a decision, unit of analysis, target variable, prediction horizon, hypotheses, measurable success criteria, constraints, and intervention. Analytical questions may be descriptive, diagnostic, predictive, or prescriptive. A sound project uses baselines, prevents leakage, validates against realistic future conditions, and evaluates operational and ethical consequences as well as statistical performance. Deployment, monitoring, governance, privacy, fairness, transparency, and human oversight are integral to the lifecycle. The ultimate test of a project is whether its evidence supports a feasible, beneficial, and responsible decision—not whether it uses the most sophisticated technology. Key TermsAnalytical question: A precisely stated question that can be addressed using data and analytical methods. Baseline: A simple reference method used to judge whether a more complex approach adds value. Business understanding: The CRISP-DM phase that defines organisational objectives, stakeholders, constraints, and success criteria. Concept drift: Change in the relationship between inputs and outcomes over time. CRISP-DM: A lifecycle framework comprising business understanding, data understanding, data preparation, modelling, evaluation, and deployment. Data leakage: Use of information in model development that would not be available at the intended time of prediction. Data dictionary: Documentation describing variables, meanings, units, formats, and permissible values. Deployment: The process of placing an analytical output into operational use. Evaluation: Assessment of technical, organisational, operational, and responsible-use performance. Hypothesis: A testable proposition concerning a relationship, pattern, or expected outcome. Intervention: An action taken in response to analytical evidence. Model monitoring: Ongoing observation of data quality, model performance, system operation, and impact after deployment. OSEMN: A workflow consisting of Obtain, Scrub, Explore, Model, and iNterpret. Prediction horizon: The future period for which an outcome is estimated. Problem framing: Translation of an organisational concern into a defined analytical and decision problem. Prescriptive analytics: Analysis that recommends actions under objectives and constraints. Target variable: The outcome a model is designed to estimate or explain. Unit of analysis: The entity represented by one analytical observation. Review QuestionsShort Answer Questions1. Why is a business problem not automatically the same as a data science problem? 2. What is the purpose of defining a prediction horizon? 3. Name the six phases of CRISP-DM. 4. What is data leakage, and why does it threaten evaluation validity? 5. Why should a project establish a baseline model? Long Answer Questions1. Explain the relationship between problem framing, intervention design, and project value. 2. Compare CRISP-DM and OSEMN in terms of purpose, emphasis, and practical use. 3. Discuss how technical, business, operational, and responsible-use success criteria should be combined. 4. Explain the role of deployment, monitoring, and governance in a data science lifecycle. 5. Describe how hypotheses, units of analysis, targets, and constraints contribute to an analytical specification. Analytical / Application Questions1. A retailer wants to “use AI to improve sales.” Reframe this request into a complete analytical specification, including decision, unit of analysis, target, horizon, intervention, and success measures. 2. A fraud model has 99% accuracy, but fraud occurs in only 1% of transactions. Explain why this metric may be misleading and propose a more suitable evaluation approach. 3. Design a CRISP-DM-based plan for predicting machine failure in a factory, including at least two risks involving data, deployment, or ethics. 22. Multiple Choice Questions with AnswersQuestion 1Which statement best represents a well-framed data science problem? A. Build a neural network for customer data. B. Create a dashboard containing every available variable. C. Estimate the probability of cancellation within 30 days so staff can contact high-risk customers. D. Use artificial intelligence to improve the business. Correct Answer: C. Estimate the probability of cancellation within 30 days so staff can contact high-risk customers. Question 2In CRISP-DM, which phase primarily establishes organisational objectives, stakeholders, constraints, and success criteria? A. Business understanding B. Data preparation C. Modelling D. Deployment Correct Answer: A. Business understanding Question 3Which situation is the clearest example of data leakage? A. Using a customer’s age as a model feature B. Using a post-discharge billing code to predict readmission at discharge C. Using historical transactions to calculate customer frequency D. Using a time-based holdout set for evaluation Correct Answer: B. Using a post-discharge billing code to predict readmission at discharge Question 4What is the main purpose of a baseline model? A. To guarantee regulatory approval B. To replace the need for data cleaning C. To provide a reference against which complex methods can be judged D. To maximise model complexity Correct Answer: C. To provide a reference against which complex methods can be judged Question 5Which question is prescriptive rather than predictive? A. How many orders were late last month? B. Why did cancellations increase in one region? C. Which customers are likely to cancel next month? D. Which inventory quantities should be reordered under supply constraints? Correct Answer: D. Which inventory quantities should be reordered under supply constraints? Question 6In the illustrative missed-appointment case, why was the decision threshold linked to staff capacity? A. Because accuracy is always irrelevant B. Because the intervention could be applied to only a limited number of appointments C. Because thresholds cannot be selected statistically D. Because all high-risk patients must be contacted regardless of cost Correct Answer: B. Because the intervention could be applied to only a limited number of appointments Question 7Which activity belongs most directly to the “Scrub” stage of OSEMN? A. Defining the organisational objective B. Cleaning, standardising, and validating records C. Selecting an intervention threshold after deployment D. Communicating the final recommendation to executives Correct Answer: B. Cleaning, standardising, and validating records Question 8Why may a random train-test split be inappropriate for some data science projects? A. It always produces too few observations B. It prevents any model from being trained C. It can ignore temporal order or relationships among repeated observations D. It guarantees data leakage Correct Answer: C. It can ignore temporal order or relationships among repeated observations Question 9Which combination most appropriately represents responsible evaluation of a deployed model? A. Accuracy alone on the training data B. Technical performance, operational feasibility, subgroup effects, and monitoring C. Model size and number of parameters only D. User satisfaction without outcome measurement Correct Answer: B. Technical performance, operational feasibility, subgroup effects, and monitoring Question 10A team discovers that its target labels changed after a policy revision. What is the most appropriate lifecycle response? A. Ignore the change because more data are always better B. Proceed directly to deployment using the original labels C. Document the change, assess label validity, and revise the data or problem definition if necessary D. Delete all variables unrelated to the policy Correct Answer: C. Document the change, assess label validity, and revise the data or problem definition if necessary
|