Feb
24
2015Going to the Gemba to understand you have to see it
Quickest way to map a process is to walk it :
The client was part of a large multinational company and struggling to deliver the required engineering services to other parts of the parent company. At the start of our work delivery of over 40% of engineering projects was late to schedule, threatening the overall project schedule. This situation meant the management team was coming under a lot of internal pressure and losing the respect of their peers.
Situation :
Previously this specialist instrumentation engineering group would get a request from another part of the company for some instrumentation work. The work would be done and sent back “over the wall”. This had been considered end of story, except for frequently requested changes to deal with a myriad of implementation and parts availability issues. The process was changed so that the instrumentation group now had to deliver a complete solution to “Project Build” not just drawings. The deliverables the group needed to achieve had changed but the how the management team managed the group and projects had not changed. They were still hoping for the best and coming up short.
The Process:
The first step was to understand the process from client request to delivery to Project Build. On asking what the process was no one could confidently define it. So we set off to follow the paperwork. We started off in our own office and moved on to the next steps asking where work came from and where it went at each step. A couple of hours later we were at “Project Build” and had a completely different understanding of the process problems we faced. We found we were unintentionally creating an incredible amount of work for another group along the process. They were the now the bottleneck in the process and the work was mostly unnecessary. Back at the office we quickly drew up some simple new project rules and implemented them that afternoon.
Results :
The result was we reduced the amount of work we sent the downstream group by 60%. This meant that work was processed faster reducing project cycle time. It also seriously improved our relationship with the downstream group enabling rush jobs to be done. Along with other changes the group went from 40% of projects being late to all projects being delivered to schedule. This took pressure off the management team who also gained a reputation of having turned a bad situation around.
The client was part of a large multinational company and struggling to deliver the required engineering services to other parts of the parent company. At the start of our work delivery of over 40% of engineering projects was late to schedule, threatening the overall project schedule. This situation meant the management team was coming under a lot of internal pressure and losing the respect of their peers.
Situation :
Previously this specialist instrumentation engineering group would get a request from another part of the company for some instrumentation work. The work would be done and sent back “over the wall”. This had been considered end of story, except for frequently requested changes to deal with a myriad of implementation and parts availability issues. The process was changed so that the instrumentation group now had to deliver a complete solution to “Project Build” not just drawings. The deliverables the group needed to achieve had changed but the how the management team managed the group and projects had not changed. They were still hoping for the best and coming up short.
The Process:
The first step was to understand the process from client request to delivery to Project Build. On asking what the process was no one could confidently define it. So we set off to follow the paperwork. We started off in our own office and moved on to the next steps asking where work came from and where it went at each step. A couple of hours later we were at “Project Build” and had a completely different understanding of the process problems we faced. We found we were unintentionally creating an incredible amount of work for another group along the process. They were the now the bottleneck in the process and the work was mostly unnecessary. Back at the office we quickly drew up some simple new project rules and implemented them that afternoon.
Results :
The result was we reduced the amount of work we sent the downstream group by 60%. This meant that work was processed faster reducing project cycle time. It also seriously improved our relationship with the downstream group enabling rush jobs to be done. Along with other changes the group went from 40% of projects being late to all projects being delivered to schedule. This took pressure off the management team who also gained a reputation of having turned a bad situation around.