他们说他们想要一个解决方案:白皮书

本白皮书是我们的“一线快报”系列文章的一部分。 本文介绍了您在安排项目日程时可能面临的一些常见挑战。 本文介绍了您在尝试确定任务持续时间以及安排的任务数量时应采用的最佳策略,以达到优化项目日程的目的。 本文讨论了为何不同行业通常需要不同类型的日程安排,例如,软件开发、EPM(工程、采购和建造),以及工厂停运。 本文还探讨了选择项目解决方案时需要注意的若干要素,如项目长度、参与的资源、资源的管理与拆分、收集数据时需要的速度和工作,以及数据更新日程安排。

若要下载本白皮书的 Word 版本,请参阅他们说他们想要一个解决方案:白皮书 (Project Server 2010)

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

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

首先,要就标题向披头士乐队道歉,然后我们进入今日主题:您的项目的解决方案。

市面上有许多材料都在介绍如何安排日程,但在那些最为关键的诀窍之中,有一点非常难以弄懂 - 您应在项目日程中设置多少个任务?每个任务应持续多长时间?

每隔一段时间,我都会遇到一些看上去无比复杂的项目日程,或者遇到一些似乎完全无法找出日程问题所在的项目经理,因为他们的日程安排范围过于宽泛,概括性太强。 我见过时长超过 100 年的项目(没开玩笑!),整个项目长度安排得非常妥当,其中包含的一些任务持续长达数十年。 我还见过仅仅持续一小时或更短时间的项目日程,这些项目同样安排得十分妥当,其中一些任务仅仅持续 1 分钟。 我见过任务数量寥寥无几的项目,也见过包含超过 100,000 个任务的项目。

我们如今使用的软件可以处理数千个任务,也能适应各种各样的项目持续时间。

那么,究竟什么才是正确的策略?

为了优化项目日程,任务应该持续多长时间?我们应当设置多少个任务? 我将把这些问题的答案称作项目的解决方案。

具体问题,具体分析

行业不同,项目类型不同,所处情况不同,那么相应的要求也不同,因此,我们来探讨下该如何确定应在您的日程安排中设置的任务数量以及任务持续时间。

不同类型的项目自然需要不同类型的日程安排。 我们来看看三个不同的示例:

  1. 软件开发   。 许多软件项目具有共同的特征。 虽然每个软件项目都有独一无二的一面,但通常都包含设计阶段、编程阶段、质量保证阶段、文档备案阶段和部署阶段。 软件项目持续期通常以周或月为单位,因此适合开展持续一天到数周的任务。 在此情况下,通常会按个人来分配资源。

    采用“敏捷”流程的人会考虑实施较短的“冲刺期”(持续 1 到 2 周时间)并在这段冲刺期内设置持续期较短的任务,但总体项目持续时间仍然以周为单位。 我们稍后将探讨有关“敏捷”开发的更多内容。

    Agile sprints 的甘特图视图
  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) 中,项目中的任务会持续数周或数月。 在第三类(工厂停运)中,项目中的任务以 6 分钟(一小时的 1/10)、10 分钟、15 分钟(一小时的 1/4)乃至数小时为单位进行计算。 很明显,在某些情况下,较短的任务更有意义,而在其他情况下,较长的任务则更为合适。 根据这一逻辑,有时我们必须设置大量任务,有时则不必如此。

选择项目解决方案时要考虑的因素

考虑到以上三种明显的区别,显然,在持续六天的停运日程中加入持续两个月的 EPC 项目任务是一项荒谬的决定,而持续 15 分钟的任务同样也不适合 EPC 或软件项目。 但是,除了参考本文然后声称“Vandersluis 说这是一个软件项目,因此任务只应持续 1-10 天”(请别这么做!)以外,到底存在哪些项目特征可以帮助我们确定应当选择哪种级别的解决方案? 我们来看看一些明显的特征:

项目持续多长时间?

我们从最明显的开始。 如果您的项目预计持续数天时间(比如我们举的停运的例子),则设置持续数天的任务毫无意义。 在考虑如何进一步细分项目范围时,为了提高效率,通常应首先采用从上至下的策略。 使用工作细分结构进行思考。 从主要的组成部分入手。 请同时考虑 4-20 项事情。

这是一种规则? 不,当然不是。

