February 6, 2013
Translating opportunities to a well-defined project plan
This is the sixth posting in a series on TOGAF’s ADM. In the previous post we zoomed in on finding opportunities that help realize a desired vision. In this post we pick up the thread and focus on translating these opportunities and solutions to a well-defined migration plan.
The objective of this phase is simple: come up with a migration plan that is aligned with other management and governance frameworks in the organization (i.e. project management approaches such as Prince2). This entails two things: (1) to make sure that work packages – based on the transition architectures from phase E – are defined and prioritized, and (2) to co-ordinate with the project management office so that the projects can be kicked off when necessary.
The inputs of this phase are numerous in the full TOGAF spec, and mostly cover the outputs of all the previous phases such as the architecture vision, statement of architecture work, architecture definition document, (preliminary) architecture requirements specification and a set of (preliminary) transition architectures. Many of these documents will be finalized in the current phase.
Following the TOGAF standard, the steps in this phase include confirming that other management and governance frameworks are aligned (i.e., project management, operations) to avoid surprises down the road; do a cost/benefit analysis based on expected business value of each of the transition architectures; prioritize; generate a time-lined roadmap and migration plan; and to establish the architecture evolution cycle as well as lessons learned. In this phase, close co-operation, buy-in, and direction from management are key in generating the desired migration plan.
The key deliverables of this phase are the implementation plan and architecture contracts for each of the proposed implementation projects. Such contract is a “joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture”. This deliverable closely resembles DYA’s “Project Start Architecture” (PSA). This document will be used in the next phase as a basis for governing and overseeing the implementation project.
In several projects at clients, we have found that maintaining a close relation between the enterprise architecture team and a project management office is a key aspect of being successful with architecture.
Traditionally when someone in the business has a great idea, a first step in achieving it is a project lead who manages the concretization of the idea into a solid implementation plan and its delivery. When adopting TOGAF’s ADM, a large part of this work is delegated to the architecture team. In order to structurally manage the relation, roles, responsibilities between the two bodies in an organization it is useful to create an architecture board. In the architecture board, key players from the business side (executive sponsors), architects, project managers and other stakeholders meet to jointly prioritize work packages. Usually such a board only approves (or calls for amendments of) plans that are prepared by the architecture team, but in some cases (i.e., large programs and key projects under high pressure), a workshop-based approach may be called for.
A second best practice in this respect pertains to document management. The TOGAF standard proposes to use an architecture repository to track and manage artefacts produced during/ used by the architecture team. However, since projects need a formal basis, in our experience it is best to let the project management office (PMO) handle management of documents that are formally signed off. The contract can then be managed together with documents and deliverables that are used by the project methodology of the organization.
Firstly, it shows that planning & prioritization is a joint activity between different roles, and is part of Phase E of TOGAFs ADM. This phase is modeled as a process step. Furthermore, the diagram also shows that the management of formal project documentation is a function that is used in phase E. (Execution of) this function is assigned to the project manager.
If you’d like to know more, please contact the author directly at firstname.lastname@example.org, or leave a comment.