在 2009 年 3 月， 我参与了 “苏州工业园区企业综合信息管理应用平台” 项目的建设。 在项目中担任项目经理职务。 整个项目以园区管委会信息中心为依托， 面向园区管委会所有 部门和园区各垂直管理的条线部门（如：工商、质监、国税、地税、公安、海关等）以及所 有的园区企业。该项目分为二个阶段：第一阶段，将园区各条线部门和园区管委会内部部门的企业信息根据统一的业务主键和采集规则进行采集合并从而建立一个全面的、 准确的园区企业综合信息库；第二阶段，在园区企业综合信息库的基础上，将现有的“园区企业网上服务系统”改造成“园区政企交互平台” 。本文结合了我的经验就项目的风险管理作了翔实的论述，包括风险管理计划编制、风险识别、风险分析、风险应对、风险监控等过程；以及风险识别技术：如头脑风暴法，风险检查表，借鉴风险历史数据库的方法；风险分析技术：如风险概率和影响评估、决策树分 析等。此外，本文也讨论了在该项目中针对风险管理的不足而做出的弥补措施。

 

由于以前苏州工业园区管委会内部部门和外部垂直管理的条线部门都是独立进行信息化应用系统的规化、设计及实施，相互之间缺少协调和沟通，比如，很多部门根据自身的 业务需要，都建有自己的企业信息库，企业信息大都由各部门自行创建和维护，数据库重复 建设，相互之间没有共享。很多部门由于缺乏企业信息的有效获取和维护手段，往往数据初始化和创建时还相对比较准确，随着社会的发展，企业的变更、注销信息大多没有及时更新， 导致数据越来越差，园区内、外各业务部门迫切需要一套准确、规范、更新及时的企业综合 信息数据库来满足业务工作要求；另外，园区企业网上服务系统是在2002年开发实施的， 随着企业网上服务业务的推进和发展，园区企业网上服务系统在许多业务流程和政企互动方 面已经显的落后， 园区管委会的领导也希望通过在新的园区企业综合信息库基础上，将老系统进行翻新，加了更多的政企互动的元素，让政府与企业能够更好的沟通、交流和发展。 因为该项目的项目干系人多、业务涉及面广、需协调的部门多、软件接口多、各部 门提供的数据格式多样化，数据范围和数据值不统一。

在这种情况下，项目面临的风险之大 是可想而知的。 项目风险是一种不确定事件或条件，一旦发生，会对项目目标产生某种正面或负面 的影响。风险有其成因，同时，如果风险发生，也导致某种后果。当事件、活动或项目有损 失或收益与之相联系，涉及到某种或然性或不确定性和涉及到某种选择时，才称为有风险。 以上三条，每一个都是风险定义的必要条件，不是充分条件。具有不确定性的事件不一定是风险。 项目风险管理就是要争取避免风险的发生或尽量减小风险发生后的影响。 项目风险管理实际上就是贯穿在项目开发过程中的一系列管理步骤：制定风险管理计划、风险识别、风定性分析、风险定量分析、制定风险应对策略、风险跟踪与监控。

综合来看，该项目有四个特点：⑴项目干系人多，业务涉及面广。工业园区企业综合 信息管理应用平台是面向园区管委会所有部门和园区各垂直管理的条线部门（如：工商、质 监、国税、地税、公安、海关等）以及所有的园区企业。项目涉及面广、用户量大。需要调研各垂直管理的条线部门他们各自能够共享的企业信息以及希望获取的企业信息。 政企交互平台集政府通告、企业活动报名、企业问卷调查、政企互动、信息荟萃、企业用户管理、企业基础信息数据权限、应用系统管理以及统一身份认证(SSO)于一体，涉及到政企交互的方方面面；⑵需求不确定，一直在变；⑶参与人员少，时间太短，前后仅有6个月的时间； ⑷采用了 Framework3.5 架构、Sql Server2008 大型数据库、FusionCharts 图表、指数平滑法预测和 Reporting Services报表等先进的技术，工作难度大。尽管如此，但在大家的共同努力下，基本按时完成了项目。那么我们是如何克服的呢？

首先，识别项目风险，编制风险管理计划和风险应对计划。

风险的类型包括项目风险、技术风险、管理风险。 项目风险主要是该项目需求不明确， 而且变更频繁， 属于新业务， 客户和我们都没有绝对的把握。 技术风险主要是采用了时下流行的 Framework3.5 架构、 Sql Server2008 大型数据库、 FusionCharts 图表、 指数平滑法预测和 Reporting Services 报表, 因为人员少，每个人兼多个角色，不过，幸运的是可以复用别的项目一部分源代码，如数据库操作类、权限管理类等。管理风险主要体现在人员分布在三地办公，无疑增加了沟通的难度，不过我之前担任过多个项目的项目经理，所以项目管理工作经验还是比较足的。所以项目一启动，在基本了解客户需求的情况下，我就召集开发人员、销售人员、公司领导，甚至有项目组人员坐到一起，采用“头脑风暴法” ，大家都来分析该项目存在的风险，同时借鉴历史数据库中的风险数据，取出我们没想到而确实存在的风险条目， 也添加到风险列表里， 然后分析每个风险条目发生的概率、风险级别，而且针对该风险条目制定的应对措施，并形成一个风险记录表。风险管理贯穿项目的始终，风险管理计划和风险应对计划缺一不可。因为风险一直在变，所以在项目的每个阶段都在更新。

