The PV-3 “Project to Capability Mapping” supports the acquisition and deployment processes, including the management of dependencies between projects and the integration of all relevant project and program elements to achieve a capability. It maps programs, projects, portfolios, or initiatives to capabilities to show how the specific elements help to achieve a capability. Programs, projects, portfolios, or initiatives are mapped to the capability for a particular timeframe. Programs, projects, portfolios, or initiatives may contribute to multiple capabilities and may mature across time. The analysis can be used to identify capability redundancies and shortfalls, highlight phasing issues, expose organizational or system interoperability problems, and support program decisions, such as when to phase out a legacy system.
The intended usage of the PV-3 includes:
- Tracing capability requirements to projects
- Capability audit
The PV-3 describes the mapping between capabilities and the programs, projects, portfolios, or initiatives that would support the capabilities. This model may be used to indicate that a project does or does not fulfill the requirements for a capability for a particular phase. This model is analogous to the SV-5a “Operational Activity to System Function Traceability Matrix”, but provides the interface between Capability and Project Models rather than Operational to System Models.
In principle, there could be a different PV-3 table created for each development phase of the program, project, portfolio, or initiative development, or perhaps for different phasing scenarios. In most cases, a single table can be constructed because the programs, projects, portfolios, or initiatives that are most likely relevant to this model can be relatively high level. If capabilities associated are generic (see CV-1 Vision Model), then they should have a well understood relationship with a set of programs, projects, portfolios, or initiatives and this relationship is unlikely to change over time.
The PV-3 can have a tabular presentation. The rows can be the Capabilities and the columns can be the programs, projects, portfolios, or initiatives. An X can indicate where the capability is supported by the programs, projects, portfolios, or initiatives whereas a blank can indicate that it does not. Alternatively, a date or phase can indicate when programs, projects, portfolios, or initiatives will support capabilities by the date or phase indicated.
- The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
- DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.
AcqLinks and References:
-  DoDAF Architecture Framework Version 2.02
- DoD Architecture Framework Working Group Version 1.0, Volume 1: Definition and Guideline, 9 Feb 04 (Old Version)
- DoD Architecture Framework Version 1.0, Volume 2: Product Description, 9 Feb 04 (Old Version)
- Website: DoDAF Architecture Framework – DoD Deputy Chief Information Officer
- Website: DoDAF Version 2.02 Journal
- Website: DoDAF Meta Model (DM2)
- Website: DoD Information Enterprise Architecture
- Website: OMB Enterprise Architecture Assessment Framework (EAAF)