Visite nuestro sitio en Español: Confiabilidad.net    RSS | Contact

A New Process Does Not Work; What Now?

June 11, 2012
(Root Cause Analysis)

So you just implemented a new process in your plant. A team of workers put the process together and they believe it will work. While you are on your walk through in the plant you ask some of the other workers about the new process. You find out that it does not have wide acceptance. While talking to one worker, she puts forward a very convincing case of why the new process is a bad idea. You look into the information you have received and come to the understanding that this process isn’t going to do what you want it to do. What now?

The last thing you want to do is trump the whole process on your own. The team that put this process together has a lot of equity and ownership in it. Bring the team together and the person with opposing ideas together. Facilitate this discussion to keep it in the learning realm.

Most processes when first written are not going to be perfect. Let those who put it together work out the fix. Consider conducting Root Cause Failure Analysis (RCFA) on the development of the first process. While it is not a failure, it is a great learning opportunity for all involved.

Getting to the root cause of the problem will help identify the correct solution. Remember to facilitate these meetings to keep them from becoming a mudslinging match. The goal is continuous improvement and making things safer, effective, or more efficient. Keep it light, stick to the facts and do not allow personal attacks. This is normal in the Plan, Do, Check, Act (PDCA) cycle. The more this takes place in a non threatening way, the better for the future of continuous improvement for your organization.

Learn more about leadership, team dynamics and RCFA here.

 

Tip provided by: Clark Kimmel, CMRP Senior Consultant, People and Processes, Inc.

 

People and Processes Logo

 

 

Previous tip: Definition: Deterministic Vibration
Next tip: Frequency Response, Range, and Resolution

« Back to all maintenance tips

Comments (4)

  • Clark - this was a failure! - They didn't engage the right people in the initial process.
    "While talking to one worker, she puts forward a very convincing case of why the new process is a bad idea."
    That should have been captured in the P stage.
    This is a failure not only of the process you were trying to implement but also in the process of developing the processes!!

    1) Posted 7:09 am, 13 June 2012 by cliff williams

  • Cliff – I see what you are saying and you make a good point. I agree that when this happens you should not only look at the process that is not meeting the goal, but also the process of developing processes. Looking into both of these areas will lead to improved processes now and in the future.

    I can also understand why the first process can be called a failure. It did not meet the original desired effect that the process was written for. I chose not to call it one because most of the time the original written process requires only minor changes to make it a success.

    The main point is to get the people involved together and learn from the original process so that these minor changes will be successful. It is also to learn to put together better processes in the future.

    Thanks for the feedback.

    2) Posted 7:16 pm, 13 June 2012 by Clark Kimmel

  • Was the purpose of the walk-thru that iniated the staff interviews on the plant floor being done by an upper-level manager ? This is the impression that I get. In my version of the perfect world the upper-level managers don't have to ask anyone how the new process is going because they were the champions from the onset, attended the round table meetings that included every dept. and the technicians and operators. This kills two birds with one stone. The new endeavor is assured success and the foolish silos promoting dissention in the ranks are eliminated.

    3) Posted 1:24 pm, 14 June 2012 by Mark O'Brien

  • I think my thoughts are similar to other responders in that the "project team" should have included representation from all involved groups. Plus, there should have been discovery workshops to strategize goals, assess points of risk, ascertain cultural buy-in, and perform representative user sampling. Users want to know whats-in-it-for-them. Of course training is key part of any project roll-out.
    Coming back to your first point, if shop floor was caught off guard, you either had the wrong team member (team representative), or, they didn't fully understand their role in terms of setting expectations and communicating change.
    As far as RCFA, I think I already know the answer to problem. Once confirmed, this project needs to regroup with stakeholders and either consider a loss, or, re-implement.

    4) Posted 12:12 pm, 23 January 2013 by john reeve

Have your say

Comments are moderated prior to publication.
Please fill out the fields below.
Email addresses will never be published.

Comment guidelines

You can use basic HTML (a, strong, em, blockquote).
Links automatically use the nofollow attribute.
Off-topic or inappropriate comments will be edited or deleted.

Focal Point Links
Upcoming events
Knowledge Base Articles
Twitter Feed
Advertisement