度的大小对风险进行评级。项目经理博客
在项目实施中，我们总结的一些高风险事件主要有：需求的不准确、项目时间表过于短促、开发一个从前没进入的领域软件、开发人员对工具的不熟悉、人员流动频繁、使用了外部软件中间件等。如果对这些风险不提前作出计划，可能会对项目的顺利进行造成极大的破坏，甚至直接导致项目失败。针对每一个风险，我们需要列出who, when, how, how much等事项，并对风险处理的结果进行追踪，最后决定是否已经解除风险或再进入风险处理循环。
一般国内公司的风险意识不强，没有很好的去规划处理风险。我们当时也是这样，往往要等到风险已经发生了，才意识到原来没有注意到这些问题。在风险的管理上，还需要更多的实践探索，首先应该从加强风险意识开始。项目管理者联盟文章
3.4质量管理
关于软件质量管理，现在已经得到了很多公司的重视，这里我想针对性地强调几个问题：
1.质量管理不单单是测试。一个容易犯的错误是把质量管理和测试等同起来，如果软件有问题就是测试没做好。其实质量管理包括很多内容，如技术检查、缺陷追踪、源代码追踪、单元测试、系统测试等。
2.质量管理不是在代码完成后才开始，质量管理应该贯穿整个项目始终，从需求、设计到编码、测试。我们往往只重视了后期对代码的测试，而忽略了对需求、设计的质量管理，而前者比较起来可能更为重要。因为处理一个在后期才发现的错误比处理一个前期发现的错误的成本要高几十倍。training.mypm.net
3.使用缺陷追踪管理工具。我们的实践证明：使用缺陷追踪管理工具比以前单纯的使用文档传送方式的效率提高几倍，并在管理诸如优先级、防止遗漏等方面有更大的优势。training.mypm.net
3.5其他
这里谈一些没有包括在上述内容里的经验教训，供大家参考：
1.项目管理工具。我们使用的是MS Project来管理项目过程，Project一个很好的优点是能把项目管理的内容自动发布到网站上去，这极大地方便了各阶层人员对项目状态的了解，有助于及时发现问题解决问题，对项目组成员也是个很好的激励方法。转自项目管理者联盟
2.项目团队中需要资深开发人员。我曾经经历过一个项目，项目负责人坚持用C++ Builder开发(可能是为了学习的原因)，但是公司没有任何一个人对这个工具非常熟悉，也没有进行相应的风险管理。结果在项目的过程中出了太多问题，使项目一直延期，在交付的时候都还存在很多问题。所以在项目团队中一定需要资深开发人员，特别是在项目的前期更是如此。
3.再次强调产品经理角色。必须牢牢记住：一个不管使用了什么先进技术、开发方法的产品，如果不能满足用户的需要，就是一个失败的产品。而产品经理角色的设立能较好满足这一要求。
4.在领域性较强的项目中，最好在基本的软件架构上(如COM或J2EE)实现一个该领域的基础开发平台，这样在以后的扩展上，在具体项目的实施上，都会极大的节省成本，软件的质量也有良好的保证。
第四章 结束语
上述简单介绍了我们项目管理的经验教训，在引入MSF管理思想后，项目的成功率比原来增大了很多。我们碰到最棘手的问题就是项目的度量(Metrics)，怎么更合理估算项目的大小，估算软件开发人员的生产率，更合理的项目计划等，这也是CMM4所要求的内容。需要在不断项目积累的同时，逐步细化量化指标，在实践中不断学习、提高。