原标题：“半路出家”的项目经理人，是怎么管理项目的？

大家好，我是孙敏，毕业17年，当过程序员，去过大厂，也创过业，还经过4年职业生涯空窗期，做过产品经理，现在是一名项目经理。

我的从业经历，在《给项目经理人备考PRINCE2的8个建议》的内容中已经介绍过了，在这里就不过多赘述了。今天主要想跟大家聊一聊我在学习过PRINCE2之后应用于项目实践的两个小案例。

由于今年，在实际的大项目管理过程中遇到一些比如：进展无法控制、其他部门团队人员不好合作、复杂产品的需求怎么分解到不同团队等问题我不知道如何解决，于是启动了成功的项目管理方法论PRINCE2的课程学习。

目前，我已经拿到了PRINCE2从业级的认证证书。学习过后，我有将自己所学到的内容，尝试着应用到我自己的项目当中，我是如何将PRINCE2应用到实际的工作当中的呢？

案例一

项目概况：

作为乙方，负责跨6个部门的软件产品研发类项目，人力投入月均80人+，有对外交付，2个月一个版本。

最开始，也就是我在学习PRINCE2之前，需求分解成活动来跟踪，发现跟踪粒度太细，而且活动做完需求是否做完并不好分辨。

在学习过PRINCE2的版本周期中：

● 首先分析项目情况，根据PRINCE2的五性雷达图，分析出该项目跨职能度/独特性较高高、变革性一般，所以应该关注组织、计划和进展，同时要注意商业论证。

在实际项目过程中，是跨了6个部门，所以利用发起人公司副总以及集团的影响力，让这些部门领导达成共识，该产品是公司重点产品，应该给予适当的人力倾斜保证进度，相关的项目进度等简报信息时刻抄送这些部门领导，保持项目关注度，同时有问题也容易协调。

● 其次，团队中有10个团队，每个团队都有TM，所以对于每个团队都定义容许偏差，比如影响进度在一周以内的问题团队内部解决，超过一周的必须上报解决，如果突破2周的进度偏差就再上报。

在吸取了需求分解成活动追踪，颗粒度太细的经验后，将需求分解成子需求，需求描述以及完成定义写清楚（工作包），再用工作包分配给TM跟踪进度。

至于工作包怎么分解成活动，是TM的事情，我只负责验收和跟踪工作包，这样既减轻了我的关注精力，也较容易跟踪。

2个月的版本周期切分成每周一个检查点，2周一个阶段，毕竟2个月的时间并不是特别长，所以每周做哪些需求的计划在本次迭代周期初已经固定。

每周五检查当周完成的进展时，下周的计划只是微调，有计划才能检查出与基线的偏差，然后根据偏差做出适当的调整（我们公司很多项目，可能PM觉得简单根本不做计划，或者觉得麻烦也不做计划，这样我认为特别不好，失控没都不知道，最后一刻才爆发）。

每个版本发布后，在下个版本计划之前会去跟发起方讨论，下一步的详细计划，大版本发布后会邀请所有相关部门的负责人一起开总结会，明确现在的成果、不足，同时也收集各相关方的需求，作为版本规划的依据，对后续版本路线进行适当调整，类似商业论证。