no man can efficiently direct work about which he knows nothingand we can rediscover it nearly a century later,
--Col Thurman H. Bane
Pre-Milestone A and Early-Phase Systems Engineering: A Retrospective Review and Benefits for Future Air Force AcquisitionItem 19 of the checklist stresses the importance of placing experienced, domain-knowledgeable managers in key program positions. The committee has observed that many of the truly extraordinary development programs of the past, such as Apollo, the Manhattan Project, the early imaging satellite programs, the U-2, the fleet ballistic missile system, and nuclear submarines, were managed by relatively small (and often immature) agencies with few established processes and controls. In that environment, dedicated managers driven by urgent missions accomplished feats that often seem incredible today.
The committee believes that the accumulation of processes and controls over the years—well meant, of course—has stifled domain-based judgment that is necessary for timely success. Formal SE processes should be tailored to the application. But they cannot replace domain expertise. In connection with item 19, the committee recommends that the Air Force place great emphasis on putting seasoned, domain-knowledgeable personnel in key positions—particularly the program manager, the chief system engineer, and the person in charge of “requirements”—and then empower them to tailor standardized processes and procedures as they feel is necessary.
[...]
While the systems engineering process is, broadly, reusable, it depends on having domain experts who are aware of what has gone wrong (and right) in the past recognize the potential to repeat the successes under new circumstances and avoid repeating the errors.
When I read that last part it reminded me of something Herbert Mason said at a talk he gave recently at the NMUSAF: "History makes you smart, heritage makes you proud."
yep. No question about it.
ReplyDeleteFor all successful projects / organizations that I have worked with this is one of the most notable characteristics. Others being (1) direct communication among the members of the working groups and between groups ( bull sessions we used to call them, Beer Friday, weekend parties, long lunches outside the office cubicle maze ), (2) extensive detailed documentation, and (3) that information easily accessible to all group members. Self-powered / self-starters smaller groups are an excellent way to get the balls rolling on new stuff. Weekly / monthly reports fed only upstream to "management" and there stuffed into a file cabinet are useless.
I worked for one organization that had established a group the sole purpose of which was to supply "Project Managers" to other groups. The hypothesis was that a generic Project Manager could successfully Project Manage anything. What a joke.
Projects working on physical phenomena and processes that are coupled in the physical domain require coupling in the models, methods, software domains, and within each of these domains domain gurus for each aspect.
Domain expertise rules.