见过项目日程安排游戏吗？
我遇到一些组织，他们有个不成文的规定：绝不讨论项目日程。这种情况我见得太多了。管理层想要一个日期，项目团队就会说：“当然，没问题，就节前吧！”但他们不会明说是哪个节。劳动节、国庆节、春节应该是项目组最怕的三大节了。

最后，当某个节到来之时，已经过了不少日子了，人们开始讨论日程安排。而这时项目已经错过不少里程碑的交付日期，甚至有可能几个早先期望的项目结束日期都已经过去了。
我曾跟这样一个项目团队共事，他们在5年之内没有达成项目日程中任何一个里程碑或其他任何要求。他们总是在反复制定优化项目日程。记得那时有个OA项目，立项时计划是10个月，国庆节出测试版本，然后拖到春节，在后面是劳动节。。。事实上，我5年后离开时，项目还没有发布正式版本。

我必须承认，长久以来，我很难理解人们怎么会陷入到这种日程安排游戏中。不过，我确实见过善于口舌的管理层，他们或威逼，或利诱，或用权力来“说服”项目经理以及团队，让他们相信可以满足管理层对项目日期的要求。这种所谓的“说服力”加上逃避困难话题的文化，足以让项目经理进行项目日程安排游戏，定期给出让所有人“开心”的日期。
有了这个开心的日期，组织中有些人（项目团队或项目经理）就可以让另外一些人（项目干系人，如高层领导或客户）感到心安。从某种意义上来说，大家都不认为日程有讨论的必要。项目团队想抚慰项目干系人，项目干系人也愿意得到安抚。
不要以为项目日程安排游戏只是某些特例，实际上很多项目组都有这个现象。我上半年刚刚拯救成功一个项目，但在我离开后，他们就开始了日程安排游戏。告诉客户，六月份会有一个大的变化，全新的产品。然后是七月。。。现在已经是八月了。。。

要阻止这个游戏的发生，你必须与组织一起在项目层面上工作。要了解你的团队，谨小慎微的进行计划，多考虑风险，不要为了领导或客户的喜好而给出不切实际的日程，最后还是要一步一个脚印的去督促执行。
如果你使用敏捷生命周期，一定要给出经过排序的代办事项列表。假如采取按阶段交付的生命周期，那么尽量使用短小的时间盒，比如以4个小时划分一项任务，这有助于人们不断取得进展，而且要让大家了解这些进展。
不要仅仅以里程碑日期作为项目项目的衡量标准。要想了解项目的真实情况，如果只使用单一的衡量标准无异于饮鸠止渴。可使用速度图表，让每个人都能了解进度。
不过，上述只是项目经理仅凭一己之力所能做到的。这个游戏揭示了组织的不一致性——大家只想彼此安慰，避免冲突。建设性的讨论（又名建设性的冲突）可以让组织更坚强。避免冲突和必要的讨论只会让组织变得更孱弱。