A road vs a set of moves: the project life cycle and the five process groups
Two concepts that are constantly confused — let's pull them apart first.
Project life cycle = the series of phases a project passes through from start to finish: each phase produces a set of deliverables, and at the end of a phase there is often a 'phase gate' — a go/no-go decision on whether to keep investing or stop here.
The five process groups = Initiating, Planning, Executing, Monitoring & Controlling, and Closing — IPECC for short. They are not the five phases of a project, and not five sequential steps; they are groups of management activities that recur within every phase — each phase gets its own mini-initiating, mini-planning, mini-executing, mini-monitoring, and mini-closing.
IPECC stands for Initiating, Planning, Executing, Monitoring & Controlling, and Closing. Initiating clarifies why the project exists and who decides; its outputs include the charter and stakeholder list. Planning aligns scope, schedule, and cost through plans and baselines. Executing organizes people and resources to produce deliverables and work records. Monitoring & Controlling compares actual results with the baseline, producing performance information and change requests. Closing secures acceptance, lessons learned, and archives. When a project stalls, use IPECC to locate the gap: unclear decisions point to initiating; repeated rework often points to planning or change control. These are process groups, not strictly sequential phases—they overlap and iterate.
The on-site project management quiz covers these five process groups.
IPECC one by one: from charter and baselines to change control and lessons learned
Initiating: formally approving and authorizing the project. Two core outputs: (1) the project charter — the project's 'birth certificate,' issued by the sponsor, granting the project manager the authority to apply resources, and stating high-level objectives, scope summary, milestones, and the business case; (2) stakeholder identification — listing everyone affected by, or able to affect, the project, in a stakeholder register. A project without a charter has no legitimacy: the PM can't mobilize resources, the scope stays fuzzy, and when disputes arise there is nothing to point to.
Planning: elaborating 'what to do and how' into the project management plan (PMP) — subsidiary plans for scope (WBS), schedule (critical path), budget, quality, risk, resources, communications, and procurement — and setting the three baselines: scope baseline, schedule baseline, and cost baseline, the yardsticks against which execution is later measured. Planning is iterative / rolling-wave: coarse for the far term, detailed for the near term — never fixed in one pass.
Executing: where the real work happens and the plan is turned into deliverables — and where most of the time and budget gets spent. The project manager's focus shifts from 'writing the plan' to 'leading people and coordinating': staffing and developing the team, securing resources, managing quality, driving communication, and maintaining stakeholder engagement.
Monitoring & Controlling: not a standalone phase, but an activity that runs throughout the project, in parallel with the other process groups: while work is being done, actual progress/cost/quality is continuously compared against the baselines, and deviations are corrected — catch variances early and respond early, instead of finding out when the project is about to collapse. A key responsibility is integrated change control: any change to scope, schedule, or budget must go through a formal process — assess the impact, get approval, then update the baseline — which is what blocks scope creep.
Closing: bringing the project (or a phase) to a formal end — obtaining the customer's/sponsor's formal acceptance, handing over deliverables, settling contracts, releasing the team and resources, and archiving documents. The step most often skipped yet most valuable in the long run is the retrospective: capturing lessons learned — writing down the pitfalls and the practices that worked, and feeding them to the next project. Without formal closing: deliverables left hanging, resources occupied indefinitely, no official 'done' for the team, and the organization repeating the same mistakes again and again. A project shouldn't fizzle out — it should close the door properly, with a real beginning and a real end.
Predictive, adaptive, or hybrid? Choose by uncertainty — and change early
The life cycle itself is a choice, and the criterion is 'how certain is the scope':
- Predictive (waterfall) — scope, schedule, and cost are pinned down fairly firmly at the start; the project advances phase by phase, with stage gates between phases for go/no-go decisions. Suits work where requirements and technology are both well understood and change is rare (constructing a building, mass production).
- Adaptive (agile) — iterative and incremental; scope evolves with feedback. Suits highly uncertain work with volatile requirements (software, new products).
- Hybrid — part predictive, part adaptive: for example, hardware runs waterfall while software runs agile.
There is no universal best: choose the life cycle by the project's degree of uncertainty — don't force waterfall onto an innovative project, and don't force agile onto compliance-driven work that must be pinned down up front.
自测 · 学完检查一下
想真正动手做题、记进度、攒连胜？到互动课里练。
Which statement about the relationship between the project life cycle and the five process groups (IPECC) is correct?
答案：The life cycle is the series of phases a project passes through from start to finish; the process groups are groups of management activities that recur within every phase — they are neither project phases nor sequential steps
The project life cycle = the series of phases a project passes through; each phase produces a set of deliverables and often ends with a phase gate for a go/no-go decision. The five process groups (Initiating, Planning, Executing, Monitoring & Controlling, Closing — IPECC) are not project phases and not sequential steps; they are groups of management activities that recur within every phase — each phase gets its own mini-initiating, mini-planning, mini-executing, mini-monitoring, and mini-closing. In one line: the life cycle is 'the road the project travels'; the process groups are 'the set of moves made on every stretch of that road.' (Sources: PMI, PMBOK Guide — Project Life Cycle & Process Groups; MPUG, 'Process Groups are not Project Phases')
What are the two core outputs of the Initiating process group?
答案：The project charter (issued by the sponsor, granting the project manager the authority to apply resources) + the stakeholder register
Initiating formally approves and authorizes the project, with two core outputs: (1) the project charter — the project's 'birth certificate,' issued by the sponsor, granting the PM the authority to apply resources, and stating high-level objectives, scope summary, milestones, and the business case; (2) stakeholder identification — captured in a stakeholder register. A project without a charter has no legitimacy: the PM can't mobilize resources, the scope stays fuzzy, and disputes have nothing to point to. The WBS, critical path, and three baselines belong to Planning; acceptance and lessons learned belong to Closing. (Source: PMI, PMBOK Guide — Initiating Process Group)
Which three are the 'three baselines' set by the Planning process group?
答案：Scope baseline, schedule baseline, cost baseline
Planning elaborates 'what to do and how' into the project management plan (PMP) and sets the three baselines: the scope baseline, the schedule baseline, and the cost baseline — the yardsticks for 'executing against the plan and measuring variance'; Monitoring & Controlling works precisely by comparing actual performance against these three baselines. Also remember: planning is iterative / rolling-wave — coarse for the far term, detailed for the near term, never fixed in one pass; and the subsidiary plans are interlinked (a scope change moves schedule and cost too), so they must be coordinated as a whole. (Source: PMI, PMBOK Guide — Planning Process Group (Project Management Plan & baselines: scope/schedule/cost))
True or False: Monitoring & Controlling is not a standalone phase that comes after Executing; it runs throughout the project, in parallel with Executing and the other process groups — comparing against baselines and collecting progress data while the work is being done.
答案：True
True. Monitoring & Controlling is not a standalone phase; it runs throughout the project, in parallel with the other process groups: actual progress/cost/quality is continuously compared against the baselines, and deviations are corrected. Executing is not head-down grinding either — it proceeds in step with monitoring, comparing against baselines and collecting progress data as the work is done. Plans falling behind reality is the norm; monitoring's value is catching variances early and responding early, not finding out when the project is about to collapse — without monitoring, even the best plan is just wishful thinking from day one. (Sources: PMI, PMBOK Guide — Monitoring & Controlling Process Group; Executing Process Group)
Halfway through execution, an important stakeholder asks to add a new feature to the scope. Under integrated change control, what should the project manager do?
答案：Follow the formal change process: assess the change's impact on scope/schedule/cost, and once approved, update the baseline first, then execute against the new baseline
Integrated change control requires that any change to scope, schedule, or budget go through a formal process — assess the impact, get approval, then update the baseline — and this is exactly the mechanism that blocks scope creep. Agreeing on the spot or building it quietly lets unassessed changes bypass the baselines, and scope slips out of control bit by bit; 'reject everything' is wrong too — change control doesn't forbid change, it makes change pass through assessment and approval so it enters the baseline with a traceable basis. (Source: PMI, PMBOK Guide — Perform Integrated Change Control)
Which statement about the Closing process group is correct?
答案：Closing means obtaining formal acceptance, handing over deliverables, settling contracts, releasing the team and resources, and holding a retrospective to capture lessons learned — the step most often skipped yet most valuable in the long run is exactly the retrospective
Closing brings the project (or a phase) to a formal end: obtaining the customer's/sponsor's formal acceptance, handing over deliverables, settling contracts, releasing the team and resources, and archiving documents; the step most often skipped yet most valuable long-term is the retrospective — capturing lessons learned and feeding the pitfalls and effective practices to the next project. Without formal closing: deliverables left hanging, resources occupied indefinitely, no official 'done' for the team, and the organization repeating the same mistakes over and over. A project should close the door properly, not fizzle out. (Sources: PMI, PMBOK Guide — Closing Process Group; projectengineer.net — Closing: formal acceptance + lessons learned)
Two projects: A is an exploratory new product with highly uncertain requirements that must adapt quickly to user feedback; B is a building constructed to finalized blueprints, with clear requirements and technology and few changes. How should the life cycles be chosen?
答案：Use adaptive (agile) for A, evolving through iterations, and predictive (waterfall) for B, advancing phase by phase — choose by degree of uncertainty
Life cycles are chosen by 'how certain the scope is': predictive (waterfall) pins scope/schedule/cost down fairly firmly at the start with stage gates between phases — suited to work where requirements and technology are clear and change is rare (constructing buildings, mass production); adaptive (agile) is iterative and incremental with scope evolving through feedback — suited to highly uncertain, volatile-requirement work (software, new products); hybrid mixes the two (e.g., hardware on waterfall, software on agile). There is no universal best — don't force waterfall onto an innovative project, and don't force agile onto compliance-driven work that must be pinned down up front. (Sources: PMI, PMBOK Guide — Development Life Cycles; PMI, Agile Practice Guide)
True or False: Making a fundamental change costs about the same early or late in a project, so it's fine to defer directional decisions to the end of execution.
答案：False
False. Early in a project, uncertainty and risk are at their highest, but the cost of change is at its lowest; the later you go, the more expensive changes become — revising a design document early is cheap, while changing a delivered, live system is extremely expensive (this is the classic cost-of-change curve). So invest effort up front to get the direction right, and don't defer fundamental changes to the end of execution. 'Changing things costs the same at any stage' is exactly the first illusion this lesson sets out to break. (Sources: PMI, PMBOK Guide — uncertainty highest and cost of change lowest early in the project; Boehm B. — cost of change curve)
True or False: Initiating and closing are 'mere formalities' — starting work without a charter and finishing without acceptance or a retrospective has no real impact on the project.
答案：False
False. Skipping initiating = no charter and no authorization: the PM can't mobilize resources, the scope stays fuzzy, accountability is murky, and disputes have nothing to point to. Skipping closing = no acceptance and no retrospective: deliverables left hanging, resources occupied indefinitely, the project fizzles out, and with no lessons learned captured, the organization repeats the same mistakes again and again. 'Initiating/closing are formalities you can skip' is the second illusion this lesson breaks — a solid initiation saves arguments later, and a complete closing is how the organization actually learns. (Sources: PMI, PMBOK Guide — Initiating Process Group; Closing Process Group)
True or False: A plan is always better the more detailed and the more firmly fixed it is — even for a highly uncertain, innovative project, everything should be pinned down before work starts.
答案：False
False. Planning itself is iterative / rolling-wave: coarse for the far term, detailed for the near term — never fixed in one pass; for highly uncertain projects, trying to pin everything down up front is waste of another kind — which is exactly why adaptive (agile) life cycles exist, letting scope evolve with feedback. The right posture is to balance 'set the direction early to cut late-change costs' against 'don't over-plan up front,' calibrated by uncertainty: too little planning makes execution chaotic, while over-planning a highly uncertain project is waste. (Sources: PMI, PMBOK Guide — Planning Process Group (rolling-wave planning); PMI, Agile Practice Guide)