蝙蝠侠求救电话:白皮书

本白皮书标题引用了哥谭市陷入严重危机时,指挥官戈登可以自由使用蝙蝠侠求救电话的故事(取自 20 世纪 70 年代的“蝙蝠侠”电视剧集)。

本白皮书是我们的“一线快报”系列文章的一部分。 本文联系科幻故事“蝙蝠侠”,介绍了在 EPM 实施期间遭遇困境时,我们有时会多么希望能拥有一部“蝙蝠侠求救电话”。 其中还讨论了多种避免在实施期间陷入困境的方法。

若要下载本白皮书的 Word 版本,请参阅蝙蝠侠求救电话

若要阅读更多白皮书,请参阅“一线快报”白皮书

蝙蝠侠求救电话

1966 年,原创电视剧集《蝙蝠侠》正式开播。 这部剧集仅播出了 120 集,但对文化产生了延续至今的深远影响。 在蝙蝠侠与罗宾(分别由 Adam West 和 Burt Ward 扮演)的世界中,蝙蝠侠可以解决一切难题。 无论遇到怎样的难题,蝙蝠侠总能一一化解。 蝙蝠车、蝙蝠船、蝙蝠飞机和蝙蝠洞都是蝙蝠侠的好帮手。 如果您急需帮助,无论处境有多困难,要怎样才能联系到蝙蝠侠? 当然是通过蝙蝠侠求救电话! 拿起蝙蝠侠求救电话,蝙蝠侠就会前来救援。

红色 Batphone 的图像(来自电视系列“蝙蝠侠”)

在茫然无助时,指挥官戈登就会拿起蝙蝠侠求救电话 - 当然,这种情况在电视剧的每一集中都会发生。 无论面对怎样的困境,只要拨打蝙蝠侠求救电话,在 22 分钟内(外加广告时间),坏人就会被制服,哥谭市就会重归祥和。

蝙蝠侠的所有工具都是蝙蝠形状的。 手铐? 蝙蝠形。 多功能腰带? 蝙蝠标志。 攀墙爪钩? 看起来就像是蝙蝠翅膀的形状。 回顾蝙蝠侠求救电话时,我意外地发现它看起来是那样寻常。 一部带拨号盘的红色电话(还记得拨号盘这种古老的东西吗?),我不知道它为什么要带拨号盘。 因为这部电话只能拨打一个目标:蝙蝠洞,也就是救世主蝙蝠侠的居所。

带拨号盘的电话和早期蝙蝠侠剧集让人怀念,但这并不是今天这篇文章的重点。 蝙蝠侠求救电话早在 40 年前就已经退役,但人们每天都在呼叫 EPM 顾问,希望“蝙蝠侠求救电话”能再一次发挥作用。

他们面临的问题多种多样。 有些是技术性质的,需要从版本 x 升级到版本 y。 有些是体系结构性质的,需要让内部 EPM 系统与外部环境中的用户实现通信。 有些是文化性质的,如用户拒绝使用系统。 有些是程序性质的,他们所采用的流程似乎无法实现预期成果。

无论挑战如何,对顾问公司提出的请求总是相同的:能否在 22 分钟内修复问题?

遇到这种情况的 EPM 用户数量之多令人意外 - 在这种情况下,他们急需顾问的协助来摆脱困境。 情况往往万分紧急,而客户管理层却要求我们一早就已经准备好对应的解决方案,这未免太不切实际。 拨打电话的用户(我每周要接待许多这样的用户)并非一无所知。 他们都是聪明能干、成绩斐然的管理者。

当然,这世界上没有蝙蝠侠求救电话。 我真心希望它确实存在。 那样就可以利用它来解决各种各样的个人挑战。 那样就能让所有打电话求助的人感到满意。 那么让我们花点时间,谈谈人们最终如何陷入这种困境 - 让他们感到必须要拿起红色的电话求助的困境,以及您要如何才能避免成为其中之一。

陷入困境

