IT行业自上个世纪70年代蓬勃发展，直到现在，如何管理好软件项目还一直是大家讨论的话题。因为软件项目失败的现实事例太多，如项目彻底被取消、项目的工期拖延等。
以中国目前很多软件开发团队的实际情况来看，从某种程度上来说，错误的使用和依赖两个软件来管理项目是项目失败的一个重要原因，而这两个软件就是Microsoft Project和Microsoft Word。
工程项目 vs 软件项目
其实，Microsoft Project本身是一个不错的项目管理工具，能够做任务分配、Petri-NET,、Gannt图、资源使用分析等
工作，但Project是用来管理工程项目的，如造房子、修大桥等。相对于工程项目的稳定性，软件项目具有不确定性的特点，计划赶不上变化便是软件项目的典型写真了。如果用Project定义任务，计划工期通常要耗费项目经理大量的时间，而且没有意义。
另外，软件项目与传统的工程项目还有一点不同，那就是应对需求变化的措施表现。怎么说呢？举个例子，当工程项目拖后了工期，可以多加人手，把工期赶回来即可。但软件项目就无法简单办到了，因为新来的人要熟悉项目的内容就要花时间，工期很难完全赶上。而且真正的有效的项目管理要靠一个有效的管理体系来支撑，并不是简单的加人手加班熬夜就行的。
一般来说，在软件项目中会用到Microsoft Word，就是用于写项目需求。也就是将项目要达到需求的要点或是隐含的想法一一记录下来，定下来，然后开发部门去实现。但是问题也来了，既然软件项目的需求具有不确定性和变化性，那么需求文档的描写也不可能一次性搞定，软件是慢慢成长起来的（见Microsoft Secrets），一个milestone一个milestone的发展。就像小孩子长大一样，中间可能会走弯路、错路，需要我们不断地调整和指引，最后他们才能成才。你也很难一开始就给他们描绘一个一生的所有的详细场景，让他们按照你的蓝图走。
而且，目前很多软件项目需求是用Microsoft Word写的，动辄几十页，甚至上百页。这样的大文档，除了上面讲到的项目管理方法上的问题，还存在下面的问题：
1、规模巨大，不方便查阅。一个中小型应用系统的需求文档可多达数百页，甚至更多。即使使用分卷或是超链接等快速寻找方式也不方便查阅。
2、不利于更新。需求文档是一个活的文档，根据实际需要和变化，更新是难免的。在Word中做了更新，即使用修订模式，也不容易看出更改的部分，这样就容易导致开发和功能设计两个环节沟通不畅，并且通常就变成需求只有第一个版本，以后的变更就会变成发个邮件或口头说一下就完事了。
3、不利于多人同时、协同修改。
4、需求没有条目化，Word文档中通常只是描述功能，但实际上我们还要把需求分成一项一项，设置每个需求的优先级、难易程度、功能点（function point）、在哪个发布中应该做完及需求来源等。这种类似数据库的特性，在Word难以体现。
5、不利于建立需求与其它开发控制元素的关系。这可能对写需求的业务人员体会不到，但对于项目经理，实现这些需求的人员来说是非常重要的。在开发过程中用户需求与软件需求的关系、软件需求与开发任务的关系、测试用例与需求之间的关系等，对于需求变更控制、质量控制都是非常重要的参考信息。一体化的需求文档（如MS Word）很难做到这一点。
当然，导致软件项目失败的原因自然不只是这两个，但这两个算是比较基础的原因了。
