Building  a “Lean” Engineering Work Cell

Applying Lean to the Engineering and Project Management process is not the typical application for Lean. This is the third time that I have had the opportunity to build an Engineering Work Cell. Each of the work cells have seen a marked increase in the total number of projects that could be completed. (30%, 32% and 36% respectively) By implementing more frequent and smaller approval batches, we reduced the total number of errors. These errors were found closer to when they occurred, allowing for near real time training and coaching by the approving Engineer. Our unintended benefit of the work cell, was simplified new employee training. The Lean work cell allowed for new members to join the cell and be actively completing billable tasks on their first day of work.

The cell design focused on making the work visible at each step in the process.  This started with the first Tasks introduced into the cell; to completed work being submitted for approval; and then to the final work completion. Within the first two weeks of start up the number of the billable hours became predictable. We then balanced the work cell for work volume by skill sets within the cell. Cross training of the engineering vocations and designers, further improved the cells ability to speed up to accommodate change in customer demand.  The vocations were still specialized but not completely limited in the work they could pull from the production board. Our toggle for a drop in demand was to induct new product development work into the work cell. This work was queued and ready to go.  The transitions between the work cell toggles were seamless, the source of the input tasks changed and the process output remained constant.

The “Task” approach, focused on reducing the Engineers batch size from several projects down to 2 hour segments of Engineering work.  Tasks that Engineering and Designers could complete without interruption. Essentially, they broke the complex Engineering and Design functions into manageable pieces that could be spread across the entire team. Our approach did not devalue the Engineering function, instead it provided the Senior Engineers with a regular cadence for work review and approvals. Setting up for more frequent coaching of the Junior Engineers closer to the time when the work was executed. The increased frequency and smaller checks, ensured that the errors were found before they had a chance to propagate through the entire design.

For the work cell to function properly some Key Rules of Engagement had to be established. The first rule was that checking had to be the first priority for the senior Engineer.  We discovered when checking approvals grew, the overall inventory in the work cell also grew. The daily task output of the cell would drop off quickly when they fell behind on approvals. Both the Designers and Engineers would take on other work tasks, but their minds were still stuck on the work in the approval queue. Without completely closing off their work in the approval queue, they still think about the work completion and the possible errors within.  This resulted in more mental switching that leads them to leaving files and information open on their desktops.  These distractions, interruptions and unanswered questions magnified the wastes while they waiting for their tasks to be approved.

The second rule of engagement was that the Tasks had to be grouped by project and project phase inline with the project delivery process. (Concept Design; Detailed Design; Construction Drawing; Turnover Packages.) This was done for the benefit of the Approving Engineer who needed to be reviewing and thinking about the design from the perspective of the whole. This improved the rate of checking by reducing the mental switching. Some standard key best practices were also incorporated to ensure the cell would function. Like the white board that acted as a Kan Ban, the morning meeting in front of the board where we looked at the plan for the day and invited the cell members to voice any issues or concerns.  The members would share how they did with yesterdays work; plan for todays work, and anything that was blocking them from being successful. This daily dialogue was key to getting the Work Cell Members to speak up and ask for help as they needed it.

Knowledge worker productivity is not always measured on a day to day basis. In the Engineering work cell we know how many Task hours should be completed each day. The work cell lead has the authority to extend work hours before we fell behind, and induct New Product Development work as project work slows down. By understanding work cell output relative to our customer demand, we are able to maximize every one of our precious Engineering hours. My approach to the Engineering Work Cell is loosely based on the concepts from the book “Lean Product Development” by Ron Mascitelli.  We took his ideas and Engineered ourselves a work cell.

Michel Handfield, C.E.T., LSSBB