WBS建立疑问_项目管理问答

用户名密码

联盟服务关于我们联系方式收藏本站

服
务
区

网站登录：会员企业专家服务商
企业服务：PMP培训内训课公开课
工具箱：发表文章提问题发案例

首页：动态 | 文库 | 下载 | 书架 | 访谈 | 专栏 | 专题 | 人才 | 培训 | 软件 | PMC

互动：活动 | 案例 | 问答 | 论坛 | 博客 | 圈子

应用：基础┊工程┊软件┊制造┊活动┊研发认证：PMP┊ACP┊PgMP┊IPMP┊P2┊ISPMP┊IMCP┊建造师┊MPM 特色：热点┊奖项

适合敏捷开发项目
敏捷项目管理最佳实践

重视项目商业分析
商业价值与需求分析能力

产品管理国际认证
全球产品管理最佳实践

单项目管理经典指南
年轻项目经理首选

北京 | 直播 | 录播

大型复杂项目全球标准
定位高级项目管理层

链接战略与项目
实现组织资源投资回报

信息系统项目管理师
系统集成项目管理工程师

计划 | 报名 | 经验

more >> 特约专家

项目管理讲师

项目管理软件专家

行业项目管理专家

more >> 本站热点

当前位置：咨询首页 >> 查看问题

WBS建立疑问 (咨询专家：傅永康) [已答]

您好！
关于WBS建立的问题想要咨询您一下：建立WBS时发现建立的WBS如果做得宽泛了就没有计划的意义，如果做的太细有会有很多突发情况使得计划不实际。怎样建立一个合理合用的WBS既能符合实际又能弹性包含突发情况造成的影响？有什么原则吗？谢谢您！

提问人：桂益民 [西子奥的斯|||otis] 提问时间：2014-02-23

专家回复
姓名：傅永康单位：上海清晖管理咨询有限公司行业：教育科研培训擅长领域： PMP认证培训，CMMI咨询	该问题专家还未回复。

提交回复

会员回复

WBS应该参照相关专业的WBS模板，特别是本公司以前工作的模板，这样才能适应自己公司的组织结构及工作节奏。

回复会员：hina 回复时间：2014-09-21

灵活运用“80/20"原则

回复会员：mikeye 回复时间：2014-08-24

以下，供参考：1、有必要提高估计成本和工期的精确性吗2、是不是不只一人对工作内容负责3、有必要准确的知道工作包中活动的时间安排吗4、在工作包的活动中需要成本支出吗5、中间活动和其他工作包之间有任何关联吗6、在执行工作过程中的工作元素有任何重要时间的中断吗7、过一定时间工作包中的资源需求变化吗8、工作元素中的中间支付的前提有区别吗9、在完成整个工作包之前有合适的可接受的准则吗10、工作包中要执行的一部分工作能够被作为一个单元安排吗11、有需要集中精力于一部分工作包的风险吗？这些工作包需要进一步的分解以使风险分散12、工作包能够被清楚和完全地理解以满足不同的利益相关者吗

回复会员：thinkinpm 回复时间：2014-08-05

这个属于风险控制的事情了，突发事情

回复会员：suvina9 回复时间：2014-06-27

这个问题：我个人认为，WBS建立不是随意的建立，应该按照项目层级、专业、时间段及计划的层级，详细的专题会作出项目文件形式。不是计划工程师个人建立，而是参照项目运行文件相关规定建立。

回复会员：sun258 回复时间：2014-05-16

我也来学习学习

回复会员：lubt 回复时间：2014-05-14

建议参照《有效的工作分解结构

回复会员：xingfuABC 回复时间：2014-05-12

分解到能够执行的最小任务

回复会员：qyb431 回复时间：2014-05-12

以最终交付物为导向，设定分段里程碑，明确各分段的交付物，敲定合适的项目组成员，时间、成本、质量相对的考虑一下，其它的不要规定的太过严苛，没有浮动余地就没有空间调整与纠偏

回复会员：第四十刃04 回复时间：2014-05-06

按照pmp中的说法来做划分，让后根据具体的情况在做一个适当的调整，个人觉得其实没有个具体的标准，就像说每个项目都是不一样的，那不会有一样的分解，我个人觉得合理就好，这个合理的度需要你去把握

回复会员：nuotuo800 回复时间：2014-05-05

我认为首先要看看WBS到底能做到哪些？不只是围绕PBS或什么原则来划分，这些都是技术问题。而是从管理的角度去思考，分享大家一个图http://www.chinapcu.com/thread-122-1-1.html
就像图中看到的，你的管理目标包含哪些？如进度、费控、风险。。，然后再思考如何去划分，包括你的视角（甲方、乙方）、你的深度（你的团队可管理的深度和可接受的管理成本），大家通用的原则无非是SMART原则。

