Understanding the Complementary Relationship Between Enterprise Architecture and Project Management.

Understanding the Complementary Relationship Between Enterprise Architecture and Project Management.

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 ...

This article was first published in A&G

Read the full article here 

To view or add a comment, sign in

Insights from the community

Others also viewed

Explore topics