I agree with the premise laid out here and with wide-ranging discussion around your March 18th post. I would caution, however, that there are pitfalls in trying to scale technology pilots to enterprise-level apps.
We all know IT programs that have failed or “failed” under the weight of acquisition rules and oversight. Lots of formal process controlling virtually every program function but after years of work and tens or hundreds of millions spent, deliver nothing that is militarily useful.
The technology pilot or prototype approach is often viewed as an appealing alternative. An operational prototype can be built quickly (and by comparison, cheaply). Domain (warfighter) expertise is usually available to guide the developers who are, in turn, responsive to immediate user needs. The pilot/prototype gains a user audience and warfighter (CoCOM) support because it provides direct military utility; the user comes to depend on the prototype and “advertises” its usefulness to domain peers.
As usage expands, however, the pilot/prototype does not/cannot scale to accommodate demand. It frequently suffers from all the ills of a prototype: no (or poor) overall architecture, constraining design, little discipline or structure in code development, proprietary key components, growth like topsy in response to near real time user requests, insufficient documentation, etc. It’s not net-centric, doesn’t and can’t comply with DOD data or services strategies, doesn’t/can’t follow CJCSI 6212.01E, and so on.
What is needed is a middle ground that takes advantage of the speed and operational user involvement of prototyping and piloting, but with some measure of engineering rigor and discipline of a formal program (PoR). Appropriate oversight needs to be provided but not be so burdensome that little actual work can get accomplished. This would be different from the current JCTD process in that (planning for) migration to a PoR would not be a mandatory requirement.
IT acquisition reform needs to be accompanied by engineering reform.