The hardest part of a first AI implementation is that you have no basis for judging any number you are given. A vendor says six weeks and you cannot tell whether that is optimistic, because you have never done this and neither has anyone in the building. Every later project benefits from a reference class you do not yet have. That is the argument for choosing your first use case by reversibility and data readiness rather than by impact: the first project’s actual job is to build the organisation’s judgement, and a boring workflow that finishes teaches you far more than an ambitious one that stalls.
The Five Things to Get Right the First Time
- Pick the boring use case. High volume, low stakes, easily reversible, and nobody’s reputation attached to it.
- Check the data before the tool. Readiness work usually dominates the timeline and is invisible in every vendor estimate.
- Do not buy a platform first. Committing to infrastructure before you know what you will build on it inverts the decision.
- Assume the timeline is optimistic. Without a reference class you cannot calibrate, so build in margin you would not need later.
- Treat the first project as education. The capability you are buying is your own team’s judgement about the next three.
Written for IT directors and operations leaders at 50 to 500 employee firms doing this for the first time.
Why First Projects Get Chosen Badly
First projects get chosen for visibility, because the conversation usually starts with an executive who saw something impressive rather than with a team who has a bottleneck. That origin sets the frame, and the frame is wrong for a first attempt in almost every case.
Visibility Is the Worst Selection Criterion
A high-profile first project puts your least-experienced attempt in front of the largest audience. If it works you have learned something at high risk; if it stalls the whole program inherits the reputation, and the second proposal is harder to fund than the first. Choose instead something unglamorous with real volume: document classification, intake triage, first-draft summarisation of routine records. The people who benefit will notice, and nobody outside the team will be watching while you learn how this works.
Reversibility Beats Impact
Ask what happens if you switch it off after eight weeks. Where the answer is that people resume the old process with no lasting consequence, you have a good first candidate. Where switching off means unwinding changes to records or explaining something to customers, save it for your third project. This is a different criterion from the risk assessment in are AI agents safe for enterprise use, which asks what could go wrong; reversibility asks how cheaply you can change your mind, and for a first project that matters more.
The Use Case Nobody Is Emotionally Attached To
Avoid the process somebody redesigned last year and is proud of, and avoid the one a senior person has already decided the answer for. A first implementation goes better where the team is mildly frustrated with the current process and has no investment in defending it. This sounds like politics and it is engineering: the time you would spend negotiating is time not spent learning what the technology does in your environment.
The Data Work Nobody Estimated
In most first implementations the data preparation takes longer than everything else combined, and it appears in no vendor timeline because the vendor is not doing it.
Find Out What Shape Your Data Is Actually In
Before committing to a timeline, look at the records the workflow will consume: how consistent is the format, how much is free text, how many exceptions exist, how much lives in somebody’s inbox rather than a system. The answer determines the project length more than any technical decision. We do this in the first week now, because the alternative is discovering in week five that the format changed in 2023 and nobody normalised the history. The governance groundwork underneath is the subject of data governance for cloud-first organizations.
Access Is Its Own Project
Getting the AI system connected to the data usually requires permissions, a service account, a security review, and somebody’s approval, and each of those has a queue. Start them in week one rather than when you are ready to integrate, because they run in parallel with everything else and they are the most common cause of a first project sitting idle. The technical patterns for connecting systems are covered in how Claude MCP unlocks real-time enterprise infrastructure and the security side in Claude API security best practices.
Good Enough Data Is a Real Standard
Perfect data is not the bar and waiting for it kills first projects. The bar is whether the messiness is systematic enough that the workflow can handle it, which is a question you answer by testing on a real sample rather than by inspecting a schema. Where a category of records is genuinely unusable, exclude it explicitly and say so, rather than letting it degrade the whole result quietly.
Buying Decisions You Cannot Yet Make
First-time adopters are routinely asked to make platform commitments before they know enough to make them, and the order of those decisions matters more than the decisions themselves.
Build the First Thing on Something You Can Leave
For a first project, choose the option with the lowest exit cost even if it is not the most capable, because the most valuable output of the project is knowing what you actually need. Committing to a platform beforehand means the second project gets designed around a choice made when you knew least. Our enterprise AI integration practice usually starts first-time clients on the narrowest viable tool and revisits the platform question once there is evidence to decide with.
You Cannot Evaluate Vendor Claims Yet, So Test Instead
Without a reference class, vendor claims are unfalsifiable to you. The corrective is not better questioning, it is a small paid test on your own data with your own success criteria, which turns an argument about capability into an observation. Vendors who decline a scoped test have told you something useful. Structured measurement of that test is covered in continuous AI evaluation and risk control.
Budget for the Second Half
First implementations concentrate budget on building and underfund everything after go-live: the fixing, the tuning, the training, the person who owns it. Reserve a meaningful share for the three months following launch. That period determines whether the thing survives, and a project that spends its whole budget reaching launch day tends to be abandoned quietly a quarter later. Enablement for that phase is what our AI implementation training exists to cover.
Extracting the Lesson Rather Than Just the Result
The first project produces two outputs and organisations reliably keep only one. The working system is the visible one; the calibration is the valuable one.
Write Down What You Got Wrong While It Still Stings
Within a fortnight of go-live, record what took longer than expected, what turned out to be irrelevant, what nobody thought to ask, and which vendor claim did not survive contact with your data. Do it while the memory is fresh and the discomfort is still useful, because six months later the project will have been smoothed into a success story and the specifics will be gone. This is the document that makes your second estimate credible, and it is the single asset a first project produces that nobody can sell you.
Name What You Now Know You Do Not Know
A first implementation reveals the shape of your ignorance as much as it fills it. You will finish knowing, for instance, that nobody owns data quality in one system, or that your security review queue is six weeks rather than two, or that a particular department will need a different approach entirely. Write those down as known unknowns with an owner attached rather than letting them resurface as surprises in project two. Half of them turn out to be worth fixing on their own merits regardless of what you automate next.
Decide Who Carries the Knowledge Forward
The person who learned the most on the first project is usually a single individual, frequently not the project sponsor, and often not formally assigned to the next one. Identify them and make them a standing part of the next project even in a small capacity, because the alternative is repeating the whole learning curve with new people. Where that person is external, budget deliberately for internal shadowing rather than assuming knowledge transfers by proximity, which our AI implementation training is built around.
Frequently Asked Questions
What makes a good first AI use case?
High volume, low stakes, easily reversible, with reasonably consistent data and a team that is not attached to the current process. Impact is the wrong primary criterion for a first project, because its real output is your organisation’s judgement about what to do next.
How long does a first AI implementation take?
Longer than the vendor estimate, and the variance sits almost entirely in data readiness and access approvals rather than in the technology. Look at your actual data in week one and start the permission requests immediately, since those two items set the timeline.
Should we hire an AI specialist before starting?
Usually not for the first project. Use external help for the build and invest in growing internal capability alongside it, because a specialist hired before you know what you need tends to arrive with a solution looking for your problem. Hire once you can describe the role from experience.
What should we spend on a first implementation?
Less than you expect on the build and more than you expect on the three months after launch. Reserving budget for post-launch fixing, tuning and ownership is what separates first projects that survive from those quietly abandoned a quarter later.
How do we know if our data is ready?
Test on a real sample rather than inspecting a schema. Consistent format, limited free text, few exceptions and a single system of record are good signs. Where a category of records is genuinely unusable, exclude it explicitly rather than letting it degrade the result.
Who Is Behind This Guidance
Our team runs first AI implementations for firms between 50 and 500 employees, which means we spend a lot of time on the part that has nothing to do with models: looking at data, chasing permissions, and talking an executive out of the impressive use case in favour of the boring one. That last conversation is uncomfortable and it is the highest-value thing we do for a first-time client. We have also inherited enough stalled first attempts to know how they stall, which is rarely technical. Matt Rosenthal, Mindcore’s CEO, keeps the practice focused on making technology decisions defensible to the people funding them, and for a first project that means a result a board can read rather than a demonstration. That is the standard this is written to.
Choose Something Boring and Finish It
Pick a high-volume, low-stakes, reversible workflow where nobody is attached to the current process. Look at the real data in week one and start the access requests the same day, because those two set your timeline. Use the narrowest viable tool rather than committing to a platform you cannot yet evaluate, and replace vendor argument with a small paid test on your own data. Reserve real budget for the three months after launch. Then treat what you learned as the deliverable, because the second project will be chosen and estimated far better than the first, and that improvement is worth more than the first project’s own return. Most first-time adopters we meet are choosing between an ambitious idea and a boring one and are about to pick wrong. If you want help making that call and running what follows, our enterprise AI integration practice starts with the use case rather than the tool. Bring your two candidate workflows to a free strategy call and we will tell you which one to do first.
