[Daniel]

How deep should the master PMI Playbook go when defining the integration of business functions (e.g. IT, HR, Finance etc)?
By that I mean the core Playbook owned and maintained by Integration Management Office.

Its a topic we have struggled with because if we try to proceduralise and predefine too much centrally then I believe it takes away the onus on the respective business functions to determine the scope and come up with their integration plans. If you give them checklists and draft plans I believe they will often take that as the scope rather than them diving deep enough to determine what actually needs to be done.

However if you don’t give them a concrete starting point then you risk the scope not being complete or aligned with other workstreams, it is inefficient and may not build on the knowledge of previous integrations. If you also leave it to the business functions to create and maintain their own playbooks then this never seems to happen based on our experience.

We have taken an approach of defining a superset or baseline list of outcomes and definition of done for each functional area and will supply previous example plans but ask them to submit a new plan based on a common template.

I am interested in how others tackle this? Do you maintain playbooks per function and if so how far do you go?

[Lindsey Edson]

I think the tension you’re describing is exactly the right one—IMO playbooks can either become a “crutch” that limits thinking or be too loose to provide any real consistency.

In my experience, the most effective approach is very similar to what you’ve already landed on: a hybrid model that separates “non-negotiable standards” from “context-specific design.”

Where it can become counterproductive is when it goes too far into detailed functional “how-to” plans, because teams then default to the template as the full scope rather than critically assessing what their specific deal actually requires.

We’ve taken a similar approach to what you described—using a baseline superset of outcomes, a common template for each function, and prior examples for reference. We also built out project templates in Smartsheet to standardize tracking and ensure all workstreams are aligned in terms of milestones, dependencies, and reporting structure.

[Author]

Posts