项目经理在电子政务建设中遭遇的种种困境

竟然不知道该系统为何物，以至该系统进度拖延一年之久，不甚感慨！当然这也和笔者所在公司的管理制度混乱有关。

国家电子政务标准经过几年的酝酿，始终没有掀起她的红盖头。笔者却在几年的电子政务实施过程中，总结了不少经验。今天有时间整理出来，献给业界各位朋友，希望能够抛砖引玉，那怕能够节省国家一分钱的投资，少走一毫的弯路，也就达成心愿了。　

　　困境之一:人员素质困境

　　电子政务工程项目的重点不应在“电子”上面，而是在“政务”上。电子政务应该以政务电子化、提高政府工作效能为指导思想，“电子化”只能做为手段来辅助“政务”这一主导思想。

　　既然“政务电子化”是指导思想，当然其主要干系人就不是“电脑”、“网络”等，而是项目涉及到的各方面人员。包括政府领导、政府部门工作人员、政府信息化工作人员；办事企业、老百姓；项目承建公司、公司销售经理、公司项目经理、公司开发实施人员等。

　　1、政府信息化领导

笔者曾经将政府信息化领导分为三种类型：

　　1.1 精通政务，对信息化工作不甚了解型

　　因为信息化工作在不少地方政府刚刚起步，信息中心是个新建部门，所以有不少信息中心的领导是从业务部门平级调过来的。此类领导应该说精通于政府的业务工作，清晰政府各部门的工作流程。

　　但其欠缺信息化工作的经验，主要表现有：

　　前期调研时不配合，“我花钱了，调研应该不用我动脑筋了吧，你们自己去协调、去收集资料吧”

　　调研报告不确认：“我不明白调研报告写得什么东西”；如果问他怎么修改，他也说不清楚；最后往往造成项目需求报告不能签字确认，项目没有基线

　　系统实施、使用过程中，不断得提出新意见，造成项目进度拖延，甚至于重新开发，当然了，项目经理对此也有很大的责任。

　　对于此类领导来说，项目经理一定要做好充足的心理准备。项目前期采用种种方法给他们讲透系统会做成什么样子，为什么做成这种样子，做成这样有什么好处；项目中期采用正规的项目管理方法，跟踪每一次客户意见，形成正式文档；项目后期要据理力争，阐明不能对系统进行大的修改的原因。

　　1.2 精通政务和信息化工作型

　　此类领导对电子政务有一套独特的见解，又能吸收其它电子政务试点城市的经验，是信息化建设的主力军，必将引导电子政务建设的潮流。

　　遇上此类领导对项目经理即是一个挑战，因为此类项目是较难通过验收的，需要花费大量的心血；反过来说项目管理水平和规划水平肯定会得到较大的提高。

　　1.3 专业人士，但规划水平欠缺型

　　某些信息中心领导本身就有多年的信息系统建设经验，学历水平较高。但是对本部门的电子政务建设没有一个全面的认识。哪些系统应该在一期中完成，哪些系统应该在二期中完成？哪些系统应该做成什么样子？怎么样可以提高本部门的工作效率？如何减少项目实施的阻力？等等一系列问题上，没有一个明确的想法。有可能会造成系统华而不实，无法实施或者使用效果不佳等问题。

　　如果项目经理遇到此类领导，要将各个问题考虑到他们的前面，将各个问题可能造成的结果解释清楚，希望能引起他们的共识。当然了，因为他们是领导，处于一个主动的地位，所以这个工作实际开展起来会比较辛苦。但是只要有理有据，讲究方法，应该会有一个完善的结果。

　　2、政府工作人员

　　应该说，随着电子政务建设的深入，政府工作人员正从各方面经受着信息化浪潮的冲击。不少地方政府把是否配合电子政务建设放在年度考核指标之中，这说明政府各级部门越来越重视信息化工作。

　　但毕竟电子政务才刚刚起步，大部分工作人员对电子政务的理解还不是十分的清晰。笔者在几期电子政务培训中，发现不少令人惊讶的问题，受培训的政府工作人员竟然不知道如何打开与关闭IE？如何开关机？如何输入用户名和密码？

