项目中本不该存在的困难及问题的应对之道

2011-5-24 17:44:14 | 418次阅读 | 来源：是 【已有16条评论】发表评论

一个前苏联笑话作为本文的开场白吧。某前苏联官员在他的发言中有这样一句歌颂前苏联社会主义制度的话：我们克服了大量在别的制度下不存在的巨大困难，解决了在别的制度下根本不会存在的巨大问题，这是苏维埃社会主义苏联社会制度的优越性的极大体现……

亲爱的朋友们，您感觉到本则笑话中所蕴含的幽默了么？扪心自问，在我们所经历的项目中，是否也存在着类似的冷幽默？在我们所经历的项目中，是否也费尽了千辛万苦，也克服了别的项目中不存在的巨大困难，解决了别的项目中根本不存在的问题？当然了，项目的独特性决定了每个项目注定要有其他项目中根本不存在的困难和问题。这里要谈的是，有些困难和问题项目发起人或项目管理者在制定项目制度和项目策略的时候就埋下了祸根。作为项目管理者，该如何应对这些本不该存在的困难和问题呢？

开始讲故事吧，这是一个国内边远落后的大省，在举国信息化建设如火如荼的进行过程当中，该省某厅再也难忍信息化多年毫无建树的尴尬、再也难熬国家部委屡次排名靠后的屈辱。于是该厅信息化建设的项目便被催生了。有了项目就要有项目经理，所谓天生我才必有用，笔者有幸，但此重任。从此，就开始了要么就是在项目上，要么就是在赶往项目的路上的“幸福生活”。亲爱的朋友们，让我们来了解一下与各种祸根战斗的“光辉历程”吧。

项目管理知识体系中有一个理论，相信凡是参与PMP考试的朋友们都耳熟能详，即：在项目的开始阶段，项目干系人对项目的影响力最大，项目的风险的几率最大，项目风险产生的影响最小。在项目的收尾阶段，项目干系人对项目的影响力最小，项目风险产生的影响最大。笔者这样理解，就是开始的时候最容易埋下祸根，最好不埋祸根。如果埋了，就要把这个祸根挖出来处理掉，越早越好。

让我们了解一下这个项目的几个祸根吧：
祸根一：建设范围、建设工期在立项阶段规划混乱
祸根二：无谓的镀金
祸根三：决策三拍惊奇

行文至此，回想本文的题目：一开始，笔者拟定的题目是项目中本不该存在的困难及问题的解决之道。反复推敲后，将解决二字换作了应对。如上所提的三个祸根，其实是无法根本解决的，作为一名项目经理，我们能做到只能是有效应对了。在埋下一个个祸根的时候，往往项目经理本人并不知情，即便知情，也会在客户期望、管理层压力、市场压力下无可奈何。

言归正传，先看第一个祸根，客户为了迎头赶上其他省份在该领域的信息化建设水平，将该领域内的所有业务，全部囊括其中。项目发起人对于范围是这样约定的：本厅所有的业务都要进行信息化。而工期从开始的三年直接压缩到了一年半。三年的工期如何估计，没有依据，一年半的压缩如何得来，也是毫无出处。客户对压缩工期的解释简单的近乎蛮横：这是我们的政治任务，一年半内必须完成。

怎么办？且看项目管理团队如何应对。你不是缺少规划么，咱来帮你先规划规划。项目管理知识体系告诉我们，对复杂的大型项目，必须要划分阶段，严格控制各个阶段的入口和出口。通过和项目发起人分析项目目标，分解项目任务，与各类项目干系人充分讨论，项目管理团队最终理清了项目范围，规划了项目工期。将项目建设内容分为八大子系统。初步的范围规划做好了，然后再解决工期问题：将项目分为四期，分阶段建设。为了压缩工期，项目管理团队首先考虑的是快速跟进，将二期的开发和三期的开发与四期的需求并行进行。二期为项目建设主体，包含了两个最为关键的子系统，为此在二期开发过程中，安排了进一步压缩工期的赶工，确保在一年半内完成任务。

规划方案草案一出，立即布告各方，充分利用PMBOK教给咱的参考权，借甲方高层的权威和乙方管理层的影响力督促项目甲乙双方干系人再进一步提出整改意见。一时间各方意见齐聚。甲方高层领导马上提出关键要求、乙方管理层提出技术层面的创新要求，甲方某个执行部门反映国家部委对他们的工作标准发生了变化，需要将第三个子系统的建设进度从二期调整到一期……凡此零零总总，滚动规划一招应对。解决了建设范围与建设工期的问题，项目的一个祸根被拔了出来。

