As the old saying goes, “Rome wasn’t built in a day!” Complex capability developments or complex and prolonged transformation efforts [GAO 2006] are seldom accomplished through single projects. For the manager who is managing a portfolio of such projects or initiatives [EPMC 2009], the task of orchestrating the deliverables of each project in synchronization with the needs of other projects is tricky and challenging. The Project Viewpoint provides the portfolio manager with a set of views that enables him/her to orchestrate the combined planning and management of multiple projects. The operative words here are “multiple projects,” because of the various dependencies between projects that affect the delivered capabilities and the need to plan the deliverables carefully in keeping with the dependencies as we have seen earlier in the views CV-3: Capability Phasing and CV-4: Capability Dependencies in Chapter 13. The Project Viewpoint is not concerned as much with the detailed tasks, schedules, and resources for individual projects as it is with the concerns of managing a group of coordinated projects that must collaborate to deliver a complex deliverable.

In the federal government arena, projects or initiatives are used to transform government or to improve the current state of the enterprise while remaining consistent with strategic goals and objectives. A family or portfolio of projects is used to deliver a collection of related initiatives that support enterprise transformation or a phase of enterprise transformation.

In the DoD arena, projects are collections of tasks that deliver capabilities within the framework of a larger initiative called a program or acquisition program. A collection of systems or services that, together with operational processes and human and other organizational resources, delivers a capability is called a capability configuration. To be effective, a program must deliver all of the component parts of the capability configuration in a consistent and orchestrated manner. A typical DoD program is responsible for the acquisition of large-scale, complex weapons systems or automated information systems as well as sustainment and maintenance of the systems once they are acquired and deployed. Programs tend to run for multiple years and are funded in increments based on various metrics that determine the health of the program and the viability of the capabilities that are produced.

The concept of portfolios is applicable to non-DoD enterprises such as the federal government as well. A transformation may be viewed as a collection of initiatives. Each of these initiatives has dependencies with other initiatives. Portfolios of projects that are responsible for delivering the collection of initiatives need to reflect and factor in the dependencies among the initiatives.

In the commercial world, every initiative is deemed an investment and is measured in terms of payback or return. A collection of initiatives is therefore seen as a portfolio of investments. A project or family of projects is related to single or multiple investments. The principles and view types described in the DoDAF Project Viewpoint are applicable, adaptable, and customizable to the commercial domain as well, given a change in terminology and a shift in focus. In the commercially oriented TOGAF 9, the formulation of opportunities and solutions is performed in Phase E of the Architecture Development Methodology (ADM). It is during this phase that a project context diagram similar to the PV-1: Project Portfolio Relationships described in this chapter is developed.

As we saw earlier with the Capability Viewpoint, we have the ability to model capability dependencies, capability taxonomies, relationships of capabilities to using organizations, to solution services, and to operational activities the capabilities enable. The Project Viewpoint view of a project is something that is responsible for delivering clearly stated capabilities. These capabilities are consistent with those defined in the Capability Viewpoint. The Project Viewpoint views must be consistent with and reflect capability dependencies. (See Figure 5-12 in Chapter 5, which shows the relationships among the Capability Viewpoint views and the Project Viewpoint views.) The multiple projects in a portfolio must be orchestrated consistent with capability dependencies, and projects must deliver independent upstream configuration components earlier than dependent downstream configuration components.

A capability configuration is a collection of interdependent capability components that must be planned together. Because each of these capability components may be developed by a different project, it is important that the project portfolio responsible for developing the entire capability configuration be orchestrated to reflect capability dependencies and the orderly development of capabilities in a manner that is consistent with those dependencies.

Views in the Project Viewpoint

The Project Viewpoint contains three views:

• PV-1: Project Portfolio Relationships   The PV-1 is used to depict the grouping of projects into portfolios and the mapping of the portfolios to the responsible development organizations or portfolio managers.

