“制定 EPM 部署路线图时把握方向”白皮书

本白皮书是我们的“一线快报”系列文章的一部分。它描述了在计划实施 EPM 时,如何确定企业项目管理部署“路线图”。它从独特的角度描述了在规划部署路径时要考虑的因素。

若要下载此白皮书的 Word 版本,请参阅在制定 EPM 部署路线图时把握方向

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

制定 EPM 部署路线图时把握方向

在我的上一个专栏中,我谈了使用分阶段的方法为部署 Microsoft 企业项目管理 (EPM) 解决方案制定计划。今天,我们将着手讨论如何使 EPM 部署路线图成为项目计划的一部分。

如果您接触过 Microsoft Live 地图,您就会知道方向需要两个要素:一个目标和一个原点。当我们把这种类比套用到 EPM 部署时,我们就必须用相似的方式思考:

  1. 从技术、流程和人员角度定义的原点

  2. 从业务角度定义和划分优先级的目标

我们还可能要定义某种“中途小站”或称中间站,在那里,你们可以重聚、拍照、欣赏一会景色、并为下一段旅程补充补给。

在制定路线图或方向时,通常有两个尺度。我们将下一段旅程制定得非常详细,一直细到分段路线。然而同时,我们可能将整个旅程的概要地图保持得更加简略,以便在整个旅程的背景下看待当前旅程。在项目管理术语中,我们称之为“滚动波浪规划”。

“方向”

在制定 EPM 部署路线图时,我们总是先从 EPM 成果的角度,确定公司要实现的愿景或意图。这就像 Microsoft Live 地图那样,给我们定下了需要前往的目标。

显示从西雅图到蒙特利尔的路线的地图

如果我们直接问“您要的是什么?”,那么答案几乎无一例外地涉及解决方案。人们很可能说“我需要一份类似这样的报告”或者“我们公司需要投资组合分析”。

对于我们这些从事解决方案业务的人来说,我们知道这样的设计说明充满了危险。我们训练我们的咨询师倾听客户,而客户将他们的问题描述成解决方案。我们会说“那是问题的解决方案,而不是问题。我们还是来定义问题吧。”

所以我们倾向于不要问“您要的是什么?”实际上,在确定愿景时可能有用的问题包括:

“您现在无法或很难作出什么样的业务决策,而制定这样的决策可能因为这种 EPM 部署而变得更加容易?”

或者:

“通过这样的 EPM 部署,您认为组织的哪个方面可以通过吞吐量增加或工作量减少而变得更加高效?”

现在,我们应该向谁提出这些问题?那当然是制定这些决策的人!如果您开着一辆坐满孩子的小面包车,然后回头问他们去哪儿,你一定会得到 50 种回答。

同样的原因,我们需要确保组织的决策者成为这一过程的关键参与者,否则我们就会碰到这样的风险:我们选择的方向不是“驾驶员”准备走的方向。此时让高级管理层参与 EPM 路线图制定过程还有另外一个好处。除了作为关键参与者来选择 EPM 部署应走的方向外,他们还能对项目规模有所了解。阻碍成功部署 EPM 的一个最常见而又最困难的难题在于长期的管理层支持。某些高级管理人员未考虑到这会在多大程度上改变现有惯例和规程,这可能引起多大的混乱,哪怕只是暂时的。他们可能还不了解像 EPM 这样洗心革面的项目需要投入多大的精力。

在我们与高级管理层、项目经理以及可能是一线人员合作的过程中,我们尝试将业务决策或业务效率与流程和技术联系起来。有没有为了满足这种要求而必须创建的流程?流程需要做到什么?有没有现有或必须创建的系统功能来服务于这种业务决策?这种功能需要产生什么结果?

基本系统分析是这一阶段的关键。我们从业务决策“输出”开始,尽力回到制定那些决策所需要的数据元素。在有些情况下,我们发现基本数据根本不存在,这导致这些路线图元素被视为“高风险”。最终,我们需要引入数据收集,我们需要以新的格式或结构收集数据来掌握这些新的数据元素,在此之后,我们才能考虑实现更好的业务流程,某些情况下,这种要求可能难以企及。

在结束制定目标的过程之前,我们还有一件事要做,那就是确定最终愿景不同元素的优先级。非常常见的情况是,人们在路线图制定过程开始时认为,只要用一种方式就能确定优先级,但在要实际记录优先级时却发现,情况非常不一样。有意思的是,当每个人都同意目标所包含的目标点时,对于那些点应具有最高优先级,他们的观点惊人的一致。

