WBS（work breakdown structures）即工程项目工作分解结构。2000版的 PMBOK Guide 将其定义为“wbs编码是一组以可交付项目产品为导向的项目分解元素，它可以用以组织和定义整个项目范围内的所有工作内容。编码每下降一个层次就能更加细致的表现项目工作的细节 。” 这一定义体现了WBS（work breakdown structures）的几下几个特征：
1）它能代表项目的工作活动，并且这一项目工作活动能产生一个切实的结果。
2）它分布于一系列有序的层次结构之中
3）它能代表一项有目标和切实的结果，并且能作为一项可交付的项目成果。
WBS作为一项全面系统的分析工程项目的有效方法和项目管理的基础性工作，其概念已为项目管理者所熟悉，内容也容易理解，但在实际实施中却会遇到很多困难，甚至难以推行。造成WBS方法实现困难的基本原因笔者总结为以下三个涉及WBS本质思想和作用方面的问题。1、WBS应该如何分解？2、不同分解方法之间的矛盾如何解决？3、如何理解WBS在项目代码体系中的地位？
1、 WBS应该如何分解？
关于WBS分解的方法，任何一本项目管理的书籍都有介绍，但大多都是经验性的。在实际应用中仍然会遇到问题：第一，WBS到底应该分解到多细？很明显由于项目管理的自身特点，在项目计划阶段，没有人能够项目所涉及的所有事情都写出来，那么WBS要分解几层，到多细呢？ 如果分细不容易，那么就分粗一点吧。每个WBS都只有三层。前两层是概要，后一层是任务。这时，问题也出来了。有可能同一个项目责任人第一阶段与第二阶段所过的工作都针对于WBS上的一个叶节点。看起来他只是在做一个工作。这种也是不合理的。 第二，WBS究竟有什么用 ？WBS把工作按一定格式，分类来填写，难道只是用WBS提醒一下作者，还有某某事没有做？那WBS与备忘录有什么区别吗？如此看来，只记住几个方法是不能做好项目分解工作的，最重要的是要发现做WBS分解的本质意义所在。
WBS分解的实质思想之一是要体现在项目过程中的项目职责的落实和明确划分。这个思想可以解答上面出现的两种疑问。从工程项目管理的特点可以发现，工程项目实施过程相对松散灵活，但是在责权确认的认证流程上却是相当严谨的，每一项可交付的项目成果都有严格的多方层层确认过程，以保证其项目成果达到各方标准要求。“责任到人”是项目管理的核心，实际工作中项目管理最怕的就是“事情出了没人认账，没人负责”。要避免这个问题的出现，就要在每一层次WBS分解过程中都考虑到项目责任划分和归属，尽可能每一个最底层的节点都有唯一责任人（或部门）相对应，其分解的粒度是“可以分配,可以交付”。
2、不同分解方法之间的矛盾如何解决？
工程项目的分解就是把一个已知的工程项目的任务目标，工作范围和合同要求，按照工程项目的客观规律和系统原理分解成若干个便于管理的，相对独立但又相互联系的项目单元（工作任务），以其分解结果——项目单元作为项目的计划、管理控制和工程项目内部信息传递等一系列工程项目管理的对象。原理是容易理解的，但是实际中的问题是, 每个人的解决问题思路不同，同一个项目不同的人有很多种分类, 因为可以按照工作的流程分解,也可以按照系统论的方法进行结构上的分解。不同分解方法侧重点不同，相互之间难以统一，这就造成了WBS方法在理论上容易理解但是在实际中操作实施的难度。
针对工程建设项目，造成这一矛盾的最大原因是，我国工程建设项目推行的是合同实物清单报价体系，工程项目的费用支付和工程实物的完成情况是按照合同清单完成情况来核定的，而且我国还专门编定了一系列用于合同概预算的代码规范，例如在交
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
