Enterprise Architecture for the PMO and Transformation Office
A transformation office follows several initiatives at once. Enterprise architecture places them on the capability map, makes their dependencies visible and keeps the decisions that changed the plan.
Updated on
A portfolio of initiatives to arbitrate
A transformation office answers for the outcomes of several initiatives at once. Two programmes touch the same applications, a third assumes a capability nobody owns, and the dependency surfaces at the first delay. The PMO needs a shared frame above individual projects.
Initiatives against capabilities
The business capability map serves as a shared backbone. Each initiative is placed on the capabilities it creates or changes. The portfolio then shows which capabilities receive investment, where several projects overlap and which strategic areas have no initiative.
Double funding, hidden dependencies and coverage gaps are spotted this way before budgets are committed.
- Place each initiative on the capabilities it changes.
- Spot overlaps, contention for the same application and coverage gaps.
- Base portfolio reviews on these findings to set priorities.
Capability-based planning
A project list follows the current organisation chart and tools; it ages with every reorganisation. Capabilities describe what the organisation must be able to do, whichever team or application delivers it. A plan built on them stays readable after a reorganisation.
The PMO can then answer sponsors’ questions: where to invest, in what order and with which dependencies. In ArchiLU, requests and projects take their place in a shared roadmap, with their objectives and the capabilities concerned.
A sequenced roadmap
A roadmap holds when it respects dependencies. When initiatives, capabilities and applications live in the same model, the team can show why initiative B waits for initiative A and what a delay causes downstream.
In ArchiLU, each landscape carries the current state, the target and a dated roadmap. The gap gives each element its work package and due date, and the 360 view shows the scope as of the chosen date. If the horizon of an approved target passes without confirmation that it was delivered, the owner of each affected object receives a task.
Transformation decisions
A programme accumulates decisions: scope changes, trade-offs, deferred work. Without a record, the question “why did we decide this?” goes unanswered when the team changes.
In ArchiLU, the decision log keeps each decision with its body, its decision maker, its date, its outcome and its reason. The architecture review then confirms what was delivered before the current state is updated. An incoming programme lead finds these reasons together with the document that was examined.
The project tool and the architecture repository
The project management tool tracks tasks, resources, budgets and status. The architecture repository describes what the portfolio changes and why. Selected Jira tickets can feed the sources of an architecture document, with their link and date.
Frequently asked questions
- How does enterprise architecture help a PMO or transformation office?
- It places initiatives on the capability map. The PMO sees the capabilities each initiative touches, the overlaps and the gaps in the roadmap, and bases its trade-offs on these findings.
- What is capability-based planning, in practice?
- Planning the transformation from capabilities, meaning what the organisation must be able to do. Organisation charts and applications change more often than capabilities; a plan built on them stays readable after a reorganisation.
- Does enterprise architecture replace our project management tool?
- No. The project tool runs delivery: tasks, resources, budgets and status. The architecture repository describes capabilities, the roadmap and decisions; in ArchiLU, the gap gives each element its work package and due date.