PMP Exam Prep Companion: Process Groups Explained Without the Jargon

Think of the five process groups as a workflow you cycle through to move a project from “worth doing” to “done and accepted.” On the exam, they are less about memorizing labels and more about recognizing what kind of work is happening in a scenario: getting permission to start, deciding how you’ll work, doing the work, checking and adjusting, and formally finishing.

Initiating (Start with permission and clarity)

Purpose (what Initiating is trying to accomplish)

Initiating answers: “Should we do this, and who has authority to proceed?” The goal is to establish a shared understanding of the project’s intent and to name the person/team accountable for leading it. You are not building the full plan here; you are getting the green light and basic boundaries.

Typical inputs in plain language

• Business need or problem statement (why this matters now)
• High-level requirements (what success roughly looks like)
• Assumptions and constraints (what you’re taking as true; what limits you)
• Stakeholder information (who cares, who decides, who is impacted)

Typical outputs in plain language

• Approved project charter (official permission to start; who the sponsor is; high-level scope, budget, timeline targets)
• Initial stakeholder list (who to engage first and how influential they are)

Common exam actions (what the PM does first/next)

• First: Confirm the project has an authorized sponsor and a clear business reason.
• Next: Help create/clarify the charter and identify key stakeholders early (especially decision-makers and those most impacted).
• Exam clue words: “authorize,” “charter,” “high-level,” “sponsor approval,” “identify stakeholders.”

Practical step-by-step: a realistic Initiating flow

1. Clarify the objective: Ask what problem is being solved and what “done” means at a high level.
2. Confirm authority: Ensure the sponsor can approve funding and priorities.
3. Capture boundaries: Note major constraints (deadline, budget cap, regulatory limits).
4. Identify key stakeholders: Start with sponsor, customer, users, operations, vendors, compliance.
5. Get the charter approved: Without this, you don’t have formal permission to spend significant effort.

Planning (Decide how you will deliver)

Purpose (what Planning is trying to accomplish)

Planning answers: “How will we do this work, in what order, with what resources, and how will we manage changes?” The goal is an approved plan (often called the project management plan plus supporting documents) that the team can execute and that you can measure against.

Typical inputs in plain language

• Approved charter (your starting authority and high-level targets)
• Stakeholder needs and expectations (what different groups consider success)
• Organizational standards (templates, policies, required approvals)
• Lessons learned from similar work (what to repeat/avoid)

Typical outputs in plain language

• Approved plan (how scope, schedule, cost, quality, resources, communications, risk, procurement, and stakeholders will be managed)
• Scope baseline (what is included/excluded; detailed deliverables)
• Schedule baseline (timeline you will measure against)
• Cost baseline (budget you will measure against)
• Risk register (top risks, triggers, responses, owners)
• Communication plan (who gets what info, when, and how)

Common exam actions (what the PM does first/next)

• First: Clarify requirements and define what “done” means for deliverables.
• Next: Break work into manageable pieces, sequence it, estimate it, and build a realistic schedule and budget.
• Then: Plan how you will manage risks, quality, communications, and changes.
• Exam clue words: “baseline,” “define scope,” “WBS,” “estimate,” “plan risk responses,” “management plan.”

Practical step-by-step: planning as a workflow (not a document dump)

1. Define deliverables: Translate needs into clear deliverables and acceptance criteria.
2. Decompose the work: Break deliverables into smaller work packages (so you can estimate and assign).
3. Sequence and estimate: Put work in order, estimate effort/duration/cost, identify dependencies.
4. Build baselines: Create the schedule and budget you will track performance against.
5. Plan “how we manage”: Decide how changes are requested/approved, how quality is checked, how risks are handled, how stakeholders are engaged.
6. Get approval: The plan is only useful when it’s agreed to and usable by the team.

Executing (Do the work and produce results)

Purpose (what Executing is trying to accomplish)

Executing answers: “How do we produce the deliverables and keep people aligned while doing it?” The goal is to turn the plan into work results: completed deliverables, completed activities, and engaged stakeholders.

Typical inputs in plain language

• Approved plan and baselines (the playbook and targets)
• Team availability and resources (people, tools, materials)
• Approved change requests (updates you’re allowed to implement)
• Quality standards (what “good” looks like)

Typical outputs in plain language

• Work results (completed tasks, created deliverables, progress updates)
• Deliverables ready for review (items that can be inspected/validated)
• Issue log updates (new problems and who owns them)
• Team performance information (capacity, productivity, blockers)

Common exam actions (what the PM does first/next)

• First: Direct the team using the approved plan (don’t “wing it” when a baseline exists).
• Next: Manage communications and stakeholder engagement so expectations stay aligned.
• Then: Implement only approved changes; log issues and remove blockers.
• Exam clue words: “manage team,” “perform work,” “implement,” “deliverable produced,” “stakeholder engagement,” “issue.”

Practical step-by-step: executing without losing control

