创建WBS项目管理过程

禅思院
452 阅读6分钟

WBS是什么

  • WBS：Work Breakdown Structure，即工作分解结构，“工作”是指作为活动结果的工作产品或可交付成果，而不是活动本身；

  • 是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解；

  • 组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作；

  • 意义：

    1. 清晰地表示项目各工作之间的相互联系
    2. 展示项目全貌，详细说明为完成项目所必须完成的各项工作，防止遗漏
    3. 建立可视化的项目可交付成果
    4. 改进工作量、时间、成本、资源估算的准确度
    5. 工作分配、职责澄清、工作责任更清晰，帮助团队的建立和获得项目人员的承诺
    6. 定义里程碑事件，为跟进项目完成情况和状态的项目控制提供依据
    7. 为绩效测量提供依据
    8. 帮助分析项目的最初风险
区别可交付成果活动
释义在某一过程、阶段或项目完成时，必须产出的任何独特并可核实的产品、成果或服务能力实现预定目标的行为
形态有形、无形抽象
导向结果过程
性质复杂单一
flowchart TD
    A[项目] --> B(可交付成果A) --> C(工作包A) --> D(活动1)
    A[项目] --> B1(可交付成果B)
    A[项目] --> B2(可交付成果C)
    A[项目] --> B5(可交付成果...)

    B(可交付成果A) --> C1(工作包B)
    B(可交付成果A) --> C2(工作包C)
    B(可交付成果A) --> C5(工作包....)

    C(工作包A) --> D1(活动2)
    C(工作包A) --> D2(活动3)
    C(工作包A) --> D5(活动...)

TIPS: 某些项目可交付成果和活动中可能存在重复的元素

创建WBS

实例

大家根据可交付成果和活动的区别，分析下列例子中，哪些是可交付成果的描述，哪些是活动的描述

一级目录二级目录三级目录
产品部署部署调研现有部署版本调研
产品部署部署调研xxx采购情况
产品部署部署实施人员&计划
迁移方案迁移调研xxx现状调研
迁移方案迁移调研1.xxxxxx
迁移方案迁移调研2.xxxxxx
迁移方案迁移调研3.xxxxxx
迁移方案迁移调研4.xxxxxx
迁移方案迁移调研5.xxxxxx
迁移方案迁移调研6.xxxxxx
迁移方案迁移工具确认迁移形式
迁移方案迁移工具迁移脚本编辑
迁移方案迁移工具迁移程序开发

创建WBS

将项目可交付成果和项目工作分解为较小的、更易于管理的组件的过程，主要作用是为所要交付的内容提供架构，建议在<立项评审>通过后开展此工作，<计划决策评审>前完成WBS的创建，从而保证团队内部排期的准确性。

stateDiagram-v2
    [*] --> 相关需求文档
    相关需求文档 --> 分解
    分解 --> 工作包规划包
    工作包规划包 --> [*]
  • 相关需求文档：满足项目业务需要的各种需求的详细描述
  • 工作包：WBS 最低层的组成部分
  • 规划包：高于工作包的工作分解结构组件，工作内容已知，但详细的进度活动未知

分解

  • 定义：把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术；
  • 工作分解结构每向下分解一层，代表对项目工作更详细的定义；
  • 分解的程度取决于所需的控制程度；
  • 工作包的详细程度因项目规模和复杂程度而异；
  • 要把整个项目工作分解为工作包，通常需要开展以下活动：
    1. 识别和分析可交付成果及相关工作；
    2. 确定 WBS 的结构和编排方法；
    3. 自上而下逐层细化分解；
    4. 为 WBS 组成部分制定和分配标识编码；
    5. 核实可交付成果分解的程度是否恰当
flowchart TD
    A[项目 1.0] --> B(需求评估 1.1) --> C(当前审计 1.1.1) --> D(组件识别 1.1.1.1)
    A[项目 1.0] --> B1(标准制定 1.2)
    A[项目 1.0] --> B2(系统工程 1.3)
    A[项目 1.0] --> B3(项目管理 1.4)

  B(需求评估 1.1) --> C1(需求确定 1.1.2)
  B(需求评估 1.1) --> C2(备选方案制定 1.1.3)
  B(需求评估 1.1) --> C3(系统需求开发 1.1.4)
  
    C(当前审计 1.1.1) --> D1(组件分析 1.1.1.2)
    
    C1(需求确定 1.1.2)--> D2(差距评估 1.1.2.1)
    C1(需求确定 1.1.2)--> D3(变更需求识别 1.1.2.2)
    
    C2(备选方案制定 1.1.3) --> D4(备选方案识别 1.1.3.1)
    C2(备选方案制定 1.1.3) --> D5(备选方案分析 1.1.3.2)

TIPS: WBS 仅为了说明之用。它无意代表任何特定项目的整体项目范围， 也不意味着这是对此类项目组织工作分解结构的唯一方法。

分解的原则：

  • MECE原则：即对一项工作进行分解时，要做到不重复、不遗漏的分类，子工作之间要相互独立，所有的子工作要完全穷尽；

  • SMART原则：即一项工作的分解要具备具体（Specific）、可量化（Measurable）、可实现(Attainable)、相关性(Relevant）、有时限(Time-bound)五个条件；

  • 100% 原则：WBS 包含了全部的产品和项目工作，包括项目管理工作，通过把 WBS 底层的所有工作逐层向上汇总，来确保既没有遗漏的工作，也没有多余的工作；

分解的基本要求：

  • 某项任务应该在WBS中的一个地方且只应该在WBS中的一个地方出现；

-WBS中某项任务的内容是其下所有WBS项的总和；

  • 一个WBS项只能由一个人负责；

  • WBS必须与实际工作中的执行方式一致；

  • 团队成员积极参与创建,确保WBS的一致性;

  • 每个WBS项都必须文档化，以确保准确理解已包括和未包括的工作范围;

  • WBS必须在根据范围说明书正常地维护项目工作内容的同时，也能适应无法避免的变更；

WBS应该有交付物;

分解的方法：

  • 使用组织特定的指南
  • 使用 WBS模板
  • 类比法：以过去类似项目的参数值（如持续时间、预算、规模、重量和复杂性等）为基础，来估算未来项目的同类参数或指标，即参考类似项目的WBS创建新项目的WBS；
  • 自上而下的方法：从项目的目标开始，逐级分解项目工作，直到参与者满意地认为项目工作已经充分地得到定义；
  • 自下而上的方法：可用于归并较低层次组件，从一开始就尽可能地确定任务有关的各项具体活动，然后将各项具体活动进行整合，归纳到一个整体工作或WBS的上一级内容当中去；

结构示例

基于项目生命周期的各阶段

在这里插入图片描述

基于项目可交付成果

在这里插入图片描述

说明

  • 对 WBS 较高层组件进行分解，就是要把每个可交付成果或组件分解为最基本的组成部分，即可核实的产品、服务或成果；
  • 通过确认 WBS 较低层组件是完成上层相应可交付成果的必要且充分的工作，来核实分解的正确性；
  • 不同的可交付成果可以分解到不同的层次；
  • 滚动式规划（规划包）；
  • WBS 词典：针对 WBS 中的每个组件，详细描述可交付成果、活动和进度信息的文件，对 WBS 提供支持；
avatar
文章
阅读
粉丝