对于方向,我们还需要一个原点,我们通过详列组织目前在哪些方面与我们选择的目标有关来找出原点。

显示从西雅图到蒙特利尔的路线的地图

我们要考虑现有人员。他们是否受过适合其特定职责的项目管理培训?我们是否有具备足够经验的足够人员来实现已经设定的目标?请注意,这里我们必须考虑多项指标,因为不同的人在最终企业项目管理流程中将发挥不同的作用。如果员工实际上不负责创建计划,那么培训每个员工都成为项目计划员没有意义。默认情况下,我们考虑四种角色:管理员、项目经理、个人资源和执行官。如果涉及考勤表,我们还要考虑主管作为第五角色。当然,根据我们在最初愿景设想过程中定义的目标,这些角色可能非常不一样。这会深刻改变详列技能清单的过程,这也是为什么我们总是先确定目标再考虑原点的原因。

我们还要考虑现有流程。有没有已经规定或明文记录的项目管理流程?它是如何维护的?谁负责?如果已经建立了项目管理办公室,那么会有很多工作集中在那里。毕竟,如果现有规程和流程已经很有效,那么创建新规程就没有意义。我们可能根据 EPM 环境的最终目标,详列当前项目管理流程内外的现有流程。

例如,我们可能决定合同管理将成为新的 EPM 环境的重要元素,而在以前,在此组织内,它从未成为项目管理流程的一部分。然而,如果再考虑得更深一点,我们会发现,组织对于管理文档有很强的控制,而且有已在移动文档(可能是在 SharePoint 中)的现有工作流。这对我们来说是一个理想的流程,我们可以采纳此流程,如果需要,还可以调整它,以确保它在这方面提高新的企业项目管理环境的能力。这样做可以一举三得。第一,我们无需再花力气创建新流程。第二,我们知道,人员已有以此方式使用流程的技能和习惯,这意味着无需培训或花力气让人员遵守流程。第三,我们没有了尝试创建单独流程的困境,单独的流程可能与管理文档(例如合同)的现有流程不相称。

我们知道,我们最大的挑战之一是按流程行事。问题不在于构建系统,而在于让每个人都使用系统,并始终如一地使用系统。我们更多地采用已融入组织中的现有习惯、惯例和规程,遵守流程就会更容易。

最后,您需要详细列出技术平台。由于 Microsoft EPM Solution 是在技术平台的基础上建立的,因此很可能找到某些现成的技术,但是也有可能,为了让您设计的解决方案起作用,组织必须升级其部分平台。SharePoint 和 SQL Server 是部署 Microsoft Office Project Server 明显需要的元素,但是您可能还需要检查浏览器兼容性(是不是每个人都使用最新版的 Internet Explorer?)、安全状态(系统是不是对外?)、部署了哪个版本的 SQL Server(是否已在使用 OLAP Services 或 SQL Server Reporting Services?)。您可能还要考虑需要与之对接或集成的其他系统。如何访问投入实际生产的这些系统?

计划系统的规模也可能使我们有必要考虑硬件、网络和其他基础结构元素,以确保系统在送达时就具备所需的结构。

与任何企业系统一样,您需要同时规划生产和暂存区域,这样才能在实验室中创建更新和增强,而不是经常在真实系统上创建。您还要为试点阶段或概念证明阶段做规划;我将在下一个专栏更多地谈谈这方面的内容。

“重新计算路线”

当我汽车中的 G.P.S. 装置发现我错过一个转弯时,一个非常好听的女声会说“正在重新计算路线”。过了一会,地图中的线路发生改变,我得到了新的方向。在 EPM 部署中,我们需要随时准备好面对绕行道或转弯因修路而被封。也许我们错过了高速路出口。我们如何应付重新规划路线?在走错路时,我们需要问清楚两点:第一,您仍要去同一个地方吗?第二,从这里怎么才能到达那里?对于这个问题,我最喜欢的一句项目管理名言是拿破仑·波拿巴曾经说过的“作战计划要持续到与敌接触。”

地图显示从西雅图到雷德蒙德的路线

在 EPM 部署中,我们如何采用这条原则?首先,您需要一个指标来确定是否已经脱离规定路线。如果有一个工作组成员明天紧急预约了牙医看牙,并且有四小时不在办公室,那么我们是不是应该让这场突发事件改变所有下游任务、重新安排每个人从明天中午到项目结束的时间表,然后给每个人发电子邮件,告诉他们新的任务时间?

当然不是。

