项目管理是一项非常有挑战性的工作，尤其是软件项目管理。而且对于规模越大的项目，其成功率越低。项目范围取决于产品范围，软件产品范围则来源于软件的使用者——客户对软件所提出的需求。由于认识到软件需求的重要性，在20世纪80年代中期，从SEI中分离并形成了软件工程的子领域——需求工程。
据经典数据统计，软件开发项目的成功率目前不超过50%，如果时光回退十几年，这个数字会再低十个百分点。分析其原因，发现其中一个主要的“败因”是范围管理失去了控制，从而引发“范围蔓延”(Scope Creep)，以这种方式失败的项目表现为：项目已经比原定计划大大延期，客户仍在源源不断地有新需求，或者对已经完成的功能提出各种修改意见，开发团队士气低迷，总有完不成的开发任务，项目预算已几乎消耗殆尽，而距离项目收尾却遥遥无期。
与软件工程提出的生命周期类似，需求工程也有需求生命周期，它将最初用户的设想和要求通过一系列过程，并采用适合的工程方法转化为可以指导软件开发的需求规格，并提出要对这些需求进行相应的管理以跟踪和控制。
从上述特征来看，需求工程与PMI的范围管理实质上都是过程管理，而且重点在于各种说明详尽的文档编制，通过文档来驱动和指导开发，以求做到任何的进展和变动都有文档记录和跟踪，在开发流程和开发文档的双重保险机制下，尽可能避免发生差错，提高过程控制能力。
过程式管理的一个出发点和作用是防范整个过程体系中有个别人能力不足或者由于人员流失而给组织带来损失，防范由于人的自由性使事情偏离预想轨道，因此通过在一系列过程中安排检查点及时进行纠偏，并且设置层级的组织结构对此进行制约。
依靠过程式的管理是否完全适合软件这样一种特别的项目制品?回答这个问题可以从三个方面入手：第一，软件这种制品有什么特征;第二，如何衡量一个软件开发项目的成功;第三，管理的本质又是什么。
一、软件项目特征
(1)软件不同于可见的有形物品，有形物品可以用计量单位和计量方法进行描述和标识，软件是运行于计算机中的代码，它不是有形实体，无法进行严格而且形象的量化。软件要模拟并解决人在现实世界中发生的活动事务，不同组织不同人其行事方式各有不同，期待的结果也不一，这就是具备相同功能的同一个软件产品不能完全适用于所有客户的原因。将解决和能解决什么问题，最终达到什么样的一个效果，这个过程需要双方的沟通，以达成对要构建系统的较为一致的认识。但是正如我们熟知的，在沟通的过程中，人们所处的观察角度不同，思考方式不同，表达方式也不尽相同，这都会导致信息在传达过程中发生丢失与变形，会出现客户所想不是开发方所做的这么一种状况。
(2)项目是一个过程，它跨越一个时间阶段，在这个阶段中客户的活动方式和事务内容往往会发生变化，在这个时候软件的开发也随之发生变化是一个再自然不过的事情，而且规模越大、时间跨度越大的项目就越是要面临这种挑战。
过程式管理模式要求项目一开始就能较清楚地确定要完成事项的大致范围，进而安排计划进度，确定投入的成本与资源，显然这与软件这一特殊项目制品渐进和反复式的构建特点以及构建过程有相违的地方。
二、软件开发项目的成功界定
由于软件项目牵涉两方，那么自然成功的衡量标准是同时满足两方的期待。
过程式管理强调计划、控制，而审慎详尽的计划往往耗时费力，又难免遇到范围信息输入较少这样的尴尬境界，因而如果项目经理死守一份僵化的计划，为了维护“项