这是常识。 思考对象低于 4 个时,您会困惑有何必要将工作进行细分,而对象超过 20 个时,您又太难同时在脑子里思考这么多东西。 就我个人而言,我会为每个 WBS 元素设置不超过 8 个思考对象,这是因为,我多年前曾看过某篇文章,其中提到,八边形是思维可以立刻识别的、最为复杂的简单形状。

稍微思考一下这个观点。 您可以识别圆形、三角形、正方形、五边形、六边形(具有 6 条边)、七边形(具有 7 条边)(好吧,这个图形想象起来有点困难)和八边形。

您是否可以在不数边数的情况下识别具有九条边的形状? 我无法做到。 为了满足您的好奇心,这东西学名为“nonagon”,即九边形。

因此,就我个人而言,我选择将限制设为 8 个思考对象,但就经验而言,这个范围可以为 4-20 个。

对于您审视的每个元素,请思考该如何细分工作。 请再次考虑 4-20 规则。 其秘诀在于,知道该在何时停止细分。 经验较浅的经理会不断细分工作,直到让每个细小的步骤都变为需要管理的任务。 这时,您应该针对任务的长度向自己询问一些有效的问题来作为提醒,比如:

  • 如果此任务被耽搁了,该怎么办?    如果答案是“什么都不做”,则表明您在考虑的任务过于细微,并不值得进行管理。 如果是这种情况,则表示您对于细节抓得太深。 请返回上一项目级别,往回倒退一步,然后看看是否已安排妥当。

  • 在收集与此任务的更新有关的数据时所耗费的时间是否比花在任务本身上的时间还多?    我们不会总是去考虑管理计划任务需要付出何种程度的工作量,但偶尔思考一下总归是有意义的。 如果管理任务所耗费的工作量比完成任务本身还多,则表明任务被定义得过于精细。

  • 此任务持续多长时间?     我们在细分工作时,有时会忽视一点,那就是任务可能变得极为细小。 顶层的大型项目阶段可能会持续数周,但随着我们向下细分几级,便很容易掉入一个陷阱:定义某个需要管理的任务,而该任务仅仅持续几分钟。 当我们细分出细小任务时,我们必须问问自己,管理这些任务能带来什么好处?

我们来实际检验一下刚才谈到的内容。 在一个持续两年的 EPC 项目中,如果一个持续一周的任务被耽搁了一天,那么几乎可以断言,我们没有必要采取任何措施。 在持续六个月的软件项目中,如果一个持续一周的任务被耽搁了一天,则有可能无需采取任何补救 措施。 在持续六天的停运项目中,如果一个持续一周的任务被耽搁了一天,问题就非常紧迫了。 换而言之,对于 EPC 项目而言,一个持续一周的任务可能过于细微;对于软件项目而言,这一任务的精细程度可能正好合适;而对于停运项目而言,则几乎可以肯定,必须将这一任务进一步细分。

涉及多少资源?

我知道,我们讨论的是项目范围,但在考虑需要何种解决方案时,我们有必要思考一下将分配多少人员来处理某项任务。 例如,在大型 EPC 项目中,我们可能会在工作的某个阶段分配几十个具备一种技能的员工。 但是,当我们最终在同一任务中加入多种不同的技能时,管理该任务的过程就会变得极具挑战(如果并非无法管理的话)。 因此,在这种情况下,我们可能得将那些需要多种不同技能的任务进行细分。

在软件项目中,我们倾向于将几乎每一个个体都视为具备独特功能的高度技术化资源。 此外,在软件项目中,经常出现这种情况:在一个部门中存在多个可重新分配的任务,但一个人仅可分配一个任务。 因此,当我们手头的任务正好可以分配给特定资源组或部门(例如,接口编程)的每位员工时,就差不多表明,项目无需继续进行细分。

如何管理或细分资源?

管理资源的方式很大程度决定了如何细分任务。 例如,在大型 EPC 项目中,项目通常会被细分为子项目,然后分包给大型分包商。 在这种情况下,我们需要执行一些操作:

  • 定义任务时,须让项目经理能够对分包商进行监督,并确信正在实施的工作进度是促进项目成功的重要因素。

  • 在定义任务时,让分包商的项目管理和工程员工可以清楚理解任务的含义。

  • 确保分包商理解和同意您已采纳为您的标准的解决方案的级别。

在面对软件、生物研究或工程等白领项目时,我们很有可能遇到矩阵管理结构,在其中,项目经理手中并不掌控任何资源,我们必须与各个部门经理合作,他们负责将这些资源分配到多个不同的项目中。 在这种情况下,关键的问题包括:

  • 在单日内,单个资源可能会处理多少个项目?

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

  • 在定义工作时,员工和资源部门经理是否都能理解如何为工作分配正确的技能?

