摘自《信息系统项目管理师教程》第3版

在分解中应该注意到WBS是将项目的产品或服务、组织和过程这三种不同的结构综合项嗣分解结构的过程，逐层分解项日或者其主要交付成果的过程，实际上也是分派角色和职责的过程。具体来说，在分解的过程中，应该注意以下8个方面。

(1)WBS必须是面向可交付成果的。项目的目标是提供产品或服务，仅仅是一连串特别的活动。WBS中的各项工作是为提供可交付的成果服务的。WBS并没有明确地要求重复循环的工作，但为了达到里程碑，有些工作可能要进行多次。最明显的例子是软件测试，软件必须绎过多次测试后才能作为可交付成果。

(2) WBS必须符合项目的范围。WBS必须包括，也仅包括为了完成项目的可交付成果的活动。100%原则（包含原则）认为，在WBS中，所有下一级的元素之和必须100%的代表上一级元素。如果WBS没有覆盖全部的项目可交付成果，那么最后提交的产一钴或服务是无法让用户满意的。

(3) WBS的底层应该支持计划和控制。WBS是项目管理计划和项目范围之间的桥梁，WBS的底层不但要支持项目管理计划，而且要让管理层能够监视和控制项目的进度和预算。如果将WBS分解得过于徉细，那么容易让人掉进细节中，同时可能会忽略更重要的事情，对于项目的控制成本也不利。另外，WBS如果变成了每小时的工作单，那么对于项目团队成员而言，谁也不愿意每时每刻都受到监控，而且，组织可能还需要雇佣相应的人员来完成如此之多的监控。

(4) WBS中的元素必须有人负责，而且只由一个人负责，尽管实际上可能需要多个人参与。如果没有个人负责的内容，那么WBS发布后，也很少有项目团队成员能够意识到自己和其中内容上的联系。WBS和责任人可以使用工作责任矩阵来描述。在一些参考文献中，这个规定又称为独立责任原则。

(5) WBS的指导。作为指导而不是原则，WBS应控制在4～6层。如果项目规模比较大，以至于WBS要超过6层，此时，可以使用项目分解结构将大项目分解成子项目，然后针对子项目来做WBS。每个级别的WBS将上一级的一个元素分为4～7个新的元素，同一级的元素的大小应该相似。一个工作单元只能从属于某个上层单元，避免交叉从属。

(6) WBS应包括项目管理工作（因为管理是项目具体工作的一部分），也要包括分包出去的工作。

(7) WBS的编制需要所有（主要）项目于系人的参与，需要项目团队成员的参与。各项目干系人站在白己的立场上，对同一个项目可能编制出差别较大的WBS。项目经理应该组织他们进行讨论，以便编制出一份大家都能接受的WBS。

(8) WBS并非是一成不变的。在完成了WBS之后的工作中，仍然有可能需要对WBS进行修改。如果没有合理的范围控制，仅仅依靠WBS会使得后面的工作僵化。在一些参考文献中，这个问题被称为滚动分解原则。