变更管理技能

一切有意义并且长久的改变都始于你的想象力,然后才变成现实。想象力要比知识更重要。

——阿尔伯特·爱因斯坦

在本章,我们将分享关于变更管理的思想,描述变更管理流程的三个部分,并且讨论随机应变的必要性。我们通过实施项目办公室进行组织变革这个案例,阐述变更管理的步骤;通过银行案例,阐述实现变革的方法。我们对比了变更控制和变更管理,同时,我们还和其他项目经理分享了他们在变更管理方面的经历。

管理变更

1492年8月3日,哥伦布从西班牙南部的帕洛斯(Palos)启航去寻找一条向西通往亚洲的航线。他相信世界是圆的,尽管当时欧洲几乎所有人都认为世界是平的。很多人甚至认为船一直朝西航行最终会从地球的边缘掉下去。

虽然哥伦布没有找到他想找的航线,但的确证实了他的怀疑——地球是球形的。经过了几个月的探索外加损失了一条船后,1493年3月15日,他成功回到帕洛斯,成了英雄。几个月的时间内,欧洲对于地球形状的观点开始发生巨大的变化——但并不是所有人都愿意改变他们对于地球的看法。

每个人其实都是抗拒改变的。很多年来,我们都以为项目领导者喜欢改变,而其他所有人都不。作为有眼光的项目领导者,我们总觉得把不情愿的追随者带到了未来。但经过对这个想法的大量研究和反思,我们最终才意识到,项目领导者并不比其他人更愿意改变,当然除非这是他们自己的想法。

变更的原因和典型结果

以下这些环境因素总是不断地影响着大多数行业,并刺激着大部分组织要考虑作出新的应对。

● 外部因素。

——产品过时。

——客户需求。

——有竞争力的供给。

——时间紧迫。

● 内部因素。

——组织内部缺乏稳定的方法论。

——技术匮乏。

——培训不是产生结果。

——支持不足。

——项目不满足范围、进度和预算的要求。

以下是典型的、杂乱的应对措施,但通常并无成效。

● 行动。

——研发新技术。

——制定政策和程序。

——开拓新客户。

——解决新问题。

——注重解决方案,不仅是在产品方面。

● 回应。

——启动项目……更多的项目……更多更多的项目。

——耽搁……失败……更多的项目……匆忙成立项目办公室。

● 结果。

——整个项目80%的工作在初步尝试后就被搁置。

——组织没能执行其战略,成为无用的基于项目的组织。

——有些事情有待改变。

牢记几百年前尼可罗·马基雅维利(Niccolo Machiavelli)的告诫:“没有什么比引领新事物更难掌控、更冒险、更不确定是否能成功的了。”

对抗拒变更有心理准备

改变总是很难的。人们普遍认为即使是最幸福的生活也暗藏着某种程度的痛苦,而这种不幸只能自己承受。其根源在于喜爱增加了无知,想要的东西得不到,而不想要的却躲也躲不掉。

例如,我(布丝洛)是个恋家的人,总想尽量和家人待在一起。但是,在过去几年,我作为项目经理和顾问的职业生涯发生了变化。几年前,西班牙的经济不景气,为了在其他国家揽下更多的生意,为了养家糊口,我比平常飞得更频繁了。这种情况让我很痛苦。我觉得自己总是在工作,疏忽了家人。但是情况就是这样,因此我自己也不得不改变,我最终适应了我的新的职业生涯。每当我主管的项目有变更时,我总会想起父亲说过的话——“在你的职业生涯里,唯一不变的东西就是石头。”——这支撑我渡过项目变更阶段。当需要变更时,全能项目经理需要灵活应对。

变更的动机

变更总是一直存在,有时我们可以让它或帮它发生。变更的刺激因素有痛苦、逃避和实现快乐。当然,它们都是紧密相连的。逃避或减轻痛苦当然是令人愉快的。研发项目和新的商业产品开发项目也总是能给人带来愉悦。大多数绩效改进项目意味着能避免痛苦。以上两者都面临对变更的抗拒。

抗拒的程度似乎会随着变更对我们习惯的结构所造成的威胁的程度而增长,但是我们不想等到痛苦到了极致以致它都超过了我们对变更的抗拒能力。我们想积极地改变能够改变的来提高我们的绩效。

抗拒有利有弊。通常恐惧都是有个度的,如果掌控得当能为管理风险和作出有效决策提供坚实的基础。通过评估其不利的一面,我们可以找到避免或减轻其不利影响的方法。通过评估抗拒,我们才能作出获取理想的变更效果的决策。

记住,恐惧很正常。勇气指的是我们如何来应对自己的恐惧。喜爱也很正常,我们的主动性由我们如何管理自己的喜爱程度所决定。如果我们能意识到隐藏在深处的引起抗拒的情感,就可以有反应而不是有反抗。我们能意识到恐惧或欲望,并且在它变成想法、促使我们采取行动之前就能意识到。不是立刻屈服于我们的抗拒或欲望,而是先分析,再计划,最后再行动。

在组织里的很多阶层,都存在对实施项目管理方法论的反对声音。最严重的要属高管和高级经理的反对。他们会决定是揭示暗藏的问题,还是忽视它们,或使用毫无作用的“邦迪创可贴”修补。一旦决策者已经对组织作出调整,那么对其他人抗拒的处理就相对容易些,他们会认为这是包含在项目计划内并是得到认可的。

怎样来处理好抗拒?管理变更首先要意识到,一个项目会影响到人们的工作方式、人际关系、安全感、威信、权力,或其他任何无论能否触及到的他们认为重要的东西。有了这个意识,就能理解抗拒是再正常不过的了。

下一步就是计划。在项目计划里要包含一个避免或减轻抗拒影响的策略。这个策略就是,在恰当的时间以恰当的方式,告诉他人现在正发生什么,可能会如何影响到他们以及他们将扮演何种角色。该策略还包括举办一些支持性的活动,使其平稳过渡到新的过程,如培训、指导和手拉手活动等。处理好变更以及对其的抗拒活动要贯穿整个项目,不是仅仅在结束时才有。

如果反对出现在决策层,需要更加仔细地处理。若在项目初期(项目在它的拥护者眼里是曙光时)、项目启动和高层级计划时期,高管或高级经理的抗拒没有解决,那么很有可能导致失去项目或建立错误的项目。因此,在实事求是阐述失败的可能性的同时,项目的拥护者要有勇气并有技巧地讲述一个案例,来破除不合理的抗拒。

