ZT“WBS应该多细”及 WBS的几个问题

清风徐来

fficeffice" />下划线是我的回答，大家看合理不合理

 

问题

1 WBS应当在什么时候拟定最为恰当？
在项目调研前计划，做草案，调研后，细化WBS

 

2 分解程度需要多细致为最佳？
和项目目标有关系，可以从工作成果、成本、人员 上加以控制

不重复，不遗漏

 

 

3 WBS的更改和维护怎样进行比较合适？

 项目实施前，有文档对变更流程有约定；必须按一定流程变更，并且有记录和反馈；

 

 

 

[讨论]WBS应该多细致？... ...

 

 

 

问题的引出

 

项目分解不宜太细

作者： WEBYY

 

我们经常遇到人们问我们“我们这个项目有多少任务”或“我在做项目计划时应该做多详细”这样的问题。这种情况不只是刚做项目的项目经理会问，有些经常做项目经理也会感到困惑。对于在项目分解时遇到的这些问题，我想谈一些自己的看法。

 

项目经理经常容易犯的一个错误就采用太细的清单任务列表法，也就是把项目分成了太多的任务，他们把项目分解到了一个小时就能完成的琐碎的任务。当然认为项目计划应该详细到项目中的每一个人应该做的每一件事这样的思路是可以理解的。但是如果认为一个项目经理的工作就是一天拿着一个写好了的、有许多任务的单子，然后把已经完成的任务一个一个销掉，这就有些不对了。也就是说，项目计划应该是为了做好项目上的每一件事的一步一步的程序，这样做的目的是为了防止同样的事被重复地做。如果项目经理没有这种理念的话，那么就提高了我们重复做这个项目中有些相同的事的可能性。

 

有许多人认为在项目中，项目经理应该尽力去想每一件事。如果是一个小项目，项目经理可能还有这个能力和精力，如果是比较大的项目，特别是当一个项目经理同时管理着几个性质相同或相近的项目时，如果让项目经理去考虑每一件事，这种可能性是很小的。因此在现实的项目管理中，我们必须依靠专家的力量，即使这样一个项目经理和它的智囊团要想管理项目中每一个小任务，也是不太现实的。

 

这种太细的清单任务列表方法使项目管理经理在做项目计划时增加了成百或者上千的任务。这些任务大多数仅需要几个小时或者几天的时间。这样的项目分解能够使得项目经理更好地控制和导致项目成功吗？从我们的观点看，一个太细的清单任务列表方法不能使我们很好的控制，可能更易增加项目不成功的可能性。

 

首先，详细的任务列表方法导致甚至是鼓励了项目经理在项目上采用微观管理。当一个项目里有不认真工作的人时，可以采用微观的管理方法。但事实上很少有一个项目团队里大部分人员都是不认真工作的人。我们相信你的项目团队中大部分人在微观管理方式下不能取得成功。这种方式其实是对那些本应对任务结果负责的人过分依靠项目经理，而不是独立处理问题提供了方便。如何激发任务负责人的独立处理问题的能力？

 

第二，项目经理是采用通过考查下属取得的成绩来管理下属，还是采用看下属是否完成了某项任务来管理他们，哪一种方式会更有效呢?我们相信前者会更有效。如果采用后一种方式管理下属，可能会出现下属虽然把任务完成了但没有取得应有的成果的情况。不但要清楚具体的工作内容，还要明白为什么要做这项工作，与整个项目成功的关系

 

第三，这种详细的任务列表的方法要维持起来是比较困难的。因为如果这样的话，人们在许多任务上都必须做出汇报，其实这样做可能使那些本来重要的、对进度影响比较大的情况的汇报的机会就相对地减少了。另外不管有没有助手，在这种情况下，一个项目经理每天都要听很多汇报，由于精力有限，他可能就不能正确处理那些实际上十分重要的事情，如果这种情况一旦发生，就会影响项目的进展，或者增加项目的成本。这听起来好象在现实中不太可能发生，其实在现实的项目管理中经常会有这种现象出现，甚至在大项目和重要的项目上也有时出现。我的观点是，既然没有一个人的精力是有限的，那我们在考虑项目计划分解时，为什么还花这么多时间去把项目分解成那么细小的任务呢？

 

一般来说，我们喜欢在做项目细分时，大多数的任务在1—8周，是比较好的。

 

 

南华学童

（由项目发起人）建立信任高效系统互动的项目组织结构，才能有效化解由某一个把WBS做得太细的困境。让与项目有关的团队成员知道项目是需要大家中每一个我来负责和互动时，整个项目才可能是健康的。

清风徐来

学童补充得非常好！

《有效的工作分解结构》中说：

“项目的全过程中都把WBS作为规划、控制和沟通的关键工具使用。“

注意 规划、控制、沟通 三词

清风徐来

问题：建立WBS的步骤？

建立一个WBS分为4个步骤：

①  确定项目目标，着重于项目产生的产品、服务以及提供给客户的结果。聚焦于目标

②  准确确认项目所产生的产品、服务或提供给客户的结果（可交付成果或最终产品）。明确交付物

③  识别项目中的其他工作领域以确保覆盖100%的工作，识别若干可交付成果的领域、描述中间输出或可交付成果。确定任务覆盖范围

④  进一步细分步骤②和③的每一项，使其形成顺序的逻辑子分组，直到工作要素的复杂性和成本花费成为可计划和可控制的管理单元（工作包）。将任务分解为子任务和对应的交付物

清风徐来

PMBOK^®遵循了在项目分解方面早期的政府经验，该项目分解表述为：“把主要的项目可交付成果或子可交付成果细分成更小的、更易管理的部分，直到可交付成果可以被足以详细地定义，以支持项目活动的开展（计划、执行、控制、终止）。”

清风徐来

 表2-3  适当的细节水平

工作包应该被进一步分解吗
下述问题的肯定回答越多，进一步分解工作包的理由就越充分
是/否	问题
	有必要提高估计成本和工期的精确性吗
	是不是不只一人对工作内容负责
	有必要准确的知道工作包中活动的时间安排吗
	在工作包的活动中需要成本支出吗
	中间活动和其他工作包之间有任何关联吗
	在执行工作过程中的工作元素有任何重要时间的中断吗
	过一定时间工作包中的资源需求变化吗
	工作元素中的中间支付的前提有区别吗
	在完成整个工作包之前有合适的可接受的准则吗
	工作包中要执行的一部分工作能够被作为一个单元安排吗
	有需要集中精力于一部分工作包的风险吗？这些工作包需要进一步的分解以使风险分散
	工作包能够被清楚和完全地理解以满足不同的利益相关者吗

资料来源：T Raz,  S

南华学童

我想能结合案例效果会比较好，但总感到比较累，是不是应该把对项目关注实施的疲劳因素也做为项目管理基本内容之一，这样才显得人性化。呵呵！