传统的工作分解结构问题

　　传统的工作分解结构往往受到3个基本缺陷的损害。
　　1.它们过早地围绕产品设计进行了结构化。
　　2.它们过早地在过于详细或过去简单的细节上进行了分解、计划和预算。
　　3.它们是针对具体项目的，项目间横向的比较通常很难或者根本不可能。
　　传统的工作分解结构过早地围绕产品设计进行了结构化。它首先围绕产品构架的子系统进行了结构化，然后进一步分解成各个子系统的构件。一旦确定了工作的分解结构，并向各个经理分配了预算，明确了进度和期望的可交付产品，那么一个具体的计划基础就形成了，此后的修改将是困难的和昂贵的。工作分解结构是财务计划的构架。如同软件构架一样，计划构架也需要封装易变动的构件。如果计划和产品构架都已经成熟，那么将二者紧密结合起来是可行的。不过如果计划或是构架需要改变时，松散的结合则更为合适。
　　传统的工作分解结构过早地在过于详细或过于简单的细节上进行了分解、计划和预算。大型的软件项目容易计划过分，小型的软件项目则容易计划不足。这些系统经常使用6级或更多级的工作分解结构元素。管理群组做出每个元素的计划，制定出预算的基线，并为每个任务在通一细节级别上安排进度。另一方面，大多数小规模的开发或作坊式的开发精心设计它们的工作分解结构，使其仅存在一个层次，而没有支持的细节。管理群组计划并领导项目实施，承担一个粗糙的任务、成本、进度责任。然而，这两种途径都失去了平衡。通常，一个工作分解结构应至少细化为2层或3层。对于大规模的系统，在生命周期的后期阶段可能需要更多的层次。在开始的时候，计划过细的基本问题是在项目中不能保证实现这些细节。例如，当已经制定了计划的基线，而构架和测试场景尚未进行时，要在第一个月就精确地列出18个月后进行的测试活动的细节是不可能的。
　　传统的工作分解结构是针对具体项目的，项目间的横向比较通常很难或者根本不可能。多数的组织允许个体项目定义它们自己的项目结构，这些结构需要按照项目经理的风格或客户的需求，或者其他项目特点进行剪裁。没有标准的工作分解结构，所以在多个项目之间比较计划、财务数据、进度数据、组织效率、成本趋势、生产力趋势或质量趋势是极其困难的。每个项目以不同的方式组织工作，使用不同的度量单位。使用传统的工作分解结构的群组多数无法回答下面这些简单的问题，而这些问题对于组织级过程改善是关键的。