Turning a decision into a model
Once an organisation has made the Build / Buy / Hybrid decision, the natural instinct is to mobilise. Get on with it. Start the procurement. Start the recruitment. We can sort the detail as we go.
This is the most expensive instinct in the methodology, and the one that I see most often in low-maturity owner organisations. The gap between making a decision and being able to mobilise against it is bridged by a Design stage, and skipping it is the single most reliable way I know of creating a programme that fails in its first eighteen months.
Design is documentary. Its outputs are written, controlled, and approved by the sponsor and board before mobilisation begins. That sounds bureaucratic. It is the opposite. Design is where the most expensive decisions are surfaced inexpensively. A design choice that looks reasonable on paper but fails on examination can be revised at low cost during Design. The same flaw discovered after mobilisation costs orders of magnitude more to correct.
What gets designed, and what depends on the path
Some design elements apply regardless of which path was chosen. The operating model itself, the intelligent client function, the sponsor role, the governance architecture, and the relationships between the programme function and adjacent organisational functions are designed first. They shape and constrain everything that comes after them, on any path.
Other elements vary materially by path. Build requires detailed design of the internal function: roles, recruitment, tooling, processes. Buy requires detailed design of the procurement and contractual architecture. Hybrid requires both, plus the sequencing and transition mechanisms that connect them. The depth and emphasis differ, but full design always covers all the universal elements before going path-specific.
The intelligent client function
If you read only one section of this chapter, read this one. The intelligent client function is the single most important cross-cutting element of the design, and the one most often under-specified.
The intelligent client function is the internal capability that holds the organisation’s accountability for outcomes, regardless of whether delivery is internal or external. In a Build path it sits within the wider PM function as the client-side discipline. In a Buy path it is the organisation’s primary engagement with the delivery partner. In a Hybrid path it bridges both modes and is the durable capability that survives any transition between them.
It comprises a credible senior sponsor with a real mandate and real time; commercial and contractual literacy proportionate to the programme’s scale; the capability to interrogate performance data rigorously rather than accept it at face value; the technical literacy to challenge a partner’s technical judgement; clear escalation routes both upward to the board and downward to delivery; and a board-level governance capability that knows the difference between a programme decision and an operational one.
The most common Design-stage error in this area is to under-specify the intelligent client function on a Build path, on the assumption that internal delivery means the function is not needed. That is wrong. Even internal delivery requires an internal client that is distinct from the internal delivery team, because accountability for what is being built must sit separately from accountability for how it is built. Functions that conflate these accountabilities cannot effectively challenge their own delivery teams. The intelligent client is independent of the delivery model. Skipping it because you have chosen Build is the equivalent of removing your own audit function because you trust yourself.
Build-path design
Build-path design is the most extensive of the three paths because every element of the function must be specified internally rather than transferred from a delivery partner’s existing capability. It produces a target operating model with reporting lines, scope boundaries with adjacent functions (engineering, procurement, operations), and the relationship between permanent and project-specific roles.
Each role in that architecture gets a role specification covering purpose, accountabilities, authorities, key relationships, competence and experience requirements, and performance measures. The specifications are written before recruitment begins, not derived after the fact from successful candidates. Organisations that recruit first and write specifications later find themselves with role definitions shaped by available people rather than by required capability.
The recruitment strategy sequences hires over the build timeline and addresses what to do when the right person is not available at the right time — interim cover, deferred mobilisation of dependent roles, or scope adjustment. Designing for these contingencies in advance prevents the most common recruitment failure: accepting an inadequate candidate because the post cannot wait.
The process framework adopts or adapts a recognised methodology (APM, MSP, sector-specific equivalent) and produces a controlled document set — governance manual, reporting standards, change control, risk management, lessons-learned protocol. A design principle worth holding onto: sufficiency, not comprehensiveness. Frameworks designed to cover every conceivable scenario are too heavy to operate. A framework that is 70 per cent complete and being used is more valuable than one that is 100 per cent complete and waiting for the perfect deployment moment.
Alongside the framework sit the tooling architecture (an integrated set of scheduling, cost, document control, and reporting tools — selected for the requirements of the operating model, not for vendor relationships) and the training and culture plan (accreditation targets per role, mentoring arrangements, and the cultural behaviours that distinguish a functioning PM function from a procedural one). Culture is treated as a deliberate design output rather than as something that will emerge from the function over time. The behaviours that need to exist are described explicitly and supported by appropriate management responses when they occur.
Buy-path design
Buy-path design is less dependent on internal structure than Build, but considerably more demanding on commercial and contractual rigour, because the contract becomes the primary mechanism by which the programme is controlled.
The procurement strategy is written before the procurement notice issues, not in parallel with it. It defines market analysis, evaluation criteria — where quality weighting is significantly above price weighting, typically 70:30 or higher — contractual route, timeline, and pre-procurement engagement plan. Pre-procurement engagement is a discrete deliverable, not a marketing exercise: its purpose is to test scope, terms, and market interest, and to refine the procurement before formal launch.
The partner evaluation framework defines scoring criteria, evidence requirements, due-diligence protocols, and the moderation process for evaluator scoring. Due diligence specifically extends to the named individuals proposed by a firm, not just the firms they work for. Major programmes are delivered by people, not by organisations. Reference verification uses individuals identified by the evaluator from prior engagements, not nominated referees. The procurement legal team is engaged early to confirm the evaluation approach is defensible.
Contract design selects the form (NEC4 Professional Services Contract, FIDIC, bespoke), defines scope by reference to the operating model and Project Execution Plan, establishes the performance regime, names key personnel with client-approval rights, and writes knowledge transfer as contractual deliverables rather than aspirations. Termination grounds and transition obligations on exit are defined explicitly. The design avoids the most common Buy-path error: a contract that defines activity rather than outcome. Activity-based contracts incentivise the partner to be present rather than to deliver.
The performance regime distinguishes leading indicators (early warnings of future performance) from lagging indicators (record of past performance) and weights leading indicators appropriately. A regime composed entirely of lagging indicators arrives at the right diagnosis too late to act on it. Knowledge transfer is designed as a contractual deliverable with defined outputs and acceptance criteria; programme closure is conditional on knowledge transfer completion, not just on delivery completion. Without that conditionality, knowledge transfer is the deliverable most readily descoped under cost pressure.
And exit and transition planning is done at the start, when the relationship is most cooperative, not later under deteriorating conditions. Designing exit at the start is materially easier than designing it when something has already gone wrong.
Hybrid-path design
Hybrid is the most demanding to design because it combines elements of both Build and Buy, requires explicit sequencing between them, and includes transition mechanisms that allow the organisation to move from one mode to the other over time.
The sequencing model defines what is procured externally, what is built internally, in what order, and against what triggers. The default sequencing: build the intelligent client function first; procure external programme leadership second; build the internal nucleus alongside; and transition to internal leadership at a defined gate. The model is documented as a timeline with named decision points, not as a general intention. Without named decision points, sequencing drifts under operational pressure and the design’s careful structure dissolves into reactive choices.
The embedded staffing model defines which internal staff are embedded within the external partner’s team, in which roles, with what development objectives, and over what period. Embedded staffing is the primary mechanism by which capability transfers in a Hybrid path. It must be designed deliberately at the outset, with named individuals where possible at the design stage. Designing for unspecified staff produces unspecified results.
Beyond contractual knowledge transfer, Hybrid design includes mechanisms specific to the planned transition: structured coaching between external and embedded staff, deliberate practice opportunities for embedded staff, and progressive handover of specific responsibilities as embedded staff develop. Each mechanism is a designed activity with defined inputs, expected outcomes, and review cadence. Proximity alone is not transfer, and osmosis is rarely an effective transfer methodology.
Capability growth milestones are explicit, aligned to programme gateways where possible. At each milestone an independent assessment confirms whether the planned capability development has occurred. The milestones are gates, not commentary — failure to meet them triggers a design response, not a tolerance.
And the transition triggers are decided in advance. What is to be decided at the trigger point is the application of the trigger, not whether the trigger should exist. Triggers that can be renegotiated at the point of decision are not triggers. This is the discipline that prevents “we’ll move internal in a couple of years” from becoming permanent external dependency that nobody planned but everybody accepts.
One last point on Hybrid worth flagging: it is entirely possible for an organisation to remain within the Hybrid model over extended timescales. Some organisations should. The target is the capability to operate across the broad spectrum of the model rather than the assumption of eventual full transition to Build.
What Design produces
Each output is a controlled document subject to change control from the point of approval onward. The universal outputs across all paths are: a Target Operating Model, an Intelligent Client Function Specification, a Governance Architecture document, a Sponsor Brief and Mandate, and an Implementation Plan summary.
Build-path designs add role specifications for each post in the function, the recruitment strategy and sequencing plan, the process framework document set, the tooling architecture, and the training and culture plan. Buy-path designs add the procurement strategy, evaluation framework, contract design (heads of terms or full drafting), performance regime specification, knowledge transfer specification, and exit and transition plan. Hybrid-path designs add the sequencing model with milestones and gates, the embedded staffing plan with named individuals where possible, and the transition trigger specification.
Design typically takes 8 to 12 weeks for Build or Buy paths and 12 to 16 weeks for Hybrid. The longer Hybrid duration reflects the need to design two modes plus the transition between them. The Design stage closes with formal board approval of the deliverable set and the appointment of mobilisation accountability. From that point, Stage 4 begins.
• • •