Lesson 5 — Advanced Project Management and Governance¶
At a glance
- Module: 12 — Advanced Project Management
- Level: Advanced
- Estimated time: 45 minutes
- Example project: the university admission portal
Learning objectives¶
By the end of this lesson you should be able to:
- Explain why single-team practices do not scale directly, and what must change.
- Choose coordination mechanisms for multiple teams and state their trade-offs.
- Reason about hybrid delivery, where predictive and adaptive practices are combined deliberately.
- Describe governance mechanisms and place a project in its portfolio context.
Prerequisites¶
Introduction¶
Everything so far has assumed one team and one project. Real organisations run several teams on one product and several projects against one budget. This lesson is about the changes that scale forces, and about the governance that keeps the whole arrangement accountable.
The theme throughout: scaling is not more of the same. Mechanisms that work in one team often become the problem at ten.
1. Why scaling breaks single-team practice¶
| Single-team practice | What happens at scale |
|---|---|
| Shared understanding in one team | Ambiguity across team boundaries becomes divergence |
| One backlog, one priority order | Competing backlogs; local optimisation at the expense of the whole |
| Daily coordination by conversation | Coordination load grows faster than headcount (Module 10) |
| One integration point | Integration becomes a queue and a schedule driver |
| Retrospective-driven improvement | Improvements are local; systemic problems persist |
The underlying arithmetic is that communication channels grow as n(n − 1) ÷ 2 while capacity grows linearly. Coordination therefore has to be designed, not left to emerge: explicit interfaces, explicit ownership, and fewer, better-structured conversations.
2. Coordination mechanisms¶
| Mechanism | What it does | Cost |
|---|---|---|
| Team-of-teams structure | Gives each small team autonomy within a shared mission | Needs alignment on goals and interfaces |
| Platform team | Provides a shared service other teams consume | Can become a bottleneck if treated as a ticket queue |
| Enabling team | Transfers capability rather than doing the work | Slow to show results; requires trust |
| Explicit interface contracts | Reduce the need for negotiation | Need an owner and a change process |
| Scrum-of-Scrums / sync of syncs | Surfaces cross-team blockers | Risks becoming a reporting layer |
| Shared definition of done | Prevents inconsistent quality across teams | Needs enforcement, not just agreement |
| Architecture decision records | Make cross-team decisions durable and findable | Require discipline to maintain |
Two warnings. Coordination roles multiply. Each new synchronisation meeting costs several people for its whole duration, so the return has to be visible. Frameworks are not mechanisms. A scaled framework prescribes meetings; it does not create the interface ownership or the architectural clarity that make them work. Adopting the structure without the substance produces the cost and not the benefit.
3. Hybrid delivery¶
Most real projects are hybrid, and pretending otherwise causes friction. Hybrid delivery combines predictive and adaptive practice deliberately.
| Hybrid pattern | Shape | Sensible when |
|---|---|---|
| Predictive envelope, adaptive inside | Fixed date and budget, iterative delivery of scope | External commitment with uncertain requirements |
| Adaptive development, predictive compliance | Iterative build with formal gates for regulated deliverables | Certification or audit constraints |
| Phased hybrid | Adaptive discovery phase, then predictive delivery of a settled scope | Requirements become clear partway through |
| Vendor hybrid | Adaptive in-house, fixed-price contractual milestones | Work is partly outsourced |
The risk of hybrid is coherence: two sets of assumptions, reporting, and definitions of done, with no one owning the seam. Make the seam explicit — which parts follow which model, who owns the interface, and how progress is reported — or the arrangement becomes an excuse rather than a design.
4. Governance¶
Governance is the set of arrangements that make a project accountable for resources and decisions.
| Mechanism | Purpose |
|---|---|
| Steering committee | Owns priorities; resolves conflicts between projects; approves beyond tolerance |
| Stage gates | Decisions to continue, change, or stop at defined points |
| Assurance review | Independent examination of how the project is managed |
| Audit | Verification that process and controls were followed |
| Escalation path | A known route for issues beyond project authority |
| Benefits ownership | Someone outside the project owns whether the benefit arrives |
The most neglected mechanism is the gate. A project with no stop decision does not have governance; it has momentum. The second is benefits ownership: the project delivers a capability, and somebody else must adopt it for a benefit to appear. If nobody owns adoption, the benefit is a prediction.
Governance also operates above the project, at portfolio level: prioritisation across competing projects, capacity planning against a shared pool of people, and explicit decisions about what will not be done. A portfolio with no exclusion decisions is a portfolio that has not been prioritised.
Key terms¶
| Term | Meaning |
|---|---|
| Team of teams | A structure of small, aligned, autonomous teams |
| Platform team | A team providing a shared service to other teams |
| Interface contract | An explicit agreement on how two parts interact |
| Architecture decision record (ADR) | A short record of a decision and its rationale |
| Hybrid delivery | A deliberate combination of predictive and adaptive practice |
| Steering committee | The body that owns priorities and beyond-tolerance decisions |
| Stage gate | A decision point to continue, change, or stop |
| Portfolio management | Prioritising and capacity-planning across projects |
| Benefits realisation | Confirming that the intended benefit occurred |
Worked example¶
Task: scale delivery of the illustrative admission portal from one team to three, and set up its governance. Figures are invented for teaching.
Step 1 — Decide what actually needs scaling. The portal grows to three streams: applications and forms, eligibility rules, and notifications. Rather than tripling one team, three small teams are formed, each owning an end-to-end stream.
Step 2 — Design the coordination rather than assuming it. The three streams share a data model and an identity service. Coordination is not left to meetings: ownership is explicit — one engineer owns the shared data model; changes to it need a written proposal — and the identity service becomes a platform with its own small team, not a side task distributed across the three.
Step 3 — Set one priority order. With three backlogs, each team would optimise locally: forms would polish while eligibility, which gates every application, lags. A single prioritised list for cross-cutting work and a shared definition of done are agreed, and the three team leads meet twice a week with a named outcome — resolving blockers — rather than a reporting agenda.
Step 4 — Choose the hybrid shape deliberately. The launch date is externally committed, which requires a predictive envelope, while the eligibility rules are governed by academic regulations that will be refined during the year. The shape is therefore: fixed date and budget, adaptive delivery inside. State the seam explicitly — the date and the budget are baselined; the rule detail is iterative; progress is reported against the fixed date.
Step 5 — Build governance with a real gate. The steering committee meets at three gates: after requirements, before build completion, and before launch. At least one gate can stop the work, and the committee knows it. Assurance review examines how the project is managed, separate from whether it is on schedule — a project can be on schedule and poorly managed.
Step 6 — Name the benefits owner. The intended benefit is a shorter admission cycle. The admissions office — not the project — owns adoption, and the measurement is scheduled three months after launch. Without that, the benefit is a project claim nobody will verify.
Step 7 — Recognise the cost of the structure. Three teams need more coordination than one: two leads meetings per week, a shared backlog, an interface owner, and a platform team. The cost is real and is stated. What it buys is that the three streams can progress without negotiating their interfaces daily — which is why the cost is worth paying, and why it would not be worth paying for two streams.
Step 8 — Report at portfolio level. At portfolio review the honest statement is what will not be done this year: the alumni portal integration. A portfolio that reports only what is happening, and never what has been excluded, has not been prioritised.
Common misconceptions¶
“Scaling up means adding teams”
Adding teams without designing coordination multiplies the communication cost and splits ownership of shared components. Design the interfaces, the ownership, and the priority order first.
“Hybrid means we can pick whatever we like”
Hybrid is a deliberate combination with an owned seam. Choosing freely per situation produces two sets of expectations and no accountability for the join between them.
“Governance is oversight that slows you down”
Governance provides the stop decision and the escalation route. A project with reports but no gates has no mechanism for ceasing, which is why unviable work continues to consume capacity.
Practical activity¶
Design for scale and accountability. For one example project:
- Identify the point at which the project would need more than one team, and what drives it.
- Choose two coordination mechanisms and state what each costs.
- Name one shared component, its owner, and the process for changing it.
- Choose a hybrid shape and state exactly where the seam is and who owns it.
- Define three governance mechanisms, including one gate with authority to stop.
- Name the benefits owner and the measurement date.
What "good" looks like: a coordination cost acknowledged rather than assumed away, an owner for every shared interface, a hybrid seam with a named owner, and a governance gate that could actually stop the work.
Self-assessment¶
- Why does adding teams increase coordination cost faster than it increases capacity?
- What is wrong with adopting a scaled framework without designing interfaces and ownership?
- What is the main risk of hybrid delivery, and how is it mitigated?
-
Why is a gate more important than a progress report?
-
Apply it — multi-team programme. Four teams deliver into one student-data platform. Three work in two-week sprints; the fourth delivers the integration layer on a fixed-date contract and cannot change its dates. Interface changes are currently agreed verbally between developers, and the programme manager reports “all teams are green”.
Hint: A strong answer names the coordination mechanism that is missing and what the hybrid seam requires.
Show answers
- Because communication channels grow as n(n − 1) ÷ 2 while capacity grows linearly, and because additional teams create shared components and interfaces that must be negotiated. The overhead is structural, not a failure of effort.
- The framework prescribes meetings but does not create the architectural clarity or ownership that make them useful. The result is the cost of coordination without the benefit.
- Incoherence: two sets of assumptions, reporting, and definitions of done, with the seam unowned. Mitigate by stating explicitly which parts follow which model and who owns the join.
- Because a report informs while a gate decides — including deciding to stop. Without a gate, governance has no mechanism for ending unviable work.
- What is missing is designed coordination: a named owner for each interface, an explicit and versioned interface agreement, and a single ordered backlog or at least a documented sequence across the four teams — verbal agreement between developers is the mechanism that fails silently, which is why every team reads green while integration slips. Because three teams are adaptive and one is predictive, this is a hybrid programme, and a hybrid needs an owned seam: the integration layer's dates are fixed, so the other three must plan to their fixed interface dates rather than discovering them, and the seam needs one named owner on each side. Finally, the reporting is part of the problem: “all green” from four independent teams is not a programme status — it needs the integration risk, the interface change rate, and the dependency picture on one page, or governance is deciding on a summary that cannot go red.
Summary¶
- Scaling requires designed coordination: explicit interfaces, named ownership, and a single priority order.
- Coordination mechanisms each carry a cost, and frameworks do not substitute for architectural clarity.
- Hybrid delivery is a deliberate combination with an owned seam, not free choice per situation.
- Governance supplies gates, escalation, assurance, and benefits ownership; portfolios must decide what will not be done.
- Every benefit needs an owner who is not the project.
Further learning¶
- Module 13 — Capstone
- Team Topologies, Matthew Skelton and Manuel Pais — team structures and interaction modes.
- A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Project Management Institute — programme and portfolio considerations.
- Accelerate: The Science of Lean Software and DevOps, Nicole Forsgren, Jez Humble, and Gene Kim — evidence on the organisational conditions associated with delivery performance.
Next¶
You have completed Module 12. Continue to Module 13 — Capstone.