首先, 我们谈谈人们在实施 EPM 时会怎样陷入困境。 有多种常见原因:

  • 低估挑战    目前,这是 EPM 部署中最常见的失误。 并不是说每次部署都必然庞大而艰难。 事情并非总是如此。 但人们或许总是过于一厢情愿,低估从 EPM 部署中获益所需付出的努力,而这种情况出人意料地极其普遍。 在低估挑战方面,第一个失误就是目标的选择。 有些人选择将工具安装视为一个成功的项目。 当然,实际上并非如此。 有些人将初次使用工具或初次从工具获取报告视为目标。 这同样也不合适。 选择 EPM 工具时希望处理的问题真正得到解决才是您需要关注的目标。 也就是说,文化发生改变、培训已经完成、投入实际生产应用、工具可以正常工作、数据已经到位。 这些工作可能非常重要 - 但如果目标设定失之毫厘,结果就可能一无所获。 (或者应该说,几乎一无所获。)

  • 设定技术项目    对于从事技术工作的人来说,这是我们最愧疚的方面,也是我们大多数人都非常熟悉的一种心态。 出于某种原因,坚信技术可用就表示问题已得到解决的诱惑难以抗拒。 因此我们访问过的许多组织都提出过类似这样的问题:我们已经安装了 Project Server,为什么员工还是不堪重负? 我们时常会说,企业项目管理工作是人员、技术和流程的组合,为了获得理想的指标,还需要涉及到大量变更管理工作。 这一切不会在软件 DVD 光盘送到府上时自动就绪。

  • 管理层未能参与其中    这同样是一项极其常见的失误。 毕竟,最了解企业项目管理系统优势的人员很可能就是那些负责分析拥有诸多项目、诸多资源的环境中的海量数据的人员。 在组织尝试协调一组错综复杂、相互冲突的优先任务,协调多种技能与经验的组合时,企业项目管理是最普遍的选择。 您或许会认为,此类项目自然会牵涉到管理层,但实际情况往往并非如此。 如果没有恰当的管理层参与,几乎不可能克服改变企业文化的挑战(即从单个项目意识过渡到企业项目意识),但由于担心管理层无法认同完成 EPM 部署所需付出的努力,这些工作往往会绕过管理层。

  • 制订不切实际的计划    没有人希望 EPM 部署耗费过长的时间。 人们通常希望项目能在短短几天或是几周内完成,而非常见的数月时间。 另外一个常见挑战是,无法为 EPM 等“内部”项目获得与基于客户的项目或商业项目同样充足的资源。 出于这样或那样的原因,项目计划中拟定的资源需求往往严重不足。

  • 未能为项目管理系统应用项目管理   如果您曾读过我写的文章,那么很可能已经看到过这种说法。 项目经理很容易出现“鞋匠的儿子不穿鞋”的症状。 结果导致他们自己的项目普遍缺乏项目章程、经过核准的预算、妥善跟踪的计划、专门的资源及其管理的其他所有项目普遍具备的其他配置。

他们会得到怎样的结果?

这就是 人们陷入麻烦的原因。 管理层期望通过部署 EPM 系统获得的优势通常直接源自业务挑战。 正是解决这些挑战的承诺才让管理层决定批准软件、硬件、基础架构甚至是服务的支出。 其中最常见的挑战耳熟能详:

  • 资源负荷过重    这些资源的去向可能不甚明确,但资源负荷过重的现象非常普遍。 更复杂的问题是,发现某些资源负荷过重,而其他资源利用率不足,这往往表示可用技能和经验与所需技能和经验不匹配 。

  • 关键项目未能及时完成    关键项目应该按计划完成,但现实似乎总是会打断计划。 原因可能是资源需求之间存在冲突,也可能是选择了太多需要过多相同技能的项目,或者是优先级排列不合理。 有时,组织可能认为项目经理自身缺乏技能,但在多项目、多部门的混合环境中,本质上更有可能是缺乏组织技能。

  • 项目未能按预算完成    适用于计划的事实同样适用于成本。 在高科技行业以及其他许多行业,项目成本中变数最大的部分就是所用的劳动力数量。 在人数不变的情况下,项目所用时间越长,项目成本就越高。 未得到妥善跟踪的白领项目之多令人惊讶。 这些项目经过规划,但各项目的实际成本未得到记录。

  • 竞争对手比您更快地完成项目    在竞争激烈的经济形势下,率先进入市场将成为生存与淘汰之间的主要差别。 因此,对于许多组织来说,确保项目管理至少与竞争对手同样高效非常重要。

  • 无法看到项目资源的时间投入到何处,也无法了解各项目所耗费的时间    有时,没有答案要比不好的答案更糟糕。 这一点在高级管理层间体现的尤为明显。 如果您确知结果不佳,您可以运用自身技能和可以调用的资源来解决手头的问题。 如果您知道存在问题,但无法确定问题在何处,那么就无法放开手脚解决问题。 无法了解应从何处着手尝试修复问题。

