1. Planning for, Acquiring, and Providing Data to Users and Customers
Module P2

2. Module P2 Principle 2: Plan for, Acquire, and Provide Data Responsive to Customer Requirements
Learning Objectives:
Understand that data is acquired by both government and industry
Understand the differences between stewardship and ownership of data
Understand the impact of data planning and data acquisition decisions on enterprise and program success
Learning Outcomes:
Distinguish the differences in applying DM planning from an Industry view and a Government view
Data meets the customer’s requirements
This module should provide the information to help the student identify the differences and similarities between the industry and government approaches and tasks related to planning and acquiring data. Additionally, the goal is to focus the student on the impacts/consequences of their planning and acquisition decisions.
Graphic depicting the Government and Industry (perhaps the Capital building, or the Pentagon, and then a Business building/skyscraper), show DM overarching both?

3. Contemporary Data Management Model
Presentation: Text can be voice over, with graphic boxes automated to add through the voice material
Explanatory Material:
DM solutions plan for, acquire, deliver, or arrange access to data consistent with this contemporary DM model. This principle addresses the steps in the DM model beginning with data need and ending with contract award. Five aspects of this model are important to planning for and acquiring data:
1. Data customers can be either external or internal to the enterprise.
2. Data is provided in a variety of forms
Ownership (control authority) may or may not transfer, providing an environment of data stewardship.
3. Data development, review, acceptance, and disposal may be joint activities, conducted by the data developer and customer.
4. Planning for data is deliberately linked to the overall product acquisition strategy and long-term sustainment planning through development of a data strategy and data concept of operations.
5. Data requirements authentication is preceded by a data risk analysis
References:
ANSI/GEIA-859, Section 2. Figure 2-1

4. Enabler 2.1: Establish General Requirements for Data
Develop data
strategy and
data concept
of operations
Determine
specific data
require-
ments
Perform data
risk analysis
Authenticate
data
requirements
Award
contract for
Establish
general
ments for
Present the entire graphic at the beginning, and then allow the user to click on each box for more information, in the form of a pop up.

5. Enabler 2.1: Establish General Requirements for Data
Evaluate the scope of data needs based on context
Program oversight (traditional view)
Performance and design
Manufacturing and testing
Operations and maintenance
Business oversight (expanded GEIA 859 view)
Legal and tax
Internal or external audit
General business operations
Presentation: voice over or pop up with text. Graphics or automation to show Program oversight first then add expanded Business oversight
Explanatory material:
The output of this enabler is a general description of potential requirements. At this point, before establishing a data strategy, it is not necessary or even desirable to attempt to define specific data requirements. This review should consider data that may be needed to support design oversight, business oversight, manufacturing, testing, operation and maintenance, and documentation that will be needed for legal, tax, historical, internal audit, or other valid purposes.
The intent is to recognize the spectrum of data views that may be needed to support the business needs, project tasks and products throughout the product life cycle. Included are not only project-specific requirements, but also related data that may be needed to meet broader enterprise or external requirements.
It should be feasible at this point to anticipate the form in which the data will be required and if access or delivery is appropriate.
. The general data requirements should define the data “mission“ - what needs to be done for whom, how, and why - the first step in any strategic analysis.
References:
ANSI/GEIA-859, Section 2.1
DM must consider both technical and business requirements!

6. Enabler 2.2: Develop Data Strategy and Data Concept of Operations
Presentation:
Graphic addition from left to write, one concept at a time with voice over
Explanatory Material:
Paraphrased from ANSI/EIA-859:
The data strategy creates the potential for data related decisions and contribution to long and short term goals by aligning data management with the context in which is lives and is being used.
While Enabler 2.1 defined the general requirements, this enabler is focused on the formulation of a data strategy, and requires a data environment assessment which examines:
Internal strengths and weaknesses of the program/enterprise
Strengths promote and weaknesses limit the ability to satisfy the requirements for data. A strength might be the existence of defined processes or technical infrastructure for vaulting electronic data. A weakness might be lack of process training.
External opportunities and challenges
Understanding external opportunities and challenges reveals how the external environment can affect management of data. It could be as simple as a corporate decision to retire a database that was intended for use, or an informed customer who creates a need to develop new capabilities that expands market potential.
Stakeholders and power sources.
Understanding stakeholders and power sources is important; stakeholders have to be satisfied, and power sources influence resource allocation.
Taken together, the elements of the DEA define what can be done without change and what will need to change to satisfy the data requirements. The outcome is the basis for defining the actions required to solve gaps and capitalize on opportunities.
References:
ANSI/EIA-859, Section 2.2
Business or enterprise perspective, ANSI/EIA-859, Section 3

