If I were to go into any product design organization and ask what their execution challenges are, they would likely have several items to share. That does not indicate that they are executing poorly, only that there is room for improvement. This is a continuous improvement world and everyone should always have a few items in their hip pocket that they would like to see done better. A larger concern should exist about items that are not obvious issues, they are not in anyone's hip pocket, and they are steeling away precious development time without any fanfare. Finding these buried sources of execution roadblocks is done through a "Discovery Process."

When embarking on a discovery process do not let any preconceived notions about where issues may be cloud your detective skills. Keep the focus broad, cover multiple areas and multiple engineering disciplines. When trying to uncover development execution challenges do not only dig around in the designer's domain. Probe around in test, product engineering, marketing, and applications. Many "unknown" issues have their roots in the exchange of information between design and their partner organizations. You will likely find multiple cases where someone is not receiving information that would improve their contribution and efficiency back to the project.

Through a quality discovery process the list of execution challenges will increase over time. You are creating awareness of issues that would not normally be identified, and that's a good step towards improvement. As part of each projects closure it would be beneficial to include some formal discovery work, allowing finely tuned continuous improvement thinking.

Diving into solution, without spending quality time in discovery, will provide limited improvements to product development execution. Having completed a discovery process there is a plentiful list of execution challenges that are either real, perceived or somewhere in the middle. The initial step in solution is to decide which of the challenges should be addressed first. Use caution if paring down the list on your own. This is especially true if you do not have a thorough understanding of the challenges and their impact to execution. You may end up dropping real issues that you spent precious time working to uncover. It may be wise to consider a large group discussion with an objective of prioritizing and paring down the challenges list.

With the list of challenges in hand, head back to the product development teams to generate potential solutions. The execution team will willingly provide valuable input for solutions, assuming an environment conducive to open discussion. Informal one on one discussion is an excellent producer of potential solutions. Another solution generator is a formal brainstorming session with the product development team. As with the discovery phase, be sure you use a variety sources as inputs to prospective solutions. Cover all the product development disciplines and keep an open mind.

Once you have the potential solutions identified; a discussion session with design, product, test, applications and marketing representation is necessary to finalize solutions and create solution acceptance. Keep the team focused on solution finalization and off of fault finding. You must leave the discussion with buy-in for each solution or the implementation will not materialize. Modify, or create your design process documentation with the agreed solutions and release.

Every project will have multiple spec change requests that come into play during design execution. I have been using the phrase "Feature Creep" to describe this inevitable process. Feature Creep is a reality that can either be accepted and ignored or accepted and managed. The former will leave you wondering why the schedule has slipped away, with no obvious reason. If changes are not managed, the design team is being quietly diverted to go off on feasibility studies, or worse, implementing changes that have not been agreed to by the business.

You must have a process in place for dealing with Feature Creep that manages the decisions about diverting resources for feasibility studies, addressing formal schedule changes, project costs and ASP changes, resource loading etc. This process must also manage the interface between marketing and your design team leader to prevent potential changes from quietly becoming a design team expectation. I am not advocating a change adverse culture. However, you must be operating in a change aware culture or costs, schedule, and risk creep away from you.

If you have any specific questions that you would like to see answered here please send me an email and I will address them here anonymously, unless you indicate differently.

email: jeff@jorvigconsulting.com

phone: 480-895-0478

web: http://jorvigconsulting.com