Volume 3, No. 3
“Helping You Accelerate Your High-Tech Development Projects”
Welcome to the ANGOTTI PRODUCT DEVELOPMENT e-mail newsletter!
The goal of this newsletter is to help you accelerate your development projects by sharing some of the many tips, techniques and strategies we’ve honed during two decades of providing high-tech consulting services.
This issue discusses another significant issue in getting new, high tech projects to market on time — taking into account the almost inevitable project slips at Debug and Test.
THE TEST AND DEBUG SCENARIO
It is nearing the end of a product development cycle; the time has come to integrate all of the work done by several engineers and software programmers into the first example of the final piece of hardware. The work is progressing, with the market introduction plan in place or with the venture capitalists awaiting this milestone to advance funding to the company. The project at this phase often incurs significant slips, sometimes for weeks or months. The team and management are working hard and with long hours to complete this phase. This takes its toll on everyone.
WHERE THE CHICKENS FINALLY COME HOME TO ROOST
Debug and test is where all of the problems that have been “swept under the table”, or that were not uncovered with the earlier Risk Management Plan, are finally uncovered (those dreaded unknown, unknowns). Often there is only one model of the final hardware,and there are various teams that need access to it. This creates a “funnel effect” on the schedule. This funnel is large at the entrance, and very small at the exit. This can create significant schedule “stretch out”.
Another significant concern is that it is often difficult to perform tasks in parallel, unless parallel tasking has been well planned earlier. This can lead to lots of chaos and additional significant schedule slips, with the attendant frayed nerves that accompany them.
END OF PROJECT RISK
The slips involved at the project “end game” are created by the risks that are inherent in any high tech new product development. The effects of these can be mitigated with earlier emphasis on a risk management plan. It is here that methods can be developed to ascertain these risks and do something about them in advance.
MOTIVATION TO FOCUS ON RISKS
It is valuable at this time to have a real, believable, understanding of the economic impact of delayed time-to-market at the debug and test phase. This could provide justification for two critical, and often overlooked, areas of focus at this time:
1) Decisions to add more resources to solve specific challenges at this critical time.
2) The strong need for a risk plan.
SOME PRACTICAL IDEAS THAT WILL HELP
Here are some practical ideas that can be helpful:
1) Risk management Plan
Of all of the times that Risk Management plans would be helpful, the chaos of this part of the development project creates the greatest requirement for a risk management plan. The risk plan should be kept small, and updated frequently during this phase. Often, risk management is done on an “ad hoc” basis during this phase. Instead, here is where discipline can really pay off. (See our earlier newsletter, “Use of Risk Management Can Help Make Projects Work“.
2) Plan the Debug and Test
Many projects have very little detail in the Debug and Test Portion of the project plan. As debug and test approach, create this plan detail. This will allow scheduling of activities with the available resources. Often this is overlooked in the haste to “get going” and “get things done”. Be sure to enroll the entire debug team in this process. This can really be a team motivator. (See our previous newsletters on this subject at Tech Resources )
A good approach to creating this plan is to keep asking the question, what can the team members do in parallel during this period? This can at least help the team to act to minimize the impact of newly determined tasks during this phase.
3) Create Alternate Approaches for Risky Elements
If possible, alternate assemblies or circuits can be created and made available in case the higher risk ones fail to work correctly. Sometimes “Black Box” simulators can be created to fill in for elements that are not working as yet.
4) System Level Redundancy
Minimize the “funnel effect” by creating more than one final system, if possible for debug and test. This is relatively easy with software portions of a project. It is much more difficult with larger systems or ones that are complex.
5) Breadboard Risky Elements Early On
To the greatest extent possible, model, or create breadboards of critical portions of the system beforehand. Today, a number of
powerful software modeling approaches are available. They are never as effective as something closer to the “real thing”. Rarely are they 100% accurate substitutes for real system elements, but they can give significant insight into potential problem areas. A concern is that these tools are often new and untested themselves, thereby creating additional problems of their own.
6) Plan for Product Introduction Risks
Another approach, if practical, is to plan market introductions with some lag time compared to schedule. It is rare that a company’s
management will do this. On the other hand, they will often delay product introduction caused by such delays. It can be very helpful to have this as part of the risk management plan.
DISCIPLINE CARRIES THE DAY AT DEBUG AND TEST
For debug and test, formal discipline in the areas of risk management and planning can make for a much easier, predictable and controllable completion of initial product development. This is not the time to abandon them, but to embrace them.