Set One Integration Boundary

Before you sign, or at the latest before integration planning begins, write why the deal should happen and how the integration could destroy the value you are buying, then weigh the consequences of each item before deciding. They are a step, not a form; the matrix records what they decide.

One consequential capability at a time: what must be common, what can stay local, and who resolves a joint choice when the two sides disagree, with the reason recorded. Test the boundary on a real handoff before extending it. A preference for the parent's software is not evidence that migration creates value.

Write a unit's local decisions as an Authority Grant for that unit, using the fields in Module 8, and keep it with the matrix in one record: its outcome, the decisions it keeps without central approval, its shared obligations, and its escalation path. The matrix holds what must be common; the grant holds what stays local.

Two-sided by design: what the acquired business must adopt and what the parent must provide, remove, or learn, with owners on both sides.

The Hero-to-Multiplier Map from Module 5 applied to the business being integrated. The responsible manager holds it; the shared record shows only the capability and whether a backup can perform it, never a person listed as a risk. Give the current holder a role in leading the transfer, and make clear what they can grow into as their knowledge spreads and who has the authority to honor that promise.

Copy this record for one initiative. Use role titles while designing the plan, then name the actual people before making a live commitment. Link to detail only where it supports a decision. Leave irrelevant fields out. If an answer is unknown, or the owner and sponsor give different answers, name who will resolve it and by when. Start with one recurring problem so the team can test the whole arrangement before expanding it; the book's illustrative locked-accounts record in Chapter 5 shows one filled in.

Decision check. Before closing, confirm: decision and reason; authorized owner; next commitment; due date; evidence and receiving person. If a gap remains, record its exact question, decider, evidence owner, and return date.

Module 7 deepens the Outcomes line and Module 8 the Ownership line. Every other tool writes into this same record, and the 90-Day Install follows it.

Before holding someone accountable, ask them to explain the decisions they can make without further permission, and compare their answer with the sponsor's using one blocked dependency or contested choice. Close any gap in writing and confirm it with affected teams. The grant has five elements, plus the header and the backing: the header names the outcome and the accountable owner; the five elements are the decisions delegated, budget and staffing authority, tradeoff authority over competing priorities, standards and constraints, and an escalation path with a response deadline; the backing names the sponsor who announces it, where affected teams can see it, and the review date. If the sponsor lacks the authority, name who can grant it and the decision deadline. If that authority will not be granted, record what the current arrangement can and cannot deliver. One owner does not mean one person does all the work. It means someone can coordinate dependencies and obtain a binding decision when authority runs out.

The grant for a unit. The same grant serves a local business, division, or region. Write it for the unit as you would for one owner: the local outcome, the decisions it keeps without central approval, the shared obligations it must meet, its resource boundaries, its dependencies on the parent, the escalation path, and the conditions for revisiting the arrangement. The Backbone and Autonomy Matrix in Module 10 holds what must be common; this grant holds what stays local. Keep the two in one record.