• PV-2: Project Timelines   The PV-2 acts like an aggregated Gantt chart for a portfolio of projects and allows a very quick view of the various timelines of the component projects and their dependencies.

• PV-3: Project to Capability Mapping   The PV-3 illustrates the relationship of a project to the capabilities it delivers. Together with the CV-3, it helps identify anomalies such as redundant capability development or the identification of capability gaps that are not covered by any project.

Figure 14-1 shows how all the elements of the Project Viewpoint fit into the views. See Figure 4-4 in Chapter 4 for an alternative view that shows how elements of the Capability Viewpoint and Project Viewpoint relate.

Figure 14-1   Integrated views set for the Project Viewpoint

Though not explicitly represented by a DoDAF-described type, the project portfolio is a composition structure that describes the families of projects that form the enterprise project portfolio.

All the Project Viewpoint views must consistently reference the same project list.

PV-1: Project Portfolio Relationships

Traditional project management tools do a great job of supporting single projects using work breakdown structures, cost, schedule, resources, and tasks. However, enterprise architecture is concerned with the management and coordination of multiple projects. The concept of project portfolios is basic. Some commercial project management tools [Microsoft 2011] address portfolio representation using a master project approach that provides active links to several smaller subprojects. The PV-1 provides a technique for representing the groupings of multiple projects into portfolios. In TOGAF 9 (see Chapter 22), the formulation of opportunities and solutions is performed in Phase E of the TOGAF ADM. It is during this phase that a Project Context Diagram, similar to the PV-1, is developed. The Project Context Diagram can be used as an alternative to the PV-1.

The PV-1 shows how acquisition or development projects are grouped in terms of organizational ownership.

Example: RMN Passenger Management PV-1

This example references the systems in Figure 16-3 and “Example: Passenger Identification SV-2” in Chapter 16. The focus is on the projects that are under the control of RMN Airport. Projects to develop the systems provided by organizations external to the airport, such as the airlines and TSA, are not included. The time frame reflected in this view is that of the first years of the initial phase (phase 1) of transformation, where RMN Airport starts to support scheduled commuter airlines. (See Figure 13-3 and “Example: RMN Airport Enterprise CV-1” in Chapter 13.) The assumptions implicit in the example are that a small airport supporting only domestic flights will not need customs and border protection (CBP), immigration, and some of the other functions that will need to be added toward the end of phase 1 as the airport approaches phase 2 of transformation. However, it will still need interfaces to the Transportation Security Agency’s Common Screening System (CSS). It is also assumed that each airline will use a different Airline Reservation and Ticketing System (ARTS) that potentially requires a different interface to Passenger Intelligence System (PaxIS) and that upgrades to externally supplied systems will not necessarily be coordinated with RMN. This example includes facilities development projects as well as IT development projects.

PV-2: Project Timelines

Just as the PV-1 shown earlier is a view that represents the composition of a project portfolio in terms of constituent projects and project owners, the PV-2: Project Timelines view represents a time-based schedule that depicts how these projects must be orchestrated in order for one project to provide timely deliverables to another.

The PV-2 references a time frame and phases and milestones. The planning window must be represented by these time frames, phases, and milestones, be consistent throughout the architecture and align with time frames, phases, and milestones in other roadmap type views such as the CV-3: Capability Phasing, SV-7: Systems Measures Matrix, SvcV-7: Services Measures Matrix, SvcV-8: Services Evolution Description, SvcV-9: Services Technology and Skills Forecast, SV-8: Systems Evolution Description, SV-9: Systems Technology and Skills Forecast, and StdV-2: Standards Forecast for example. These time frames and phases will also likely be described by the AV-1 as the applicable time frames overall for the architecture.

The PV-2 shows project start and stop dates, how project durations relate to each other, and project dependencies. Note that the PV-2 is not intended for use with Solution Level architectures because it is designed for managing multiple projects with dependencies. (Standalone schedules for single projects are of interest only to the single project manager.)

Example: Passenger Management PV-2

