项目风险管理案例分析

1、项目风险管理案例分析风险的不确定性是指风险的发生是不确定的，即风险的程 度有多大、风险何时何地由可能转变为现实均是不确定的。这 是由于人们对客观世界的认识受到各种条件的限制，不可能准 确预测风险的发生。以下是关于项目风险管理案例分析相关内 容，希望文章能够帮助到大家 !项目风险管理案例分析10 年前，摩托罗拉还一直是引领尖端技术和卓越典范的 代表，享有着全球最受尊敬公司之一的尊崇地位。它一度前无 古人地每隔 10 年便开创一个工业领域，有的 10 年还开创两个 成立 80 年来，发明过车载收音机、彩电显像管、全晶体管彩 色电视机、半导体微处理器、对讲机、寻呼机、大哥大 （ 蜂窝 电话） 以及“

2、六西格玛”质量管理体系认证，它先后开创了汽 车电子、晶体管彩电、集群通信、半导体、移动通信、手机等 多个产业，并长时间在各个领域中找不到对手。但是这样一家有着煊赫历史的企业，在 2003 年手机的品 牌竞争力排在第一位， 2004 年被诺基亚超过排在了第二位， 而到了 2005 年，则又被三星超过，排到了第三位。而在2008年5月，市场调研厂商IDC和战略分析公司 Strategy Analytics 表示，摩托罗拉可能在 2008 年底之前失 去北美市场占有率第一的位置。摩托罗拉的当季报也显示， 2008 年第一季度全球手机销量下降39%，手机部门亏损 4.18亿美元，与上年同期相比亏损额增

3、加了80%。败于“铱星计划” 为了夺得对世界移动通信市场的主动权，并实现在世界任 何地方使用无线手机通信，以摩托罗拉为首的美国一些公司在 政府的帮助下，于 1987 年提出新一代卫星移动通信星座系统 铱星。铱星系统技术上的先进性在目前的卫星通信系统中处于领 先地位。铱星系统卫星之间可通过星际链路直接传送信息，这 使得铱星系统用户可以不依赖地面网而直接通信，但这也恰恰 造成了系统风险大、成本过高、维护成本相对于地面也高出许 多。整个卫星系统的维护费一年就需几亿美元之巨。谁也不能否认铱星的高科技含量，但用 66 颗高技术卫星 编织起来的世纪末科技童话在商用之初却将自己定位在了“贵 族科技”。铱星手

4、机价格每部高达 3000 美元，加上高昂的通 话费用，它开业的前两个季度，在全球只发展了 1 万用户，这 使得铱星公司前两个季度的亏损即达 10 亿美元。尽管铱星手 机后来降低了收费，但仍未能扭转颓势。项目风险管理案例分析1 公司背景简介河北 H-A 会计师事务所是河北省财政厅对国有大中型企业 进行社会审计的试点所，承担省直大中型企业的审计工作。具 有丰富工作经验，拥有一批具有丰富实践经验的注册会计师。河北省某研究所是省直科研单位，现有 50 多位员工。在 基于WINDOW平台开发软件方面，具备较丰富的实战技能。河 北 H-A 会计师事务所在审计工作中发现，很多企业都采用了会 计电算化软件，对

5、审计工作提出新的要求。社会审计工作的需 要，对开发计算机辅助审计软件的愿望越来越强烈。所以就联 合河北省某研究所进行联合开发2 实际项目分析2.1 项目介绍该系统基于 windows 和 sql server 进行开发，开发工具是 powerbulider 。项目开发过程中，共生成程序源代码约数 万行，项目开发的难度和源代码行数都比预计的要多。计算机 辅助审计软件具有工作底稿制作能力和查证功能 ; 数据可传递， 能自动生成和人工输入相结合，产生合并抵销分录 ; 能自动产 生勾稽无误的审计报告和会计报表附注 ; 有灵活开放的系统， 方便用户进行二次开发等特点。2.2 开发队伍的风险开发团队维持在

6、 10 人上下，事务所提供 3 人，开发单位6-7 人，有一些人员只能部分时间工作，开发人员能够自始至 终地参加整个项目的工作。开发人员的流动基本能保证工作的 连续性。2.3 技术风险 数据结构复杂，关联比较多。需要创建新的算法或输入 , 输出技术 ;软件需要与其他软件产品的数据库系统接口 ; 客户能 确定所要求的功能是可行的。同时，由于当时审计软件在国内 的应用尚处于起步阶段，开发人员普遍对该系统比较陌生，这 也带来了相当的技术风险。2.4 客户相关风险 用户对自己真正的需求并不是十分明确，他们认为计算机 是万能的，只要简单的说说自己想干什么就是把需求说明白了， 而对业务的规则、工作流程却不

7、愿多谈，也讲不清楚。有的用 户日常工作繁忙，他们不愿意付出更多的时间和精力向分析人 员讲解业务，这样加大分析人员的工作难度和工作量，也可能 导致因业务需求不足而使系统风险加大。2.5 项目按时完成的风险 另外，这个项目也像许多其它软件项目一样，面临着竣工日期带来的巨大压力。项目风险管理案例分析 某油田地面工程项目分两期建设，一期 300 万吨/ 年，计 划于 2011 年 6 月 30 日机械竣工 ; 二期 600 万吨/ 年，计划于 2011 年 12 月 30 日机械竣工。主要包括：原油中心处理站、 电站、气处理装置、注水站、水源站、外输管线、单井、计量 站、集输管线、输电线路等工程。由于

8、该项目规模较大，产生的项目文档种类和数量繁多， 因此在文控执行模式方面，项目部根据项目特点，将文档控制 小组归至控制部，与工程进度控制、质量控制、费用控制等项 目控制职能划在一起，对项目进行统一控制和管理。同时，在设计部、采购部、施工部分别设置文档控制工程 师，文档控制工程师与上述职能部门专业工程师相互协作配合， 从而有效的加强了该项目文档控制各工作界面之间的相互联系。 随着设计、采购、施工等项目工作的陆续全面展开，以及项目 部由国内动迁到了国外，文控人员配置也经历了四个主要阶段： 第一阶段：项目启动，设置了两名文档控制工程师负责项 目前期文档的相关工作 ;第二阶段：随着设计工作的全面开展，增

9、加了两名文档控 制工程师负责国内项目部的文档控制工作，同时增加了一名文 档控制工程师负责国外项目部的文档控制工作 ;第三阶段：随着采购和施工工作的全面开展，增加了四名 文档控制工程师负责国外项目部的文档控制工作 ;第四阶段：随着项目工作的逐步完成，文档控制工程师将 工作重心调整为项目交工资料整理，并最终实现项目文件交付。从上述四个主要阶段来看，对于规模庞大、地点分散的该 项目而言，其控制部文档控制小组的人员配置相对来说较为精简，要实现项目文档控制工作的良好执行，是离不开项目部主要职能部门的文档控制工程师和专业工程师的配合和协作的。项目部虽然将文档控制小组归至控制部，但文档控制小组与其 它项目部重要职能的交流不够，并没有充分介入到项目进度、 质量、费用等统一的综合控制管理中，致使文档控制相对独立， 没能更好的与项目管理结合起来。虽然最终的项目文档控制工 作执行结果令人满意，但此种文档控制管理执行模式存在以下 不足需要改进：文档控制小组虽隶属于项目部控制部，但与控制部自身的 其它职能交流较少，没有设置明确的工作界面与工作接口程序， 没能发挥出与控制部其它主要职能的配合效果，没能起到对项 目进度、质量、费用等进行综合管理控制的作用 ;由于项目工作地点在国内外两地，文控人员分布于项