DODAF - DOD Architecture Framework Version 2.02 - DOD Deputy Chief Information Officer

DM2 Data Groups


A Project is a temporary endeavor undertaken to create Resources of Desired Effects. Projects are relevant to all six core processes. Projects form the major elements of the DAS and are the primary focus of the DoD PPBE system.

The Primary Construct of the PPBE system is the Program Element (PE). The PE is defined as:

Program Element: The program element is the basic building block of the Future Years Defense Program. The PE describes the program mission and identifies the organization responsible to perform the mission. A PE may consist of forces, manpower, materiel (both real and personal property), services, and associated costs, as applicable.

The key architectural construct within the Program Element is the Work Breakdown Structure (WBS) subject to DoD Instruction 5000.2. The WBS is the primary instrument connecting an Architectural Description to the Defense Acquisitions System and the PPBE processes. The Work Breakdown Structure (WBS) is defined as:

Work Breakdown Structure: "A product-oriented family tree composed of hardware, software, services, data, and facilities. The family tree results from systems engineering efforts during the acquisition of a defense materiel item".

MIL-HDBK-881A provides guidance for constructing the WBS applicable to programs subject to DoD Instruction 5000.2. The WBS is the process necessary for subdividing the major product deliverables and project work into smaller more manageable components and it serves as a valuable framework for the technical objectives, and therefore it is product-oriented. Its elements should represent identifiable work products, whether they are equipment, data, or related service products. A WBS is a product structure, not an organizational structure, providing the complete definition of the work to be performed by all participants and the required interfaces between them.

Hardware, software, services, data, and facilities are Resources in the DM2. The information captured in the project administrative tool/techniques (e.g., Project Management Body of Knowledge [PMBOK] 2004) provides the basis for resource information in the DM2. The WBS forms the basis of reporting structures used for contracts requiring compliance with ANSI/EIA 748 Earned Value Management System (EVMS) Guidelines and reports placed on contract such as Contractor Cost Data Reporting (CCDR), Software Resource Data Report (SRDR), Contract Performance Reports (CPR), and Contract Funds Status Reports (CFSR).

MIL-HDBK-881A states: ".the Program WBS and Contract WBS help document architectural products in a system life cycle. The DoD Architecture Framework (DoDAF) V1.0 defines a common approach for DoD Architecture Description development, presentation, and integration for warfighting operations and business operations and processes."

Just as the system is defined and developed throughout its lifecycle, so is the WBS. In the early Project phases of concept refinement, system architecture, and technology development, the program WBS is usually in an early stage of development. The results of the Analysis of Material Approaches and the Analysis of Alternatives (AoA) provide the basis for the evolution of the WBS at all stages of Project evolution. As the architectural design of the project's product or service matures, so should the WBS. The WBS is a primary tool in maintaining efficient and cost effective developments of products and services. The figure below illustrates the evolution of the WBS during the lifecycle of Project.

Evolution of the Project WBS

Evolution of the Project WBS


A Project Plan contains the project WBS (including Tasks and responsible Organizations). The Project Data Group (PDG) contains the essential data required for defining a Project Plan, e.g., those required by DoD 5000.2:

a. Acquisition Strategy

b. Technology Development Strategy

c. System Engineering Plan.

The Tasks and Performers form the essential elements of the project's WBS. The use of both Tasks and Performers focusing on products to be delivered (e.g., System, Service, etc.) in the WBS is the essential premise of the product-oriented WBS defined in MIL-HDBK-881A.

The Project Plan also shows plans and initiatives to coordinate transition planning in a documented program baseline, shows critical success factors, milestones, measures, deliverables, and periodic program reviews.

Data Group Description

The DoDAF Meta Model for the data comprising Project is shown in Figure 13. There are several items to note regarding this model:

a. Like all concepts in the DM2, Project has whole-part, temporal whole-part, and super-subtype relationships so that major Projects can have minor Projects within them, Projects can have time phases, and Projects can be categorized.

b. Because a Project involves execution of a plan composed of Activities (Tasks), there is a flow of resources into the project's activities and a flow of products out of them, as described by the Resource Flow data group. So this model can describe a Project that results in a System, a Service, Personnel Types (i.e., Training), Organizations (i.e., organizational development), Materiel, or Locations (e.g., Facilities, Installations).

