撬动PMBOK6运用指南第九章

最新推荐文章于 2024-07-10 23:35:45 发布

gogoat

最新推荐文章于 2024-07-10 23:35:45 发布

阅读量212

点赞数

编者按：本文是撬动PMBOK6运用指南系列第九章，作者栾志强是达人圈资深网友，感谢作者对达人圈的大力支持！关注IT达人圈公众号并输入“PMBOK6”，即可下载到PMBOK6管理指南！

640?wx_fmt=png

一

案例名称

XX运营商大客户监控管理项目

二

案例场景

PMBOK第6版，第9章项目资源管理

三

案例时间

2010年-2012年

四

案例主要干系人

U运营商

U.LX：建设部门负责人

U.QY：建设部门主任

系统集成公司JC

JC.F：系统集成公司项目经理

邮电设计院T

T.J：主管设计工程师

监理公司JL

JL.T：监理

硬件集成商A

A.D：硬件集成商项目经理

软件外包公司B

B.L：软件公司项目经理

B.W：软件公司产品经理

五

案例亮点

该项目规模庞大，项目干系人复杂，在项目执行过程中存在大量变更，请求变更流程复杂，项目成果中对质量的要求较高。

六

背景描述

U运营商是国内三大运营商之一，在传输网领域有先天优势，完善的一级干线网、二级干线网以及本地网。为发挥其网络全覆盖的优势，由U运营商创新规划部门发起，建设一套VPN网络，提供给各级企业使用，如：中石油、中石化以及更多的政府部门。进而解决在享受专有网络的同时，降低资源投入量。而面向市场的营销，则由集团大客户部负责完成。

该项目就是在上述背景下产生，由集团客户部完成与国内C石油公司完成商务洽谈，实现一套支撑各加油站刷卡业务的基础网络，在终端用户进行刷卡后，能够将交易数据与总部清算系统进行互通，进而完成交易处理。而本项目中是在大客户网络构建完毕后完成硬件应用扩容（将原来低容量的VPN网关设备更换为高容量的VPN网关设备，进而增加接入容量），同时建设一套软件监控平台，用于监控VPN网络环境下各硬件设备性能及可用性，为运维提供强有力的支撑工具。能够在产生故障时做到及时准确告警，高效快速排障。从而更好的满足面向客户的SLA。

该项目涉及众多的组织及项目干系人，主要包括：C石油公司业务部门、U公司集团客户部、U公司网络建设部、U公司运维部、U公司系统集成公司、T邮电设计院、监理公司以及合同总包A系统集成公司，同时将监控软件部分外包至B软件产品公司。A系统集成公司以硬件集成为主，没有软件产品经验，同时项目管理成熟度非常低。该项目的项目金额较大，涉及部署节点5000+。

七

案例描述

U公司指定其系统集成公司员工F作为项目经理，F是一名只有三年工作经验的系统运维工程师，以往的工作经验更多的是开发及运维经验，并没有太多系统集成及软件产品实施经验。硬件集成公司任命D作为乙方大项目经理，D有10年以上的数通产品技术工作经验，属于技术型的工程师，对数通产品非常熟悉。监控产品厂商任命L作为软件产品项目经理（分包项目的项目经理），L有四年工作经验，公司在其工作第二年年底的时候做过系统性的项目管理培训，已经初步形成基于PMBOK的知识框架，同时按项目管理框架做过两个小型的项目。W是软件产品厂商的产品经理，软件实现能力以及需求理解能力都非常强，能够与L形成很好的配合。

在商务合同签订后，受限于商务流程签订周期较长的原因，导致合同约定的交付周期非常短，要求在三个月内完成上线工作，同时能够提供给U运营商各省分公司进行使用，满足运维考核的管理要求。项目正式启动前的一周时间，L接到产品分包合同告知完成基础的监控产品实施即可。在项目启动过程中由L针对软件产品交付实施部分进行了项目计划的制定，制定的项目计划完全依据于产品实施的标准化方式进行。针对于大项目并未出具详细的项目管理计划，而是简单的列举了项目里程碑节点，所有的时间节点均为了三个月的工期而设定。

640?wx_fmt=png

