4.1. Develop an Integrated Project Management Plan and Plan Delivery
💡 First Principle: An "integrated" plan means every subsidiary plan (scope, schedule, cost, risk, quality) is checked for consistency against the others, not authored in isolation — a schedule that ignores a resourcing constraint documented in the resource plan isn't integrated, it's just two separate documents that happen to share a folder.
Enablers: assess project needs/complexity/magnitude, recommend a development approach (predictive, adaptive/agile, or hybrid), determine critical information requirements (the ECO's example is sustainability), recommend an execution strategy, create the integrated plan, estimate work effort and resource requirements, assess consolidated plans for dependencies/gaps/continued business value, maintain the plan as conditions change, and collect/analyze data to make informed decisions.
Selecting a development approach is itself a tested decision, not a given: high-uncertainty, evolving-requirements work favors adaptive/agile; well-understood, low-change work favors predictive; most real projects land somewhere in a hybrid blend. The exam expects you to justify the approach based on project characteristics described in the scenario, not apply your organization's default methodology reflexively.
The four life cycles, and the one that combines them
Life cycle questions are usually decided by two variables: how certain the requirements are, and how the product is delivered — once at the end, or in usable pieces along the way.
| Life cycle | Requirements | Activities | Delivery | Choose it when |
|---|---|---|---|---|
| Predictive | Fixed up front | Performed once, in sequence | Single delivery | The work is definable, done before, with known risks and heavy oversight |
| Iterative | Dynamic | Repeated until the solution is right | Single delivery | Requirements are clear but the solution is uncertain — refine it through prototypes |
| Incremental | Dynamic or known | Performed once per increment | Frequent smaller deliveries | Customers need usable, finished pieces early and regularly |
| Adaptive (agile) | Dynamic | Repeated in short timeboxes | Frequent smaller deliveries | Both requirements and solution are uncertain and fast feedback matters |
| Hybrid | Mixed | Tailored per component or phase | Mixed | Parts of the project have different profiles |
Agile is iterative and incremental combined: it refines unfinished work through feedback and ships usable increments frequently. The telltale sign of an iterative project is successive prototypes or proofs of concept feeding one release; the sign of a predictive one is that the bulk of planning happens up front and execution follows in a single sequence.
⚠️ Exam Trap: Confusing iterative with incremental. "Novel, unproven technology but a well-defined scope" calls for iterative — build and test prototypes to retire technical uncertainty. "Release a module early and the rest later" calls for incremental. The deciding question is whether you are repeating work to get it right or delivering finished slices.
Recommending an approach from project characteristics
Read the scenario for signals, then match them:
- Favor adaptive: uncertain scope, a small co-located cross-functional team, ready customer access, and a need to release usable value quickly in a competitive market.
- Favor predictive: stable, approved requirements; hard sequencing; strict regulatory oversight with a fixed deadline; construction-style single handover.
- Favor hybrid: components with different profiles — custom hardware with long lead times planned predictively alongside evolving software delivered in sprints; fixed regulatory reporting beside a dashboard shaped by user testing; or a risk-averse R&D effort that starts with a time-boxed feasibility phase and a go/no-go decision before committing to full development.
When a team has no methodology experience and the approach is still open, a neutral set of general phases — feasibility, design, build, test, deploy, close — lets planning proceed without prematurely committing to one model.
The Agile Practice Guide's suitability filter gives a structured way to make the initial recommendation: it scores culture, team, and project factors and indicates where a project sits between predictive and agile. Complexity models serve the same purpose. The Stacey matrix plots requirements agreement against technical certainty; middle-ground uncertainty points to delivering small usable features and adjusting from feedback. Cynefin separates domains: clear work applies best practice, complicated work — clear requirements with several possible correct solutions and known unknowns — calls for assessing the facts, analyzing, and applying good practice, while complex work calls for probing through experiments. For a tangled legacy system with many integrations, simplify first — decouple connected parts to reduce variables — then reframe the problem with a diverse group of stakeholders.
Tailoring is continuous, not a one-time pick
Tailoring adapts processes, tools, governance, and team structures to the project — it is broader than choosing a methodology, and PMBOK 8 still expects it even though it is no longer a named principle; it lives within Adopt a Holistic View and the non-prescriptive Focus Areas. The four steps are: select the initial approach from project context, adjust it for the organization, adjust it for the specific project, then implement it and keep improving it. A PMO that buys a vendor framework wholesale and still sees late, over-budget projects needs to tailor, not buy a different framework.
Transformation follows the same logic: evolve teams gradually and visibly. A first step for a team with hidden work and weekly catch-ups is a shared Kanban board plus a short daily standup. Directing everyone to "go agile in one go" is the pattern PMI rejects.
In a hybrid environment the tailoring work is at the seams. When an agile team must integrate with a system governed by stage gates, agree explicit integration points, interface specifications, communication protocols, and a shared view of dependencies. When deployment must follow a documented sequential process, the challenge is producing that documentation from iterative artifacts.
Agile values and principles you are expected to recognize
The 2001 Agile Manifesto values individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. An executive who wants to center everything on set processes and tools should be steered back to people and interactions.
Its twelve principles include: satisfying the customer through early and continuous delivery of valuable software; delivering working software frequently, preferring the shorter timescale; business people and developers working together daily; sustainable development at a constant pace; continuous attention to technical excellence and good design; simplicity — maximizing the amount of work not done; working software as the primary measure of progress; and regular reflection so the team tunes its behavior. "Meet every deadline even at the cost of quality" is never one of them. Agile measures follow suit — value-based metrics such as a feature burndown, features delivered, and customer satisfaction rather than percent-complete against a predictive plan.
Frameworks, briefly
| Framework | What to remember |
|---|---|
| Scrum | Timeboxed sprints, defined roles and events |
| Kanban | Continuous flow, a pull system governed by WIP limits; each card pulled is an increment of value and a measure of progress |
| XP | Pair programming, refactoring (improving internal structure without changing behavior), continuous integration, whole team sitting together in an informative workspace, real customer involvement, team continuity, sustainable pace |
| Crystal | Alistair Cockburn; core values of people, interaction, and community; scaled by color — Clear, Yellow, Orange, Red — as team size and criticality grow |
| DSDM | Focus on the business need, deliver on time; fixes cost, quality, and time up front, then prioritizes scope |
| FDD | Develop an overall model, then plan, design, and build by feature; feature teams, individual class ownership, configuration management, visible progress |
| AUP | Iterative cycles across seven disciplines such as model, implementation, test, deployment, configuration management, project management, and environment |
| Disciplined Agile | Context-sensitive, choice-driven, enterprise-aware |
| SAFe | Agile Release Trains align in PI Planning; the Release Train Engineer facilitates cross-train coordination |
| LeSS | Scrum across many teams on one product, with one Product Owner and one Product Backlog |
⚠️ Exam Trap: At scale, strong team metrics with late program delivery points to unmanaged cross-team dependencies, not weak teams. The answer coordinates across teams — PI Planning, an ART sync, integration planning — rather than pushing individual teams harder.
PRINCE2 is sometimes used as a contrast: its End Stage Assessment reviews the completed stage against plan, confirms continued business justification, and approves the next stage plan — a formal version of the "assess continued business value" enabler.
Building and maintaining the integrated plan
In predictive planning, activities are sequenced into a network diagram — most dependencies are finish-to-start — and shown on a Gantt chart of start and end dates. Responsibility is clarified in a RACI matrix: Responsible, Accountable, Consulted, Informed. The scope, schedule, and cost baselines together form the performance measurement baseline used for earned value. Checking the consolidated plan for gaps and dependencies — such as three vendors integrating under different technical standards — is Adopt a Holistic View in action, and so is building the capacity to absorb change through reserves, change control, and flexible architecture, whatever the approach.
In agile planning, a functional manager's high-level needs become themes or epics, decomposed into features and then user stories; candidate features for a three-to-six-month horizon can be tested with a business model canvas before they enter the backlog.
Maintaining the plan means baselines move only through change control. Once a change is approved, update the affected baseline — for example, revise the schedule baseline — and communicate it. A minor deviation found during validation is documented, and a change request follows if correcting it would affect baselines. Schedule compression is an integrated decision too: crashing with experienced contractors who already know the technology avoids the learning curve that makes crashing costly.
⚠️ Exam Trap: Absorbing unrelated new work because it is convenient. An executive asking your funded construction project to also build a website is a new initiative — help them write a business case and seek separate funding rather than expanding your scope.
⚠️ Exam Trap: Picking "agile" as the answer whenever a scenario mentions changing requirements, without checking whether the described work also has fixed regulatory deadlines or contractual scope — those characteristics can push the right answer toward hybrid or predictive despite the changing-requirements signal.
Reflection Question: Describe a project where a hybrid approach (not purely predictive or purely agile) was the right call. What specific project characteristics drove that choice?
