他们说他们想要一个解决方案

本文是我们的“从战壕”集合的一部分。 它描述了在计划项目时可能面临的一些常见挑战。 本文介绍了在尝试确定任务应使用多长时间以及应该有多少个任务来优化项目计划时，会想出最佳方法。 本文讨论了不同行业通常需要不同类型的计划， (例如软件开发、EPM (工程、采购和施工) ，以及工厂关闭) 。 它还讨论了选择项目解析 (的几个因素，例如项目长度、涉及的资源、资源的管理或划分、收集数据所需的速度和工作量，以及数据更新计划) 。

若要下载本文的 Word 版本，请参阅 他们说他们想要一个解决方法：白皮书 (Project Server 2010) 。

若要查看更多文章，请参阅 “从战壕”白皮书。

他们说他们想要一个解决方案

与向披头士乐队的标题道歉，今天的主题是你的项目的解决方案。

有很多关于如何制定计划的材料，但最关键的课程之一是很难获得 — 项目计划中应包含多少个任务，每个任务应该有多长？

我经常遇到看似不可能复杂的项目计划，或者项目经理似乎无奈地查明日程中的麻烦，因为日程表处于这样的摘要级别。 我见过一个长达一百多年的项目， (是的，真的) ，长度非常合适，其中有些任务长达数十年。 我还看到项目计划只持续了一个小时或更短的时间，这是完全合适的，其中一些任务只持续了一分钟。 我看到的项目只有几个任务，其他项目的任务超过 100，000 个。

我们今天使用的软件可以处理数千个任务和广泛的持续时间。

那么，正确的方法是什么？

任务应该有多长，需要多少时间才能优化项目计划？ 我将这称为项目的解决方案。

不同人的不同笔划

由于不同行业、不同类型的项目和不同情况的要求可能不同，因此让我们看看如何确定日程中要放置多少个任务以及任务应保留多长时间。

不同类型的项目自然需要不同类型的计划。 让我们考虑三个不同的示例：

1. 软件开发。 许多软件项目都有共同的特点。 虽然每个软件项目都是独一无二的，但通常有一个设计阶段、一个编程阶段、一个质量保证阶段、一个文档阶段和一个部署阶段。 软件项目通常以周或月为单位，适合一天到几周的任务。 此处的资源分配通常分配给单个级别。

   那些采用敏捷开发软件流程的人希望短一两周的“冲刺”，并在该冲刺中放置持续时间较短的任务，但总体项目工期仍以周为单位。 稍后我们将详细介绍敏捷开发。

   

2. EPC - 工程、采购和施工。 EPC 项目是关键路径计划方法开始的地方。 在这类项目中，正在开发一些非常大的东西。 它可能是一个大型防御项目，如北极星导弹项目，为PERT图提供了开始，也可以是近海石油钻机、新船或发电厂。 在此类项目中，有一个工程阶段，其中构思了完成的项目。 工程阶段通常具有一些以前从未设计过的方面。 采购阶段将考虑查找、承包和管理项目要素的供应或分包的交付。 在“构造”阶段，将构建最终产品，然后委托使用。 我们通常将 EPC 项目计划考虑在几个月或几年内，其活动持续时间从几周到几个月不等。 在这样的项目中有 5，000 到 20，000 个任务并不罕见。 这里的资源计划几乎总是分配给技能级别而不是个人， (只是为了增加乐趣，) 可能有许多子项目被制作成一个计划或主项目，以便于管理。

   

3. 工厂关闭。 为工厂关闭和维修周转执行项目计划时，你将在最具挑战性的计划环境之一工作。 工厂关闭进行维护有两种形式：计划内和紧急。 让我们暂时将紧急类型放在一边：这是一个世界本身。 计划关闭工厂的持续时间在很大程度上取决于工厂的类型。 例如，核电站机组可能会在12个月内进行“快速”的关闭和周转。 炼油厂可能持续4-6周。 但我觉得最有趣的工厂项目时间表类型是制造厂，如钢厂，造纸厂或类似的东西。 全世界有成千上万的此类植物，每年左右必须进行定期维护。

   这些情况的关闭成本通常以机会成本衡量：在工厂闲置和进行维护时不会生产的产品成本。 此成本以小时为单位，成本可能高达每小时 150，000 至 250，000 美元！ 因此，完成工作的压力是每分钟。 在这种情况下，关闭通常持续 5-8 天，一天的延迟以数百万为单位计算。 如果你只习惯于更长、更传统的计划，你可能会认为在短短几天内，“通常有多少个任务？”，但这种关闭有 2，000 到 4，000 个任务，每个任务持续 15 分钟到几个小时，这并不罕见。 此处的资源分配由技能完成，但很少对人员进行资源调配。 由于每小时的成本如此之大，如果你把更多的人放在项目上并不重要，只是赶紧完成它。 在这种情况下，资源调配通常针对高度受限的瓶颈执行。 例如，“我们只能在电气室容纳两个人，因此必须单独管理”。

   

