Digital adoption
Roll out a new workflow with your team, not at your team
Test a small change, prepare French and English task guides, and expand only when real work supports the decision.
The software is ready, but staff still use the old spreadsheet because exceptions, training and support were left until launch day.
Pilot one complete task with the people doing it. Treat guidance, support and fallback as part of the delivery—not an afterthought.
Test the work, not just the buttons
A demonstration proves that somebody can show the software. A pilot asks whether the team can complete real work, including missing inputs, corrections and interruptions. Choose a bounded task and agree who supports it.
IHI's Plan-Do-Study-Act worksheet describes planning a test, carrying it out, learning from its consequences and deciding what to modify. It is a quality-improvement tool, not evidence that a particular software rollout will succeed. [1]
Apply that learning cycle to a small approved trial. State what you expect to improve, what could go wrong and what would make you stop. Include people who receive the work downstream as well as those entering it.
Write a task guide in the team's working languages
A useful quick-reference guide follows one task: when it begins, what the person needs, what they do, how they know it is complete and who helps if it fails. Avoid a tour of every menu.
For French and English guides, keep the same steps and version reference in both. Use short direct instructions and have people who work in each language check that the action and exception route mean the same thing. Machine translation alone is not a review.
Use approved screenshots with private details removed. Test each guide by asking a colleague to complete the task without coaching. Where they hesitate, improve the guide or the workflow rather than assuming they need to try harder. These are editorial recommendations, not a statement of Quebec legal compliance.
Use a decision gate before expanding
Record training attendance, but do not confuse attendance with capability. Ask users to complete a normal task and handle a common exception. Keep support reachable during the trial.
At the review point, examine completed work, corrections, unresolved questions and the time required for support. Decide to expand, revise or stop. There is no universally correct pilot length; use the task's frequency, risk and variation to judge whether you have enough evidence.
When you expand, name the owner of the procedure, both language versions and future updates. Keep the fallback available for the agreed transition period, but avoid two unowned systems becoming permanent competing records.
A practical rollout decision sheet
| Stage | Evidence to collect |
|---|---|
| Prepare | Task boundary, pilot users, support owner and stop condition |
| Practice | A completed normal task and a handled exception |
| Pilot | Handling time, corrections and support questions |
| Review | Decision to expand, revise or stop, with reasons |
| Maintain | Procedure owner and matching French/English guide versions |
A suggested rollout structure, not a funded training schedule or an eligibility claim.
Try it in your operation
- Choose one complete workflow and ask its users to identify the common exceptions.
- Prepare matching French and English task guides and review them with staff.
- Run a bounded trial with an accessible support owner and a fallback.
- Review work quality and support effort together before expanding.
How to tell whether it helped
Check first-pass task completion, corrections, requests for help and total handling time including support. Ask whether staff know where to find the current guide and how to report a problem. Usage alone does not establish that the workflow helped.
Sources & review notes
- [1]Plan-Do-Study-Act (PDSA) Worksheet
Institute for Healthcare Improvement
The rollout and guide recommendations are practical advice, not legal compliance advice or a promise of training funding. Do not infer client results from these planning examples.