转向偏爱过程管理。按德鲁克的观点，企业的R&D部门，是知识型组织结构的创新典范，特别是软件开发组织。而软件工程的过程属性可以说是现代项目管理的典范。
转贴于：中国项目管理资源网 软件工程可以说是最忠实地在项目管理、工程方法的路线上艰苦求索的领域。但令人苦恼的是，软件工程似乎每每遭遇失灵的窘境。自从1969年“软件危机”成为一个学术术语以来，克服软件危机的努力一直在“工程项目管理”的认识框架下进行，比如结构化软件方法，原型化软件方法和面向对象的软件工程方法。
人们普遍认为，软件的开发效率、可用性和质量，最终取决于软件的需求分析。如果对一个系统的需求描述有缺陷，那么软件无论如何也不可能实现预期的目标。
认为软件是一个按照需求分析的结果所建立的模型进行设计的过程，无疑是一种工程方法。工程方法的最大特征就是，先有设计，然后有作品。
软件工程管理引起广泛注意源于20世纪70年代中期。当时美国国防部曾立题专门研究软件项目做不好的原因，发现70%的项目是因为管理不善而引起，而并不是因为技术实力不够，进而得出一个结论，即管理是影响软件研发项目全局的因素，而技术只影响局部。这个结论非常重要。到了20世纪90年代中期，软件工程管理不善的问题仍然存在。
软件项目失败的主要原因有：需求定义不明确；缺乏一个好的软件开发过程；没有一个统一领导的产品研发小组；子合同管理不严格；没有经常注意改善软件过程；对软件构架很不重视；软件界面定义不善且缺乏合适的控制等等。在关系到软件项目成功与否的众多因素中，软件度量、工作量估计、项目规划、进展控制、需求变化和风险管理等都是与工程管理直接相关的因素。
虽然软件工程管理和其它工程管理相比有其特殊性。比如，软件是知识产品，进度和质量都难以度量，生产效率也难以保证。其次，软件系统复杂程度也是超乎想象的。但软件项目管理的工程特征并没有改变，软件工程的分析-综合架构并没有改变。
如果在这个层面看待项目管理，的确没有任何可以激动的地方。一切只不过是干起来更加迅速，集成度更高、复杂性更高而已。发现过程的重要性，只相当于重新审慎地注意到了细节。
应当说，MIT于20世纪80年代提出的“软件能力成熟度模型CMM”，把注意力引向了正确的方向，即项目赖以存在、展开的组织的成熟度。这是一个全新的视角。工程问题很容易被简化为工具是否锐利的问题，即简化为一个根据目标演绎的过程。工程失败也可以从项目管理上寻找原因。但组织的成熟水平，的确是一个好的探索方向。
CMM首先不是单纯地考察项目，而是考察组织，以及组织的演进。一个组织如果通过项目获得了能力的提升，比如越来越标准化、一致化的软件过程；越来越可以预测的软件过程；软件项目的优化是一个持续优化的可感知的过程等等，都体现了组织的成熟性。
CMM强调的是组织的能力，而不是项目管理过程中一些更多地以规则、方法面目出现的东西，比如IDEAL模型，概括了建立一个成功的过程改善项目的必要步骤，其中I代表Initiating(启动)、D代表Diagnosing(诊断)、E代表Establishing(建造)、A代表Acting(措施)、L代表Learning(学习)。
转贴于：中国项目管理资源网 软件工程的探索把软件项目关注的焦点，从工程本身转向了实施工程的组织，这就是现代项目管理的灵魂所在。项目管理不再仅仅是工具，而是关于组织、关于组织的成熟程度、关于组织的能力、关于组织的智商的学科和技术。
组织行为的改善，可以视为种群习性的迁移，其意义远远大于一次孤立的猎食行动（项目）。