过程
与过程相关的错误会降低项目的开发速度，因为他们会浪费人们的智慧和精力。以下列举一些影响最坏的错误。
#14：过于乐观的项目进度
一个要在三个月内完成项目的 人与一个要在一年内完成项目的人所面临的压力和挑战是不同的。过于乐观的项目进度会使项目被过分重视，削弱了有效的计划，并缩减了上层开发活动如需求分析 和设计，这将使项目面临失败。这还会对开发者连续施加压力，使他们的士气和产能受挫。这也是案例分析3-1中问题的一个主要来源。
#15：风险管理不足
有些错误可以被视作经典错误，有些则只在特定的项目中发生。在经典错误中，如果不注意主动地进行风险管理，就会将一个快速开发项目变成慢速的。风险管理失败是最普遍的经典错误之一。
#16：承包人失职
公司有时候会因为项目太 紧急不能自己完成就把项目的一部分交给承包人来做。但是承包人通常会迟交任务，且质量很差，甚至没有达到指定的要求（Boehm 1989）。当程序的需求不够确定，或是程序结果设计得不好，那这其中的风险将会在寻找承包人时得到放大。如果与承包人之间的关系处理得不够好，就会降低 项目的开发速度，而不是加快。
#17：计划不足
如果你不计划快速地完成项目，那就不可能快速地完成。
#18：在压力中放弃计划
当项目进 度遇到麻烦，开发者就会放弃原先制定好的计划（Humphrey 1989）。问题的严重性并不在于放弃了计划，而在于没有建立一个备用方案，从而陷入编写-修复的循环中。在案例分析3-1中，团队因为按时进行第一次发 布（这很正常），因而放弃了他恩的计划。结果是，这一时间点之后的工作都是无计划的，甚至Jill开始用一部分时间来为她以前的队员工作，且没有一个人知 道。
#19：在“模糊的前端”中浪费时间
“模糊的前端”指的是在项目开始之间所进行的验证和预算阶段。不少项目会花上几个月甚至几年的时间来进行这项工作，然后制定出一个非常紧迫的项目进度。从“模糊的前端”中节约几个星期或几个月的时间要比在经过压缩后的项目进度中节约时间容易、便宜和有保障得多。
#20：不充足的前期工作
比较紧急的计划会尝试着缩减一些不必要的工作，所以诸如需求分析、建构和设计等不能产生代码的工作就成为了缩减的首要目标。有一次我接手了一个非常糟糕的项目，我说我想看一下项目的设计图，团队领导却说他们没有时间做出设计图。
这个错误还被称为“直接跳进编码阶段”，其结果是可以料想到的。在案例分析中，条状设计图被质量设计工作所代替。在产品可以被发布之前，设计图的工作只能被否决，更高的质量工作必须要立刻完成。缩减了前期工作的项目肯定要在后期工作中弥补这些工作，而花费的精力却是10倍甚至100倍的（Fagan 1976; Boehm and Papaccio 1988）。如果你没有额外的5个小时去把第一项工作做好，难道你能找到额外的50个小时去做接下来的工作吗？
#21：不充足的设计
在不充足的前期工作中，不充足的设计是一个特例。紧急的项目会使用来进行项目是设计的时间减少，同时高压的环境会让提出替代方案变得非常困难。项目设计的目的在于权宜而不是质量，所以在项目完成之前你需要一些非常耗时的项目设计周期。
#22：不充足的质量保证
一个紧急的项目会 通过减少设计和编码的检查、减少测试计划并只进行简单地测试。在案例分析中，设计回顾和编码回顾都只花了很少的时间以完成项目进度。而结果是，当项目进行 到关键的地方，仍有过多的程序错误导致推迟5个多月发布。这种后果是很典型的。在质量保证过程中减少了一天的工作，就会在后期增加3到10天的工作量 （Jones 1994）。这会降低项目开发的速度。
#23：不充足的管理控制
在案例分析中，有一些管理控制措施会用来对即将发生的工作失误进行警告。但是，当项目出现了问题，这些管理控制就被放弃了。如果你想让项目一直保持在轨道上，那你就必须知道项目是否在轨道上，即有一个评定的标准。
#24：过早的或过于频繁的整合
在产品即将发布之前，应该做一些准备，如提高产品的星等、打印最终使用文档、组织最终的帮助系统挂钩、修饰一下安装程序、找出不能完成任务的组件等。在紧急的项目中，人们喜欢把项目过早地整合起来。由于在完成之间不能进行组合，于是有人就在工作过程中对项目进行许多次的整合，直到成功。这些额外的整合并没有使项目受益，而只是浪费时间和拖延进度罢了。
#25：忽略了某些任务
如果人们不对已经完成的项目作仔细的记录，而忘记了其中某些不显眼的任务，那这些任务会越积越多。这些被忽略的工作会累计到整个进度的20%到30%。
#26：计划以后再抓紧
如果你要完成一个6个月的项目，而用了3个月的时间完成了2个月的工作，你会怎么做？许多开发人员会说他们计划以后再抓紧，但是他们从来没有这样做过。你在建立项目的时候你会知道得越多，其中包括还需要多少时间去完成它。所以这些信息也需要反映在项目日程中。
另一种错误来自于项目的变更。如果你的项目变了，那你需要完成该项目的时间也会发生变化。在案例分析3-1中，项目的主要需求改变了，而项目开发团队却没有制定相应的措施来对进度表作出调整。面对日益增多的新要求，而不在项目进度中反映出来，一定会导致不能按期交货。
#27：糟糕的编码
有些组织认为快速、随意的编码是同样快速开发的捷径。他们争辩道，如果开发者被充分地激励了，他们就能克服万难。这远远不是实施，本书的其他章节会阐述其中原因。“企业家模式”通常是守旧的“编码-修复”模式的幌子，而且这种模式几乎不管用。这也是“错加错不等于对”的一个例子。
