13.1 BAI Build, Acquire, and Implement

Quick Answer: Build, Acquire and Implement (BAI) is the 11-objective management domain that turns a funded investment into a working change. BAI01 Managed Programs coordinates a selected investment. BAI11 Managed Projects — new in 2019 — delivers a defined work package; programs are not projects. BAI02 Managed Requirements Definition analyzes needs before buy or build. BAI03 Managed Solutions Identification and Build designs, sources, and constructs the solution. BAI04 Managed Availability and Capacity balances current and future performance against cost. BAI05 Managed Organizational Change prepares people and ways of working. BAI06 Managed IT Changes is IT-specific — COBIT 5’s broader Managed Changes title is retired. BAI07 Managed IT Change Acceptance and Transitioning formally accepts, converts, pilots, and transitions. BAI08 Managed Knowledge keeps validated knowledge available. BAI09 Managed Assets accounts for I&T assets through the life cycle. BAI10 Managed Configuration maintains descriptions and relationships of key service assets. APO05 Managed Portfolio still sits above this domain.

Governance and Management Objectives is 23% of the COBIT 2019 Foundation exam. Chapter 12 taught Align, Plan and Organize (APO). This chapter is the rest of the management catalog: BAI (build), DSS (run), and MEA (management monitoring). BAI is the largest of the three remaining domains. Memorize the 11 official titles. Do not invent a twelfth, do not drop BAI11, and do not let a project manager absorb the whole domain because “the project is late.”

Where BAI sits

Management’s verb set is plan, build, run, and monitor. BAI is the build domain. After APO05 Managed Portfolio selects an investment, someone still has to coordinate the program, define requirements, identify and build the solution, keep availability and capacity honest, move the organization, control IT changes, accept and transition, capture knowledge, account for assets, maintain configuration, and deliver the project work packages. Those jobs are BAI01 through BAI11.

BAI does not set strategy. It does not rank the enterprise portfolio. It does not run the service desk after go-live. If a stem is still arguing whether the claims engine deserves funding, you are in APO05. If the engine is already selected and Northline must now deliver it without wrecking adjusters, data, or uptime, you are in BAI.

The eleven official objectives

Learn those titles as three stacks plus a build chain, not as eleven isolated flashcards.

High-yield stack 1: APO05 versus BAI01 versus BAI11

Foundation items love to swap these three IDs. Write the stack from a blank page.

BAI11 Managed Projects is new in COBIT 2019. COBIT 5’s 37-process catalog did not give projects their own BAI ID. Candidates who still think “programs cover projects, so there is no BAI11” fail a clean recognition item. Candidates who treat BAI11 as a rename of BAI01 fail the other way. Programs ≠ projects. A program is the coordinated investment. A project is one work package inside it.

Northline’s digital-claims bet is one of twelve demanded initiatives. APO05 keeps the claims engine and defers telematics. BAI01 then runs the digital-claims program: mobile first-notice-of-loss, the vendor engine, adjuster reskilling, and data conversion as one outcome. BAI11 is the mobile-app work package — a start, a finish, a scope, a quality bar. The project manager does not silently become the portfolio manager.

BAI02 and BAI03: requirements before build

BAI02 Managed Requirements Definition sits before acquisition or creation. Official coverage is business processes, applications, information and data, infrastructure, and services. Stakeholders review feasible options, relative costs and benefits, and risk, then approve requirements and the proposed solution. A vendor demo that becomes the requirements document is a BAI02 failure, not “being agile.”

BAI03 Managed Solutions Identification and Build takes those approved requirements and establishes the solution: design, development, procurement or sourcing, and partnering. Build and buy both live here. BAI03 is not the portfolio decision (APO05) and not the vendor-ecosystem objective (APO10 Managed Vendors). APO10 selects and monitors vendors. BAI03 uses that relationship to identify and construct the actual solution.

Sequence matters. Requirements, then identification and build. Reverse them — start coding or signing, then write requirements to match what you already bought — and both objectives fail.

BAI04 Managed Availability and Capacity

BAI04 Managed Availability and Capacity balances current and future needs for availability, performance, and capacity with cost-effective service provision. It is a build-domain objective because capacity and availability have to be designed into the change, not discovered on the first Monday after go-live.

Northline cannot promise “claims in minutes” and size the engine for last year’s branch volume. BAI04 asks whether the target service can be available and fast enough at a cost the enterprise will actually pay. It is not DSS01 Managed Operations (running the shift) and not DSS04 Managed Continuity (surviving a disruption). Availability design is BAI04. Availability operations and continuity live in DSS.

High-yield stack 2: BAI05 versus BAI06 versus BAI07

