自上而下还是自下而上
本文是我们的“从战壕”集合的一部分。 它讨论了项目管理、项目组合管理和任务管理，并比较了与其相关的自上而下和自下而上管理做法。
若要下载本文的 Word 版本，请参阅 自上而下或自下而上：白皮书 (Project Server 2010) 。
若要查看更多文章，请参阅 “从战壕”白皮书。
自上而下还是自下而上？
“我们需要项目管理... 嗯，我的意思是项目组合管理... 嗯，我的意思是任务管理... 哦，哎哟，我们需要所有这些，“是我经常听到的战斗呐喊。 这三个概念的定义并不会导致混淆，而在于它们的相似性。
我们这些在 IT 领域工作多年的人倾向于从技术角度看待问题，有时它并不能很好地为我们服务。 如果我们查看项目组合管理、项目管理和任务管理中的数据，它看起来可能非常相似。 我在这三个中都有一个 ID 字段、一个说明字段以及一个开始日期和结束日期。 那么，链接这三者应该是很自然的。
也许不是。
让我们一次一个地了解这三个概念。 很容易看到它们的相似之处，但三种观点存在根本差异。
项目组合管理 - 自上而下的方法
人员“项目组合管理”可能意味着很多不同的事情，但最常见的含义可能是项目选择和优先级。 这些原则最终会影响组织中的每个人，但高级管理人员非常感兴趣。 管理从某些限制开始，例如总可用预算，以及需要回答“我们可以和应该用这笔钱完成什么？”如果项目组合管理过程足够成熟，此分析可能不仅包括新的想法，还包括现有项目。
若要创建项目组合选择和优先顺序流程，管理层必须面对驱动公司的业务标准，并提前就查看新项目和现有项目时要考虑的指标达成一致。 投资回报是否应是关键指标？ 也许我们应该考虑对客户满意度、员工保留或与战略目标的一致性的影响。 无论关键指标是什么，管理层都必须权衡每个项目计划，了解该项目如何推进这些目标，以及每个项目与可以花费资金的备用计划进行比较。
这是一个高度分析的过程，即使它是在头脑中完成的。 使用项目组合管理软件时，这当然是高度分析的。 即使从软件进行分析到达报表或视图，实际上也总是有一些管理级别的监督，其中对优先级做出最终决定。 完成此操作后，最终结果必须传递给将执行每个项目的项目管理的人员。 这些决定的效果将是资助一些项目而不是资助其他项目，使一些项目而不是另一些项目更优先地获得资源，并提前一些项目的时间表，并拖延其他项目。
项目管理 - 自上而下和自下而上
项目获得批准后，将完全进入不同的领域。 现在，更经典的项目计划视图成为焦点。 现在，我们必须在获得批准之前，实际构建我们在业务理由中描述的东西。
项目经理开始考虑项目范围和可交付结果。 项目经理知道必须创建的最终产品，无论是一个软件还是一个随时可供占用的建筑物。 他们可能会考虑该项目的主要阶段，并创建工作分解结构。
设计完成项目所需的逻辑步骤的关键路径。 项目经理还知道，他或她将负责生成的时间表，因此他或她咨询项目中的一系列主题专家。 项目经理通过逐个查看任务并将这些任务汇总到项目阶段，并最终汇总到项目本身，从而创建项目的自下而上视图。 此时，项目经理也可能开始按技能、部门甚至名称分配资源。 这些资源可能具有相关的成本。 计算任务工期、所需资源及其费率的结果可让我们对项目进行自下而上的估计。
目前为止，一切都好。
但是，当我们查看项目组合选择过程的自上而下的方法时，也存在成本。 事实上，项目的估计成本是管理层在批准项目时考虑的业务理由的一部分。 如果我们现在只是从主题专家的结合专业知识中获得项目自下而上的估计，那么他们在执行套件的项目选择中使用了什么？
这是一个很好的问题。 在某些组织中，项目部门将为项目提供粗略估计，以便为项目创建业务理由。 在其他组织中，在项目组合过程中考虑项目之前，会创建完整的自下而上估算。 这两种方法的问题都在于它们付出了努力。 完全估计可能需要花费大量精力，但项目尚未获得批准，以资助任何工作。 因此，在许多组织中，管理人员只是猜测该项目的成本。
因此，该过程看起来都是集成的，但这里可能有点 catch-22。 首先，为了能够将时间花在项目上，在估算或选择项目上花费了哪些工作？
此外，如果自下而上的估计值与项目组合选择过程的估计不匹配，会发生什么情况？ 如果估计值较低，则可能没有问题，但如果工作不可能在项目组合选择人员估计的时间或预算中完成，则存在冲突。
你可能会认为，自然的事情是重新召集高级管理层，只是讨论问题，但在许多情况下，这并不像看起来那么容易。
首先，项目组合选择委员会很少是项目管理人员。 高级项目管理人员几乎总是包括在项目组合选择委员会中，但团队本身通常是非常高级的高管，他们发现组织时间在一起是具有挑战性的。 其次，遴选委员会可能会不定期开会，因此，让他们回到一起讨论一个项目与估计成本不匹配的所有后果可能是一个很大的挑战。 最后，在一些公司文化中，必须向高级管理人员传达他们的猜测完全错误的消息，这不会是促进职业发展的举措。
任务管理 - 自下而上的方法
当我们想到任务管理时，我们倾向于非常可操作地思考，这通常将我们带到日常议程和 Outlook 等产品中。
现在，我们在个人或小型团队成员级别工作。 在上下文中看不到任务。 我们可以看到我们承诺的内容，或者我们要求团队成员承诺的内容。 这根本不是分析视图。 有任务要做，个人已经承诺做。
其核心是，任务管理非常简单。 你执行任务，当你完成时，你告诉给你任务的人，它已完成。 Outlook 中已提供此功能的所有功能。
类似数据的恶作剧
有句谚语，“如果它看起来像鸭子，像鸭子，它一定是鸭子。这适用于鸭子，但对于基于任务的数据并不总是如此。
让我们考虑以下三个级别的面向项目的数据：
在项目组合级别，我们有一个项目，也许还有该项目下面的阶段。 阶段信息可能包含代码号、说明、持续时间、开始日期和结束日期。
在项目级别，项目下有一个项目和任务。 任务信息可能包含代码号、说明、工期、开始日期和结束日期。
在该任务管理级别，我们有一个任务，任务信息可能有代码号、说明、持续时间、开始日期和结束日期。
它们看起来确实相同，但事实上，数据的角度使得每个相当常见的记录都有一个非常不同的用途。
经常被问及：“是否可以将数据从项目组合视图移动到项目视图，然后移回 Outlook。
这个问题的简短回答是“是的”。
但在我们的公司，我们有一个口头禅，当我们提供技术建议时，我们对自己说：“不要告诉我如何做，告诉我为什么你应该这样做。
为了说明这一点，假设此示例。 我们创建一个完全集成的环境。 在规模最顶层，我们有按项目组合组织的项目列表。 我们不仅选择这些项目，还会进一步集成，在从 EPM 系统中激活到实时项目中后，对其进行了进一步的集成。 为此，我们使用已有的功能将项目和阶段定义从集成系统的“项目组合”端移动到系统的项目端。 数据看起来完全相同。
在企业项目管理系统中，我们现在使用从上到下推送的项目组合定义中的原始阶段进行更详细的定义。 这样做可以在我们更新项目时在项目组合系统中更新该摘要。 我们执行许多任务并分配许多资源。 我们现在执行资源调配分析，以确定跨多个项目的容量。
我们使用资源分配将任务和分配数据作为 Outlook 任务或日历事件推送到每个用户。 用户不再需要转到“项目管理系统”。 他们现在可以在日常议程中查看其数据。 数据看起来与项目列表中的数据一样，并进一步链接到项目组合视图的上游。
这些任务中的进度和 Outlook 的可用性将从个人转移到项目管理系统，并估计何时完成这项工作。 数据看起来就像在其他两个系统中一样，因此移动数据相对容易。
使用目前可用的工具以及一些配置和开发，创建此类系统在技术上非常简单。 它会展示得很漂亮。
我们经常被要求提供这种类型的结构。 但是，即使我们可以做到这一点，我们应该吗？
想象一下，在任务级别，一个人早上请假进行紧急牙科检查，并更新她的 Outlook，她今天早上将不可用。 这对他来说是个坏消息，但对这个项目的连锁反应可能是巨大的。 现在，项目系统计算出原定今天上午完成的任务不会在今天完成：它只会在明天中午完成。 它尽职尽责地查看关键路径和从此路径下游执行的所有任务，并将它们向前推进四个小时。 也许有数百个任务受到影响。 结果可能是将项目的结束日期推送到半天后。 其他项目也会受到影响，因为从事此项目的其他人现在必须重新排列其任务，项目组合视图本身向前滑动几个像素。
如果我们实时想象这一点，问题就放大了。 成百上千的人一整天都在进行更改，EPM 视图、资源调配视图和项目组合视图通过效果来回进行动画处理。
实际上，这不会发生。 首先，无情的牙科病人将在中午回到她的岗位上，并可能在几个小时后今晚工作，以确保这个关键的道路被赶上，所有将在早上回到正轨。
此外，即使数据看起来相同，也永远不会以这种方式集成，因为正是这种效果。
数据上下文 - 透视很重要
查看数据时，数据的上下文至关重要。 根据应用程序的角度，从记录到记录架构来看可能看起来相同的数据用于非常不同的用途。
在自上而下的投资组合视图中，我们正在做出战略决策，确定将资源投入到何处，以最大限度地提高我们的投资回报。 我们可能会做出项目经理不会做出的选择。 在我自己的组织中，我们有时选择了完全超出现有技能集的项目，因为我们知道，我们很难完成这些技能，但这样做是因为我们想要提高这些技能。 投资回报不是有效的安装，它是经过培训的安装人员。 这是一个分析视图。
在战术项目视图中，我们正在做出操作决策，确定在何处获得人员的最佳吞吐量，并尽可能快速高效地完成项目。 项目经理始终关注未来。 过去发生的事情只对项目经理感兴趣，因为它能改善他或她对未来的看法。 这也是一个高度分析的视图。
在任务管理视图（如议程）中，我们不是分析的。 议程是承诺制度。 我们向自己或他人保证，我们将在特定时间做一件特定的事情。 这可能适合分析视图。 它可能不会。
混合这些观点和上下文而不了解影响可能会导致混乱。
自上而下还是自下而上？
像往常一样，没有正确的答案。 项目管理系统的某些方面确实需要从下到上。 归根结底，是个人将生成任何项目。 但有些决定是，而且应该从上而下做出，而且是自上而下的必要条件。
当你保持项目管理范例的每个级别的用途的区别时，可以更清楚地了解其中一些系统是否应该真正集成。 如果一个级别的过程和思维没有直接的好处，从另一个层次完全整合，那么集成不是最好的发挥。 请务必了解此类集成在实际上下文中的工作原理，以及一个级别的频率和详细信息是否为另一个级别提供任何价值。
例如，如果指导委员会每季度只召开一次会议，就哪些项目要推进和哪些项目不向前发展做出重大决定，那么每天、每周甚至每月更新他们的观点有什么好处呢？
企业项目管理资源调配算法是否确实需要查看个人的牙科预约，或者是否足以了解该个人的大致可用性？
然而，如果我们可以直接将作业发送到个人的议程或时间表屏幕，那么他们每天需要进入不同的系统和界面来查看相同的数据，这是否会节省他们几分钟的时间？
因此，在某些情况下，自上而下是正确的，而自下而上是正确的。 你必须看看自己的情况，看看集成这些工具和概念在将这些工具和概念结合在一起之前，在哪里可以回报正确的红利。
关于作者
Chris Vandersluis 是总部位于加拿大蒙特利尔的 HMS Software（Microsoft 认证合作伙伴）的总裁兼创始人。 他拥有麦吉尔大学的经济学学位，在项目控制系统自动化方面拥有30多年的经验。 他是项目管理研究所 (PMI) 的长期成员，并帮助创立了 Microsoft 项目用户组的蒙特利尔、多伦多和魁北克分会 (MPUG) 。 克里斯撰写的出版物包括《财富》、《重型建筑新闻》、《加拿大计算》杂志和PMI的PMNetwork，他是《项目时报》的常任专栏作家。 他在麦吉尔大学教授高级项目管理，并经常在北美和世界各地的项目管理协会职能部门发表演讲。 HMS Software 是 TimeControl 面向项目的计时系统的发布者，自 1995 年以来一直是 Microsoft 项目解决方案合作伙伴。
可通过以下方式联系 Chris Vandersluis： chris.vandersluis@hms.ca
若要阅读 Chris Vandersluis 与 EPM 相关的更多文章，请参阅 HMS 的 EPM 指南网站 (https://www.epmguidance.com/?page_id=39) 。