by Michael Carter
When you think of root cause tools, does process map come to mind? Apart from being used to document a current or future state process, it is also used as a communication tool. I ask all teams to construct a process map as a way to keep the teams aligned with the project scope. The added benefit I’ve come to understand is …
its use as a root cause tool. But first, a few basics. When constructing a process map, always begin with “Start” – a designated or easily identified starting point for the process under consideration (i.e. the beginning of scope). Staying at a high level, continue to document the process steps and decision points through to the end of the scope which is clearly labeled with “End”. Keep the process map at a high level in the beginning (10 process steps or less) because the project may never require more detail and if time is invested now, it may be a waste. If more detail is required later in the project, a detailed process map may be necessary.
Once the map is finished, it is time to look at it through the eyes of one looking for root cause. To do that, ask:
Where do the handoffs occur?
Where is data transformed?
Where is special attention required by operators?
Where are the inputs not clear?
Where are the outputs not clear?
Where are the instructions not clear?
Where is specialized training required?
Where is special handling required?
Where is the process confusing?
Where are the specification limits non-existent or poorly defined?
Where is unusual behavior required?
Where does inconsistency frequently appear?
Where is rework built into the process?
Where is QC or inspection built into the process?
These are areas for delay, mistakes, defects, mis-communication, throughput and process velocity problems. Use these questions as a starting point for your root cause discussion and be amazed at how often root cause is discovered.