项目经理怎么知道每天该干什么

思考的牛

　　项目经理怎么知道每天该干什么

　　                                                            ——也许一本《项目经理手册》能解决问题

　　神州数码 软件服务本部 潘东

　　[内容提要]2004年神州数码在西安建立了软件开发基地，随着基地规模的不断扩张，大批新任的项目经理感觉管理工作繁杂，流程规范众多，经常是“一头雾水”、“无所适从”。问题的原因之一，是因为项目经理是个综合性很强的岗位，需要参与很多管理过程。为此，我们以项目经理为“中心”对流程进行了梳理，整理出了一本《项目经理手册》，使得项目经理的工作条理清晰，显著提高了流程“落地”的效果。

　　1 规模快速扩张时遇到的问题

　　2004年开始神州数码在西安建立软件开发基地，到07年时已经接近千人，成熟度达到了CMMi4，70%以上的金融软件开发任务也成功地转移到了西安基地。

　　但随着规模的快速增长，也出现了一个问题：尽管有明确的流程和规范，大批新任项目经理在执行时却不断出现错误和遗漏，过程逐渐“走形”，规范慢慢“退化”!而且，虽经不断提醒，甚至采取严厉的惩罚措施，仍没有好转的迹象。

　　“新项目经理”的不胜任，同时造成“老项目经理”的严重短缺，一时间合格的项目经理成了继续扩展的重要的瓶颈。

　　2 项目经理是怎么说的？

　　怎么解决这个问题呢?“解铃还须系铃人”，最直接的办法就是听听项目经理的意见。于是，管理团队多次与项目经理开会、沟通和访谈，就想弄清一个问题：为什么总是出现错误和遗漏?项目经理反馈了各种各样的原因，集中在以下几个方面：

　　a管理头绪多，弄不清什么时候该干什么;

　　b流程太多了!常用的还能弄清楚，不常用的很不熟悉，要用时找不着;

　　c有些流程只规定了怎么做，但没规定该什么时候做，不知道与日常工作什么关系;

　　d一遇到突发事件就比较慌乱，忘记了必须要作的事情;

　　听了这些意见，我也从项目经理的角度看了一下他们所需要面对的流程和规范，发现数量确实比较大，但这是因为项目经理岗位的综合性强所决定的客观事实。但同时也发现，过程文档的结构和流程定义的方式不利于指导项目经理的工作：

　　流程定义一般是将“某件事情分一二三四五步，其中有ABCD四个角色，每个角色的职责是什么”。从流程制定者角度看，这样的文档结构非常清楚。但对于项目经理这种要参与很多流程角色来说，要从“堆积如山”的流程中“挑出自己的职责”，并且弄清该什么时候去做，的确不是件容易的事。特别是那些新上任的项目经理，为此经常感觉“一头雾水”、“无所适从”也就可以理解了。

　　联想到有一种团队操表演：很多人同时举起不同的颜色的板子就可以拼出不同的图案，对观众来说，关注的肯定是“图案是什么”;但是，对于每个负责举板子的人来说，最重要的是要知道“什么时候该举哪块板子”。

　　此时大家才恍然大悟，明白了以前工作的失误之处：我们一直在跟项目经理描述每个图案是什么，而没有告诉他们该在何时举起哪块“板子”。要想让项目经理清楚什么时候该做什么，就必须从项目经理的角度出发组织过程文档。

　　3《项目经理手册》—以PM为中心重组过程

　　“从项目经理的角度出发组织过程文档”这一思路的具体措施，就是整理一本《项目经理手册》。这个想法很好，但如何做却不是件简单的事情，《手册》至少需要满足下面几个条件：

　　a只是换个角度梳理现有管理流程，而不是重新创造。因此，必须与现有流程保持一致，不能有遗漏或者冗余;

　　b不能简单的抽取，内容必须按照一定的规则组织起来，保证条例清晰

　　c内容必须与项目经理日常的工作内容挂起钩来

　　简单说，《项目经理手册》除了要让项目经理知道什么时间该做什么，还要保证“按照要求做了，所有的流程就被正确执行了”，这必须要一个的系统的方法才行。这时候，自然想起了“法宝”——《PMBOK》。受到其中过程组分类方法的启发，经过大家的讨论之后确定了以下的思路：

　　(1). 建立项目管理矩阵，纵向按照启动、计划、执行、控制和结束五过程组分类，横向按照项目管理9个管理域分类;

　　(2). 按照上述矩阵结构重新组织，将现有的过程和规范分别放到矩阵的不同“格子”里，形成一个描述项目经理工作内容的“项目管理框架”。training.mypm.net

　　(3). 对于项目管理框架上的活动，按照发生频度或场景进行分类，形成项目经理“活动一览表”。

　　(4). 对活动一览表中的每个活动进行详细描述，包括具体的步骤，使用的模版、工具或者IT系统，以及验证的检查点，完成《项目经理手册》。

　　下面以梳理神州数码西安开发基地所使用的《项目经理手册》为例，完整介绍一下整个过程。

　　4《项目经理手册》实例

　　4.1 建立项目管理矩阵