回复会员：frankhorse 回复时间：2014-04-29

我也想学习，刚接触不久

回复会员：underfrozen 回复时间：2014-04-28

看你的项目的大小，一般可以采用时间以及费用来控制WBS的大小

回复会员：haojidee 回复时间：2014-04-24

WBS 的功用在於理清項目中必須要執行的細節。可以用process mapping 對映出時間序列有關事項或用product mapping對映出不同類別的事項，然後再細步分解出每一件與資源相關的事件。其目的都是在管理每一個事件所須動用的資源(人事地物或資金)。

回复会员：QQolly 回复时间：2014-04-24

你好，我也是遇到同样的困惑，我个人体会，在简历wbs之前，一定要有个明细的组织架构以及人员配置，而工作的分解的界面要适合组织架构的，分解的任务也要与人员的能力配备。

回复会员：zhaochangpeng 回复时间：2014-04-17

WBS，既然是工作任务分解，那说明其对于后期项目开发起着比较重的作用，细化程度可做详细些。

回复会员：mike58811868 回复时间：2014-04-15

您好！WBS有粗有细，站在不同的角度去做，内容和细致程度不一样。要做进度计划，这个WBS的工作定义应该是最小的块，当然是越详细越好。

回复会员：qi2jing 回复时间：2014-04-15

一般来说，WBS最好控制在4-6层以内，根据项目和项目模块的复杂程度，如果需要的话，可以将WBS中的一个复杂的工作包单独拎出来，做一个独立的WBS。

回复会员：yinzhiwang 回复时间：2014-04-14

细化到风险可控的程度：
如果觉得到这个程度，风险还比较大，难以把控，继续细化；
如果觉得风险到这个层级已经能掌握了，就不必再细化。

回复会员：欣木回复时间：2014-04-11

先确定好里程碑，作为WBS的第一层。
然后确定完成里程碑需要完成那些可交付成果。作为WBS第二层。
实现这些可交付成果，需要完成那些规定动作。作为WBS第三层。
当然在不同行业有不同的划分方式。
谢谢！

回复会员：xwshawn 回复时间：2014-04-09

其实也不要把WBS想的太绝对了，我们主要的目的是利用WBS对我们的工作进行分析，这只是一个工作的工具和手段，根据这种方法，结合自己的工作目标，对任务按WBS的程序结合实际进行分析，了解在完成每一步工作时涉及到的所有问题和相关的问题，然后按计划实施，在过程中随时根据出现的问题进行处理，目的只有一个就是完成工作目标。

回复会员：sbjlj 回复时间：2014-04-08

一切都可以变通。。。

回复会员：by611 回复时间：2014-04-04

个人觉得WBS建立应该根据项目的具体情况，根据项目各个阶段分布分项工程的重点难点来区分细化程度

回复会员：winter0606 回复时间：2014-04-03

可以按照40或者80小时的工作考虑，也可以按照可交付成果考虑

回复会员：zjcc 回复时间：2014-04-03

学习了！

回复会员：elaineying1984 回复时间：2014-04-02

WBS不应以太粗或太细来定分解层次或颗粒度，其根本标准是看分解出来的活动是否可控；另外，在项目管理过程中还要主动识别每个活动存在的风险，并策划相应对策；变与不变也是辩证的，计划内容在一定范围内变动是正常的。

回复会员：llano 回复时间：2014-04-01

好。

回复会员：luhongyou 回复时间：2014-04-01

分解到1周或者2周，主要是比较明确的目标(story)，但是在进行风险分析时需要尽可能的细致。
项目开展过程中逐步细化(比如当前这一周和未来一周的是比较清楚的)

回复会员：liquory 回复时间：2014-03-29

不宜太多，应该划分到责任人级别就可以吧，目的是归到项目计划中，作为一个activity。个人理解

回复会员：renleiqing 回复时间：2014-03-25

确实如你所说，太泛了就管不住了，太细了就不灵活了。所以每个项目均需要根据实际情况，征求多方意见，才能确定。其实，wbs里面涵盖你关注的内容，细化重点关注的内容就好了。

回复会员：1bit 回复时间：2014-03-24

这要要根据你的项目大少，管理需要来分，不能一概而论吧。

回复会员：3825908 回复时间：2014-03-23

需要和您的项目规模相匹配。

回复会员：gtboyyyr 回复时间：2014-03-23

学习，同样的疑问

回复会员：liyupashu 回复时间：2014-03-21

分解的颗粒度保持在3天左右，理论上是这样的。在实际操作中，要尽可能保证每个节点都有必要的可交付物。这种颗粒度是比较容易掌控的。

回复会员：brian007 回复时间：2014-03-20

根据工作包的时间限制，自己把握最佳时间

