Framework
AI Project Discovery Framework: lock the process and its value, then find where to improve it
Many AI ideas arrive as a technology looking for a problem. I start the other way round: with the process, and with what it costs today. This is the stage before the method I use to decide whether an idea is worth building, which I wrote up in The most valuable AI call you'll make is often "not this one".
I have spent 15 years in regulated pharma systems, and this is the order I try to follow. Lock the as-is process and its baseline first. Then look for candidate improvements, where AI is one possible answer and often not the right one. I walk through it on one made-up example in Lock the process and what it costs before you look for AI.
Diagram. Discovery is the first of four stages in the idea lifecycle: Discovery, Assessment, Solutioning, Adoption and Improvement. Inside Discovery there are three steps: 1. Lock the as-is process and value, 2. Find candidates, 3. Light screen: frequent or high-stakes? an owner? usable data, or a path to it? Drop only on a clear no, and write the reason. Unknown goes forward. They produce an output, a short list of candidate use cases plus the locked flow and baseline, which is handed off to Assessment: value case, outside Discovery, where the target, owner and check date are confirmed and Assessment nets value against full cost.
Why start with the process and not the tool? Process improvement has been around for a long time, and AI being a new and powerful tool does not make it the best answer to every process problem. AI brings its own risks and often added cost, especially generative AI. A deterministic process is easier to validate and less likely to change, so I look at the process first.
What this stage does
It turns "we should use AI somewhere" into a short list of candidate use cases that are specific enough to assess. It locks how the work runs today and what that is worth, then finds and describes candidates. It does not decide, design or rank candidates by merit. The value case and the final call come next, in the Assessment method.
What you hand over: the short candidate list, the locked as-is flow, and the baseline numbers behind each candidate.
Words used on this page
- As-is process:
- how the work is done today, step by step, as people actually do it.
- Baseline:
- today's measured numbers for a step (hours, errors, delay, cost), taken before anything changes. It is the yardstick for any later claim of improvement.
- Value at stake:
- what the pain costs today, taken from the baseline. It is not a promise of savings.
- Full cost:
- everything an improvement would cost over its life: building and integrating it, validating it, licences and running it, human review, monitoring and changes, and retiring it.
- Validation:
- documented objective evidence that a system is fit for its intended use and can consistently meet its requirements. The rigor depends on context of use and risk. I cover how much of it an AI system needs in How much validation does your AI actually need?
- Generative AI:
- AI that generates content. On this page the focus is systems that write, summarize or answer in natural language.
- Candidate:
- a specific step or decision on the process that might be improved.
Who it's for
-
IT system owners
who run a system and want to know where it could help.
Your question: where does the data behind each step live?
-
Business process users
who feel the slow, repetitive or error-prone parts every day.
Your question: where does the time go?
-
AI team leads
who coordinate with the business.
Your question: what is already running, officially or not?
None of you needs to be an AI expert. The questions are about the process, the pain and the data.
Before you start
Pick one process that has a known pain, a named owner, and enough activity or risk evidence to establish a baseline.
If the idea came first ("we should use AI for X"), do not assess X yet. Map the process X touches, then see whether X still looks like the answer.
The three steps
-
1. Lock the as-is process and its value
This comes before looking for improvement points. My principle is to start with the value drivers, and cost is the main one.
- Map the flow as it runs today, step by step. In a regulated setting, map what people actually do, not only what the SOP says, and note where the two differ. The difference is often where the pain and the risk sit.
- Gather it with the people who do the work. Use a walk-through, not a desk exercise.
- Put numbers on it: hours, errors, delay, cost, volume and frequency. These numbers are the baseline. No baseline yet? Measure one first, even from a short sample.
- Note the value at stake per step, from the baseline.
- Record current measures now, such as hours spent, outside spend, cycle time, error or quality-event rate, overdue items and their age, or missed escalations. In Assessment you pick one or two outcome metrics, using its types (cost, capacity, speed, quality, compliance risk, adoption), and add a target, owner and check date; each is netted against the full cost. Released hours count as capacity, not cash, unless spending falls. Findings avoided are a modeled benefit only.
- GxP (good practice rules for regulated pharma): Record whether the step creates, changes or approves a GxP record, or affects a patient-safety, product-quality or data-integrity decision. Capture the fact only. Judging it comes later.
- Flag a broken process, but do not decide on it. If a step should simply be fixed or removed, write it down and pass it on. The Assessment makes that call.
Lock it: the process owner and one or two real users agree the flow and the baseline. Write the version and date on it, set a time limit for the mapping, and re-open it if the process changes.
-
2. Find candidates on that flow
Walk the locked flow and mark the steps that match the checklist below. Write each one down in the template. A candidate may later turn out to need a process fix or plain automation rather than AI. That is a valid result, not a failure of Discovery. In my experience, "let's use AI" ideas often belong in Bucket 3, heavier automation without generative AI: rules engines, scripts, statistical process control and threshold checks. The Assessment post explains the four buckets.
-
3. Light screen
Apply 2-3 checks to each candidate, each answered yes, no or unknown:
- Is the step frequent, or costly when it goes wrong?
- Does an owner exist who will answer questions about it?
- Is usable data available, or is there a credible path to access it?
Drop a candidate only on a clear no, and write the reason down. Anything unknown or unclear stays on the list, with the open question written next to it. Keep the dropped rows, so you can revisit them when data, process or rules change.
What to look at (checklist)
- Steps that are repetitive, slow, error-prone or rework-heavy.
- Steps that read, write or summarize text.
- Handoffs where information is re-keyed or lost.
- Steps that depend on one person's knowledge.
- Steps that are costly when they fail: patient safety, product quality, data integrity, an inspection finding.
- The key decisions people make, and what they base them on.
- The data or source behind each step: where it lives, who owns it, whether it is correct and complete, and whether it is clearly defined and easy to find. Poor data causes inefficiency (people don't know where to find things), and it limits what any later improvement can do.
A step that is neither slow nor repetitive can still be a candidate if a mistake in it is costly. A step that merely matches a keyword is not a candidate until it has a number next to it.
Notes for regulated settings
- Mark which steps create, change or approve a GxP record, or affect a patient-safety, product-quality or data-integrity decision, and note the data-integrity expectations that apply (ALCOA+: attributable, legible, contemporaneous, original, accurate, and also complete, consistent, enduring and available).
- Write down where the data lives, who owns it, and whether it is confidential or personal. Do not paste regulated or confidential data into external AI tools while mapping.
- Ask QA (quality assurance) / validation to read the candidate list early, as informed readers, not as approvers. Validation effort is unknown at this stage, so do not estimate it here; flag which candidates touch GxP records or affect patient-safety, product-quality or data-integrity decisions. Once a candidate is real, how much validation it owes depends on its context of use.
- Ask whether anyone already uses public AI tools informally on this process.
Candidate-list template
One row per candidate. Keep each line short. Write "unknown" rather than guessing.
Template: one row per candidate
| Field | Entry |
|---|---|
| ID | |
| Step (in the as-is flow) | |
| Pain (time / errors / delay) | |
| Volume / frequency | |
| Baseline | |
| Who feels it | |
| Data source and owner | |
| GxP relevance? | record / decision / no / unsure |
| Screen result | Keep / Drop (reason) |
Example row
- Mapped flow, step 4: a lab coordinator copies supplier test results from emailed spreadsheets into a tracking sheet.
- Baseline from a two-week sample: about 2 hours a week, 3 typos found in review.
- Candidate row:
Field Value ID C-1 Step (in the as-is flow) re-keying supplier results Pain (time / errors / delay) about 2 hours a week, occasional typos Volume / frequency weekly Baseline 2 h/week, about 3 typos per 2 weeks Who feels it lab coordinators Data source and owner emailed spreadsheets, no single location, owner not named GxP relevance? unsure Screen result Keep (frequent; owner to be confirmed) - Handoff: C-1 goes to Assessment with its baseline. Assessment may well decide it is a process fix (a shared location for the files), not AI.
For real examples of what pharma companies say publicly about AI on specific process steps, each with a linked source and a quote, see the Pharma AI Tracker.
One example of an AI-specific step in a published process: Novartis says generative AI can create well-structured first drafts of clinical and regulatory documents from approved sources, which Novartis experts then review and refine. See the Pharma AI Tracker entry or Novartis's own story.
Handoff to Assessment
The output is the short candidate list (one row per candidate), plus the locked as-is flow and the baseline behind each row.
- Discovery supplies the baseline and the value at stake. The Assessment opens by confirming the target, owner and check date for each metric. It does not re-measure the baseline unless the process changed.
- Each candidate gets its own Assessment pass, because the Assessment is applied to one proposed idea at a time.
- Sequence the list for review by baseline magnitude, the biggest pain first. This is not a merit ranking.
- Assessment nets the value against the full cost and decides whether to build it, or says "not this one".
Boundary with Assessment
| Discovery | Assessment | |
|---|---|---|
| Question | Where on this process is the pain, and what is it worth today? | Should we build it, and with what kind of automation? |
| Value | Lock the baseline and the value at stake | Declare the value case and net it against full cost |
| Work | Lock the flow, find and describe candidates | Sort into the four buckets, decide whether to build it, or say "not this one" |
| Screen | 2-3 yes / no / unknown checks, drops clear non-starters only, no ranking by merit | The value case, the bucket, and the final call |
| Output | Short candidate list, locked flow, baseline | A decision per candidate |
| Design | None | None (design comes later, in solutioning) |
Discovery does not score or rank by merit. If you find yourself choosing a technology, stop and pass the list on.
Common mistakes
The mistake I see most often is that the business owners are not committed to properly assessing the need, the effectiveness or the baseline. I am willing to sit down and work out exactly how much time this process really takes, because only the business side really knows.
- Starting from the technology ("where can we use AI?") instead of from the process and its value.
- Mapping the SOP and not what people actually do.
- Skipping the as-is flow, so there is no baseline to measure against later.
- Listing ideas with no number attached (no hours, errors, delay, volume or cost).
- Treating every candidate as an AI project. Many end as a process fix or plain automation, which is the point of the "not this one" post.
- Ignoring the data behind a step: if nobody knows where it lives or what it means, say so in the template.
- Dropping a candidate because a number is missing. Measure it or pass it on as unknown.
- Scoring, netting full cost or designing during the screen, which duplicates Assessment.
- Leaving out the people who feel the pain, so there is no owner and no adoption later.
Good questions for your next process walk-through
- 1Who on the business side owns this process, and will own the value baselining and the assessment?
- 2Which step do the people who do this work complain about most, and can we put hours or errors on it?
- 3Where does this process differ from its SOP, and why?
- 4Which decision here depends on one person's knowledge?
- 5Where does the data for each step live, and who owns it?
- 6If we fixed nothing but the process, what would it be worth?
Where this goes next
Candidates that survive this stage go to Assessment, which ends with one line I use to sum it up:
rules for what must be exact, AI for the language, a person for the decision.
Read it in The most valuable AI call you'll make is often "not this one".
The people you mapped the process with come back at the end, when the tool has to stick in their daily work. That stage is the AI Adoption and Improvement Framework.
Want to run a discovery workshop with me? That is the work I do.