好吧，我们现在有三种示例，还有更多示例，但这三种示例将服务于讨论的目的。 在类型 1 (软件开发) 中，我们得到的任务通常为一天或两天到两周。 在类型 2 (EPC) 中，我们得到长达数周或数月的任务。 在类型 3 (工厂关闭) 中，我们得到的任务单位为 6 分钟 (1/10 小时) 、10 分钟、15 分钟 (1/4) 1/4，最长为几个小时。 很明显，在某些情况下，短任务有意义，而长任务则更合适。 遵循相同的逻辑，有时有大量的任务是有意义的，有时它只是没有。

选择项目解决方案的因素

通过这三个区别，很容易看到，在六天的关闭计划中，为期两个月的 EPC 项目任务看起来很荒谬，并且 15 分钟的任务在 EPC 或软件项目中将不合时宜。 但是，除了提到这篇文章并说，“Vandersluis说这是一个软件项目，所以任务只能持续1-10天”， (，请不要这样做，) 项目的哪些特征告诉我们要选择哪种级别的分辨率？ 让我们看一下几个明显的：

项目需要多长时间？

让我们从最明显的开始。 如果项目预计会持续数天（例如在关闭示例中），则具有几天长的任务毫无意义。 当我们考虑划分范围时，从自上而下的方法开始通常很高效。 使用工作分解结构思维。 从主要组件开始。 考虑不低于 4 个且不超过 20 个项目。

这是规则吗？ 不，当然不是。

这是常识。 不到 4 个让你想知道为什么你把工作分开了， 超过 20 个太难在一个人脑子里一次。 就我个人而言，每个 WBS 元素不超过 8 个项目，这是因为我几年前读到的一篇文章建议八角形是头脑可以立即识别的最复杂的简单形状。

想想一下。 可以识别一个圆、一个三角形、一个正方形、一个五角形、一个六边形（包含 6 个边），一个有 7 个边的六边形 (正常，一个很难可视化) 和一个八角形。

是否可以在不进行计数的情况下识别 9 面形状？ 我不能。 它被称为“非角”，为你琐碎的buff。

因此，就我个人而言，我努力达到8项限制，但我的经验法则是4-20。

对于你查看的每个元素，请考虑应如何划分工作。 同样，想想 4-20 规则。 但知道何时停止是秘密。 较新的项目经理将进行分除、子划分和子划分，直到走廊下的每一步都是一项托管任务。 你可以问自己关于任务长度的一些好分水岭问题可能是：

• 如果此任务延迟，我会采取什么操作？ 如果答案是“无所事事”，则表明你正在考虑的任务太小，不值得管理。 如果是这种情况，你看起来太详细了。 备份一个级别，后退一步，看看你是否已完成。

• 收集有关此任务更新的数据所花费的时间是否比任务本身更长？ 我们并不总是想到管理计划任务需要付出什么样的努力，但即使有一段时间，也值得考虑。 如果管理任务所花费的精力比完成要花费的精力要多，那么这很好地表明任务在细节级别上定义得太精细。

• 此任务需要多长时间？ 当我们分工时，有时我们看不到任务变得多么微不足道。 顶层的大阶段可能长达数周，但当我们降低几个级别的粒度时，我们很容易陷入定义要管理的任务的陷阱，该任务只有几分钟的时间。 当我们完成微小的任务时，我们必须问管理这些任务的好处是什么。

让我们对刚才谈论的内容应用现实检查。 在为期两年的 EPC 项目中，如果一周的任务晚了一天，几乎肯定不值得采取行动。 在为期六个月的软件项目中，延迟一天一周的任务可能不值得执行。 在一个为期六天的“关闭”项目中，延迟一天一周的任务是一项巨大的紧急情况。 换句话说，EPC 项目中的一周任务可能过于细化，在软件项目中，它可能恰到好处：在“关闭”项目中，几乎可以肯定需要细分为更详细的项目。

涉及多少资源？