　　项目经理如果不能认识到最终用户的使用需求，不能从他们的角度出发考虑问题，势必造成系统实施过程中步入困境。　　　　

　　3、承建方项目经理

　　项目经理是项目的灵魂，他的思想决定着项目的成败，所以有些客户的招标文件中明确要求，在项目实施过程中不能更换项目经理。项目签定合同后，项目经理就是此项目的“总经理”，直接面对各种客户，协调公司资源，从调研到实施完毕项目。

　　笔者曾经接触过许多“优秀”的项目经理，精于项目管理理论，善于与人沟通，能熟练应用各种项目管理工具，但往往其所主管的项目不能成功实施。本人究其原因，排除外界环境外，是其不具有项目经理必须具备的其它几个主要素质。

　　我认为项目经理应该具有下列几种素质，才算是一个称职的项目经理：

　　3.1 勤奋+忍耐

　　对IT人士来讲，人们也许认为项目经理这个职位不错的吗，权利还挺大的，可以经常陪客户出去玩，又不用开发程序。其实项目经理是确实是一个比较辛苦的职位，薪水不高(比技术骨干、公司红人要低得多)、经常出差(老婆肯定有意见，除非遇到一个比你更经常出差的老婆)、遭遇各种客户的各种要求、在公司内部不太受重视等等。

　　如果项目经理仅仅看中眼前利益，可以说大部分时候应该是得不偿失的，所以很多人没有坚持到项目的最后，就败走麦城了，造成了一个又一个烂尾项目。

　　一个成功的项目经理，应该具有坚强的精神面貌，无论碰到各种挫折，都要对自己负责，对客户负责。

　　笔者举个例子，2003年初，本人在某地市级政府电子政务第一期培训过程中，系统忽然瘫痪，而且再也启动不了了，下面的培训人员包括市委书记、市长、部门一把手等等人员。当时笔者顿时感觉像有一支剑沿着后脊梁骨穿了下去，两眼发直，心里想“完蛋了，这个项目就这么结束吧。”晚上和信息中心的领导在一起喝酒，他们也感觉自己的从政生涯不会一帆风顺了，每个人都是一杯一杯的白酒接着喝，最后烂醉如泥。不过，一个领导这么说了一句话，令我一辈子也忘不了：“小谁啊，不用担心，有问题我来承担，来喝酒”。

　　事后本人极其郁闷，几度想向公司提出辞职。但项目还是照样进行，没有出现想象中的各种问题，而且一个多月后，系统问题解决了，进行了几期更大范围的电子政务培训。本人也不再郁闷了，领会到任何事情只要坚持总能挺过去。这个项目后，笔者将系统的稳定性放在了系统设计的第一位，再好的系统如果压力测试不能通过，什么都是白干。

　　3.2 引导能力

　　一个项目经理的引导能力关系着项目工作量的大小。笔者曾经接触过一个合同额6万的网站项目的项目经理，他在调研过程中，竟然给客户演示某价值百万的网站，希望客户在此基础上提出栏目结构需求，结果可想而知，这个项目花费了大量的成本。而且客户竟然不满意，因为没有这么多的工作人员来维护如此多的网站栏目。

　　所以做项目不是说做得东西越多越好，而是要切实钻透客户的业务，抽象出能用计算机解决的最简单的方法。在和客户沟通过程中，不能被客户牵着鼻子走，要处处想在客户的前面，想到客户还没有想到的地方，方能引导客户按照项目的即定方向发展，使项目成为一个可控的项目。

　　3.3 沟通和表达能力

　　沟通和表达能力是项目经理最重要的能力，有人说项目经理大部分的时间处于沟通过程中，此言不虚。沟通对象有：客户方领导、客户方工作人员、项目组人员、公司领导、公司部门经理等等。无论那一环沟通不力，都可能会造成项目进度的延迟。

　　困境之二:整体规划困境

　　电子政务工程涉及到横向各级人民政府，纵向各部门、厅局，所以很难形成一个统一的电子政务建设标准。比如，前期提出的“三网一库”和“十二金工程”就只能起到指导作用，在实际建设过程中，各级政府部门从实际出发会提出各自的建设需求。

