项目经理怎么做好项目的监督与控制？
一、项目监控目的
提供对项目进展的理解，以便当项目的性能严重偏离计划时采取适当的纠正措施。重点是采用控制措施。
项目的监督和控制对软件项目的成败至关重要。项目监督和控制是以项目计划为基点来进行的。通过将工作产品的实际规模、工作量、成本、进度与预定的计划和进行比较，对目标进行分析了解项目实施是否正常。一旦发现与计划有较大偏差时，就要采取纠正措施。纠正措施通常包括：
- 通过激励来提高工作效能、
- 对剩余工作进行重新规划、
- 根据实际执行情况调整项目计划等。
二、监控的过程
三、项目监控的范围和频率
项目监控一般来说在项目启动以后就要开始进入监控状态，监控一般分成日监控、周监控、里程碑监控和随时监控。监控的频率和你想了解项目当前状况的信息需求相关。
日监控比如敏捷方法中的站会就是一种日监控的方式，但是这种监控模式的沟通成本其实很高，对于很多不想表达自己的程序员来说，有时候这样的监控会迎来反感。
周监控是目前在项目管理中用的最多的一种方式，通过开项目周例会，总结项目周报，然后呈报给相关的领导或者PMO。
里程碑监控一般都是大型项目因为时间周期较长，干系人较多，必须制作状态报告或者召开会议做出总结的时候，需要进行里程碑节点的状态观察。
项目监控的内容包括了：
- 项目任务完成情况
- 工作量增加和消耗情况
- 项目需求的范围是否变更
- 项目的周进度、里程碑进度、成本的计划和实际对比情况
- 团队人员的进出和变化情况
- 干系人对项目的支持态度变化（比如你的某位成员想离开项目团队）
- 项目的风险、问题的处理情况
- 项目变更的执行情况
- 经验、教训的总结（里程碑监控）
尽管看上去监控的内容并不是特别多，但是如果一旦需要量化这些指标时，在一周中总结所需要的时间可能不是一天能够完成，所以很多项目经理更加愿意使用一堆流水账似的工作把一周的工作事项写到周报中。当你不需要把你的周报提交给你的领导查看时，这种记账似的方式好像并无不妥，好像你的团队成员都对此表示没有任何异议。当你把这份周报交给你的领导时，这个时候就会产生一个问题，假设他对你的项目情况细节了解的不多，这份周报提交上去他很可能看不懂你要说明什么。
他的困惑在于，第一，他并不清楚你作为项目经理对项目整体情况的把握判断是什么？正常、有偏差但可控、不可控等等。第二，他可能并没有那么多耐心一条条去看你完成了哪些工作，而是他更关心是重点工作的完成情况。第三，你写周报是否有什么想要反馈他的问题和风险，他可以帮你处理。
有一种莫名的监控，凡事都要量化数据化，图表化，好吧，如果没有一款好的信息工具去处理，你可能每天都在整理报告，而真的离开了项目监控的意义，这在很多企业成了一种形式主义，问题在于某些领导青睐于一眼望穿。但是事务都要遵循简单到复杂、低级到高级的发展过程，你还没有学会走就要去飞，这不是一个良性循环。
项目监控的实质，是你了解现状而采取措施干预，或者找到问题的定位。这是主要目的，报告工作这是影响你的干系人的一种手段，但不是终极目的。
三、执行CMMI过程的项目监控方式
1.审批工作产品
- 项目成员把本周完成的《个人周报》提交OA或配置库。工作产品提交配置库。项目经理对于提交的周报和产品进行确认。
- 审批后的工作产品与《个人周报》提交配置库，由CM负责人进行统一管理
- QA对项目周报审批进行定期检查。对个人周报 进行随机检查
2.收集状态和相关数据
项目状态及相关数据的收集主要通过《项目周报》完成。项目组成员须每周按时提交《个人周报》，项目组提交《项目周报》 。
项目周报的主要内容如下：
问题和风险，包括：
- 本次发现的新问题，及拟定的解决措施。
- 上次报告中尚没有关闭的老问题的状态。
- 次遇到的新风险，及拟定的缓解措施。
- 上次报告中没有关闭的风险的状态。
度量数据：来自于项目周报、评审报告、测试问题记录、客户满意度调查。
3.分析状态与相关数据
在项目的开展过程中，项目经理安排人员对项目中涉及到项目目标的度量项进行数据收集，并记录在《项目度量分析报告》中，对偏差进行分析。同时对质量和性能目标进行SPC分析。
- 周报中列出的问题
- 估算的准确度
- 经验与技能
- 外部原因
- 变更的次数
- 外部干扰
- 工作习惯
- 管理过程与技术过程
- 可以获得的资源状况
4.实施项目监控措施
进行项目控制的目的是解决项目中存在的问题和风险。在项目偏离预定的基准时，要及时采取纠正措施，使项目重返轨道。项目控制活动在项目启动之时就同步开始，项目控制活动主要包括项目例会、问题管理、风险管理、以及变更管理等。
项目例会：项目例会是项目组内进行信息交流的一种重要的机制，是项目管理例行过程的一部分，应该每周一次。项目例会由项目经理主持，项目组成员出席。与会人员应事先准备好项目周报和在例会上要讨论的内容项目例会通常包括以下议题：
- 项目的实际状态与预定项目计划之间的偏差
- 对已知的问题和风险的跟踪及纠正行动
- 识别新的问题和风险并形成相关文档
- 对已提出并已被批准的计划的变更进行交流
- 目标达成分析
- 配置管理
会议将产生《会议纪要》，由记录人员在会议结束1个工作日内分发给全体与会人员，如果有客户参与项目，应提交客户进行确认。与会人员收到《会议纪要》2个工作日内没有提出异议的，视同认可。
对于没有条件召开例会的项目，例如：项目组成员分算在不同的区域，项目经理可根据实际情况，选择其他会议方式（视屏、电话会议、短讯工具等）进行项目团队的沟通，但要留下沟通的记录。
- 复审项目周报的内容，识别会影响项目将来性能的问题
- 识别和分析成本和进度性能的趋势，这些趋势表明将来会发生的明显偏差。
找出项目遇到麻烦的信号，例如：
- 报告变得主观或停止
- 无休止的加班加点
- 对不合作行为的指责
- 项目组对估算和日程表缺乏信心
- 士气成问题
- 项目偏离了计划的过程
- 交流减少
- 项目开始走捷径
- 识别出了新的重大的风险
将相关分析结果记录到《风险问题管理日志》中。
项目变更：管理变更的主要目的是确保变更是受控的。变更除了包括对软件配置项(如需求文档、设计文档等)的变更外，还包括对项目管理文档的变更(如进度、预算等)
因为是集成化项目管理，所以项目在提出变更时，要对所有相关的影响进行分析，填在变更申请单中。
变更包括项目管理、需求基线、设计基线、测试版本发布基线、产品发布基线的变更。
由项目经理向CCB提出，CCB进行决策。
CCB:配置控制委员会（Configuration Control Board）：审查和批准提出的正式基线的变更。确保只有经过批准的变更才能得到实施。一般由以下人员组成：
- 高层经理
- 项目经理
- CM负责人
- QA负责人
- 测试负责人
- 客户代表
变更执行
- 对变更影响配置项实施变更。实际的变更必须经QA审查，确保变更经过了要求的技术审查和确认，如评审、测试等。
- CM负责人进行基线审计，保证项目变更均通过审查并纳入配置库。更新《项目变更申请单》中变更验证一栏。经CCB批准发布。
- 基线更新和基线发布由CM人员执行
6.项目汇报和交流
项目汇报的目的是促进交流，包括项目组内部交流，项目组同客户之间的交流、项目组之间的交流。与项目相关人员协调，是集成化项目管理的目标之一。通过以下活动，管理人员参与，管理项目之间的依存关系，协调解决问题。
- 项目整体进度情况
- 本周工作成果
- 问题和风险
- 下周工作计划
- 度量数据 /目标达成
- 客户（如果有）
- 高层经理
- 其他的软件组
- 相关联的项目组本项目组成员
在每个里程碑结束时或者项目大的阶段结束时，项目经理应准备《里程碑评审报告》，以向高层经理和项目组成员或其他干系人汇报阶段工作情况。尽量会议评审。里程碑评审中的相关经验教训，同时也要要提供给组织的过程资源。作为组织的财富，供其他项目参考、过程改进。
四、项目总结
1.项目总结的时机
软件项目验收前由项目经理完成《项目总结报告》
2.项目总结参加人员
- 客户（如果有）
- 高层经理
- 其他的软件组，如系统测试组、需求组
- 相关联的项目组
- 本项目组成员
3.总结时进行评价的内容
1）项目计划的执行情况
研发项目：开发过程中，制定的《项目计划》、《测试计划》、《质量保证计划》以及《配置管理计划》的情况，有无重大的修正和时间上的延迟。
工程项目：工程实施制定的《项目实施计划》的情况。
2）产品质量目标完成情况
总结产品质量和质量目标的完成情况。
3）评价开发和工程活动采用的规则、惯例、约定以及技术和方法的适用性及有效性。
4）总结开过活动中的经验与教训。
5）后期维护工作的安排。
4.总结评价
5.中途停止项目的处理
对中途停止开发和实施的项目，在停止开发和实施的决定做出后，立即进行项目总结活动，由项目经理写出《项目总结报告》，说明停止的原因，已完成的工作，形成的工作产品，应处理的善后工作等。
6.工作移交
对于正常结束或中途停止的项目，项目经理应准备《移交申请表》及项目所有的源代码、文档与项目过程数据提交给公司配置管理员，由配置管理员对所移交的工作产品进行审计，并签字确认，项目方可结项，对于需要继续开发的版本，项目经理还需将《移交清单》提交给继续开发的项目负责人，并且由项目组继续保存这些文件。