我知道我们只是在研究范围，但当我们看看我们需要什么样的解决方案时，值得思考有多少人将从事一项任务。 例如，在大型 EPC 项目中，一个工作阶段中可能涉及一项技能的数十名工人。 但是，当我们在同一任务中最终获得许多不同的技能时，管理该任务将变得非常具有挑战性（如果不是不可能的话）。 因此，在这种情况下，需要许多不同的技能的任务可能需要划分。

在软件项目中，我们倾向于将几乎每个人都视为具有独特功能的高度技术资源。 此外，在软件项目中，许多任务在一个部门内可重新分配，但只有一个任务分配给一个人，这很常见。 因此，当我们的任务分配给特定资源组或部门的单人级别时， (例如接口编程) 我们非常接近，无需更多细节。

如何管理或细分资源？

如何管理资源是决定如何对任务进行细分的一大决定因素。 例如，在大型 EPC 项目中，项目通常分为子项目，这些子项目被包裹给大型分包商。 在这种情况下，我们需要执行以下几点操作：

• 以一种让项目经理能够监督分包商的方式定义工作，并确信进度是一个重要因素。

• 以让分包商的项目管理和工程人员理解其含义的方式定义任务，而没有歧义。

• 确保分包商理解并同意已采用的已作为标准的决议级别。

当我们查看白领项目（如软件、生物研究或工程）时，我们最有可能遇到矩阵管理结构，其中项目经理不拥有任何资源，我们必须跨跨跨多个不同项目分配这些资源的部门经理工作。 在这种情况下，关键问题将是：

• 一个资源在一天内可能处理多少个项目？

• 员工从一个项目切换到另一个项目需要多长时间？

• 对工作的定义是否使员工和资源部门经理都了解如何为其分配适当的技能？

