A project can look manageable on a roadmap and still be too much to introduce well. The scope is agreed, the system is configured and the launch date is visible. Then the calendar fills: testing, training, feedback sessions, data checks, regional questions and the normal work that has not stopped while the project is happening.
At that point, implementation can quietly become extra work for the people expected to adopt it. The pressure is often explained as a communication or motivation problem. Sometimes it is. But often a more basic question has not been answered: when will people have the time and attention to learn a different way of working?
Capacity is part of the design
Time is not only a delivery constraint for the project team. It is also a design constraint for the change itself. If a new workflow needs a manager to explain it, a team to practise it and someone to resolve what does not fit, those activities need a place in the plan. Otherwise they will be squeezed into evenings, postponed until after launch, or carried by the few people who are already trying hardest.
This does not mean every project needs a long rollout. It means the size of the change should match the room available to absorb it. A small improvement with clear ownership can be easier to learn from than a broad release that leaves no space for feedback.
Start with one useful slice
A useful first step is not a pilot for its own sake. It is a contained part of the work where the team can learn something real: one process, one group of users or one recurring decision. The point is to test the new route in everyday conditions, not in a version of the work that has been made artificially simple.
Before starting, agree on three things:
- What will change now? Name the specific task, handoff or decision—not the whole future system.
- What will people need? Include time for practice, a place to ask questions and someone who can make a decision when the process does not fit.
- What will decide the next move? Set a short review point, using both what happened in the work and what the people doing it noticed.
Make the hidden work visible
Implementation research often describes an effort in terms of its actor, timing and dose: who is doing the work, when it happens and how much of it is required. That language can feel formal, but it asks a practical question. When a project adds workshops, testing rounds or new support tasks, whose time is being used?
Making this visible can improve the conversation. Instead of asking people to “make time,” a team can decide what to pause, simplify or move. It can also reveal when the proposed sequence is too ambitious. That is not a failure of commitment. It is useful information about the design.
Use the first release to learn, not to prove the plan was right
After the first slice has been used, ask what took more effort than expected, what became easier and which exceptions returned. Then decide whether to extend the change, adjust it or leave it where it is for now. This makes a rollout less like a promise to complete everything at once and more like a series of informed choices.
If a new way of working would require people to absorb it on top of already full weeks, then make that cost visible before committing to the launch. Choose the smallest change that can teach the team what to do next.
Further reading
- Bunger et al. — Tracking implementation strategies. An observational example of tracking actors, timing and effort across an implementation.
- Li et al. — Organisational context and implementation. A systematic integrative review from healthcare settings, useful for thinking about the interacting role of resources, communication and feedback.