Making it stick

Hi Lorax,
Not sure if you are using DMAIC for the improvement projects – if not, it would be a good idea.
Reason is that you seem to be getting the teams to midway the I – Improve stage. This pilots and verifies that solutions should work. (Looks like you’ve done this). The bits that look as though they may be missing would be to get Mgt sponsor/support for the solutions, with realistic target dates for full implementation, taking into account things that we know management are held accountable for (e.g. month end results etc). Some typical checks for the completion of Improve stage:
1. Has action plan been prepared with target dates and owners?
2. Have solutions been verified through piloting/testing
3. Do results of piloting suggest results can be achieved?
4. Does Mgt Sponsor/support the solutions. (Not just agreement)
5. Have refinements been made following piloting?
6. Have any negative/unexpected results been considered and addressed?
When all the above are ticked (we need to be quite anal about ticking these!!)…..
……..The final stage is then to Control. This would typically include standardising the solution, establishing control mechanisms (that can continually check improving trend, issues etc e.g. new KPIs) and most importantly, deploying the solution into the culture. Normally, this is the tough part – needs change management skills on the part of the team leader.
Guess in short, what I’m suggesting is that the projects are not finished until the Control stage has been satisfactorily completed.
Does this help, or are you looking for something else?
Best regards
Davy T

Lorax:
 
IMHO most of the challenge is with the transition from the project team to the process owner and the operators. Project managers like to think the project is complete when the solution has been found, piloted and turned-over to the process group/owner. Not the case. The project should be considered open for days/weeks after the solution has been implemented to ensure the change management pieces have become routine. Leadership too, should realize this and allow projects to include a longer post-implementation phase (Control).
 
Process owners and operators are no different than many (most?) of us. At times, we become comfortable with what we know and we become comfortable with a routine. The existing routine has to be broken, the new process established, the new process repeated/tweaked, repeated/tweaked, repeated, and repeated before it becomes the new routine.
 
Also, sometimes, “short and intense” projects blow by proper communication to all the participants. Everyone needs to know what is in it for them and why the change is necessary. It is especially important for the process owners as they are the ones who inherit/live with the changes. Project managers/project teams can have the mind set that they are doing the process owner a favor. Reality? The process owner may not directly realize the benefits of the changes but they directly experience the temporary inefficiencies.
 Good Luck! OLD

I can’t add much to the posts already listed – the people/change management needs are a must.
One addition I have had to implement during the improvement stage is Poka Yoke.  When you have people-intense systems such as healthcare, and make a process change, it is sometimes necessary to look into your systems to ensure that the process can’t be done the old way (not just by monitoring, but through system design). 
For instance, say you change a process that removes a particular inventory item that could be used.  The use of that item may have caused quality issues or simply be too costly relative to other alternatives.  After making the process change and getting employee buy-in, you make the item unavailable so they can’t use it even if they wanted to. 
Just an example, but this can be done in other improvement areas as well.  Doesn’t work all the time, but striving for defect proofing the system should be part of the improve and control process.  Dealing with the people and the system simultaneously often proves effective.