16.2 Benefits, Costs, Risk, and Tracking

Quick Answer: Benefits in an EGIT business case must be specific and measurable — fewer audit findings, a faster change cycle, reduced unplanned downtime, a clearer risk appetite, avoided regulatory fines — and tied to enterprise or alignment goals. Costs include people, tools, training, assurance, and opportunity cost, not just software. The program carries its own risk: change fatigue, vendor lock-in, and theater without behavior change. Tracking continues after go-live through implementation Phase 6 (Did we get there?) and Phase 7 (How do we keep the momentum going?). EDM02 Ensured Benefits Delivery is the board loop; MEA01 Managed Performance and Conformance Monitoring is the management measurement work. Do not invent ROI percentages. “Better governance” alone is not a benefit.

The last section put a formal case in front of the board. This section is the part of the case that Foundation items actually poke: can you tell a benefit from a slogan, a cost from a license line, a program risk from an enterprise risk register, and tracking from a go-live party?

Still 3% of the exam. Still roughly two items. Still cheap if the numbers you quote are the ones the enterprise can count, and expensive if you recite a vendor ROI or stop measuring when the policies are published.

Benefits must be specific, measurable, and cascaded

A benefit is a change in an outcome the enterprise already cares about. It is not a feeling about governance. It is not the fact that a framework name now appears in the annual report.

ISACA does not publish a universal EGIT ROI percentage. Do not invent one. Do not memorize a vendor slide that claims a three-digit return. The Foundation exam is not testing arithmetic on a fictional 347%. It is testing whether you can name benefits a board can monitor.

Good benefit language looks like this:

Each row should trace back through the goals cascade: stakeholder need → enterprise goal → alignment goal → the governance or management objective you are actually funding. Aether’s board does not buy “better governance.” It buys fewer examination findings after an acquisition, a single measured change path that product teams will use, downtime hours on the payments rail, and decisions that cite one appetite instead of three hallway versions.

Exam trap: listing only qualitative “better governance” as a benefit. “World-class IT,” “a culture of excellence,” and “improved alignment” are slogans until they inherit a measure and a goal. You may use qualitative language to explain a measure. You may not replace the measure with the slogan.

Costs are more than software

COBIT is a framework. There is no official “COBIT installer.” A case that lists only a software license has described a tool purchase, not an EGIT program.

Count at least these cost types:

• People. Sponsor time, process owners, workshop facilitators, control and risk analysts, product-team representatives who must leave feature work to design decision rights. Board time is a cost.
• Tools. A GRC platform, CMDB, or monitoring stack only if the design actually needs it. Tools are optional servants of components. They are not the system.
• Training. Role-based awareness, Foundation-level literacy for people who must operate the system, coaching for the sponsor. One certificate on the CIO’s wall is not a training plan.
• Assurance. Independent check that the program is doing what the case promised — MEA04 Managed Assurance plans those initiatives. Assurance is a cost of honest tracking, not an insult to the program team.
• Opportunity cost. Every week Aether’s best engineers spend in a RACI workshop is a week they are not shipping payments features. Every quarter Northline’s plant supervisors spend rewriting procedures is a quarter they are not attacking unit cost. If the case hides opportunity cost, it is lying about resource optimization (EDM04 Ensured Resource Optimization).

Minimal-looking programs often hide the real bill in unpaid overtime and deferred product work. Tailored programs look more expensive on paper because they tell the truth.

Risk of the EGIT program itself

The case already exists because the enterprise has I&T-related risk. That is EDM03 Ensured Risk Optimization altitude. This heading is different: risk of the EGIT improvement program. Funding the program creates new ways to fail.

Foundation-level program risks you should be able to name:

