“自上而下还是自下而上?”白皮书

本白皮书是我们的“一线快报”系列文章的一部分。它探讨项目管理、项目组合管理和任务管理,并比较与其有关的自上而下和自下而上管理实践。

若要下载本白皮书的 Word 版本,请参阅自上而下还是自下而上:白皮书 (Project Server 2010)

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

自上而下还是自下而上?

“我们需要项目管理… 嗯,我是说项目组合管理… 嗯嗯嗯,我其实是说我们任务管理… 见鬼,我们全都需要。”我经常听到这样的咆哮。混淆不清不是对这三个概念缺乏认知导致的,而是相似性导致的。

在 IT 行业工作多年的人士倾向于从技术角度看待事物,但有时结果不太如意。如果看看项目组合管理、项目管理和任务管理的数据,看起来可能非常相似。这三者全部都有 ID 字段、说明字段和开始与结束日期字段。自然应该把这三者联系起来。

或许不该联系起来呢?

我们一次讨论这三个概念中的一个。很容易发现它们的相似之处,但是这三方面存在根本的区别。

项目组合管理 - 自上而下的方法

“项目组合管理”对不同的人可能有许多不同的含义,但是最常见的含义可能是项目选择与制订优先顺序。这些原则最终可能影响组织中的所有人,但是高层管理者会对此流程非常感兴趣。管理层首先考虑的是特定的制约因素,如可用总预算和需要回答问题“我们可以用这笔钱做什么?应该用来做什么?”。如果项目组合管理流程十分成熟,此项分析可能不仅包括新观点,还包括现有项目。

显示多个项目的状态的仪表板

若要创建项目组合选择与优先顺序制订流程,管理层必须直面哪个业务条件推动公司前进,并就寻找新项目和现有项目时要关注的度量标准提前达成一致。投资回报率应不应该成为关键度量标准?或许我们应该关注对客户满意度、人员挽留或战略目标调整的影响。无论关键度量标准是什么,管理层都必须在了解项目如何推进项目目标和各项目与备选目标可能花费的资金的对比基础上,权衡各项目目标。

这个过程涉及大量分析,即使只是在脑中进行分析也是如此。使用项目组合管理软件时当然涉及大量分析。就算从软件传来的分析是报告或视图格式,做出有关优先级的最终决策时,实际上总是难免有些管理层级别的疏忽。此过程完成后,必须将最终结果发给各项目的项目管理执行人员。这些决策的影响是有些项目得到了资金,其他项目得不到资金,以便让可用资源对某些项目更倾斜,对其他的不太倾斜,并让某些项目的进度提前,让其他项目的进度延后。

项目管理 - 自上而下和自下而上

项目得到批准后,将一并转到其他领域。现在重点是更经典的项目计划视图。现在我们必须真正实现项目通过批准之前业务调整中描述的内容。

项目经理开始考虑项目范围和可交付结果。项目经理知道必须创建最终产品,不管是软件还是要进驻的建筑物。他们可能会考虑该项目的主要阶段,并创建工作细分结构。

图表中描绘的项目的主要阶段

将设计完成项目需要执行的逻辑步骤的关键路径。项目经理也知道自己需要负责生成的计划表,所以可以咨询项目主题的相关专家。项目经理将创建自下而上的项目视图,方法是逐个查看任务并将这些任务汇总到项目阶段,最终汇总到项目本身。此时项目经理也可以开始按技能、部门,甚至姓名分配资源。这些资源可能涉及成本。任务持续时间、所需资源及其费率的计算结果就形成了对项目自下而上的预估。

到目前为止,一切非常顺利。

项目的甘特图视图

但当我们审视自上而下的项目组合选择过程方法时,也有成本。实际上估计项目成本也是管理层在批准项目时考虑的业务调整组成部分。如果我们现在仅采纳主题相关专家汇聚的专业知识对项目形成的自下而上的预估,他们在选择项目时在管理层面又起到了何种作用?

这个问题提得好。在一些组织中,项目部门会提供大致的项目预估,以便针对该项目调整业务。在其他组织中,将项目放到项目组合流程中考虑之前,会创建完整的自下而上预估。这两种方法的共同问题是需要开展实际工作。完整预估可能需要大量工作,而项目必须得到批准才能获得资金来开展任何工作。所以在许多组织中,不过是管理层的有些人猜了一下项目所需成本。

所以过程看起来很复杂,实际上也许不过是如第二十二条军规般让人左右为难。把工作用在执行项目预估上还是用在项目的选择上以便将时间花在项目本身上,哪一项更重要?