1. Kick off the work: Confirm roles, working agreements, and near-term priorities.
2. Produce deliverables: The team completes tasks and creates outputs.
3. Communicate continuously: Share status, risks, and decisions per the communication plan.
4. Handle issues: Log, assign owners, escalate when authority is needed.
5. Request changes when needed: If something impacts scope/schedule/cost, raise a change request rather than quietly adjusting baselines.

Monitoring & Controlling (Check reality vs plan and adjust)

Purpose (what Monitoring & Controlling is trying to accomplish)

Monitoring & Controlling answers: “Are we on track, and what should we do about deviations?” The goal is to compare actual performance to the approved plan, control changes, and keep the project aligned with objectives. This is not a phase that happens after Executing; it runs alongside it.

Continue in our app.

• Listen to the audio with the screen off.
• Earn a certificate upon completion.
• Over 5000 courses for you to explore!

Or continue reading below...

Download the app

Typical inputs in plain language

• Approved plan and baselines (what you promised)
• Work results (what actually happened)
• Risk register and issue log (what might happen; what is happening)
• Quality requirements (what must be met)

Typical outputs in plain language

• Performance reports (status, forecasts, variances)
• Change requests (requests to adjust scope/schedule/budget or correct problems)
• Accepted deliverable (when the customer/sponsor formally agrees a deliverable meets criteria)
• Updates to plans and logs (risk updates, issue updates, revised forecasts)

Common exam actions (what the PM does first/next)

• First: Measure current performance against the baseline (identify variance before acting).
• Next: Determine root cause and options (corrective action, preventive action, or change request).
• Then: Use formal change control when baselines or scope are impacted; don’t bypass approvals.
• Also: Validate deliverables with the customer to get formal acceptance.
• Exam clue words: “variance,” “forecast,” “change control,” “approve/reject change,” “validate,” “acceptance,” “corrective action.”

Practical step-by-step: what to do when something is off track

1. Detect the gap: Compare actual progress/cost/quality to the baseline.
2. Assess impact: Determine how the gap affects objectives and constraints.
3. Choose the right response:
   • Corrective action: fix current deviation (e.g., re-sequence work).
   • Preventive action: reduce likelihood of future deviation (e.g., add peer reviews).
   • Change request: adjust baseline/scope because the plan itself must change.
4. Get approval when required: Follow the change control process.
5. Update plans and communicate: Keep stakeholders aligned with the new reality.

Closing (Finish formally, not informally)

Purpose (what Closing is trying to accomplish)

Closing answers: “Are we truly done, and have we captured what we learned?” The goal is to formally complete the project or phase, confirm accepted deliverables, close contracts if any, and ensure knowledge is captured so the organization benefits.

Typical inputs in plain language

• Accepted deliverables (proof the customer agreed the work meets criteria)
• Project records (plans, logs, approvals, reports)
• Contract documentation (if vendors were used)

Typical outputs in plain language

• Formal sign-off / closure confirmation (documented completion)
• Final reports (what was delivered, final cost/schedule, outcomes)
• Lessons learned archive (what to repeat/avoid next time)
• Released resources (team members reassigned; tools returned)

Common exam actions (what the PM does first/next)

• First: Confirm deliverables are accepted (don’t close without acceptance).
• Next: Complete administrative closure: finalize documents, close procurements, archive records.
• Then: Capture lessons learned and release the team/resources.
• Exam clue words: “formal acceptance,” “close contract,” “archive,” “lessons learned,” “release resources.”

Practical step-by-step: closing a project or phase

1. Verify acceptance: Ensure acceptance criteria are met and documented.
2. Close open items: Resolve remaining issues or document handoff plans.
3. Finalize vendor work: Confirm deliverables, settle invoices, close contracts.
4. Archive and report: Store key documents and publish final performance results.
5. Capture learning: Record what worked, what didn’t, and why.

Mini-map: how process groups overlap (and how the exam jumps between them)

Real projects don’t move in a clean straight line. Planning, Executing, and Monitoring & Controlling run in loops, and Initiating/Closing can happen multiple times (per phase).

Overlap map (simple mental model)

Initiating → Planning → Executing → Closing  (big picture)  But day-to-day looks like: Planning ↔ Executing ↔ Monitoring & Controlling (repeat)  And at the end of a phase: Closing → (next phase) Initiating/Planning again

How exam scenarios “jump”

• Executing → Monitoring & Controlling jump: You’re doing work, then a variance appears. The exam often expects you to measure/assess before acting, then follow change control if needed.
• Planning → Executing jump: Once the plan is approved, the next best action is usually to direct work and communicate, not to keep refining documents.
• Monitoring & Controlling → Planning jump: Approved changes often require updating the plan/baselines and re-communicating expectations.
• Monitoring & Controlling → Closing jump: When deliverables are accepted and objectives met, the next step is formal closure activities, not “keep monitoring.”