Lesson 2 — Feasibility, Risk, and Scoping Discipline

Unit 4 | Lesson 2 of 3

By the end of this lesson, you will be able to:

• Apply four feasibility checks to your chosen process and identify any conditions that need resolving before implementation
• Recognise the most common scoping failure at this stage — choosing a process that is too large — and apply the discipline to avoid it
• Identify high-level risk flags honestly without conflating awareness with a full risk assessment
• Use an AI assistant to find blind spots in your feasibility thinking and generate questions to raise with your line manager

The gap between a good idea and a viable project

By now you have a process you believe is worth automating and a value estimate that supports that belief. Those are genuinely important steps. The work in this lesson is less exciting but equally critical: checking whether the opportunity is actually achievable within the constraints of your organisation, your apprenticeship timeline, and your current capabilities.

This matters because enthusiasm and insight are not the same as feasibility. The apprenticeship gateway is not just asking whether you have found an interesting idea — it is asking whether you have found a deliverable one. A business case that identifies a brilliant opportunity but ignores an obvious showstopper will not pass. A business case that acknowledges its constraints honestly and shows you have thought through how to manage them will.

There are four feasibility checks to work through. None of them requires you to have all the answers yet. They do require you to have asked the questions and to be honest about what you found.

Feasibility check 1: data availability

The first and most fundamental check is whether the data your process depends on actually exists in a form that an automated system can use. This sounds obvious — of course the data exists, the process is already running on it — but the question is more specific than that.

Automation requires data that is digital, accessible, and consistently structured. A process that currently runs on data that a human reads from a PDF, interprets using experience, and keys into a separate system is a process where the data technically exists but is not yet in a usable form for automation. The human is doing three things: accessing the data, interpreting it, and transferring it. Automation can assist with all three — but only if there is a way to get the data into the system in the first place.

Practical questions to ask yourself include: does the relevant data live in a system that can be queried or connected to via an integration? Is it structured consistently, or does its format vary significantly between instances? Is it owned by your team, or does accessing it require permission from another team or IT function? Are there data protection obligations that affect how it can be processed?

If you identify a data access problem, that is not necessarily a reason to abandon the opportunity. It may be a reason to start with a more bounded scope — a subset of the process where the data is clean and accessible — and plan the data infrastructure work in parallel. The business case should name the problem and describe the plan, not pretend the problem does not exist.

💬 Reflection

Go back to your workflow map. For each step where data flows into or out of the process, ask: is that data currently in a form that software can read without human interpretation? Mark any steps where the answer is no or uncertain. Those marks are your data readiness gaps, and they belong in your business case.

Feasibility check 2: process maturity

The second check is whether the process you have chosen is stable enough to automate. Automation works well on processes that are well-defined, consistently performed, and unlikely to change significantly in the near term. It works poorly — and can actively cause problems — on processes that are in flux.

A process might be unstable for several reasons. It may be new and still being refined; the team may not yet have settled on a consistent approach. It may be subject to regulatory or policy changes that alter how it needs to work. It may be dependent on a system that is scheduled for replacement or upgrade. Or it may simply be that different people in the team perform it differently, meaning there is no single "current state" to automate.

If the process is currently changing, the right response is not to abandon automation but to wait for it to stabilise before building. Automating a process that is still being defined locks in a version that may quickly become wrong — and changing an automated system is significantly harder than changing a manual one. Note the instability in your business case and propose a review point at which you would revisit the scoping decision.

Feasibility check 3: organisational readiness

Technical feasibility is necessary but not sufficient. The process also needs to be one that your organisation — and specifically your line manager and the people who own the process — is willing and able to support.

Organisational readiness has several components. Your line manager needs to know about the project and support it: not just be aware of it, but actively have agreed that you can work on it as part of your apprenticeship. The team whose process you are automating needs to be willing to engage: to answer your questions, review your workflow map, test your output, and adapt their working practices if the automation requires it. There should be no obvious tool or platform constraints that prevent the automation from running — for instance, an IT policy that prohibits third-party integrations, or a security requirement that means certain data cannot leave a specific system.

Budget is rarely a significant barrier for the types of automation you are likely to build at this stage — most no-code and low-code tools have free tiers or are already available in your organisation's existing software stack. But it is worth confirming this rather than assuming it.

If you have not yet had a conversation with your line manager about your chosen process, that conversation is your immediate next step after this lesson. The business case you submit to your coach should reflect your manager's awareness and support, not be the first they hear of the project.

A note for learners on a technical pathway. If your proposed solution involves writing code — for example, using Python to connect to an API, process data, or build a custom integration — the organisational readiness questions become more specific. You will need to confirm that your organisation permits custom code to be deployed in its environment, that there is a suitable place to run it (a server, a cloud environment, or a scheduled task), and that IT or engineering teams are willing to support or at least not block the work. You should also check whether any libraries or external APIs your solution depends on require procurement or security approval before use. These are not reasons to abandon a code-based approach — many organisations actively welcome practitioners who can build at this level — but they are questions to raise with your line manager and IT contacts before you commit to a technical solution design. A no-code or low-code approach may face fewer of these organisational hurdles; a code-based approach may offer more flexibility and power. Both are valid pathways, and the business case should honestly reflect whichever you are proposing.

