The complete guide to scoping an AI project in business

In many companies, an artificial intelligence (AI) project begins with a convincing demonstration. A tool summarises an analysis note, classifies accounting documents or answers questions about a contract, and senior management immediately wonders why it is not already in use everywhere. Then the project slows down. The tool works, but nobody knows precisely what problem it solves, within what scope, with what data, or who should decide what happens next. The obstacle is rarely technical at the outset. It stems from insufficient scoping, that is, the phase of work that precedes development and answers questions that look simple: which task to improve, for whom, from what starting point, with what data, and under what conditions to move on to the next stage.

This guide is intended for executives, CFOs, investment fund partners and the heads of accounting firms who have to decide on an AI project or steer one. It follows the actual path of a scoping exercise, from the first question to the roadmap. It covers, in turn, how to formulate the need, how to define what falls within scope, the starting position and the quality of the data, how to prioritise the candidates, how to organise responsibilities, and finally the distinction between a limited trial and a genuine go-live. Each technical notion is explained when it first appears, and the glossary at the end of the article brings the definitions together.

This article sets out a method for reframing a project idea as a precise work situation, conducting a structured diagnostic across four dimensions (process, data, decisions and skills), building a prioritisation that you can defend before a committee, spotting the most common pitfalls and writing a roadmap in which every stage ends with an explicit decision. Regulatory questions and the rules for using tools call for separate treatment. This guide presents the principles, but their practical application must always be checked with a lawyer.

Why scoping is essential#

An AI project does not behave like conventional software#

Business management software applies known rules: the same input produces the same result, and validation consists of checking that each function behaves as intended. An AI system works differently. Systems based on language models or other statistical models produce probabilistic answers, that is, answers calculated from patterns observed in data, with a degree of uncertainty. A language model is, to put it simply, a system trained to produce plausible text in response to a request. Its answer may be correct, incomplete or wrong, and it may vary from one attempt to the next.

This difference has three consequences for scoping. First, quality cannot simply be declared: it is measured on real cases, which means knowing in advance what a good answer looks like. Second, quality depends heavily on the information supplied to the system, so an AI project is as much a project about information as it is a project about the tool. Finally, the system lives on over time: documents change, practices evolve, data deteriorates. It must therefore be managed as an ongoing operation rather than as a delivery that is signed off and closed.

What scoping must produce#

To scope is to answer a series of questions in writing before committing significant resources. Useful scoping produces, at a minimum:

• A use case sheet: it describes the target work situation, the expected result, the people involved and how the answer will be checked. It serves as the reference for all subsequent discussions, and it is the document to reread when the project drifts.
• A written scope, setting out what is included, what is excluded and what is deferred.
• A diagnostic that examines the process, the data, the decisions and the skills.
• A prioritisation that justifies why this project comes before others.
• An allocation of roles and clear decision-making bodies.
• A phased roadmap, in which each stage ends with a decision.

The first question: what business problem are we trying to solve?#

Many projects that fail started from a technology rather than from a need. The starting question must therefore be framed in business terms: which task, which decision, which work situation currently presents an identifiable difficulty? The answer takes the form of a use case, that is, a precise work situation in which algorithmic assistance could bring identifiable value to a person or a team.

A useful use case fits in a single sentence: for whom, in what situation, on the basis of what information, what assistance is provided, and who validates the result. For example: "For the closing team, during the review of bank reconciliations, classify discrepancies according to their probable origin, with validation by the head of accounts payable." This sentence looks modest, but it makes it possible to check that the need exists, who owns it and how we will know that it has been met.

A good use case has four qualities:

• It concerns a repeated task or a frequent decision, because repetition is what makes it possible to observe an effect. An exceptional event is no basis for lasting use.
• It is bounded: we know where it begins and where it ends. "Helping the finance department" is a domain, not a use case.
• It is measurable, in the sense that there is a method for comparing the situation before and after the tool is introduced, even if the measurements have not yet been taken.
• It has an owner who knows the real work and agrees to validate the results.

Distinguishing the idea, the use case and the prototype#

Three levels must be kept apart. The idea is a vague intention, such as "using AI for payroll". The use case is the precise sheet described above. The prototype is a technical build that shows that part of the use case can work. Many projects lose their way by going straight from the idea to the prototype. The prototype then answers a question that nobody asked, and it is hard to say what it proves.

Defining the scope#

