Every time we develop a new technology or design a new product we have an obligation to document our work in a design guide. We do this so that anyone with technical competence can read the summary of how the design came to be, how it was designed to work under both nominal and stressful conditions and how to manage it once it has been completed and handed off to those who will manage its life-cycle. There are many reasons we should generate a design guide. Below is a list of elements found in a reasonable design guide, in no particular order, along with the team members who should be responsible for each:

Objective Learning: An account of how and what the development team learned from one major task/deliverable set to the next across the phases of the development process. This provides a sense of how the orderly execution of selected, specific patterns of tasks and tools produced results that enabled major Design Reviews and formal Gate Reviews to be successfully passed. Person responsible: Project Manager.

Learning Rates: A guide to how long learning took for specific task/tool combinations so future teams have a sense of how long things are likely to take for similar types of tasks and tool applications. This can be a great help in conducting Monte Carlo simulations on project schedules for new projects. Person responsible: Project Manager.

Critical/Key Parameter Data base: A list of the candidate Critical/Key Parameters that were successfully converted from NUD (New, Unique or Difficult) status to ECO (Easy, Common and Old) status illustrates how risk was lowered using the methods and tools of Critical/Key Parameter Development & Management. We also must document which candidate Critical/Key Parameters actually became proven Critical/Key Parameters because they failed to fulfill one or more of the requirements established by The Big 7 Metrics for Critical/Key status. The Big 7 are 1) Measurability, 2) Stability, 3) Adjustability, 4) Independence/Interactivity of controllable engineering control parameters that possess Statistical Significance, 5) Sensitivity, 6) Robustness and 7) Capability. These proven Critical/Key Parameters should be few in number and represent the vast majority of ongoing risk that is present in the design after it has been optimized during development. Person(s) responsible: Lead System Engineer or Lead Technical Engineer for the project.

Principles of How the Design Works: A complete set of System, Subsystem and subassembly level Functions, Functional Flow Diagrams, Interface Diagrams, Parameter Diagrams, and Noise Diagrams along with all major math models (both analytically and empirically derived) must be documented. This enables down-stream life-cycle management teams to understand how the design works as an integrated system, as well as across its interfaces and down through its sub-level designs. This is the basis of how the design follows the laws of physics and how this design is specifically represented in engineering terms and units of measure. Person(s) responsible: Lead System Engineer or Lead Technical Engineer for the project, and the engineers responsible for the math models for the subsystem or subassembly to which the models pertain.

Lessons Learned: An account of situations that impeded the progress or usefulness of the work. Lessons Learned can be consulted to prevent future teams from making the same mistakes or going down the wrong path that we encountered. The root causes of "design scrap and re-work" are documented so we know how to prevent them on future projects. It is also helpful to include the final Design Failure Modes and Effects Analysis Document (DFMEA) so people can see what risks were present and mitigated through application of specific "design controls". These might include analytical modeling and simulation, graphical and spatial modeling and tolerance balancing using CAD, empirical characterization of NUD functional relationships using Regression Analysis, various forms of Designed Experiments, and final tests that assure that the performance meets requirements. Persons responsible: Project Manager with the help of the Lead Systems Engineer and the Technical Team Leaders on the project.

Documenting a design guide is not trivial. Unfortunately it is rare to see a series of tasks proactively designed into a project schedule to allow for the time to do this important part of technology or product development. It takes some work almost every week in the development process to assure the data, the models, learning and summarization is clear and well-ordered so that it is easily followed by those who are going to need this kind of traceability and interrelated facts as the design is transferred to its new owners.

My recommendation is to think through the elements of value within a design guide. Create a list of all those who are likely to benefit from this kind of information as you hand new technologies to your down-stream peers in product development or from product development to those in production and ongoing life-cycle management. I know from experience the difficulty and waste associated with the lack of this kind of information. The people who subsequently become responsible for the technology or design or product will be extremely grateful for the effort you put into the design guide. Most likely, at some point in your career, you could be the beneficiary of that effort made by someone else!