The system has launched. Training has been delivered. Staff have access. Yet requests still arrive through informal channels, approvals take place outside the workflow and the monthly report depends on somebody's private spreadsheet.
This situation should prompt a management review before another software purchase. The organisation may have introduced a new tool while preserving the behaviours that made the old process unreliable.
A technology project changes what the business can do. Adoption determines what it actually does. That distinction matters when directors are deciding whether the investment is producing value or whether a further rollout should proceed.
Observe the work after training
Training attendance confirms participation. It says little about whether an employee can complete a real task under normal workload.
Watch a request move through the process from entry to closure. Include incomplete information, an urgent exception, a correction and a handover between departments. These are the circumstances in which a process either becomes useful or is bypassed.
When a workaround appears, investigate the reason. The employee may lack authority, the required information may arrive too late, the screen may make a routine task unnecessarily difficult or a supervisor may continue to demand the old report.
Those causes require different responses. Coaching can address a knowledge gap. It cannot remove an unnecessary approval or repair a poorly designed handover. Treating every workaround as resistance can prevent management from seeing a legitimate operating problem.
There should be a controlled way to raise these issues and record the decision. Staff need to see that a problem reported through the process can be resolved through the process.
Stop rewarding the behaviour the project was meant to replace
If managers accept verbal approvals, ask for unofficial spreadsheets and make urgent exceptions without recording them, employees receive a clear message about which process has authority.
The sponsor should use the new information in normal management discussions. Supervisors should refer to the agreed workflow when assigning work and reviewing completion. Exceptions need a defined route so that operational flexibility does not create an invisible second system.
Prosci's discussion of reinforcement emphasises the continuing actions that sustain changed behaviour. My application of that principle is practical: align the daily management routine with the process the business has chosen to adopt.
This also means reviewing incentives. A target based solely on speed may encourage staff to skip the information needed for a reliable handover. A department measured only on its own completion can transfer unfinished problems to the next team.
Management should make the desired outcome clear and ensure that the measures do not reward the opposite result.
Retire the old process deliberately
Parallel working can be useful during a controlled transition. It becomes costly when two competing records remain indefinitely and nobody can say which one governs a decision.
Agree the conditions for retiring the old forms or spreadsheets. These should include dependable completion of the core workflow, a route for correction, appropriate access and a tested fallback for interruption. Set an owner for the retirement decision.
Some records may still be needed for legitimate purposes. The answer is to define their role and relationship to the main process. Requiring staff to maintain duplicate information without a clear use creates reconciliation work and weakens confidence in the change.
A fallback also needs a return procedure. If work is recorded temporarily outside the system during an outage, somebody must reconcile and enter it afterwards. Otherwise, the exception becomes a permanent gap in the operational history.
Judge adoption by the result the business bought
Logins and records created can indicate use. They do not establish that the original problem has improved.
If the objective was to reduce lost maintenance requests, examine whether requests reach an accountable owner and whether closure can be verified. If the objective was faster approvals, measure the elapsed time across the complete route and identify where work waits. If it was dependable reporting, test whether the report can be produced without extensive manual reconstruction.
Use the baseline established before the change where available. If no baseline exists, acknowledge that limitation and establish a consistent measure now. A precise percentage improvement should not be manufactured from incomparable records.
Early reviews should combine these results with observation and staff feedback. A promising average can conceal a group of users or a particular task that is still struggling.
The decision to expand should follow evidence that the process works under ordinary operating conditions. The leadership team should be able to explain what improved, what remains unresolved and who owns the next correction.
That is when a system implementation begins to become an operational investment with a defensible return.