The scope is everything the project covers: the process steps affected, the teams involved, the data used, the legal entities, and the documents and decisions that the system can influence. A well-drawn scope states explicitly what is included, what is excluded and what is deferred. A vague scope, on the other hand, turns every meeting into a negotiation: everyone adds their own topic, and the project ceases to be manageable.

It is useful to define it along four axes:

• The functional scope specifies which process steps are concerned. A tool that helps draft a summary does not necessarily play a part in validating that summary, and this difference must be set down in black and white.
• The data scope lists the authorised sources: management systems, shared folders, email, document repositories. It also specifies those that are excluded, for example for confidentiality reasons.
• The decision scope distinguishes what the system merely proposes from what it triggers automatically. In a first phase, a proposal followed by human validation is almost always the most prudent choice.
• The risk scope identifies the consequences of an error and the people who would bear them. It determines the level of control to be put in place.

A practical rule: if the scope does not fit in a short summary, it probably contains several projects. You should then isolate one, the smallest that remains useful, and put the others on a list of ideas to be reconsidered.

The four-dimension diagnostic#

A scoping diagnostic examines the context of the use case across four dimensions: process, data, decisions and skills. These dimensions are not independent. A poorly documented process produces inconsistent data, which leads to decisions that are hard to justify, which in turn call for skills the team does not yet have. The purpose of the diagnostic is to make these links visible before the project discovers them at its own expense.

The process#

The process is the actual sequence of tasks that leads to a result. A distinction must be drawn between the prescribed process, as described in the procedures, and the actual process, which includes workarounds, shortcuts and exceptions. It is the latter that largely determines the value of a tool. Assistance inserted into a step that teams bypass is very likely to go unused. The most reliable method is to follow a few real files from start to finish, then compare the result with the written procedure.

The data#

The data diagnostic answers three questions: where the information needed for the task is located, who is responsible for it, and what state it is in. You check whether the same term covers the same reality in two departments, whether the essential fields are filled in, how often the information is updated and who can access it. This diagnostic feeds into the assessment of data debt, that is, the gaps that have built up between the data available and the data the use case needs. This debt is dealt with further on.

The decisions#

An AI project generally changes a decision or prepares it. The decisions concerned must therefore be described: who takes them, on the basis of what information, according to what criteria and with what consequences in the event of an error. Many criteria remain implicit. Writing them down is often the first contribution of the diagnostic, even if the system is never put into service.

The skills#

The skills diagnostic is not limited to the question "who knows about AI?". You need to identify who has a sufficiently fine-grained command of the business to judge an answer, who knows how to handle the data, who can explain how the assistance works to users, and who will be able to monitor quality over time. The absence of one of these skills does not rule out the project, but it must appear in the plan with an explicit response: training, recruitment, external support or giving up certain functions.

The reference process and the measured starting point#

These two notions are inseparable. A project can only demonstrate an improvement in relation to something. That something is the reference process, that is, the current, documented and shared way of carrying out the task, and the measured starting point, that is, the state of that task before any change, described by means of precisely defined indicators.

The reference process#

The reference process is a snapshot of the work as it is carried out today, from trigger to delivery, with its variants and exceptions. It must be frozen at a given date, so that it is clear what the results are being compared with. It must also be written with the people who carry it out, and not only with those who manage it. When the project changes a step, the process is updated with a version history, so that the successive versions remain comparable with one another.

The measured starting point#

The starting point answers a simple question: before the project, where does the task stand on the dimensions that matter? It is built from indicators whose formula is written down in advance. For example:

• Average processing time: the sum of the durations measured on the files in the sample, divided by the number of files in that sample.
• Return rate: the number of files sent back for correction, divided by the total number of files processed over the reference period.
• Quality gap: the difference between the anomaly rate observed before the project and the rate observed afterwards, relative to the initial rate.

Three precautions are essential. The sample must be representative, that is, it must cover the usual types of file and not just the easy cases. The reference period must be long enough to absorb normal fluctuations in activity, so that a quiet period is not mistaken for an improvement. Finally, what is not counted must be written down: a measurement without a defined counting scope produces endless debate.

Without a measured starting point, everything else becomes a matter of impression. Teams say the work is heavy, management thinks it runs smoothly, and nobody can settle the matter. This measurement work is a scoping investment in its own right, and it is often underestimated.

Reference data and data debt#

Reference data#

