Planning Process ITTOs

References
image of two people in a room planning Planning is where vision becomes structure — and structure becomes direction.


Planning Process Group – From Intention to Instruction

If Initiating is about permission, Planning is about precision. This is the most ITTO-heavy process group for a reason: it turns high-level intent into detailed direction. Every estimate, every schedule, every plan for scope, quality, risk, resources, procurement, and communication emerges here — not just as a theory, but as a coordinated set of documents and baselines ready for execution.

The Planning ITTOs don’t live in isolation. They live in context. Together, they form the blueprint of how the project will be executed, monitored, and controlled. They respond to stakeholder needs, organizational constraints, and delivery methods — predictive, agile, or hybrid.

This page walks through the Planning processes one by one, explaining how ITTOs show up, interact, and build toward a full project management plan. Don’t memorize. Read for understanding. The patterns will take you further than the lists ever could.


Plan Scope Management and Collect Requirements

Planning begins with boundaries. In Plan Scope Management, you define how the project will define and control scope. In Collect Requirements, you gather the raw material for what the project must deliver — from stakeholders, regulations, contracts, and strategic goals.

Inputs here include business documents, the project charter, and enterprise environmental factors (EEFs), which all influence how flexible or strict your scope will need to be. Tools include workshops, interviews, and decision-making techniques to ensure you surface not just what stakeholders want, but why. Outputs like the requirements documentation and traceability matrix create a clear line between input and outcome — a chain that can be validated later in delivery.

Together, these processes set the foundation for all future planning: if your scope and requirements are misaligned, your estimates, deliverables, and timeline will suffer.


Define Scope and Create WBS

Once requirements are collected, Define Scope refines them into a project-specific lens. Here, you translate vague desires into actionable features. Then, in Create WBS, you break those features down into tangible deliverables and work packages using a Work Breakdown Structure.

These processes pull from the stakeholder register and requirements docs. Tools like decomposition, expert judgment, and progressive elaboration help you clarify where the edges of the work really lie. The result? A scoped project — not just in idea, but in architecture. These outputs become the scaffolding for everything else: schedule, cost, quality, and risk.


Plan Schedule and Cost Management

Scope is what you’re doing. Schedule and cost are how long it takes and what it will cost. Plan Schedule Management sets the rules: what methods you’ll use to estimate, track, and report progress. Plan Cost Management does the same — establishing the frameworks for estimation, budgeting, and control.

ITTOs in these processes focus on guidelines and governance. You’re not building a schedule yet — you’re defining how you’ll build one. Organizational process assets (OPAs) come into play here: templates, past project data, and financial policies that inform your planning logic.

These two processes don’t create the final numbers — they create the way you’ll arrive at those numbers. They’re about meta-planning: how will we measure time and money in a way that fits our project?


Define Activities, Sequence Activities, Estimate Duration, and Develop Schedule

Now the real work planning begins. Using the WBS as a foundation, you define individual activities, sequence them logically, estimate how long each will take, and combine those estimates into a full project schedule.

ITTOs here reflect a shift: from conceptual to quantitative. You’ll use data analysis techniques (e.g. analogous, parametric, and three-point estimation), dependency mapping, and modeling tools like critical path and what-if scenarios. Outputs include the activity list, network diagram, and the schedule itself.

This is where Planning becomes predictive. You’re shaping a timeline based on logic, constraint, risk, and resource availability — and turning it into a schedule you can execute against.


Estimate Costs and Determine Budget

Just as time gets modeled, cost gets quantified. Estimate Costs produces detailed cost estimates using tools like reserve analysis, expert judgment, and historical data. Determine Budget takes those estimates and aligns them with funding limits, approval thresholds, and contingency needs.

Together, they generate a cost baseline — one of the most critical outputs in Planning. This baseline becomes your measuring stick during execution and control. Missed estimates here ripple forward as surprises, overruns, or scope reductions later.

These processes rely heavily on accurate documentation: scope baseline, schedule, and resource estimates all feed into meaningful financial planning.


Plan Quality, Plan Resource Management, and Plan Communications

These processes ask: How will we ensure delivery meets expectations? Who will do the work? And how will we keep everyone informed along the way?

In Plan Quality, you define standards and how you’ll test against them — using benchmark studies, cost of quality, and design for X approaches. Plan Resource Management identifies roles, responsibilities, and reporting structures. Tools like hierarchical charts, RACI matrices, and organizational theories support clarity. Plan Communications determines how stakeholder needs will be met: what gets communicated, when, how, and to whom.

Each process produces its own plan — and together, they ensure that project delivery is not just possible, but visible and understood.


Plan Risk Management, Identify Risks, Perform Qualitative and Quantitative Risk Analysis, Plan Risk Responses

Planning isn’t complete without forecasting uncertainty. This sequence of processes builds the risk planning framework from identification through prioritization and response design.

Plan Risk Management sets the tone: how risk will be defined and tracked. Identify Risks gathers threats and opportunities through interviews, checklists, and prompt lists. Perform Qualitative Risk Analysis scores them by probability and impact; Quantitative Risk Analysis models them numerically, often using simulation. Finally, Plan Risk Responses decides what to do: avoid, mitigate, transfer, exploit, or accept.

The ITTOs here involve data gathering, analysis, and expert facilitation. Outputs include the risk register, risk report, and a plan for how you’ll respond — before risks become problems.


Plan Procurement Management

This process defines how the project will interact with external vendors — from what needs to be purchased, to how contracts will be structured and managed. Inputs include the scope and schedule; tools include market research and make-or-buy analysis. Outputs range from the procurement management plan to bid documents and source selection criteria.

Effective planning here avoids future disputes. It ensures procurement timelines match project needs and that vendor engagement follows organizational policy.


Plan Stakeholder Engagement

This final Planning process maps how stakeholder expectations will be managed and aligned throughout the project. It draws heavily on the stakeholder register, EEFs, and communication preferences — and uses interpersonal tools, analysis methods, and engagement models to develop a strategy.

The result is a stakeholder engagement plan — a playbook for maintaining alignment, trust, and transparency as the project unfolds.


What You Should Take Away

Planning is where all the pieces begin to fit together. The ITTOs aren’t standalone facts — they are interdependent building blocks of project readiness. Most of them feed forward into Executing, Monitoring, and Controlling.

On the exam, you won’t be asked to list them. You’ll be shown a scenario that asks:

Did the project manager plan correctly for this?

Your job is to recognize which planning outputs should exist — and whether they were applied well or missed entirely.


Questions Worth Exploring

  • What’s the difference between a plan and a baseline?
  • Why is the Planning process group the largest in terms of ITTOs?
  • How do planning artifacts shift when using Agile or hybrid delivery?
  • Which planning processes depend most on stakeholder engagement?
  • What happens if quality, risk, or procurement plans are skipped or rushed?

Back to the Top

Section Contents