It has been a few weeks since I last wrote on this blog.  At work , we were busy with an implementation of mobile technology in our maintenance department.  That brought me back to the various stages of Lean and the actual improve stage.  Whether you are using Six Sigma Lean and the DMAIC or Define, Measure, Analyze, Improve and Control methods or the straight Lean PDCA- Plan, Do, Act, Check method, you need to at some point pull the trigger.  That is exactly what we did last week.   This stage is starting to become one of the tougher ones for me because of past failures. I pulled the trigger too soon on several occasions when we were not ready and it blew up in my face.  I tend to draw out this improvement phase by planning, planning and more planning.

This time it went well.  We as a team planned, prepared, trained and looked at the calendar to finally decide when to implement.  Here are a few of the tools that we used and that you might decide to use when going through the improve stage of a lean project.

1. Future State Map:  I consider the analyze stage the right place to vet out different options for improvement.  I consider myself at the improve stage once the solution is in hand.  Do not fool yourself.  There is still a lot of work to do.  You need to sit down with your team and map out exactly how the day to day work will look with the solution or counter measure in place.  Gain a firm understanding of what will happen from a high level and make sure that it fits your business needs. We did this and showed how maintenance work orders would move through the value stream from creation to assignment to the work being completed and billed.  This gave us valuable insights on where we needed to focus attention during the implementation.
2. Failure Modes and Effects Analysis: Fancy way of saying think through all the shit that could go wrong before implementing improvements to identify and address potential problems that may arise using the improved process. Sit down and thing of all the issues, list them, discuss the likelihood of them occurring and then create solutions.
3. Standardized Workflow: When you decide your new processes you need to work with the team and staff to document everything!  Everyone needs to be on the same page whether it is in written or verbal form.  We created standard operating procedures for all of our maintenance techs that they could take in both paper and electronic form.  These are for them to fall back on if they have questions about how to use the technology.  We created standard operating procedures for the office assistants who jobs changed and we created standard operating procedures for the supervisors whose jobs changed slightly.  Will they pour over these documents everyday?  No.  However; we have them and next year when we role this project out further, we will be prepared.   Outside of what buttons to press and when to press them a lot of other questions came up.   What happens if a maintenance tech receives an emergency work order in the middle of the night?  Should the tech create a work order?  What happens if he does not go out and fix the issue because it can wait until morning?  We sat with the actual team including supervisors to make this decision.  We could not make it for them.  Once we came to an answer, I created standard operating procedures to document this.  We will have more of these pop up.  The important thing is to listen to the people doing the work and let them decide what business process makes the most sense and help document and train.
4. Training Plan:  If there is one f*&#&g thing I’ve learned in my short career, do not go into an implementation without a solid training plan.  We created standard operating procedures for all of our staff but training was another issues.  We created a plan ahead of time and discussed what we wanted to train on and in what ways.  We decided we wanted to do a group training, small group training followed by one on one assessments.  We discussed how we wanted to train supervisors and office assistants and captured the plan on paper.  After that, we actually wrote training scripts for our bigger trainings and agreed on them.  We went further and actually trained the trainer and all practiced training each other to make sure we were delivering the same message.  We made sure to train early and allow for staff to practice.  We monitored their practice and looked for ways to improve during this training phase.  We also came back in at the end and provided training to refresh everyone before the implementation.  This was all laid out in our initial training plan that was laid out early in the project planning.
5. Go-Live Support Plan-  This ended up being overkill but it was good to have.  I cleared my calendar weeks ahead and decided to work from the maintenance office for the week.  The I.T. staff were also ready to go and in place if needed.  After Monday morning it became clear my presence was not needed.  There were a few questions but nothing that could not have been handled by a telephone call or email.  The major idea though was to show support.  Staff needed to know we were there and ready to assist.

Conclusion:  I started preaching earlier this year the need to really think through and measure issues before jumping to solutions.  Same thing with implementing solutions.  If you do not plan well, implementations can blow up.  Even with the best plans, there can be plenty off issues.  Do not blow this stuff off.  A shitty go-live can lower morale and cause you to lose staff really quickly.  You and the team are looking to improve the situation and making it longer/harder is a fast track to failure.