Why does the engineering-vs-research distinction matter? “Build a model that classifies customer support tickets into 12 categories with 90% accuracy.” Is this an engineering task or a research question? In our experience across AI scoping engagements, the answer determines everything about how the project should be planned, staffed, budgeted, and evaluated — and getting the answer wrong is one of the most common causes of AI project failure. An engineering task has a known solution path. The techniques exist, the data requirements are understood, the expected performance range is documented in the literature, and the implementation effort is estimable. A text classification model for 12 categories with sufficient labelled data is an engineering task — the solution path (fine-tune a pre-trained language model on the labelled data, evaluate, tune) is well-established, and the expected accuracy range (85–95% depending on data quality and class separability, as reported in industry survey reports and published benchmarks) is predictable. A research question has an uncertain solution path. The techniques may not exist, the data requirements may be unknown, the expected performance range is not established, and the effort to reach a satisfactory outcome is unpredictable. As an illustrative example from our scoping engagements: “Build a model that predicts customer churn 90 days in advance with 80% accuracy from transaction data alone” may be a research question — the signal may not exist in the data at that prediction horizon, and no amount of engineering effort will create a signal that does not exist. Why the distinction matters for project planning Engineering tasks and research questions require fundamentally different project management approaches. Engineering tasks are estimable. The solution path has been implemented before, the effort for each step is known, and the total timeline can be estimated within a reasonable range. A project plan with milestones, deliverables, and a fixed budget is appropriate. The team can commit to a timeline and a performance target with reasonable confidence. Research questions are not estimable. The solution path may require multiple attempts, dead-end explorations, and hypothesis revisions. A fixed timeline and a performance commitment are inappropriate — they either force the team to declare premature success (lowering the quality bar to meet the deadline) or force the project into indefinite extension (missing deadlines while pursuing an uncertain outcome). Research questions require time-boxed exploration: “we will invest N weeks exploring this question and evaluate whether the findings justify continued investment.” The failure pattern: a research question is planned as an engineering task. The project has a fixed timeline, a fixed budget, and a fixed performance target. In our experience across AI scoping engagements, the team spends the first 60% of the timeline discovering that the initial approach does not work. The remaining 40% is insufficient for the revised approach (an observed pattern, not a benchmarked industry rate). The project is over budget, over schedule, and under-performing — not because the team is incompetent, but because the project plan assumed certainty that did not exist. How to classify your AI project The classification is not always obvious at project initiation. These diagnostic questions help: Has this specific problem been solved before? Not “has AI been applied to this domain?” but “has a model been built for this specific task, with this type of data, at this performance level?” If the answer is yes, and you have comparable data, it is likely an engineering task. If the answer is no, or the comparable solutions used significantly different data or had significantly lower performance requirements, it may be a research question. Is the signal known to exist in the data? For predictive tasks: is there evidence (from domain expertise, exploratory data analysis, or published research) that the data contains sufficient information to make the prediction at the required accuracy? If the signal’s existence is uncertain — if the team is hoping the model will find a pattern that has not been identified — the project contains a research component. Is the performance target within the established range? Published benchmarks and industry survey reports establish performance ranges for common AI tasks. Text classification: 85–95% (as reported in published benchmark suites). Object detection: 70–95% mAP depending on domain. Document extraction: 80–95% field accuracy. If your performance target is within the established range and your data is comparable to the data used in benchmarks, the project is likely an engineering task. If your target exceeds the established range, the project requires research-level effort. Does the project require novel data representation? If the input data is in a format that standard model architectures handle well (text, images, tabular data, time series), the project is more likely an engineering task. If the data requires novel representation — combining multiple modalities, handling unusual formats, or representing domain-specific structures — the representation engineering may be a research component. The hybrid case: projects with both components Most real AI projects contain both engineering and research components. A customer churn prediction project might have: an engineering component (build the data pipeline, train a classification model, deploy the serving infrastructure) and a research component (determine what features predict churn at 90-day horizon, determine whether the accuracy target is achievable with the available data). The project plan should separate the two components and manage them differently: Research component: Time-boxed exploration. “We will spend 3 weeks on feature engineering and exploratory modelling to determine whether the 90-day churn prediction target is achievable. At the end of 3 weeks, we will have a report with: the best accuracy achieved, the features that contribute most to the prediction, and a recommendation on whether to proceed to the engineering phase.” Engineering component: Standard project plan. “Given the features identified in the research phase and the validated accuracy range, we will build the production pipeline in 8 weeks, including data pipeline, model training automation, serving infrastructure, and monitoring.” The research phase’s output is a go/no-go decision for the engineering phase. If the research phase shows that the target is not achievable, the project can be cancelled or rescoped before the engineering investment is committed. The POC methodology implements this approach — the POC is the research phase, and the production build is the engineering phase. The organisational implication Organisations that treat all AI projects as engineering tasks — with fixed timelines, fixed budgets, and fixed performance commitments — will experience a high failure rate on projects that contain research components. The failures are not failures of execution; they are failures of planning. The fix is not to avoid research questions — some of the most valuable AI applications require solving novel problems. The fix is to identify which projects (or which components of projects) are research questions, plan them accordingly (time-boxed, with explicit go/no-go criteria), and manage stakeholder expectations about the uncertainty. This distinction — engineering task vs research question — is the first assessment we make in any new AI engagement. It determines the engagement structure, the timeline expectations, and the budget model. For generative AI projects, evaluating use case feasibility before building applies this classification alongside data readiness and accuracy tolerance assessments. The enterprise AI project failure patterns are disproportionately caused by research questions managed as engineering tasks. AI project classification intake form The following intake questions help classify an AI project as an engineering task, a research question, or a hybrid — before the project plan is written. What specific business outcome will this project deliver? (Free text — if the answer is vague or aspirational, the project needs scope refinement before classification.) Has this exact problem type been solved before with comparable data? (Yes, with published benchmarks → Engineering / Yes, but in a different domain → Hybrid / No or uncertain → Research) Does the required data exist, and has someone inspected it? (Data exists and has been examined → Engineering / Data exists but has not been examined → Hybrid / Data does not exist or must be collected → Research) What is the target performance metric and threshold? (Within published benchmark ranges → Engineering / Above published ranges or no benchmark exists → Research) Does the project require a novel data representation or model architecture? (Standard inputs and architectures → Engineering / Non-standard combinations or representations → Research) What systems must the model integrate with, and do APIs exist? (APIs exist and are documented → Engineering scope for integration / APIs do not exist or require significant development → adds engineering complexity) Is there a simpler non-AI solution that could deliver 80%+ of the value? (Yes → evaluate whether AI is justified / No → proceed with classification — planning heuristic from our scoping engagements, not a benchmarked industry rate) What is the acceptable timeline for a conclusive result? (Fixed deadline with committed deliverable → must be engineering / Flexible with interim checkpoints acceptable → can accommodate research) What is the budget model? (Fixed price → requires engineering-level predictability / Time-boxed with decision gates → can accommodate research) Who is the executive sponsor, and have they agreed to the success criteria? (Sponsor identified and criteria agreed → proceed / Sponsor unclear or criteria not agreed → resolve before classification) Scoring: Count the Engineering, Hybrid, and Research answers for questions 2–5. If all four are Engineering, the project is an engineering task. If two or more are Research, the project contains significant research components and should be planned with time-boxed exploration phases. Mixed results indicate a hybrid project that should separate its engineering and research components into distinct phases with a decision gate between them. If AI projects in the pipeline have not been classified as engineering tasks or research questions, an AI Project Risk Assessment provides the classification and the appropriate planning approach for each.