当我们查看关闭或施工项目时，我们倾向于跨特制人员工作。 在这些情况下，即使该团队包括木工和管道安装工) 、管道团队或锅炉机组翻新团队，资源团队主管也可能在管理电气团队 (。 工作必须以这样的方式进行组织，以便船员在整个轮班期间保持忙碌，他们不会到达另一个已经在该地区工作的工作人员。 鉴于关闭项目完成的强烈压力，工作通常先按工作进行组织，然后按计划，然后由资源团队负责人重新分组和细分，这样每个团队领导都可以在一个文档中只处理其任务，并在另一个文档中将整个项目置于上下文中。 因此，必须以员工和资源团队主管可以理解的方式定义任务。 此处的任务可能定义为小时，或者更细化到第十或四分之一小时。

收集数据的速度有多快，这需要多少工作量？

当你习惯于在周末看到项目数据全部排成一排时，这听起来像是一个愚蠢的问题，但是当你试图确定项目的解析级别时，这可能是一个关键问题。 例如，当您通过许多分包商工作时，可能会获得某种每周或每月更新。 事实上，在合同中构建项目管理更新子句至关重要。 在这种情况下，你必须将这些不同公司的数据集成到你自己的公司中，验证进度数据是否有意义，然后执行自己的分析和报告。 在 EPC 模式下，这可能是每月发生一次。

在关闭项目中，需要每班更新项目、快速更新项目，并在下一班中获取资源团队主管的更新。 在这种情况下，项目人员在轮班期间蜂拥而至，尽可能实时地收集数据，并让资源团队领导和工头使用“下班”工作表来“下移”任务进度。 在软件或研究项目中，你可能正在每周工作一次或类似的事情，个人报告自己的进度，并在一两天内通过审批。

这是在查看项目中要包含的任务数时要考虑的一个重要点，因为收集数据是有成本的。

因此，考虑定期周期性地收集、批准、集成、分析和报告数据的速度是关键，考虑收集数据的成本和收集的数据的投资回报。

我们多久更新一次？

下面是确定可以收集的数据量并包括的两个密钥：

• 考虑如何收集数据。

• 考虑合理更新项目的频率，并为管理层提供指导项目和资源朝正确方向发展所需的决策工具。

我看到一些项目经理坚持说，他们希望转向“实时”项目管理和项目收集，虽然这在理论上是可能的，但在实践中很难实现。

当我们查看项目管理数据时，我们会做出一些假设。 我们假设：

• 数据就全部存在。 我们不希望查看某些已更新的任务，也不会查看其他未更新的任务。

• 数据都在类似的时间更新。 我们预计，一半的任务在几分钟前就更新了，但另一半的任务已经两周没有更新了。

• 这些数据都获得了一定程度的批准。 我们希望项目经理支持呈现的数据，并且他或她能够说“这是项目的公平和准确的表示形式”。

• 数据属于一起。 我们预计风险不会随着成本和资源而模糊，除非我们以这种方式专门设计了报表和分析。

我经常问那些对实时项目管理概念感到兴奋的高管们，如果我们能克服上面提到的要点，他们会怎么做。 “你准备好在一周内做出管理决策了吗？我会问的。 响应应取决于分辨率级别。 在关闭项目中，答案最好是“是”。 在软件项目中，答案可能是'不，我们会每周执行一次' 。 在EPC项目中，答案将是“每月”。

在某些时候，回报递减的规律开始说，“更快地交付项目报告不会给我们任何效率的提高。

审阅你的工作

现在，你已考虑了一些建议，你已使用工作细分方法对数据进行细分，并且你已观察了一些警告信号，即数据定义过于精细。 现在是时候把日程靠在墙上，退后一步，用一些视角来看待项目了。 令人惊讶的是，许多项目经理从未这样做过。 他们陷入了最后一个细节的定义，并且一次又一次地忙于分任务，以至于他们把自己推到上线的最后期限，从不抬头看他们所做的是否将是一场管理噩梦。

在某些情况下，高管们从所有MBA培训中确信，“更详细越好”，他们正在推动为期6个月的项目完成5分钟或15分钟的任务。

在项目开始之前更改项目始终比以后的任何时间都容易，因此，在计划生成活动中生成时间可以根据需要重新工作计划。

太多了吗？

有时，项目经理查看他们创建的内容的范围，并意识到他们处于过于精细的细节级别。 如果是这种情况，修复是显而易见的。 这可能是大量的工作，但你会感谢自己稍后通过上一个级别使计划更简单。

有时图片不是那么容易。 在某些情况下，只有组装好整个计划后，项目经理才能看到它有多复杂。 从本质上说，复杂的项目风险更大，在当今的经济中，风险是项目的关键选择因素。 在这样一个复杂的项目开始之前，值得考虑的一些问题可能是：

• 我们能成片地做吗？ 一些风险项目可以分解为较小的部分，作为较小的项目，其风险会下降。 但是，如果使用此策略，则每个离散项目在完成时都应有自己的值。

• 我们应该重新考虑范围吗？ 有时最简单的操作是首先回到工作的设计者，解释日程中看似明显的复杂性，并查看工作是否可以重述。 这往往导致创新思维，这是永远不会发生的机会。

我们应该这样做吗？

有些项目从来就不是，取消这些项目的最便宜的时间是它们开始前一天。 如果项目的风险现在才显现出来，那么现在比以后更适合意识到它。 将执行计划的结果重新融入到项目组合管理 (PPM) 流程中时，你可能会发现更复杂的项目的风险在投资回报规模中的工作分数要差得多。

一个敏捷... 否，敏捷项目

我答应说一些关于敏捷项目管理的事情，如果你是敏捷的粉丝，并且你已经读到这一点，我很感激你的耐心。 通过敏捷方法管理软件项目是一种理念，但对于那些因大型软件开发项目而失败的人来说，这是一种越来越流行的理念。

在敏捷软件开发领域，我们尝试将项目分解为一到三周的“冲刺”，每个微型项目的目标是最终获得可用代码。 在这种情况下，我们在一些相当已知的约束下工作，因此我们的分辨率级别几乎为我们选择。

我们有一到三周的时段，资源可供我们使用，我们将为每个资源分配工作。 我们可以在该结构中定义的可能任务数是有限的，这有助于保持适当的分辨率级别。 是的，可以通过定义太短的任务来在敏捷中遇到麻烦。 “定义字段 1： 10 分钟、定义字段 2： 10 分钟、定义字段 3： 10 分钟”等，但不太常见。

敏捷是为公司开发环境设计的，我们正在创建供内部使用的软件，其用途通常扩展到商业软件开发。 (我们在 HMS 中使用方法自行开发 TimeControl.) 敏捷方法会产生一个更灵活、更灵活的开发部门，但它不适用于每个行业甚至每个软件公司。 如果你是在软件环境中进行项目管理，我的建议是阅读敏捷，从中学习，然后采用这些元素 (所有、部分或任何) ，这将使你最有效。

总结

与项目管理的大多数方面一样，对于最初似乎如此明显的问题，没有固定的答案。 项目中有多少个任务，每个任务应该有多长，你需要自己去决定... 但决定你必须。

选择项目解决级别是项目管理责任，可能是管理项目日程的关键成功因素。

关于作者

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) 。