变更就绪

“变更就绪”这一术语指的是,人或组织在作出变更时准备扮演积极角色的程度。这个角色可以是变更推动者或接受者。尽管这种就绪能通过交流和教育来培养,但是总有些时候,人所能做的就是后退,耐心地等待,直至它出现。人们为变更准备就绪,可能是由于人们已经到了无法忍受的地步或是源于我们的无知,这种无知是形成我们控制或逃避反应的基础。

源于无知的情形通常发生在变更过程中,这个过程包括了普遍接受新观点的教育和改变。例如,在项目管理改进方面,很多组织采取行动的先决条件是,在项目管理原则内人们普遍认可并接受的一系列的最佳实践。该行动要求改变项目组合和跨项目资源的管理方式,以此作为解决项目绩效问题的一个手段。之前准备进行正式的项目和项目组合管理的尝试,可能已经遭到强烈反对并且总是以失败告终。

抗拒变更是生命的本质。人们总是更愿意待在一个虽让他不愉快但却熟悉的环境,而不愿以改变现状为代价来换取一个痛苦更小的环境。这种抗拒基于害怕未知,不愿放手诸如自认为已建立的安全感和权力,以及试图逃避不可避免的事。而抗拒的根源在于不知道变更是不可避免的,以及不知道自己,最起码在某种程度上,其实是可以积极主导变更的。然而,抗拒也有其好的一面,它可以激发有效的风险管理程序。我们可以肯定,在涉及组织变革的项目计划里都需要变更管理技能。

变更管理流程的三个阶段

阶段一

由于变更的形式多样,可以举个具体的例子。假如我们的目标是使得项目办公室成为组织变化尤其是朝更加项目化的组织转变的一个载体,创立项目办公室可能势在必行,但同时也充满了未知的危险。首先第一步就是要找到引导组织变革所必需的流程,并且创造能够促成转变的条件。这就类似于项目计划的准备。

有人会说计划就是浪费时间,有人可能会急于求成而回避计划这一过程,也有人会鼓动团队加快步伐、尽快采取行动。但项目经理应该更清楚,计划是必不可少的。对于那些坚持跳过第一步、想走捷径的人而言,下面的例子就是个警示。

1846年的春天,一群移民从伊利诺伊州出发,要行程2000英里到达加利福尼亚州。他们计划取道著名的俄勒冈小道(Oregon Trail)到达那儿。而这群人中的一部分人——当纳团体(the Donner Party)想快点到加利福尼亚州,因此决定走捷径。他们行进至小桑迪河(the Little Sandy River)时仍是一大批人。此时,另外那个大部队朝北走,取道更远的路北上俄勒冈,再到加利福尼亚州。而当纳团体选择朝南走,取道当时无人走过的哈斯廷斯捷径(Hasting’s Cutoff)。由于包括哈斯廷斯本人在内的人都从没走过这条道,因而不知道未来等着他们的是什么。他们遇到的第一个障碍就是大盐湖沙漠(the great Salt Lake Desert),在那儿他们遇到了从未遇到过的情况:白天被阳光炙烤着,晚上被刺骨的冷风吹着。到达雪乐山(the Sierra)时,他们面临着更强大的阻碍。由于“捷径”耽搁了他们的行程,那时已是冬季,是雪乐山有史以来最糟糕的时刻,加上猛烈的冬季风暴,他们不得不在当时一条不知名的通道的东边搭建临时的小屋或帐篷来宿营。大多不幸被困的人在山上度过了一个又冷又饿的寒冬。最后出现了人吃人的现象。这个团体的很多人都死掉了,而那些幸存下来的人到达加利福尼亚州的时间,比原来从伊利诺伊州出发的大部队晚了许久。

当纳团体犯的错误如下。

● 一点都不了解旅途会有多艰难。

● 没有经验和向导。

● 拿自己的生命做赌注。

● 走了一个不熟悉、从未有人走过或探索过的路。

● 计划不切实际。

● 发现自己走上了一条灾难之路。

这个故事给项目办公室团队的第一个警示就是,在你经历组织变革之前早已有前人走过这条路。他们的集体经验就像俄勒冈小道,告诉你如何实现预期目标。尽管这条路似乎很长,但考虑到自己可能承担的风险,就不要在乎这点。第二个警示是,尽管俄勒冈小道很有名,很多人走过,但并不代表它很容易走。这条路上同样有很多困难,毫无疑问也会有人死去。因此,走了这条路并不能确保成功,不过成功的概率会大大增加。第三个警示是,走捷径,通往未知的领地,如穿越大盐湖沙漠,在地图上看着没问题,但地图不能准确描述实际地况,走捷径可能会导致要求无法实现或出现不好的结果。

当被问到人怎样才能被他人理解时,项目经理丹尼斯·H.(Dennis H.)讲了上述这个前车之鉴。“完成一个项目之后,我希望干系人会期望仍和我一起合作。作为项目领导者,相比较于领导当纳团体的带队人,我更愿成为带领定居者们到达俄勒冈的带队人。”

因此,要多读关于创立项目办公室(其他无论什么你想看的)的书籍和文章,找个有经验的顾问,做个好规划,然后再一步一步慢慢执行。一定要弄清问题,知道谁握有权力,你想去哪儿,以及怎么到达那个地方。在创立项目办公室之前,要先评估环境,分析确定该方案通过与否的利弊。由于我们的目标是为了使整个公司的项目绩效最优化,因此要确定形成组织工作基础的核心价值观。要确定过程中所需的参与者和领导计划。对考虑走捷径的项目办公室策划者,弗吉尼亚·里德给出的最好建议就是:“记住,永远别走捷径,尽快前进。”

阶段二

阶段一要求为变革发生创造条件。在阶段二里,我们的重点将从计划转向实践。现在该和组织里具体执行变革的人进行交流了。有句军事名言:“没有任何计划能活到与敌人接触之后。”组织成员并非传统意义上的“敌人”,但他们的反应可能出乎你的意料,根本没计划或想到过。

以下是一些建议。

● 随机应变。计划是一种手段,而非金科玉律。把组织变革计划当作行动指南,而非强制之举,正如另一句军事名言所说:“计划虽微不足道,但制订计划就是一切。”

