Archive for October 7th, 2010

New & Improved

SELC Appendix BToday’s post is a reminder of what many of you already know: DHS APMD published an update to Appendix B of the SELC Guide. That appendix is the policy at the heart of how we implement Acquisition Directive 102-01.

Some of the language in it is different from earlier drafts I’d shared. As I told with some of you earlier today, I think the descriptions of technology demonstrators may be of particular relevance to us.

From page 169-171

B5.6 Technology Demonstrations

B5.6.1 Definition

A Technology Demonstrator is defined as a working model (physical, electronic, digital, analytical, etc) or a process-related system that may be used in either a laboratory, simulated, testing, controlled operationally relevant environment, or operational environment, depending on the type and purpose for its’ [sic] use.


Type 1 Technology Demonstrators are used as part of a Program in support of the Analyze/Select phase for the purpose of evaluating technology or process maturity, refining requirements (including Concept of Operations), or producing data in support of analyses of alternatives. Type 1 demonstrations are conducted in simulated or controlled operationally relevant environments. The scope of the technology demonstrator must be within the scope of the program’s Mission Need Statement. The scope and plan for Type 1 technology demonstrators is part of the CDP approval at ADE-1.

Type 2 Technology Demonstrators are used as part of a Program to refine or verify requirements and/or designs throughout the Obtain phase. Type 2 demonstrations are typically conducted in simulated or laboratory (non-operational) environments, but may be conducted in controlled operationally relevant environments to obtain operational/user feedback. Type 2 demonstrations may be part of a program’s contractor or Developmental Test (DT) effort. The scope of a Type 2 Demonstrator must be within the scope of the MNS/ORD, with objectives included in the APB. If part of a Developmental Test effort, the Type 2 Demonstrator objectives must be documented in the TEMP and Developmental Test Plans before evaluation. The scope and plan for Type 2 technology demonstrators is part of the APB approval at ADE-2A.

B5.6.2 Benefits
In many traditional system development methodologies, prototypes were not used, were not available during development, and/or were maintained only long enough to establish technical feasibility. It is now recognized that technology demonstrations can provide a variety of benefits throughout the systems development life cycle, rather than at a single time for a single purpose. Technology demonstrations are an effective technique used in product design and evaluation to accomplish the following:

  • Discover physical principles of a product
  • Assess and/or confirm product feasibility, requirements, performance, and/or
  • features
  • Mitigate project and program risks
  • Evaluate technical integration feasibility or alternative solutions
  • Elicit user feedback and refine requirements

Technology demonstrations are considered a best practice in commercial software development, especially as it applies to the design of user interfaces and complex systems.
B5.6.3 Considerations

Technology demonstrations provide increased value in the use of evolutionary/Spiral development methodologies, such as Rapid Application Development (RAD), Agile Development, and Extreme Programming.

All major DHS IT development projects should use technology demonstrations to facilitate requirements analysis and technical feasibility.

All major DHS IT development projects should continue to leverage the prototype as part of the initial build or baseline capability, where feasible.

Privacy compliance requirements do not distinguish between pilot and prototype and instead look purely at the data and data usage; consequently, privacy requirements must be met for both.

I’m not saying there’s definitely a tech demonstration in our future.  But as I wrote in last post, everyone wants us to find a way to deliver capability more quickly. Keep looking for ways to make the major system acquisition process work more quickly.