7. Enabler 2.2: Develop Data Strategy and Data Concept of Operations
Concept of Operations defines:
Customer/user
Range and depth of data
Nature of the business over time
Generation of and delivery/access to data views
Provision for quality assurance
Provision for required resources
Presentation:
Addition bullet by bullet, one concept at a time with voice over
Explanatory Material:
Paraphrased from EIA-859 :
The concept of operations should identify:
Who the customers/users will be – internal or external. In the government environment, this may be a direct manager, the soldier, the supply officer, the PMO. In the industry environment, the customer may be external, such as the government or may be internal, engineering, finance, quality assurance, or human resources.
What range and depth of data will be provided, and over what period of time. Financial data for the enterprise will have a different requirement than a program requirement for cost and performance data from a subcontractor over the life of a development or production project.
What the nature of the business relationship will be and, how it is expected to change over time. Enterprise relationships are less conducive to change than customer/buyer relationships, but are evolving in the current business environment with out-sourcing of jobs that have been traditionally maintained within the organization. In a similar fashion, government/industry relationships and contractor/subcontractor relationships must be considered and evaluated.
How data views will be generated and provided. Decisions are made to define methods for delivery of or access to data and how it must be generated to support those methods.
How quality assurance will be provided – defined requirements necessary to ensure quality data. Subcontract evaluations, DCMA involvement and relationships identified, and technical and format review requirements should all be defined.
Who will provide resources to accomplish and fullfil the requirements? A combination of technical and management personnel, facilities, services and tools are examples of resources to be addressed.
References:
ANSI/EIA-859, Section 2.2
Business or enterprise perspective, ANSI/EIA-859, Section 3
DM must develop a plan for the use of data!

8. Enabler 2.3: Determine Specific Data Requirements
Refine data requirements to specific
Data products
Tradeoff considerations for similar data requirements
Users of data
Multiple users of data validate requirements
Frequency of data delivery
Users validate frequency requirements
Functional generation and review
Presentation:
Pop-up or voice over
Explanatory Materials:
Paraphrased from ANSI/EIA-859:
The process begins with understanding the data life cycle and, in that context, reviewing the general requirements to determine the types of data products that will need to be created. Consider tradeoffs of consolidating requirements for similar data products against providing the ability to personalize products. With electronic access to data, benefits from personalizing the data presentation can outweigh the decreasing cost of doing so. Requirements, project specific, enterprise or government, should be reviewed and included. Some requirements are likely to evolve over time. The impact of those changes on data products and their requirements must be assessed.
Identify specific users of the data products and establish when the users need each of these items. The users who need access to each of the completed data products, and any interim data products, are identified based on life-cycle requirements of the data. If multiple areas use a data product, all areas that require the information should be recorded, along with the dates needed. These users comprise the reviewers and validate frequency.
Relate Data Requirements to the Functional Areas Responsible for Data Generation and Distribution. Determine who will provide the data and how. More than one functional area may be involved in the creation of some data products.
If an internal source is responsible for preparing a data product, enterprise procedures should ensure that data requirements are communicated to the responsible functional area(s). If a contractor/subcontractor or other outside source is responsible for data generation, make sure the requirements are properly communicated. The schedule and supporting information requirements must be understood and commitment secured. If requirements were collaboratively developed, implementation of this step is simplified.
References:
ANSI/EIA-859, Section 2.3
Data must be requirements specific!

9. Use Project Life Cycle to Determine Needs for Data

10. Enabler 2.4: Perform Risk Analysis
Risk Management for data
Multiple sources of risk
Under and over provisioning of data
Irretrievability of data
Data loss and Data Obsolescence
Intellectual Property compromise
Risk Analysis method
Recognize and enumerate source
Determine occurrence probability and consequence severity
A Balancing
Act:
What is the
risk of NOT acquiring the
data?
risk of
acquiring the
Presentation:
Drop downs; voice over; automation – possibly a little man chasing a risk (butterfly?) with a net trying to capture and control it.
Explanatory materials:
There is often a lack of understanding that risk management also includes data and how data is managed. Some of the major risks that need to be evaluated are:
Under-provisioning of the data—this is the failure to request and provide data when it is needed
Over-provisioning data—providing data that is not useful or providing data prematurely to the point that it affects accuracy)
Inability to retrieve data – either the data is non-existent or there is inadequate cataloguing and metadata
Data loss, whether due to misplacement, theft, or a natural disaster
Data obsolescence—retaining data that is of no value.
Compromise of intellectual property – one of the most misunderstood or overlooked risks.
More information about intellectual property is located in the intellectual property module
Although the specifics of projects differ from one another, there is a demonstrated risk analysis method to consider:
Recognize and enumerate the sources of risk
For each risk, determine the likelihood of occurrence and severity of consequence if the risk materializes.
Simple scales (e.g., high, medium, low) are usually adequate to characterize the likelihood and severity of a related consequence. A priority can then be assigned for risk mitigation and given to those risks that, in relation to others, have combinations of higher likelihood of occurrence and severe consequences if they occur.
Characterization of under- and over-provisioning is an important input to data authentication and provides a basis for understanding and defending data requirements that should be satisfied. It also helps identify those requirements that are unnecessary. There may be other sources of risk not listed here as this list is not intended to be comprehensive.
Risk management is an iterative process, not a one-time event. Risk analysis is an inherent part of the data requirements definition and consolidation steps discussed earlier.
References:
ANSI/EIA-859, Section 2.4
For Intellectual property information, ANSI/EIA-859, Section 6
DM must recognize and plan for multiple sources of risk!