在面对停运或建造项目时,我们倾向于与专门的工作团队进行合作。 在这些情况下,资源团队负责人可能负责管理电气团队(即便该团队包括木工和管道安装工)、水暖团队或锅炉机组整修团队。 在安排工作时,需要确保工作团队在整个轮班期间始终有工作可干,同时工作团队在到达时不会正好遇上另一支团队正在该区域开展工作。 考虑到需要尽快完成停运项目的紧迫压力,通常由资源团队负责人按工作优先的方式对工作进行组织,然后安排相应的日程,接着进行重新分组和细分,如此一来,每位团队负责人只需随身携带两份文件,一份仅包含他们负责的任务,另一份则包含了整个项目以及项目背景。 因此,在定义任务时,必须确保员工和资源团队负责人都能清楚理解任务。 在这种情况下,任务可能会细分至以小时为单位,甚至 是进一步细分为以 1/10 或 1/4 小时为单位。

您收集数据的速度有多快?这个过程需要耗费多少工作量?

这个问题听起来挺傻的,因为您可能习惯于在一周结束时以统一规整的方式检查您的项目数据,但是,当您尝试确定项目的解决方案级别时,这可能就会成为一个关键的问题。 例如,当您正在与大量分包商合作时,则有可能您每周或每月都会收到某种更新。 实际上,您必须在合同中加入项目管理更新条款。 在这种情况下,您必须将来自不同公司的数据与您自己的数据进行整合,验证进度数据是否有效,然后完成自己的分析和报告。 在 EPC 模式中,您很可能每个月都需要执行这一流程。

在停运项目中,您需要在每次轮班时更新您的项目,而且还要确保迅速进行更新,然后在下次轮班期间将更新提交给资源团队负责人。 在这种情况下,项目人员会在轮班期间聚集到工厂各处,以尽可能接近实时的速度收集数据并帮助资源团队负责人和工长使用“记录”表“记录”员工任务的进度。 在软件或研究项目中,您可能会按照每周日程安排或类似的排班表开展工作,同时每个员工会报告自己的进度并在一或两天内接受审批。

当您思考应在项目中设置多少个任务时,这一点是重要的考虑因素,因为收集数据会产生成本。

因此,一定要思考您能够以多快的速度定期收集、审批、整合、分析和报告数据,同时,也必须考虑数据收集成本和收集的数据带来的投资回报。

我们的更新频率是怎样的?

可通过两种方法确定您可以收集多少数据,其中包括:

  • 思考您将如何收集您的数据。

  • 思考您能够以何种频率来合理地更新您的项目并为管理团队提供必要的决策工具,以便正确指导项目和资源。

在我的印象中,有些项目经理坚称自己希望迁移至“实时”项目管理和项目收集,尽管理论上这是可行的,但在现实中实现起来却无比艰难。

在面对项目管理数据时,我们来做一些假设。 我们假定:

  • 数据全部存在   。 我们不希望出现某些任务得到更新而另一些则没有的情况。

  • 数据均在几乎同个时间得到更新   。 我们不希望看到一半任务在几分钟前得到更新,而另一半则两个星期都没有进行任何更新。

  • 数据均获得了一定级别的审批   。 我们希望项目经理能够为展示的数据提供支持,希望他们能够清楚地表示“这些数据公正且准确地反映了项目。”

  • 数据应进行整合   。 我们不希望风险数据与成本数据以及资源数据混淆在一起,除非这种结果与我们在设计报告和分析时的初衷一致。

我经常会问那些对于实时项目管理的概念感到兴奋的管理人员,如果我们可以克服上述挑战,他们会怎么做? 我会问:“您是否准备好在一整周的时间内随时制定管理决策?” 得到的答复应该取决于解决方案的级别。 对于停运项目,答案应该是“是”。 对于 软件项目,答案可能是“不,我们将每周制定一次决策”。 对于 EPC 项目,答案可能是“每月制定一次决策”。

在某个时刻,回报递减规律会生效,然后答案将变成“进一步加快项目报告交付速度对于提升效率没有任何帮助。”

检查您的工作

