When a program leader brings in a consulting firm, the instinct is to start planning: workshops, strategy sessions, whiteboards covered in workstream structures. Intake asks the team to stop and start with what already exists before building anything new; it asks the program leader to hand over charters, roadmaps, governance documents, data dictionaries, migration specifications, and meeting notes so the consulting team can read them, organize them, and reflect the current state back in a structured format. The program leader would rather start building the plan; the consultants would rather start facilitating sessions. Intake is the step that makes everything after it more accurate and more honest. The book devotes an entire chapter to it because it’s the one most likely to be rushed or skipped, and the one whose absence creates the most problems downstream.
Intake Builds the Baseline
Intake is a compilation exercise, not a discovery phase. The consulting team reads what exists and organizes it; the output is a structured baseline showing where artifacts contradict each other and where pieces are missing. Charters that do not answer operational questions. A charter that says the program is “enterprise-wide digital transformation” describes an aspiration. Intake identifies whether existing charters define boundaries and name dependencies with measurable success criteria. Roadmaps that are presentation artifacts rather than planning tools. A color-coded Gantt chart in a slide deck is a presentation tool. A roadmap maps dependencies between workstreams, sequences milestones against capacity constraints, and identifies decision points that gate downstream work. Intake distinguishes between the two. Governance structures that generate meetings rather than decisions. Intake reviews the existing model for decision rights: who can make what decisions, and what the escalation path is. Organizations that have a governance structure on paper but cannot point to a recent decision made through it have a meeting cadence, not governance. Dependencies that exist in people’s heads. Every program has cross-workstream dependencies. In most organizations, those dependencies are understood informally by the people who manage them and invisible to everyone else. Intake compiles what’s documented and makes the gaps visible. The baseline it produces becomes the landscape brief the board needs.
The Room’s Willingness to Engage
The client and her team built those charters and roadmaps; they know the documents are imperfect. Bringing in an outside firm to review that work carries an implicit judgment. This is why we frame intake as documentation rather than diagnosis. The consulting team compiles what exists into a structured format, and the gaps become visible through the structure itself. The Workstream Hierarchy, the primary intake artifact, organizes the program’s existing work into a clean structure: workstreams and sub-workstreams with the relationships between them. The client can see what her team built, organized in a way that makes both strengths and gaps visible; the structure does the work without requiring a findings presentation. This design choice matters. The room’s willingness to engage honestly for the next eleven weeks depends on how the first week feels. If the first week feels like an audit, the team shifts into defensive mode. If it feels like the firm took the team’s work seriously and built on it, the team collaborates rather than complies.
What Happens When Intake Gets Compressed
Programs that compress intake (i.e., spending a half day instead of a full week) build the rest of the engagement on an incomplete foundation:
- Dependencies and contradictions surface mid-engagement instead of week one. During roadmap sessions, someone says “we cannot sequence that milestone before Data Engineering completes validation testing” and the room discovers a dependency that intake would have caught. One workstream’s charter defines a scope boundary that overlaps with another’s, and the overlap becomes visible only when both workstreams are executing and discover they’re building the same thing.
- The team loses ownership. When consultants skip intake and start from scratch, the client’s team watches their prior work get set aside. The consultants build new artifacts using their own frameworks. The output may be technically stronger, but the team does not feel ownership because it wasn’t built on what they contributed. The plan becomes the consultant’s plan, and the likelihood the team maintains it after the engagement ends drops.
The structured baseline feeds directly into every subsequent step. Stakeholder mapping uses it to identify influence and decision authority; program architecture uses it to build the Workstream Hierarchy and the pre-mortem uses it to identify untested assumptions. Programs that invest in building this baseline properly spend less time in every subsequent session correcting misunderstandings and reconciling artifacts that were never compared.
