AI implementation means turning a business goal into a working process: choosing the right opportunity, defining what changes, building or configuring the solution, and improving it through use. I organize that work around Discover, Design, Deploy, and Drive.
“Use AI to save time” is an ambition. It is not yet an implementation plan.
To turn it into something useful, the business needs to decide which work should change, what a better result looks like, and how that result becomes part of an ordinary working day.
That is the connection I want an AI strategy to make. The strategy should guide the build, and the build should remain accountable to the business reason for doing it.
A roadmap is useful when it helps people make those decisions. The problem is not the document. The problem is treating the document as a substitute for everything that must happen next.
A recommendation should lead to a decision
Consider a hypothetical recommendation to use AI for client-status updates.
Before choosing a tool, I would ask what is wrong with the current updates. Are they too slow to prepare? Is information missing? Are customers unsure what happens next? Is the team preparing reports nobody reads?
Those are different problems. A faster summary does not necessarily solve any of them.
A stronger recommendation names the intended change: prepare a draft from agreed source information, flag missing items, let the responsible person review it, and deliver an approved update through the normal client channel.
Now there is something specific to investigate and test.
Discover: understand how the work happens
I start by learning about the business, its goals, and the work involved. That means asking questions, reviewing relevant examples, researching the context, and speaking with the people who actually perform the task.
The owner’s perspective is essential, but it should not be the only perspective. A team member may know about an exception, an unofficial spreadsheet, or a necessary check that changes the solution.
The aim is to understand enough to make a worthwhile recommendation, not to make every inquiry undergo the same exhaustive assessment.
Design: connect the goal to a workable approach
The output I aim for is a tailored growth and systems plan: worthwhile opportunities, recommended changes, and how implementation could proceed. It should give the client a clear direction before committing to the build.
A design should explain more than the proposed features.
It should establish the information the system needs, the actions it may take, the decisions that remain with people, and what happens when it cannot complete the work.
It should also make responsibilities, costs, and assumptions clear enough for the client to make an informed decision.
Microsoft’s AI use-case guidance evaluates business impact, technical feasibility, and user desirability. That is a useful reminder that an attractive demonstration is not sufficient: the idea must matter, be deliverable, and make sense for its users.1
For a complex situation, the next step may be a limited test rather than a commitment to the entire vision.
Deploy: test the work, not just the interface
A system is not ready simply because its screens load.
Test the normal case. Then test missing information, conflicting records, duplicate requests, unavailable services, and outputs that require correction.
Include the people who will use it. Can they understand the result? Can they correct it? Do they know when to trust it and when to ask for help?
For the hypothetical client-update system, the useful test is not whether AI can produce a fluent paragraph. It is whether the approved update is accurate, useful to the customer, and less burdensome to prepare.
Keep the review effort in the measurement. Time spent correcting a draft is still time spent doing the work.
Drive: improve through actual use
After launch, compare what happens with what you expected. A feature that looked important may go unused. A small exception may turn out to be common. A source system may change.
That feedback should inform the next improvement.
Ongoing work also needs a clear arrangement. Maintenance, incident support, feature development, hosting, and third-party usage are different responsibilities. They should not be hidden inside a vague promise to “stay involved.”
The right arrangement depends on the project. It should be understood rather than assumed.
Keep the strategy open to correction
Sometimes implementation exposes a weakness in the original idea. A sensible response is to revise the approach, not force the team to use something because it appeared on the roadmap.
Sometimes the best discovery result is to improve existing software instead of building a new system. Sometimes the cost or risk does not justify proceeding. GOV.UK’s discovery guidance leaves room for that decision.2
At Fidelis, Discover, Design, Deploy, and Drive describe a connected approach, not four boxes to complete regardless of what the business needs.
The goal is to move from uncertainty to a worthwhile change, then to a system people can use with confidence.
You do not need to know the tools, or even where to start.
Related reading
How to Identify AI Opportunities in Your Business
Custom Software vs. Off-the-Shelf: How to Choose
Microsoft Learn, “Business plan for AI agents.” https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/business-strategy-plan↩
GOV.UK Service Manual, “How the discovery phase works.” https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works↩