此外,如果自下而上的预估与项目组合选择过程的预估不一致,该怎么办?如果前者更低,可能没有问题,但是如果工作无法按照项目组合选择人员预估的时间或预算完成,就会产生冲突。

您可能认为自然只需重新召集高层管理人员讨论问题,但是情况很复杂,并不是看起来那么简单。

首先,项目组合选择委员会成员很少是项目管理人员。项目组合选择委员会中几乎总是会有项目管理高层,但是该委员会本身级别极高,很难聚齐。其次,选择委员会可能会不定期聚会,但是可能很难再次召集大家讨论一个项目的成本与预估不匹配衍生的所有结果。最后,在有些企业文化中,如果向高层汇报他们对该项目的正确安排和预算的猜测完全错了,会妨碍个人的职业发展。

任务管理 - 自下而上的方法

考虑任务管理时,我们更倾向于从运营角度考虑,所以我们最容易想到的是日常议程和产品,如 Outlook。

任务列表的视图

假设现在我们独自工作或以某个小组成员的身份工作。我们无法从全局的角度来理解任务。我们只能看到我们需要处理的任务,或者是让我们的小组成员去处理的任务。这根本不是分析视角。只是有任务待完成,而个人承诺要完成。

就本质而言,任务管理非常简单。执行任务,完成后通知任务分派人任务已完成。以上所有功能均可在 Outlook 中执行。

相似数据的危害

有这么一种说法,“如果看起来像鸭子,叫起来也像鸭子,那肯定是鸭子。”这种说法对鸭子来说是成立的,但对基于任务的数据来说则未必。

请考虑面向项目的数据的以下三个级别:

  • 在项目组合级别,有一个项目,或许该项目下还有一些阶段。阶段信息可能有代码号、说明、持续时间、开始时间和结束时间。

  • 在项目级别,则是有一个项目,该项目下有一些任务。任务信息可能有代码号、说明、持续时间、开始时间和结束时间。

  • 在任务管理级别,则是有一个任务,任务信息可能有代码号、说明、持续时间、开始时间和结束时间。

它们看起来的确相同,但是实际上,看待数据的角度导致这些相当普通的记录发挥出大为不同的用途。

经常有人问我,“是否可以在项目组合视图与项目视图和 Outlook 之间移动数据。”

这个问题的简短答案是“可以”。

但在我们公司,我们提供技术建议时会问自己,“不要告诉我如何做,告诉我您为什么应该做。”

  1. 为了阐明这一点,我们想象一下下面的例子。我们建立一个完全集成的环境。最上端是按项目组合排列的项目列表。我们不但选择了这些项目,参与程度还深得多,项目在从 EPM 系统激活并成为现行项目之后也予以关注。因此,我们使用现有功能将项目和阶段定义从集成系统的项目组合端移到系统的项目端。数据看起来完全一样。

  2. 在我们的企业项目管理系统中,现在我们使用自上而下推动的项目组合定义中的原始阶段创建一个更详细的定义。这样如果更新项目,也会在项目组合系统中更新摘要。我们创建多项任务并分配大量资源。现在我们执行资源调配分析以确定多个项目的容量。

  3. 我们使用资源分配将任务和分配数据以 Outlook 任务或日历事件的形式发布给每位用户。用户不再需要访问“项目管理系统”。他们现在可以在自己的日程表中看到自己的数据。数据看起来和在项目列表中差不多,但是却链接到了更上游的项目组合视图。

  4. 这些任务的进度和 Outlook 中的可用性将随着相应工作的预估完成时间从个人反馈给项目管理系统。数据看起来和在另外两个系统中差不多,所以移动这些数据相对简单。

创建此类系统从技术上来说相当简单,只需使用现有工具并进行一些配置和开发。这样就可以表现得非常出色。

经常会有人问这种类型的结构到底是怎样的。就算我们可以做到,但是应该吗?

想象一下,在任务级别,有人早上要去看牙科急诊,她更新了 Outlook,说明当天上午没空。这对项目管理人员来说不是好消息,且对项目的连锁反应可能很大。现在项目系统认为本来安排今天上午完成的任务今天完成不了,将安排在明天中午完成。它尽职尽责地看看关键路径和该任务下游的所有任务,并将这些任务向后推 4 个小时。影响的任务可能成百上千。结果可能是项目的结束日期延后半天。其他项目也可能受到影响,因为为该项目工作的其他人员现在必须重新安排任务,而项目组合视图本身则不过是移动了几个像素。

如果把以上设想放到现实中来,问题会放大。千千万万的人整天都在改变,而 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 支持专员。

×