The Monday morning problem
Here's a scene that plays out in procurement departments everywhere. A manager attends an AI webinar. Maybe it's about spend analytics, maybe contract intelligence, maybe supplier risk. The demo looks genuinely useful. The presenter mentions efficiency gains — in some industry studies, teams using AI on structured procurement tasks report cutting processing time by 40 to 60 percent on those specific workflows. The manager leaves the webinar thinking "we should do something with this."
Monday morning: inbox, three supplier escalations, a budget review meeting at 10. The AI thing goes to the bottom of the stack. Six months later, nothing has changed. The tools exist. The problem isn't access to tools anymore. The problem is not knowing where to touch the system first.
Name the task before you name the tool
The most common mistake isn't picking the wrong tool. It's buying a tool and then looking for a problem that fits it. You see it constantly: a company subscribes to an AI platform, spends two months on onboarding, then realizes no one knows what specific work it should replace. The adoption stalls because there's no concrete before-and-after to point to.
Start the other direction. Open a blank document and write down the five tasks in your week that feel most like manual labor. Not strategic work. Not the things that require judgment. The things that are repetitive, information-heavy, and low-stakes if an AI gets them 80% right — because you'll review them anyway.
Common answers in procurement teams: summarizing supplier email threads before a negotiation meeting, formatting quotation comparison tables, pulling delivery data from emails into a spreadsheet, writing first drafts of RFQ scope documents, chasing internal approvals.
One task from that list. That's your first project.
Find the person who's already impatient
Every team has one. Someone who's been complaining about a specific manual task for longer than anyone can remember. They're not waiting for top-down permission — they've already tried a workaround using Excel macros, or they copy-paste things into ChatGPT in their own time, or they've mentioned three times that "this is insane, there has to be a better way."
That person is your co-pilot for the first project. They know the task in detail. They're motivated to make it work. And because they're already frustrated with the status quo, they won't give up when the first attempt isn't perfect — they'll iterate until it is.
Managing it top-down — "everyone will now use this tool" — almost never works for first AI projects. The adoption gap that kills most initiatives comes from skipping the single motivated person and going straight to mandatory rollout.
What "starting" looks like at 50 vs 300 people
At a 50-person company, the first AI project is almost always informal. One person, one task, one tool, two weeks. You don't need a steering committee. You don't need a business case. You pick something from your list, run it for two weeks, and see what happens. If it saves three hours a week and the output quality is acceptable, you document it and expand it. If it doesn't work, you cross it off and try the next item on your list.
At a 300-person company, the mechanics are similar but the paperwork is heavier. You'll probably need to go through IT to confirm data security requirements — especially if you're processing supplier contracts or spend data. Plan for two weeks of procurement project time, but also one to two weeks of IT coordination. The total is still under a month for a first working prototype.
Run for two weeks, then decide
Two weeks is enough to know whether an AI approach to a specific task is viable. Not polished, not optimized — just viable. You're looking for three signals: Does it save meaningful time? Is the output good enough to be useful (not perfect)? Does the person using it want to keep using it?
If all three are yes, you've found something worth building on. Document the prompt or the workflow, train one more person, see if the same results hold. If two of three are yes, dig into what's failing — sometimes a better prompt fixes it entirely. If only one or none are yes, close it down and move to the next task on your list. No shame in that. The point of a two-week test is to find out quickly without sinking three months into something that doesn't work.
A real example to anchor this
Contract monitoring is one of the cleanest starting points in procurement — the task is well-defined, the current process is purely manual, and the output is easy to verify. If you use SharePoint and Power Automate, you can build a flow that reads every new contract, extracts renewal dates and price adjustment clauses, and posts a summary to Teams. The build takes about 30 minutes. The full walkthrough is here. It's the kind of first project that costs nothing extra (it runs on your M365 licence), produces a visible result in week one, and actually changes how the team works.
What slows people down
The two most common blockers aren't technical. The first is perfectionism — waiting for the right strategy document, the right AI partner, the right moment when everything is aligned. That moment doesn't come. The second is scope creep before launch — the task starts as "summarize supplier emails" and by week two the plan includes CRM integration, a custom dashboard, and automated spend reporting. Scope that before anything is running means nothing runs.
Pick one task. Run it for two weeks. That's the entire framework.
There's no elaborate methodology here. The teams that get moving are the ones that stop planning and start testing. Pick one task from your shortlist and run it for two weeks.