Getting the right tools, methods and best practices designed into your project schedule is essential for communicating what to do and when to do it. This is an efficient way to build just the right amount and type of knowledge needed to meet your specific project requirements. Every project's Design Control allocation is different, so this type of planning must be carefully done on a project-by-project basis.

The Five Design Controls

A Design Concept it is usually transformed from a sketch to a computer file by way of laying the concept's physical geometry out using a CAD system. In parallel with that Form-Fit model, the development team develops functional models and initiates simulation using CAE systems using, for example, Pro-E, MathCAD and similar software tools. So the front end of C/KPD&M work is heavily dependent on computer models. CAE and CAD iterations lead to readiness for building necessary variations of prototypes. Prototypes are often expensive but are needed to obtain additional learning that computer-aided development tasks cannot produce.

The physical prototypes enable the last three Design Controls. The third Design Control of Characterization uses simple curve-fitting for basic Y = f(x) relationships that are totally new to the development team. Characterization (regression analysis) is common prior to formal DOE for brand-new materials and configurations that have not been integrated in the past. These are built using linear or non-linear regression as prototypes are operated over a range of values for one or two Xs, as one or more Ys are measured for their corresponding changes.

When there are two or more Xs that possess potential or unknown interactivity between them, the empirical modeling approach expands to include the fourth Design Control - Designed Experiments (aka DOE). There are many DOE structures for screening, modeling, optimization, integration and tolerance balancing activities so that main effects, interactions, sensitivities and robustness behaviors between the Ys and their controlling Xs can be well-understood.

The fifth Best Practice - Testing -- is often used prematurely by development teams. The mis-use is common due to an old, bad habit of modeling with CAE and CAD and then immediately building a prototype that is "tested" to see if it passes requirements. If the prototype passes one or more of these "tests", the team hands the design over to production. The claim is "we are fast... we hammer out a design, build it, test it, do a round or two of fixes to pass our final tests, then move on to the next project." Unfortunately, the next project is often another turn of the development crank (design scrap and re-work) after the original design that passed the tests is found to be plagued with reliability and produceability problems. This approach will also likely cost way more than originally projected once it has been made to finally work under all the real conditions not fully covered in the "tests". Testing is good and necessary but only after you've done your homework, passed a few quizzes and thoroughly mastered the lessons.

C/KPD&M - It's About Knowledge and Learning

The 12 Steps of C/KPD&M progressively prepare the product to pass tests. The Project Manager and the development team must keep track of the actual Knowledge-in-Hand in relation to the required Knowledge-in-Hand to illustrate this progress. Progressive learning is one of the major goals of a development project. Testing will come soon enough, but we need to do our learning first. During our school days, those years of homework, reading assignments, writing of papers and solving equations were not for torture purposes! They were meant to build good developmental habits.

I read an article recently about "progressive" business leaders who think it's a good strategy to rush a product to market and then fix it. Sorry, but I just don't believe this is right either on an ethical basis or as a way to develop knowledge. It is better to be smart than lucky in the long run.