• Change fatigue. Aether just absorbed an acquisition. Another “transformation” on top of two change processes can produce compliance on paper and workarounds in the product teams. BAI05 Managed Organizational Change is not optional decoration.
• Vendor lock-in. A consultancy or a GRC vendor becomes the system. When the contract ends, the “governance” leaves with the contractors. The case should say what the enterprise will own.
• Theater without behavior change. Policies published, RACIs printed, a steering committee that meets to admire slides, and the same downtime, the same findings, the same unofficial appetite. Theater is the program-risk version of “we implemented COBIT.”
• Scope creep to all 40. The tailored design is abandoned because someone wants a complete-looking heatmap. Resources dilute. Nothing reaches a useful capability.
• Sponsor disappearance. The CIO who asked for budget leaves; no executive still owns EDM02 monitoring.
• Design treated as finished forever. The dynamic principle says a design-factor change forces EGIT review. A case that funds a one-time project and no maintenance fails EDM01 Ensured Governance Framework Setting and Maintenance on purpose.

These risks need treatments in the case: a real sponsor, a scoped design, a change plan, exit ramps, and success measures that cannot be satisfied by publishing documents.

Tracking continues after go-live — Phase 6 and Phase 7

Approval of the case is not a benefit. Publication of policies is not a benefit. Go-live of a committee is not a benefit.

Implementation Phase 6 — Did we get there? compares outcomes to the case. Did findings fall? Did change lead time move? Did downtime hours move? Is appetite used? If not, the enterprise did not “get there,” no matter how complete the binder looks.

Implementation Phase 7 — How do we keep the momentum going? is the refusal to treat EGIT as a project that ends. Benefits leak. Sponsors rotate. Design factors change. Tracking is how momentum stays honest.

Two official objectives carry the tracking load:

MEA01 is the measurement work. It is not a fifth governance domain. It feeds EDM02. It does not replace EDM02. Optimize is EDM02’s verb. Shipping more artifacts at a loss of value is an EDM02 miss, not a badge of delivery throughput.

Baseline before you change anything. If Aether never counted repeat findings or downtime hours, Phase 6 will become a storytelling contest. Success measures in the case are the contract MEA01 will report against and EDM02 will judge.

If benefits do not appear, the honest EDM02 move is to change the program or stop it — not to declare victory because Phase 5 produced documents.

Scenario: Aether reports that COBIT is “implemented”

Two quarters later Aether’s CIO returns. “COBIT is implemented. We published twelve policies, stood up an I&T committee, and trained sixty people. We should close the program.” Unplanned downtime on the payments rail is unchanged. Repeat access-recertification findings are unchanged. Product teams still ship around the committee. No decision packet this quarter cited the written risk appetite. There is no MEA01 report against the case measures — only a slide titled “activities completed.”

That is theater. Phase 6 would fail the case. The board, using EDM02 Ensured Benefits Delivery, should not accept “we implemented COBIT” as a benefit. Management still owes MEA01 evidence. The program risks named in the case — fatigue, lock-in if a vendor wrote every policy, theater — have materialized.

A repaired Phase 6 pack would show the baseline and the current counts, explain which design-factor-scoped objectives moved, name residual program risk, and ask the board to continue, retarget, or stop. That is tracking. A completion certificate is not.

Northline would fail the same way with different numbers. If the manufacturer’s case promised fewer hours of unplanned line-stopping downtime and a shorter emergency-change tail, a new policy binder with no movement in those counts is not Phase 6 success either. The measures follow the enterprise goals. The rule does not.

Exam traps for benefits, costs, risk, and tracking

• Listing only qualitative “better governance” (or “world-class IT,” “excellence”) as the benefit.
• Inventing an official ROI percentage. ISACA does not publish one for Foundation to memorize.
• Treating software as the only cost; omitting people, training, assurance, and opportunity cost.
• Stopping measurement at go-live or at policy publication.
• Calling Phase 6 and Phase 7 optional because “the project shipped.”
• Collapsing EDM02 into MEA01. The board owns benefits delivery. Management owns performance and conformance monitoring. Both are required. They are not the same objective.
• Treating a completed activity list as Phase 6 success.

Prefer the answer that demands measurable benefits tied to enterprise or alignment goals, a full cost picture, program risk that includes theater, and tracking after go-live through Phase 6 and Phase 7, judged by EDM02 and measured by MEA01.