项目计划的七宗罪
本文是我们的“从战壕”集合的一部分。
本文讨论在项目日程中出现的常见错误，并提供实用建议。 它提供与任何 Microsoft Project 版本相关的实用建议和建议。
若要查看更多文章，请参阅 “从战壕”白皮书。
项目计划的七宗罪
计划从来不是项目的简单组件;然而，在过去的20年里，我一再遇到我为他们工作或咨询过的每个组织在日程安排方面遇到的相同基本问题。 在这里，我列出了项目日程的七大致命罪，并为你提供一些解毒剂。 我希望，在使用计划时，你将使用此建议为成功的项目管理打下适当的基础。
Sin #1：计划太复杂了！
如果计划从北到南运行而不是从左到右运行，则会出现问题。 如果利益干系人需要数周或数天才能了解你的计划，则模型过于复杂。 如果太难向高管甚至你的团队解释，那么你怎么能指望有人从中受益呢？
如何知道项目是否过于复杂？ 问问自己在日程中查找关键路径有多容易。
Sin #2：你的计划任务太多
这比什么都更有助于为什么日程会落到一边。 项目经理给人的印象是，日程表需要是需要完成的所有事项的清单。 任务项和自我提醒不属于工作分解结构。 此方法完全违背了表示项目模型的计划的全部目的。
为了说明这一点，我来分享一个示例。 假设你是木材供应者或要建造正在建造的房子的框架者。 你需要知道何时交付木材包，或何时与工作人员一起开始工作。 这通常在基础完成时发生。
可以生成如下所示的计划：
或者如下所示：
如果你是构建者和计划程序，你希望采用哪种方法来更新和维护实际值？
现在假设你同时有 30 所房屋正在建设中。 你更喜欢哪一个？
这不是说列出的所有其他任务都不重要，或者其他任务不需要完成。 这里真正的问题是如何跟踪和维护它。 还可以将详细信息任务作为上面所示的一行任务的注释列出。
这是我的经验法则，我从 Eric Uyttewaal 的著作《Microsoft Project 2010 的预测计划：最短工期是项目工期的百分之一：最大值为持续时间的 10%。
Sin #3：网络逻辑不完整或不动态
不完整的网络逻辑是计划无法正确预测或动态发展的主要原因。 依赖项太少，这一点就说明这一点。 使用太多约束也会大大损害布局正确的网络的动态性质。 如果在指示器列中看到大多数约束，则表示你可能并不真正知道你在做什么。 项目经理通常将隐藏此列作为一个要点，以便隐藏他们的计划中包含许多约束。
下面是一个简单的测试。 在计划中找到关键路径 (如果不能，则) 已经有一个主要问题，然后尽早在计划中执行最长的未完成任务之一，并将持续时间加倍。 项目完成日期是否更改？ 如果没有，则没有工作计划。 拥有可用于预测任务和时间范围以及让项目经理更好地控制结果的动态计划，你将无法从基本租户中受益。
Sin #4：你的日程安排没有基线
如果不对计划进行基线，则很难（如果不是不可能）度量差异。 基线有助于在开始工作之前捕获计划，并允许你在现实开始时从差异中学习。 如果无法测量它，则无法控制它。
Sin #5：你的计划不会更新
我看到的绝大多数时间表都过期了。 一旦项目正在进行，项目经理通常会放弃日程，并发现自己在执行时要扑灭火灾。 如果计划过于详细，并且需要太多的工作才能使其保持最新状态，则发生这种情况的可能性会显著增加。 底线：如果不更新计划，则失去预测未来日期的能力。
Sin #6：你的计划没有资源分配，或者分配过度
通常，创建计划时根本不分配任何资源。 这可能会带来一张漂亮的图片，但也可能会给人一种错误印象，即时间线是可以实现的。 如果添加资源，然后调配资源，可能会出现完全不同的时间线。
分配资源时，使用资源使用情况视图) 查看“后台” (时，通常会严重过度分配资源。 如果你从现装的固定单位开始，你会从错误的脚开始。 花点时间评估你是否在人员能力范围内分配的时间和工作方面进行了实际分配。
此外，使用自动资源调配功能时，请特别小心。 它最好在手动模式下使用。 使用可让你了解其他项目工作负载的企业解决方案可以提高你完成任务的信心。
Sin #7：你不知道什么是任务类型
如果你不了解项目计划引擎的工作原理以及任务类型在公式中的工作原理
工期 * 单位 = 工时
你将永远拔出你的头发，并感到沮丧的工具。
如果你发现自己没有得到信息，那么我建议你给自己一个很好的资源，并研究它。 使用 Microsoft Project 2010 进行预测计划是一个很好的起点。
关于作者
Kevin Watson、PMP、MCT、MCTS 拥有超过 25 年的项目管理经验，是 Microsoft Project 和 Microsoft Project Server 的黑带。 Kevin 将项目管理和项目服务器的独特组合带到了该领域，他是 Microsoft 的高级顾问。 通过 联系他 kevinw@microsoft.com。