Feasibility check 4: high-level risk awareness

At this stage of the programme, you are not expected to conduct a full risk assessment. That rigorous analysis — covering data governance, legal compliance, ethical implications, and responsible AI design — is the work of Module 2. What you are expected to do now is demonstrate that you have looked for obvious showstoppers and either resolved them or flagged them honestly.

The most common high-level risk flags at this stage fall into three categories. Technical risks include dependency on systems that are out of scope for integration, data quality problems that would undermine the automation's reliability, and complexity in the exception paths that makes the process harder to automate than the standard path suggests. Organisational risks include team resistance to the change (particularly if staff fear the automation is intended to replace their roles rather than free up their time), lack of a clear owner for the automated process, and timelines that conflict with other organisational priorities. Practical risks include the scope being too large for the apprenticeship timeline, the process being one where errors would cause significant harm before being caught, and the learner not yet having the technical skills to build the proposed solution.

Naming these risks in your business case is not an admission of weakness — it is evidence of professional maturity. Every good project proposal acknowledges what could go wrong. The question is whether you have a credible response to each flag, or whether it remains an unresolved issue that needs further investigation.

Scoping discipline — the most important lesson in this unit

Of everything covered in Unit 4, scoping discipline is the area where learners most commonly undermine their own projects. It is worth being direct about this.

The instinct at this stage is to choose a process that feels significant: something that would make a real difference, that involves multiple teams, that tackles a longstanding organisational frustration. That instinct is understandable. It is also, in many cases, how apprenticeship projects fail — not because the learner lacks capability, but because the scope was too large to deliver within the programme timeline, the complexity exceeded what was achievable with available tools, or the organisational change required was too significant to happen in parallel with a learning programme.

A well-scoped, modest opportunity that actually gets built — that runs, produces output, is used by real people, and can be evaluated — is worth far more than an ambitious proposal that stalls in Module 2 because the data access problem turns out to be harder than expected, or the line manager changes, or the tool cannot do what was assumed. The organisation learns more from a small, completed automation than from a large, unfinished one. You learn more from building something end-to-end than from designing something that never gets implemented.

The test for good scoping is whether your opportunity is specific, bounded, achievable within six to eight weeks of active build time, visible to the organisation, and supported by your line manager. If the answer to any of those is no, the scope needs adjusting before you write your business case.

💬 Reflection

Read back your chosen process description. Could you build a working pilot of this in six to eight weeks, using tools you either already know or could learn with a reasonable amount of focused effort? If you are uncertain, that uncertainty is a scoping signal. Consider whether there is a smaller, more bounded version of the same opportunity that you could start with — a single step in the process, a single document type, a single team's workflow — that would demonstrate the value of the approach before you scale it.

Using AI to find your blind spots

Before you write your feasibility section, there is a highly practical use of AI that is worth building into your process: asking it to identify the feasibility questions you have not thought to ask.

AI assistants are particularly good at this kind of adversarial thinking — generating the challenges, objections, and edge cases that a practitioner who is close to the work can easily overlook. Try prompting with something like: "I am proposing to automate the following process as part of an AI apprenticeship project: [describe your process]. I have done a feasibility check covering data availability, process maturity, organisational readiness, and high-level risks. What feasibility questions am I most likely to have overlooked, and what questions should I be asking my line manager before committing to this scope?"

The output will not be perfectly tailored to your organisation, but it will almost certainly surface at least one question that had not occurred to you. Common blind spots that this kind of prompt reveals include: whether the process involves personal data and whether that has implications under UK GDPR; whether there are seasonal peaks in the process that would affect how it needs to be designed; whether the process has dependencies on other processes that are also being changed or reviewed; and whether the people who currently perform the process have been consulted, or only those who manage them.

Use the AI's output as a checklist to work through before your line manager conversation — not as a substitute for that conversation.

Quick Check

📝 Activity 2 — Feasibility check and line manager conversation

Complete before your coaching session | Estimated time: 45 minutes

Using the Feasibility Check template in your Unit 4 Workbook, work through all four dimensions for your chosen process. For each one, record your status (Clear, Needs attention, or Blocker) and write two to four sentences of specific evidence. Do not leave any dimension blank — if you genuinely do not yet know enough to assess it, write that honestly and note what you need to find out and from whom.

Before you complete this activity, have a conversation with your line manager about the project if you have not done so already. Your feasibility check should reflect that conversation, not precede it. The organisational readiness dimension in particular cannot be completed honestly without your manager's input.

Once your feasibility check is complete, use the AI blind-spot prompt from this lesson on your written assessment. Add any relevant questions it surfaces to a short action list — specific things you need to confirm or resolve before writing your business case in Lesson 3.

Finally, write two to three sentences describing how you have refined or adjusted the scope of your project as a result of this lesson's analysis. If the scope is unchanged, explain why the feasibility check confirmed rather than challenged it.

Bring your completed feasibility check and your action list to your coaching session.

⏭️ Up next — Lesson 3: With your value estimate and feasibility check complete, Lesson 3 brings all of it together into the five-component business case document — and prepares you to defend it verbally at the gateway.