Why a WW2 contracting practice is the best way to build a federal cloud
Current contracting methods fall short when it comes to procuring something as large and complex as a federal cloud but a method used during World War II might just be the answer.
The Joint Enterprise Defense Infrastructure (JEDI) contract is a mammoth Defense Department cloud contract valued at $10 billion. JEDI is probably the largest example of how the federal government is going about cloud, cloud adoption, and emerging technology all wrong.
Realistically, the federal government does not have the critical technical and business expertise to manage and operate a federal cloud, nor do the standard FAR-based acquisition rules support acquisition of this type of technology. We need to adopt a management and operating contract model if we want to modernize the federal government in the most expedient, cost effective way possible without sacrificing quality.
What is the M&O Model?
The M&O contract was pioneered by the Department of Energy. The model dates back to World War II and the Corps of Engineers’ Manhattan Engineer District. It was designed to ensure the recruitment of world-leading scientific and technical talent, and the successful completion of the mission at hand—to win the war. This is how the atomic bomb was developed. The bomb was not built by the government. It was built by industry and academia under project management of the Army Corps of Engineers. We need to treat cloud adoption the same way.
How Would a M&O Model be Executed?
The idea behind an M&O contract is simple – it is essentially a government-owned, contractor operated (GOCO) model with the following characteristics:
- The contractor would assume technical and business responsibilities under a broad statement of work with a requirement that is continuing with no foreseeable end.
- The contractor would be responsible for integration of technical, business, and infrastructure functions and would perform the technical, business, and integration functions with its own workforce which would remain on site despite changes in contract.
- Every M&O contract for this work would operate like a joint venture and the JV is sold to the winner of the following contract which are typically multi-decade awards.
- The contractor’s entity or JV may only perform work for the federal government and may only accept work from the federal government.
- The federal government oversees the security, health, and safety of the contractor’s site(s) which would function essentially as large government owned facilities after contract award.
- The budget is tied to the acquiring department’s budget and all accounting systems are tied to the department
In this scenario, the government should evaluate existing cloud service providers with a government compliant offering of substantial capacity (I’m not naming names here – you know who they are) and provide an offer to buy the entity (land, infrastructure, facilities, etc.) making it government owned. Part of the offer to buy would include an agreement to award the first multi-decade M&O contract. The government compliant cloud service provider in this example is a separate entity from the cloud service providers public offering and has its own fiber, land, and facilities, is highly available with power, infrastructure, and telecommunications redundancy, and is geographically separated for national security reasons.
To be government compliant, the cloud service provider is already staffed with a dedicated group of professionals that would meet all requirements (U.S. citizens, background-checks, etc.) meaning that a staff is already in place to support the M&O entity. It also has existing capacity to handle most of the federal governments workload, or it could be made ready to handle the workload in short order.
The M&O Model Over Time
Once the purchase is complete and the M&O contract is put in place, a plan to integrate all federal workloads could occur. I’ll use a sample 10-year contract award as an example for the timeline below:
- Years 0-3: Lift and Shift workloads from all departments and agencies
- Years 1-4: Retire data centers, infrastructure, on-premise environments, etc. from those departments and agencies that have migrated to the M&O’s Federal Cloud
- Years 2-6: Federate identities of sub-components at the parent or HQ level
- Years 5-8: Refactor/retire/replace systems
- Years 7-10: Create a federal government identity for all departments and agencies
Benefits of the M&O Model
An M&O contract approach would reduce overall IT spend by consolidating budgets, retiring services, reducing utility spend, and more. It also would provide a more secure environment for our critical data by securing a single, very large environment with known ingress/egress points on private communications rather than having departments and agencies secure hundreds of smaller environments with unknown connections, unknown users, and immature processes and procedures to protect the data.
As it stands, our government’s IT budget continues to balloon as our IT capabilities continue to fall behind, evidenced by the now-stalled JEDI contract. By using an approach that has worked in the past, we can reach the level of modernization and next-gen capabilities needed to keep the government running while protecting our nation. It’s time to (re)adopt the M&O model and build the cloud.
NEXT STORY: The return to work raises critical questions