● 注意。起初,事情可能会进展得顺风顺水,变革推动团队总是说最初的努力很容易被接受。这通常会产生一种错误的安全感,认为事情会继续没有任何阻碍。然而,实际情况是对立面一直在虎视眈眈。此时你很容易占上风,直到对立面也组织起来抗拒变革。

● 保持警觉。无法预知的障碍可能随时出现。看似一马平川,但灌木丛中可能藏着狮子、老虎和熊。制订好计划和实施步骤,积极主动地接近丛林。

● 随时准备改进计划,使之适应实际情况。计划的每一步都有三个选择。首先,哪一步不起作用时,就放弃或退出。其次,根据实际情况,对步骤进行修改。最后,若步骤能按预期进行,继续推动它前进。

先找个处在困境中的小项目,证明标准项目管理方法对它是起作用的,从中总结出一个成功结论,然后利用它证明其合理性,进而把它运用到更大的项目中去。项目团队成员可能会突然发现自己接了一个巨大、高关注度与公司性命攸关的项目。这种情况就需要制订一个完全不一样的方案,计划需要根据实际情况而发生改变。

有人建议,针对项目办公室应采取广泛行动,从项目经理培训开始,培训他们的专业技能,使项目办公室最终能够有助于项目的组合管理。然而,辅助项目组合管理可能是项目办公室成员被要求完成的首要任务,随后就需要计划上的变革。

和组织沟通经常会导致情况混乱。应对混乱情况没有捷径和既定方法。这时,看你的地图,继续前行。

阶段三

阶段一是为变革创造条件,阶段二是实行变革。现在我们准备进入最后一阶段,也是最艰难的一步:让变革持续。如果变更推动团队能进行到这步,就已经消耗了部分时间了。毫无疑问项目办公室已经变革过许多次,可能从项目控制办公室,到卓越项目管理中心,再到战略项目办公室。

组织本身可能也已变革过很多次,变得更集中,然后分散开,最后再回到集中。首席项目官也许已经任命了,并且拥有和首席运营官一样的权力,这样就形成了矩阵式组织结构。而首席执行官可能也换了好几次,多个管理办公室的人员来了又走,因为人们要从零预算开始,经历了大规模的“中子弹杰克”(“Neutron Jack”)5裁员,尝试了重组,甚至一个平衡性方法。

若项目管理团队经受住了那些变革,并且给出的结构和流程都执行了,他们可能会开始觉得这些变革不再改变,他们已经在组织内作了一次持久性的变更。然而真是这样的吗?

经验告诉我们完全不一样的情形。假设组织就是一个大的橡皮圈,可以用双手进行拉伸。项目管理的变更已经使得组织内的人员扭动、翻转、拉伸。只要压力还在,组织就会处在紧绷的状态。一旦压力释放——哪怕只有一只手松开,组织又会恢复到以前的状态(见图11-1)。

大多组织变更的流程会跟某个人或某一群人保持一致。只要这些人在组织里是当权者,大量的精力会用来帮助运作这些变更。开会、参会、建立委员会、在年度报告发布声明,所有这些都是为了表明他们支持变革。然而,当带头人离开组织或变革推动团队下台时,一切就停止了。关于变革流程的会议不再开了,委员会也解散了,突然大家都有自己的事要忙了,年度报告里的声明也被人遗忘了。在带头人离开之后到组织访问的人,很难找到任何能够体现得出有过变更的活动迹象,组织又迅速回到原来的状态了。

要在变革发起人走了之后仍保持变革,就意味着要寻求一个已经变革的状态,并且开始为之建立框架。将领导才能、学习、方法和动机(这四者缺一不可)运用到第5章所提到的组织成熟度组成要素中,以此为项目成功创造环境(格莱姆和英格伦,2004)。目标是为了达到一个“临界点”[格莱德威尔(Gladwell),2002],此时关键人物、流程和环境一起作用,来支持这个已经变革的状态。成功的关键在于要长时间保持住这种压力,这样就没有想用其他方式做事的人留在该组织。若确实做到这样,就不存在以前的组织反弹的情形,这样的话,新的流程就能变成现实。

变更控制与变更管理

变更控制这一术语通常指的是对项目变更的实际管理,并确保变更得到批准、整合和归档,等等。变更管理涉及的问题更广,主要与组织和人力资源有关,不仅影响到经历变更的项目,还有人们是如何受变更影响的。这就包括处理和克服个人和组织两方面的抗拒,个人是因为感觉受到变更威胁,组织是因为目前结构还没做好变革准备。变更管理不只在变更得到变更控制程序批准之后才发生,在确定是否、为什么、怎么样以及何时管理任何变更之时,也会提前发生。

变更控制就是对项目三角约束中的任何一方进行变更管理的具体步骤。变更管理就是通过管理人来采纳、适应和运用变更的过程。优秀的项目领导者要精于两者。无论我们是否理解这两个术语,在个人、团队、项目和组织层次执行所有变更时,考虑清楚这些问题是很重要的。

这些变更管理步骤——为变更创造条件,作出变更以及让变更持续——适用于任何倡议。例如,如果一个组织想要引进控制项目变更更加具体的流程,那就需要按照变更管理流程来执行变更控制流程。同样,如果你想成为福音传道者,让更多的项目管理流程在你的组织内得到实施,你就需要采用变更管理方法。

项目管理经理克里斯汀·G.(Christen G.)给出了以下观点。

项目管理协会发布的《PMBOK®指南》把项目控制定义为“识别、记录,赞成或反对,以及控制对项目基准的变更。”或是“决定采取纠正或预防性措施,或是重新规划,以及依据行动计划跟进,来确定采取的措施是否解决了绩效问题。”由此可以看出,变更控制更多指的是决策什么变更需要、什么不需要。这跟变更管理相反,变更管理更多地是处理经过批准的变更及其执行。

《创建项目办公室》(英格伦,格莱姆和丁斯莫)(Creating the Project Office, Englund, Graham, and Dinsmore,2003)里谈到了变更管理的阶段:领导组织变更,了解紧迫性,建立指导同盟,制定蓝图和策略,利用内部支持;掌握其复杂度,执行,前进,人员配备和运营;向前看并讲述故事。这些术语都跟同一个关键目标有关——确保变更对组织有利或是项目目标得到授权,并能领导组织经受住变更,以此确保一个好的结果。