项目启动后，在U集团公司召开了简单的项目启动会，参会方包括：网建部、运维部、U公司集成公司、T邮电设计院、监理公司、A硬件集成公司、B软件产品公司等相关成员。启动会上由A公司项目经理介绍了项目建设目标、建设范围、建设周期、分工界面、项目风险。同时承诺在三个月内完成合同范围内的软硬件交付，达到系统上线的目的。

随着项目的推进，首先要完成的是硬件核心设备VPN网关的割接替换，按照项目计划要在两周内完成，但在硬件设备采购的过程中硬件设备并未按照项目管理计划完成到货，导致到货延期两周才完成到货。而硬件到货后需要上架、加点，同时在完成初始化配置后要向U公司发起割接申请，完成设备上线工作。在此过程中受限于割接申请管理流程各审批环节周期较长同时割接方案需要网建部、运维部、集成公司等多个部门进行技术评审，导致方案审核比原计划推迟三周时间，方案评审一直无法达到各方要求，在多次反复修改后最终终于通过评审。

在硬件上线的过程中，申请的割接窗口为3个小时，但在实际的割接作业过程中，高配置硬件网关存在系统级的Bug，导致VPN隧道一直建立不起来，业务无法正常运行，而在3个小时的割接窗口时间里并没有完成割接任务，进而导致了大量的终端用户无法进行刷卡业务，直接影响了U公司的大客户业务。此后，又经过两个多小时的方案回退，最终新设备下线，仍然采用老设备进行业务支持，本次割接作业失败。对于业务的影响导致了U公司客户满意度急剧下降。而此前对割接方案的技术可行性并未做充分测试，同时也因为硬件设备自身Bug导致了无法预期的问题。也因为此事件，导致A集成公司的项目管理水平受到很大的质疑，包括：周报发送、测试方案的完整性、人员到场支持情况、项目计划的偏差等。

640?wx_fmt=png

随后，在几经周折完成硬件割接上线后，进入到软件平台实施部署阶段，而在软件平台部署的过程时，U公司集成公司又提出需要高可用性的架构方案，高可用性方案必须满足HA要求，包括：数据库层及应用层，需要满足在单点故障时能够及时进行备机接管。而该部分工作并未在合同范围内进行约定。而集成公司的理由是：为了系统安全以及高可用性。为了满足该项要求，重新对软件部署架构进行调整，申请多台硬件资源实现数据库的高可用性要求，并重新采购应用节点高可用性软件来满足应用端的切换要求，项目组成员并没有相关资源储备。此过程中因涉及软件功能较多，所以完全由软件产品公司项目经理L作为面向客户的项目经理，原大项目经理D已经不能满足项目管控的作用。与此同时，项目已经延期两个月的时间，延期已经非常严重。

软件平台交付的过程中随即产生大量的定制化需求，其需求内容并未在合同范围内有非常明确的要求，项目处于需求蔓延状态。其中大部分的需求来源于运维人员对产品界面以及页面交互性的调整方面的需求，这样导致了前端页面调整非常频繁，也很难达到客户要求。另外，在管理对象非常庞大的情况下，产品性能出现一定问题，也导致客户对数据准确性产生质疑，为了解决客户信心的问题对告警数据进行核对，并对数据进行分析。在进行性能优化及调整的过程中，产品组开发人员大部分为实习生，开发质量上一段时间内无法达到项目要求，出现大量的返工情况。

软件系统配置的过程中，结合客户业务的特征，大量的加油站站点在某些固定的时间段内网关设备直接做关机处理，所以此时系统在捕获到设备中断后需要做特殊处理，并不是真正的故障，因此软件产品需要开发特定功能来满足业务要求，对部分资源进行例外处理。

软件平台在上线的过程中，按照U公司集成公司的要求，需要进行安全扫描，并将所有的安全漏洞完成修正后才能进行投产，此时安全漏洞扫描的问题整改花费了大量的时间，同时也填补了产品在安全方面的不足，同时体现出原软件平台在安全方面的不足。

U公司在建设VPN管理系统是面向各分公司运维部门使用，并实现对各分公司运维的考核，因此在权限管理方面需要实现分权分域管理。项目推广过程中需要对北方十省的运维团队进行集中培训，为了更好的进行系统推广，在完成集中培训后，需要厂商配备专门的技术支持工程师进行各省巡回培训，此过程中产生了大量的差旅费，直接导致项目成本的增加。