Reference data is the version of a piece of information that the organisation has decided to treat as authoritative. A third-party master file, a chart of accounts, a list of activity codes or a contract register are typical examples. When the same information exists in several copies, in a spreadsheet, a management system and an email inbox, these copies end up diverging. A system that relies on the wrong copy can produce an answer that is consistent with false information, which is far harder to detect than an obvious error.

Scoping must therefore identify the reference data for each object handled by the use case, designate its owner and check that downstream systems do indeed read it from the same source. The term source of truth is sometimes used to describe this authoritative data.

Data debt#

Data debt refers to all the gaps that have built up between the actual state of the data and what would be required for the use case to work reliably. The image comes from technical debt, which is well known to IT teams: it builds up through successive shortcuts, it weighs on every new project that comes up against it, and it must be paid down in a planned way rather than endured.

Four families of debt are generally distinguished:

• Quality debt covers duplicates, missing values, data entry errors and inconsistent formats. It is detected through systematic checks on a sample.
• Definition debt arises when the same term refers to two different realities depending on the department, for example a "deal" or an "active client". It is often more costly than the previous kind, because it affects meaning and not just form.
• Access debt concerns data that is needed but hard to obtain, scattered across personal files or protected by poorly documented rights.
• Traceability debt is the absence of history: nobody knows any longer who changed a piece of information, when and on what basis. Traceability, by contrast, means the ability to reconstruct that path, which is essential for explaining a decision assisted by a system.

To assess the debt, you compare the observed state of each item of reference data with the requirements of the use case, then rank the gaps by severity. A three-level scale (low, medium, high) is generally sufficient, provided each level is justified by an observation. Debt that blocks the use case must be dealt with before any go-live. Debt that merely complicates the work can be included in a data improvement plan.

Prioritising with a value, feasibility and risk matrix#

An organisation rarely has just one idea. It therefore has to choose, and the choice must be defensible. The most common method rests on three criteria: value, feasibility and risk. The matrix is the analytical grid that cross-references these criteria in order to rank the candidates. It does not produce the truth: it structures a discussion whose assumptions are visible.

Reading the matrix#

The matrix is read by cross-referencing value and feasibility, with risk acting as a filter that determines the framework for implementation. Risk never offsets value: a highly promising but sensitive use case should not be discarded, but it must be placed within a more demanding framework. The following table offers a typical reading of the most common profiles.

Scoring without false precision#

The levels should remain qualitative (low, medium, high) and be justified in writing. A score given without justification creates false precision: it gives the impression of an objective analysis when it actually reflects an opinion. It is preferable for each criterion to be assessed by the person best placed to do so, the business owner for value, the data owner for feasibility and the risk lead for risk, and for the differences to then be discussed in a meeting. Disagreements are often the most instructive part of the process.

The roles around the project#

A poorly allocated AI project often fails for lack of an identified owner rather than through excessive complexity. Four roles must be explicitly assigned. In a small organisation, one person may hold several of them, but this must be a deliberate decision and not an oversight.

The sponsor#

The sponsor is the executive who champions the project within the organisation. The sponsor arbitrates between competing priorities, unlocks resources and answers for the project to the governance bodies. The sponsor's role is not to manage the detail, but to ensure that the project remains tied to a real stake. The classic pitfall is the distant sponsor, who approves the launch and then disappears until the review is requested.

The business owner#

The business owner knows the real work. The business owner defines the use case, validates the reference process, judges the quality of the answers and decides how the system is actually used. The business owner also agrees to change their own practices. Without them, the system is designed for imagined work rather than for real work.

The data owner#

The data owner looks after the quality, definition and accessibility of the reference data. The data owner identifies the data debt, proposes a remediation plan and checks access rights. They need not be an IT specialist: their expertise lies in knowing what a piece of data means and who can correct it. Without them, technical teams are left with questions of meaning that they cannot resolve on their own.

The risk lead#

The risk lead assesses the consequences of an error, checks the regulatory framework, defines the human controls and organises the reviews. The risk lead may come from compliance, internal audit, information systems security or legal, depending on the size of the organisation. Their role is not to block the project, but to make explicit the level of risk accepted and the person who accepts it.

The steering committee#

The steering committee is the project's decision-making body. It brings together the sponsor, the business owner, the data owner and the risk lead, at regular intervals set in advance. Its role is not to track the progress of tasks, but to take the decisions that commit the project: moving on to the next stage, changing the scope, stopping.

