Run a Data Analysis Project, from the Decision It Should Improve to Real Use

## Work in Steps and Go Back When an Assumption Turns Out Wrong Organize the project as a connected lifecycle rather than a rigid sequence. Move through decision understanding, data understanding, data preparation, modeling, evaluation, and deployment, but return to earlier phases whenever evidence invalidates an assumption or exposes a new requirement. Define an expected outcome and review point for each phase. Record inputs, decisions, findings, unresolved questions, and reasons for moving forward or back. The lifecycle may emphasize different phases depending on the problem, but do not ignore downstream questions merely because a phase appears less important. Keep the decision problem visible throughout the project. Analytical activity is useful only when it improves a decision, process, product, or measurable outcome. ## Turn the Decision You Want to Improve into Analysis Questions and a Plan Begin by describing the decision context, desired outcome, current process, stakeholders, and the value expected from the work. Define measurable success criteria from both the decision perspective and the analytical perspective; keep them separate so technical performance cannot silently replace real-world value. Inventory available people, data, tools, time, budget, and subject-matter knowledge. Document requirements, assumptions, legal or operational constraints, terminology, risks, contingencies, costs, and expected benefits. Convert the decision objective into analytical questions, target outputs, and acceptance criteria. Produce a project plan with phases, dependencies, resources, milestones, review points, and candidate techniques. Revise the plan when later evidence changes the original understanding. ## Explore the Data and Check Whether It Can Answer the Question Collect an initial, representative set of data and document its sources, ownership, acquisition conditions, time coverage, and known limitations. Describe record counts, fields, types, ranges, distributions, relationships, and important metadata before drawing conclusions. Explore the data to test early hypotheses, reveal unexpected patterns, and identify promising or irrelevant fields. Distinguish observations from interpretations, and trace each conclusion to the data and method that support it. Verify completeness, validity, consistency, uniqueness, timeliness, and fitness for the intended decision. Record missing values, errors, noise, bias risks, and collection gaps in a data-quality report. If the data cannot support the objective, return to the objective, collection plan, or project scope instead of forcing a model. ## Clean and Combine the Data and Record Every Change Select records and fields according to relevance, quality, technical constraints, and the planned evaluation design. State why data is included or excluded so later reviewers can reproduce the analytical population. Clean errors and missing values using explicit rules. Construct derived attributes only when their meaning and calculation are documented. Integrate sources with verified keys and grain, then format the result for the chosen methods without changing its intended meaning. Maintain a transformation record covering source versions, selection rules, cleaning actions, derived fields, joins, formatting, and resulting quality. Revisit data understanding whenever preparation reveals anomalies or changes the interpretation of important fields. ## Choose Models and Set Up a Fair Test Before Building Them Choose techniques according to the analytical objective, data characteristics, assumptions, interpretability needs, operational constraints, and success criteria. Document why each candidate method is suitable and what conditions would make it invalid. Design evaluation before fitting models. Define training and test partitions, comparison baselines, metrics, sampling rules, and procedures that prevent the assessment data from influencing model construction. Use the same design when comparing candidate approaches. Build multiple justified candidates when uncertainty warrants comparison. Record data versions, features, parameters, assumptions, execution conditions, and results for every run. Assess model quality against the predefined technical criteria and investigate failures rather than selecting a result only because it ranks highest. ## Judge Results by Whether They Help the Decision, Not Just by Scores Review the analytical results against both technical criteria and the original decision success criteria. Confirm that findings are accurate enough, relevant to the stated problem, understandable to stakeholders, and feasible within operational constraints. Audit the full process for overlooked requirements, weak assumptions, data limitations, dead ends, surprising results, and alternative choices. Return to earlier phases when the evidence is insufficient; iteration is expected and should be documented rather than hidden. Choose the next step explicitly: proceed to deployment, refine the current approach, replace it, collect better data, or stop. Document the evidence behind the decision. A technically strong result must not proceed when it fails to address the decision objective. ## Put Results into Use and Watch Whether Their Accuracy Drops Deployment may mean integrating a model into an operational system or communicating findings so people can change a decision or process. For each result, identify the audience, owner, delivery method, dependencies, implementation steps, technical requirements, and contingency plan. Define monitoring before release. Specify the factors to track, measures of validity and accuracy, reporting cadence, alert thresholds, and conditions that indicate drift, expiration, or loss of usefulness. Decide in advance whether each condition calls for recalibration, rebuilding, replacement, or a new project. Coordinate with the people who operate systems, maintain data, make decisions, and are affected by the outcome. Automate routine monitoring where practical, but retain human review for judgments that depend on context or acceptable tradeoffs. ## Write a Final Record and Save Lessons for the Next Project Produce a final record that covers the original problem, success criteria, methods, costs, deviations from the plan, data limitations, results, deployment approach, monitoring plan, and recommended follow-up work. Adapt the level of explanation to each audience without changing the underlying evidence. Review every phase for value contributed, avoidable work, failures, dead ends, surprises, and better alternatives. Gather feedback from project participants and people affected by the deployed result when possible. Preserve decisions, reports, reusable transformations, evaluation designs, and lessons in a form that future projects can find and understand. Judge the project not only by model quality, but also by whether it delivered the intended benefit and improved the organization’s ability to conduct the next analysis.