我们常说,要知道自己的能力圈,通过有效的方法不断扩展自己的能力圈,做能力圈内的事情更容易成功。项目范围也是如此,要看清项目能力圈的边界,有所为,有所不为。
在这个有所为,有所不为的原则下,定义项目范围尤为重要。范围定义是详细说明到底要做什么的过程。主要作用是明确所收集的需求哪些包含在项目范围内,哪些排除在项目范围外。从而明确产品、服务或成果的边界。成功的项目前期都应制定一个明确的项目范围。
【案例】
8A公司的数字化转型咨询项目的需求文档已经输出,各部门摩拳擦掌,期待项目全速推进。
各个部门的需求多样,若全部都涵盖到项目中实施,项目在4个月内达成项目目标的难度很大,投入的资源、成本非常大。筛选需求,定义项目范围,确保在有限的时间里,项目能够快速推进,成为罗宾在当前阶段的第一要务。
项目需求文档中,每个部门提出的数字化转型咨询需求都在20个以上,涉及业务流程改进、系统数据共享、外部数据引入、业务大屏方案等。哪些需求优先级比较高,哪些需求可以后续建设等,这些范围决策都需要各个部门的反馈。
因此,罗宾和项目组召集采购、市场、制造、财务、人力等部门项目的主要相关方开会讨论。会上,罗宾首先说道:“感谢各位对项目的支持,这次会议的目标是与各位讨论确定项目的核心建设范围。在收集需求阶段,各部门给出了非常有价值指导意见。当前推进数字化咨询项目实施中,也需要各部门的宝贵输入。每个部门都有近20个需求,我们会有所侧重,希望最终方案是能够解决各个部门最紧迫的诉求。各位从专业角度评估,项目必须满足的需求是什么,如果没有达成这些需求,我们的项目要么不可行要么完成不了项目目标,那么这些必须的需求,我们会确保涵盖在项目范围内。”
罗宾接着说道:“有些需求也很重要,我们会记录下来,会在后续会议中进一步沟通细节。有些大家觉得应该有的需求,我们会咨询业务专家的意见,评估是否应该包含在项目中,并给出相应建议。有些非必需但可以包含的需求,会进一步讨论实施可行性,在资源允许的情况下,再推进实施。项目需要实施的范围,将由管理层做最终决策。”
罗宾另外补充道:“考虑我们这一阶段是咨询项目,重点在方案设计,指导后续公司数字化战略,涉及数字化系统的采购和实施建设,希望跟大家明确,将会在后期的项目中推进,不会包含在这次咨询项目中。”
会议目标很明确,各个部门负责人也很清楚部门最核心的需求,非常高效的初步决定了项目必须要有的需求清单。为了确保最终项目范围得到业务部门的认可,后续会议也邀请了各部门最终的用户代表(包括制造工厂的车间主任、财务、人事、销售人员等)对咨询项目的实施范围给出建议,确保项目范围是解决最终用户的最核心需求,确保输出的项目范围说明书得到各部门的认可。
经过多轮会议沟通讨论,项目建设范围已在项目范围说明书文档明确。需求跟踪矩阵也随之更新,矩阵中列明哪些需求包含在项目中,哪些是建议在后续项目中实施,哪些不建议在项目中。
在准备好相关评审材料后,罗宾组织召开公司管理层会议,对项目最终实施的项目范围进行决策。项目组给管理层提供了详尽的评审文档,项目范围说明书中有详细的需求分析,各个部门重点需要解决的核心需求也做了非常详细的描述,同时需求跟踪矩阵中也给出了需求业务优先级、实施成熟度和可行性建议。参会各个业务部门负责人已经在前期多轮沟通确认了核心需求建设范围,整个决策过程比较高效,管理层决策同意了项目按照范围说明书的项目实施范围,决定后续按照范围说明书推进实施。
【案例分析】
需求众多,容易出现各相关方间的观点冲突,定义范围阶段,需要明确项目最终需要实施的内容,其核心是与项目相关方达成共识。达成共识过程中,决策非常关键。决策可能来自专家判断,也可能是集体决策。如果在决策的过程中,遇到多个相关方的冲突。人际关系技能就显得非常重要。针对冲突点,可以设计沟通主题会,通过引导的方式,求同存异,快速达成共识。
项目是由在时间、成本、范围约束下进行的一项临时性工作。项目管理由人参与,在确认范围时,我们不能逃脱人性的本质,想的容易,范围就容易扩散。做加法容易,做减法难。项目需要达成的需求目标太多,时间紧,配置和资源跟不上,项目会很难以达成目标。
范围蔓延是一些失败的项目死结。项目初期定义范围阶段,简单人为、不假思索地加入很多项目需求,想得很美好,但会因为没有按照原则做取舍,会最终导致“收一样,做一样,差一样”,导致项目发起人、项目组成员、相关方都痛苦不堪。
我们要记住,有所为,有所不为,找到项目范围的能力圈。引导相关方认识的组织和项目的能力边界,项目范围需要重点关注解决最核心的问题。
范围定义和决策中,介绍一个有效的工具:MOSCOW分析法。MOSCOW其名称是4个级别的首字母缩写,Must have(必须有)、Should have(应该有)、Could have(可以有)、Won't have(不会有)。
拿到项目需求清单,按照MOSCOW原则,可以快速聚焦,确定有效的项目范围。
表2-8 MOSCOW 原则
Must have 必须有 | 必须有。如果不包含,则项目不可行。Must Have的需求或功能,通常就是项目必须要达成的目标,有时在产品交付中,是最小可行产品Minimum Viable Product(MVP)的功能。比如房子就应该四面有墙,有门窗,有屋顶 |
Should have 应该有 | 应该有。这些需求很重要,但不是必需的。虽然“应该有”的要求与“必须有”一样重要,但它们通常可以用另一种方式来代替,去满足项目相关方的要求 |
Could have 可以有 | 可以有。这些要求是项目相关方期望的,但不是必需的。可以提高用户体验,或提高相关方的满意度。如果时间充足,资源允许,通常会包括这些需求。但如果项目交付时间紧张,通常现阶段不会做,会挪到下一阶段或者下一期做 |
Won't have 不会有 | 这次不会有。最不重要,最低回报的事项,或在当下是不适合的需求。不会被计划到当前项目的交付计划中。“不会有”会被要求删除,或重新考虑 |
当然,也有其他方法,例如收集需求中用到的工具专家判断、数据分析、决策、人际关系与团队技能,都可以在范围确认中使用。
定义范围的阶段性成果是项目的范围说明书,后续项目实施都会基于项目范围说明书作为基础来推进。项目的范围说明书,一般包含如下内容:
表2-9 范围说明书内容
内容 | 说明 |
项目概述 | 包括项目目标、实施内容、项目实施规模等 |
工作范围描述 | 工作范围中详细说明项目承诺交付的产品、服务或结果的特征。在项目建设中,很多项目需求是渐进明晰的,因此更需要关注项目产品范围,产品描述要提供足够的细节,支持后续的项目规划 |
整体建设方案 | 包括系统整体设计原则、整体架构(业务架构、数据架构、技术架构等) |
项目的可交付物 | 明确项目交付后,需要提供产品或服务的各种结果。交付成果可以包括两部分内容,即主要交付成果和辅助交付成果 |
验收标准和流程 | 明确定义项目交付后的验收标准及验收流程。文档、硬件、软件、土建都有不同都验收标准 |
项目组织架构 | 明确项目各相关方职责,项目后续实施的组织架构 |
制约因素和假设条件 | 一般包括政策约束、时间约束、成本约束和其他约束等。假设是项目相关方都确认过,不需验证即可视为正确、真实或确定的因素 |