回复会员：kele829 回复时间：2014-03-20

个人认为粗略的和细化的都应该做。

回复会员：awai192 回复时间：2014-03-19

好。非常好。

回复会员：xhwswq 回复时间：2014-03-19

这个要根据工作的细化程度来定，一般来讲WBS的最低级必须是可交付的工作包，work pakage.

回复会员：gongzhaojin 回复时间：2014-03-18

同问

回复会员：张三回复时间：2014-03-18

2周 4层左右

回复会员：jiale 回复时间：2014-03-17

四十八十原则

回复会员：chqtong 回复时间：2014-03-17

学习，同样的疑问

回复会员：kathy0476 回复时间：2014-03-14

WBS建立同时，请先建立以范畴为导向的"目标"项目(第一层展开)

回复会员：hyh651225 回复时间：2014-03-14

我也想学习

回复会员：ftagain 回复时间：2014-03-13

分解到可以直接作为进度计划和控制的工具的程度。

回复会员：岚冰回复时间：2014-03-13

WBS分解原则是可执行或交付的工作或产品，是一个工作包不是具体的工作，风险的管控可以设定缓冲时间，但哪是另外一个问题了，因为在排定工作计划时，具体工作的完成时间是估算的，并不在WBS中体现，WBS也不能体现出风险。

回复会员：c60397130 回复时间：2014-03-08

需要对产品进行分解，根据你可以完成，可以衡量的最小模块进行切割划分，当然，不是越小越好，建议切割规模是5个工作日能完成的任务。

回复会员：marcojiang 回复时间：2014-03-07

WBS是针对项目可交付成果进行工作的分解，个人认为对于突发事件，如果所说的突发事件是可能发生或可能不发生的情况，这不应该在WBS中考虑，而是在风险管理中考虑的。

回复会员：fengxun 回复时间：2014-03-07

wbs分解的原则是到可执行，可度量，可考核的程度

回复会员：phemen79 回复时间：2014-03-07

分解到可控的单元。范围可控、时间可控、资源可控。

回复会员：janeite 回复时间：2014-03-06

我认为先按照提交物无来分解，再按照产生提交物的活动和任务来分解即可

回复会员：secit 回复时间：2014-03-06

在实际工作中没有一个万能的标准，要看具体的项目情况。
就WBS分解的大小，一般性原则有3点：
1 分层原则。
项目--阶段--任务--子任务--工作单元
2、 80小时原则
3、逐步求精原则，由于是逐步求精，所以刚开始分解的时候，本着“够用”就好。所谓够用，就是计划能够报批，相关数据可以执行为原则。

回复会员：zouwen99 回复时间：2014-03-06

WBS分解到可量化的活动包

回复会员：ketiy2004 回复时间：2014-03-05

80原则

回复会员：cczbamboo 回复时间：2014-03-05

我认为细化到能具体考核的标准即可，不能一味追求细化

回复会员：luojian2046 回复时间：2014-03-01

我都有疑问

回复会员：bnuhay 回复时间：2014-03-01

根据80小时的原则，工作包的时间跨度不要超过2周时间

回复会员：zyly11 回复时间：2014-03-01

分解到能够执行的最小工作单元

回复会员：maggie0926 回复时间：2014-02-26

我认为应该是自己掌握大致的项目进度，具体的项目进度由开发人员掌控，项目管理人员跟进即可

回复会员：xieweiq 回复时间：2014-02-26

根据项目的情况，所需要的wbs层级分解不尽一致，分析任务的目标和操作性具体考量制定。

回复会员：cruellin 回复时间：2014-02-26

更具项目工作任务和项目性质合理拆分工作层级，拆分粒度要视项目工作任务和项目性质而定。

回复会员：lljlls2014 回复时间：2014-02-25

做两份，一个粗略的，供领导查阅，一份详尽的，供自己随时审查

回复会员：maweihh 回复时间：2014-02-24

wbs分解的原则是到可执行，可度量，可考核的程度

回复会员：hutony 回复时间：2014-02-24

WBS的分解原则，请去看PMBOK2012，即可！

回复会员：xiangmu2070 回复时间：2014-02-24

建议参照《有效的工作分解结构》，谢谢！

回复会员：lei20061104 回复时间：2014-02-24

排行榜 [24年4月]

会员	积分	问题	回答
iJzhong	3	0	1
guojision	3	0	1
qqaaa	3	0	1
阿灿onthewa	3	0	1
touefeel	3	0	1

如转载本站文章，必须于文章开头处注明转自“项目管理者联盟”，并注明原作者

PMI,Project Management Professional, OPM3, PMBOK, PMP，PgMP，PfMP，PMI-ACP，PMI-PBA
and the PMI Registered Education Provider logo are registered trademarks of the Project Management Institute, Inc.