　　如前面所述，项目管理矩阵纵向按照启动、计划、执行、控制和结束五过程组分类，横向按照项目管理9个管理域分类。理论上这很简单，但实际上却需要化些功夫。

　　这是因为，PMBOK中的启动、计划、执行、控制、结束五个过程组理论上的定义，不能直接与业务流程进行映射。因此，必须从实际的业务流程中找到“标志”性事件作为切分点，将具体的管理流程进行分类重组。通过比对PMBOK定义和实际业务，找到了公司实际项目生命周期管理中的6个标志性事件：

　　(1)售前立项：识别出一个商务机会，在系统中建立项目号;

　　(2)签定合同：以法律形式确定项目责任;

　　(3)售中立项：内部准备完成，在PMC系统中批准执行;([注]：PMC，Project Management Center，神州数码内部使用的项目管理信息系统)

　　(4)组织监控：项目 “执行”过程中，项目经理正常的管理活动是“执行”活动;但是，某些受到组织级监控，并可以强制采取纠正措施的活动被认为是“控制”活动;

　　(5)验收开始：验收的条件已经具备，开始启动验收过程

　　(6)关闭项目：项目完成验收，收款完成，系统中关闭项目号



　　参见图 1，依照上述6个“标志”进行切分，就可以将五个过程组直接映射到业务流程的不同阶段：启动，对应从“售前立项”到“签订合同”之间的活动，重点是确定范围，估算成本。计划，则对应“签订合同”到“售中立项”之间的活动，重点是完成各种计划的制定。执行，是项目经理对项目的控制过程，控制，是组织级队项目的干预活动;结束则是指从“验收开始”到“关闭项目”之间的活动。

　　横向划分为范围、进度、成本、质量四个主过程，以及风险、人员、沟通和客户四个辅助过程。因为采购管理在开发类项目中很少遇到，因此将其替换为了客户管理，这对于软件项目管理来说其实是非常重要一个方面。

　　4.2构造项目管理框架

　　根据项目管理矩阵构造项目管理框架的过程相对比较简单，只要将所有项目经理参与的管理过程分别放到矩阵的不同“格子”里。为了方便使用，框架分为主过程框架(图 2)和辅助过程控家(图 3)两个部分。对项目经理来说，这个管理框架非常直观地给出了其在整个项目生命周期所需要管理的所有事项。从中，也可以看到不同活动的一些特点：

　　有些活动是具有非常明确的阶段性的。例如，立项、结项和计划;

　　有些过程则贯穿项目生命周期，比如，问题和风险管理;

　　执行和控制有比较强的关联性，并且是日常活动的主要内容





  　4.3项目经理“活动一览表”

　　项目管理框架明确了项目经理该做什么，但为了进一步让项目经理知道“什么时候该做什么”，对所有的活动按照执行的频度或者使用的场景进行了划分，完成了项目经理“活动一览表”。因为活动一览表是从框架中导出的，可以确保“每天这样做了，所有的流程被正确执行”。同时，表中还规定了活动所必需使用的模版、工具和信息系统，因此，项目经理知道自己需要掌握哪些东西，用的时候能迅速上手。

　　限于篇幅，这里仅节选了“执行”和“控制”的一部管理活动进行说明。参见图 3，一个项目经理的典型工作场景如下：

　　每天：每天必须召开晨会，更新底层计划和完成度矩阵(一种度量任务完成比例的表格)，记录个人周报的工作进展;

　　每周：每周必须完成周例会，更新范围矩阵。

　　每个季度：每个季末必须完成客户满意度调查和员工满意度调查

　　里程碑：到达每个里程碑的时候完成里程碑评审，签收阶段完工证明(财务确认收入用)，并为即将进入的阶段进行导入培训，包括下个阶段的规范、流程和技术培训：

　　事件触发：遇到风险、问题、重大变更、人事变动、运行事故和客户投诉等突发事件的应对流程

　　日常工作：这类活动没有固定的时点要求，可以根据项目实际情况安排。例如，每周应该与一名员工进行一次面对面地成长沟通;根据客户的要求定期汇报项目进展沟通;遇到范围超过阈值之后进行的项目重估算;人力资源变化时在报派工系统中进行操作;至少每个季度召开一次的团队会议等等。



　　4.4 活动的详细描述

　　基于活动一览表，从原有的过程体系中抽取相应的部分，详细描述每个活动的过程、模版和检查点(过程审计的依据)。这样，一本项目经理手册就形成了。这里以“周例会”活动的为例，说明手册的内容是怎么组织的：

　　范例：

　　周例会：跟踪中层计划

　　(1) 过程

　　a. 会前准备

　　b编写《个人周报》：项目组成员完成《个人周报》的编写，提交到配置库中。

　　c 更新《完成度矩阵》：小组长根据上周底层计划完成情况更新《完成度矩阵》，测算各项任务的完成比例。

　　d跟踪《中层计划》：项目经理根据各小组长提交的《完成度矩阵》和测算完成比例，更新《中层计划》中的各任务完成情况。

　　e更新《项目控制面板》：

　　项目经理将项目成员实际工时数据导入到《项目控制面板》的“工作量分布”栏中;

