wbs分解模板,宴会wbs实例
随着商业社会wbs分解模板的发展,现代企业wbs分解模板的愿景和商业目标越来越宏大。无论是整体的战略规划,还是传统KPI *** 、最近几年大受欢迎的 OKR……都离不开“分解”的艺术。本篇文章,笔者将简要介绍项目管理中的工作分解结构(WBS),以及3个实践中的问题与解决思路,一起来看看吧。
一、什么是工作分解结构?根据 PMI 的定义,创建工作分解结构(WBS)是把项目可交付成果和项目工作分解成较小、更易于管理的组件过程。对于工作分解结构(WBS)的概念,我们认为应该在以下两方面重点理解:
WBS 以可交付成果(Deliverables)为对象,而不是以计划活动(Schedule Activity)为对象;WBS 的结构,包含了一套科学的逻辑结构和分类 *** ,而非单个的、离散的、在时间顺序上不连续的成果的描述结构,通过层层的包含关系,非常严谨。二、WBS 分解 *** 与常见问题关于 WBS 的分解 *** ,许多项目管理的书籍都有介绍,常见的方式包括按照产品的物理结构、产品或项目的功能用途、项目的实施阶段和过程、项目组织的地域分布、各个子目标、部门或者职能角色等等。
但由于每个项目的独特性,这些经验性的理论 *** 在实际应用中仍然会遇到很多问题,结合团队的服务实践,我们梳理归纳了3个痛点问题和对应的解决思路。
1. WBS 分解的颗粒度由于项目管理的自身特点,在项目规划阶段,我们很难穷尽项目涉及的全部事项,对一些远期才能完成的成果,项目初期可能无法分解。即使是在一个理想环境下,工作分解过细,也会带来管理成本的无效耗费,资源使用效率低下,同时 WBS 各层级数据汇总困难。
分细不容易,分粗一点呢?比如每个 WBS 设计三层,前两层概要、后一层是最终的成果,又很可能导致范围蔓延、权责分工不清晰,也是不合理的。
解决思路:
WBS 的实质思想之一,是要体现在项目过程中项目职责的落实和明确划分。
「责任到人」是项目管理的核心,实际工作中最糟糕的情况是事情出了,没人认账,没人负责,要避免这个问题的出现,就需要在每一层次 WBS 分解过程中都考虑到项目责任划分和归属,尽可能每一个最底层的节点都有唯一责任人(或部门)相对应。
因此,分解的粒度是”可以分配,可以交付”。
2. 不同分解 *** 之间的矛盾在实际的管理实践中,一个项目往往有多种分解 *** ,可以按照工作的流程、可交付成果分解,也可以在不同层级使用不同的 *** ,在一些大型复杂项目中,常常还涉及诸多的对外采购活动,合同中清单分解项目依赖具体的场景需求,有时候还会受到独立的行业标准和惯例约束。
不同的分解方式侧重点不同、相互之间难以统一,造成了 WBS *** 在理论上容易理解但在具体场景下操作实施的难度。
解决思路:
解决这一矛盾,首先要理解 WBS *** 的另一作用,是实现项目进度/成本控制的基础,如果没有这个功能,WBS 在具体活动中没有任何特殊意义,只是一个工作备忘录。
结合这一作用,我们可以考虑在应用 WBS *** 的时候,将其分为两个部分:
上层部分为大项工作分解结构,可以参考项目的高层级目标,将整个项目按级别划分若干大项和单项。大项分解可以参考项目的生命周期、各个阶段、各个里程碑控制点等原则划分;
底层部分划分也不一定严格遵循80小时等传统原则,尽可能有一个相对完整等交付成果即可,如果涉及对外合同,尽量让底层部分的分解层次位于合同清单项之上,避免混乱、也利于工作量和成本衡量。
3. WBS 在项目各阶段的地位作用WBS 不是一个大而全、覆盖整个项目的分解结构,很多项目关键信息都不能在 WBS 中完整表现。由于主要呈现项目「可交付成果」,我们实际执行往往陷于细节,没有把它放到项目中系统看待其关联,远不如项目活动、进度类文件用得多,常常被束之高阁,沦为工作的备忘录。
解决思路:
WBS 并不是孤立存在的,它可与其他编码体系配合,体现不同的配置关系,比如 WBS 和 OBS(组织分解结构)结合,就可以进行职责配置,把项目工作分解结构 WBS 看作纵轴,组织分解结构 OBS 为横轴,通过两者的整合确定部门或个人的工作任务和责任。
另外,WBS 在不同阶段也有不同的侧重作用:
项目规划阶段——明确项目范围,是项目进度/成本估算的基础项目执行阶段——检查项目质量,可以项目进度/成本联合控制项目结束时——项目绩效衡量以上就是我们本期分享。关于 WBS 更多详细信息,可以参考PMI《工作分解结构实践标准》,这一标准列举了一些具体行业的 WBS 模板,可以在裁剪后应用于特定领域的具体项目。
本文由 @ONES 原创发布于人人都是产品经理,未经作者许可,禁止转载。
题图来自Unsplash,基于CC0协议。