书中还谈到为变更创造环境。我把这个看作是组织内部的更多的变更,而不是一个对于只影响项目结果的项目的变更请求。公司要发展壮大,获取更多利润,变更就有必要;而要让这一切发生,需要有个强大的变更管理系统。项目经理在这两项活动中都很积极但能力不同。对于执行综合性项目控制的流程而言,项目控制更多扮演的是顾问的角色。对于组织、团队成员或受到变更影响的员工而言,变更管理是顾问的角色。

根据我的经验,有两种截然不同的变更:一种是对项目规模、时间和成本的变更,一种是对公司政策、目标或愿景的变更。在我的公司,通常是对项目的变更——我们的客户总是改变范围,我们也总是盲目地改变范围,而没有改变项目的成本/时间比例——其实,我觉得变更控制程序能够使项目质量有所提高。而对于变更管理,我们即将结束几年前开始的对公司方向的变更。广告也从传统形式(电视或文字)转到数码形式(网上宣传和社交渠道),公司也注重把自己转变成一个专注于数码的公司。这一变更遭到了一些员工的反对,他们只愿舒服地待在他们熟悉的领域而不愿学习新的知识。因此,管理这个变更的一个最大要素是领导团队。看待变更阶段时,他们当然会将其和我们已经经历过的相联系。据我所知,那个项目的经理们能够进行交叉训练,遇到的反对要比其他部门少。并且,在应对变更时我们被当作榜样。

案例分析

在本案例中介绍的是一家金融公司,它要在市场保持领先地位,这取决于它变革行为、技能、结构和流程的能力。该案例描述了西班牙的一家银行——格拉纳达(Caja Granada)银行的主要变更流程,它是如何减少对变更的抗拒并利用现存的有利条件的。每次变更本身是痛苦的;项目需要组织内部每个人的努力。有的人回应得很好,也有许多人拒绝在改变自己的行为上作出努力。

位于西班牙马德里的惠普咨询公司被选为主要的承包商。作为项目经理,我(布丝洛)和团队一起承担了这个任务,即通过项目管理技能和流程发挥作用。整个组织需要变更才能实现项目目标,成功是可能的,因为大家都愿意学习,他们具有激励整个项目团队的能力,并且即使面对极其艰难的状况也决不放弃。

项目背景和客户目标

客户是西班牙南部重要的金融公司,十年来,该公司一直是UNISYS系统和解决方案的大型用户,并且在那个时期一直很稳定,业绩良好。体系和方法保持多年不变,并且不允许大量快速变更,而现在他们面临巨大的竞争压力。

客户非常清楚使用者乐意用旧的系统,但要在金融竞争中存活下来,就要尽快变更。Y2K6的逼近迫使所有金融组织必须要做好准备,这也意味着他们不得不更新或创新系统保护程序,培训相关人员以及更新或改变技术。

“红城堡”(Red Castle)项目于9月开始。“红城堡”是个信息系统规划项目,由功能创新和技术创新组成,能通过运行硬件和软件平台,研发定制的软件包和管理变更,来满足市场和环境需要。

看着需要进行的所有变更,与新客户一起工作,了解所有的项目干系人和他们的行为,我知道我的挑战开始了。

客户的商业目标如下。

● 绩效提高。办公室需要更多的业务而有些流程导致了数小时的耽搁。

● 增长。银行需要增加组织的分支数量,而不损失绩效。

● 新技术。他们需要更多的能增值的有竞争力的东西;改变他们的平台和软件是当务之急。

挑战

最复杂的任务之一就是要让银行高层经理相信项目规划的必要性。起初客户参与进来了,第一个月之后,客户就要求有实际效果。我解释说规划对于项目成功绝对有必要。我借来设备并让一个团队成员启动机器,为的是向客户展示惠普是如何在它的平台上运行的。这样暂时减小了客户压力。

管理项目过程中的挑战是变更管理的一部分,也是项目经理的责任。与银行经理清楚地交流和建立亲密关系是至关重要的成功要素。我检查了“红城堡”项目和银行规划之间的联系——这种联系在项目全过程中被证明对我们非常有帮助。在我的督促下,高级管理层对这个项目高度重视。

流程

惠普的公司项目管理推动小组(Project Management Initiative,项目办公室的一种形式)总结了主要的变更引导流程。为了得到支持并将对客户组织的影响降到最低,我应用了这个流程。

确定项目关键人员

花了两个多月的时间分析客户组织内所有的关键人员。在第一个月,我组织了阶段性会议,目的是让人们参与进来并告知其项目的地位。我日常的任务之一就是让大家都能找到我,这样的话就能促进团队成员间的信息沟通和交流。

成功的一个关键要素就是能拉到那些能保证资源并且支持项目经理的发起人。客户认为这个项目至关重要,并完全把它和商业目标联系起来。惠普最初的模型就确立了四类关键人员:支持者、发起人、代理人和目标对象。我是这次变更的代理人,但说实话,起初我觉得自己是支持者。我得积极主动、自信并且获得客户信心,以此来为交流开个头。

制订执行计划

我们要做的第一件事就是确定哪些事能保证变更并且帮助大家理解变更的价值。在计划阶段,我们让所有的团队领导者都参与进来,讨论执行的不同策略。这并不难,因为每个团队领导人都负责不同的职能范围,而且非常了解之前的旧体系。

我们分析新旧体系以及运用之间的差距,同时,计划还要把对流程、体系、人和组织的变更考虑在内。然后,我们再制订一个执行变更的计划,要考虑到可能对流程、人和技术产生的影响和突发事件。

为了促进变更,我们需要获得银行高层的支持。通过和他们分享事实和理论依据,我说服他们,让他们得出这个变更计划是有效的结论。当计划结束时,我们要求得到发起人对执行计划的认可。而我自己也得到了执行委员会和组织内其他干系人的认可。

理解行为模式和对变更的反应

在这类项目里,像往常一样,我们会找出整个项目生命周期里抑制变更的因素。我需要和所有分支组织的负责人单独会面,来澄清项目目标并让他们相信项目对他们及他们的事业会带来巨大好处。

该银行强制变更,但我们得一个组一个组地向银行的工作人员解释变更的所有理由和合理依据。结果是,因为我们建立了很好的沟通机制,人员的抗拒也减少了。

