PRINCE2 7 计划主题
本文是PRINCE2 第7章，计划主题的学习笔记。本章主要介绍项目计划，项目计划的构成，项目计划的编制。具体介绍了一步一步的项目计划编制方法。
PRINCE2与PMP的计划编制内容大同小异，区别在于PRINCE2强调用以产品为基础的计划编制，PMP是以WBS为基础的计划编制。核心都是将整个项目的交付物进行分解，然后通过自下而上的估算，计算出每个活动所需要的资源、时间、成本，再构成项目的总体计划、成本。
《大型网站技术架构：核心原理与案例分析》学习笔记 01
本系列来源于《大型网站技术架构：核心原理与案例分析》学习笔记总结，本文为本书“第1篇 概述”的总结。
- 介绍《大型网站技术架构：核心原理与案例分析》的全书结构
- 第一部分概述的主题内容：大型网站架构演化、架构模式、架构要素
- 笔记为知识点摘要、总结，对于知识结构的总结
作为一个非技术出身的项目经理，工作中遇到的各类技术问题往往是困扰我们的一个大问题。对于这个问题，除了在工作中频繁与技术同事沟通，项开发的同事学习之外，也需要自己在工作之余不停的补充相关技术知识，能够做到听懂同事在说什么，从逻辑上理解他们的解决方案。项目中经常涉及系统架构，阅读、协助撰写架构文档。最近的一个项目是需要为客户开发一个中型网站，了解网站相关的架构知识，是学习这本书的目标。
｜
项目管理_04 项目进度管理的关键路径法和关键链法
摘要：本文以案例的形式介绍了同一个项目分别以关键路径法和关键链法做进度规划得出的两种进度计划，比较了两种进度计划方法的不同和优缺点。
项目管理的关键链法是关键路径法的一个延伸。其主要目的是避免糟糕的多任务制，“帕金森法则”和“学生综合症”。
关键路径法
那么关键路径法是什么，又是怎样实施的呢？
关键路径，就是完成项目所需要的最长路径和最短时间。很拗口，举个例子。一个项目，首先做WBS，分解出6个工作包。如下图：
画出它的关键路径
可以看到，关键路径是上面那条，时间为21天。
用MS Project的Gantt图表示：
项目时长 = 关键路径 = 21天
注意，其中有一天的时间作为buffer，在task3后面。
关键路径法的弊端
那关键路径法有什么弊端呢？
首先，关键路径要求项目的变化很少。一旦有变化，关键路径上的task时间延长，整个项目时间延长。
第二，这样简单的做关键路径规划，没有考虑资源的使用。比如上面的R2就同时在做Task2和Task5，这也很可能不能按期交付。
第三，buffer时间的使用并不效率。比如驾驶Task1实际使用了4天就完成，但是Task2仍然在第6天开始这种情况。还有就是最开始说的“帕金森法则”（Parkinson’s Law) 和
“学生综合症”(Student Syndrome)
项目管理_03 PMBOK第五版软件分册
很多人不知道，PMBOK除开它本身之外，还有很多行业分册。如软件行业，就有软件分册，由PMI和IEEE合著。既然是合著，就表示这本分册中的概念和方法会同时符合两个机构的理念。
如今的软件行业已经越来越往敏捷的方向发展。我们在工作中常常遇到，其实PMP这一套并不怎么实用。曾经有一次面试，面试官问我是如何将PMP中学到的知识运用到现实的工作中的。我瞬间懵了一下，努力回想自己平常工作中的运用。然而这个问题答的也不是很好。
偶尔看到这本书，发现这便是可借鉴的标准答案，PMI是如何将它的项目管理方法论运用到软件行业的呢？
首先看书的框架。见下图：
从框架上看，与PMBOK的第五版并没有什么不同。都是首先总体介绍，然后讲项目生命周期和项目管理流程，最后讲几大知识域。
继续翻看，从生命周期看，PMI将结合了软件行业不同的生命周期类型来匹配了自己的项目管理流程。
如瀑布式：
迭代式：
Scrum理念的
从PMI的角度来看，软件行业可以选择不同的生命周期，但每个生命周期都必须经历的项目管理过程组是一定的。瀑布式的项目更是在每个阶段都会经历一次完整的项目管理周期。这也是PMI一直强调的产品生命周期与项目管理生命周期的区别。
其后的每个知识域，这本书都突出写明在软件行业的特定条件下，项目应该怎么管。大多数的输入输出都直接指到了PMBOK 第五版。我们在阅读的时候可以着重看一下，书中写的特殊活动。比如在整合项目管理中，就写到了项目经理在管理适应性项目中应该做的活动；软件项目信息披露应该包括哪些部分。甚至写到了项目组中需要有一个大的显示装置——纸质的或电子的——让团队成员可以一眼看出项目现在的状态，这也的良好做法。
在软件项目管理中，我们有太多新式的管理方法论。PMI这样的庞杂的系统往往看似冗余。但是这本书对于软件项目经理平常翻看也有一定的参考意义。
项目管理案例分析_03 如何开经验教训总结会
此案例选自 Project Management Case Studies and Lessons Learned: stakeholder, scope, knowledge, schedule, resource and team management, M. Kemal Atesmen, CRC Press, 2015, P51-53
团队成员
高层领导
客户
分包商
案例简介：
一个为期两年的项目已经交付，客户和公司高层都对项目结果表示满意。在做最终的经验教训总结之前，项目经理被安排去海外处理一个紧急的问题，为期三周。当项目经理回来准备经验教训会的时候发现，原来的项目组成员都已经被分配到其他的项目中去了，很难把大家的时间凑期。有两个成员甚至被分到了日本项目。而且大家对于此类项目总结会的兴趣下降的很快，大家手里都有更重要的事情要做。
项目经理凑齐了10个项目组成员中的8个，开了一个午餐会。项目经理自掏腰包给大家买了午餐。午餐会上项目经理向大家提出了经验教训总结的列表，并组织大家讨论以后如何避免类似的情况发生。过后，项目经理又分别与在日本和德国的成员开了视频会议。项目经理也发起了要请高层参加的经验教训总结会，只有一半的人参加了回忆。随后，项目经理还分别和客户项目经理、分包商（subcontractor）也进行了这样的讨论。
最终，项目经理发布了这个项目的经验教训列表和大家讨论的结果，以便之后的项目经理查阅。
经验教训列表包含了涉及以下几个方面的问题：团队人员、项目说明、公司相关、客户相关、分包商相关、项目进度和项目预算。在所有讨论的问题在，两个关于财务的问题凸显了出来。一个是国际结算时存在的汇率风险，另外一个是小批量采购导致单价上涨。这两个问题教训对于以后项目遇见类似问题时提供了一个很好的参考。
案例分析：
项目结束时期的经验教训总结会是很多项目组经常忽略的一件事。实际中，项目结果好还好，项目结果不好很容易开成吵架会，或责任推诿会。所以很多项目经理不愿意开这个会。
本案例想着重分析一下案例中的项目经理是如何组织这个经验教训总结会的。
案例中的项目是一个成功的项目，但是在做经验教训总结会之前，项目经理被调走三周，导致回来之后团队成员都被安排到别的项目组，凑不齐人。而且时间一长，大家都对开这样的会兴趣不大了。但项目经理还是坚持组织了这样的会议，并与几乎所有相关方进行了讨论。参与讨论的人包括：
- 团队成员
- 高层领导
- 客户项目经理
- 分包商
召集尽可能多的人进行讨论，实在无法凑在一起，可以分开讨论。
会议的议程上，项目经理没有撒漫的让大家去讨论，而是总结了一个问题列表，让大家就列表发表看法，以后如何避免出现类似的问题。我们可以看到会议议程可以简单如下面写：
- 项目经理介绍问题列表
- 与会人员讨论问题及以后避免方式
案例中还写了问题列表涉及哪些方面：
- 团队人员
- 项目说明书
- 公司相关
- 客户相关
- 分包商相关
- 项目进度
- 项目预算
我们可以看到，这个问题列表基本涉及了项目管理铁三角的内容和各相关方的内容
最后，项目经理将成文的经验教训总结发布出来，供之后的项目参考。这样真正让项目的价值、经验得以延续。
案例中最后项目经理也说，经验教训总结是一件非常费时的事情，但是其价值是巨大的。任何一个经验的吸收都可能对后期的项目产生积极的影响，就这一点，就给项目经理以足够的动力去完成这件事情。
Take-away:
经验教训总结会召开方法
时间：越早越好。拖的越晚，大家对开这样的会的兴趣越低。集齐尽可能多的人，实在不行，分开开也可以。不同的相关方分别开会。
与会人：项目参与的所有相关方。可能包括：
项目管理_02 浅谈PMO的职责
工作这些年，在三家公司做过PMO，2家500强企业，一家新兴美资外企。发现基本每家公司的PMO职责都不尽相同。与其他公司的PM聊天的时候，发现他们也是各有侧重。本文简单梳理了一些这些年PMO的工作内容和对于这个工作的一些思考。
PMO中文翻译为项目管理办公室。有个项目经理曾经问我，这个办公室里有什么角色，除了项目经理还有什么？我说还有PMO。他很不理解，为什么一个办公室也可以是一个岗位。
PMO具体做什么呢？在我最初做这个工作的时候，对这个问题思考了很久。当时的主要工作是日常的项目状态监控和项目流程梳理。不管具体项目，却涉及每个项目。对于这个工作，我当时找到的最贴切的方法论是项目治理。处于项目之上，考虑项目具体怎么管的工作。
后来的PMO工作涉及到了很多具体的方面，如财务、采购、资源协调等。我了解到，原来PMO还可以做这么多具体的事务，能够具体帮助到项目的进展。
再后来，通过与同行业的人沟通，发现一个平常我有做但是并没有重视的一个方面——项目的知识管理与信息分发。这部分其实一直都有在执行，但只是浅尝辄止，效果也不好。
总体来说，我将PMO的工作划分为以下三个大类：
1 制定项目管理标准
1）企业级项目管理方法裁剪
我所待过的每一家企业都有自己企业的项目管理方法，企业级的PMO会做这件事情。这里面用的方法是我们一直提到的“裁剪”。
“裁剪”这个词有两层含义：1）企业将行业标准裁剪成适合企业的标准；2）项目组将企业项目管理标准裁剪成适合其项目的管理方法
企业级PMO需要负责制定、修订适合企业的项目管理方法论。而且需要与时俱进、适时修订。老牌企业的项目管理方法论都是根据PMI制定的，当Agile出现之后，是否制定Agile项目管理方法？小企业也有类似的需求，每个项目怎么管，不是每个项目经理拍脑袋决定就可以，没有统一的标准就会变得天南海北。
2）企业级项目管理工具
很多公司会上线公司级项目管理系统，将所有项目从立项到结束，所有的流程、状态、文档都管理起来。PMO会牵头做这件事情。当然上线这套系统本身也是一个项目。
还有制定项目管理中所需的各种支持文档、模板，这大概是PMO们最熟悉的工作了。
2 日常业务活动
我将几个日常的活动规在此类，包括：
- 项目监控：进度、风险、问题
- 项目资金支持
- 资源协调
- 采购管理
1）项目监控
这也是PMO们经常做的事情。定期组织项目经理开会，汇报进度、问题和风险。然后形成报告，发给高层和各利益相关方。
由于项目众多，并不是每一个项目都应该受到同等程度的重视。所以我之前的公司会制定标准，将不同的项目分为不同的类别和重要程度。再结合项目状态，PMO和高层对不同的项目问题区别对待。
对于重大风险的控制也是PMO的一项主要工作。特别是存在关联关系的项目可能发生的连带反应，PMO需要及时反应并进行风险警示。
2）项目资金支持
不是所有公司都需要PMO来为项目提供资金支持。有一些公司，需要将很多项目打包，或者项目组合形式从外部组织寻求资金支持。这样的情况下，需要PMO牵头进行项目费用估算和预算谈判。我写过一篇案例分析是关于作为PMO进行的项目财务管理。项目管理案例分析02：项目组合财务管理
3）资源协调
这是很多项目经理会问到的一个问题。如果项目资源不足，项目经理自己无法争取到足够的资源的时候，PMO能不能帮忙进行资源协调。答案是肯定的。PMO应该了解各个项目的实际资源实际情况，从而采取必要的协调措施。实际角度出发，如果PMO层面也搞不定，那就找老板。
4）采购管理
这个模块跟项目集的采购管理很像。PMO收集不同项目的类似采购需求，通过发一个大的采购包的形式来降低采购成本，增加采购效率。
3 项目知识管理和信息分发
知识管理是最近很热的一个词，有很多相关的管理工具在市场上出现。特别是人工智能兴起之后，知识管理变得更为重要，思路也更开阔。这部分我接触的很少，思考的也不成熟，是以后自己要加强的部分。
在之前的工作中其实遇到过这样的困境。每个项目经理都管着自己的一摊子，不关心也没有什么渠道去了解别人在做什么。曾经产生了一个新的领域，公司几个大部门的不同小部门分别起了好几个项目来研究同一个领域，造成资源浪费，也不利于协同。
我们之前做过最基础的一步工作，通过wiki或者confluence为每一个项目建立一个简介文档，包括项目的基本情况和现阶段状态。这种开放式的编辑工具，让每个项目经理和团队成员都能随时更新其内容，也让大家都能自由的看到别的项目的情况。对于项目经理，这部分有些像额外的工作。但是当大家都这么做，规模都起来之后，便成了一个知识库。大家知道以前做了什么项目，自己现在做的项目是不是有相关性，是否能够找到相关的历史资料。
现在市场上有很多知识管理工具，很多公司也纷纷开始上线知识管理系统。这部分工作会越来越被企业和PMO重视起来。
项目管理_01 PMBOK第六版 – 3. 项目经理的角色
摘要：本篇为PMBOK第六版新增内容——第三章项目经理的角色——的学习笔记
3 项目经理的角色
3.1 概述
3.2 项目经理的定义
3.3 项目经理的影响力范围
3.4 项目经理的能力
3.5 执行整合
3.1 概述
成员与角色
项目经理像交响乐团中的指挥。项目成员承担不同的角色，项目经理指挥协调
在团队中的职责
项目经理为团队的成果负责
审查组织的愿景、使命和目标，确保与产品保持一致
解释与成功完成产品相关的愿景、使命和目标
像团队沟通自己的想法，激励团队完成目标
项目集管理_07 九大支持流程综述
摘要：本文综述从通用流程模型说起，综述项目集管理九大支持流程，介绍了流程学习的方法及项目集管理支持流程与项目管理的区别。
沟通管理
财务管理
整合管理
采购管理
质量管理
资源管理
风险管理
进度管理
范围管理
所有的理论、方法最后都必须要落实到流程和工具上，否则很难运用到实践中。项目集管理也是如此。PMI的这本书给出了九大支持流程来帮助大家日常工作的使用。
很多人谈流程色变。总觉得流程是很僵化、做很多没有用的事情。有些流程确实如此。但流程存在有其好处，对于组织来说其有利于规范工作方法，提高管理水平和效率；对于个人来说，刚接触的人可以快速了解做事的方法（我所在的公司甚至有每个阶段所需要做的每一个步骤、每个会需要问的问题的文档），对于经验丰富的项目经理也可以起到一个备查的作用。
流程，简单来说就是通过一系列的活动将输入变成输出的过程。不管是项目管理还是项目集管理，大家都更加关心交付物，即输出的产生。无论是固化的还是临时的将输入变成输出的过程，都可以叫做流程，是工作中不可避免的环节。
通用的流程模型中有几个模块：输入、过程、输出、流程控制、支持流程，如下图。学习流程的方法就是搞清楚每个流程的这几个部分。如此，对于一个流程就会有一个基本了解。
ITIL v3
我之前自己做过一个流程学习的excel表，通过这样模块化的方法来学习流程可以更加快速的在脑中建立关于某个流程的体系和其他流程的交互。
流程学习模板下载：流程学习模板
项目集管理九大支持流程包括：
项目管理案例分析02：项目组合财务管理
以下案例来自真是工作经验， 客户名称与具体项目内容已隐去。
项目组合全年预算
项目组合财务框架
资金流模式（资金流转通道）
资金支付方式（第一笔支付全年预算75%， 十月进行前九月结算和后三个月估算，支付剩余预算）
涉及领域：财务管理、干系人管理、风险管理
项目组合背景
该项目组合支持集团旗下所有品牌的某些服务在中国区的落地。所有服务已在国外开发完成，中国团队负责将打包好的服务部署在中国的云上。主要合作方有：总部项目团队、云服务商、本地软件服务商。资金来源为两个不同的总部项目团队。项目组合中组件项目，有的在当年完成，有的在之后的年份完成，但是预算以年为单位，每年计算。
过程简述：
年初项目组合成本估算
活动：
- 搭建项目组合成本框架
- 估算组件项目全年支出
- 与投资部门就估算达成一致
估算方法：专家经验
输出：