您现在有一些事情值得思考,您已使用工作细分法细分您的数据并且您已留意到那些表示数据细分过度的警告迹象。 现在,您应当将日程安排挂在墙上,回退一步,然后从某种角度审视整个项目。 令人吃惊的是,许多项目经理从未这么做过。 他们是如此着迷于定义哪怕最为微小的任务细节,一遍又一遍地忙于细分任务,亲手将自己逼近项目截止期限,从来没有抬头审视一下自己的所作所为是否将会造就一堆难以管理的烂摊子。

在某些情况下,管理人员肯定参加过那些以“细节决定成败”为口号的 MBA 培训,他们总是乐此不疲地在持续六个月的项目中推行持续 5 分钟或 15 分钟的任务。

在项目启动前更改项目总要比启动后再更改要更加简单,因此,如有必要,请在日程安排创建活动中留出用于修改日程的时间。

任务是否过于详细?

有时,项目经理在审视自己创建的项目范围时,会发现自己将任务定义得过于详细。 如果是这种情况,那解决办法也一目了然。 可能您需要开展大量工作,但之后您会对此心怀感激,因为您通过缩减一个细分级别而让日程变得更加简单。

有时,并不是那么容易就能知晓这种复杂性。 在某些情况下,只有在将整个日程安排组合到一起时,项目经理才能知道它有多么复杂。 本质决定了,复杂的项目具有更高的风险,而在如今的经济环境下,对于项目而言,风险是一项重要的选择因素。 在执行此类复杂项目前,有必要考虑几个问题,例如:

  • 我们是否可以将项目细分?    一些具有潜在风险的项目可以细分为较小的项目,而随着项目变小,其风险也在降低。 但是,如果您使用的是此策略,那么每个分离的项目应在完成时具备自身的价值。

  • 我们是否应重新考虑项目范围?    有时,最简单的办法是回过头去找到项目工作最初的设计人员,向其说明日程中显而易见的复杂性,然后看看是否可以对工作进行重新安排。 这种处理通常会让之前被压抑的创新思维得到解放。

我们究竟应不应该这么做?

一些项目本来就不需要做,最好是在项目启动之前取消项目,这样付出的代价最低。 如果项目风险直到现在才表现得比较明显,那么最好现在就意识到这些风险,而不是留到以后。 返回项目组合管理 (PPM) 流程制定日程后,您会发现很多信息,当您梳理这些信息时,您可能会发现,如果按照投资回报来为工作打分,更加复杂的项目所带来的风险会大幅降低工作的得分。

一个灵活...不,“敏捷的”项目

我曾说过要谈谈“敏捷”项目管理,如果您对“敏捷”项目深感兴趣并且坚持看到了这里,我对您的耐心深表感激。 通过“敏捷”法管理软件项目在某种程度上是一种理念,但这种理念越来越受到那些被失败的大规模软件开发项目搞得焦头烂额的用户追捧。

在“敏捷的”软件开发环境中,我们尝试将项目细分为持续一到三周的小型“冲刺项目”,每个细分项目的目标都是最终产出可用的代码。 在这种情况下,我们将在一些相当广为人知的约束下开展工作, 如此一来,我们便拥有了量身定做的解决方案级别。

我们有一到三周时间,拥有可用资源,同时我们将把工作分配给每个资源。 我们可在这一结构中定义的任务数量是有限的,因此相当适合维持一个适当的解决方案级别。 没错,如果您定义的任务持续期太短,则可能会在“敏捷”项目中遇到麻烦。 “定义字段 1:10 分钟,定义字段 2:10 分钟,定义字段 3:10 分钟”等等,但这种情况要罕见得多。

“敏捷”项目最初设计用于企业开发环境,在此类环境中,我们会创建供内部使用的软件,而现在此类型的结构经常被延伸用于商业软件开发。 (在 HMS,我们将本文中的方法用于开发自己的 TimeControl 产品。)“敏捷”法可以让开发部门的管理更加灵巧和灵活,但其并非适用于每个行业,甚至并非适用于每家软件公司。 如果您是在软件环境中进行项目管理,那么我建议您阅读“敏捷”法的相关内容,从中学习经验教训,然后采纳那些可以最大程度帮助您提升效率的元素(全部、一些或无)。

总结

就项目管理的绝大多数方面而言,并没有为那些最初看上去如此显而易见的问题设置标准答案。 您该在项目中设置多少个任务?其中每个任务应持续多长时间?这些问题的答案都需要您自己去发掘...而且必须作出决定。

选择项目解决方案的级别是项目管理的职责,这可能是项目日程安排管理中的关键成功因素。

关于作者

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 支持专员。

×