Figure 14-2 shows an example PV-2, a partial set of timelines for early RMN Airport transition phase 1. In the figure, the arrows show the dependencies, with the tail of each arrow indicating the dependent project and the head of each arrow pointing to the project that should supply the needed component. The positioning of the arrows indicates the expected time when the needed component should be available. The assumptions are that early in phase 1, there will be only one airline serving RMN Airport. The focus is on the dependencies around the integration of the airline-supplied basic ARTS system and PaxIS. The example would be more complex if the timelines covered more of phase 1 and if more than one airline was involved.

Figure 14-2   Example RMN passenger management PV-2

PV-3: Project to Capability Mapping

In a project portfolio of multiple projects whose primary purpose is to deliver a capability or a set of capabilities, the PV-3: Project to Capability Mapping view maps each individual project to the capabilities it provides components for. In other words, a project may provide only some components for a capability configuration, a complete capability configuration, or, in rare cases, more than one complete capability configuration. This view is useful for detecting whether multiple projects are delivering the same capability configuration or whether some projects do not contribute to any capabilities. It can also show whether some component of a capability configuration is not being developed by any project.

Example: Domestic Passenger Identification PV-3

In this example, most of the projects provide components for each of the three identified capabilities. It is assumed that in the early phase 1 transition for RMN Airport, the passenger terminal construction project does not address facilities for TSA and baggage handling or baggage claims. (For example, the early passenger terminal may consist of portable temporary structures.) The projects for these facilities have not been included in this set of examples.

Summary

The Project Viewpoint views are designed to support portfolio managers and planners in the management of investment portfolios. The Project Viewpoint views integrate with the Capability Viewpoint views and these two viewpoints provide the majority of the recommended core views for Enterprise Level architectures. The Project Viewpoint includes only three views—PV-1: Project Portfolio Relationships allows tracking of portfolio projects to the organization managing the portfolio; PV-2: Project Timelines allows the tracking of critical deliverable dependencies among the projects in a portfolio or across portfolios; and PV-3: Project to Capability Mapping allows the tracking of project contributions to the development of desired capabilities.

Questions

1. Discuss the challenges of managing a family of projects versus managing a single project. Will the project management tools that help manage single projects also help you manage multiple projects? How will they handle the determination of dependencies of tasks across projects?

2. What Capability Viewpoint views can help you manage a family of products? How would you use the CV-3: Capability Phasing and CV-4: Capability Dependencies to help you analyze the project portfolio?

3. Does your enterprise distinguish between programs, projects, and initiatives? Explain what these terms mean in the context of the federal government, DoD, and commercial enterprises.

4. Where are the financial aspects of a project, program, or initiative reflected (or not) inside the Project Viewpoint views depicted in this chapter?

5. What are the pros and cons of not developing a PV-3: Project to Capability Mapping?

5. Who is the audience for the Project Viewpoint?

7. Discuss the analysis aspects related to the costs, paybacks, and benefits of:

a. A new system being developed and viewed as a capital investment

b. A project viewed as a budgeted expense that represents a sunken investment

c. An initiative that is opportunistic and represents a gamble on the payoff

References

The Enterprise Portfolio Management Council, Pennypacker, James, and San Retna, eds. 2009. Project Portfolio Management: A View from the Management Trenches. Hoboken, NJ: John Wiley & Sons.

Government Accountability Office. 2005. Best Practices: Better Support of Weapons System Program Managers Needed to Improve Outcomes. GAO-06-110. www.gao.gov/new.items/d06110.pdf.

Government Accountability Office. 2006. Defense Acquisitions: Major Weapons Systems Continue to Experience Cost and Schedule Problems Under DoD’s Revised Policy. GAO-06-368. www.gao.gov/new.items/d06368.pdf.

Microsoft Corporation. 2011. Plans Within Plans: Master Projects and Subprojects. http://office.microsoft.com/en-us/project-help/plans-within-plans-master-projects-and subprojects-HA001226035.aspx#BM#2.