我要如何才能摆脱困境?

您一定不希望陷入只能寄希望于蝙蝠侠求救电话的困境。 那么您要如何处理 EPM 环境,确保不会陷入麻烦?

我们在第一部分中说明的要点显而易见:

  • 合理预测

  • 不要将 EPM 视为单纯的技术项目

  • 让高级管理层从一开始就参与其中

  • 制订现实的计划,将其与您所在行业内的其他计划对比,检查是否切合实际。

  • 制订项目计划和项目章程,采取通常对其他所有项目采取的全部措施

还能做些什么?

首先,项目开始时应该承认在未来的某个时刻,您会希望能使用蝙蝠侠求救电话。 必然会如此。 了解到这一点后,您就可以划拨预算,为当前尚未计划的协助做好准备。 我们建议客户将项目中 10% 至 20% 的预算划为供“未分配需求”使用。 客户总是会问我们:“这样做的原因是什么 ?” “不久之后,您自己就会来告诉我们答案,”我们总是会这样回答。 通常,这笔资金不会用光。 但动用其中的部分资金几乎是不可避免的。 安排技能精湛的专家和充足的预算会在项目后期带来极大的优势。

最初起就应该预期到计划和人员可能发生变动。 拿破仑·波拿巴曾经说到:“只要未开始与敌人当面交锋,就应该始终拟定作战计划。”这是我最喜爱的一句项目管理箴言,它同样适用于 EPM 计划。 考虑到一个项目可能会持续数月之久,计划中发生人员变动的几率很大。 因此应做好冗余计划。

EPM 系统不断演进。 如今,企业应用程序常常要考虑“总拥有成本”。 我认为我们应该在 EPM 项目计划中包含总应用程序生命周期。 您是否曾经考虑应该试试哪种版本的工具? 您是否曾经考虑过它又依赖于其他哪些工具? 这些工具的定期更新/升级情况如何? 您是否进行了自定义? 自定义培训的情况如何? 您是否考虑过,如果完成了部署,要如何迁移到新版本?

此外,还应进行专家的冗余规划。 如果您只有一名顾问,那么如果您在几个月内过渡到实施的新阶段,或者在团队中增加了新的关键成员,将会发生怎样的情况? 在那时,顾问是否能及时到位? (顾问通常从一个项目转移到另一个项目,因此这个问题的答案往往是否定的。)如果您在与顾问公司合作,您是否曾经与他们探讨过,在必要情况下,如何保留其员工的工作成果,让他人可以重复相应的工作?

将一切归于书面

最常见也最容易处理的挑战之一就是文档记录不够完善。 这是最容易在短期内频繁变动的元素,但此类文档的存在让您可以回头翻查书面参考资料,避免仅仅寄希望于“蝙蝠侠求救电话”的窘境。 编写文档后将文档随意塞到抽屉里的做法并不够。 文档应成为长期记录的一部分,您的 EPM 流程应在定期审查流程中查阅这些文档。 下面列出了我认为对于 EPM 环境最为重要的部分文档:

  • 业务案例   我不了解原始业务案例是什么,它听上去也没有什么吸引力,但我们常常会迷失方向,因此从许多角度而言,它是您拥有 EPM 环境的首要原因。 业务案例说明了预期组织获益有哪些;组织预期通过 EPM 系统获得的成果有哪些。 在我们接听“蝙蝠侠求救电话”时,最先提出的问题之一就是:“您希望这个系统能给您带来怎样的成果?”我们的提问对象不只是管理员。 还包括管理人员、用户和业务受益者。 每一方给出的最常见答案都有所不同。 这是因为他们遗忘了最初的业务假设。

  • 角色和职责    在最新版本的角色和职责中,我们常常会细化至个人姓名,但在不久之后,每个人在 EPM 系统中的角色就会被遗忘。 保留角色和职责文档让您可以在组织经历自然发生的人员变动甚至是组织结构变动时,调节参数,确定各人在 EPM 流程中的职责。

  • 流程指南和流程图    在我们着手拟定过程指南时,往往会遗忘流程指南和流程图。 过程手册为人们提供了“操作方法”步骤,但没有说明背景信息,没有说明这些步骤为何至关重要以及如何处理每个步骤的结果。 流程指南(最好是可视化的流程图)允许未来的管理者理解系统提供了哪些功能,从而使得系统可以 在未来更轻松地进行调整。

  • 系统选择标准    在顺应项目发展选择 EPM 系统和任何第三方工具时,应该让后续接班人能了解您的决策依据。 我们遇到过许多这样的组织,在系统部署完成后的 5 年、7 年甚至是 10 年后,他们偶然发现一个具有多种相关工具的系统,而且感到非常疑惑:“为何要采用那样的工作方法? 利用这种方法要简单得多!”而当时那些决策背后的理由无从考证。 在某些情况下,客户耗费数年时间采用极其复杂的方法开展工作,但利用现有工具的更新版本完全可以更轻易地完成这些工作。 他们无法轻松决定更换工具或使用更新版本,因为他们无法再了解多年前为何选择特定的工作方法。