就流程、人员和技术而言,客户的状况是稳定的,但为了让他们更加努力,银行的高级管理层必须知道如何激励和补偿人们。他们知道没有补偿就没法获得额外的努力。然后他们再为每个团队领导者制定标准和个人目标。

在此过程中的一个成功要素是,识别不同的行为模式,并留出足够的时间和组织的每个人一起工作。

变更引导流程

● 领导。我们为个人划分了八个功能组,制定了具体的目标,并授权那些团队领导人参与大多数的决策。为了完成这些事,通常我需要高级管理层和客户的支持,但我对其他人的影响不大。

● 测试。我们邀请人们来表达他们对于变更的反应,这个反馈非常有价值,能让人们从错误中学习并取得进步。

● 认可。我们确定留有进步空间的标准,并认可团队和团队领导人所作出的努力和所获得的成就。

● 跟进。每个项目都是活的,需要监督。这样的话,后续跟进就包括每周和项目领导人作简要回顾,分析结果,从我们自己的经历中学习。

团队

团队由职能团队领导人组成,他们掌控着银行内每个职能领域的整个项目生命周期。每个职能领导负责和终端用户交谈和见面,领导他/她的软件研发团队并管理所有的测试。惠普顾问培训这些领导人,让他们为管理和激励团队做准备,并且这些领导人还得到了惠普项目经理的支持。

执行委员会成员不但要参与发起任务,还要加入到促进项目成功的交流和宣传任务中去。他们和人们交流,支持他们,以公开方式鼓舞士气并认可他们的努力。

采用的工具

● 团队训练,利用真实的会议让想法付诸实践。

● 对之后即将公布在计划文件里的角色和责任作出定义。

● 改变代理商的培训方式。

● 日常团队成员间的交流。

● 要求每个团队领导人都进行反馈。

● 团队成员之间要互相交流和尊重。

结果

项目经常失败不是因为技术原因,而是因为组织内的人拒绝变更。执行体系成功的关键因素在于人和组织要素被规划的方式,而技术是次要的。起初,整个管理团队没能理解这一信息,我们花了六个月时间才让每个人信服。

从客户的角度而言,我们可以根据许多参数衡量出结果,但当谈到变更管理时,我们谈的是能够促进变更的流程、人员和技术。

流程

流程需要由人来制定、修改和使用。执行新的流程是这个项目中最艰难的一步,但能参与到这一步的人都应该很骄傲,因为他们有机会对项目成功作出贡献,成为一家成功银行的员工。通过评审旧流程,规定新流程,以便能让他们将新产品引入市场。流程的所有权是关键。

人员

另一个关键结果是终端用户对体系的使用。每个用户会逐步让他或她的行为适应新的体系和新的流程。任何体系都是由终端用户来测试、衡量和评估的。在这个案例中,起初,各分支的终端用户没能参与进来,因为他们没参加最初的研究,但在几个月内他们的参与度以一种积极的方式在不断增加。

技术

当项目结束时,新应用里的所有软件模块都在运行。客户拥有了一个为新世纪建立未来信息系统的基础平台。旧系统里的技术结果得到改进。绩效更好了,系统让客户能在金融市场内有足够的技术竞争力。

经验教训

我们得知以下几个因素是项目成功的关键。

● 客户高级管理层对项目的赞助是必需的。

● 将项目和银行战略联系起来是项目成功的前提。

● 质量管理会对项目的成功起到很大的作用。

● 沟通规划和实施很难,但却是促进变更的关键。

● 鼓励终端用户的参与是必需的。

我发现和团队里的每个人合作时,自己得有不同的参与度。与人合作花费的时间比例,可以根据项目阶段来分类。

启动和规划阶段

● 我所有的时间都花在范围确认和规划上(时间花在客户项目经理、团队领导人和其他干系人身上)。

执行和控制阶段

● 75%的时间花在交流管理上(和整个团队一起)。

● (每周)用40%的时间花在项目会议上(和团队领导人、管理层和执行委员会一起)。

● 剩下的时间花在规划和监控上。

即使你有优秀的领导技能做后盾,在大型组织和复杂项目——如格拉纳达大银行——要取得变更主动权上的重大成功,仍需要许多人的参与,还需要时间、耐心、坚持,尤其是高级管理层的支持。像我们所遵循的那样详尽清楚的变更管理流程,是项目经理工具箱里必不可少的工具。

项目团队的适应能力

一个同事兼好友,迈克尔·欧·布洛切特(Michael O’Brochta),现就职于Zozer公司,他与我们分享了以下经历。

即使是项目管理中最有用的计划,哪怕制订得再仔细,都要受制于变更。这个新认识,是当我在美国中央情报局(Central Intelligence Agency, CIA)开始项目管理生涯的初期才有的。回顾以往,我总觉得这个关于变更的意外启发来得太晚了。

在情报机关工作生涯的初期,我仰仗自己的电工技能,认为自己越努力,就越能从认真提出的经久不变的要求中更加精确地表达客户的需求。我认真地列出追踪和定位策略的要求,以便特工能利用这些策略对形形色色的人和工具保持警觉。我甚至还在列表中加入了一些要求,这些要求基于我对客户想要什么以及我了解到的对他们需求的不断理解。我觉得自己的状态变得相当好。我非常重视这种准确性,毕竟我是个工程师。

我曾经很幼稚。但事情总会改变的,这是我无法控制的事实。当我狭隘地认为自己无法控制变更时,我又开始妄自菲薄。我开始了解需求变更,但却想尽办法去阻止其在我的项目里出现。那么,如果客户调整他们的需要该怎么办?我对自己工作的看法是,确保自己的项目和那些变更隔绝,隔绝程度只要使项目在预算内、不受变更损害、能按时进行即可。我也非常擅长这点,同时也很自豪自己能牵制自己的客户,并仍能推动我自己以及我依靠其来坚持原始需求清单的承包商。

的确,我在预算内按时精确地完成了很多项目,并达到了所有的要求。问题是,有的项目成了“架子上的摆设”。这些交付物、追踪和定位设备或其他类型的间谍工具,有时客户并不采用——它们被放在货架上,干等着被使用。这怎么可能呢?我在想。一些有用的、能满足所有要求的间谍工具,为什么不被使用呢?此时,我的天真屈服了,慢慢地被基于经验的智慧所代替。

