Back to Digital Guide Home

Digital Strategy Considerations

How to Define Your Program’s Digital Strategy
The Digital Campaign has developed four digital acquisition approaches and believes it is important for programs to identify their contract strategy in terms of one of these four digital approaches. This continues to be a work in progress, but here is the latest.
 
Before defining your digital approach, a program needs to identify their program model objectives. Program model objectives are derived from program and technical requirements. Technical requirements include the capabilities, threats, security, and operational concept for the acquisition and program requirements include time, budget, and resources. Program objectives could include concepts for options, re-competition, down-select, production, prototype, and demonstrations. The modeling objectives then define the model and model data that the government needs to make key decisions and/or perform their duties based on those program objectives, technical and program requirements. The modeling objectives will then lead the program into a digital approach for acquisition. Below is a graphic representation as further explanation.
 
The four acquisition approaches are Model-Supported Acquisition, Model-Collaborative Acquisition, Model-Centric Acquisition, and Model-Service Acquisition. Each are defined below:
 
Model-Supported Acquisition is an acquisition approach where models may be used to support various engineering activities including the production of key documents for contractual purposes. This implies that specific analytical models are used to address specific engineering concerns.
 
Model-Collaborative Acquisition is an acquisition approach where models form part of the contractual artifacts but as secondary or complementary artifacts (with the capability to generate required documentation or model views). This implies that along with specific analytical models system descriptive models are used in parallel with architecting and engineering activities. This views modeling as “documenting” the architecture and engineering activities.
 
Model-Centric Acquisition is an acquisition approach where models are primary artifacts with the capability to generate required documentation or model views. This implies that along with specific analytical models system descriptive models are used as the basis for architecting and engineering activities. This views modeling as being the basis of the architecture and engineering activities.
 
Model-Service Acquisition is an acquisition approach where models are used to support various engineering and program management activities to ensure quality of service. This implies that specific descriptive and analytic models are used to enhance quality of service.
 
As you can see from the figure below, the blue box has a program defining their acquisition and digital objectives. This will help determine the acquisition approach from the three definitions above.
To further explain the figure above, we need to provide a few more definitions. The Government Digital Reference Library in the yellowish box is a government data-managed and
configuration-managed set of Government Reference Models (GRMs), Acquisition Reference Models (ARMs) and artifacts model data, used as a reference for the Request for Proposal. The Government Reference Model (GRM) is the technical model (e.g. descriptive “enterprise model,” “systems model,” and “product models” as well as analytical models such as physics models). The Acquisition Reference Model (ARM) is the acquisition model that contains the information to generate acquisition documents (e.g. ASP, SEP, TEMP, ILSP, TTP) and program management documents (e.g. WBS, SOW).
 
The “Defined DE Features” box illustrates a place that a program can go to for the defined digital program features and the associated RFP example language based on the choices made by the program. Today that information is provided within this Digital Guide at Model-Based Contract Language.
 
So from the “Define the DE/Modeling Strategy” (blue box) and the Defined RFP Examples, a program can move forward with the selected model-based RFP example language in a thorough review to ensure the right language is appropriate for their program. The final box on Tailoring and integrating the Digital RFP language is very important and requires a program to critically think about their acquisition objectives and the outcome they wish to have.