An effective committee works from a short briefing document: the status of the indicators against the starting point, open risks, observed variances and the decisions requested. Each decision is written down, dated and assigned. Three types of decision recur in practice:

• Continue: the results meet the criteria set, and the project moves on to the next stage in line with the approved plan.
• Adjust: the objective remains relevant, but the scope, the data or the process must be changed before going further. The adjustment must be documented, otherwise it turns into gradual drift.
• Stop: the assumptions do not hold, or the cost of verifying them is disproportionate to what is at stake. A well-documented stop is a useful result: it can free up resources and limit the renewal of a project through sheer inertia.

The committee must also be able to respond between meetings when an incident occurs. It is therefore useful to provide for an emergency procedure, with an identified decision-maker able to suspend the system.

Assessing quality before deciding#

An AI system is not validated by watching it work on a few flattering examples. It requires an evaluation set, that is, a collection of real cases, representative of the task, for which the correct answer has been established by experts before the test. This set must contain the routine cases, but also the difficult ones: incomplete information, ambiguous documents, procedural exceptions.

The answers are then assessed against an explicit grid. Each criterion must be precisely defined: accuracy of the information, completeness, compliance with instructions, citation of internal sources, absence of fabrication. For each criterion, compliant answers are separated from non-compliant ones, and the proportion of compliant answers is then calculated using the following formula: number of compliant answers, divided by the total number of answers assessed. What matters is less the value obtained than the fact that it is calculated in the same way at each iteration.

Two further precautions apply. First, not all errors are equal: an error that leads to a decision that is hard to reverse weighs far more heavily than a clumsy turn of phrase. The grid must therefore distinguish blocking errors from tolerable ones. Second, the evaluation set must be kept and enriched, because it will become the instrument for monitoring the system in operation. A project without an evaluation set has no objective means of saying whether quality is improving or deteriorating.

Proof of concept and moving into production#

The proof of concept#

A proof of concept (often abbreviated to POC) is a tightly bounded trial that answers a precise feasibility question. It covers a reduced scope, with representative but limited data, and it is designed to learn before making a bigger commitment. Typical questions are as follows: does quality reach the threshold set in the evaluation grid? Is the necessary data actually accessible? Do users accept the form of assistance proposed?

A proof of concept is not intended to be deployed as it stands. It is generally not connected to production systems, does not address all security requirements and cannot support widespread use. Its expected outcome is a documented decision: continue, adjust or stop.

The main pitfall is what is sometimes called the demonstration effect. A carefully prepared demonstration, on hand-picked examples, gives the impression that the problem has been solved. The proof of concept must therefore be assessed with the evaluation set, on cases that were not chosen because they were easy.

Moving into production#

Moving into production means bringing the system into real processes, with all the requirements this entails: integration with existing tools, management of access rights, usage logging (the automatic recording of who did what, with what information), human oversight, monitoring of quality over time, a rollback procedure, documentation and operational responsibilities.

Human oversight refers to the principle whereby a competent person checks the results and retains the final decision, particularly when the consequences are significant. The operations owner is the person who ensures the day-to-day running of the system, responds to incidents and triggers updates.

The following table summarises the differences between the two stages:

The criteria for moving on#

The move from proof of concept to production must be conditional on criteria written down before the test, and not negotiated after the event. At a minimum, it is advisable to check that the measured quality reaches the defined threshold, including on the difficult cases; that the blocking data debt has been dealt with; that the reference process has been updated to incorporate the new tool; that responsibilities for operations and incident response have been assigned; that the monitoring plan is ready; and that the steering committee has approved the decision in writing.

The phased roadmap#

A phased roadmap breaks the project down into successive phases. Each phase has an objective, deliverables, entry and exit criteria, and ends with a decision on whether to proceed. The word "phased" underlines the fact that you do not move forward in one block: you move forward in stages, each of which may lead to an adjustment or a stop.

A roadmap must not be confused with a committed timetable. At this stage of scoping, precise deadlines remain assumptions, because they depend on the results of the preceding phases. What must be committed to is the order of the decisions and their criteria.

What a good roadmap does not do#

A good roadmap does not plan for roll-out to every team from the outset. It explicitly lists what is not planned at this stage: extension to other processes, integration with every system, coverage of all sites or subsidiaries, new use cases. This list of things deliberately left out helps to limit the gradual expansion that makes a project unmanageable. It also shows that work on the data can proceed in parallel, provided its dependencies are known.

