在组织项目日程安排和重新估算工作时，可能要修改规划，这很正常。既然知道项目会随着时间演变，就没有必要详细安排整个项目的日程了。如果客户在签合同之前希望看到完整的项目时间表，要告诉他们：这个初步时间表只是基于目前状况所做出的最好猜测，是会变化的。

http://www/uc/myshow/blog/misc/gif/E___6783EN00SIGG.gif估算要准确，而不是精确。

安排项目日程有很多种方式，不管是自上向下还是自下而上，都可以先草拟出一个项目日程，然后在此基础上制定项目计划。对于项目来说，规划和日程安排二者不可或缺

一个注重实效的项目经理，为了先让项目启动起来，会做恰到好处的规划，并随项目进展不断进行规划和重新规划。不管怎么做，规划与日程安排都不可忽视，尤其是规划中的项目验收标准。在安排日程时，也许没有必要使用设计精美的甘特图，对于大部分项目来说，形成一个较为详细的进度表就足够了。

项目的日程安排会与选择的生命周期有关系。请注意：生命周期是项目的模型，让别人看到项目是如何组织的。在创建日程时，可以将生命周期用作指导方针。每种生命周期模型都有其内在风险，无论采取何种方式安排日程，都要保证处理这些风险。在顺序式生命周期中，项目经理要预留计划外的时间，比如项目结束时的系统测试，以弥补项目过程中的未知风险和问题可能造成的损失。要记住，生命周期可以作为指导方式，但不是严格的限制条件。

日程安排和历时估算是两种不同的活动。日程排定要安排工作任务的顺序，展示它们之间的依赖关系。历时估算则要猜测某个任务要花费的工时数。这两种活动有关联，如何安排日程，可能取决于某项任务的估算历时和需要的特定人员。

对未知事物进行判断，仍然难以做到精确。国人惯用“管理既是一门科学又是一门艺术”这样自嘲的、毫无信心的说法恰，好说明了这一点。

前期规划活动耗费的时间要适当，特别是在团队人员已安排到位的情形下。产生的规划足以让项目启动就可以了。使用滚动式规划的方式，可以让每个人把注意力放在项目近期的工作安排上。一旦大家知道最近一段时间内要做什么，项目经理就可以再考虑规划和日程安排中还需要补充哪些内容了。

一、估算是一个逐步精确化的过程

不是每个人都善于估算。有些人过于乐观，对于每项工作都会少估算一定的工作时间。有些人会过于悲观，为每项工作添加缓冲的时间。有些人在估算不超过一周的工作时没有问题，但是对于超过一周的工作，却很难估算准确。还有些人为了保护自己，为自己负责的工作在估算基础上添加余量（给工作加注水分），他们信奉“不管你制订出什么样的日程，发起人总是希望项目能更早完成”。作为项目经理的你该怎么办？

1.        要了解你的团队成员。要想清楚，对每个人在项目中的估算提供多少反馈。你没有必要在项目第一周时就试图解决所有估算问题。

2.        要去掉每个任务的任何额外缓冲时间。询问每个人在估算时是否考虑了缓冲时间，当然仍需要你们之间有基本的信任。这里，大家要达成一个共识：“不是要减少任务的完成时间，而是要确保能够得到最准确的结果”。

3.        可以考虑在估算时使用TOC理论（Theory of constraints）[1]，请每个人提供一个他认为合理的任务估算，在此基础上取其估算历时的一半，在甘特图中将该任务标识为对应的时间长度，再取估算时间的25%放人缓冲区中。如果关键路径中的任务需要更多时间，可以从缓冲区中取出时间加在这个任务上。再继续处理缓冲区。当团队完成所有的任务之后，通过计算缓冲区中的时间，就可以知道之前估算的整体效果如何。

4.        不断修正项目估算。在项目经历一段时间以后，项目经理应收集已完成工作所花费的时间，并将其与估算时间对比，随项目推进不断学习和修正估算历时，千万不要认为估算历时是一件一劳永逸的事。

二、避免注入水分，警惕估算陷阱

不要为任务估算添加过多的水分，如果拉长估算就可能会引入“帕金森法则”或是引发“小学生症状”( Student Syndrome)，并因此担上风险。如果人们可以一直无忧无虑地忽略他们当初所做的估算，那他们就永远不会学会如何改进自己的估算技能。可以提供一个估算信心百分比、一个日期范围[2]，也可以使用PERT技术。

客户/发起人总是希望项目经理能给出总的项目进度表，因此项目经理必须面对在一开始就负责估算并安排整个项目的时间表。这会花去他们（以及参与进来的项目团队成员）几周的时间，因为他们要对需求和系统整体有足够的理解，才能产生合理的估算。基于组织对该项目的陌生程度，他们的估算会发生偏差。我曾见过从100%到400%不等的偏差幅度。

从一开始就估算整个项目，这是个陷阱。要想做好，可以让团队先动手做一点项目工作，测量出完成工作需要多长时间，再看看项目中包括多少类似工作量的工作，并通过迭代或类比方式得到项目的历时估算。项目经理要利用估算信心百分比和日期范围，这样大家就可以知道估算的不确定性有多大了。

三、使用项目历时估算的置信范围

你对自己的估算有多大把握？项目刚开始，我一点儿把握都没有。我只知道项目不会完全按照我们制订的日程推进。有些东西是会变的，它们会改变估算。不要使用只估算出一个结束日期，尝试使用自信心范围吧。

