Did you just attend another program review meeting 15 months before launch and have an uneasy feeling about a program team that seems too comfortable missing milestones or are 20 days past start of production and are unable to meet delivery and quality requirements? For the former you are wise to invest some energy to determine if the program is still on track. For the latter, while it would’ve been great to discover this earlier, it can still be fixed. You just have the additional burden of propping up production while you go back and put all the pieces for success in place.
To assess launch readiness on a new product development program any time before start of production, start with a broad look across the program at a high level. Another way to say that is to “manage wide”. This has to be done by someone (internal or consultant) with enough experience to know how to sense danger. They should review tracking and summary tools to look for disconnects, missing execution steps or tasks performed out of sequence.
Here are a few examples of observations and analysis the troubleshooter should be doing:
To assess launch readiness on a new product development program any time before start of production, start with a broad look across the program at a high level. Another way to say that is to “manage wide”. This has to be done by someone (internal or consultant) with enough experience to know how to sense danger. They should review tracking and summary tools to look for disconnects, missing execution steps or tasks performed out of sequence.
Here are a few examples of observations and analysis the troubleshooter should be doing:
- Is the program team executing tasks out of sequence? Did they write the DFMEA before they got a signed statement of work? Did they create drawings without writing a DFMEA? Was the control plan written before, and does it inform, the operator instructions.
- Is the timeline an actual credible plan? Are lead times based on commitments from suppliers and functional groups or is the plan “the best you could do” with the time available? If supplier timing doesn’t support requirements, has expediting been sought? Have customer expectations been adjusted to match what is possible?
- When weaknesses are found, transition from managing wide to managing deep. For example: The plan will probably include a PPAP required date. So, test the validity of the ability to meet it by asking questions. Is there a bill of materials? Yes? Good. When is final PPAP? What is the component PPAP date for each component? Have all suppliers been selected? Have purchase orders been issued? Have all suppliers committed to their PPAP timing? Mastery of all of that is required. Any signs of weakness are a point of risk for the program.
- Look for red flags in the basic program tracking tools or program outputs. For example, ask if they have an open issues list. If they don’t, it’s a huge red flag. If they do, dig deeper. Which issues have to be closed to support the next big project milestone? How many issues are 30, 60, and 90+ days old? Are any of the aging issues holding up downstream activity that will affect the timeline?
"It is much less expensive to bring in a consultant for a short time to keep a project on track than it is to hire a team of consultants to pick up the pieces after a start of production for which you weren’t ready."
So, the approach is to manage wide until something suspicious is found and the switch to getting into the details by managing deep. The investigation is in no way limited to the examples given above. The approach applies to every facet of a new model development program. If there is concurrent engineering, as is often the case, the investigation can take you beyond the walls of the client to the customer or suppliers designing adjacent subsystems. The bottom line is you are looking for total commitment to parts on the floor at the expected time and quality, as opposed to tidy red/yellow/green charts.
The success of this investigation and the resultant prescribed corrective action, if any is required, is largely dependent on who runs the process.
The program team led execution to where they are today. They were influenced by management, budgets, politics and the limits of their own experience. Egos, pride, and job security being with they are, they are likely to conclude everything is fine or “I already knew about that problem”. To know and not to fix is to not know.
The PMO is often staffed with well-intended, smart people that create systems and processes for everything. With each customer and product being different, emerging technology, ever changing sourcing strategies and many other variables, no two programs are alike. So, as much as it’s attempted to automate program execution, an experienced person with focus on parts on the floor needs to know when to pivot from systems and processes to guerilla warfare to get the job done.
The best alternatives are either: a) An experienced outside consultant that can quickly assess a program, determine if they sense danger, identify the source, and prescribe a corrective action and credible plan. b) A trusted resource with the same experience and talent but from within the enterprise that is selected by the head of the organization. The relationship would allow them to prevent being blocked by politics or fear of a shoot-the-messenger response. These relationships are increasingly rare.
Given sufficient resources at the onset of a program, any of them can launch successfully. However, competing priorities, budget ‘adjustments’ to “make the quarter”, lack of experience, turning off your brain and letting the system handle execution, and countless other causes often lead to results that fall short of requirements and expectations. It is much less expensive to bring in a consultant for a short time to keep a project on track than it is to hire a team of consultants to pick up the pieces after a start of production for which you weren’t ready.
The program team led execution to where they are today. They were influenced by management, budgets, politics and the limits of their own experience. Egos, pride, and job security being with they are, they are likely to conclude everything is fine or “I already knew about that problem”. To know and not to fix is to not know.
The PMO is often staffed with well-intended, smart people that create systems and processes for everything. With each customer and product being different, emerging technology, ever changing sourcing strategies and many other variables, no two programs are alike. So, as much as it’s attempted to automate program execution, an experienced person with focus on parts on the floor needs to know when to pivot from systems and processes to guerilla warfare to get the job done.
The best alternatives are either: a) An experienced outside consultant that can quickly assess a program, determine if they sense danger, identify the source, and prescribe a corrective action and credible plan. b) A trusted resource with the same experience and talent but from within the enterprise that is selected by the head of the organization. The relationship would allow them to prevent being blocked by politics or fear of a shoot-the-messenger response. These relationships are increasingly rare.
Given sufficient resources at the onset of a program, any of them can launch successfully. However, competing priorities, budget ‘adjustments’ to “make the quarter”, lack of experience, turning off your brain and letting the system handle execution, and countless other causes often lead to results that fall short of requirements and expectations. It is much less expensive to bring in a consultant for a short time to keep a project on track than it is to hire a team of consultants to pick up the pieces after a start of production for which you weren’t ready.
RSS Feed
