“Swanson’s Unwritten Rules of Management” is a pocket guide containing 33 basic principals of management written by Bill Swanson, CEO of Raytheon. The hardcopy of the guide is available “free” from Raytheon and can be ordered from their website at http://www.raytheon.com/feature/ceo_handbook. Several of the 33 principals are reviewed in a PDF summary of the handbook on this site at the same location. As I went through this summary several principals drew my attention for to their applicability to the engineering world. I have identified three of these below and commented on how they apply to our engineering world.

“Look for what is missing. Many know how to improve what’s there; few can see what isn’t there.” This is a beauty! How often do we really take the time to step back and probe around to seek what we don’t know? If we are immersed in fixing something in a design, or procedure or process it is fairly simple to fall into a mode where we think we understand what’s broken and go about fixing it. A phrase that I came across several years ago sums this up nicely for me. “Those that know, know they know but those that don’t know, don’t know they don’t know.” We must strive to know what we don’t know.

“Learn to say, “I don’t know”. If used when appropriate, it will be used often.” I view this is a supporting principal on to the previous one. Saying “I don’t know” implies not being dialed-in, when in reality it means there is something to be learned that is currently unknown. If we go about giving an impression that we know everything we need to know, then we have denied ourselves the benefit of finding “what isn’t there” and the associated learning’s. In today’s business climate, there is no room for complacency. We must have a vision that we can always be better or we will stagnate. An action plan must be defined to support that vision, or it is only a wish.

“When facing issues or problems that are becoming drawn out, short them to ground.” If we spend too much time on theorizing about how we are going to improve, we never get anything done and spend costly time talking about it. We need to get from problem to solution in the quickest possible fashion, and that solution will only happen from specific action. If we truly want to find solutions, they will be found in the people dealing with the problem every day. Talk to them, involve them, and ask them for solutions. Rarely does anything get fixed when the solution comes from outside the circle; it is frequently only a band-aid solution.

You have decided that there is an area of your product design process that you would like to improve upon. It’s time to build the team and you want to keep it economical, maybe even under the budget radar screen. Resource availability, cost, skills, and team leadership perception all must be identified and addressed for success. I have detailed these attributes below to provide some food for thought as you consider defining your process improvement team.

Resource Availability – This one is obvious but has some subtle aspects to it. If you’re working towards an improvement goal, the bare minimum requirement is a leader dedicated to the execution of the goals. Many times there is a leader in this role, although committing to it being a dedicated role is where challenges exist. If you have an effort that is taking longer than expected, nor producing the desired results it may be time to “short it to ground” by seriously looking at the depth of dedicated resources. If you are unable to commit dedicated leadership resources it may be time to look for outside support, or your improvement effort may be doomed to escalating cost with limited benefit. to see addressed in a best practices document include version control, design kit and version, team meeting expectations, simulation matrix expectations, valid reference libraries etc.

Cost – This one can be elusive. A first order view is that the price of a process improvement effort is the cost of resources assigned to the task. What about the price for not having the improvement in place in a timely manner? The true cost is best identified by adding the incremental cost of the improvement effort (resource cost) to the revenue loss associated with each day the improvement is not in place. In most cases you will find the incremental costs to be small relative to the revenue loss associated with the delayed implementation of a well-defined process improvement for your design team. The revenue loss figure is always directly proportional to the ability to commit a dedicated team. Skimping on incremental costs usually leads to a much larger, behind the scenes revenue loss.

Skills – The number one skill that must be addressed is having someone with excellent detective abilities lead the effort. Someone who has the ability to “see what is missing” is critical to ensure that your not simply improving upon what’s “already known”. Your process improvement must include the research necessary to see where the challenges are and propose possible remedies. You cannot assume everything is already known or the positive results will not be maximized. The leadership skill you choose must be able to drive the detective, “out of the box” thinking strategy. If you don’t posses this skill within your organization you must find it outside your organization. Don’t skimp on this key skill. Keep in mind that the incremental cost is probably much smaller than the revenue loss associated with a delayed or ineffective implementation of a needed improvement.

Leadership Perception – The team must view the leader of an improvement effort as an individual with the proper vision, implementation skills, listening abilities, credibility, commitment and the ability to say “I don’t know”. Without these attributes readily displayed to the rest of the team, a leader has a tough sell ahead of him or her. The design team is certain there are a many reasons that the improvement effort is going to fall short of it’s goal and they will be looking under all the rocks to find them. Not because they want the effort to fail, but because they are naturally reluctant to change. Change affects the way people do things and most are content with doing them today just like they did them yesterday. The leader must be able to walk through the negativity, carry the flag high and instill a sense of enthusiasm with the rest of the team.

The design tools and the design flow that glues them together are only a piece of the pie when it comes to managing a design. If they were the sole focus in managing the daily activities for the design team I would anticipate an unpredictable nature in their ability to meet milestones. It is equally essential that the communication dynamics of the team be managed to the same level of detail as the tools and flow.

This is best accomplished through the development and refinement of your design process. Included in a design process are items such as the design flow, change management, engineering documentation, design reviews, IP sharing strategies etc. The diagram above provides a good representation of the items that make up a thorough design process. Please click on the image for a larger view. The integration of all of these items into a well-defined workflow produces the design process for your organization.

It will take some work to develop the process along with the supporting documents and templates. Is it worth it? As discussed in the previous section about implementing a process improvement, cost includes the revenue loss associated with a delayed improvement. What is the value to your particular situation if you could remove a spin and/or pull in the schedule to production release on all future products? What is the value of having predictable execution for your design projects? Just some food for thought as you consider costs associated with improving.