不久前陷入了一次关于WBS工作分解结构设计规则的论战，争论到底应该面向可交付成果分解项目工作还是面向活动。
其实，这要看你在什么层面，从什么角度去使用WBS；以及你的项目所具有的一些特征。这些将决定你如何有效地使用WBS工具去管理你的项目。
下面谈谈我对这个问题的看法：
在这里用这个表格可能更直观地表达我的认识
面向活动的分解方式非常适合于服务类项目的工作分解，而且这类项目的工作结构本身应该不复杂，例如网上流传很广的结婚WBS案例。当然，这不是说面向活动的WBS就一定结构简单，但是WBS的本质并不是“穷举”所有的工作细节，而是科学合理的管理项目工作。你可以参考关于80Hrs规则的文章，来了解WBS的分解精细度问题的答案。
（暂且放下面向成果分解方式的评价）
面向活动的分解方式最大的问题就是对变更的控制力不够，因为就任务本身而言也许他在项目实施过程中不会改变，但是它产生的结果很有可能是会发生变化的。比如：采购任务按照设计图纸要求采购设备。无论你将活动分解得多么详细，你都无法跟踪最终采购设备和图纸标明设备是否存在差异。另外，当你管理的项目是由很多参与方共同完成的（例如AEC工程领域），那么针对任务的分解方式是非常脆弱的，因为你很难规定一个独立承包商的所有任务（即便你有合同约束他们），这有悖于另一个被普遍接受的WBS设计原则100%规则。
面向活动的分解方式同时也容易导致WBS演变为schedule工具，或者WBS容易沦为项目进度计划的工具而不是基本的项目管理工具。这一点在我看到的wbs中甚至成为了一种趋势。[Lax老兄，我可不想与你开展新的论战] 但是我们不得不承认，至少在有限的范围内，有很多人忽略了WBS作为范围管理工具的作用，而更多地将它用于schedul计划和管理。
面向活动的分界方式的重要基础就是任务的成果简单明了，不存在任何可变因素。例如获得“某某部门或领导的批准”，相反如果活动定义为“确定区域供电方案”就有可能包含大量的可变因素。对付这一问题的方法有两个：
- 将活动继续分解，直到它不再有任何可变因素；
- 定义活动的可交付成果（还是需要基于成果的分解和定义）。
[这里我要提醒sam: 当WBS含有很多不确定因素的时候，维护WBS结构绝对是件非常繁冗的工作]不同的方案有可能导致不同的工作任务模式。
小结
上述论调似乎在刻意“贬低”面向活动的分解方式，如果你这样认为就大错特错了！事实上面向活动的分解方式特别适合个人对于项目的管理，至少我是这样的。毕竟，个人看待项目管理不能避免的会面向活动。另外，如果项目是完全属于组织内部的，那么面向活动的分解方式可以提高组织的协同效率。
而PMI则倾向于面向成果分解方式，并且在其出版的《Practice Standard for Work Breakdown Structures》 有详尽的阐述。据个人的实践，在AEC领域，面向成果分解的方式是唯一的选择。
相关文章...
Good Design is Good Business on July 24th, 2006
建筑策划 on July 3rd, 2006
工程项目配置管理 on July 8th, 2007
从西方判例看工程项目管理经理的职责 on December 24th, 2006
Primavera 的prince2 整合方案 on June 4th, 2006
肯定一点：面向活动的分解方式的确存在很难达到100%分解（容易漏项）的风险。
质疑一点：难道面向成果的分解方式就不需要对WBS进行维护？
评论 作者： sam — 2007-07-23 @ 10:09 pm
当然也需要，而且一定要。只不过维护量大小的问题。在PMI的Practice Standard里面例子展示得很好：自行车就是车架、轮子和传动系统构成，不变的是产品的特征结构。另外你要知道活动与活动之间的关系很多时候都不是刚性的，一旦发生变化，维护工作不仅仅是在数据层，很有可能在结构层都会变化。
评论 作者： clockwork59 — 2007-07-24 @ 1:16 am
建设工程项目管理软件（WBS）多维结构模型的思考
1.对项目管理的初步认识
1.1 项目
许多项目管理的课程、书籍、文章、软件，均对项目作了一些定义。
我们可以从以下眼光看一个项目。
如果你从远处看一个项目，项目就像一个点、一个名称、一个事件……（例如，国家大剧院……）
当你向项目走近时，你可看到项目的轮廓，一个建筑工程建设、一个飞机制造、一个新药品的开发…..从项目管理的角度来看（例如，一个建筑工程的建设……），你看到项目的技术配置（例如，市政外线、室外场区外线、结构工程、建筑工程、机电工程、精装工程、装饰品工程…）此回答了我们一般想问的“是什么？做什么？WHAT？”
当你进入或参与或调查或指挥此项目时，你逐步发现此项目所发生的建设过程中事件――项目进度（例如，立项、设计、招标、施工、验收、开业…），此回答了我们一般想问的“怎样做？如何做？HOW？”
再进一步了解发现，项目所需要控制的目标……技术、进度、质量、安全、风险、成本、合同、资料……此回答了我们一般想问的“要求是什么？条件是什么？WHEN、WHERE？”
看一个项目，就如同分解项目，由远到近、由表至里、“循序渐细”。
由此，我们可以给项目一个这样的定义：项目就是一个相对独立的事件（远看一个点），此事件出自一个设想（项目输入原点IN），――→需要一个组织（项目分级组织OBS）投入资源并进行实施过程（项目实施过程WBS），产生一定的功能（项目技术配置PBS）、满足某种条件（项目约束条件RBS）。――→从而实现并验证此设想（项目输出结果OUT）。
1.2 项目管理
从上面的项目定义，我们就不难理解项目管理。
业主投资的建筑工程项目管理，是一个多维的管理体系。业主项目管理就是组织、实施和控制这个相对独立的建设工程项目的实现（远看是一事件）。此事件出自企业战略的一个设想步骤（项目输入原点IN），――→需要一个组织（项目分级组织OBS），进行实施过程（项目实施过程WBS），产生一定的功能（项目技术配置PBS）、满足某些相关资源条件和外部条件（项目约束条件RBS）。――→从而实现并验证此原始战略设想目标（项目输出结果OUT）。
1). “一个设想（项目输入原点IN）”：当代项目的规模越来越大，“投资人”的重点须着眼于项目投资的初始商业论证和项目最终结果论证。“项目主管”须在项目实施过程中，始终要把握住项目原始设定的投资目标，无论项目外部环境如何变化，都要使项目控制在“有商业效益”的范围内，否则项目投资毫无意义。项目实施过程中的具体事务，则采用分级授权给项目组织负责并加以控制。
2). “现代的项目组织（项目分级组织OBS）”：已经从原始的金字塔直线形式，发展到向三维方向分解和授权的“多层多维”矩阵组织结构。组织结构实行多层分级授权，从公司战略层，向项目主管、项目经理、设计、监理、施工承包商、材料设备供应商等等进行授权和承包；业主项目经理，也向多维组织结构方向全方位进行渗透和分解，从原有的项目职能部门（项目组织分解OBS）（例如，投资部、规划设计部、工程部、预算部、合同部、财务部、），向项目的过程进行部门分解（项目实施过程分解WBS）（例如，开发部、前期部、拆迁部、工程总监、销售部、经营部、物业部），并向项目产品进行部门分解（项目技术配置分解PBS）（例如，工程总监下设有土建结构部、机电设备部、装修装饰部、栋号组等等）。“项目经理”在“项目主管”的授权下，着重于项目组织、管理和实施过程的控制，而项目的具体生产施工任务均采用合同形式，授权给专业的建设设计单位和施工单位及材料设备供应商去承包。
3). “项目实施计划”： “项目经理”对项目的组织、管理和控制首先体现在一个较好的项目实施策略和实施计划（一个对项目实施进行的“规划设计蓝图”），然后按此计划进行过程中的控制（按“规划设计蓝图”进行控制），最后，按层层分解的各各分包合同，进行各工序、分项工程、分段工程、分部工程、单项专业工程、单体建筑工程进行工程验收和总体竣工验收，并达到政府部门的强制验收，以实现建设工程的竣工、移交及开业。
当代“项目实施计划”，与以往只着重于“建设工程施工计划”的单一计划不同，即充分利用计算机网络和软件，在统一的计算机平台上，全方位对项目的A、组织层次、B、过程、C、目标资源、D、工程配置，E、及工作流程监控等等进行综合。项目经理首先按上述多层多维的结构模型对建设工程项目进行合同分解，制定合同招投标策略，制定项目“总体实施计划”，包括按项目职能管理部门分解为投资，预算、合同、质量、进度等等计划、按项目过程分解为开发流程、前期报审、拆迁、设计、招投标、施工、竣工移交、销售、物业经营管理等等计划。然后，按“三级计划管理”原则，按项目产品配置再进行承包合同计划分解，由合同承包单位进行编制计划。例如，设计计划中包括各承包单位的建筑结构设计总包、机电、精装、外墙玻璃幕墙、设备专业功能（比如，厨房设备设计、洗衣机房设计、热力站、冷站、变配电室等等设计）、园林绿化、市政管线、家具、装饰品、标志系统、广告等等设计计划，施工计划中又包括各承包单位的土建施工总包、机电、精装、外墙玻璃幕墙、设备采购、材料采购、装饰品、家具采购等等施工安装制作计划。
4.) 专业咨询：作为当代项目经理，组织、控制和管理如此众多的项目参与单位的工作，往往也采用授权分解的原则进行，由项目经理经合同授权聘请专业咨询单位进行专业管理。比如，造价咨询公司、施工质量监理公司等等。
5). 专业设计和施工承包：虽然当代建筑工程业主的项目管理模式有许多种，比如以往的合同分解承包、和现代的CM代理承包、项目代理制、BOT模式等等，归根结底，最终都要按项目产品配置以合同授权方式聘用专业设计单位和施工单位进行最具体建筑工程的设计和施工。包括各承包单位的建筑结构设计总包、机电、精装、外墙玻璃幕墙、设备专业功能（比如，厨房设备设计、洗衣机房设计、热力站、冷站、变配电室等等设计）、园林绿化、市政管线、家具、装饰品、标志系统、广告等等设计。包括各承包单位的土建施工总包、机电、精装、外墙玻璃幕墙、设备采购、材料采购、装饰品、家具采购等等施工安装制作工作。
1.3 项目管理的基础：由表至里“循序渐细”
项目一开始，誰也不知道项目的一些细节，而是随着项目的不断深入，逐步明确了项目的阶段、条件、子项目、工序……故，项目管理的基础着重在于，明确了“项目总目标”后，由表至里“循序渐细”地进行项目的分解工作，使项目从大目标分解成小目标（子项目）――→合同包――→步骤――→工序……使我们各控制部门、各参加建设单位、各专业工种在此项目上同时“并行协同”地进行各自的工作。
那么，如何将参与项目的所有具体人的工作组织在一个有秩的计划中？如何分解项目？
以往的项目管理及软件均是按WBS（工作分解结构）进行项目的分解，是一维的。不知道是先按项目过程分解，还是按项目技术配置分解，或是相互穿叉，很多时候我们自己就将项目分解乱了…。
按上述我们所看项目的眼光，可以用三维对项目进行分解，而时间单位仅是一个测量尺而已。
A. 第一维，按项目产出物或产品分解，则为PBS（项目技术配置分解结构系统）。比如，
汽车可分为车身、发动机、底架结构、外壳；
建筑可分为室外、裙楼、主楼、结构、建筑、机电、装修等；
B. 第二维，是按工作过程流程分为WBS（项目过程工作分解结构系统）。比如，
汽车制造可分为概念、设计、采购、加工、组装、测试等；
建筑的流程可分为规划、立项、征地、场地、设计、招标、采购、施工、验收、试运行、交付等）。
C. 第三维，是按项目目标分解为MBS（项目目标分解结构系统）。比如，
产品技术配置（在制造行业中已经经常使用此概念，有PLM配置管理系统）、进度、质量、造价、合同……
D、当然，在一个项目中还有一些多级组织、多层计划、工作流的概念：
多级组织级别：项目是由各级单位组成的――例如，项目管理层次有投资人、业主、项目经理、项目监理、设计单位、施工单位、供应商、分包商、物业管理使用单位等；对不同级别的使用者来说反映不同的重点，对于业主高层领导，多层计划是看见较高级别的问题，从宏观的角度看是否存在工期的滞后、费用超出的问题，而对于项目管理部的计划工程师来说，看见的是比较微观的问题，即工程计划的哪些WBS和哪些作业存在问题，应该如何去调整计划。
多层计划：项目（例如，在P3软件中）在EPS、项目、WBS、作业、步骤上形成“从粗到细”的、按照项目“渐进明细”特征的层层细化的计划，项目被细分为总目标――→大目标――→小目标――→合同包――→步骤――→工序……成百、上千、上万个工序和步骤。
多组织：所有的项目，均是由多个组织共同“并行工作”完成的。各单位组织按照上述分解系统，分别完成不同项目产出物，或在不同的过程阶段，或控制不同的项目目标，或承担不同的管理级别任务，或处于不同的管理级别岗位，或承包不同的子项目合同任务……
由此，可将项目目标分成多级、多维分解结构系统：项目总目标――大目标――小目标――合同包――步骤――工序……成百、上千、上万个工序和步骤。这些众多的工作均是以时间为测量尺，以逻辑关系或组织关系的前后顺序编排而成。
1.4 现有一些项目管理及软件，在实际工作中的问题
现有的项目管理，一般都使用项目管理软件辅助进行WBS分解工作，（是按一维方式分解的）形成一个个工作包（合同包）。并以进度计划管理模块为基础，然后将资源、成本、组织责任、等信息放置到每个工作包上，再按时间坐标进行排列，从而形成一系列项目管理各种子目标随时间轴的目标计划安排和每个工作包上信息强度列表（例如，资源分布图表）。
在此种工作中，通常，进度计划管理模块的表现形式有甘特图、单代号网络图、单代号时标网络图、双代号网络图、双代号时标网络图等表现方式。
甘特图的最大优点是表格化，许多项目管理软件中预制了大量的项目管理表格，十分方便于统计报告。但是，其最大的不便之处是一维表格，所有的项目工作分解任务均在左侧单列，往往一个项目的分解表很长，而甘特图中的条条很稀，占用很多纸张图面空间，不能一目了然。
双代号网络图和其双代号时标网络图的最大优点是图形化表现形式，图面很紧凑；但其最大的缺点是不能形成表格化，虽是二维的，但不能按项目分解的思路进行排列成表格。而在项目管理实践中经常需使用各式各样大量的表格，故而双代号网络图在项目管理中的应用遇到了阻碍。
单代号网络图和其单代号时标网络图的优缺点同双代号网络图。同样，在项目管理中的应用遇到了阻碍。
那么，为什么不能将双代号网络图或单代号网络图的图形制成表格状？用表格嵌套的方式进行项目管理。………
题外话，单代号网络图与双代号网络图之间可以进行转换。把单代号网络图中的节点方框拉长，就得到双代号网络图的工序线。有一些项目管理软件已经实现了此种转换。
另外，我建议：我们在双代号网络图中引进第三节点――即除头尾二节点外，我们在双代号的中段引进第三节点，用来表示工作间的搭接关系，则双代号网络图同样可以表示FS、FF、SF、SS等工作间搭接关系。
2.用嵌套方法进行项目管理，软件的思路
为了克服双代号和单代号网络图不能形成表格化的缺点，我本人有以下建议模型。
2.1、我们经常会遇到此种情况，即在进行编制WBS工作分解结构时，到底是以“项目阶段过程”为主线进行分解，比如建筑工程项目分解成立项、设计、招投标、施工、验收等阶段过程，还是以”项目产出物”的专业系统为主线进行分解，比如建筑工程项目分解成结构、建筑、机电、装修、外线、市政管线等专业系统？有时候拿不准，二者相互穿叉，自己就分解乱了，出来的分解表自然比较乱。
其实，我们发现，在进行WBS工作分解结构时，用二维矩阵表方式是最清楚的。我们可以将项目实施的阶段过程和步骤分解项列在表格的顶部行中，将项目产出物的专业系统分解结构项列在表格的左侧列中，这样就形成了一个二维WBS矩阵分解表。表中各单元格内的数据就是项目子项目、或是合同包（或称为工作包）、或是各工序，各单元格相当于单代号网络图中的节点，各工作包格中可以承载――子项目编号、工作编号、合同分解编码，工作名称、工期、资源、成本、责任单位人、等。
再者，如果将上述矩阵表中各单元放在我们一般编制进度计划网络图中，按工序的逻辑顺序連线起来，再加上时间坐标，就形成一张同我们一般思维相同的《单代号时标矩阵网络图》：横向看是每个工作过程各阶段各步骤，纵向看是项目每个并行工作着的各专业系统。而且，此图也符合我们平常的工作编排―――即从图的横向看，项目各系统专业均有一个实施过程，比如建筑、结构、机电、精装专业均有设计、招投标、施工、验收等过程，从图的纵向看，项目的设计、招投标、施工、验收的每个阶段过程中均有项目各系统专业的人们在并行工作。图中的节点，即为大项目的子项目，或为小项目中的合同包。
在时标网络图中，将时间坐标放大顶部项目过程维中，各单元项承载的数据也就随之被放置在时间坐标中。进而，我们随之得到了有时间坐标的人员计划、图纸计划、材料计划、设备计划、场地计划、资金计划、机械计划、施工计划、验收计划、……。我们可以按照矩阵表的纵横两方向进行统计，进而，得到了有时间坐标的设计、招投标、施工等《项目各阶段计划》，或者，有时间坐标的《项目各专业系统的分包实施计划》其中包括各专业系统的设计、招投标、施工等工作。
2.2、当然，一般项目不是用此一个二维矩阵表格就能表现清楚的。按P3软件的原理说法，在大型工程项目的管理中，进度计划的编制一般是采用编制不同内容的多级计划(multilevel plan)和 多层计划。也就是说，项目在EPS、项目、WBS、作业、步骤上形成从粗到细的、按照项目渐进明细特征的层层细化的计划，计划的层次远远超过传统意义上的进度计划。而这一计划对不同级别的使用者来说反映不同的重点，对于高层领导，多层计划是看见较高级别的问题，从宏观的角度看是否存在工期的滞后、费用超出的问题，而对于分包合同的计划工程师来说，看见的是比较微观的问题，即工程计划的哪些WBS和哪些作业存在问题，应该如何去调整计划。
项目经理都知道，项目进度计划一般均有三级管理计划。
第一级为项目总进度计划，一级计划一般称为里程碑计划，一般反映的是重要的总形象进度控制点。
第二级为项目各阶段或各子项目进度计划，二级计划分为指导性计划与控制性计划，其中指导性计划由业主工程部门编制，其编制依据是里程碑计划及项目的投资与单位工程的轻重缓急编制，
第三级为各承包单位的合同实施进度计划。三级进度计划是由承包商根据二级控制性计划编制，可以说是合同包进度计划，反映承包商对所承包的项目内容的总体安排。
而四级计划则是三级计划的周、月、季、年作业实施计划，是对三级计划的进一步分解.通常用滚动计划。
滚动计划是在同一个计划上，在一个固定的时间，根据输入的实际进度，推算将来的进度。而每一次提交审批的，都是从这个计划内，抽取部份内容更新后提交。《年滚动计划》就是每年提交整个计划。《季滚动计划》就是每季提交数据日期后180天的推算。《月滚动计划》就是每月提交数据日期前30天的进度和数据日期后90天的推算。《周滚动计划》就是每周提交数据日期前7天的进度和数据日期后35天的推算。
各级上计划中的目标参数，例如，工期、成本、资源等，均按照工序间的关系路线进行汇总到上一级计划中。反映了工程施工由粗到细逐步深化的过程。在多层计划情况下，无论你处于哪一个级别，看见的计划都是完全一致的。无论是设计计划、采购计划还是施工计划，都完美地统一于总计划里面。例如，我们需要的只是设置设计的交图计划点与采购计划订单的接口、采购计划交货时间与施工计划的接口。例如对于一个大型工民建项目，首先可以分为业主、监理、总包单位、设计、分包单位、主要设备供应商等不同的应用单位，分别设为不同的级别；而其中的任一级别，又可以按施工部位和施工阶段分为不同的WBS；对于每一个WBS，又可以分解为不同的作业及作业步骤。对于每一次分解，都可以做出进度、费用……分解计划。在作业层次上使用作业完成百分比，在WBS和EPS层次上使用预算完成百分比，这样就可以在各个WBS上灵活地应用赢得值技术对一个或者多个项目进行绩效考核、进行工作变更的管理以及项目发展趋势的准确预测。
多层计划的编制是在里程碑计划完成之后，由各个应用单位编制自己的基于里程碑计划的独立计划，由业主项目控制部汇总后形成。它是自上而下编制的计划，由下而上地汇总实际进度。多层计划是由参与各方共同编制完成的，各个利益不同的参与方，分别编制自己的计划，而业主（或业主的项目管理单位）对该计划进行平衡。
由此可见，我们可以用表格嵌套的方法进行项目管理。
2.3、让我们拓展一下思维。我们联想一下进行建筑设计的过程。概括的说，建筑设计的过程是用二维纸张平面图来表现三维建筑物的过程，当然目前可以在电脑上用动画形式表现建筑物的三维空间。在用二维纸张表现三维建筑物时，我们一般将建筑物分解为数个楼层（就像是项目的多级多层概念）、然后是各楼层平面（就像是每个子项目二维分解）、再者是各楼层平面中所含的建筑要素（例如，墙体、天花、地面、活动家具、电气等）（就像是项目的条件――项目的配置、质量、进度、成本、资金、风险……），。然后，根据此模式，我们分别编制各楼层平面图（就像是项目的各子项目）、剖面图（就像是项目的各子项目的计划）、大样图（就像是项目的各工序）。
我们知道，项目管理实质上也是一个多维、时间、目标综合的管理系统。其一，是管理多层次系统，例如，项目管理层次有投资人、业主、项目经理、项目监理、设计单位、施工单位、供应商、分包商等；其二，是项目管理过程系统，例如项目管理过程有立项、规划、设计、报建、施工、验收、运营等；其三，是项目管理产出物系统，例如建设工程项目管理的产出物可以分解为外源、庭院、结构、建筑、风火水电、精装、艺术品等专业系统。其四，是项目管理中各约束条件的管理系统，例如建设工程项目管理中有技术配置、进度、质量、资源、成本、资金、场地、人力、机械、工具、图纸、材料物质等要素的管理。
参照上述建筑施工图的表现模式，我们可以将项目管理计划按以下方式进行：
A、项目相当于一个建筑，其子项目相当于单个楼层，
B、将项目管理过程与
C、项目产出物系统组成的二维矩阵表相当于各“楼层平面图”，
D、项目各约束条件维度相当于“各楼层中的要素”，
E、将项目管理各工种、工作、工序等，视为各分包合同中的“各步骤”。
如此，组成了一个四维、多级、多层、时间模型。
我们可以将此模型从各个角度进行剖切，剖切后可用各个二维的表格来分别表现多维的项目管理模型的各个侧面。例如，要建立项目的进度计划体系时，我们1. 按项目职能约束条件轴剖切面，可以建立《项目各管理目标（例如技术配置、进度、成本、质量…）的矩阵计划》，相当于上述项目各职能部门计划模式。2. 并可以按项目过程轴剖切面的方式，建立《项目各阶段的进度计划》，3. 或者同样按项目技术配置轴剖切面，即按项目合同包剖切面，建立《项目各专业系统分包合同的跨阶段进度计划表》。同样，4. 我们还可以针对项目中各合同包，建立各合同包的《子项目各各种剖切计划》。5. 每个合同包计划中，继续分解，同样建立详细工作步骤，建立并下发《工作任务单》。6. 各《工作任务单》的各要素可以向各各合同包汇总，再向各项目阶段汇总或向项目各专业系统汇总，再向项目各管理层次汇总。最后汇总成《项目各种总计划》状态数据，例如，最终汇总为项目的“技术总状态”、“总工期”、“总投资”、“资源总需求”等。
2.4、如果将前述的C、B二维组成的矩阵视为项目计划的表现形式，则项目计划可以视为一个个表格集合并相互嵌套。我们可以引进电子表格的优势，将三维的项目模型，用各表格嵌套的表现和计算模式，进行项目管理。即一个项目总计划为一个总工作簿，总工作簿中有许多工作表，其中第一张表为项目总技术配置计划，用于控制项目技术要求。第二表为项目总进度计划表，第三表为项目总成本计划各。总表格中的单元格嵌套着子项目。子项目为一个个子工作簿，各子工作簿中分别有许多工作表，其中第一张表为项目总技术配置计划，用于控制项目技术要求。第二表为项目总进度计划表，第三表为项目总成本计划……而且总表格中的单元格与子项目的表格中的单元格可以相互关联数据。这样就实现了项目进度计划分级、多层管理的目的。项目管理软件完全可以参照此模式编制。
具体说，我们可先将此二维所分解的工序和步骤，组成一个二维表格：例如，
顶部横向为过程轴――例如，立项、设计、招标、施工、验收、开业…
左侧竖向为项目技术配置轴――例如，市政外线、室外场区外线、结构工程、建筑工程、机电工程、精装工程、装饰品工程…
有了此表格，我们就可以用 软件进行项目有序分解了。我们可以得到一个二维表格，《项目总控计划》，表格中各单元均是项目分解后的总目标――大目标――小目标――合同包。
第一个合同包，就是一个子项目。同样，它们也需要进行有序分解……此每个子项目与整个项目，可以用 软件的表格关联方式。由此我们得到一个项目的多级分解结构系统，并得到第一个总工作表簿《项目总控计划》，（一个子项目的集合），
子项目，照此类推……
当然，关键是要有 网络图工具软件。还要在 中，建立树状大纲分解编码功能、透影功能、……
3. 期望
如果项目管理软件，特别是国内项目管理软件借用上述思路，抛弃甘特图，而改用“ 单双代号时标网络图”，并按上述矩阵表方式排列（同时可以制作一系列相关表格），则即发挥了单代号网络图或双代号网络图的图形化优势，又克服了无WBS表格化的缺点，最重要的是解决了多层、多级进度计划模式问题，岂不是项目管理软件的一大进步。
从事多年的建筑工程项目管理工作中，发现对中小企业还没有一个“能用的项目管理软件”。要么软件太大，要么功能单一。我认为中小企业“能用的项目管理软件”包括几个基本功能，而不仅仅局限于画画网络图。
1. 组织层次分解、计划分级分解及综合功能。现在的工程项目都是由业主、设计、监理、施工、分包、供应商等等单位共同实施的。大家编制各自的进度计划，而不是由某个人统一编制进度计划。如何能在一个共同的软件平台上综合计划，是一个能用的基本问题。
2. 项目分解、按PBS及WBS分解成矩阵表单。项目成功的一个基础是首先要知道“做什么（PBS）”，而后要知道“怎么作（WBS）”。
3. 项目文件档案管理。现在电子文件有建筑工程项目中越来越多。如何管理此电子文件，并按项目档案管理目录方法进行管理已经影响到项目竣工资料管理成效。同样，项目管理周期（PLM）软件，也应该从制造行业移植到建筑工程项目中来。
评论 作者： fhyq — 2008-07-18 @ 3:08 pm
fhyq:
几次同你联系均没有成功，希望你留下联系方式。你的评论是在太长，这样的宏篇巨著放在评论中有些可惜。而且没有正确的联系方式，不利于彼此的交流不是？
评论 作者： clockwork59 — 2008-07-31 @ 1:29 pm