在涉及几十个人,为期六个多月的项目中,一个人缺席四小时不会迫使我们改变路线。启动任何类型的企业项目需要设置可接受进度的阈值。航天和国防界最近为此找到了一个新术语“绊发线”,这个词非常形象。我们可以确定什么样的条件会提示我们需要重新计算路线。有多个典型的指标或度量可以考虑。首先,如果预计完成成本偏离原预算 X% 以上,那么这可能构成项目计划审查。您也可以用人工时间或金钱来衡量成本。任何方式都有效。也许预测完成日期与原计划的完成日期相差 X 天,那么这也可能构成项目计划审查。

您也可以将特定里程碑缺少一定天数以上定为绊发线,或者将某些成为现实的风险定为绊发线,或者将某个关键项目团队成员(如执行发起人)的变更定为绊发线。设置某些条件比让条件完全正确更重要。另外请记住,在项目的整个生命周期中,您需要对照这些条件进行测量,所以如果您选择了 50 或 100 个不同的指标,那么最终您花在测项目上的时间可能比做项目还要多!

一旦确定您已偏离规定路线,那么回到正轨的最佳方式是执行项目计划审查。我们建议引入最初帮助确定目标的原高级管理层的代表,以及最初帮助详列各项清单的项目管理团队的代表。项目计划审查可能追查为什么项目偏离正轨,为什么会触发某根绊发线,从而陷入追责的怪圈。这样的事情可能起到严重的反效果。我们建议将重点放在下面的问题上:

  1. 发生了什么情况?

  2. 我最终走到了哪一步?我们当前的原点在哪里?

  3. 我们是否仍在为原来的目标而努力,或者有没有令人信服的理由来审查该流程,甚至重做愿景设想过程?

  4. 我们是否需要重新设定什么中间里程碑或中间阶段?

  5. 我们是否需要改变任何项目团队?

  6. 我们是否需要重新设定任何绊发线指标?

我们发现效果适得其反的问题包括:

  • 我们目前遇到的是谁的过错?应该责备谁?

  • 我们如何“重回”正轨;回到原来的计划?

项目计划审查最常见的原因是组织的优先级发生变化。例如,原定于第 3 阶段的项目被要求提前到第 2 阶段。这通常是组织内健康活力的征兆,也是人们开始认真思考部署 EPM 系统的意义的结果。

坏天气

在您准确长途驾驶之前,您可能会看看天气频道(或 weather.msn.com),确保没有恶劣天气影响您的行程。风险是生活的一部分。请记住,如果没有风险,也就不需要项目经理!为最明显的风险做好规划并不是复杂的过程。可以从愿景设想过程的最初阶段开始,然后在考虑您所设计的目标的各个元素时,问问整个小组,达到此目标会有哪些障碍。某些情况下,风险会非常巨大。组织需要一个特定的结果,可到头来只发现,他们从未收集到产生该结果所需的原始数据,而且收集这些数据可能遇到相当大的阻力。这种情况司空见惯。

显示蒙特利尔天气预报的 MSN 页面

例如,有一家组织需要资源产能规划。这需要所有项目人员的所有资源可用性的完整核算数据,以及可以施加于这些人员的所有可能的工作负载的完整核算数据。当我们询问是否有这两种数据时,他们说当然有,但是只有该组织五分之二部分的数据。然后当我们发现所缺的五分之三部分的数据甚至在愿景设想会议上都未提供过时,我们说“让我们猜一下。你们遇到的资源产能规划问题就在那三个部门吧。”很自然,就是那样的。我们不得不把请那些部门的部门领导人参与进来当作该项目一个单独的阶段,而且视其为风险很高。

当您在详列清单过程中继续与项目管理和一线人员合作时,可以在会谈时询问他们能够识别的任何风险。

一旦确定了风险,整理风险就很重要。如果您以前没有整理过风险,那么最基本的信息就是最有价值的信息。包括:

  1. 风险的简短说明

  2. 它可能影响项目的哪个方面或哪个阶段

  3. 如果设定的条件变成现实,风险严重性有多大

最后,您可以做的最重要的事情之一是,增加一些缓解风险的细节。只要考虑到风险就可以大大缓解风险。但在 EPM 部署仍处于襁褓阶段时,输入在项目期间如何应对特定风险的提示会显得非常难能可贵。人们常常在风险变成现实时才凭一时冲动匆忙作出决策。在冷静的头脑占上风时想出来的提示可能很有用。

让我们自己造车自己开

