What is a CDRL? It stands for Contract Data Requirements List (CDRL), but in “government-speak” a CDRL is shorthand for any contractually mandated documentation (reports, drawings, source code, etc.). Management by CDRLs has negative cultural impacts to the government Program Management Office (PMO). These negative impacts must be addressed if the government is going to “own the tech stack”.
“Oversight by CDRLs reinforces a bad habit of cubicle engineering. Cubicle engineering is where engineers are no longer building things, but spend up to 100% of their time going to meetings and reviewing / writing documents.”
This behavior impacts the PMO culture because it draws focus away from delivering value to the warfighter. The Program Office spends too much energy focusing on tracking, reviewing, and correcting CDRLs vs. focusing that same energy on creating a fast feedback loop with their end users. Instead of oversight by CDRLs, contractor interaction should be a part of the daily software development process.
That was Rise8’s COO and former Acquisition Talk guest Matt Nelson, From CDRLs to Agile Services. Read the whole thing. It has specific methods for turning CDRLs into an agile approach. Here’s an important part from the conclusion:
My next article will be about “how to create talent density at the microlevel and how to scale it to the enterprise”.
I’d like to foot stomp of the importance of building technical talent in DoD. Of course, the Air Force led the charge to neuter itself, thinking that acquisition officers can evaluate complex contracts without being practicing engineers. Here’s the wise Merton Peck and Frederic Scherer in their 1962 classic, The Weapons Acquisition Process: An Economic Analysis:
One intangible which has an exceptionally important influence on the staffing of engineering jobs deserves special mention. Many service agencies responsible for administering advanced weapons programs do little or no “in house” research, development, and production work; contracting instead with industry to have the work done. Consequently, the engineers employed by these agencies tend to become “desk engineers” whose main contact with technology is the reports submitted by contractors.
This has two major disadvantages. First, these desk engineers may lose a close feeling for the technology in their fields. Moreover, the competent and creative engineer is often dissatisfied with merely reviewing the work of others; he prefers to be in the laboratory or test center where he can participate firectly in the resolution of development and design problems.
Like the article and link