现实中没有蝙蝠侠求救电话。

这句话就像是在说复活节兔和圣诞老人都是不存在的。 这些都完全是坏消息。 但现实如此,蝙蝠侠求救电话根本不存在。 但我确信,即便没有这种拥有魔力的电话,人们也会一直打电话给我,要求我打败“哥谭市最新出现的恶棍”。 如果您遇到麻烦,认为有必要联络专家,下面几条建议可能有所帮助:

  1. 仔细倾听您得到的建议。 付费聘请专家来为您提供建议,然后又认定自己比他们知道得更多,这种做法是绝对愚蠢的。 如果您想要征求建议,而且请到了专家,应该尽量耐心倾听他们的建议,然后至少要仔细考虑这些建议。 如果每一次蝙蝠侠前去为指挥官戈登解围时,戈登表示:“蝙蝠侠,既然你已经在这里了,请像我手下其他警员那样循规蹈矩地做事。”那么蝙蝠侠一定不会再前来救援。

  2. 蝙蝠侠能在 22 分钟内解决难题,但您很可能做不到。 如果您在联络专家,应该请专家对您说明,解决挑战需要多长时间。 在专家给出建议后,您可以选择不去修复问题,但 EPM 问题(即便是那些技术难题)绝不是几分钟内就能修复的。 毕竟蝙蝠侠必须要在 22 分钟内解决困境,将另外 8 分钟时间留给商业广告 - 这非常重要。

  3. 指挥官戈登从没有指手画脚地对蝙蝠侠说明过解决方法,只是陈述问题。 而我们在接到惊慌失措的 EPM 管理员的来电时,太多人表示自己知道需要安装补丁、撰写报告或是培训两名员工。 我总是会耐心地听完这些话,然后请客户陈述他们遇到的问题,就像他们之前对我陈述解决方案一样。 在拿起电话呼叫专家之前,一定要先想清楚您要提出的问题究竟是什么。

结论

您需要借助“蝙蝠侠求救电话”。 应该广泛征求意见。 不要只是询问一名顾问专家,不要只依靠一种可能的解决方案。 询问您的同事或业内同行,问问他们是否知道有人能接听这种“蝙蝠侠求救电话”,至少应该与两个人沟通。 了解两名专家如何以不同的方式解决您的问题 非常有帮助。 切记,蝙蝠侠确实非常棒,但还有其他许许多多的超级英雄可以依靠!

关于作者

Chris Vandersluis 是加拿大蒙特利尔的 HMS Software(Microsoft 认证合作伙伴)的总裁及创始人。 他拥有 McGill 大学的经济学学位,在项目控制系统自动化领域有着三十余年的丰富经验。 他是项目管理委员会 (PMI) 的长期成员,帮助创办了 Microsoft Project 用户组 (MPUG) 的蒙特利尔、多伦多和魁北克分会。 Chris 撰文的期刊包括《财富》、《Heavy Construction News》、《Computing Canada》杂志和 PMI 的 PMNetwork,他也是《Project Times》的专栏作者。 他在 McGill 大学讲授高级项目管理课程,经常在 北美和全球各地发表有关项目管理联盟职能的演讲。 HMS Software 是针对项目的时间记录系统 TimeControl 的发布商,自 1995 年起成为 Microsoft Project 解决方案合作伙伴。

可以通过电子邮件联络 Chris Vandersluis:chris.vandersluis@hms.ca

如果您希望阅读 Chris Vandersluis 撰写的更多 EPM 相关文章,请访问 HMS 的 EPM Guidance 网站 (http://www.epmguidance.com/?page_id=39)。

扩展你的技能
了解培训
抢先获得新功能
加入 Office 预览体验计划

此信息是否有帮助?

谢谢您的反馈!

谢谢你的反馈! 可能需要转接到 Office 支持专员。

×