这里有一条有关路线图制定的提示,它能让您大受裨益:使用 Project Server 和 Microsoft EPM Solution 帮助制定和管理路线图规划。也许这显而易见,但是鲜有组织这样做,以至于我们不得不在这里提一下。

显示项目可交付结果列表的 SharePoint 网站

有一个高级经理曾经跟我说,他的项目人员问他,他是不是觉得使用 Microsoft EPM 解决方案来部署 Microsoft EPM Solution 并不过分。“如果我们为了谋生而造喷气机,我们不会开着飞机去上班,”他们说。“你在开玩笑吗?”他反应道。“如果我可以开着喷气机去上班,我就会天天这样做!”

实际上,让 EPM 部署团队使用 Microsoft EPM Solution 是很好的想法。

安装 Project Server 和 Microsoft EPM Solution 的其他元素不是很大的技术难题,只要绝对最少的配置,就能在几天内让身为用户的小型部署团队建起并运行整套系统。这对将成为部署支持者的那些用户来说非常有利,这可以在系统安装到大量工作人员的桌面之前,就让这些用户熟悉系统的使用和优点。

此部署不能作为生产环境。您几乎肯定要进行配置和自定义来实现最初目标的愿景。在 Project Server 的 EPM 部署迭代中,您几乎肯定不会从事多项目调度或资源产能规划或投资组合优化之类的工作,但是您可以交出可带来很大优势的系统。我们建议:

  1. 作为已发布项目做一个滚动波浪计划。

    滚动波浪计划详细突出当前阶段,而更概要地突出未来阶段。这可以让团队成员知道现在需要做什么工作,同时仍让他们在更大的背景下看待项目。

  2. 在项目工作区中管理愿景文档。

    项目工作区是与项目相关的 SharePoint 网站,默认情况下它包含一个问题、风险和文档板块。为什么不把 EPM 部署项目的所有项目文档都放到这里,并开启 SharePoint 的版本控制,这样就总是能回到最初的版本?

  3. 将里程碑签核和“门”放入项目工作区可交付结果。

    这是一个简单的任务列表,可以将其链接到 Project Server 中的任务。它将提供非常高端的项目视图,同时也是易用的工具,可以用于阈值管理,以确定何时“脱离正轨”。

  4. 将变更管理作为问题放入项目工作区。

    变更管理是技术项目的大难题之一。在新的项目变更建议提出时,将其作为待管理的潜在变更放入问题区域。将几个字段添加到此区域,就可以随时列出高优先级项目及其负责人。

  5. 将项目风险放入项目工作区。

    除了文档和问题外,工作区的风险区域是添加风险和缓解计划的理解位置。实际上,默认屏幕提供了可随时供您使用的所有字段。

我们到了吗?

“快了。我们很快就到了。”

EPM 部署可能将组织引向很多不同的方向,所以无法简单地发布适合每个人的默认计划。但是只要花几分钟搜索 Internet,您就会找到很多项目不同部分的可行示例。如果我总结上面的路线图实践,您可能最终会得出一个分成几个明显阶段的项目:

  1. 路线图实践

    1. 愿景构想(选择目标)

    2. 现有流程的清单(识别原点)

    3. 现有人员的清单(识别原点)

    4. 技术清单(识别原点)

  2. EPM 团队的 EPM 解决方案部署

  3. 第 1 阶段

    1. 设计

    2. 配置、自定义、文档

    3. 试点

    4. 培训

    5. 铺开

    6. 回顾第 1 阶段,并根据需要调整第 2 阶段

  4. 第 2 阶段

  5. 第 3 阶段

  6. 第 4 阶段

  7. 项目收尾

将路线图实践应用到您的 EPM 部署可以很快将体验从混乱变成可控。要记住,先选择目标,接着想出原点,然后绘制两者间的路线。

旅行愉快!

关于作者

Chris Vandersluis 是总部位于加拿大蒙特利尔的 HMS Software(Microsoft 认证合作伙伴)的创始人。他拥有麦吉尔大学经济学学位,在项目控制系统自动化方面有 30 多年的经验。他是项目管理协会 (PMI) 的长期会员,并帮助建立了 Microsoft Project 用户组 (MPUG) 的多伦多蒙特利尔分部和魁北克分部。刊登过 Chris 撰写的文章的出版物包括《财富》、《Heavy Construction News》、《Computing Canada》杂志以及 PMI 的 PMNetwork,他还是 Project Times 的专栏作家。他在麦吉尔大学教授高级项目管理,并经常在北美和世界各地的项目管理协会聚会上讲话。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 支持专员。

×