我开始明白,作为项目经理,我的职责不是阻止变更而是接受它,我开始明白自己的职责是管理变更的影响。我明白需要确立管理那些终将发生的变更的方法和流程。我会把那些最可能发生的变更当作风险,并作出回应以减少风险发生的概率或是减少其对项目的影响,如果确实发生的话。我会确立要求、进度、计划以及任何受制于变更的任何事物的基准线。我会进行例外管理,如果没什么变更,我就会按计划进行。若发生变更了,我会作些分析并确定其影响。这些影响会和别人分享,以便他们能就变更是否值得作出决定。我会遵照他们的决定。那一刻我意识到了变更管理所确立的方法和流程。有关配置管理的Mil-Std-973是个讨人喜欢的能让人大开眼界的东西。

这对正逐步显露的项目管理技能中央情报局年轻工程师而言,是个很棒的东西。意外的发现!我的任务是管理变更。

不灵活是项目经理最糟糕的弱点之一。你可以学会控制冲动,用自信克服恐惧,用纪律约束懒惰。但思维不灵活没有任何解药,很可能为失败埋下隐患。

有些项目经理在做客户项目时总想强加上自己的习惯和进度表。若想让客户团队团结一致,有必要灵活适应客户的进度表。我们建议无论你去哪儿,他们怎么做你也跟着怎么做,否则你不会被当作是团队必不可少的一份子。团队合作和个性强硬不可调和。要想和他人相处得不错,同时成为优秀的团队成员,就需要心甘情愿调整自己去适应团队。

那些有较强适应能力的项目团队成员,一般具有以下性格特征。

● 可教性。他们是这样一种人,只要能看到这种经历能让他们达到一个新高度,暂时的痛苦或不适不算什么。他们对于未知领域感兴趣,知道通向未知领域的唯一路径就是突破障碍。适应能力强的人总是非常注重开辟新天地。他们非常具有可教性。

● 情绪稳定。项目有很多不确定性因素。要获得成功你必须先相信你能成功。那些情绪不稳定的人总是把一切都当作是挑战或威胁。和项目中的其他同事相比,他们更加敏感多疑。一项新的活动,一项进行中的变更却有可能被看成是挑战或威胁。情绪稳定的人则不会被变更弄得紧张,他们会在自己的职责范围之内,从价值和影响的角度来评估新的情况或变更。

● 具有创新性。创新是一种能用新的方式组合事物的能力。当困难到来之际,人们会想方设法来处理。那些无所畏惧的人是真正的具有创新性的人。他们是那种能想出新方法,继续前行,并最终实现目标的人。

● 具有服务意识。相比那些愿意服务他人的人,那些只关注自己的人不太可能为整个团队作出改变。不愿为别人做任何事,其实自己也会一无所成。如果你的目标是服务团队,那么调整(自己)来实现这个目标并不难。

当谈到适应能力时,你有怎样的想法?作为项目经理,如果要提高团队绩效需要你改变做事的方式,你会作出何种反应?你是支持还是继续按以前的方式做事?要成为具有团队精神的人,最关键的就是愿意使自己适应整个团队,而不是期望团队来适应你。

以下是基于我们的自身经验,能让你适应能力变得更强的一些看法。

● 养成学习的习惯。很多年以来,我(布丝洛)的口袋里一直放着一张卡片,每天我都会把新学到的东西写在卡片上。当一天结束时,我会试着和朋友或同事分享,并把这个想法归档以备将来使用。这让我养成了不断寻找并学习的习惯。你也可以尝试着做一周,看结果如何。

● 重新评估自己的角色。花些时间重新审视下自己目前在团队中的角色,然后试着找找是否有同样或更好的角色适合自己。这个过程可能会促使你转变,但即使没有,这种脑力锻炼也有助于增强自己的灵活性。

● 打破常规。许多人适应性不强是因为他们陷入了消极的陋习。若你容易发生这样的情况,把下面这句话写下来并放在你每天能看见的地方:“不是为什么不能做成,而是怎样才能做成。”每当遇见挑战时,要努力寻求创新性的解决方法。若持续这么做的话,你会很惊讶,自己已经变得如此富有创新力。

项目在其整个生命周期里总是频繁地变更,为了整个团队的利益,你得适应它。那样的话,你会一直有机会成功。对于全能项目经理而言,适应能力是个关键技能。花时间训练你的团队,让其适应能力越来越强,你也会成为更好的项目经理。

帮助他人认可变更流程

西蒙娜·邦孜(Simona Bonghez),一个在罗马尼亚之外工作的项目管理专业人士(PMP)向我们分享了以下对话,该对话阐述了她和她的同事所经历的学习历程。

西蒙娜:传统的项目经理非常注重项目机制(手段和技术),有时会忽略人具有能动性的一面——处理人际关系和增加交流互动。事实证明,如果多注意处理相关利益方(需要他们的支持或突破其阻碍)的关系,成功的概率也会增加。当然,我们指的是干系人及和项目有相关利益的人或团体,他们能影响最终结果;他们可能会推进整个项目并积极支持它。但他们中也有些人想法相反,因而会想办法阻碍变更。

我想举个例子,是一个建筑公司的组织发展项目。一个工程和技术非常专业的专家被任命接管这个复杂的内部项目,他的专业技术非常纯熟,并且非常善于激励团队;然而,这个项目给他出了个非常大的难题,因为他对干系人管理和沟通非常生疏。

项目经理:这跟我以前做过的项目(建设项目)截然不同,明显从注重“硬”技能转变到注重“软”技能。交流很“煽情”,并且浪费时间,真相并非如此。为了项目,我需要组织管理层和员工双方的付出和参与,而我唯一的“武器”就是交流。我得知——艰难地——为了有成效,我得识别所有相关的利益方,明白他们的要求和期望,期待他们的回应,尤其最难的是影响他们。

西蒙娜:为了影响他人以某种特定方式行事,你认为项目经理最关键的社交技巧是什么?

项目经理:嗯,对我而言,最关键的社交技巧是交流和懂得变更管理。为了获取高级管理层的源源不断的支持,并让这个项目一直处于优先地位,我得和他们沟通。我得跟主管和职能经理沟通,让他们相信这些变更对他们的位置不会产生不利影响,让他们明白自己职责的变更以及帮助他们适应。他们有些想法要融进我们的项目,有些倡议要停止,所有这些行动都要有合理依据,要事先计划好,然后恰当地交流,最后再进行变更。