This is the second stack you must be able to teach closed-book.

BAI06 Managed IT Changes is IT-specific. COBIT 5 used a broader Managed Changes title. COBIT 2019 narrowed the official name to Managed IT Changes. If a stem offers “BAI06 Managed Changes” as the 2019 title, that is a version leftover. Organizational and enterprisewide people change is BAI05, not a 2019 BAI06 job.

BAI05 is why a technically perfect engine still fails. If adjusters never adopt the workflow, the program did not deliver. BAI05 covers readiness, communication, training, and sustainable new behavior — the complete life cycle of the organizational change, not the ticket that released the binary.

BAI07 Managed IT Change Acceptance and Transitioning is the handoff. Implementation planning, system and data conversion, acceptance testing, piloting, going operational, and looking back after implementation all sit here. A team that “deploys” on Friday with no conversion rehearsal, no acceptance record, and no post-implementation review skipped BAI07. They may have done a BAI06 release. They did not transition.

Do not collapse the three. A people rewrite is BAI05. A controlled IT release is BAI06. Making the new solution formally operational is BAI07.

BAI08 Managed Knowledge

BAI08 Managed Knowledge maintains relevant, current, validated, and reliable knowledge so process activities and decisions have something better than hallway memory. Knowledge here is not a wiki nobody trusts. It is the validated residue of programs, projects, incidents, and designs — what the engine actually does, how conversion was run, which workarounds are approved.

If Northline’s second squad repeats the first squad’s conversion mistake because nobody captured the lesson, BAI08 is missing. BAI08 is not APO07 Managed Human Resources (acquiring and developing people) and not APO14 Managed Data (data assets through their life cycle). People, data, and knowledge are three different official objects.

High-yield stack 3: BAI09 versus BAI10

BAI09 Managed Assets is life-cycle accountability: acquire, maintain, account, protect, retire. Value at optimal cost is the official idea — not cheapest, not hoarding. BAI10 Managed Configuration is the map of service assets and their relationships so incidents and changes can be assessed. A complete asset register with no relationship map is BAI09 without BAI10. A configuration management database that cannot tell you whether a server is still an owned, protected asset is BAI10 without BAI09. The exam will offer both titles as distractors for each other. Keep the object different: thing you own versus description of how things connect.

BAI10 is also how BAI06 stays honest. You cannot assess the impact of an IT change if configuration is folklore.

Scenario: Northline builds the claims engine

Watch the IDs, in order, around one investment.

1. APO05 already selected the engine. That was planning, not BAI.
2. BAI01 opens the digital-claims program and coordinates mobile, engine, data, and organizational work as one outcome.
3. BAI02 writes requirements across process, application, data, infrastructure, and service — “straight-through simple claims” is specified before the vendor’s demo becomes the spec.
4. BAI03 identifies and builds: configure the engine, integrate the mobile channel, source the remaining components.
5. BAI04 sizes availability and capacity for mobile-volume Mondays, not branch-volume Tuesdays.
6. BAI05 moves adjusters and team leads onto the new workflow; resistance is treated as a delivery risk, not a communications inconvenience.
7. BAI06 puts engine releases and emergency patches through controlled IT change, not Friday-night heroics.
8. BAI07 converts history, runs acceptance, pilots one region, cuts over, and holds a post-implementation review.
9. BAI08 captures conversion lessons and the approved workaround list so the next region does not relearn them.
10. BAI09 accounts for licenses, scanners, and retired desktops through the life cycle.
11. BAI10 baselines which services depend on which engine components before the next BAI06 change.
12. BAI11 delivers the mobile-app work package inside the BAI01 program — a project, not the program, and not the portfolio.

If the project manager does all twelve “because go-live is Tuesday,” Northline has collapsed BAI — and leftover APO work — into one hero. The Foundation exam will not reward that collapse.

Exam traps

• Portfolio = program = project. APO05 / BAI01 / BAI11 are three altitudes. BAI11 is new in 2019.
• BAI06 Managed Changes. Wrong 2019 title. Official name is Managed IT Changes; organizational change is BAI05.
• BAI05 = BAI06 = BAI07. People versus IT change versus acceptance and transition.
• BAI09 = BAI10. Life-cycle assets versus configuration descriptions and relationships.
• Starting BAI03 before BAI02. Requirements before identification and build.
• Calling BAI a governance domain. BAI is management. Only EDM is governance.
• Letting BAI11 absorb BAI01. Programs coordinate; projects deliver packages.

Prefer the answer that keeps all 11 official titles, keeps BAI11 as the 2019 project objective, keeps BAI06 IT-specific, and keeps the three stacks intact.