How the Clinger Cohen Act can accelerate your digital transformation.

7 min readNov 13, 2020

In 1989, Kodak contracted with IBM to outsource its IT operations, creating the IT outsourcing industry. Kodak’s IT outsourcing proved disastrous. With a 10-year, $250 Million contract, Kodak was anchored to a single company; significantly impacting their ability to be responsive to market changes¹.

IT outsourcing does not work. Private industry primarily abandoned full-scale IT outsourcing in by the early 2000s, but the government did not. By 2002, 46% of the software systems developed across $37 billion worth of DoD spending failed to meet real needs, even though they met written contractual specification².

In 2020, successful companies own their technical baseline. Google owns Google Cloud Platform, G-Drive; Amazon owns AWS, S3, EC2, and Lambda. In fact, Amazon Web Service was originally built to solve an internal Amazon problem of a tightly coupled, hard to change system architecture. From 2003 -2006, Amazon decoupled its internal services into an API-first, modular architecture³. But it's important to note, the AWS transformation took 3-years and they started with internal IT teams.

The government’s digital transformation journey is starting from a deeper deficit when compared to Google and Amazon.

First, the majority of core capabilities within the DoD (e.g. air, land sea, space, and cyberspace superiority, intelligence, surveillance, reconnaissance (ISR), rapid global mobility, global strike, and command and control) have been outsourced to large defense contractors. This makes it extremely difficult to influence rapid change to the current business model, let alone the architecture baseline.

Second, the acquisition community views laws written to help digital transformations, like the Clinger Cohen Act, as bureaucratic red tape.

Most people view the Clinger Cohen Act as acquisition queep.

Acquisition queep is the annoying, time-wasting, and sometimes unnecessary duties associated with operating within the bureaucratic DoD acquisition process.

The Clinger Cohen Act was labeled as acquisition queep because it's a statutory requirement (meaning its mandated by law). Compliance often gets bolted-on at the back end of an acquisition strategy, and it significantly conflicts with the current IT outsourcing model within the DoD.

If the Clinger Cohen Act was viewed as a tool to enable digital transformations, you could use a statutory law to defend your transformation.

Below are the Top 4 digital transformation plays that can come from Clinger-Cohen Act implementation.

Play #1: Conduct a build vs. buy analysis

Associated CCA mandates⁴:
1. Conduct an analysis of alternatives (AoA)
2. Redesign the processes the system supports to reduce costs, improve effectiveness and maximize the use of commercial off-the-shelf technology.
3. Determine that no private sector or government source can better support the function.
4. Conduct an Economic Analysis that includes a calculation of the return on investment.

Digital transformation method to comply with CCA. Typically an AoA is not viewed as an important component within a digital strategy; however, an AoA is mandated by CCA for a good reason. The act of performing an AoA makes you defend your initial investment assumptions and prove your results with data and critical thinking.

Unfortunately, the DoD tends to contract the completion of AoA reports out to an FFRDC or an A&AS support contractor, missing the value insights gained during the AoA process.

Official AoAs are costly and take too long to complete. The reason these AoAs take so long is that they are surrounded by acquisition queep; hundreds of pages of policy, instructions, and guidance. For example, the Air Force has 188 pages tied to cost analysis guidance alone.⁵

Government personnel within the program office should perform a light-weight build / buy analysis that meets the intent of the CCA.

The best starting point for your build / buy analysis is to breakdown your technology stack into separate components to be analyzed.

All of the segments of the tech stack should should analyzed against building the services/capabilities yourself, maintaining the status quo of outsourcing the IT baseline, or GOTS / COTS alternatives.

After you’ve determined what alternatives exist for your tech stack, you need to consider what options you have within the commercial and organic DoD space to support your transformation. Additionally, an AoA should evaluate compliance with the DoD Enterprise DevSecOps Reference Design⁶ and evaluate the elements of the DoD Enterprise DevSecOps Services⁷. Below is a suggested outline for a lightweight build / buy analysis.

Play #2: Simplify your ISP approach