最终，经过严格的测试、系统数据准确性验证、上线前的评审以及推广培训等关键环节，最终该项目于原计划晚14个月终于完成上线工作，完成了投产使用，系统正式进入试运行阶段。

八

问题分析

该项目在范围、成本、进度上都有非常大的偏差，其中进度、成本偏差最大。Standish Group的一项报告指出，71%的项目失败或受到挑战，各类型的项目成功比例如下：

640?wx_fmt=jpeg

31%的项目，在未完成或未达到预期以前被终止。而对于未成功的项目中，平均成本超出原始估算的比例达189%，平均进度延迟222%，平均62%的需求满足原始需求。

640?wx_fmt=jpeg

经过对大量失败项目的研究及分析发现，如下原因是导致项目失败的重点原因，包括：缺乏有效的领导、缺乏责任感、没有计划（或计划不更新）、缺乏用户测试或无反馈、沟通不足、一直在解决错误的问题，割裂的推进项目）

640?wx_fmt=png

PMBOK 6th中对项目经理的人才模型有了明确的定义：领导力、技术项目管理、战略和商务管理。其中领导力已经成为项目经理的一个核心能力，在To B型的企业级软件中信息技术是一项基础能力。

640?wx_fmt=png

本项目案例中存在大量问题，直接导致项目失控，并没有形成对项目的良好控制，非常贴合Standish Group的研究报告中的相关问题点。现对项目问题分析如下：

1、项目启动阶段规划问题。项目启动阶段未对项目进行系统性评估，缺乏项目章程、充分的项目计划的支持，项目启动环节只是简单的召开了项目启动会，没能清晰的评估项目范围、项目风险、人力资源配置等

2、忽略了事业环境因素影响。项目执行过程中，对U公司的事业环境因素不了解，导致在硬件变更过程中受限于行业客户的特点，导致硬件上线延期。另外，在进行项目规划阶段未能识别出客户对安全管理的要求，导致安全管理环节产生大量的工作量。

3、没有制定沟通管理计划。在项目执行的过程中未统筹制定沟通计划，各类信息的发布采用了随机性的沟通，同时在关键的里程碑节点以及项目异常时未能及时启动工程协调会等沟通方式来进行问题分析及反馈，在此环节非常影响项目管理的专业性。

4、资源估算不够充分。在进行项目资源估算的过程中，对于设备及人力资源估算过于乐观。相关资源的使用完全凭个人经验进行评估，并未结合项目团队的整体资源现状以及能力结构进行项目资源估算，导致项目里程碑一直在变更。同时，在采购管理方面也未能进行规划及控制。另外，在资源类型方面也未能进行整体规划，导致项目执行过程中专业性的人才缺乏，比如：熟悉高可用性架构实施工程师、安全管理工程师等，进而导致该项工作的质量及效率无法保证。

5、缺乏项目团队的组建及建设。项目启动后项目团队的工作模式较为分散，未形成团队章程及统一目标，各成员角色及工作职责不够清晰，未形成有效的RACI结构矩阵，从而也导致任务执行时效率低下，沟通不够顺畅。在发现团队成员能力不够时需要对团队成员进行能力培养。

6、缺乏良好的绩效报告及检查机制。在人员职责不够清晰的情况下，团队整体绩效偏低，项目执行更多的是靠“惯性”推动，并未形成良好的绩效。这与项目经理的管理方式有很多关联，各团队成员的管理属于任务驱动型，未能结合WBS进行持续跟进，同时个人的绩效报告不能及时反馈给组织，用于对项目进度的偏差分析。也无法为项目经理进行团队建设提供依据，基本处于无序的状态。

7、缺乏有效的变更管理控制。在项目延期的过程中，发现是因为项目范围蔓延，尤其是在软件交付的过程中，需求蔓延是非常普遍的现象。在项目推进的过程中，发现项目范围发生变化时，需要将变化内容提交至CCB进行评审，审核通过后方可变更。同时需要对变更风险及影响作出相关描述，便于决策层进行决策。而在该项目的执过程中，变化时未进行控制，也缺乏相关的变更管理流程加以控制，导致需求未能及时收敛。

九

规避建议