其次，制定项目管理计划，化解开发进度的风险。

该项目时间实在太短，仅有六个月 时间。 作为项目经理， 我的压力非常大， 所以我做开发进度计划的时候， 根据最终交付日期， 采取倒推法，将时间逐一分配到各个任务上，同时尽量考虑到任务的并发执行，而且要细化到小时，我使用 MS Project2007 软件，利用PERT 技术，在工作分解结构（WBS）上定义每个任务的开始时间、结束时间，识别关键路径（CPM） ，然后从甘特图就能自动显示人力资源状态图，能自动统计每个人每个任务或者每个时间段的工作量，而且通过这个软件，可以非常方便的拆分任务，定义里程碑事件等。 接着，进行软件需求管理，降低项目范围的风险。在和客户的初步沟通中，确定了需求的大致范围，定下了 12 个模块，然后就针对每个模块讨论实现的功能、数据的流向、模 块之间的接口等。 因为有些业务包括客户在内都不在清楚，所以在需求讨论的时候经常很难达成一致共识。于是，我使用了 WORD 版本控制的功能，几易其稿，需求基本趋向一致。形成了软件功能规格说明书，确定了产品范围，双方签字确认。然后，我用 Excel 做了一个软件需求跟踪矩阵，实际为一个二维表，每行就是一个功能，而且是按层次分解的，每列是一个阶段，从需求定义阶段开始，到设计、编码、测试、交付、维护等阶段。在每个阶段结束 时都来更新这个需求矩阵，主要是更新每个任务的状态（如已批准、已实现、已确认、已删 除等） ，如果功能点的变化，可以在上面增加或者修改、删除该功能点，管理起来非常有效 和方便。另外，我们采用原型开发模式，主要分为两个阶段迭代。我将需求按优先级排序， 先完成客户最想要的功能,在整个开发过程中我都跟项目组成员灌输敏捷开发的思想：个体 和交互胜过过程和工具，可以工作的软件胜过面面俱到的文档，客户合作胜过合同谈判，响 应变化胜过遵循计划。

再次, 制定沟通计划，解决项目沟通的风险。

在该项目中，开发人员、公司领 导、销售人员、客户分别在三个地区，沟通不太方便。基本的通信是靠 Email 联系，大家约 定都用 Outlook Express 收发邮件（设定每 3 分钟检测一次） ，因为同一个邮件，回复次数往往比较多，使用同样的邮件软件，查阅比较方便，跟综起来也容易。而且，邮件沟通有个非常大的好处是沟通的内容都落实在纸面上，便于将来分清责任。其次，是电话联系、电话沟通可能就比较直接，尤其是和客户沟通，效果可能更好。此处，我还建了一个项目组的QQ 群，只要项目成员一有问题，都可以在 QQ 群里及时沟通，增强了沟通的时效性和项目组成员之间的互动性。 我经常把开发进度表打印出来贴在每个开发人员的桌面上，让开发人员 “心中有数” ，增强紧迫感。而需要众人一起讨论的问题，则放到每周项目例会上讨论，较 紧急的问题召开临时性会议。 通过以上方法， 基本实现了有关各方及项目组内部的有效沟通， 及时发现问题、解决问题，避免因各方立场不一致造成严重对立而影响项目进度，避免了因 交流不畅形式重大质量问题。

现在回顾这个项目，我们是在一个周密的开发计划下，在非常短的时间、非常有限的 人力资源的情况下，一一化解了项目的风险，按时完成了项目，客户很满意，也得到了我们 公司管理层的高度评价。我想，这归功于整个团队的配合。作为项目经理，我也充分的利用 了各种项目管理工具（软件）在风险监控、进度把握、需求跟踪等各方面的作用。

虽然基本按时完成任务，但也有很多不足之处：

第一，因为工期紧，开发人员少，所 以经常加班，大家非常的疲惫，而且加班费很少。我也采取了一些弥补措施，如请示管理层 在精神方面做了一些鼓励和表扬，适当的出去聚餐、看电影、参加健身运动，一定程度上缓 解了紧张的氛围，而且大家也没有太多的怨言，否则就要另当别论了。

第二，测试的时间太短，在性能测试这方面没有专业的测试人员，没有全面而系统的测试，所以系统交付之后， 发现了不少问题，虽然没有威胁到系统的运行，但作为项目经理，我觉得如果多给一些时间 和人员，我们会做的更好。后来，该系统在别的客户现场实施时，我们做了多方面的改进， 系统也更趋于完美了；在以后的工作中，我还需要不断的学习，总结经验和教训，为我国电子信息化事业尽一份绵薄之力。