象大多数的故事一样，这个故事也发生在很早以前。但是当我谈起它的时候，伤疤依然疼痛。我曾经在一个软件开发团队工作过，这个团队拼命的想生产一个产品，或者是只要能使用的任何东西。由于过去项目的失败，这个团队尽管许多基础建设已经到位了，但是却缺乏成功的向导和迹象。你可以说这个团队存在，但是缺乏清楚的组织结构和许多达到成功的必要的商业要素。这个团队的使命和眼界被一个受过良好教育，可是很可能没有经验的新领导人弄得墨成一团。
至于商业需要，它们一直在那儿。幸运的是，操作系统满足了稳定的最小需要。但是同样遗憾的是，这些系统并不能适应快速改变的环境，而且在许多年后，也超过了它们的平均寿命。为了替换这些老化的主机，执行者提出了一系列的 “改进创新”。执行这些创新对开发团队而言，几乎不需要优先级考虑并且甚至只需花费更少的钱。
许多内部的项目不过是在重复着劳动和竞争。“买一套ERP软件，定制它来满足我们的需要”，“为什么我们要重新发明轮子呢”。那些是来自团队内的经常的喊声，也是一个来自企业失败项目的教训。经过了与巧舌如簧的销售人员一道玩若干回高尔夫和共进几次两小时的午餐的结果就是为一套ERP软件投资几百万美元。但是那只不过是买License的花费。
模型、标准和认证
“我喜欢用老软件，为什么我一定要改变？”，用户、软件开发人员、需求分析师、项目经理和股东都面临着对即将到来的变化的相互间的抵制。
明显的，需要正规的项目管理。而执行管理层选择了CMM作为银弹工具。“只要这样一个基础组织就位，所有的项目就可以成功的、一致的完成。我们需要工作组在6个月之内达到CMM2认证。”起先，这些指令都被忽略或者轻视，但是执行管理层通过中层管理者的奖金来施压。
通过和一个成熟的开发团队的比较来提高自己看起来比填写一个空白的过程文档更容易。复制他们的制度和过程看起来也是一条可以达到CMM检查表的捷径。“让我们改变这些文档的页眉、页脚，拿来为我所用。”由于执行者又要实施另一种模型ISO9001,所以这个策略并没有起到作用。从这个前提出发，“文档化你所做的，并根据你的文档去做事”，一条粗线被画在了文本流程和实际操作之间。
在运用了CMM差距分析检查表后，这些结论发展成为了一个CMM项目计划。因此什么是这个团队应该建造的呢，过程或者产品？项目计划和项目跟踪与监控的关键过程域的执行逐步演化成了现存的项目办公室。但是却遗失了执行这些过程的技巧。
咨询的角色
组织了解了越多的成功的开发团队，他们就需要越多的启发，使他们能够看到“隧道的尽头”。他们不得不补充工作团队的技能。“求你告诉我们为什么我们的小孩这么丑陋。但是如果我们放弃了，我们要回到项目的混乱状态去。”于是他们花费很大的价钱请咨询机构来调查。在预算被耗尽的几个星期之后，他们拿出了一个报告，描述了他们需要什么样的过程和技能。但是如果没有一个有悟性的讲解员去把这些咨询报告翻译成简单的操作，那么这份报告就好像讲给聋子听了。
为了增加复杂度的层次，不断变化的公司战略和新的创意压迫着全方位的预算。当这个团队对增加一点又减少一点这样反反复复的投资提供感到气急败坏的时候，他曾寻找过促进项目管理知识交流的更划算的方法。有一个方法就是去补充合同制的雇员。这个策略持续了一段时间，大量的知识在领导、项目管理专业人员和以前公司的雇员间交流。这个方法看起来能满足目标。但是在大多数的团队里，个人冲突是屡见不鲜的，并且很可能这个项目的领导被要求离开。在招聘某个替代职位的过程中注意到一些个人的特点将会得到一个更能与团队协调的候选人，但是雇佣期会比较短暂。当预