Key Concepts
A project should run on one integrated plan, not several separate ones. Trying to track things separately leaves you looking at an incomplete picture, the same way separate calendars can lead to double-booking. This task covers the full arc of planning: understanding the work, choosing the approach, gathering the inputs, building the plan, estimating, and keeping it current as things change. The arc starts from the approved project charter and runs through approach selection, potentially including hybrid project management, into effort estimation that may also feed cost and schedule baselines.
Anyone managing more than one calendar understands the importance of integrating plans. Try to track things separately and you will be double-booked or miss something, because you were looking at an incomplete picture. The same applies to projects, but more so, since they engage many people across many activities at once.
This task covers the full arc of planning: understanding what you are dealing with, choosing the right approach, gathering the information you need to plan well, building the plan, estimating the work, and then keeping the plan current as things change. The integrated project management plan is the master document that ties all subsidiary plans together. It is also the instrument through which you collect, analyze, and act on the data that keeps decisions grounded in reality.
2.1.1 Assess Project Needs, Complexity, and Magnitude
Before choosing an approach or starting to plan in detail, you need to understand what kind of project you are actually dealing with. Not all projects are the same. Even building the same house in a new location introduces new variables, new stakeholders, and new constraints. The factors that shape a project include the type of work being undertaken, the level of uncertainty in requirements and technology, the complexity of delivery, stakeholder needs, and timeline pressures.
A useful place to start is understanding whether the work is primarily industrial or knowledge work. Industrial work is tangible, stable, and mostly repeatable. Knowledge work is less defined, more collaborative, and concerned with solving novel problems rather than transforming raw materials. Project management emerged from an industrial tradition. The techniques that followed, including work breakdown structures, network diagrams, and Gantt charts, work well for large, complicated but defined projects. They are less suited to projects where the goal is unclear at the outset and the path will emerge through learning and adaptation.
The Stacey Matrix
Project uncertainty exists in two dimensions: what exactly you are building (requirements uncertainty), and how to best build it (technology uncertainty). The Stacey Matrix plots these two dimensions on perpendicular axes and produces four zones.
In the bottom-left sits the Simple zone: low requirements uncertainty, low technology uncertainty. Projects here are well-served by traditional, predictive life cycles. Large scale and complexity do not automatically disqualify a project from this zone. As long as uncertainty is low, stable upfront planning is achievable.
In the top-right sits the Chaos zone: very high uncertainty on both dimensions. No life cycle handles this well; the right response is to take action to reduce one or both sources of uncertainty before committing to a delivery approach.
The large middle region is Complex territory. These projects are well-served by iterative, incremental, and agile life cycles, because frequent feedback loops and the ability to adapt are exactly what high-uncertainty work requires.
2.1.2 Recommend a Project Management Development Approach (Predictive, Adaptive/Agile, or Hybrid Management)
No Single Best Approach
There is no single best way to execute every project. If there were, it would likely have been automated by now. Because all projects differ, we need to determine how to select the most appropriate approach. The factors to evaluate include the work type, level of uncertainty, complexity, stakeholder needs, organizational culture, team characteristics, and timelines. These project inputs, together with industry and organizational norms, help form a well-grounded recommendation.
Traditional/Predictive Approaches
Traditional, predictive approaches work best for defined, repeatable projects. They can be planned in detail upfront and then executed by following that plan. The mantra “Plan the work, work the plan” captures their character well. Deliverables such as Gantt charts, network diagrams, work breakdown structures, and detailed specification documents are commonly associated with this approach.
Agile/Adaptive Approaches
Agile approaches work well when solving new problems with high rates of change and uncertainty. They focus on communication and collaboration while iteratively building, inspecting, and adapting. They evolve toward an emergent solution that may not have been knowable at the start. Frequent review points, and course corrections when needed, allow teams to chase moving targets that predictive planning could not anticipate.
Hybrid Approaches
Hybrid approaches combine elements of both traditional and agile life cycles. A hybrid might still do significant upfront planning but then execute iteratively, perhaps with monthly iterations rather than the shorter sprints typical of pure agile. Since there is no single standardized hybrid definition, stakeholders usually need to align early on what “hybrid” means for this particular project.
The Spectrum of Hybrid Approaches
Since hybrids are unique blends, they come in many varieties. On the spectrum from highly predictive to highly adaptive (Traditional to Agile) they occupy the entire middle ground. This means we can create hybrids that are close to traditional, predictive approaches – such as a traditional approach with a series of proof of concepts before committing to a single path. Or a hybrid that is very close to a pure agile approach, but with additional documentation, approvals and governance.
Agile Suitability Filter
Once you have assessed the project, a structured tool can help frame the conversation. The Agile Practice Guide contains an Agile Suitability Filter that helps assess which life cycles are most appropriate given the circumstances. It covers three broad areas: Project characteristics (likelihood of change, criticality, suitability for incremental delivery), Team characteristics (team size, experience, access to business representatives), and organizational Culture (organizational agility, trust, and sponsor buy-in).
Using a radar chart to plot scores ranging from ideal-for-agile to ideal-for-predictive, the tool creates a visual summary of fits and gaps. The result is not a mandate. It is a starting point for stakeholder discussion. There may be regulatory requirements, sponsor direction, or organizational constraints that override what the filter suggests. The value of the tool is that it makes the discussion more objective and the tradeoffs more visible.
The image above shows a blank Agile Suitability Filter assessment sheet. It contains segments for Team characteristics, organizational Culture, and Project characteristics. Each segment contains three sub-categories measuring elements such as, in the Team segment, the team size, agile experience and access to business or customer representatives.
The radar chart is completed by answering questions about each of the 9 sub-domain topics. The questions are scored on a continuum from a good fit for agile to better suited for a plan-driven approach. Scores in the middle indicate a hybrid approach should be considered. In the image above, these continuums are depicted by the bars on the right-hand side of the radar chart.
The example shown below depicts possible scores for a website project.
In this website project example, the scores are clustered around the center of the chart. This indicates the project is likely suitable for an agile approach.
The Project/Criticality score is in the Hybrid zone, indicating what is at stake might be higher than the validation/verification and documentation levels normally associated with agile approaches. This does not indicate that an agile approach cannot be used, instead perhaps additional rigor and checks-and-balances might be warranted.
The example shown below depicts the scores for building a new big-box super-store and getting it ready for opening.
In this example, the scores are all in the plan-driven zone. This indicates the project is likely a good fit for using a traditional, plan-driven approach.
Agile suitability filters are not definitive, instead they are just one tool that can be used to help have meaningful conversations with the interested stakeholders about approach selection. The radar chart creates a visual that people can focus on and hopefully have objective discussions around. There may be other factors such as regulatory standards or sponsor direction that over-rule the approach suggested.
The example plots above were clear-cut examples firmly in the agile and plan-driven domains. In practice, we often find spikes and lopsided plots that point to hybrid solutions.
2.1.3 Determine Critical Information Requirements (e.g. Sustainability)
Every project has information it cannot function without. This enabler asks you to identify what that information is, so gaps do not surface mid-execution when they are expensive to close.
Critical information requirements fall into several categories. Compliance requirements define what the project must conform to: government regulations, corporate policies, quality standards, and industry-specific mandates. Safety and security requirements specify what must be protected. Stakeholder reporting requirements define who needs what information and when.
Nominal Group Technique
The nominal group technique is a structured approach to requirements gathering in groups that reduces the tendency for a few voices to dominate the conversation. Each participant first generates ideas independently without discussion, then the ideas are shared and the group discusses each one. Finally, participants vote or rank the ideas to produce a prioritized list. The independent generation step is what makes this technique useful: it gives quieter participants, or those lower in the organizational hierarchy, the same starting position as everyone else. The nominal group technique is particularly well suited to groups where seniority differences or controversy might suppress honest input during open discussion.
Prototyping and Storyboarding
Prototyping is a requirements elicitation technique that builds a working model of the product (or a portion of it) and presents it to stakeholders for feedback. The reason it works is straightforward: most people find it much easier to react to something they can see and interact with than to describe what they want in abstract terms. Showing stakeholders a prototype often surfaces requirements that interviews and surveys missed entirely, because seeing a product helps people recognize what they need.
Storyboarding is a lighter version of the same idea. Instead of a working model, the team creates a sequence of sketches or screen mockups that walk stakeholders through a process or user journey. Storyboards are faster to produce than prototypes and still generate concrete, visual feedback. Both techniques are particularly useful early in the project, when requirements are still vague and conversations about abstract concepts are producing noise more than signal.
Context Diagrams
A context diagram shows the product or service as a central box, surrounded by the external systems, people, and organizations that interact with it. Each interaction is represented by an arrow showing the direction and nature of the information or data flow. The diagram is deliberately simple: it does not show internal processes, only what crosses the boundary between the product and its environment.
Context diagrams are useful at the start of requirements work because they force the team to define the system boundary and identify every external party the product must interact with. Each arrow on a context diagram becomes a candidate set of requirements. A diagram produced early in the project and reviewed with stakeholders often reveals interfaces that were overlooked and dependencies that were assumed but never confirmed.
Sustainability as a Critical Information Requirement
Sustainability has become a named consideration in project planning, and it deserves explicit attention alongside scope, cost, and schedule. This means identifying the environmental, social, and governance factors that the project must account for.
On the environmental side, this includes understanding energy use, material sourcing, waste generation, and any carbon commitments the project carries. On the social side, it includes supply chain labor standards, community impact, and whether the project outcomes create lasting value or simply transfer risk elsewhere. On the governance side, it means knowing which reporting or disclosure obligations apply.
Capturing sustainability requirements early, as part of determining critical information needs, means these factors shape the plan rather than being retrofitted to it. A project that ignores sustainability constraints during planning is likely to face scope changes, rework, or reputational risk during execution.
What does this look like in practice? A construction project needs to track material sourcing, waste disposal, and ground contamination. A technology project may need to assess data center energy consumption and hardware end-of-life disposal. A product development project may need to report on carbon footprint or recyclability of packaging. These are not afterthoughts; they are planning inputs with real cost, schedule, and compliance implications.
The first step is asking: what sustainability requirements apply to this project? Those requirements might come from regulation, from organizational policy, from the customer’s procurement standards, or from the community affected by the project. Identify them early, because they influence scope, procurement choices, quality standards, and financial planning.
Agile teams surface sustainability requirements the same way they surface other requirements: through backlog refinement and stakeholder conversations. Adding sustainability acceptance criteria to user stories, and including sustainability-related technical debt as backlog items, keeps these concerns visible throughout delivery rather than addressed only at the end.
2.1.4 Recommend a Project Execution Strategy
The execution strategy answers questions that go beyond the development approach. How will the project be governed? How will it be funded and reviewed? What contracting model applies? What are the escalation paths? Governance, culture, and team characteristics all feed into the execution strategy alongside the approach selection covered in 2.1.2.
Once the Agile Suitability Filter assessment, stakeholder discussions, and analysis of organizational constraints are complete, a recommendation for the most appropriate approach should be made. The final decision may reside with the project manager, the PMO, the sponsor, or the team, depending on the organization. What matters is that the decision is explicit, shared, and documented so everyone understands how the project will be run before execution begins.
2.1.5 Create an Integrated Project Management Plan
The term “Project Management Plan” has a specific meaning in the PMP exam. It is the name given to the master plan that integrates and consolidates all the subsidiary management plans, along with baselines and other information necessary to manage the project.
The project management plan describes how the project will be run, monitored, controlled, and closed. It brings together the following subsidiary plans:
- Stakeholder engagement plan: how stakeholders will be engaged according to their needs, interests, and impact.
- Scope management plan: how scope will be defined, developed, monitored, controlled, and validated.
- Requirements management plan: how requirements will be analyzed, documented, and managed.
- Schedule management plan: how the schedule will be developed, monitored, and controlled.
- Cost management plan: how costs will be planned, structured, and controlled.
- Communications management plan: how project information will be created, shared, and confirmed.
- Risk management plan: how risk management activities will be designed and carried out.
- Quality management plan: how quality policies, approaches, and standards will be implemented.
- Resource management plan: how project resources will be classified, allocated, managed, and released.
- Procurement management plan: how goods and services from outside the organization will be acquired and managed.
Having a single integrated master source for all plans allows the project manager to see how efforts align and how dependencies flow between them. It also helps identify conflicts and gaps that will need resolving before they cause problems in execution.
Baselines
In addition to the subsidiary plans, the project management plan contains the baselines used to track performance. Common baselines include the scope baseline, schedule baseline, cost baseline, and performance measurement baseline. As the project progresses, actual values are compared to the baselined plan values for that point in time. Sufficient deviation from baseline triggers corrective action.
Planning across life cycles works differently. On predictive projects, requirements are defined in specific terms before development begins and outcomes are delivered at the end. Hybrid projects elaborate requirements periodically during delivery and can divide outcomes into increments. Adaptive projects elaborate requirements frequently and incorporate change in real time, with stakeholders involved continuously rather than only at milestones.
Agile projects do not produce a formal project management plan with ten subsidiary plans. The equivalent integrated planning structure is lighter and distributed across several artifacts. The product backlog holds the scope. A team charter or working agreement captures how the team will operate. A release roadmap provides a horizon view of delivery. Sprint plans define near-term work. Together, these artifacts serve the same integrating function as the project management plan, but they are designed to be updated continuously rather than baselined and change-controlled. The emphasis shifts from planning completeness to planning currency.
Hybrid projects often maintain a project management plan for governance and reporting purposes while managing delivery-level scope and scheduling through agile artifacts. The project management plan in this context tends to be lighter than a full predictive plan, focusing on the subsidiary plans that matter most to sponsors and governance bodies (schedule, cost, risk, communications) while leaving scope decomposition and iteration planning to the backlog and sprint cycles.
2.1.6 Estimate Work Effort and Resource Requirements
Estimating how much work a project requires, and what resources are needed to do it, is one of the most consequential planning activities a project manager performs. Poor estimates lead to under-resourcing, schedule failure, and budget overruns. They also erode sponsor and stakeholder confidence early in the project’s life.
Estimating starts with understanding the scope. Work effort, duration, and resource needs are all derived from what the project must deliver. On predictive projects, cost and schedule estimates are built bottom-up from the work breakdown structure. Activities are estimated individually, then rolled up to work packages, then to control accounts, and finally to a project total.
Common estimating techniques include analogous estimating (using data from similar past projects as the basis), parametric estimating (applying a cost or duration rate per unit of work), and bottom-up estimating (estimating each activity individually). Early in a project, when scope is still being defined, estimates are rough. A rough order of magnitude estimate typically carries a range of minus 25 to plus 75 percent. As the project progresses and scope becomes clearer, estimates narrow toward a definitive range of minus 5 to plus 10 percent.
On agile projects, teams estimate effort in relative units rather than hours. Planning poker and affinity estimation are common techniques for reaching a shared team estimate on user stories or backlog items. Budget is then derived from team velocity and a cost-per-point calculation based on loaded team salaries.
Resource Management Plan
The resource management plan is a component of the project management plan that describes how project resources will be acquired, allocated, monitored, and controlled. It covers people and equipment, defining roles and responsibilities, competency requirements, the project organization chart, team development methods, and a recognition plan. The plan also addresses how non-human resources will be made available when needed throughout the project.
2.1.7 Assess Consolidated Project Plans for Dependencies, Gaps, and Continued Business Value
Once all subsidiary plans are assembled, the integrated plan needs to be checked for untracked dependencies, missing activities, resource gaps, and continued alignment with the business case.
Project Management Information Systems
Project management information systems, commonly called PM tools, assist with this review. Tools used on predictive projects include Primavera and Microsoft Project. For agile projects, options include Azure DevOps, Jira, Trello, Basecamp, and many others. These tools vary in functionality but allow users to identify problems such as capacity limits, dependency violations, and skill gaps before they surface during execution.
Business Value
Business value is the net quantifiable benefit derived from a project. It may be tangible (financial gain, first-to-market advantage, new customers) or intangible (brand reputation, employee capability, social benefit). The project’s declared business value, typically documented in the business case and benefits management plan, is the benchmark against which continued justification is assessed.
Plans should be reviewed not just for internal consistency, but for whether the project still delivers the value it was authorized to create. Scope changes, schedule shifts, and cost growth can each erode business value. Assessing the integrated plan against the original value proposition is part of how project managers keep stakeholders and sponsors honest about what they are actually getting for the investment.
2.1.8 Maintain the Integrated Project Management Plan
“Planning is everything; the plan is nothing.” Dwight Eisenhower made this observation about military campaigns, but it applies equally to project work. The value of planning lies in the thinking and consultation that produces it. The resulting document is today’s best guess, and tomorrow we will know more.
Changes are inevitable. The project management plan must be kept current to remain useful. This requires a Change Management Plan.
Change Management Plan
The change management plan explains how the change control process works and documents the roles and responsibilities of the change control board. Organizational culture directly influences how this works in practice. Organizations in highly regulated environments tend toward cautious, formal change management with multiple approval levels. Organizations operating in rapidly evolving environments tend toward a lighter-touch approach.
The change management plan typically addresses approval levels for changes, the structure and membership of the Change Control Board, the change control process itself, the tools used to track and communicate change decisions, and the emergency change process for situations that cannot wait for a scheduled review.
Change Control Boards
A Change Control Board is a formally chartered group responsible for reviewing, evaluating, approving, deferring, or rejecting changes to the project. It represents key stakeholders and assesses change requests in terms of cost, schedule, risk, and value impact. The board exists to ensure changes are considered fairly and with full awareness of their consequences.
Configuration Management Plan
The configuration management plan lists all items under configuration management and defines how the Change Control Board will operate. It explains what constitutes a change, who can recommend one, what steps are required to evaluate a change request before approving or rejecting it, what effect the change has on project objectives, and which documents must be updated when a change is approved.
A Configuration Management System maintains the change history of all tracked components, recording what changed, when, and who authorized it. This creates an auditable version history for all project components and allows the project manager to see the lineage of any current configuration.
The Product Owner as a CCB
Agile projects handle change very differently from the CCB model. The product owner holds the authority to accept new scope, reprioritize existing backlog items, and defer or remove lower-value work, all without a formal change request process. New items are added to the backlog and prioritized against existing items. If a change is accepted, something of similar size moves down the backlog or out of scope entirely. This keeps the total amount of committed work stable while allowing priorities to shift. The backlog itself is the change log: it reflects the current agreed scope at any point in time, visible to everyone.
Hybrid projects often apply a CCB process to changes that affect the project baseline (budget, milestone dates, contractual scope) while allowing the product owner to manage delivery-level changes through the backlog. Defining this boundary clearly in the change management plan prevents disputes about which changes need board approval and which can be handled within the team’s own authority.
2.1.9 Collect and Analyze Data to Make Informed Project Decisions
Plans require information to remain relevant. As the project progresses, the project manager must continuously monitor change requests, risks, issues, and team performance. Then, based on these factors alongside customer and sponsor guidance, plans are updated to keep delivery on track.
Compliance management is one dimension of this. Most projects are subject to conditions including appropriate government rules and regulations, corporate policies, product and project quality standards, and requirements specific to the project’s industry or sector. Monitoring compliance means comparing project information to these requirements and acting when gaps appear.
Beyond compliance, data collection and analysis supports everyday decision-making. Two practical tools for this are earned value analysis and value stream mapping.
Earned Value Analysis
Earned value analysis compares planned work against completed work and actual cost at a given point in time. It produces metrics such as Schedule Performance Index and Cost Performance Index that give an objective view of whether the project is on track. These metrics replace judgment calls with data, and they make performance trends visible early enough to act on.
Value Stream Mapping
Value stream mapping traces the flow of work from initiation to delivery, identifying where value is being added and where it is not. Delays, handoffs, rework loops, and waiting time all appear on a value stream map. Removing or reducing them directly improves delivery speed and quality.
The principle behind both tools is the same. Data allows you to see clearly. Clear sight allows better decisions. Good decisions protect business value and keep the project on course.
The data types useful for project decisions falls into a few categories. Historical data from similar projects gives a starting point for estimates and risk assessments. Current performance data, including cost, schedule, defect rates, and team throughput, tells you where the project actually is, not where the plan said it would be. Stakeholder input and survey data tells you how the project is being received and whether expectations are shifting.
Decision-Support Tools
Two tools are worth naming here because they structure data collection and analysis rather than leaving it ad hoc.
Trend Analysis
This involves tracking a metric over time to see whether it is improving, stable, or deteriorating. A cost performance index that has been declining for three consecutive reporting periods tells you something the current-period number alone cannot. Trend analysis turns snapshots into a story.
Variance Analysis
This compares planned performance against actual performance and asks: how large is the gap, what caused it, and what does it mean going forward? In predictive projects this is formalized through earned value management. In adaptive projects, velocity trends and burndown charts perform the same function.
The discipline that matters is deciding in advance what data you will collect, not searching for data after a decision has already been made. Define your key metrics during planning, identify the sources, and establish the cadence for review.
Agile projects use a different set of metrics to answer the same question: are we on track? Modern agile teams increasingly rely on throughput and flow metrics rather than velocity and burndown charts, which are easier to game and have been subject to management misuse. Throughput measures how many work items a team completes in a given period, regardless of estimated size. Flow metrics such as cycle time, lead time, and work in progress track how smoothly work moves through the delivery system. A rising cycle time signals a bottleneck; growing work in progress signals overload. These metrics are harder to manipulate because they reflect what actually happened, not what was estimated or planned. They are updated continuously and visible to all stakeholders, creating an ongoing performance signal rather than a periodic report.
Hybrid projects often combine both worlds. Earned value analysis may be applied at the project level to satisfy governance and reporting requirements, while throughput and flow metrics are used at the team level to manage sprint-by-sprint delivery. The project manager translates between the two views, connecting team-level flow data to the project-level performance baseline.
Deliverables and Tools
- Project Management Plan
- Baselines (Scope, Schedule, Cost, Performance Measurement)
- Product Backlog
- Configuration Management Plan
- Change Management Plan
- Business Case
- Benefits Management Plan
- Needs Assessment
- Resource Management Plan
- Requirements Management Plan
- Agile Suitability Filter
- Stacey Matrix
- Project Management Information System (PMIS)
- Change Control Board (CCB)
Related Topics
- 2.2 Develop and manage project scope
- 2.3 Help ensure value-based delivery
- 2.4 Plan and manage resources
- 2.6 Plan and manage finance
- 2.7 Plan and optimize quality of products/deliverables
- 2.8 Plan and manage schedule
- 2.9 Evaluate project status
- 3.1 Define and establish project governance
- 3.2 Plan and manage project compliance
- 3.3 Manage and control changes
- Sustainability and the 2026 PMP Exam: What Candidates Need to Know
- PMP Mind Map
FAQ
Why is a single integrated plan important?
Separate plans give an incomplete picture, so things get missed, the same way juggling multiple calendars can lead to double-booking.
What is the integrated project management plan?
The master document that ties all the subsidiary plans together.
What does this task cover?
The full arc of planning: understanding what you are dealing with, choosing the right approach, gathering the information to plan well, building the plan, estimating the work, and keeping the plan current.
How does this task fit into the 2026 PMP exam?
Task 2.1 sits in the Process domain of the 2026 Exam Content Outline. The 2026 PMP Exam page has the domain and task breakdown and what changed in the new exam.
Mastery Map and Quiz
Congratulations! You earned the Plan Delivery badge.