Project management frequently develops business user needs to include technical and functional requirements. Whereas, enterprise architecture (EA) employs a method of producing technical standards and business operational needs. Successful companies are beginning to integrate both functions by ensuring proper data flow between them and common language and taxonomy is used to establish consistency by extending dimensions between both organizational units. This post gives a perspective of the different views and complementary relationships between an Enterprise Architecture (EA) function and a Project Management Office (PMO).

Complementary Business Functions

The Enterprise Architecture Body of Knowledge defines enterprise architecture as a practice, which analyzes areas of everyday activity within or between organizations, where information and other resources are exchanged to guide future states from an integrated viewpoint of strategy, business, and technology. The responsibility of Enterprise Architecture is to assist business leaders in vision, mission, capability, goal and objective identification leading to the creation of business models and processes describing the structure of the enterprise. This structure includes the people, process, and technology required to fulfill the business mission while achieving the business vision through select business goals. These select goals are then completed through Project Management. EA identifies dependencies to the achievement of these goals which are needed by project management for project planning; these goals are similar to project milestones in the traditional waterfall methodology, and EA only facilitates this process through the application of best practice techniques.

Enterprise Architecture creates roadmaps as a deliverable to establish the relationships between business capabilities and business goals. The method lists individual work packages between the current processes (the baseline architecture) and future state processes or goals (the target architecture), dependencies and analysis of the gaps, and shows a progression of how these goals will be achieved. Goals expand the business vision. Goals are milestones required to realize the business vision. Enterprise Architecture also promotes discussion and provides a process between the Project Management Office (PMO) and the business leadership to create an executable roadmap to ensure achievement of the business vision. In the nonexistence of an EA function within an enterprise, a PMO may use business analysis to assemble IT requirements that support business goals; showing where EA and the PMO may intersect. At the project or solution delivery level, enterprise architecture supports project management, by defining work packages included in a project management plan. Project teams reference a catalog of work packages to ascertain tasks needed to be done to achieve the set goals. These work packages help with resource management, a key element to activity resource estimating and project human resource management. Both are essential components of a comprehensive project management plan to execute and monitor a project successfully.

Enterprise Architecture is a consultant to business leadership and the project management office. Working directly with business leaders, EA creates a structure proposal to capture the business needs such as purpose, vision, mission, capabilities, business goals, scope, process, functional needs, and objectives to complete the business architecture. Upon approval, the business leadership authorizes the delivery of the business architecture to project management. Project management uses the business architecture to plan implementation (product development, contracting, coordination of resources, planning, outsourcing strategies and so on). If project management identifies required changes to the business architecture deliverable, project management coordinate with EA to make necessary approved changes. Requirements are managed using a Requirements Management process. As described in the TOGAF 9.1 specification, this is used to manage architecture requirements identified during any execution of the Architecture Development Method (ADM) cycle.

There are always two sides to a coin, and some may argue that both disciplines do not intersect. From an information technology viewpoint, EA differs significantly from project management. EA includes non-technical areas such as organizational and business process; topics that do not primarily concern IT. EA also assists in the establishment of a clear understanding of the business environment, also known as the important business outcomes. EA is responsible for the structure, documentation, and modeling of the enterprise while the PMO is responsible for planning, monitoring, and reporting of work packages. The architect models the enterprise and establishes principles for transformation, standards for technologies, and the roadmap for the business with the aim of achieving the target architecture or business goal. After receiving the transition architectures, dependencies, roadmap, risks, the work breakdown, skills and resources and deliverables from EA, the PMO has to come up with a project plan and iterate it until the schedule, resources, and costs are in sync. The PMO has then to monitor and report progress, impediments, risks, and required changes to these architectures. But, asides these differing perspectives we can still argue that objectives of both functions are pretty similar; The following lists out the overlapping objectives of both functions;

• Strategy: It is an adage that EA ensures business and IT strategy alignment while PMO supports strategic planning

• Investments: EA influences approval decisions and budget formulation when it comes to business investment. PMO supports the budget formulation process and monitors investments

• Governance and Review Process: EA is a member of the review process, project portfolio planning and review board which governs project performance against scope, schedule, costs, risks, and quality. PMO leads this review process and adds new projects to project portfolios, monitors and reports risks, issues and performance problems

• Acquisitions: EA ensures IT assets align with target architectures and technology standards, promotes re-use and provides acquisition support. PMO supports development of procurement package through cost estimates, Request for Proposals and selection plans

Both disciplines are complementary, but the domains and work products are different, and the outcome between the two is a collaborative effort.

It is clear that Enterprise Architecture is a way of using system thinking as an instrument to integrate and align all organizational levels; from strategic to project level, against a primary objective. EA recommends solutions that help the organization attain its goals, and to continually govern the implementation of these solutions to meet business goals and objectives. However, Awareness of the subject of Enterprise Architecture tends to surface in the Enterprise through IT, the Information Systems (or Information Technology) Community. This lack of awareness is a perception that business leaders need to address to gain value from EA.

Creating Business Value

To build a case for integration, EA and the PMO have to focus on outcomes that will validate the business value collectively. These results are achieved by improving the project selection decisions by adequate prioritization of the project portfolio using Project Portfolio Management (PPM). PPM is the centralized management of the processes, methods, and technologies used by project managers and PMOs to analyze and collectively manage current or proposed projects based on numerous key characteristics.9 Determination of supported future business capabilities is supported, and alignment with strategy and architecture is also required.

EA has to ensure that the PPM provides key deliverables to the architects. Ways of achieving this include proposed project and business case meetings, shared project dependencies reports, project fulfillment of EA requirements before commencement, a unified PMO and EA governance process, and involvement of EA in project design reviews. On the other hand, the PMO has to ensure EA provides key deliverables to project managers by delivering the enterprise context for every goal at the project or solution delivery level, collaborative project change proposals, project developmental assessments, and well-defined enterprise architecture road maps showing how such goals fit into the bigger picture via transition architectures.

To sustain value, here are business exceptions that EA and PMO must solve:

• Increased focus on business value: Both functions must understand and translate business strategy into strategy execution.

• Increased knowledge of business and information architecture.

• Improved collaboration and fewer silos.

• Focus on prioritization: Strategic enterprise goals must be understood and followed.

Strategy execution happens when EA receives business direction from the business planning which in turn gives a structured guidance to portfolio management (program and project management). Capability planning using this model leads to strategy execution.

Conclusion

Successful companies are beginning to integrate both functions by ensuring proper data flow between them and using common language and taxonomy to establish consistency by extending dimensions between both organizational units. PMO dimensions are extended to include business capabilities and risk, while EA dimensions are extended to fully enable execution of project data and its application to applications. Alignment occurs when both functions support integrated bi-directional scenarios. EA is the role of seeing the big picture as a tool to help focus on the right details, project management. It is about architecting optimized processes and models based on leadership’s strategies for the enterprise, but a process by itself does not create value; rather, identified value requires a process. Finally, EA and PMO are often complementary disciplines in many regards, not contradictory to each other. When there is a concession to approach EA, in general, as a collaborative effort with agreement on the transition architectures, the relationship between both functions can be rewarding to the business they serve.

This article was first published in the Architecture & Governance Magazine.