可以看看图1，这就是项目历时估算的置信范围。可能性的范围就是估算的置信区间。在22周内完成项目的概率在20%左右；在25周左右完成项目的可能性尚不足50%；如果要确保100%完成项目，项目经理可以给出约40周左右的时间计划。

http://s5/mw690/001WNOgkgy6VXPQ0y3O94&690
图 项目完成时间的累积图

四、面对乐观的干系人

人们很容易乐观，并过少估算完成任务需要的时间。要想解决这个问题，似乎必须要拉长这些估算。但是问题在于“帕金森法则”：工作会占满为其分配的时间。

假设你的首席开发人员很乐观，他对任务的估算是16小时。可是你知道这个任务得用20-30个小时才能完成。作为项目经理，该怎么做？

首先，要帮助开发人员在估算时分开考虑规模与持续时间。如果他的任务量很大，让他把任务切分解更小的工作。

如果分解工作做法不可行，考虑做一到两周的“验证性”工作，这有助于大家看清任务要用多久才能完成。

与习惯性低估任务完成时间的人交谈，帮他们认识到自己实际能够完成的工作量要比他们估算的少。在任何情况下，没有人能投入一个工作100%的精力，如果同一时间分配给员工大量的工作任务，都会降低工作效率！

日程安排是由整个项目团队共同制订完成的，所以每个人都对日程有信心。可是“天有不测风云”，总会发生点儿意外。

别担心。项目日程是团队当前对于项目工作会如何展开的估计。随着时间的推移，意外情况发生了，通常在日程“完成”一到两天之后，最初的日程就变成明日黄花了。这就是我为什么只做足够的时间计划，而且会使用滚动式规划，这样我就可以随着环境变化很容易地更新日程安排。

五、用里程碑切分项目

验收节点带来的压力，往往是干系人们（尤其是客户和发起人）关注的重要节点，对于项目团队而言属于没回旋空间的硬性节点，而里程碑节点（特别是内部控制的里程碑节点）有时是有弹性的，不属于火烧眉毛。但是忽视项目里程碑，则是一个压力积累、风险做实的过程。

作为项目经理，你因该合理规划里程碑节点，使其有可行性，有验收价值；同时，围绕每一个里程碑安排工作，找到项目的节奏。这里，借用某位老师的话，送给读者：

眼睛盯住细节的，是工程师。

眼睛盯住结果的，是老板。

眼睛盯住过程的，是项目经理。

1、使用基于可交付物的规划来安排任务

项目经理和团队在制订日程时要依据可交付物确定项目的里程碑。一个阶段的“完成”要由其可验证的交付物。例如，对于名为“完成架构原型”的里程碑，如果没有可交付物用于帮助理解如何完成它，团队又该怎么交付？

2、将里程碑的结束安排在一周之中的某天

大家都愿意将主要（和次要）里程碑的结束日期安排到周五。这样一来，每个人在回家的时候，就能知道他们已经完成了一部分主要的工作。不过，生活很少能够这么理想。

如果将周一作为开始、周五作为结束是危险的。周五结束，意味着在周一之前，没有人会检查已经完成的工作。人们就有可能在周末疯狂加班，以满足流程对周五的日程要求。而且，项目经理（或团队）就越难以搞清楚工作是不是真地做完了，除非在项目即将结束时进入测试阶段。

当项目经理将里程碑的结束安排在周中时，有哪些工作尚未完成就很明显了（项目经理也希望看到这一点）。你可以调整项目，因为你知道哪些完成了，哪些还没有完成。可如果不知道哪些工作还在进行中，你所能做的调整选择就很少了。

可以选择周二或是周三作为主要的里程碑的开始／结束的日期。这样项目经理可以看到真正的进展（或是未完成的工作），你可以减少加班，而且能够调整项目，不会被项目结束时可能发生的灾难所吓到。

六、让估算更容易的实践

实践中，下面这些方式可以让估算变得更容易些。

l   时刻提醒干系人估算只是一个估计值——一个猜测。猜测范围越大，错误可能就越多。在对项目完成“日期”进行估算时，要提供一个日期范围，让听众知道你的估算只是猜测。

l   很多年轻的项目成员都很乐观。国内高速发展的30年，让大家变得越来越乐观，乐观主义情绪深深停留在人们脑海中。

l   完成一项工作总是要花费比预计更多的时间。

l   估算小块的工作更容易。

l   项目经理和团队需要做好估算记录并在工作中收集反馈。没有反馈的估算只是“估算”——它让人感觉良好，不形成书面记录只能是个人头脑中的“经验”，对组织被证明毫无价值。

l   做好反复估算的准备。项目进行到一半时意识到估算过于乐观并不晚，花点时间重新估算，重新安排剩下的工作。已经延迟的项目是无法再赶上进度的，交付一定会延迟。即使项目看起来不会晚，也应该花时间重新做估算。

l   不管别人怎么要求用里程碑把项目分阶段控制住。在计划过程中，合理规划里程碑节点，使其有可行性，有验收价值。在执行过程中，围绕每一个里程碑安排工作，找到项目的节奏。在管理过程中，将里程碑的压力传递给项目中的每一个人。

l   如果项目过大（包含很多技术风险），不容易估算好，考虑做一到两周的“验证性”工作。