Associated CCA Mandates⁴
1. Make a determination that the acquisition supports core, priority functions of the DoD.
2. Register Mission-Critical and Mission-Essential systems with the DoD CIO.
3. Ensure that the program has a Cybersecurity Strategy that is consistent with DoD policies, standards and architectures, to include relevant standards.
4. Ensure that the acquisition is consistent with the DoD Information Enterprise policies and architecture, to include relevant standards.

Digital transformation method to comply with CCA. The Clinger Cohen Act applies to all IT systems that support a core mission function within the DoD. Additionally, the CCA requires you to determine if your system is mission essential / mission critical. Don’t overthink this analysis, if your software directly contributes to mission success then its most likely falls into this category.

If your system falls into these categories the CCA enforces you to document your systems dependencies and interface requirements in sufficient detail to enable testing and verification.

Most organizations try to satisfy this requirement by writing a static and cumbersome document called the Information Support Plan…just like an AoA, ISPs are costly and take too long to complete.

Instead of writing a static ISP, organizations should examine the mission their software supports. This can be accomplished by building data models and architecture diagrams centered around war-fighting mission threads. A key enabler to developing your data model and architecture quickly is building them together with your entire team: end-users, system engineers, software developers, data engineers, and legacy system experts. This can be accomplished through event storming and domain driven design.

Additionally, instead of forcing organizations to write about how well they will protect mission critical information, we should ask them to prove it through successfully passing a common CI/CD pipeline and pushing the results into a common repo, the DoD Centralized Artifacts Repository (aka Iron Bank) is a great example of this practice⁸.

Play #3: Use growth boards and a cascading goaling system for program governance.

Associated CCA Mandates⁴
1. Establish outcome-based performance measures linked to strategic goals.
2. Develop clearly established measures and accountability for program progress.

Digital transformation method to comply with CCA. Most modern software enterprises leverage a highly aligned, loosely coupled architecture. Additionally, most modern software is built and delivered in increments. However, most oversight methods do not account for of these new processes and they still rely on the waterfall approach of “adherence to a plan” to drive alignment and accountability.

There is better way: a cascading goal system (i.e Objective and Key Results (OKRs) or Objectives, goals, strategies and measures (OGSMs)). Using these systems, detailed plans are replaced with objectives centered around achieving warfighter outcomes. Teams are empowered to develop technical roadmaps to meet those objectives. To ensure the system is well architected, guardrails and non-functional requirements compliance should should be automated as much as possible inside your CI/CD pipeline to ensure cybersecurity, integration, and operations resiliency is being continuously assessed.

After OKRs are established, a governance structure to measure progress at the team, portfolio, and enterprise level should be established. Doing this, the one size fits all PMR is replaced with a series of Growth Boards.

Growth Boards reinforce alignment at all levels within the organization by:

Teams and Leadership have a clear shared understanding of what success looks like
Cross-functional support becomes a reality, ensuring blockers to progress being removed more efficiently
Ability to change direction sooner and more objectively on the basis of agreed-upon metrics, enabling all to celebrate such changes and radiate learnings across the organization

Play #4: Deliver modular contracts frequently

Associated CCA Mandates⁴
1. Ensure modular contracting has been used to the maximum extent possible

Digital transformation method to comply with CCA. Clinger Cohen Act introduced FAR 39.103, which states,

Modular contracting is intended to reduce program risk and to incentivize contractor performance while meeting the Government’s need for timely access to rapidly changing technology architecture, agencies should, to the maximum extent practicable, use modular contracting to acquire major systems.

Program offices should using modular contracting and divide their contracts into several smaller acquisition increments that:

Are easier to manage individually than would be possible in one comprehensive acquisition
Address complex information technology objectives incrementally in order to enhance the likelihood of achieving workable systems or solutions
Provide for delivery, implementation, and testing of workable systems or solutions in discrete increments, each of which comprises a system or solution that is not dependent on any subsequent increment in order to perform its principal functions.

If your organization needs help getting its digital transformation off the ground, Rise8 can help. We have a dedicated group of engineers and change agents to co-innovate with you. mnelson@rise8.us

How the Clinger Cohen Act can accelerate your digital transformation.

Play #1: Conduct a build vs. buy analysis

Play #2: Simplify your ISP approach

Play #3: Use growth boards and a cascading goaling system for program governance.

Play #4: Deliver modular contracts frequently

Written by Matt Nelson

No responses yet