Process Documentation

A new project team forms to solve a business problem and asks the simple question, “What is the current process?” A little digging around yields a dusty old process document, but it is so out-of-date. The project team (in their element) run a brown paper process mapping to get the true current process.

Detailed analysis and design produces the new processes which are documented, delivered and rolled-out. Once trained, the teams know their roles and the process document goes into the draw to gather dust as people get on with their job.

  • Does this mean that process documentation is only a vehicle for transition from current-state to future-state?
  • How can you “bring the processes to life” in a transactional world e.g. visual controls?
  • How can you ensure processes do not become redundant but are fully embedded and updated as new working practises develop?

I am working on this at the moment and interested in hearing views on best practise and how they much they cost/time to implement.

Comments 5

  1. Mark

    Hi Robin, I’m a long time follower and first time responder! I’ve been in exactly the same situation several times… LSS transactional process improvement events. What I found to be the most successful way to change the process and get the team out of the "SOP" perspective has been to:

    – help them see what a "defect" is (obviously you need to do your due diligence in data collection – you need a strong data collection plan)
    – draw the huge ugly map with them with their data
    – have them rebuild the process in the event (Kaizen, if you will) and then update their SOP as they are doing this.

    The impact gets them to see what they should be doing versus what they are doing, people become vested in it and if the sponsor or champion truly supports this, it will stick. This becomes the basis to going to some form of "visual control" tool at a later date. Once again, this is a gradual process.

    What made our process changes so successful were multiple other processes in the same area were having similar process issues, we had done a lot of Green Belt / Black Belt and Yellow Belt (DMC) training prior to this and had strong sponsor support to "fix" the processes.

    One key learning that I had was to just guide the team in the process redesign, challenge them but let them own the redesign. They’ll get it and you’ll score a huge win as they "see" what their process really is and what they can make it. Of course, pilot your improvements and share the improvements in whatever metrics you have for the process so they can see it and believe in the change. Also, follow up with them and stay engaged with them after the new process is updated.

    Hopefully this helps you!

  2. Fang Zhou

    First, I agree with several important points Mark made.

    1. help people see what’s going on
    2. it is going to take time, no matter what you do
    3. involve stakeholders early and throughout the change

    In addition, what I often see in process improvement projects is too much emphasis on generation of the documents for rolling out the new process and not enough on how they are used for "continuous" improvement.

    Documentation should help people 1) see if significant deviations from the Standard Work occurred in the process and 2) if yes, what to do to correct it and/or update the Standard (SOP).

    It sounds simple because it’s basically Standard Work in Lean and Control phase in DMAIC. However, in practice few project teams spend time developing mechanisms to help operators to detect such deviations and to correct them or update the SOP.

    My view on this is that we are still not in a continuous improvement culture where PDCA is in everyone’s head everyday. We often think and behave as if process improvement is a project-based activity. Documents are collecting dusts because people think they are done with process improvement.

    The real improvement often lies in the daily discovery of actual significant deviations from the "documented" process, and subsequent learning and correction from such discoveries. Well developed mechanisms are required to discover such deviation. One component of such mechanisms is process metrics built in a Control Plan.

    Setting clear cycle time or WIP targets and their expected variations at critical process steps would be my first step to bring processes to life.

  3. Robin Barnwell

    Hello Mark & Fang

    Many thanks for your feedback.

    Mark, excellent approach – goal focus – direct involvement in improvement – continuous improvement

    Fang, thanks – to paraphrase – Kaizen – never standstill – constantly evolve the process – hence static documentation is redundant – need to think about standard work/defect approach to see how to bring to life (and when I will get a chance to try it out) – not sure about targets remember Deming rule 10 – Eliminate Targets


  4. Fang Zhou

    To follow up on Robin’s last comment, I want to clarify what I meant by "targets." I definitely agree with Deming’s principles.

    There is a distinction between 1) a target of a process metric for process improvement and 2) a target of the same metric for evaluating the performance of people.

    Setting a target for process improvement is equivalent to setting a Null Hypothesis. This target is not a goal to achieve, but a reference for people to compare and measure deviations from it.

    As Lean (Standard Work) teaches us, if the measured outcome differs significantly from the target, at least one of the two things happened: 1) the operator didn’t follow the SOP or 2) the target (as assumed in SOP) is wrong. Identification of either can lead to investigation and improvement. Without a clear target, no one would know whether either happened. This is how documentation (with the help of visualization) can engage people and help us identify improvement opportunities everyday.

    What has often been done incorrectly is that management uses the data (individual deviations from the target) to evaluate people, not the process. This is exactly what E. Deming wanted management to understand in his principles.

    A common barrier to continuous improvement is people do not know what is a significant deviation that warrants investigation. This is where Six Sigma concepts, such as Statistical Process Control (or simply special cause vs. common cause variations), can help. Without such understanding, people are going to misunderstand the purpose of measurements and misuse the data. That’s why I emphasized "and their expected variations" in my original comments.

    People have to understand that just because the outcome deviates from the average (expectation or target), it doesn’t necessarily mean there is anything wrong with that particular person or operation. So collect data and display on the board so everyone can see. Challenge them "do you see any significant variation? Why?"

    Hope this helps.

  5. Robin Barnwell

    So……a target is to achieve an evidence-based process improvement that disproves the null hypothesis. For this you would require a process that is in statistical control else the special causes disrupt the measurement.

    However most processes when first inspected through SPC present as out-of-control and improvements are required to remove special-cause.

    Hence process improvement can only really begin in earnest once a stable process is achieved and null hypothesis can be developed based on improvement opportunities – cause & effect.

    Yes – I like the thinking – thanks Robin

Leave a Reply