4.1日,奇迹发生了,你的上司给高层发邮件说明你们已经成功的完成了分析阶段.老板团队所表现出的不可思议的团结和团队协作(盲目的乐观)

　　有传言说，一旦被 SEI 授予 CMM3 级，和BB同层以及更高层的管理者就可以得到丰厚的奖金.(权力和政治)

　　"如果我们要将设计详细到代码级的程度,我们为何不直接去编写代码呢?"
　　"因为那样的话，你当然就不是在设计了。而设计阶段惟一允许做的事情就是设计."

　　评审会议很快就变成有关面向对象的意义、分析和设计的定义以及何时使用聚合和关联的争论。(偏离主题的评审)

　　你告诉你的上司，这些变更意味着你需要对系统的大部分内容进行重新分析和重新设计,但是他却说，“分析阶段已经结束。惟一允许做的事情是设计。现在回去设计吧。”（死板的规程）

　　7月1号，另一个奇迹发生了！你完成了设计！一份无法反映真实需求的设计文档.充斥着大量的类图,模型和序列图.(复杂而无用的模型)

　　你的上司雇佣了一个顾问来构建一个计算所编写的代码行数的工具。他把一张很大的坐标纸贴在墙上，在顶部标出了数字1000000。每天他都会延长红线来显示增加了多少行代码。（毫无意义的度量）

　　接着，他立刻闪现出了管理方面的洞察力，说，“我知道了！，任何一行代码都不能超过 20 个字符。任何超过 20 个字符的代码行必须得分成两行或者更多的行——越多越好。现有的所有代码都必须按这个标准改写。这会使我们的代码行增加！”

　　拼凑、拼凑、拼凑还是拼凑。你和你的团队疯狂地编码。到8月1号，你的上司皱着眉头看着墙上的坐标纸，制定出了强制性的每周要工作 50小时。（加班已不能解决问题）

　　最后，到3月份。经过了大量的 65 小时工作周后。一个非常不可靠的版本完成了。实地使用时，错误的出现率非常高，技术支持人员对于发怒的客户的抱怨和要求束手无策。所有人都不高兴。(为时已晚)

　　4月，高层决定通过购买的方式来解决问题，他购买了由 Rupert工业公司开发的产品的使用授权并重新销售。客户的怒火被平息了，市场人员沾沾自喜，而你被解雇了。（替罪羊产生）