西蒙娜:因此,干系人的管理不仅代表的是和项目管理领域的另一种社会交流,其结果在一些“纯”项目管理方面也很明显,如资源和质量规划、变更管理,它清晰地转化成数量和质量指数。在项目的初期阶段,项目经理应该对干系人进行分析,将他们的要求、期望文档化并上交团队。评估完干系人利益(以及他们积极或消极地影响项目的方式)之后,要制订一个处理与他们之间关系(获得他们支持,最小化他们的反对,以及为项目创造有利环境)的计划。

项目经理:这还不够。在参与项目时,干系人们有不同层次的责任和权力,并且这些责任和权力在整个项目生命周期中还会变更,他们的期望会改变或与其他干系人的期望发生冲突。在项目初期,团队成员是项目的重要支持者,但随着事情的进展,他会觉得项目以某种意料之外的方式影响着他的地位,感觉受到威胁,从而开始搞破坏。我学会了应该保持警觉,不要把干系人的目前状态当作是确定不变的,对可能构成转折的外部变更保持警惕。在整个项目生命周期中,干系人管理是个持续的职责。

西蒙娜:干系人管理和沟通是项目管理的一种方法,它将项目的重心从“硬”技能(与内容有关的活动)转移到“软”技能(关系方面)上。当然,两者都非常重要而且要平衡好。为了实现这个目标,有必要让管理项目的专业人员意识到干系人管理手段的重要性,且这么做的效果显著。

莱姆克·麦斯纳(Remco Meisner)分享了以下片断,以便帮助其他人意识到变更的影响、评估组织状况,并且明白全能项目经理该做些什么。要特别注意他是如何精心提问的。

在一个政府组织项目的起始阶段,威姆(Wim)来找我征询意见。我认识他大概有十年的时间了,因此当他问道:“你认为这个项目能在三个月左右完成吗?”我发现他有一丝紧张。

莱姆克:我曾在几个礼拜之内完成过类似的项目。为了作出恰当的评估,我需要更多的细节。例如,我知道在过去五六年里,这个部门连续至少有好几次组织变更。这可能没影响他们的热情,但说实话,我担心在经历了那个时期发生的事之后,人们已经精疲力尽了。

威姆:是的,我认为过去几年的确发生了很多事情,而过去半年却是另外一回事。最近我们宣布了一个新的程序,它要求几乎所有员工改变他们做事的方式。你知道的,由于新政府制定的新政策,我们不得不这么做。直到上个月,我们才制订出了新的规划。这花费的时间和精力超出了我们的预期,但我们对最终结果并不是特别满意。它已经让我们的一线员工精疲力尽,并且他们也明显感觉到了我们的期望和现实结果之间的冲突。

莱姆克:前几天我和彼得谈话时,他跟我讲了点这些,他还说已经在全国范围内对所有建筑会有大规模的改建。我们知道几年前其中一栋建筑发生了火灾,导致了人员伤亡,这引发了媒体的特别关注。因此,那个国家将近70栋建筑现在需要更新防火保护措施:换成新窗户,更换所有的门和金属设备,等等。要完成这些,需要将在那工作和生活的人暂时重新安置。这让我们的员工和那些住户很有压力,也会让形势紧张,人们感觉拥挤时可能会产生冲突摩擦。除此之外,我们没法为所有人合理安排住房,提供足够的居住空间。

威姆:是的。在未来一年,有一些事情是我们谁都无法战胜的。将所有信息整合到一起,那个为期三个月的时间安排,听起来实在是毫无吸引力,是这样吗?

莱姆克:嗯,然而这未必不合格。上回我为你做这个软件开发项目时,我们不得不和几十个外来的分析师、程序员、设计师和测试人员一起来做。我还记得,你的公司没什么做复杂项目的经验——临时从各个领域召集来的很多专家一起赶工。难怪你没经验,因为那不是你的核心业务,对吧?做这种项目的确是个例外。然而,情况比部门预期的要复杂混乱得多,在那时这倒可以让人开开眼界。

威姆:在现在那确实算个项目,对吧?但我们成功把它延期了。现在我依然还记得当时要让信息通信技术部门(ICT)和项目内人员合作有多难。他们真的是截然不同的两群人:项目成员乐意创新,愿意彻底变更;信息通信技术部门(ICT)则完全相反,他们总是试图按既定程序和服务协议来办事。这根本不切实际!并且他们在做这种规模和难度的项目方面没什么经验。在这点上我非常赞同你。

莱姆克:我想起上次我们做项目时很打动我的一些事。在海牙的董事会和遍布全国的董事会意见不一致。他们对经营企业的方法有截然不同的看法,是吧?在努力得到所有董事的赞同之后,海牙(董事会)宣布要变更组织结构。然而,最终董事们还是让组织回到了原来的结构,这点董事会毫无察觉,这样的话实际上他们再次屈从了原来的想法。我认为对于政府组织而言这很典型,因此没有抱怨。但让我觉得很有趣的是,在私企就不会发生这样的情况。

威姆:嗯,在这方面我们的确有遗留问题。它已经存在几十年了。在海牙(董事会)的人并不非常清楚该如何处理领域内不同深度的问题,并且他们总带着最好的期待来作决策,这从长远来看,在外界或多或少会被忽略掉。或者,充其量也只是作细微调整而已,连续许多次之后,最后被彻底改变了。

莱姆克:这么说组织还是有一定的刚性的?

威姆:嗯,是的,通常是为了更好。

莱姆克:嗯,如果我没猜错的话,你目前有个复杂的项目,想在几个月内完成。

威姆:没错!

莱姆克:等等,我还没说完呢!(两人大笑。)你去年很忙,并且在此之前也并不平静轻松,对吧?

威姆:不是。

莱姆克:运用了新的手段,他们需要花费比预期多得多的时间、精力和金钱。而你对最终结果并不满意。

威姆:对!我们认为它还没完成呢。

莱姆克:由于政策压力,防止火灾事故失控,人们全都在进行这种类型的建筑工程。这会对全国范围各个部门产生影响。这的确给那儿的人造成压力,因为为了让工人修理那些在金属设备、门窗上存在防火漏洞的地方,他们不得不四处搬迁。

