This article, the second of two, explores how organizations can adapt the 4S Help Chain Model to product and process development. Read the first part, Understanding the 4S Help Chain, Part 1: Lessons from NUMMI on How to Manage Work Disruptions, which describes the four critical characteristics of a help chain.
Over the years, I’ve learned from work experiences and other lean thought leaders — Jim Morgan, John Shook, Jeff Liker, my fellow LEI LPPD coaches, and others — that Toyota applied these same concepts to development work.
4 Essential Elements of the 4S Help Chain Model
Sense is the ability to recognize normal from abnormal as quickly as possible. The first step in any problem-solving methodology is problem awareness and its relationship to the current performance.
Signal is communicating easily and rapidly to the appropriate person that you need help based on a determined set of conditions.
The team leader or other designated person will swarm the area to assess and diagnose the situation.
To minimize the risk of having to stop the line, the team leader and team member must quickly solve the pending abnormality while also getting the development work back on schedule.
They used two levels of problem-solving, depending on the issue:
Level one (serve to protect) is to ensure safety and quality while keeping the line from physically stopping. At this level, the aim was to troubleshoot or complete a short-term problem-solving cycle of plan-do-check-act (PDCA), usually without identifying a root cause (this type of problem-solving happened all day long with each abnormality).
Level two (serve to prevent) is to understand the trends and major issues, get to the root cause, and work toward problem avoidance. This type of problem-solving usually happened offline or in weekly improvement circle meetings since it frequently required focus and collaboration.
With a few adaptations, the company created an effective and efficient social-technical system to keep development work and other long-cycle-time programs that are many months or years in duration on track. , Still, applying the 4S Help Chain Model to development is not as well-known as other lean practices– and is often missing from the obeya (“big room”) and other visual management systems that organizations use to track and maintain progress of the development programs.
Development teams use the obeya to create a visual, physical representation of the work that needs to be done over the program by all the functions and areas – to make the standard workflow visual. This representation is different from a traditional Gantt chart.
In the obeya, teams hang a paper timeline on the wall, including the work they must do and highlighting key milestone points, where the activities align across all the groups. Each group’s work responsibilities are plotted by week within a “swim lane.” If the current work environment is remote due to Covid-19 or geographically dispersed teams, the timeline may be digital or virtual but still simple and effective like the paper one.
In effect, this timeline depicts the development process just as the assembly line image shown earlier illustrates production. But instead of a single physical line, it illustrates multiple swim lanes representing the workflow across many areas, frequently including the work that’s to be done in a digital space, not only a physical space.
One difference from a production process is that development consists of two phases, an early study phase or learning phase and an execution phase, and two different visual obeya approaches are utilized. The study phase is when risks and knowledge gaps are identified, prioritized, and closed through learning cycles and research. Once the study phase is complete, the development team transitions to the execution phase, while updating the obeya to show all the swim lanes involved in configuring the product and process designs for a successful launch.
In both situations, the work progresses from left to right, with a dateline running across the swimlanes indicating the current day. If an activity falls behind schedule, it’s listed to the left of the dateline and usually color-coded red, highlighting the abnormal situation.
As Jim Morgan, LEI LPPD senior advisor, states, “it is okay to be red, but it is not okay to stay red.” The goal is for the team to work together or ask for the right level of help to “get back to green” to keep the program on track to plan.
As in the assembly line, development teams want to sense if they are ahead or behind the program schedule or in an abnormal situation as soon as possible, and not wait until a milestone point that could be weeks or months later. When they fall behind and determine that it will impact the customer or the program, the team signals for help from the right resource in a timely, simple, and effective manner. The resource provides capable people to swarm the issue to determine a short-term countermeasure to get back to the target condition, and, if appropriate, to offer support for a longer-term countermeasure to prevent the issue from reoccurring (serve to protect & serve to prevent). The resources need to have the capability to resolve the issue, thus protecting the customer. Also, as part of the help chain, they must teach and help develop the problem-solving capability of the team they’re helping.
What’s an Andon in Product and Process Development?
Environments where product development takes place do not have physical andon cords, so another mechanism is needed to signal for help once a team member senses that they are struggling? One method of signaling for help is to use a leader help chain board, whether physical or virtual. For a development program, non-urgent yet abnormal situations may be addressed by the functional “team leaders” at a set time each week, for example, during a ten-minute leader huddle at a set cadence (weekly, bi-weekly, every other day, etc.).
For genuinely urgent issues that cannot wait until the next leader huddle, the team can immediately reach out to the functional leader for help. In this sense, the team can separate common cause issues from special, urgent issues, which is vital to maintaining a synchronized workflow. The development team will also find that most of their issues can be solved within the team while only needing to pull on their leadership for lingering or difficult struggles.
Whether your work is supporting a manufacturing area, technical center, medical care, and more, the 4S characteristics — Sense, Signal, Swarm, Solve — of the help chain will keep your product or process development program moving forward. As stated in the first article, an effective PDCA problem management cycle requires awareness, agreement, and alignment on the actual problem that needs to be solved. It likewise needs capable people with the means to enact appropriate countermeasures to the important struggles and problems.
Subscribe to The Design Brief to get the latest insights in Lean Product and Process Development.
Interesting article and application to the world of product development. A challenge I’ve seen in large matrixed organizations is a reluctance to “help” because the individual knows she will fall behind on her individual tasks. I’ve seen this same behavior at a management level as leaders are reluctant to risk delays on their own projects to “swarm” another manager’s immediate problem. Thanks Matt.