A roadmap without decisions is merely a schedule. Each phase must therefore name the person who decides, the criteria used and the document that records the decision.

The classic pitfalls#

Three pitfalls recur frequently in projects that get bogged down. Two others, less conspicuous, are also worth knowing.

Tool first#

The symptom is easy to recognise: a tool is subscribed to, or a demonstration is organised, before the use case has been defined. The cause often lies in commercial pressure, a passing trend or the desire to be seen taking the initiative. One remedy is to write the use case sheet, then compare the available solutions against precise criteria: data location, contractual terms, security, ability to integrate with existing systems and reversibility, that is, the ability to change solution without losing your data. The tool is not the enemy, but it can only come after the need.

The vague scope#

The symptom is a use case sheet containing expressions such as "and also", "possibly" or "eventually". The cause is the desire to deal with everything at once, often in the name of efficiency. One possible remedy is a written scope with explicit exclusions, and a separate list of ideas for deferred topics. Every addition to the scope must be submitted to the steering committee, together with its effect on resources and risks.

No starting point#

The symptom is a project about which nobody can say whether it works, because everyone relies on their own impression. The cause is often that measurement was considered tedious or unnecessary at the outset. One possible response, to be prepared upstream: establish the measured starting point before the first trial, with a written method, a sample and a reference period.

Mistaking a demonstration for a go-live#

The symptom is a team announcing that the work is finished after a successful presentation. A demonstration shows a possibility, not reliability. One possible response is to require the evaluation set and the criteria for moving on before any announcement.

The project without an owner#

The symptom is a lack of response when an error is reported or when the system needs updating. The cause is a common one: the project is driven by the innovation team or by the IT department alone, with no business owner and no operations owner. One possible response is to appoint these owners and to make monitoring of the system part of day-to-day responsibilities, rather than leaving it in a pile of exceptional tasks.

Regulatory framework and rules of use#

The European regulation on artificial intelligence, often referred to by its short name, the EU AI Act, governs the use of AI systems according to their level of risk. Subject to verification by a lawyer, it prohibits certain practices deemed incompatible with European values, subjects high-risk uses to stricter requirements, imposes, subject to verification by a lawyer, transparency obligations on certain systems, and leaves other uses under the general rules. Without going into detail, several principles underpin this text and should guide scoping:

• The risk-based approach: the more a use can affect people's rights, safety or important decisions, the more demanding the expected controls. The risk lead must therefore classify the use case as early as the prioritisation phase.
• Transparency: people should in principle be informed that they are interacting with an AI system, a point to be confirmed with a lawyer, and certain generated content must be identified as such.
• Human oversight: a competent person should, subject to legal verification, be able to understand, check, correct or set aside the result, with a genuine ability to intervene.
• Traceability: the data, the system versions and the decisions taken should, subject to legal verification, be capable of reconstruction, particularly in the event of a challenge.
• Data quality and robustness: the data used should, subject to legal verification, be relevant and sufficiently reliable for the intended use, and the system must behave in a stable manner.

These principles do not say which obligations apply to a specific case. That depends on the organisation's role (designing, acquiring, deploying or simply using a system), the type of use and the data processed. These obligations must be checked with a lawyer before the proof of concept phase, then re-examined each time the use changes. The European personal data protection framework may apply in parallel, to be confirmed with a lawyer, with its own requirements on purpose limitation, data minimisation and the rights of individuals.

The practical rules for day-to-day use are set out in the acceptable use policy, the details of which are not repeated in this article.

Glossary#