威姆:对,我认为这会对他们的工作压力产生巨大的影响。我们还没有那么多的空间来搬迁……

莱姆克:最后我要说的是,你在处理类似复杂项目方面没有经验。住在单元的住户和中央办公室的人,不习惯应对大的变更。这就需要复杂的规划体系,因为我们得在全国范围内对人们的日常习惯作深度改变。新的习惯会接替旧的,让现有的功能、等级制度和奖励体系颠个底朝天。

威姆:我预感到接下来会发生什么了。

莱姆克:在过去几年,组织不得不应对一系列大的变更,这让它厌烦了变更。现在我们谈论的变更将会影响到它们的根基,因为它会影响头衔、奖励体系、掌控一切的信息系统、规划方式……(停顿了一下)我想实际上你对相同的规划体系不是很满意,对吧?

威姆:对。那儿可能还会有些改变和更新。

莱姆克:实际上,关于项目方向的变更,你的组织还没完全准备好。复杂的变更需要各个部门和各个领域的专家参与,他们要团结一致,在数不清的话题上找到共同点,这才有可能构建成我们心中一直构想的那个结构。

威姆:那么你认为三个月太短了?

莱姆克:是的。我本可以能够在短时间内将它延期,但是效果并不如人意。最好还是根据实际情况来确定时间。我们真的必须重新在目前所站的这个垫脚石上找到平衡,在迈出下一步之前,认真想好下一步该做什么。如果不这样的话,我们可能会跌倒或摔进水里。

威姆:那你的建议是什么?

莱姆克:我们得从已经完成的任务里学习经验。接下来,为了执行对每个单元的变更,我们得调查该采取什么步骤。与此同时,我们得找出其他项目的期限。我们已经完成哪些工作?哪部分最明智?我的意思是,谁拿到了第一块绿牌,谁会是下一个,等等。同时,为了应对新的结构,我们得弄清楚改变信息通信技术部门到底有多难。我们还要调查清楚,对我们在全国范围内运用的程序会有何影响。我想他们还在使用我上次碰到过的那种长长的软件清单,是吧?

威姆:是的,但我们一直为此在努力。

莱姆克:我知道。让许多人出来并不容易。过去这些单位都有特权,我们都知道,要增加特权,人们很容易接受,但要减少就难得多了……

威姆:我们把很多人剔除在工作名单之外,在那之后,我们明确地解释了这个消息。但如果你去核查该领域的状况的话,仍会发现很多单位每天还是用着过时的软件。

莱姆克:我知道。让我加一条建议:我们应该把在海牙的和单位的管理团队联系起来。我们需要确定哪些是失败因素哪些是成功因素,开始的热度怎么样。由于各方厌倦变更,开始时应冷处理。我们该如何让那些在日常工作已经学会变更的人参与到这个项目中来?

威姆:那么我们需要一个变更方法?

莱姆克:没错!由于这是个项目主导的大环境,起码这是组织所喜欢的,我们需要规定几个项目来处理将涉及的不同领域。这个变更方法关联不同职位的董事,并有助于作决策并跟进它。项目方法将处理规划,这也可能是个项目。另一个项目将是人力体系。第三个项目就是在领域内使用的不同应用程序。思爱普(SAP)体系和所有的金融数据流将是第四个(项目)。第五个项目将应对劳资协议会和工会。最后一个项目不太符合项目的定义,因为它是一系列猛烈的措施,但如果你喜欢的话,我们可以把它归结为类似项目的东西。

威姆:我们什么时候能开始?

上述故事和莱姆克与威姆之间的对话基本一致,描述了在起初认为就像是标准项目的重大组织变更中,变更管理和项目管理技能产生的方式。

与项目管理相比,变更管理是另一种机理。它们有相似性,比如都面对临时性组织,相应的结构,经常牵涉到外部专家,都面临(通常很紧张的)预算限制和管理团队的沟通互动等。但它们也有同样多的差异。

在变更管理中,有必要考虑参与进来的组织的起点。在过去几个月或几年,它是否遭遇了一系列的变更?这将影响该组织内人员是否能再次接受另一个变更。若组织一直很稳定或变更很小,这可被看作是“温暖的”。温暖在这方面指的是组织能应对创新,并且该组织员工不会轻易地让自己对工作的看法变得消极。而在“冷的”组织内,员工处理原来事务就已经疲惫厌烦了。若这点在项目开始阶段没被考虑到,结果可能会事与愿违。无论如何我们都得不到太多的帮助。

在变更管理中,我们应该考虑到组织的成功和失败因素。他们擅长什么(成功因素)以及他们应该还承担些什么,即使在这点上他们自己看得没我们清楚?他们对哪些事物和活动应对能力很差(失败因素),我们该如何避免将他们卷入其中?

我们还需要考虑到彼得·德鲁克(Peter Drucker)的“商业理论”。组织背后隐藏着什么?组织是在什么基础上开始、发展、生存下来的?组织基于此的假设是什么?

其中最重要的是,我们要考虑到,变更管理针对组织,而项目管理针对事。我们承认,自己的确也把和项目相关的人员考虑进去了,但与变更经理的方法相比,项目经理的方法还是有很大区别的。

变更经理得诱导员工和商业关系从A转到B或C。一旦这些事物跟他们的诉求产生了联系,就变成了项目。

项目经理跟研发新事物,推动其发展或变更它们有关。一旦有人参与进来,那些跟“事物”关系最紧密的人就会被考虑到(起码,一个可靠的项目经理会这么做)。但在项目中,并不是所有的组织内员工都会被考虑进去。

不允许我们把猫叫作狗,反之也不行。我们不会因为把项目经理叫作变更经理(反之亦然)而中枪。我们可能会决策开始一个项目,而实际上是个组织变更,它不这么叫是怕被扼杀在摇篮里。但如果我们尽可能地保持单纯,上述理论就是真的。

在理想状态下,任何想参与复杂项目的项目经理至少应该知道变更管理的关键。任何项目,无论大小,都可以从项目经理身上受益。我们总是会忘记这个事实,事情和个人在很多方面总是联系在一起的。我们项目经理应该能够通过学习变更管理以及它给我们带来的新视野,将自己从一个项目中所收获的绩效和评估转移到另一个项目中去。

你可能感兴趣的:(变更管理技能)