17.1 Implementation Lifecycle Overview

Quick Answer: COBIT 2019 implementation is a seven-phase continual-improvement lifecycle, not a one-time project and not COBIT software you install. The home publication is the COBIT 2019 Implementation Guide. Programmes are triggered by pain points and trigger events — mergers, regulatory shock, a major outage, a new CIO, a digital strategy, or audit findings. The exam trap is implementation without design, or treating the lifecycle as “stand up COBIT” by launching a project before anyone has decided which objectives matter.

Implementation is 8% of the 75-question COBIT 2019 Foundation exam — roughly six items. Those items are cheap if you remember three ideas: it is a cycle, it is started by pain and triggers, and it is not software. They are expensive if you treat COBIT as a product you deploy, a binder you deliver, or a seven-step project that ends when the first change goes live.

This section is the map. The next section teaches each official question in order. Then come roles, pain points, and challenges. The last section locks the Design Guide to the Implementation Guide and closes the study path. Do not skip the map. Every later trap — swapping phase 2 with phase 3, stopping at phase 5, handing EGIT to audit, boiling the ocean — is a failure of this concept.

A lifecycle, not a project close-out

ISACA did not publish a “go-live weekend” for COBIT. The Implementation Guide describes a continual improvement lifecycle. The seven phases are usually drawn as a cycle: when phase 7 asks how to keep the momentum going, the answer feeds the next pass through phase 1. New pain appears. A new trigger arrives. Design factors shift. The enterprise goes around again.

That is why “we implemented COBIT last year” is a suspicious sentence on the exam and in real life. You can close a programme increment. You do not close EGIT. A one-time project that produces a binder, a kickoff, and a “complete” stamp has confused delivery of documents with governance of I&T.

Keep the companion books in their lanes from the first paragraph:

• The Design Guide answers what the tailored system should look like — prioritized objectives and target capability.
• The Implementation Guide answers how to move from the current system to that target through the seven phases.
• Introduction and Methodology introduces the idea that implementation exists.
• Governance and Management Objectives is the 40-objective core model you are implementing a profile of, not a substitute for the lifecycle.

Implementation without design is motion. Design without implementation is a binder. Foundation will punish the first failure more often, because energetic programmes love to “show progress this quarter” by opening the Implementation Guide before anyone has used design factors.

What starts the cycle: pain points and trigger events

A lifecycle does not begin because a consultant booked a kickoff. It begins because something already hurts, or because an event opens a window in which change is suddenly possible. ISACA groups those starts as pain points and trigger events. Memorize both labels. They are not synonyms.

Pain points are current dissatisfaction. The enterprise already feels them. Failed projects, recurring outages, audit findings that never close, IT cost that the board cannot explain, shadow SaaS, and a standing argument between the plant and the CIO shop are pain. Pain can smolder for years. It creates the case for change, but it does not always create the window.

Trigger events are discrete events that open that window. A merger, a regulatory shock, a major outage that reaches the board, a new CIO or CEO, a published digital strategy, an IPO, or a hard audit finding that the chair will not ignore are triggers. Triggers create urgency and air cover. They do not, by themselves, tell you which of the 40 objectives to raise.

Northline’s pain is aging plant systems, project overruns, and a unit-cost story the board no longer believes. Its trigger might be a new plant manager plus a near-miss outage that stopped a line for a shift. Aether’s pain is shadow SaaS, release collisions, and post-acquisition data that nobody will sign. Its trigger might be a completed bank acquisition plus a supervisory letter. Both enterprises have reasons to start. Neither reason is “install COBIT.”

A stem that says “we should wait until next year’s budget to start, because nothing hurt this quarter and no event occurred” is missing both starts. A stem that says “a merger happened, so implement all 40 objectives this quarter” has a trigger and still has no design.

High-level map of the seven phases

The official phase titles are questions. Learn them as questions, in this order. The next section teaches the work under each one. This section only needs the map.

1. What are the drivers? — Recognize why change is needed now; gather pain and triggers; start the programme and the case for sponsorship.
2. Where are we now? — Recognize the current state: issues, capability, and the honest as-is.
3. Where do we want to be? — Define the target, including capability targets from design, and the roadmap toward that target.
4. What needs to be done? — Translate the gap into a planned set of improvements. Prioritize. Do not boil the ocean.
5. How do we get there? — Execute the plan. Change work, not just documents.
6. Did we get there? — Review benefits. Compare outcomes to the target, not to the volume of deliverables.
7. How do we keep the momentum going? — Embed continual improvement so the cycle does not die when the PMO closes the increment.

Read that list twice. Phase 2 is current. Phase 3 is target. Phase 5 is execution. Phase 6 is benefits. Phase 7 is sustain. Candidates who memorize only “there are seven phases” and then invent the order will miss cheap items.

The seven questions are not the four-step design workflow. Do not merge “understand / initial / refine / conclude” into this list. Design produces the target the lifecycle aims at. Implementation walks the enterprise there and then around again.

Implementation without design is a common failure

Picture two kickoffs.

In the first, Aether’s CISO wants a security programme started this quarter. A programme manager opens the Implementation Guide, names a seven-phase project, and starts executing “COBIT” before anyone has used design factors. Security work may be needed. The failure is that nobody has decided which objectives are in the designed system, at what target capability, or how security sits with data, vendors, and change. Urgency became a side project that bypasses EGIT.

In the second, the same urgency is treated as a trigger plus a threat-and-compliance design input. Design concludes a profile that raises APO13 Managed Security, DSS05 Managed Security Services, and the related data and vendor objectives, with explicit capability targets. Implementation then uses those targets as “where do we want to be?” That is a programme. The first kickoff is motion.

Northline’s plant manager wants to “just implement ITIL and COBIT” on the shop-floor tools and call governance done. That is implementation without design, plus a category error about what COBIT is. Northline still needs a designed profile — heavier on operations, assets, and cost — and then a lifecycle. It does not need a generic 40-row binder.

The exam loves this failure because it looks like diligence. Seven phases sound mature. Without a design they are seven phases of the wrong work.

Exam trap: “install COBIT software”

COBIT is a governance and management framework. It is not a software product, not an appliance, and not a module you license and install. There is no official “COBIT server.” Tools can support components — a GRC platform, a CMDB, a risk register — but installing a tool is not implementing COBIT.

Wrong instincts:

• “Implementation means we bought the COBIT tool and turned it on.”
• “The seven phases are a project plan for a software rollout.”
• “When the vendor’s implementation partner leaves, COBIT is live.”
• “The Implementation Guide replaces the Design Guide, so we can skip tailoring.”
• “A one-time project that ends at go-live is a successful implementation.”

Right instincts:

• Implementation is a continual-improvement lifecycle of seven official questions.
• It lives in the Implementation Guide.
• It is triggered by pain points and trigger events.
• It needs a designed target — prioritized objectives and capability — before the phases have somewhere to go.
• It changes how the enterprise evaluates, directs, and monitors I&T, and how management runs the 40-objective profile. Software may help. Software is not the thing.

If a stem offers a programme that “implements COBIT” by installing a platform and closing the project, reject it. If it offers a sponsored lifecycle that starts from pain and triggers, aims at a designed target, and keeps circling, take it.