• Use case: a precise work situation in which algorithmic assistance can bring identifiable value, with an owner and a method of verification.
• Scope: all the steps, teams, data, decisions and risks covered by the project, together with what is excluded.
• Reference process: a documented and frozen description of the current way of carrying out a task, used as a basis for comparison.
• Reference data: the version of a piece of information regarded as authoritative across the whole organisation.
• Measured starting point: the state of a task before the project, established with written indicators, formulas and a written data collection method.
• Proof of concept: a tightly bounded trial intended to answer a feasibility question, not designed to be deployed as it stands.
• Moving into production: putting the system into service within real processes, with integration, security, oversight and operational responsibilities.
• Data debt: the gaps that have built up between the data available and the data that would be needed for the use case to work reliably.
• Value, feasibility and risk matrix: an analytical grid that cross-references three criteria in order to rank and prioritise candidate projects.
• Phased roadmap: a plan broken down into phases, each ending with a decision on whether to proceed, based on written criteria.
• Steering committee: the body that brings together the project's decision-makers, reviews the results and decides on the move from one stage to the next.
• Language model: a statistical system trained on large quantities of text to produce or transform text in response to a request.
• Evaluation set: a collection of real cases for which the correct answer is known, used to measure the quality of a system.
• Traceability: the ability to reconstruct, after the event, the data, versions and decisions that led to a result.
• Human oversight: control exercised by a competent person, who can validate, correct or set aside the result produced by the system.
• Risk lead: the role responsible for assessing the consequences of an error and defining the associated controls.
• Operations owner: the person who ensures the day-to-day running of the system, responds to incidents and manages updates.

Printable checklist#

To be used at the end of scoping, then before each decision to move on to the next stage.

Before you start

• The need is expressed in business terms, and not on the basis of a tool.
• The use case sheet has been written and validated by the business owner.
• A sponsor has been appointed and has accepted the role in writing.

Scope and diagnostic

• The functional, data, decision and risk scope is written down, with its exclusions.
• The actual process has been observed on real files and compared with the written procedure.
• The four dimensions (process, data, decisions, skills) are documented.
• The reference data has been identified, together with its owners.

Starting point and quality

• The measured starting point is based on a method, a representative sample and a reference period.
• The data debt has been assessed, and the blocking debts are listed.
• The evaluation set contains both routine cases and difficult cases.

Prioritisation and governance

• The three criteria (value, feasibility, risk) have been rated and justified in writing.
• The risk lead has reviewed the use case, including from a regulatory standpoint.
• The data owner and the operations owner have been appointed.
• The steering committee has a meeting frequency, a standard agenda and an emergency procedure.

Moving on to the next stage

• The exit criteria for the proof of concept were written down before the test.
• The decisions (continue, adjust, stop) have been taken and recorded.
• The roadmap states the expected decision for each phase.
• A lawyer has checked the obligations applicable to the use case.

Frequently asked questions#

Do you need an AI specialist to lead the scoping?#

Not necessarily. Scoping is first and foremost an exercise in understanding the business, the data and the decisions. A technical profile is useful for assessing feasibility, but the core of the work rests on the business owner and the data owner. It is, however, essential that someone is able to translate technical questions into choices the committee can understand.

Can a project be scoped without knowing precisely how good its data is?#

Yes, provided that this lack of knowledge is itself an output of the scoping. The data diagnostic is there precisely to measure it. It is, however, risky to launch a proof of concept without having identified the reference data, because the first results will then be difficult to interpret.

Should you start with a cross-functional use case or with one specific to a single business area?#

In general, a well-bounded use case specific to a single business area is simpler to scope and to evaluate. Cross-functional cases, which span several departments, presuppose data governance that is already mature. They can come later, once the first lessons learned have made it possible to stabilise definitions and responsibilities.

Who should approve the exit from the proof of concept?#

The decision lies with the steering committee, on the basis of a written file containing the measured results, the list of data debts, and the opinions of the risk lead and of the business owner. The sponsor makes the final call in the event of persistent disagreement. This approval must be documented, as it determines the resources committed thereafter.

What should you do if the proof of concept does not deliver the expected results?#

A disappointing result is not a failure of the approach. The first step is to establish whether the problem lies with the system, the data, the process or the use case itself. Depending on the diagnosis, the committee decides whether to adjust or to stop. A documented stop makes it possible to redirect resources towards another priority and to build on what has been learned.

Conclusion#

Scoping an artificial intelligence project means answering, before building anything, questions that seem obvious: what business problem, for whom, with what data, from what starting point, under the responsibility of which people and according to what rules. These questions may look administrative, but they have a strong bearing on the quality of what follows. A well-formulated use case, a scope that holds, a well-understood reference process, identified reference data and assessed data debt give the project a foundation on which decisions can rest.

The proof of concept and moving into production must remain two distinct stages, separated by written criteria and an explicit decision. The phased roadmap is not enough to guarantee success, but it makes the order of decisions visible and enables the steering committee to stop, adjust or continue with full knowledge of the facts. The regulatory framework and the rules of use should accompany this process from the outset, with the support of lawyers and competent leads.