Start small when the team has no spare time

There's a particular kind of project that never quite begins. Everyone agrees the business needs to modernise, somebody creates a roadmap and the meetings start multiplying. Meanwhile the sales team is still doing the same frustrating work every day.

If people are already stretched, announcing a major transformation is a difficult sell. They hear more meetings, more change and another thing to learn. I would start with something smaller and more useful.

Small is not a lack of ambition. It is how you earn the right to go bigger.

Find a problem the team already complains about. Meeting preparation, duplicate CRM updates, missing customer information or proposals rebuilt from old documents are all worth investigating. The right first problem is one you can see, measure and improve without redesigning the whole business.

Make the ask specific. A handful of people, a defined task, a short test and a review date. Tell them exactly what time you'll need and what they'll get back. Vague requests for people to 'get involved' tend to disappear behind urgent customer work.

1. 01One problem. Pick the friction your team complains about most often, not the one that sounds most impressive in a board pack. If people groan when it is mentioned, you are in the right place.
2. 02A small group. Choose 3 to 5 people who feel that friction and are willing to try something different. Include at least one sceptic, because their objections will make the result stronger and their support will carry weight.
3. 03A baseline. Measure the task as it is today, in time, quality or both. Without a baseline, the conversation at the end has nothing to measure against.
4. 04A fixed review point. Agree in advance when you will look at the results and what would count as worth continuing, changing or stopping. Write it down so nobody moves the goalposts later.

Measure the current task before changing it. How long does it take? How much correction does it need? What does good look like? If you skip that, the end-of-project discussion becomes a contest of opinions.

Include somebody sceptical. Not to manufacture a success story, but because they'll find the problems an enthusiastic pilot group might overlook. If the workflow survives their questions, you're in a better position to share it.

At the review point, make a decision. Keep it, improve it or stop. Don't keep extending the pilot because nobody wants to admit it hasn't worked.

Small changes can create confidence for larger ones, but only when people see the benefit in their own work. A useful improvement their colleague recommends will often travel further than another presentation about the future of AI.

When the review point arrives, look at the evidence honestly with the group involved. What changed, and by how much compared with the baseline? Did people keep using the new way when nobody was watching? What would they change? Then decide: extend it to more of the team, adjust it and run again, or stop and choose a different problem. Each of those is a good outcome, because each is a decision made on evidence.