一条路 vs 一套动作：项目生命周期与五大过程组
两个最容易混为一谈的概念，先掰开。
项目生命周期（project life cycle）＝项目从启动到收尾所经历的一系列阶段（phase）：每个阶段产出一组可交付物，阶段末尾常设一个『阶段关口（phase gate）』，做『继续投入还是就此打住』的去/留决策。
五大过程组（process groups）＝启动 Initiating、规划 Planning、执行 Executing、监控 Monitoring & Controlling、收尾 Closing，简称 IPECC。它们不是项目的五个阶段，也不是先后走完的五个步骤，而是一组组管理活动，会在每个阶段里反复出现——每个阶段都要小启动、小规划、小执行、小监控、小收尾。
IPECC 逐个过：从章程与基准，到变更控制与复盘
启动（Initiating）：把项目正式批准、授权立项。两项核心产出：① 项目章程（project charter）——项目的『出生证』，由发起人签发，授予项目经理动用资源的权力，写明高层目标、范围概要、里程碑与商业理由（business case）；② 干系人识别——列出受项目影响或能影响项目的人/方，建干系人登记册。没有章程的项目等于没名分：调不动资源、范围说不清、出了分歧无据可依。
规划（Planning）：把『要做什么、怎么做』细化成项目管理计划（PMP）——范围（WBS）、进度（关键路径）、预算、质量、风险、资源、沟通、采购等子计划，并定出三大基准（baselines）：范围基准、进度基准、成本基准，作为后续『对照执行、衡量偏差』的标尺。规划是迭代/滚动的：远期粗、临近细，不是一次定死。
执行（Executing）：真正『干活』、把计划变成可交付物的地方——也是花掉最多时间与预算的地方。项目经理的重心从『写计划』转到『带人和协调』：调配并发展团队、保障资源、管理质量、推进沟通、维护干系人参与（engagement）。
监控（Monitoring & Controlling）：不是一个独立阶段，而是贯穿始终、与其它过程组并行的活动：边执行边把实际进度/成本/质量对照基准，发现偏差就纠偏——早发现、早响应，而不是等项目快崩了才知道。它的一项关键职责是整合变更控制（integrated change control）：任何对范围/进度/预算的变更都要走正式流程评估影响、批准后再改基准，挡住『范围蔓延（scope creep）』。
收尾（Closing）：把项目（或一个阶段）正式结束——拿到客户/发起人的正式验收、移交交付物、结清合同、释放团队与资源、归档文档。最容易被省略却最有长期价值的一步是复盘、总结经验教训（lessons learned）：把这次踩的坑与有效做法记下来，喂给下一个项目。不做正式收尾的后果：交付物悬而未决、资源被无限占用、团队没有正式『完成』的句号、组织一次次重复犯同样的错。项目不是『不了了之』，而是有始有终地关上门。
预测式、适应式还是混合式？按不确定性选，并趁早改
生命周期本身也要选型，标准是『范围有多确定』：
- 预测式（predictive／瀑布）——开工就把范围、进度、成本定得比较死，按阶段顺序推进，阶段间设关口（stage gate）做去/留决策。适合需求与技术都清楚、变更少的工程（建楼、量产）。
- 适应式（adaptive／敏捷）——迭代增量、范围随反馈演进。适合高不确定、需求易变的工作（软件、新产品）。
- 混合式（hybrid）——一部分预测、一部分适应，如硬件按瀑布走、软件按敏捷跑。
没有放之四海皆准的最佳：按项目的不确定程度选生命周期——别拿瀑布硬套创新项目，也别拿敏捷硬套需要前期定死的合规工程。
自测 · 学完检查一下
想真正动手做题、记进度、攒连胜？到互动课里练。
关于项目生命周期与五大过程组（IPECC）的关系，下面哪个说法是对的？
答案：生命周期是项目从启动到收尾经历的一系列阶段，过程组是在每个阶段里都会反复出现的一组组管理活动——它们不是项目阶段，也不是先后步骤
项目生命周期＝项目经历的一系列阶段（phase），每个阶段产出一组可交付物、末尾常设阶段关口做去/留决策；五大过程组（启动、规划、执行、监控、收尾，IPECC）不是项目阶段、也不是先后步骤，而是一组组管理活动，会在每个阶段里反复出现——每个阶段都要小启动、小规划、小执行、小监控、小收尾。一句话：生命周期是『项目走过的路』，过程组是『每段路上都要做的那套动作』。（出处：PMI, PMBOK Guide — Project Life Cycle & Process Groups；MPUG 'Process Groups are not Project Phases'）
启动（Initiating）过程组的两项核心产出是什么？
答案：项目章程（由发起人签发、授予项目经理动用资源的权力）＋ 干系人登记册
启动过程组把项目正式批准、授权立项，核心产出有二：① 项目章程（project charter）——项目的『出生证』，由发起人签发，授予项目经理动用资源的权力，写明高层目标、范围概要、里程碑与商业理由；② 干系人识别——建干系人登记册。没有章程的项目等于没名分：调不动资源、范围说不清、出了分歧无据可依。WBS、关键路径与三大基准属于规划过程组；验收与经验教训属于收尾过程组。（出处：PMI, PMBOK Guide — Initiating Process Group）
规划（Planning）过程组定出的『三大基准（baselines）』是哪三个？
答案：范围基准、进度基准、成本基准
规划把『要做什么、怎么做』细化成项目管理计划（PMP），并定出三大基准：范围基准、进度基准、成本基准——它们是后续『对照执行、衡量偏差』的标尺，监控过程组就是拿实际表现对照这三条基准来发现偏差的。另外记住：规划是迭代/滚动的，远期粗、临近细，不是一次定死；各子计划相互牵连（范围变→进度成本都变），要整体协调。（出处：PMI, PMBOK Guide — Planning Process Group（Project Management Plan & baselines：scope/schedule/cost））
判断：监控（Monitoring & Controlling）不是一个排在执行后面的独立阶段，而是贯穿项目始终、与执行等其它过程组并行进行的活动——边干活边对照基准、边收集进度数据。
答案：正确
正确。监控不是独立阶段，而是贯穿始终、与其它过程组并行：持续把实际进度/成本/质量对照基准，发现偏差就纠偏。执行也不是埋头蛮干——它和监控同步进行，边做边对照基准、边收集进度数据。计划赶不上变化是常态，监控的价值就是早发现偏差、早响应，而不是等项目快崩了才知道；没有监控，再好的计划也只是开工时的一厢情愿。（出处：PMI, PMBOK Guide — Monitoring & Controlling Process Group；Executing Process Group）
项目执行到一半，一位重要干系人提出要往范围里加一个新功能。按整合变更控制（integrated change control）的要求，项目经理最应该怎么做？
答案：走正式变更流程：评估该变更对范围/进度/成本的影响，获批后先更新基准，再按新基准执行
整合变更控制的要求是：任何对范围/进度/预算的变更都要走正式流程评估影响、批准后再改基准——这正是挡住『范围蔓延（scope creep）』的机制。直接答应或私下做掉，都是让未评估的变更绕过基准，范围就这样一点点失控；『一律拒绝』也不对——变更控制不是禁止变更，而是让变更经过评估与批准、有据可依地进入基准。（出处：PMI, PMBOK Guide — Perform Integrated Change Control）
关于收尾（Closing）过程组，下面哪个说法是对的？
答案：收尾要拿到正式验收、移交交付物、结清合同、释放团队与资源，并复盘总结经验教训——最容易被省略却最有长期价值的正是复盘
收尾把项目（或一个阶段）正式结束：拿到客户/发起人的正式验收、移交交付物、结清合同、释放团队与资源、归档文档；其中最容易被省略却最有长期价值的一步是复盘、总结经验教训（lessons learned）——把这次踩的坑与有效做法记下来喂给下一个项目。不做正式收尾的后果：交付物悬而未决、资源被无限占用、团队没有正式『完成』的句号、组织一次次重复犯同样的错。项目要有始有终地关上门，不是『不了了之』。（出处：PMI, PMBOK Guide — Closing Process Group；projectengineer.net — Closing：formal acceptance + lessons learned）
两个项目：A 是探索性新产品，需求高度不确定、要靠用户反馈快速调整；B 是照既定图纸施工的楼宇工程，需求与技术都很清楚、变更少。生命周期应该怎么选？
答案：A 用适应式（敏捷）迭代演进，B 用预测式（瀑布）按阶段推进——按不确定程度选
生命周期按『范围多确定』选型：预测式（瀑布）开工就把范围/进度/成本定得比较死、阶段间设关口，适合需求与技术都清楚、变更少的工程（建楼、量产）；适应式（敏捷）迭代增量、范围随反馈演进，适合高不确定、需求易变的工作（软件、新产品）；混合式则一部分预测、一部分适应（如硬件按瀑布、软件按敏捷）。没有放之四海皆准的最佳——别拿瀑布硬套创新项目，也别拿敏捷硬套需要前期定死的合规工程。（出处：PMI, PMBOK Guide — Development Life Cycles；PMI, Agile Practice Guide）
判断：项目早期和后期做根本性变更的代价差不多，所以方向性的决策拖到执行末期再定也没关系。
答案：错误
错误。项目早期不确定性与风险最高，但变更代价最低；越往后，改动越贵——早期改一版设计文档很便宜，上线后改已交付的系统极贵（这就是经典的变更成本曲线）。所以要在前期多花力气把方向定对，别把根本性变更拖到执行末期。『哪个阶段改都差不多』正是本课要破的第一个错觉。（出处：PMI, PMBOK Guide — 项目早期不确定性最高、变更成本最低；Boehm B. — cost of change curve）
判断：启动和收尾只是『走形式』——跳过章程直接开工、做完不验收不复盘，对项目没什么实质影响。
答案：错误
错误。跳过启动＝没章程没授权：项目经理调不动资源、范围说不清、权责不清、出了分歧无据可依；跳过收尾＝不验收不复盘：交付物悬而未决、资源被无限占用、项目烂尾，而且经验教训没有沉淀，组织一次次重复犯同样的错。『启动/收尾是走形式，可跳过』是本课要破的第二个错觉——启动做扎实后面少扯皮，收尾做完整组织才学得到东西。（出处：PMI, PMBOK Guide — Initiating Process Group；Closing Process Group）
判断：计划永远是做得越细、定得越死越好——哪怕是高不确定的创新项目，也应该在开工前把一切都算死。
答案：错误
错误。规划本身是迭代/滚动的：远期粗、临近细，不是一次定死；对高不确定项目，前期把一切算死是另一种浪费——正因如此才有适应式（敏捷）生命周期，让范围随反馈演进。正确的姿势是在『早定方向、降低后期改动成本』与『别过度前期规划』之间按不确定性拿捏：规划不足执行就乱，过度规划高不确定项目又是浪费。（出处：PMI, PMBOK Guide — Planning Process Group（滚动式规划）；PMI, Agile Practice Guide）