现实中,真正能将工期、成本和质量目标在启动前就定义清楚的项目只占少数;更多的是称为“泛项目”的项目,也就是不能预先将目标、范围等清晰定义而只能大致明确的项目。
新产品研发(如抗埃博拉病毒药物的研制)常是“泛项目”,人们无法预知该项目将遇到何种技术难题、它们究竟需要多长时间才能攻克。
融睿智捷公司的项目经理李炯曾经面对一个产值规模以“亿元”作为度量标准的客户,要为其定制开发的一套价格是以“10万元”作为计量单位的软件。第一次面对客户主管领导(职位是总工程师)的时候,该领导要求:“由于机构多、人员多、场地大,需要在网上共享尽可能多的资料,以方便员工之间的交流和领导层及时掌握实际工作状态。因此,我们需要以各部门(大大小小20多个)整理的资料为基础,连接若干个外部独立软件的数据库,建一个集介绍、查询、统计、共享为一体的综合性内部网站。为配合3个月后国家××部门(主管领导)的视察,该项目必须抓紧完成。”随后李炯的手中多了一份3页的建站内容要求(本书隐去某些细节)。于是,一种前所未有的挑战感在李炯心中油然而生。
接下来,制订解决方案、编制投标书等,再加上一些不为外人知的人情运作,3周后顺利中标。合同中约定,该项目的开发期3个月,维护期1年。
在公司总经理的授意下,李炯成立了一个由技术部“牛人”牵头的5人项目组。“牛人”负责系统总体设计和系统“主要部分”的开发,2名程序员负责系统“次要部分”的开发,还有一名美术设计来负责页面的美工制作。做为项目经理,李炯负责项目的总体把控和协调。
“项目成功后,依托客户的影响力将大大提升我们公司在行业中的地位。”启动会上,
总经理为大家打气。
接下来的过程,正如狂热项目的过程,各位一定都很熟悉。陷阱就在此时被“挖”好了。
首先,客户方的需求暗藏玄机:既要功能全、自动化程度高,又要赶在上级视察时充分表现;其中又面临时间紧、初期构思简单等问题。真可谓“时间短、任务重”。
其次,合作方涉及面广,作为系统构建的主要出发点,系统应能连接众多的外部孤立系统,并从中查询和共享数据。以何种方式保证技术公开的完整性和准确性是片空白(相关系统中包含由国外厂商开发,由国内代理商销售的系统)。
再次,“主要部分”“次要部分”的评价标准模糊,而且也没有人负责划分和解释,这在某种程度上挫伤了几个团队成员的自尊心。
最后,作为项目经理的李炯怎样对项目进行把控和协调也没有明确的定义和授权。
李炯感觉到了问题的严重性,决定针对预见到的问题召集一次项目会议。会议如期召开,参加的成员有总经理、销售副总、团队成员,会议的议题是“在有限时间内的优先开发标准”。最初,会议目的是建立基于判别标准的团队共识,以在3个月时限情况下,能够确定各类内容的开发时间顺序。换言之,短时间内,先做什么、后做什么,给出衡量标准。
可是,会议进程大出李炯的预料。总经理的态度:“客户要什么样的系统,就给什么样的系统,技术的要求就是实现而已。”而且旧话重提“项目成功后,依托客户的影响力将大大提升我们公司在行业中的地位。”销售副总:“我已经争取了这单,你们就一定要做好。”“牛人”也开始表白:“选择我,没错的。”其他人:“领导怎么说,就怎么做。”
李炯慌了,思考了两天,很痛苦的两天,可能已经预计到了失败,然后毅然决定:一是不过问项目技术细节,不表态;二是一切以领导视察为首要目标。
这里,客户的项目目标事实上是不确定的。
首先,一个能及时提供信息的平台是为提升工作效率而设定的业务。
其次,配合3个月后的领导视察是一个政治目标,根本就不在项目的业务范畴之内。
再次,客户把本该属于他们的时间制约转给了公司。
项目应该为客户进行整体规划,遗憾的是走上了“泛项目”之路。
启动会议乐观氛围弥漫,没有实质内容。问题只要还没有发生就不是问题,这也是国内很多项目的实际情况。
工作安排也值得探讨,“主要部分”“次要部分”的划分引入了不必要的竞争。
会议中“拍脑袋”和“拍胸脯”的表现已很明显,大家憧憬成功,而没有人关心目标的具体化、可行性以及项目的过程控制。
通常,作为项目经理,尤其是新技术行业的项目经理,都会遇到“客户逼”“上司压”“牛人顶”的局面。这是任何技术手段都无法解决的矛盾。
在该条件下试图以技术手段来解决矛盾的一切方法都包含幼稚的成分。这些问题已远超纯技术范围,划为公共关系学的范畴也许更合适。