　　项目经理将《项目控制面板》中的当期数据填写完整;

　　项目经理分析《项目控制面板》的各类度量数据，在《项目周报》中分析原因，并采取纠正措施(具体各控制指标的计算方法、阈值定义等，请参考 “3.5 项目控制”章节)。

　　f 编写《项目质量周报》：质量经理收集缺陷、质量问题，进行质量分析，填写《项目质量周报》(详细内容请参考《质量经理手册》)。

　　g 跟踪问题和风险：项目经理按照“3.5.1.3 问题管理”、“3.5.1.2 风险管理”章节要求跟踪问题和风险。

　　k依据中层计划，项目经理和各组长确认下周的工作任务。

　　m项目经理根据以上信息，完成《项目周报》的编写。

　　(2). 会议过程

　　a.项目经理发布周报内容，包括：

　　本周任务完成情况

　　.偏差原因分析和纠正措施，对项目的影响分析

　　b.质量经理发布《项目质量周报》，分析项目质量问题;

　　c.项目经理布置下周工作任务，并获得大家的承诺;

　　d.项目经理询问有无其他风险和问题。

　　(3). 会后工作

　　a 项目经理确认下周工作计划，更新《中层计划》并同步到PMC中;

　　b.各组长根据下周的工作任务，在《完成度矩阵》中进行任务分解，并制定底层计划;

　　c.项目成员从《完成度矩阵》导出各自下周的工作任务，完成《个人周报》之“下周工作计划”部分，并将其补充完整，提交到配置库中;

　　d.如果识别出新的问题和风险，项目经理负责更新到PMC系统中

　　e.项目经理将周例会讨论的关键内容，记录到《项目周报》的“其他”章节中

　　f.将《项目周报》提交到PMC中，进行归档。

　　(4). 会议时间

　　a.每周五下午，1小时以内

　　b.模板

　　《个人周报》，《完成度矩阵》，《项目周报》，《项目质量周报》，《项目控制面板》。

　　c.检查点

　　是否在周会之前填写《项目控制面板》;

　　《完成度矩阵》是否填写规范、完整，并与《中层计划》、《个人周报》一致;

　　是否每周召开周例会;并在会议上发布下周工作计划;

　　是否有完整的《项目周报》

　　是否将周报抄送相关客户

　　是否收集风险与问题，跟踪风险和问题的状态，更新PMC系统

　　是否每周更新《中层计划》中的任务完成情况，并与PMC进行同步;

　　是否在会后由小组长依据《中层计划》制订下周《完成度矩阵》;

　　4.5执行的效果

　　有了《项目经理手册》之后，培训方式相应地进行了的调整。改变了过去重点培训流程的方法，而是针对手册中的内容采取了三种形成的定向培训：

　　a.实战培训，结合一个具体的项目案例，培训项目的计划制定、风险评估和控制过程;

　　b.IT系统培训，针对手册的使用场景，培训PMC、报派工和缺陷管理等IT系统;

　　c.项目经理社区活动，通过“最佳实践”的方式分享经验。例如让周例会组织的最好的项目经理进行讲解和演练，可以让受训者形象地知道“哦，原来一个周例会是这样开的”。

　　《项目经理手册》在使用后，流程“落地”的效果大为改观。首先，项目经理工作条例清晰了，动作很少走样，新任项目经理进入角色的时间也大为缩短;其次，这样一个沉淀最佳实践的平台，可以不断将项目经理积累的方法和经验增加进去，并迅速推广到组织级。第三，遇到突发事件时，项目经理不再慌乱，而是迅速掏出手册“查查有没有说明”。

　　但是，任何事情都有其两面型，基地也曾出现过片面依赖《项目经理手册》进行管理的现象。实际上，能够熟记手册内容，并不等于就是合格的项目经理。因为手册仅能保证大家动作一样，而不能保证效果一样。同样一拳打出去，是否将对手击倒还要看功底。因此，绝不能忽视项目经理能力、素质和经验，以及团队管理、沟通技能等方面的培养。另外，手册容易养成项目经理“照章办事”的习惯，时间久了会束缚了创造性，甚至形成“重流程、轻效果”的惰性。经常听见有人说“我已经按照手册作了…”，言下之意“至于结果?根我没有关系…”。因此，借鉴此方法的朋友要特别注意这两个方面不要走偏。

　　5.总结

　　《项目经理手册》在帮助管理流程的“落地”方面有显著作用。这种以项目经理为中心重组过程的方法，有以下优点：

　　按照系统的方法进行分解和重组，不容易遗漏，甚至可以发现原有体系中缺陷

　　项目经理知道该在什么时间做什么;反过来，“按照要求做了，就能保证所有的流程被正确执行”。

　   通过手册这个桥梁，很好地建立了日常活动和管理流程之间的关系，将抽象的过程与具体的工作场景联系了起来，便于培训和推广。

　　“行百里者半90”，有了规范和流程相当于走了前90里，剩下的10里就是过程“落地”;从难度上，这最后10里至少相当于征程的另一半。但愿此文，对处于最后那10里的人能有一点帮助。