一个项目的成败既有项目外部的因素，也有项目内部的因素。对于项目外部的因素项目组一般是难以扭转的，例如项目经费的削减，组织的业务方向的变更，客户对合同的违约等等。但是对于项目内部的因素造成项目的成败却是与项目经理的素质和管理是密不可分的，大多数项目经理在项目管理中存在以下四个失误：

1、  需求把握不好：没有控制好需求，使需求陷于反复变更之中，既浪费了项目的时间，有容易使开发工作失去重心。有这么一个例子：我做的车辆年费征收系统的项目里，有一个收费折免功能，稽查队、车管所、路桥处都会用到，只是折免权限不同，最开始项目组在车管所调研，车管所提出折免界面应该输入免去多少金额，等这项功能做好以后，拿到稽查队去，而他们提出折免界面应该输入折后实收多少金额，后来到了路桥处就要输入打几折，项目组为这项功能反复变更了三次。正确的做法应该是，在确定某项需求时，要把与这项功能相关联的所有客户的需求都收集起来，提出一种合适的解决方法，然后得到与这项功能相关联的所有客户的确定，有时候需要让客户自己先到达一致，然后再与客户确定需求。

2、  做事欠条理：条理清晰是做管理的基本要求，条理不清晰容易使工作迷失方向，抓不到重点，做事没有条理大多是没有认真作计划造成的。有这么一为项目经理，有一天，本来要审核测试报告的，可是客户一个电话要变更一个需求，他马上匆匆忙忙到客户那里讨论需求，回来后马上要做这项需求的开发人员根据变更的需求更改程序，而这项需求刚好做了测试，测试报告还没有来得及审核。这样既浪费测试人员的时间，又使做这项需求的开发人员没有根据测试报告及时修正程序。正确的做法应该是：自己继续审核测试报告，派做这项需求的开发人员与客户交流，开发人员回来后，与开发人员、测试人员一起讨论需求的变更，同时根据测试报告形成一个修正方案，开发人员再进行修改程序。

3、  专注做项目中的某项工作而没有看到项目全局：项目经理如果没有全局观念，就不能及时觉察到项目中出现的种种迹象，从而发现可能出现的问题。其实有很多事情，如果在刚有苗头时及时采取措施，是完全可以避免的。一个项目的成功是项目整体的成功，如果严重影响项目的风险没有避免，哪怕项目经理做的模块做得再好也于事无补。原来自己负责一个教育资源管理系统得开发，由于自己也是技术骨干，负责系统的核心模块教育资源存取的开发，自己整天沉浸于自己负责的模块的开发中，没有觉察到做系统管理的开发人员由于情感问题情绪低落，还一味根据自己的进度对他进行加压，在他做了70％时，他主动提出离开项目组，而且由于我的不懂人情对我产生了怨恨而带走所有源码，这件事对项目产生很大影响。

4、  配置管理混乱：大凡在项目开始时，大家还比较清楚各自所做的工作产品的版本和更改情况，但时间一长，东西一多就会混乱。有许多开发人员认为严格的配置管理太麻烦，有时偷点懒觉得没关系，其实到了出现问题时，就后悔莫及。我就在做教育资源管理系统时由于开始都是个人自己管理自己做的模块的文档与代码，等一个模块全部做完了再提交给测试人员进行测试。由于做系统管理的开发人员带走了所有源码，我这里什么都没有，我真的后悔死了。

另外，一个成功的项目有以下四个特点：

1、  依着一个目标前进：一个项目必须有一个统一的目标，要使得整个项目组向这个目标前进。其实在一个项目组中，每个项目成员可能有自己的小算盘，有的想通过做项目学习新的技术，有的更注重获得经济效益，也有的想积累项目经验，这样需要项目经理把大家的精力集中到项目的方向上来。我做过一个多媒体教室的项目，其中项目组有两个小伙子很有上进心，喜欢钻研技术，不喜欢作细致完备的工作，于是我把系统所用到的技术分为几个主题，每一周召开一个主题的研讨会，在研讨会我就给他们讲任何先进的技术并不在于其本身的先进，而在于其应用的先进性和完备性。一个程序员的技术水平的高低并不只是由于他掌握了先进的技术，正如《卖油翁》所说的高手其实就是唯手熟而。后来在开发中这两个小伙子积极性很高，而且做事也越来越认真细致。

2、  让规章说话：项目组在容易出现争执或难以控制的地方制定合理的规章制度，按规章办事虽然不能保证样样是好的，一般可以保证70％是正确的，同时可以避免项目组有些矛盾的激化。尤其在与客户确定需求时，必须制定一套确定客户需求的规章，不能哪个客户说什么就作什么，在项目组和客户之间按照一定的规章来确定需求，这样做，就不存在项目组的某个人得罪了某个客户。我在做一个进销存系统时，由于在现场开发，如果没有一套确定客户需求的规章，一个客户跑过来讲一个自己的想法，不一会儿另一个客户跑过来讲一个自己的想法，会使整个项目开发工作都难以进展，于是我们在第一次与客户交流时就与客户制定了确定需求的规章，并且打印出来人手一份，规章里规定客户有一个确定需求的负责人员，每一个需求及需求更改必须以书面形式，并且有负责人员签字，项目组才予以承认，到项目组后，必须有项目经理的签字或授权认可，这项需求才成为正式需求，开发人员才进行程序更改。这样虽然不能保证100％按照规章执行，但可以杜绝大多数的因为需求变更而出现的问题。

3、  按照计划行事：凡事预则立，不预则废。制定合理的项目计划，就是让项目组的每一个成员在项目中的任何时间都知道自己应该作什么，如果一天不知道自己该干什么，就浪费了一天，一个小时不知道该干什么，就浪费了一个小时。其实有很多项目的延迟，都是平时一天一天的浪费，一个小时一个小时的浪费造成的。我做项目，一般三个月以上的，项目计划精确到周；另外每一个项目组成员都要制定个人工作计划，不要详细，心里明白就行，个人计划必须到天，至少可以保证不会浪费一天。

4、  按照条例检查：对于工作产品的质量检查和软件测试，必须先制定需要检查的和测试的条例，然后按照条例进行检查和测试。这样可以做到有的放矢，事半功倍。我接触到有这么一个项目组，该项目组开发的系统已经开始运行了，但存在很多BUG，于是项目组招进了三个测试人员，这三个测试人员没有多少测试经验，对系统也不了解，业务也不熟悉，项目经理给每个人分配一台电脑，里面装有一套项目开发的系统，对他们说：这个星期，你们对这套系统进行测试。一个星期到了，项目经理来检查，发现他们除了发现几个界面上的错误外，没有发现什么BUG，项目经理埋怨他们工作不尽力。其实他这种做法好比拿一个古董给一个外行人去鉴别真伪，不知道从何下手，既浪费时间，又没有什么效果。我做项目的一般做法是：对于质量检查，质量保证人员根据项目的质量标准和公司的相关规范列出一个质量检查表，质量保证员根据质量检查表逐个检查就行。对于软件测试，在测试前必须撰写测试案例，一般测试案例的撰写都是要根据前一个工作产品为基准，对于界面测试，我们对每种控件都规定若干测试条例，例如下拉列表框，我们需要测试以下几个方面：回车键、TAB键的选定及焦点的变化，下拉选项的长度和宽度，鼠标的单击的选定，无选择项的选定，鼠标的滚轮的选择，关联快捷键的操作，是否可以编辑（编辑的测试条例另外给出）等。测试人员只要拿着测试案例和条例逐个测试，然后把测试结果记录下来就行了。