试想如果规划问题悬而未决，将会给项目带来怎样的影响，相信这会勾起带过项目的朋友们的诸多回忆。小例一则：笔者之前带的一个项目规模远比这个小，那时候还没有学过PMBOK，从战争中学习战争，有时死都不知道是怎么死的。项目来了就是需求、设计、开发、测试、实施一条龙的往下干。往往项目都开发完了，上线了，某月某日某时，电话突然响起：“那个小谁啊，你们的系统是咋做的啊，我们部门要做的业务咋一点也没有啊，blablabla……”，“请问您是哪个部门？”“XXX部门”。心中暗骂系统分析师，“咋做得需求，老子都没听说过这个部门”。是系统分析师的错么？现在回头想想，系统分析师固然有错，项目经理首当其冲。你项目经理不做好规划，不把项目干系人要求和期望分析好、管理好，人家系统分析师为什么要知道都需要找哪些部门？那个时候，只能焦头烂额的去克服别的项目中根本不会存在的困难，解决别的项目中根本不会存在的问题了。

祸根二：无谓的镀金

PMBOK告诉我们，镀金是不允许的。笔者有好多很有经验的好心的专家级同事，他们都是业务领域内的能人，他们的敬业精神让人钦佩不已，他们有一颗为了满足用户需求宁愿操碎的心。在学习PMBOK之前，我对他们敬畏三分，惊为天人，甚至愚昧加天真的想象，有了这样的人士，需求调研是不是纯属多余了？几个项目下来，加上PMBOK的熏陶，使我改变了看法，镀金这个词汇转为这样的人所创，但镀金的责任与这些人无关。发生镀金谁负责，在我看来，非项目经理莫属。

请看如下故事，用户说对项目经理说我要实现从系统中查询到上个月录入的数据20项，并且可以导出Excel。且看我们的镀金高手如何操作：

场景一：
1、 要求开发人员开发所有表的查询功能（新增模块35个）
2、 所有模块都要有导出功能（导出数据项2302项），并对者2302项数据使用变成技术，自动在Excel中出现图表分析，分为饼图、柱图、折线图……
3、 每个模块都要通过严格授权方能使用，需要创建分类角色35个，如有一个操作者可以操作多个模块，需同时拥有多个角色。
4、 工期一个月，投入设计1人月，开发2人月。共计3人月，设计每人月2万元，开发每人月1.5万元，折合人民币5万元。

场景二：
5、 要求开发人员开发针对20项数据的查询模块(新增模块1个)
6、 针对该模块的导出功能（导出数据20项）
7、 一个模块，无须特殊的授权处理
8、 工期1天，投入设计0.5人日，开发1人日。按每个人月22人日计算，按照上述标准，折合人民币0.1136万元

再看用户拿到结果后的反映：
场景一：
“这是神马？浮云么？我要的20项数据导出结果呢？”项目经理蚊子般的声音：“领导，我们的软件功能强大，可以把这2302项数据从35个模块中都导出来，想要什么你自己挑选啊。。。”，“你们是猪啊？”“这个变更单是不是签一下，成本是5万”，“当我也是猪么？”

场景二：
“领导，您要的需求做好了，点击这个查询，系统会列出您要的20项数据。点击这个导出按钮，系统会将查询结果导成电子表格”。“不错哦，我很满意，变更单拿来签了吧。”
估计场景一：我们的项目经理压力肯定小不了，管理层对这5万块的投入会不会很愤怒？客户还在等他的20项数据导出呢。设计人员眼巴巴的等着得到正面的反馈（项目经理的赞美、用户的表扬），看我设计的系统，功能多么强大，用户要什么有什么，还有绚丽的饼图、柱图、折线图……开发和实施人员往往跟着项目经理出生入死，心中悲凉：“这倒霉蛋这次又要倒霉了，嘿嘿，我们马上也要跟着倒霉”。可怜的项目经理又要去克服别的项目中根本不存在的困难，解决别的项目中根本不存在的问题了。

相信场景二中的项目经理也会有众多高水平的同事。同时也有理由相信，评审工作肯定是做了不少。他在预防镀金方面肯定是很有经验。

再看祸根三：决策三拍惊奇

三拍大家应该都会太陌生，这里的三拍，从拍击部位看：一拍者，拍脑门儿也，二拍者，拍胸脯也，三拍者，拍大腿也。从人员构成讲：一人拍脑门儿，数人人拍胸脯，最后往往大家一起拍大腿。
说得到这里，笔者认为，这才是某些项目，尤其是国内某些地区、行业或部门项目最大的祸根所在：盲目决策，盲目执行，盲目收场。这些都是与PMBOK理念格格不入、水火不容的。上面的两个祸根充其量也就是这个祸根的枝叶而已。这样的故事往往太多了，笔者就不一一列举了。

项目中有各种各样的困难和问题，作为项目经理，当识别到这些困难和问题时，只能作为客观条件、作为项目的输入来加以处理。但是，项目中的某些困难和问题是不是本不该发生，这个应该引发项目管理者的思考。借用李开复先生的话来做本文的结尾吧（为了适应本文，稍有改动）：作为项目经理，我们要有勇气避免可以避免的困难和问题、有胸怀接受不可以避免的困难和问题、有智慧分辨这两者的不同。