1）紧紧抓住“需求定义”，要求对方把所有需求都反映到文档中，定期Review这些文档（1周1回吧）
2）要求对方做出“整体计划”，在其中表现出各个重要的“里程碑”，然后根据整体计划制定各个阶段的“详细计划”
3）根据“详细计划”，定期检查项目进度，至少1周1回。首先得有“周报”，然后基于“周报”确认一下这一周的问题点，是否有延迟，下周是否有风险，共同商讨对策。
4）评价是否到达“里程碑”不能由对方随口报告，而是要由发注方对“需求定义”以及“代码”都比较熟悉的人，参与Reiew后，在问题点都基本解决的情况下，才可以判断为到达里程碑，可以进入到下一个开发阶段。
5）最容易出问题的阶段是编码实现阶段，因为有大量功能本身就存在一定的“歧义”，很难用简单的语言进行定义；大部分的开发人员会认为“开发出能用的产品”就OK了，而很多“可扩展性”、“可维护性”的东西很难在事前说下。为了解决这种问题，在编码之前，整合开发人员的思路，统一大家的意识，这些“设计”工作就很必要了；重要的整合内容务必保存为“设计资料”，在今后的代码审查阶段，要基于“需求定义”和“设计资料”这些上游资料进行检查
6）进入到测试阶段，相对就比较好管理了，把所有的“测试用例”都消化完的计划做好，每个“Bug”的类似问题都检查一下，需要重新测试的部分重新回归测试一下
7）最好在每个阶段的开始和结束之间留下一些预留的空档，哪怕仅有2、3天，一来是预留对应风险的时间，二来是调整一下开发人员的节奏，总结、反省一下上游工程的问题点，规避一下下游工程可能发生的风险和问题总之，所有的东东都文档化，可以减少很多事后互相指责的问题
2）要求对方做出“整体计划”，在其中表现出各个重要的“里程碑”，然后根据整体计划制定各个阶段的“详细计划”
3）根据“详细计划”，定期检查项目进度，至少1周1回。首先得有“周报”，然后基于“周报”确认一下这一周的问题点，是否有延迟，下周是否有风险，共同商讨对策。
4）评价是否到达“里程碑”不能由对方随口报告，而是要由发注方对“需求定义”以及“代码”都比较熟悉的人，参与Reiew后，在问题点都基本解决的情况下，才可以判断为到达里程碑，可以进入到下一个开发阶段。
5）最容易出问题的阶段是编码实现阶段，因为有大量功能本身就存在一定的“歧义”，很难用简单的语言进行定义；大部分的开发人员会认为“开发出能用的产品”就OK了，而很多“可扩展性”、“可维护性”的东西很难在事前说下。为了解决这种问题，在编码之前，整合开发人员的思路，统一大家的意识，这些“设计”工作就很必要了；重要的整合内容务必保存为“设计资料”，在今后的代码审查阶段，要基于“需求定义”和“设计资料”这些上游资料进行检查
6）进入到测试阶段，相对就比较好管理了，把所有的“测试用例”都消化完的计划做好，每个“Bug”的类似问题都检查一下，需要重新测试的部分重新回归测试一下
7）最好在每个阶段的开始和结束之间留下一些预留的空档，哪怕仅有2、3天，一来是预留对应风险的时间，二来是调整一下开发人员的节奏，总结、反省一下上游工程的问题点，规避一下下游工程可能发生的风险和问题总之，所有的东东都文档化，可以减少很多事后互相指责的问题
外包有好多形式，有的外包合同是FP，那就是当你将需求提交给外包团队以后，其实你是不需要参与到管理中，看项目情况，你甚至不需要Review他们的中途结果，只要等到开发结束的时候，按照你们的需求定义来进行验收就可以了。当然也有完全包人的T&M，这样就需要你去管理整个团队，对方完全听命于你，好处是项目一般都不会出现和需求有很大偏差的情况，但是发包方就会比较累了。如果你觉得有各种各样的原因，需要你参与到管理中去的话，那就定期开会，会上要求各种报告，比如说进度报告，课题分析报告，品质报告，以及各种成果物也需要定期Review，比如说画面设计书，比如说系统架构书，比如说他们的测试观点。但是也别让人家经常和你开会，那样对方的PM就会天天的被你拉着开会，做针对你的资料，上面有兄台说要一周开一个会，我觉得太频了，PM都被绑的死死的，这样的情况下，对方团队必须有一个专门和你搞沟通的人，然后PM才会专心到开发中去。但是无论如何，作为你个人，你得懂行，要不然说实在的，所有的报告，所有的指标都会骗人的，指标可以做的特别漂亮，但是一验收的时候就会发现做的稀烂。一开品质报告，测试密度，bug密度，bug收束率全在正常范围内，但是品质仍然存在大问题的项目多了去了。如果你是一个门外汉，建议让你们公司给你找一个懂行的人带一带你，一个项目动辄上千万，你一个人承担不了责任的。
对项目进行监控时，监控方法可以分为定期监控、阶段性监控和事件触发性监控三种：
a) 定期监控是指项目组可以同构定期召开周例会的方式来对项目的各种参数进行跟踪和监控。
b) 阶段性监控是以项目生命周期各阶段的里程碑为标记，通过里程碑的评审会议来对项目的各种参数进行跟踪和监控。
c) 事件触发性监控是指当项目发生重大变更时都需要对项目的某些参数进行跟踪和监控。监控内容包括：
1) 对项目进度的监控
在实际工作中对项目进度进行监控时，主要关注与项目进度计划中每个任务的实际开始时间、实际完成时间和实际花费的工作量，以及项目里程碑的具体日期。我们可以通过以下步骤完成对项目进度的监控:
a) 通过对里程碑时间的计划值和实际值之间的对比，就可以知道项目是否出现阶段性的进度偏差。
b) 当发生阶段性进度偏差时，可以通过该阶段内每个任务实际开始时间、实际完成时间、计划开始时间和计划完成时间的对比找到进度偏差发生的原因。
c) 及时制定纠正措施来纠正偏差，常见的方法有赶工或者快速跟进。但赶工会增加项目成本，快速跟进是调整某些任务之间的关系，使它尽量并行前进，但这样会给项目带来风险。需对项目风险进行识别及跟踪。
d) 定期检查纠正措施是否发挥了应有的效果。
2) 对项目成本的监控
a) 以里程碑为标记统计该阶段成本花费的计划值和实际值，并将它们进行对比得到项目是否出现阶段性成本偏差。
b) 当发生阶段性成本偏差时，可以通过该阶段内每个任务实际开支和计划开支进行对比，找到成本偏差发生的原因。
c) 及时制定纠正措施来纠正偏差。
d) 定期检查纠正措施是否发挥了应有的效果。
e) 对于项目成本，咱们公司的度量单位是工时。
3) 对项目质量的控制：对项目质量监控的目的是将项目质量控制在项目预期内，如果咱们CMMI实施比较好的，在经过一段时间的软件管理后就会积累下大量的度量数据，通过对不同类型项目的分析，可以得到每种类型项目各个阶段缺陷出现的频率，所以对项目质量的跟踪和监控就可以通过控制图来实现。a) 以里程碑为标记统计该阶段缺陷发生的频率，也可以将缺陷按照种类或严重程度的级别划分后再进行统计。
b) 参考组织级别的历史度量数据中有关产品质量部分的度量目标，找出控制图的上控限、下控线和均值。
c) 定期将项目实际的质量情况在质量跟踪控制图中进行标记，以判断当前项目是否发生了质量偏差。
d) 如果发生偏差应及时制定措施来对其进行纠正。
e) 定期检查纠正措施是否发挥了应有的效果。
4) 对项目风险的监控：
a) 定期对风险进行重新识别，新识别出的风险要及时制定风险的预防和应用措施，并且要明确这些措施的责任人。
b) 定期判断风险在当前阶段的状态
c) 定期判断风险在当前阶段发生的可能性和严重性。
d) 定期对风险预防或应对措施的执行效果进行评判，以判断是否需要对这些措施进行修正。
e) 定期判断风险预防或应对措施执行后，是否会引发其他新的风险或者还有残留的风险。
f) 一般应当以周为单位，进行项目风险监控。
5) 其他参数监控：
a) 监控工作产品或工作任务：包括项目规模监控和项目复杂度的跟踪等。
b) 监控资源的提供与使用：包括硬件资源和人力资源。
c) 监控项目人员的知识与技能，确保相瞒找既定的技术解决方案进行事先。
d) 监控承诺事项：对项目干系人的承诺进行监控和跟踪。
e) 监控数据管理：监控相关数据是否按要求纳入形成文档并纳入基线等。
f) 监控关键人员的参与：定期监控关键人员是否按计划如期参与到了项目中。 总结：项目的进度、质量和成本是项目的三要素，项目是需要资源来完成的，“监控资源的提供与使用”重点关注的是资源的数量；“监控项目人员的知识与技能”重点关注的是资源的能力；“监控承诺事项”、“监控关键人呢元的参与”、“监控数据管理”重点关注的是资源的行为，“监控工作产品或工作任务”重点关注的是资源所承担的工作。
比如后期bug数量级别 ，还要做需求变更管理
1. 识别需求
2. 在规划和执行项目时，处理干系人的各种需求、关注和期望
3. 在干系人之间建立、维护和开展积极、有效合作性的沟通
4. 为满足项目需求和创建项目可交付成果而管理干系人
5. 平衡相互竞争的项目制约因素，包括（但不限）
a) 范围
b) 质量
c) 进度
d) 预算
e) 资源
f) 风险
因项目所处的具体环境会对制约因素产生项目影响的，应加以关注制约因素之间的关系是，互相联动的，任何一个因素发生变化，都会影响至少一个因素。例如：缩短工期通常需提高预算，增加额外资源，从而较短时间完成同样的工作量；如果无法提高预算，则只能通过缩小范围或降低质量，以便在较短时间内以同样的预算金额交付项目最终成果。项目干系人可能对哪个因素有不同看法，是项目实施变得更加复杂，改变项目要求或目标，引发更多风险。为了取得项目成功，项目管理者必须能够正确评估，平衡项目要求，并与干系人保持积极主动的沟通。
由于可能发生变化，应该在整个项目生命周期中，反复开展定制项目管理计划工作，对计划进行渐进明细，估算也越来越准确，因而在一个项目生命周期中要持续改进和细化计划。