　　但是笔者认为电子政务工程的整体规划却有原则可循，参考这些原则，也可使工程建设少走不少弯路。笔者在下面整理了几条，各位项目经理如果认可本人的观点，可以继续完善补充。

　　规划前，深入了解最终用户的建设需求

　　大多数电子政务项目由信息中心统一规划，而最终使用者是各部门、处室。在规划过程中，经常出现信息中心没有深入了解业务部门实际的信息化需求，而是信息中心领导参考上级领导的意见，制定总体规划，指导该项目的实施。可想而知，这种项目的后果往往不容乐观。

　　信息中心领导和工作人员由于本身是政府工作人员，其对政府业务的把握明显要比开发公司要深入。但是，由于业务工作范围不同，尤其是对横向人民政府的信息中心，不可能全面了解各部门实际的信息化建设需求。如果在项目规划前不进行深入调研，规划的内容范围、质量都可怀疑。

　　着眼于近期实际业务需求，分阶段推进电子政务工程

　　笔者参与过一个电子政务项目，合同中要求的建设内容有：CA认证系统、外网门户、内网门户、办公自动化系统、网上审批系统、基本数据库系统、信息采编系统、财务公开系统、财税分析系统、经济分析系统、应急指挥系统十大应用系统。从内容中我们可以分析出，该方案囊括了的电子政务的近期建设热点(办公自动化系统、门户网站、网上审批系统)以及将来的建设的热点(决策分析、应急指挥、CA认证系统等)。如果按照合同的要求，实施完毕此电子政务项目，可以说，五年内不需要再进行类似的电子政务项目建设。

　　但其中存在的问题是：

　　1)电子政务建设处于探索阶段，各个应用系统基本都是“摸着石头过河”，调研、开发、实施的工作量都相当大。

　　2)由于没有统一的、标准的数据资源的积累，电子政务的决策分析系统的建设时机还不成熟(毕竟电信、银行的决策分析项目才刚刚开始)

　　3)由于协调工作量大，出现要么开发不能按时，按质完成，造成比较大的经济损失；要么开发完成后，项目实施有难度，使系统束之高阁。

　　困境之三:实施困境

　　笔者在几年的电子政务项目实施过程中发现，政府客户普遍存在“重开发，轻实施”的观念。下面笔者举两个曾经做过的实际项目，请各位项目经理参考：

　　1.某纵向部门级电子政务项目

　　该项目调研比较顺利，各处室业务人员、处室领导、信息中心领导都在需求报告上签字确认，认可此项目基线；

　　笔者和项目组成员，是平台、产品软件的坚决拥护者，深入抽象各处室客户的业务需求，规划用三个平台软件解决客户十一个业务系统的建设需求。开发过程比较顺利，提前完成系统开发(当然，开发工程师经常加班)；

　　在公司内部经过几轮测试后，需要在客户方进行Beta测试，但这以后的实施过程却一拖再拖，影响了项目整体进度。

　　2.某地市级政府电子政务项目

　　该项目建设内容包括“并联审批系统”，有下列问题：

　　项目调研过程中，该政府行政服务中心竟然不配合调研，理由是他们自己已经建设了一个并联审批系统，会在近期内上线试运行；

　　笔者将该情况反映给信息中心领导，领导说：“既然他们不配合，就不用调研这个部门了；这个项目的规划、建设部门是信息中心，只要你按照我们的要求建设完成，我们就付款。”于是笔者所在的项目组就按照领导的要求，继续向下开展项目；

　　因为没有最终用户的需求，此系统的开发过程各位可想而知。一版、二版再版后，信息中心领导终于认可此系统的功能；(当然，这和笔者当时的项目管理经验有关，不能跟踪与控制客户修改意见)

　　在实施过程中，由于没有最终客户行政审批大厅的配合，造成该系统只能由信息中心维护少数审批事项的介绍和相关表格，并不能真正的进行网上审批，使项目开发和项目应用严重脱节。虽然由于信息中心的领导能力较强，可以通过市领导强迫要求推广应用此系统，但是由于没有调研最终客户的需求。

来源： 博锐管理在线

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友