通过上述案例可以了解到该项目在执行的过程中，缺乏项目管理思维以及专业的项目管理经验，导致项目失控，在项目范围、项目进度、项目成本、项目质量方面均有较大偏差，基于上述原因很难达到良好的客户满意度。在整体的项目管理过程中，项目经理在开展项目管理工作时，并没有相应的管理制度、管理工具作为输出，能够更好的开展项目工作，基本处于被动推进的状态。相关规避建议如下：

1.加强启动环节的项目策划及启动控制。在项目启动环节需要对项目范围进行深度理解，同时制定项目章程，并在项目启动会上完成项目章程的发布，项目相关各方要对项目章程形成高度共识。包括：项目里程碑、团队成员、项目风险、项目交付物等。项目章程需项目相关方签字生效。如下工具供参考：

640?wx_fmt=png

2.对项目所需资源进行评估。在项目启动前结合合同内容以及调研到的需求，进行资源规划，最终形成资源管理计划。包括：资源类型、资源能力要求、资源准入时间、资源退出时间等。相关资源管理需要项目团队共同参与讨论得出，或邀请该领域的专家进行评审。也可以利用组织经验库，找到同等业务类型或同等规模的项目进行参考，再依据专家经验给出相关系数。形成资源管理计划后，用于指导后续项目执行。

4.依据资源管理计划，向组织申请对应资源。在资源管理计划中已经明确出所需资源类型以及准入条件，因此需要向PMO或职能部门获取符合条件的资源，同时做好资源评估，如果资源能力达不到相关要求，则需要在团队建设的过程中进行人员能力建设，使其满足项目需要。如原案例中缺乏对高可用架构的实施工程师以及安全管理工程师，如果在前期做好资源规划，则向相应的组织进行资源申请，若内部资源无法满足时，则可以考虑外包的形式来完成项目任务。

5.加强对项目团队的建设及管理。项目管理中人力资源管理部分是非常重要的一个环节，尤其是软件类型的项目中，人力资源更是重中之重。在充分了解项目范围及交付物之后，依据资源规划获取项目成员，接下来就要完成团队组建及团队建设以及绩效管理。作为项目经理需要有良好的领导力，能够带领项目组成员完成项目目标，同时还要掌握项目组成员的绩效状态。项目团队成员要有统一的目标及意识，成员之间要有足够的信任，形成一致性的沟通语言，进而提升团队绩效。项目团队都会经历形成期、震荡期、规范期、成熟期及解散期。项目经理的重要职责就是将项目团队快速度过形成期及震荡期，使团队进入规范期及成熟期，并妥善处理解散期，让每位团队成员都有良好的归属感以及成就感。团队管理的过程中也需要注意团队绩效，在充分了解成员绩效的同时，需要进一步了解项目整体绩效，若存在绩效偏差需要及时进行绩效调整。通过成员绩效表现，来评估团队成员能力是否有所缺失，在缺失的条件下需要对其进行弥补，及时进行培训、分享或复盘。

6.增加变更控制流程。项目范围、项目计划等关键项目要素形成基线后，若受到其他因素影响需要变更时，项目经理需要通过变更管理控制流程，将变更内容描述清晰，同时将变更风险、影响资源等因素加以说明，提报至CCB进行评审，在条件允许的情况下才能够进行变更，否则不予以变更。如：在该案例中项目范围在逐渐蔓延，但项目经理并没有及时做范围、进度、质量、成本方面的平衡，也未提报CCB进行报批，而是全盘接纳了用户需求，导致范围处于失控状态。在软件项目实施的过程中，工作说明书是项目范围控制的重要依据，项目经理及项目成员需要对工作说明书中的内容了如指掌，有偏差时需要高度敏感。

7.熟悉事业环境因素，并在团队内进行宣讲。不同的行业客户，有不同的项目特征以及一系列的管理要求。如果团队成员不了解相关事业环境因素，将会增加未知风险，因为风险内容并不在项目经理或团队成员的认知范围之内，而跟多的时候是问题发生了，才会采取补救措施，而此时已经造成了一定的损失。为了更好的解决该问题，需要项目经理及团队成员熟悉事业环境因素，并做好团队内部的宣传工作。保证项目团队成员的高度共识。

640?wx_fmt=gif