c. Because technology is part of the Project, this group models the analog of the DoDAF V 1.0 and V1.5 SV-9 (System and Services Technology Forecast) and SV-8 (System and Services Evolution Description).

d. Many kinds of measures may be associated with a Project - needs, satisfaction, performance, interoperability, organizational, and cost.

e. Measures and Rules can be assigned at all levels of the Project decomposition. Top-level Measures and Rules (Conditions and Constraints) could be assigned to the Vision, Goals, and Objectives (VGO). Lower-level Measures and Rules can then be derived and assigned to compliance and test criteria. When part of a legal contract, policy, or directive, formal agreement, or contract instrument, the Rules constitute a principle portion of the requirements for the Project.

DoDAF Meta Model for Project

DoDAF Meta Model for Project

Usage in Core Processes

Data for Projects are used in the following ways:

  1. JCIDS
    1)Project is the typical outcome of the JCIDS process when material solutions are identified. 2)Non-material solutions may also result in projects

  2. PPBE, DAS , and CPM
    1)Project is the core element of the PPBE, DAS and CPM processes. The primary construct of Project is the Work Breakdown Structure (WBS). The WBS is the primary reification within Project that relates Performers and Activities to Cost and Milestones. As stated in MIL-HDBK-881A, the WBS is a continually evolving instrument from Project conception to lifecycle management. This tracks closely with the evolution of the architecture. As key Activities are refined into primary Activities and assigned to or allocated to Performers, the WBS should mature and the project definition can gain additional focus (reification).

    2)Early Project WBSs may contain high-level Activities (Tasks, Processes, System Functions, or Service Functions). As the Project matures, the WBS identifies the system components, such as subsystems and software configuration items (SCIs). The SCIs can be software services or individually testable and deliverable packages of software. Depending on the acquisition strategy, all or part of the Project WBS and, depending on acquisition strategy, may become the Contract WBS and form the basic outline of the requirements in a statement of work and the project Statement of Objectives (SOO) or Specification. The figure below illustrates this method.

    3)The other, non-materiel portions of the WBS (Work Packages, Task and Activities) are derived in a similar fashion, i.e., Activities assigned to or allocated to Performers that are, in turn, assigned to Organizations, Personnel and Facilities.

  3. SE 
    The data derived from Architectural Descriptions, derived through the systems engineering process, directly support the definition and structuring of Projects. The DoDAF architectural data elements are used in the WBS, Architecture based and Classical Specifications and the SOW essential to the systems engineering process. The DoDAF augments classical System Engineering techniques by standardizing the lexicon and relationships. The figure below illustrates the typical systems engineering process and its relationship to DODAF constructs. The process shows how operational needs, as described in description documents such as the Capabilities Description Document (CDD), are translated into structured, engineerable requirements and associated Project constructs. Further, this shows how capabilities and processes are transformed into Solutions through automation tradeoffs and Analysis of Alternatives (AoA). Various alternatives are iterated through the architectural descriptions to meet the required performance, cost, and schedule constraints. From here, Functional and Allocated baselines can be established. As increased detail is added to the architecture, classical systems engineering and design techniques are increasingly applied.

  4. Ops Planning:
    1)Project also is used in Operational Planning in such areas as developing specific Mission Plans and procedures. Any effort in the Operational community requiring identifiable funding and management can be defined as a Project.

Derivation of the Materiel Portion of the WBS
(click to enlarge)

Architectural Description Usage in Forming Project Structure Reified in the WBS

Architectural Description Usage in Forming Project Structure Reified in the WBS


Project presentation techniques are typically use Tree models (WBS), Timeline Models and Tabular information (e.g. spread sheets). Tree models containing products and organizations are represented in the PDG as whole-part breakdowns of the overall end-product and participating organizations of the project. The figure below illustrates how a whole-part structure can be used to partition the Project into manageable subprojects, identify where common off-the-shelf-building blocks (Reuse) can be utilized, and identify all components of the system. In the acquisition stages, the level of breakdown of this decomposition is dependent on perspective (e.g., SoS, Enterprise, System, etc.) and acquisition strategy.

Non-prescriptive, Illustrative Example of System Project Decomposition Used to Develop the Product Portion of the WBS

Non-prescriptive, Illustrative Example of System Project Decomposition Used to Develop the Product Portion of the WBS