WBS管理特点Word文档格式.docx
《WBS管理特点Word文档格式.docx》由会员分享，可在线阅读，更多相关《WBS管理特点Word文档格式.docx（9页珍藏版）》请在冰豆网上搜索。
自上而下法
自上而下法常常被视为构建WBS的常规方法，即从项目最大的单位开始，逐步将它们分解成下一级的多个子项。
这个过程就是要不断增加级数，细化工作任务。
这种方法对项目经理来说，可以说是最佳方法，因为他们具备广泛的技术知识和对项目的整体视角。
自下而上法
自下而上法，是要让项目项目经理成员从一开始就尽可能的确定项目有关的各项具体任务，然后将各项具体任务进行整合，并归总到一个整体活动或WBS的上一级内容当中去。
仍以ABC飞机制造公司设计制造新型战斗机为例，用这种方法，则不是开始就考察WBS制定的指导方针或是参考其他类似项目的WBS，而是尽可能详细的列出那些项目团队成员认为完成项目需要做的任务。
在列出详细的任务清单后，就开始对所有工作进行分类，以便于将这些详细的工作归入上一级的大项中。
比如说，项目团队某小组中的商业分析人员会知道他们必须确定用户对项目的要求以及该项目的内容要求;
工程师们也会知道他们必须确定对系统的要求和对发动机的要求。
于是，该小组可能会将这四项任务都归入到战斗机制造项目的概
念设计这个总项中去。
自下而上法一般都很费时，但这种方法对于WBS的创建来说，效果特别好。
项目经理经常对那些全新系统或方法的项目采用这种方法，或者用该法来促进全员参与或项目团队的协作。
使用指导方针如果存在WBS的指导方针，那就必须遵循这些方针。
（国防部）项目都要求承包商按照国防部提供的WBS模板提交他们的项目建议书。
许多DOD
这些建议书必须包括针对WBS中每一项任务的成本估算，既有明细估算项，也有归总估算项。
项目整体的成本估算必须是通过归总WBS底层各项任务成本而得到的。
当国防部有关人员对成本计划进行评审时，他们必须将承包商的成本估算与国防部的成本估算进行对比，如果某项WBS任务成本有很大的出入，那一般就意味着对要做的工作任务还没搞清楚。
三WBS的应用首先简单的介绍一下我们要应用WBS方法进行分解的管线项目经理管理系统:
在网络资源管理系统中，管线资源应该包含如下的几类:
基础空间信息局站,机楼、机房、背景地图（道路、居民地、河流、铁路、绿地……）管道,杆路网络资源人,手井、管道段、管孔、子管、电杆、吊线、线担,支架,抱箍、吊瓶,线夹、杆路项目经理等电缆网络资源电缆段、电缆附件信息（传感器、分歧接头、气门、余长点等）、MDF、交接箱、分线盒等光缆网络资源光缆段、光缆附件信息（光纤接头盒、余长点）、ODF、光交接箱、光分纤设备等传输网络资源DWDM,PDH,SDH设备物理资源、DWDM,PDH,SDH逻辑资源（如光波道、段、通道、槽道、电路等）、传输倒数字配线架（DDF）数据网络资源ATM、IP、DDN、帧中继、分组项目经理等网络设备资源及逻辑资源管线资源管理系统主要实现对管道、杆路、电缆、光缆以及设备的管理，以及实现对97用户配线系统进行支撑的功能，主要的功能分为基础空间资源管理、管线项目经理、拓扑管理功能、路由设计分析、用户配线、资源调度、业务档案管理、查询统计、管线网络分析、系统管理、设备管理、专线业务、系统接口、数据管理等（利用该系统，能够实现对管线资源的统一管理，从而达到为生产、建设、维护部门提供良好的统计分析、网络资源优化、规划设计和辅助决策的目的。
下面我们将使用自上而下的方法对该系统进行WBS分解第一次分解:
使用项目管理过程（包括启动，计划，实施，控制和收尾）作为工作分解结构的第一层，这样不仅可以确保项目团队实施良好的项目管理惯用做法，而且还可以比较容易的按照时间安排工作分解结构的各项活动（第二次分解:
在第一次分解中，将功能设计已经分解到了子系统范围，而每个子系统，一般而言，都可以分解为若干模块，由模块则可以分解到具体的功能点，现以管线团队设计为例，继续分解如下，第一次分解和第二次分解的相互关系:
后者在项目全过程管理工作的不同阶段，为前者提供不同的项目WBS分解的层次，以满足不同阶段计划和控制管理的需要。
根据以上WBS的分解结果，我们就可以在项目的不同阶段对项目进行估算（成本和日历）、安排进度、作出预算、分配负责人员或组织单位，以便顺利完成项目。
四结语由以上的分析，我们可以看到，WBS在项目管理中可以帮助我们实现:
将项目分解为相互独立的、容易充分管理的、通用的项目产品/设施;
分配负责这些项目产品/设施的人员或单位，与其组织机构分解结构（OBS）相关联;
设定这些项目产品/设施之间的业务逻辑关系、工作顺序，做进度计划安排;
计划实施这些项目产品/设施所需的团队分解结构（RBS）,人员/材料/设备，做费用估计;
确定这些项目产品/设施应符合的质量团队、团队环境保护规定;
通过WBS和OBS，得到职能责任矩阵，形成项目各参与方的团队团队，制定沟通计划;
统一的WBS、RBS、OBS，有助于对整个项目的工作范围、费用、进度和质量进行计划和控制，提高管理效率;
对WBS、RBS和OBS进行编码，建立统一的项目管理信息平台，关联与项目有关的各类数据，实现对工程项目的实时控制，也为各参与方调整计划，控制变更，提供及时的项目决策依据;
统一的项目团队的建立，帮助企业形成自身需要的各类工程项目经验数据，指导今后类似工程的工作。
由此可见，统一的、标准化的WBS分解体系对解决团队项目管理中存在的问题，对快速提高我们的项目管理水平具有重要意义。
以WBS分解结构为基础，建立的统一的项目管理信息系统平台，将大大提升我们项目管理的效率和项目信息的实时性，真正实现项目管理信息库数据关联、信息共享的关键，也为建筑企业持续积累历史数据提供平台。
网站项目开发WBS（WorkBreakdownStructure，工作分解结构）分解，与传统软件开发项目类似，但又不完全相同。
首先明确网站项目的目标以及里程碑，通常团队接受的网站项目开发有两种类型，一种是任务型项目，一种是产品型项目。
任务型项目以完成用户预期目的为主要目标，项目通常目标比较明确，但任务本身不具备完整的产品形态;
产品型项目是以完成用户描述的产品功能、性能为主要目标的项目开发。
对这两种类型项目，在进行WBS分解时，要采用两种不同的方式:
任务型项目的WBS分解，任务型项目的分解应以核心作业过程作为其里程碑的节点，例如:
我们把某个网站存放位置从A主机转移到B主机，并保证网站随时可以正常访问，可以采用如下的工作分解结构:
1）B主机环境搭建;
2）A主机内容转移到B主机;
3）B主机试运行测试;
4）修改域名DNS。
在任务分解时，先确定关键作业的前置或后置关系，作为整个WBS的里程碑节点，然后在此基础上，添加其它非关键作业。
核算这类项目成本时，按资源的实际消耗量以及作业频率进行核算。
产品型项目的WBS分解，产品型项目的分解应以完成的核心产品部件作为其里程碑的节点，分解时先不考虑资源环境，而只考虑目标产品自身功能结构。
在核心部件内部再按任务型方式分解，但对于较大型产品，可能还需要几个层次的产品结构分解。
举个例子:
现在要建立一个电子商务网站，可以采用如下的工作分解结构:
1）产品管理系统
2）订单管理系统
3）支付管理系统
4）信用管理系统
5）物流管理系统
在任务分解时，先确定网站的核心功能，作为WBS分解的第一层次，然后再逐项分解，以分解到单纯资源消耗性任务作为分解的最底层。
产品成本由每个部件产本构成。
实践中，能制定一份切实可行的WBS并不是一件很容易的事，因为时间、资源能力以及预期成本都是制约WBS的因素。
文章二:
项目跟踪控制的目的是保证项目目标的达成。
项目周期是重要的项目目标，因此进度控制是重要的监控内容，同时软件产品的质量，成本等也应该根据当初定义的目标进行监控。
否则到了时间点，产品完成了但质量和成本都达不到要求，仍然是失败。
有监控但项目仍然延期，或者说仍然达不到当初定义的质量和成本要求，原因何在,只跟踪不控制，只发现问题不找寻根源和解决问题，只应急处理问题而不是提前观察各种征兆是监控中最常见的现象。
进度跟踪中发现进度偏差的根源分析:
1.任务本身的估算问题
任务本身的工作量估算是否合理,进度出现偏差首先要考虑的工作量的估算是否合理，是否考虑了工作中存在的技术难点，是否考虑了项目成员自身的技能，是否考虑了其它应该考虑的风险。
任务计划下达给项目成员时候应该获取承诺，但很多时候获取承诺是无用的，是否可以承诺或者是否能完成承诺跟项目成员的个人经验和技能有太大的关系。
当偏差出在估算上，而且后续项目都是采用的相同估算模式的情况，调整项目计划往往是必须的了。
对于短期型的项目，如果这个时候才发现是项目成员技能问题，而想通过培训来提高技能以取得立竿见影的效果往往已经是不现实的。
如果项目任务中存在着技术攻关或技术难点需要解决，对于这种任务往往是很难估计工作量的，而且一旦在技术问题上被卡住往往对项目进度产生致命的影响。
唯一的方式就是把无法预测和不透明的东西转换为透明，在项目开始之前就应该进行风险分析和应对，提前进行技术问题的预研，开发原型，积累相关的知识和经验。
估算问题的根源又出在历史项目或版本对项目历史数据的采集和分析不够，准确的估算依赖于专家的经验，但专家的经验同样是依赖于历史项目和历史数据。
估算问题的根源还在于对项目成员技能和生产率水平没有较清楚的认识，一个软件类任务的完成往往存在着巨大的个人生产率差异和进度差异。
2.任务本身的粒度问题
对于一个软件项目，出现1-2天的偏差很容易得到纠正。
而如果出现1-2周的偏差则很难再进行纠正。
任务本身的粒度和工作量直接和偏差的大小相关。
当任务本身的粒度太大的时候是不适宜进行跟踪的，任务本身是否会偏差不在取决于跟踪者，而是执行者对于大粒度的任务是否有很好的细分和自我控制能力。
任何一个任务，要么不出现偏差，要么出现成倍的偏差。
一个任务的粒度如果是1个月，那这个任务很有可能要2个月才能完成，如果我们的进度偏差最多允许一周，则需要把任务粒度细化到周，按周进行跟踪。
如果对于任务最多允许偏差1-2天，则需要把任务粒度细化到天，按天来进行跟踪。
细粒度的跟踪目的就是要消除不确定性因素和风险，尽可能早的发现任务中的问题，这样才有可能有时间来解决问题和纠正偏差。
对于大粒度的项目任务，任务内部本身也存在跟踪但一般只能有项目成员自己进行。
任务没有细分，成员反馈的任何任务完成40%,70%等完成百分比都是不可靠和主观的数据。
项目成员的自我监控能力对进度是否偏差起到重要的影响，在这种情况下，任务是否能够按期完成对项目经理是不可控的，因此项目经理必须对成员有充分的了解和信任。
3.项目经理对业务和技术领域的不熟悉
对于IT领域项目经理，对业务和技术领域的熟悉是必须具备的能力。
有了这些能力才可能和项目组一起得出比较好的WBS分解和任务工作量的估算，有了这些能力才可能实现细粒度任务的划分，并定义清晰的出入口准则。
在项目的跟踪过程中往往体现的较多的是项目管理能力，但在项目控制过程中体现更多的则是业务和技术能力。
控制的目的是真正去发现问题的根源，去解决问题并纠正偏差。
项目经理给项目成员安排了一个任务，要求本周完成，到了周末项目成员反馈无法完成需要延期2天，项目经理就确认延期两天并调整后续任务。
到了下周二，项目成员又反馈出现了新问题，有个细节没有考虑到还需要延期三天，项目经理不得已又进行任务调整。
这就是我们常看到的场景，整个任务和项目计划都变得不可控制了，项目成员有责任，但项目经理同样有责任，项目经理在第一次出现偏差时候就应该介入任务或问题本身，帮忙一次诊断和分析问题，挖掘问题延期根源，或者调整任务粒度，改进监控方式，而这些都需要项目经理具备一定的业务和技术能力，具备相关的经验积累及时做出指导。
在第一次出现进度偏差的时候，你需要的就是及时介入问题，查找问题根源而不是简单的关注成员反馈的下一个可能完成的时间点。
只有这样才可能进度小偏差就立即查找根源并控制，而不是进度大偏差的时候进行应急。
4.最后总结
项目总体进度允许偏差确定了项目任务粒度划分和任务跟踪频度。
很多进度问题是前期没有进行充足风险分析和提前应对。
估算很重要，一份不切实际的进度再怎么跟踪都只可能延期或低质量。
任务完成百分比不可靠，可靠方法是任务细分并定义严格的出入口准则。
第一次延期就应该介入问题，查找根源而不是乐观期待下一个可能完成点。
文章三:
2004年版PMBOK指南对WBS的解释:
WorkBreakdownStructure（WBS）工作分解结构:
对应当由项目团队执行以便实现项目目标，并创造必要的可交付成果工作，按可交付成果所
做的层次分解。
WBS将项目的整个范围组织在一起并加以明确。
每向下分解一个层次，就意味着项目工作的定义深入了一步。
WBS最终分解为工作细目。
WBS的层次结构以可交付成果为对象，包括内部和外部可交付成果。
WBS和WBS字典是项目范围的核心，通过WBS分解真正使项目目标和范围和项目进度中具体的工作任务有效的衔接起来。
WBS分解的难点不在是否有WBS模板，不在于WBS分解的方法和层次，分解的粒度等内容，更多的困难点在项目管理组要对整个项目目标范围相当熟悉，要对特定业务领域的业务运作和管理相当熟悉。
比如对于IT项目如果对软件项目管理方法论，软件过程改进，软件工程和生命周期不熟悉，或者没有积累如果经验很难分解出有效的WBS。
分解WBS，确定活动任务，已经活动排序依赖这些都不是孤立和严格先后关系的过程。
在这个过程中不断的存在着反复和调整，调整重要目的仍然是保证制定出有效的进度计划，保证后期的质量和成本控制有基准。
WBS的最底层是工作包，工作包必须是严格的输出物并且可验证。
对于小型项目个人认为工作包可以直接作为任务下达。
WBS是项目范围的全集，但不要忽视了WBS字典，WBS字典是对WBS每个分解项要求的详细描述。
简单讲，项目进展过程中的任何产出物，任何活动都应该在WBS中有体现。
项目执行中应该只做应该做的事情，不能遗漏也不能镀金。
WBS分解的越清晰，完善，说明项目管理组对整个项目全景的把握越好，越心中有数。
对于软件项目，我们最终需要提交的是软件产品，因此WBS的核心应该是结合了软件开发生命周期模型的产品分解结构（PBS）。
PBS再结合项目管理过程，配置变更等支持过程共同构成工作分解结构。
因此WBS应该是包含了工程域，管理域和支持域的内容，其核心是产品分解结构，其它活动和任务都是保证项目目标，保证产品能按质按时完成。
WBS是项目管理的基石，WBS首先解决了做正确的事情，其次才能去做到正确的做事情。
文章四:
如何建立有效的WBS结构,
在项目管理过程中，项目规划和控制是非常重要的一个环节，良好的项目规划能同时对项目进度、质量和投资起到很好的控制作用，失败的项目规划则有可能带来混乱、失控甚至项目的最终失败。
在项目规划的过程中，人们往往会求助于WBS方法进行项目工作内容的分解。
在此基础之上再进行资源的分配、进度计划并估计项目的成本。
WBS随着项目规模的差异所起的作用不尽相同。
小的项目只需要很简单的WBS结构，结构的划分基本上是一目了然的，得到的结果容易得到认可。
项目规模越大，WBS也越重要，从另外一个角度来讲也越难做好。
对大型项目而言，确定项目的WBS结构往往不可一蹴而就，需要经过多次反馈、修正，最后才能得到一个项目各方都能接受的WBS结构。
划分项目的WBS结构有许多方法，如按照专业划分、按照子系统、子工程划分、按照项目不同的阶段划分等，以上每一种方法度有其优缺点。
一般情况下，确定项目的WBS结构需要组合以上几种方法进行，在WBS的不同层次使用不同的方法。
那么，确定项目的WBS结构需要遵循何种方法和原则呢,
在回答这个问题之前，首先需要反问一下为什么需要WBS结构，也就是说，WBS在项目过程中究竟起到何种作用,这个问题涉及到项目规划和管理的几个层次。
良好的项目管理必须具备以下因素:
对项目的认知、为项目提供良好的协同环境和有效的控制。
这几个因素环环相扣，前者是后者的必要条件。
一个良好的WBS结构在项目管理中所起的作用也可以这三个层次来理解。
站在认知的层次，WBS所起的作用是一目了然的。
对项目的认知是协同和控制的基础，如果项目各方对项目本身如果没有一个清晰的无歧义认知的话，项目的成功几乎是不可想象的。
WBS的层次结构为我们认识、把握复杂项目的逻辑关系提供了良好的工具。
在共同认知的基础上，项目的成功还有赖于良好的协同环境。
一个复杂的项目往往有许多参与者，例如高速公路基建项目，参与者会包括:
政府部门、业主、设计咨询机构、施工单位、
设备采购供应商、施工监理单位等。
项目的顺利进展有赖于这些不同角色的协同工作。
由于这些参与者在项目过程中从事不同的工作，需要不同的信息。
比如，复杂的项目会遵循先自上而下后自下而上的计划制定过程。
两种计划的粒度和范围都是不一样的，但二者需要有机地结合起来形成统一的计划，WBS结构为这些信息提供了一个结构框架。
另外和邮政系统中的邮政编码类似，WBS结构还可以成为进度、资源等信息的标签，使不同层次的信息就可以在预先规定的线路中漫游。
认知和协同环境并不必然意味着项目的自动成功。
项目管理者还必须对项目的进度、范围和资源进行有效的控制。
为了进行有效的控制，必须对项目中的工作任务进行范围界定。
清楚的范围界定能有效防止出现纠纷时合同双方牵扯不清，同时还有助于业主对承包单位进行数量最少但最有效的控制。
而WBS结构实际上有助于界定范围，当然，这实际上也是对WBS结构的要求。
回答了WBS作用的问题，现在可以对不同的WBS划分方法进行分析。
首先是按照专业划分项目，应当说这是一种最自然的划分方法，优点是容易让人接受，缺点是不易协调。
比如，在进行地铁建设时，假定在WBS的顶层按照专业将建设分为土建和安装，并按照这种划分确定一个土建分项目经理和一个安装分项目经理。
按照这种划分方法在画项目的网络图时就会出现一系列的土建作业和一系列的安装作业。
因为某一个车站即包括土建工程又包括安装工程，这样在两组作业组之间就会出现非常复杂的关系，分项目经理之间也很难协调工作。
按照系统划分方法容易界定项目范围，但有时候显得不那么直观。
系统是人们在长期实践中确定的一种分类方法，其特点是系统与系统之间的联系往往是比较简单的，这种联系通常被称为系统界面或接口。
正由于系统之间的界面比较清楚，所以按照系统对项目进行划分更容易界定子项目或子工程的范围，在项目实施过程中更容易控制结果。
按照项目的不同阶段划分WBS结构有利于项目管理者控制中间结果。
对那些不确定性比较大的项目来说，项目最后的结果往往是未知的，控制项目的唯一方法就是控制中间结果的
进度和质量，当然阶段的划分应该是可测量的。
按照阶段划分项目有助于管理者在不同阶段控制中间成果同时不至于使项目管理者陷入到项目细节中去。
不同的项目，其范围、性质可能都不一样，项目管理的目标和重点不尽相同，项目的WBS结构也并不一样。
但无论对何种项目进行WBS划分，都必须兼顾WBS的三种不同层次的作用。
划分项目的WBS结构还必须遵循一定的方法论。
具体说来，划分项目的WBS结构必须遵循以下步骤:
确定项目特性并确定WBS层次，比如项目的不确定有多大,项目的规模又是多大,,确定项目管理的重点，为项目管理目标划分优先级别，比如，项目质量是放在第一位的，还是项目进度居于首位,
针对项目管理目标的优先级别确定每级WBS划分方法。
确定WBS结构。
文章五:
建立WBS五建议
当你必须从头建立一个进度表时，工作分解结构（WBS）是了解项目工作详细情况的最佳方式。
它被用来把项目分解成主要的阶段、可交付项和项目建立的工作要素。
然后，可以将这些工作要素分解成建立这些要素所必需的活动。
WBS和最终进度表（它需要确定先后次序、资源、预计的努力、预计的期限等）并不相同。
在制定工作分解结构时，请应用以下五条建议:
为大型项目建立一个WBS字典
一般来说，你不需要WBS字典，但如果你的WBS含有数百（或数千）条详细的活动，那么手工进行追踪可能是一件繁重的工作。
在这种情况下，把所有重要信息放入一个WBS字典中会有好处。
WBS字典有助于追踪所有的概要和详细的活动，包括一个简短的说明、WBS数字标识符（1.1、1.1.1、1.1.2等）和预计的努力。
如果你把WBS字典输入到一个专门的工具中，这个工具还有助于追踪WBS的变化。
用概要活动作转折点
你的WBS中应包含详细和概要活动。
（概要活动指能够进一步分解的活动;
而详细活动指不能进一步分解的活动。
）虽然进度表中可能仅包含详细活动，用概要活动作为转折点（表明一个可交付项或一组可交付项完成的标记）会有好处。
由于概要活动表示所有基本的详细工作都已完成，因此可用它作为转折点。
把活动分解成二个或更多详细活动
我看到一些团队把WBS中的一个活动分解成下个阶段的一个活动。
在我看来，这
升级会员 