A new process succeeds when the people affected can understand it, use it, and get support when something goes wrong. Explain why the change is happening, involve users who know the work, and roll it out in manageable stages.
Explain the change plainly
Describe the problem, what will change, who is affected, and when the new way begins. Connect the change to fewer duplicate updates, faster approvals, or clearer handoffs. The outcome is better work, not simply a new tool.
Involve the people doing the work
Ask users to test the workflow and point out exceptions. Include their feedback, especially where responsibilities or customer communication change. Identify a point person who can answer questions and route issues.
Train, launch, and refine
- Prepare a short guide and live example.
- Test with a small group or low-risk workflow.
- Set a clear start date and support channel.
- Track adoption, errors, and recurring questions.
- Review what is not working and adjust.
Link the approved process to daily tools so employees can find it. Process documentation helps new practices stick.
How should I handle resistance? Understand whether the cause is workload, unclear benefit, missing access, or risk, then address it. Measure against a baseline after the team has used the process.
Explain the reason and the impact
People are more likely to adopt a change when they understand what problem it addresses and how their work will be different. Explain what is changing, what is staying the same, when the change takes effect, and where people can get help. If the change affects customers or other teams, include those handoffs in the plan. Avoid announcing a new process before the tools, access, and guidance are ready.
Listen for friction during rollout. A team member who returns to an old spreadsheet may be resisting the change, but they may also be missing access, unsure of the new steps, or responding to a real gap in the setup. Provide a clear way to report issues and decide who will review them. Small adjustments made early can improve adoption more than repeated reminders.
A practical rollout plan
- Describe the purpose and desired outcome.
- Identify the people, workflows, and customers affected.
- Prepare instructions, access, training, and support.
- Pilot with a small group or a limited workflow.
- Gather feedback, address issues, and confirm the wider launch.
Track adoption and the business result separately. A team may log into a new tool without using it consistently, and high usage alone does not prove the change solved the original problem. Review both behavior and outcomes, then update the process as needed.
Frequently asked: How do you handle resistance to change?
Ask what is difficult, clarify the reason for the change, and remove practical barriers. Involve affected people in improving the rollout while keeping accountability for the agreed outcome.
A worked example: moving a team onto a project tool
A team of six tracks work across chat messages, email and a shared spreadsheet. The owner wants everything in one project management tool. The version that fails is an announcement on Friday that the new tool starts on Monday. Two weeks later, half the team is back in the spreadsheet.
The version that works takes longer and involves the team.
- Explain the reason. Tasks are being missed because they live in three places. The goal is one place to look.
- Pilot with two people. They run one real project in the new tool for two weeks and report what is confusing.
- Adjust. The setup is simplified based on what they found.
- Train on real work. A short session uses the team's own tasks, not a demo project.
- Set a switch date and close the old route. After that date, the spreadsheet is read-only and tasks sent by chat are moved into the tool.
- Review after thirty days. What is working, what is being avoided, and why.
Mistakes that send people back to the old way
- Leaving the old way open. If the spreadsheet still works, people will use it. Retire it on a stated date.
- Leaders not using it. If the owner still assigns work by message, the team learns the new process is optional.
- Changing too much at once. One change, fully adopted, before the next one starts.
- Treating questions as resistance. Most pushback is a practical concern that nobody asked about. Ask early.
Where to start this week
Before announcing your next change, write two sentences: what problem it solves for the team, and what will be harder for them at first. Share both. People accept a change far more readily when the cost is acknowledged. If the change is a new tool, choose it carefully first with this comparison of ClickUp, Asana, Monday.com and Notion.
Want a second opinion on your operations?
Take the free Business Scale Readiness Assessment, or book a strategy call and I will tell you what I would fix first.