This presentation was given at the Lean Software and Systems Conference 2012 (LSSC12).
Working closely with end users can help ensure complex systems meet not just the contractual specification but also operators’ and other stakeholders’ evolving needs in realistic operational environments. Gaining users’ strong support is crucial to maintaining funding for projects and programs in austere budget environment. But working with users is often difficult to arrange and fraught with challenges: They often disagree among themselves and change their opinions frequently. And which users should we contact and whose inputs should we consider? Users don’t speak engineering and engineers seldom speak “ops” so how can we have a meaningful conversation with them anyway? DOD contracts seldom contain any provisions for contacting or visiting with end users, nor does the USG want to pay for such discussions, so how can we arrange discussions with end users? Since there is no substitute for detailed operational discussions with end users of complex systems, an effective, efficient, reliable method must be found by systems engineers and project managers for the regular, methodical engagement of hands-on users of the systems we design and build. This presentation describes the Technical Concept of Operations (TechCONOPS) as the primary document for tying together users, buyers and designers. Then the briefer discusses the four most common user groups, when to involve each and what kinds of information we can typically get from them. This is followed by a brief discussion of how a robust TechCONOPS can drive modeling and simulation. Lastly the other two key communities (technologists and threat/intel specialists) are discussed in the context of their crucial contributions during regular revisits/updates to the CONOPS. Finally, several real-world examples of failed developmental systems (division air defense artillery system, UAV, imagery analysis software, others) illustrate common pitfalls of not building CONOPS and not involving hands-on end users early enough or often enough in system design and test.