11. Enabler 2.5: Authenticate Data Requirements
Data authentication
Data strategy and DM plan in place
Bill of data covers user requirements
Risk assessment performed
Requirements integrated
Quality assurance measures specified
Data rights issues addressed
Access and maintenance issues resolved
Presentation:
Voice over or pop-up
Explanatory Materials:
Paraphrased from EIA-859:
Before the data can be authorized for development or procurement, authentication of the data requirements must occur. The purpose is to make sure that requirements, as defined in a bill of data, are valid, complete, and make sense from a business standpoint. In authenticating data requirements, the enterprise or government agency should address the following questions at a minimum:
Are a DM strategy and DM plan in place to guide overall data acquisition for the affected project or procurement?
Are the strategy and plan adequate to support the end use?
Does the proposed development/procurement of data follow the strategy and plan?
Does the proposed bill of data respond to user requirements? Content, as well as types, formats, and delivery or access timelines must respond to user and enterprise needs.
Has the risk assessment been performed?
Is the risk assessment reasonable? Risks must be understood and the approach to risk mitigation reasonable.
Are there duplicate requirements? Requirements must be adequately integrated to eliminate redundancy.
Are quality assurance measures specified so that the data received, generated, and used will be appropriate and suitable?
Have data rights issues been addressed and resolved?
If future access or contingent requirements are involved, data maintenance, configuration management, and (if appropriate) deferred data delivery, deferred data ordering, or third-party escrow should be considered and addressed.
References:
ANSI/EIA-859, Section 2.5
DM assures requirements are valid, complete, current, and make sense!

12. Enabler 2.6 Contract for Data
Multiple methods for contracting
Traditional contracting – prime and sub contracting
Partnership agreements – teaming
Work authorizations
Memorandum of Agreement
Multiple forms of contracted data
Data Access
Conventional Delivery
Deferred data ordering
Deferred data delivery
Third party escrow
Presentation:
Pop-up or voice over
Explanatory materials:
Paraphrased from ANSI/EIA-859:
“Contract” is intended to include formal contracts between two companies, formal contracts between a government agency and a company, interdepartmental work authorizations within a company, memoranda of agreement, and any other form of agreement that describes the duties of a supplier to perform DM for a customer.
Data may be provided through a standalone contract or as part of a larger contract for goods or services. What is contracted for can take many forms, including the following:
Data access under agreed-to provisions (period of time, access rights, purposes, and limitations). “Access” is becoming increasingly important and does away with traditional delivery, per se. “Delivery,” when it is needed at all, is effected by notification that the data is available to be accessed.
Conventional delivery at a specified time or in conjunction with a specified event.
Deferred data delivery. Used when design is still evolving, is technical and final design is the desired data. It establishes an obligation on the part of the supplier to deliver data up until some specified time period following contract termination.
Deferred data ordering. Used when a firm requirement for a particular data item has not been established before contract award but there is a potential need for the data. Buyer may order any data that has been generated in the performance of the contract, or any subcontract, until some specified time after contract termination.
Third-party data escrow. Used when it is not in the buyer’s interest to take immediate delivery of data, but needs assurance that data will be available in the future. Placing the data in the hands of a disinterested third party protects supplier technology and intellectual assets until release under specified conditions. Provisions for periodic updates (e.g., when versions change) and verification can be included.
References:
ANSI/GEIA-859, Section 2.6
DM pertains to all types of contracting!

13. Quiz Questions – P2 Data is procured only by: Government agencies
Defense industry companies
Commercial organizations
All of the above
Ownership may or may not transfer, providing an environment of data stewardship.
True or false?
Why is a data strategy important?
a. Provides basis of data related decisions
b. Defines specific data requirements
c. Changes ownership of data
Once specific data requirements are defined, they never change.

14. Quiz Questions – P2
Which organizations should perform a risk assessment for data?
Only Government agency
Only Contractor
Buyer and seller
None of the above
All of the above
Data strategies and plans are the same for every context of the organization.
True or false?