Good development leaders work in earnest to create a “safe culture” for people to share issues. Working to drive out fear, and actively communicating the need for candor and collaboration is both important and necessary. But it is not nearly sufficient for identifying and eliminating technical issues at the optimal time in a development program. Good intentions are not enough.
In addition to fostering a safe culture, your development system needs integrated mechanisms and practices that provide people with: 1) the ability to distinguish abnormal from normal conditions, 2) the ability to communicate abnormal conditions effectively and, 3) the ability to respond to these conditions consistently and effectively.
1. Distinguish Abnormal from Normal
Solving problems, mitigating risk and closing knowledge gaps are a fundamental part of development work. So much so that developers often have difficulty distinguishing normal from abnormal situations in development programs. Consequently development teams must have a method for understanding where they are relative to a performance standard. Are they where they need to be at this point in the project to have a high likelihood of success? Often the reason engineers don’t surface problems “early” is that they are not completely sure when “early” is. They have no model to compare to.
Please understand that I am not talking about the thousands of lines of requirements embedded in you project management standards. More requirements are not the answer; in fact, too much information (if they read it at all) usually detracts from a developer’s ability to distinguish critical criteria. I am talking about scalable guidelines that provide developers with acceptable risk profiles over time (i.e. what are the acceptable number of open issues at each milestone, along with corresponding severity levels), cadenced knowledge gap closure (i.e. what % completion of product design is acceptable at each gate) and a focus on synchronized solution convergence across functions (i.e. time-bound input/output requirements across Functions).
2. Effectively Communicate Abnormal Conditions
Next, you have to have a way to make abnormal conditions visible to critical participants in the development system. In lean manufacturing this is a large part of the role of “andon”. It is the flashing light, music, or green painted safe operating range that calls the team’s attention to an issue on production. Think of this step as creating a development andon system. Obeya visual management and associated “dashboard strategies” that contain the vital few indicators is one of the most powerful ways to do this as long as active management is the more important half of visual management. It’s not about decorating the walls.
However, it is not enough to make abnormal conditions visible, just like it is not enough to just detect a land mine, you have to de-fuse or avoid it. Although it seems many companies are content just to predict the explosion, you also need a robust management system that reacts and resolves issues in a timely manner. Without one, most engineers hesitate to surface problems because they have no realistic expectation that they will get the support they need. Just imagine if there was no response to andon on a production line. How long do you think people would continue to pull the cord?
3. Respond Consistently and Effectively
One crucial part of that management system response is a regular cadence of recurring events designed to respond to abnormal conditions and provide rapid support to developers. Regular status reviews for cost and timing are important, but our VP was struggling in particular with surfacing technical issues on programs. And for that a cadence of technical or design reviews is crucial. No, I am not talking about that “dog and pony show” that occurs just before a milestone. I am talking instead about a regularly occurring technical deep dive review designed to surface and resolve thorny technical issues, promote cross-functional collaboration, break up technical log jams, and grow organizational capability. The time must be sacred.
The nature of the reviews morphs over time to support the program needs and provides the pace making function to keep development moving forward. Early in the program they focus on set-based exploration of potential design solutions, later perhaps efficient design, cost target, and attribute delivery is primary, then system compatibility and finally effective response to breaking issues. But at every point in the process it is a place to surface and resolve technical issues, not berate or debate them. It is a place of candor and challenging questions. It’s a “hands-on” cross-functional event held at the gemba when possible, focused on improving both the product and the organizational capability. These events should act like “superchargers” to build momentum and confidence, align participants, and continually move programs forward.
