`
wangleide414
  • 浏览: 590400 次
  • 性别: Icon_minigender_1
  • 来自: 西安
社区版块
存档分类
最新评论

信息系统项目管理师 范文

 
阅读更多

 

信息系统项目管理师论文范例1:论软件项目的进度管理

  摘要

  本文讨论了《电力行业工作票、操作票系统》的项目管理,在本项目中我作为项目负责人,承担了项目管理工作.

  在本项目管理中,我主要采用了面向对象技术同传统技术相结合的原则,在估算项目的工作量这方面尤为突出,面向对象技术对传统技术有所改进,传统技术能弥补面向对象技术的不足。

  本文从合理的估算项目的工作量及技术难度;识别关键任务;随时了解项目进度,必要时调整进度表等方面讨论了《电力行业工作票、操作票系统》项目管理的基本活动与方法,有效地控制开发进度,确保项目如期按质量完成.本系统在电力系统已经运行,状况良好,受到一致好评.

  正文

  2003年2月,我参加了《电力行业工作票、操作票系统》的开发,担任项目管理工作.电力系统有关部门在对电力设施进行检测、维修、试验等一系列活动时应按照我国电力行业相关标准进行工作,《电力行业工作票、操作票系统》就是按照国家有关标准及电力行业操作规程设计的仿真系统。工作人员在施工前按照工作流 程在此仿真系统上进行操作,严格遵守电力设施的逻辑闭锁关系,顺序执行.有效地防止不规范操作,确保电力设施及现场工作人员的安全,提高安全意识.

  本系统由系统图编辑平台和工作票、操作票签发系统两大部分组成,其中系统图编辑平台主要是编辑变电站、用电系统及变电站控制系统图,每一个电力设施对应一个对象,在系统图上都有相对应的部分,系统图真实地反映电力设施的布局及相互关系,生动形象又合乎技术标准,同时为第二部分提供操作对象.工作票、操作票 签发系统主要是在系统图的基础上进行点击操作,每饮点击对应一个对象即一个电力设施,根据电力设施的逻辑闭锁关系自动生成相应的工作票或操作票或提示操作不规范.

  在本系统的开发过程中,我通过合理的估算项目工作量及技术难度;识别关键任务;随时了解项目进度,必要时调整进度表等方面对项目进行管理,确保本系统如期按质量完成。

  1、合理的估算项目工作量及技术难度

  我们在项目工作量及技术难度的估算上采用面向对象技术同传统技术相结合的原则.

  本系统采用了面向对象的分析、设计等一系列面向对象技术,在本系统工作量的估算上根据功能点进行估算.将每个功能模块逐步分解,直至基本模块为止.我们将系统分为系统图编辑与工作票、操作票签发两个大的功能分别进行估算。系统图编辑部分主要是一个图形编辑系统.一种电力设施对应一个类,电力设施的技术参数 及其操作对应相应类的属性和方法,电力设施图是由线段、圆、曲线、折线、多边形等基本图形组成,这些基本图形分别对应一个类,这些类又继承一个最基本的类.系统图编辑部分的工作量也就是这些类的实现,工作票、操作票签发部分用到了编辑平台的系统图,因此由大量的功能可以复用,这部分的功能划分同系统图编 辑部分一样也是采用类作为基本结构,这样就比较准确的进行工作量的估算.

  同时我们开发的这个系统是基于C/S结构的,由于C/S结构的系统我们公司有不少成功的案例,因此有不少的案例供我们参考.对于本系统的第二部分我们就是借鉴以前我们做过的基于C/S结构的系统,基于C/S结构的系统的框架基本上是一致的,数据库的设计、前台操作如对数据库进行添加、删除、修改、查询等一系列活动大体相同.正是如此,有大量的东西可供我们复用,如权限控制模块我们就是复用以前的案例,仅作少量修改.在工作量的估算上也有很好的借鉴作用.这 对工作量的估算也是一个重要的参考,为工作进度安排提供了依据.

  在技术上,我们重点考虑本系统与其他C/S 结构的系统的不同之处,相同或相似之处我们认为没有技术难点.系统编辑平台主要是绘图,我们知道MFC的绘图功能确实强大,但是过于繁琐,功能封装不是十 分完美,我们采用了Form++这个MFC 扩展类库,这个扩展类库对图形操作封装得很好,大大降低了系统图编辑部分的难度,在界面设计上我们采用了BCG 这个扩展类库,使得VC应用程序界面设计得如同Delphi等工具一样完美.同时减少了工作量,在工作安排上,技术难度相对大一点的部分我们安排经验丰富 的程序员,同时也同其他工作组的成员商讨技术细节间题,同他们进行技术探讨.这样不至于因为某一技术细节而影响整个工程进度.

  根据上述分析我们制定一个详细的进度表并定义相应的里程碑.

  2、识别关键任务

  系统图编辑部分是整个系统的基础,因为工作票、操作票签发部分是建立在该部分的基础之上,系统图编辑部分直接影响到整个项目.因此该部分是整个系统的关键部分,在这部分中每种电力设施所对应的类及其父类的定义是关键,因为所定义的类必须完整、准确地反映该电力设施的技术参数和操作.

  工作票、操作票签发部分,是用户明确提出的要求实现的功能,直接面对用户,这部分的成功与否直接影响到该系统的质量,因此也是不容忽视的.

  如果上述两部分任务的进度受到影响,则整个项目的完成将受到威胁.因此是本项目的关键任务.在进度控制时我们将其作为重点对象进行控制.

  3、随时了解项目进度,必要时调整进度表

  在确定项目开发计划时,我们制定了详细的进度表.我们在确定每一项任务时都确定该任务的工作量、开始时间、持续时间、结束时间.同时让每个小组成员知道自己所承担任务的时间表,小组成员根据自己的任务制定自己的详细工作计划.

  工作日志是了解每个小组成员工作情况的很好的方式,我们要求每个小组成品对自己的工作都要做工作日志,对自己每天的工作做详细记录.每周对自己的工作进展做出结论,向项目组汇报.在做结论时,不得使用“差不多”、“大概”、“完成了90%”… 等模糊字眼.而是采用某任务“已经全部完成”、或者“90%的工作全部完成”或者“再过1 天全部完成”…等方式.每个小组成员对自己做出的结论负责,这样可以做到随时了解项目进度,为调整项目计划提供客观基础.

  同时我们在项目进度计划中根据项目设计定义了相关的里程碑,在每个里程碑我们都采取小组会议形式对本阶段的工作进行确认、总结,对本阶段的进展情况做出结论,并决定是否调整下一阶段的进度计划.

  在系统图编辑部分我们认为各电力设施所对应的类(包括其父类)定义完成为一个里程碑,每个类是否具备了相对应的电力设施的技术参数及操作是该里程碑的标 准,这些类(包括其父类)的实现完成又为一个里程碑,… … 整个系统图编辑部分完成也是一个里程碑.每个里程碑的标准在系统设计时已经定义好.

  结束语

  《电力行业工作票、操作票系统》目前已经开发完毕,运行状况良好,受到一致好评。在本系统开发的整个过程中采用了面向对象技术同传统技术相结合的原则,因为小组成员的各有特长,面向对象技术不是每个小组成员都熟练掌握,加之面向对象技术在我们公司还不是很成熟,必须有一个过渡,不能一下子转型,因此采用该 种策略符合我们公司的现实情况。

  由于项目进度管理得当,项目按期完成,我们小组赢得公司的好评,其他小组也研究我们的管理方式。当然项目管理方式多种多样,根据项目不同、人员不同管理模式应做调整而不是一成不变。适合本项目的管理模式才是最好的模式,先进的管理方法在不同的项目组中取得的效果是不同的,这有待于我们去研究,探索,实践, 总结.

信息系统项目管理师论文范例2:论软件项目计划的制定

  摘要

  本文讨论了一个作者参与的软件项目的项目计划制订的若干问题.项目所开发的产品是一种智能电子教学设备,该设备可以实时同步地将用户在硬件端的书写内容显示在计算机屏幕上,并可以保存、编辑、打印用户输入的数据,联网的计算机也可以实时观看用户的书写过程,并且用户还可以通过投影在硬件端的PC机画面交互操作PC机.

  作者是该项目的软件开发组负责人兼软件架构师.作者针对项目计划的制定采取了:分而治之,逐步求精,经验数据三个主要策略,从而得到较好的效果.

  正文

  2002年6月,作者所在公司启动了一个项目,该项目开发出来的产品是一种智能教学设备,该设备可以实时同步地将用户在硬件端的书写内容显示在计算机屏幕上,用户可以保存、编辑、打印通过硬件端输入到计算机的书写内容,联网的计算机也可以实时观看用户的书写过程.另外,用户还可以通过投影在硬件端的PC机显示画面交互地操作PC机.作者有幸全程参与该项目的开发,并且担任了项目PC机软件开发组的负责人兼软件构架师的角色.对于这种实时通信且具有联网功能的软件项目,我认为首先需要制定一个良好的项目计划,才可以保证项目开发的成功.

  总结这次项目的经验,我认为行之有效的策略有三个,分别是分而治之、逐步求精、经验数据。下面就结合这三个策略详细讨论本次项目计划的制订。

  一、分而治之

  将一个过于复杂的问题分解成若干复杂度不那么高的小间题来依次解诀,这种方法人类已经采用了几千年.这里我们也可以用于项目计划的制定.因为整个考虑项目的方方面面来制定计划其复杂度已经超过了人类处理问题的能力.为了解决这个问题,可以将整个项目分解为一些更小的组织体,逐一进行处理,这项工作也就是项目管理中的WBS(工作分解结构)。

  比如针对这次项目中采取的RUP开发过程模型,我在完成需求管理计划时我就将计划内容分解成初始、细化、构建、移交四个阶段来分别制定,最后合到一块儿就是完整的需求管理计划.

  除了按时间段分解的角度来制定项目计划,我制订软件开发计划时同时按照了RUP过程方法的工作流的概念来分解项目计划的制定工作,根据每个工作流在四个阶段业界通用的工作量估计来制定计划,安排工作人员以及相应的软件资源。因为软件开发计划涉及到多个工作流,我认为以这种方式分解是合理的.同时因为本项目的特点,我省略了业务建模工作流,这是因为这次的产品是以硬件为主,软件为辅的消费类产品,所以业务建模不是那么必要了.以不同的方式分解项目,可以从多个不同的角度来制定整个项目计划,有利于全面、深入地了解项目,避免“瞎子摸象”的情况发生.

  二、逐步求精

  计划工作其实是一种管理未来、管理未知的工作,而未来是变化莫测的,还存在许多自身无法掌握的因素,因此存在很大的难度.而解决这一困难的法宝就是逐步求精.按照先框架后细节,先粗后细地进行项目的计划。

  比如在这个项目中,在接受这个项目后就开始了做了一个初步计划,这个计划的内容主要是做出时间上的安排.因为打算在2003年的月需要用这个项目的产品申请国家中小企业创新基金的支持,所以完成时间就定在了2003年4月,预留一个月用于写申请报告.总的时间进度确定后,大概分配了三个时间段:系统工程分析、软件开发模型确定、软件产品制造时间段、项目总结.

  等到确定这改项目后的RUP 开发模型后,就可以继续对项目计划进行第二改求精了。其实RUP 过程中出体现了逐步求精的理念,比如在初始与细化两个阶段都要产生出项目计划的制品.这样我就可以在这个两个阶段对项目计划逐步求精,比如在初始阶段只是将我需要完成的项目计划分为了需求管理计划、软件开发计划、实施计划,然后在细化阶段我再具体地制定每类计划的详细内容.

  比如在初始阶段时架构设计考虑以MFC为平台,根据这个决定软件开发计划的制定是比较粗略的,在细化阶段架构设计进一步详细,这时已经清楚各个模块和MFC的Doc/View主结构的接口定义,以及各模块之间的接口定义,这时我就可以根据所需开发的模块制定计划。比如这时我就计划了特效界面模块开发分两次迭代,第一次迭代计划一个月时间,第二次迭代两周时间,第一次迭代需要完成放大和缩小、树形选择、缩略显示等主要的界面效果,第二次迭代的主要任务是根据用户反馈进行修改调整。

  三、经验数据

  要制定一个良好的计划离不开精确的估算.不过项目计划是在项目开发的早期制定的,而在早期要完成精确的估算是非常困难的.要解决这个问题的关键就在于“经验数据”.由于整个软件产业都还十分年轻,经验数据的积累都普遍不足,才导致这一现象的出现。

  但是因为这次项目开发的产品在国内还没有开发过,再加上公司没有积累深厚系统的项目历史数据.针对面临的困难,我选用了FP功能点分析作为项目主要的估算方法.因为FP方法中有大量项目经验数据可以从网络上获得,同时其数据功能TLF、EIF,以及事务功能EI、EO、EQ的计算对经验数据依赖不强,只需对概念理解正确一般就可以正确估算了.在估算成本的时候,因为公司以前的生产率数据是以LOC为单位的,我利用软件工程书籍中的“逆火”经验数据,将LOC转换为功能点单位,当然,这里必然导致一些误差。为了降低估算误差,最后使用Delphi专家分析法对估算结果进行了调整。

  Delphi方法是一种集策法,也就是通过多名专家对估计值的不断校正的方法.当然,请专家增加了项目成本,不过最后得到高质量的项目计划还是值得的.比如,在某专家的建议下我们改变了自行开发网络层组件的计划,而是采购现有的完全可以解决项目需求的成熟的中间件产品,这个策略的调整在后来证明是正确的.一开始犯错误的原因是由于我们网络开发经验不足把用户需求想复杂了。

  最后谈一下使用的工具软件.在制定项目计划过程中我采用了Microsoft的Project 2003绘制甘特图.因为项目的进度安排是和项目中每个人都是息息相关的,所以在做甘特图前我首先征集了大家对文字和条形图效果的意见,然后按大家的意见进行了美化,比如用鲜艳的颜色标识关键任务,放大任务摘要信息,突出里程碑信息等.这在有些项目管理者看来似乎是小事,不过我认为一个赏心悦目的甘特图可以带给观看者好的心情,而好的心情可以大大提高工作效率。

  同时,考虑创新基金支持的项目在交互期限上有很大压力,所以在定义甘特图任务的依赖关系时我采取了业界惯用的“时间盒”的技术,也就是在每个任务的任务信息对话框中“前置任务”一栏中的“延隔时间”我填入5%-15%,也就是说当任务完成90%左右时就可以结束转而执行下一个任务.因为本项目中的所有人员几乎是全程参与,所以我不是很担心每个任务遗留的少量问题在下一阶段没有负责人去解诀。

  配合Project 2003使用的估算软件是Software Productivity Research的KnowledgePlan.这款工具软件的最新版加强了对Microsoft Project 2003以及RUP开发模型的支持,而且其中的Project Template功能允许用户采用自己定制的WBS来进行估算,这些因素使得KnowledgePlan对本项目的项目计划成功制定带来很大的帮助。

  在上述三个策略的指导下,以及合适工具的辅助下,使最后形成的计划有效地指导了后期的开发活动。项目开发出来的产品通过了专家的鉴定,获得了国家中小企业创新基金的支持。

  项目完成后发现的问题是早期计划的估算结论偏差还是较大,看来还是受到缺乏经验数据或者经验数据不够精确的影响,所以在以后的工作中需要开展有效的度量的工作,为公司积累覆盖面广且尽量精确的经验数据。

信息系统项目管理师论文范例3:论软件开发成本管理

  摘要

  2004年8月,我作为项目经理开始参与某某银行授信业务系统的开发项目,主要工作职责为需求分析、系统设计和项目管理.系统基本功能包括:业务操作、业务提醒、基础资料、查询统计和权限管理等五个模块.系统采用Struts + Hibernate主流Web应用框架,实现Web应用程序服务器WebSphere与协作应用程序服务器Lotus Domino的高度集成。

  项目的成功很大程度上归功于在项目过程中各个阶段对进度和成本的有效管理和控制。本文以该项目为例,结合作者实践,讨论了信息系统项目中的成本管理问题,主要通过在计划阶段做好工作量估算,有效管理和控制风险因素,在实施阶段进行成本跟踪和控制等方法来有效管理和控制项目成本.实施结果…

  正文

  2004年8月,我作为项目经理开始参与某某银行授信业务系统的开发项目,主要工作职责为需求分析、系统设计和项目管理.当然也做一些编码工作,主要是基础性公用代码和关键核心代码的编写与维护.授信是指银行以自身信用向客户提供贷款(包括项目贷款)、担保、开票信用证、汇票乘兑等业务,授信业务是商业银行资金运作中最为重要的业务之一。开发授信业务系统,提高授信业务的管理水平和运行效率、充分利用共享的信息资源、减小各种风险、运用各种科学的金融分析模型指导业务开展具有十分重要的意义.系统基本功能包括:业务操作、业务提醒、基础资料、查询统计和权限管理等五个模块.系统全面实现授信业务的网上操作,实现流程的上报,审批和管理,大大提高了授信业务工作效率。提供了强大的业务查询和统计功能,便于对授信业务工作的管理和监督.其中业务操作模块实现授信业务工作流程,主要包括正常类授信业务申报、问题类授信业务申报、特殊类授信业务申报和授后监控业务等工作流程。

  系统采用Struts + Hibernate主流Web应用框架,开发工具采用WebSphere Studio Application Developer 5.0 (WSAD 5.0),WSAD 5.0集成并扩展了Eclipse 2.0的功能.硬件配置方面:IBM P610小型机用于安装WebSphere 5.0,DELL服务器用于安装Domino R6和SQL Server 2000。实现Web应用程序服务器WebSphere与协作应用程序服务器Lotus Domino的高度集成,并使用Single Sign On(SSO)实现单点登陆.总体架构思想,将表单数据的生成和分析采用关系型数据库来实现,通过WebSphere架构实现业务逻辑的处理,而表单的审核流程由Domino进行驱动.将基于业务为主的J2EE服务系统和基于协作为主的DOMINO流程处理系统有效的结合起来,确保整个业务流程的有效运行和各种数据查询分析统计的有机结合。

  由于考虑到银行帐户年度等因素,客户要求系统在2004年12底前交付,项目开发周期为4个月。项目人员配备情况,项目经理l人,开发人员4人,测试人员3人,界面美工人员1人,项目行政秘书1人,配置管理人员1人,质量管理人员1人.其中开发人员小张来自某某银行科技处.项目行政秘书、配置管理、质量管理等人员为兼职人员,为多项目共享。由于公司属于大型软件企业,在项目基础设施方面包括开发服务器、开发机、测试服务器、配置管理服务器、开发工具等配备状况较好。

  软件成本管理是软件项目管理的一个重要组成部分,也是一个十分容易被忽视但却又是十分重要的内容.成本管理的目的是通过执行项目成本管理过程和使用一些基本项目管理工具和技术来改进项目成本绩效。项目组整体上把按进度和预算交付项目作为我们最大的挑战,因此我们十分重视对项目进度和成本的控制和管理.该项目中我们借助项目管理软件Microsoft Project 2003来辅助进度和成本的计划和管理.我们主要通过在计划阶段做好工作量估算,有效管理和控制风险因素和在实施阶段进行成本跟踪和控制等方法和策略来有效管理和控制项目成本。

  1、计划阶段做好活动历时(工作量)估算

  项目需求分析阶段结束,《软件需求说明书》得到客户正式签字确认后,我们开始创建工作分解结构WBS和制定详细项目进度计划.我们认为工作量估算是成本估算的基础,对于项目成本管理+分关键.由于对代码行(LOC)估算、功能点(FP)估算等估算方式研究不是很深入,工作量估算主要采用基于公司项目历史绩效数据库和个人经验的估算方法.对于部分涉及流程的活动单位一般比较难一次性把握其活动的历时,事实上流程调试的工作量在页面基本功能(增加/删除了修改)的3倍工作量以上.例如业务操作模块——问题类授信业务申报——问题类客户行动计划申请流程页面提交工作量为2日/人,而流程调试需要涉及20多个角色和8条路径.对于估算把握不是很好的任务,我们一般通过提供一个乐观估算A、悲观估算B、正常估算M进行3次估算然后利用PERT公式[1 ( 4 * M + A + B)/6]计算取整.每项活动我都先确定具体人员,然后需要对活动本身进行详细分析,必要时查看公司项目历史绩效数据库。最后需要为各项活动建立了依赖关系,明确各项活动的前置任务,活动开始时间和结束时间.总体上讲活动历时估算工作量较大,我花费了数个工作日。

  项目组人员流动率较低,在J2EE和Struts架构下的WEB应用开发已经有一定的项目积累和团队合作基础.如项目组自行开发了功能完善的Struts-config.xml统一维护工具,实现了FormBean和ActionBean方便管理。有大量可供复用的东西,如公共基础代码包,权限管理模块等.这些也是在我们工作量估算中需要考虑的因素。

  2、有效管理和控制风险因素

  项目中我们对项目风险进行了必要的管理,以避免风险事件的发生引发项目成本增加或超支.公司项目管理部门提供了风险管理计划的模板和风险事件列表模板.为了让项目组整体在各个阶段保持良好的风险意识,我尝试采用了“十大风险事项跟踪”,把项目中各主要风险事项按照排名张贴在公告栏上.由于当时有部分未明晰的需求包括:①问题类客户行动计划申请流程;②查询统计部分需求;③客户方面可能提出的新需求.需求和范围界定不清、计划不充分、用户参与不足、缺乏领导支持、技术问题等为我们项目计划阶段主要风险事件.事实表明,这种做法效果是非常明显的.特别是客户方面,我定期把风险事件列表Email给客户方项目负责人方某.为了能尽快落实未明晰的需求部分,我与客户方主要项目负责人方某进行了面对面的沟通.通过一番利弊关系的陈述,达成尽快明晰悬留部分需求的共识.需求问题很快得到解决.项目组整体信心十足,积极性和责任感增加.公司领导方面对项目组也表现出特别的关心,特别是公司赵总开始频繁出现在项目组的每周进度评审会议上,他们也开始担心因为对项目支持不够而导致项目的失败。

  3、实施阶段进行成本跟踪和控制

  实施阶段需要进行成本的跟踪和控制.Project 2003中需要设定各项资源(人员)的工时标准费率,即人员每小时的工作成本.项目组成员每周五下班前通过内网B/S项目管理信息系统PMIS提交《项目周报》,把各自本周内完成的任务进度情况和下周任务计划进行汇报.报告要求按百分比严格量化任务完成情况,PMIS只提供具体百分比的选择.项目经理(我)把各项任务实际完成数据输入到进度计划中,Project 2003自动成本统计表,清楚显示任务基准和实际成本信息.通过查看跟踪甘特图就可以较好把握项目总体的进度绩效。

  授信业务系统在2004年12月下旬正式上线,提前1周完成了项目.目前系统运行正常,受到客户方各有关部门的一致好评,对项目满意度较高.项目的成功很大程度上归功于在项目过程中各个阶段对进度和成本的有效管理和控制.没有成本管理,项目也可能成功.但没有成本管理的项目,对于项目管理质量、时间、成本三大目标的实现是具有巨大风险。

信息系统项目管理师论文范例4:论软件开发的风险管理

  摘要

  本文讨论了某公司实施SAP系统的风险管理.该公司原先运行着一套ERP系统,现在要转到SAP上,需要完成新系统的流程的重新定义,数据的切换,用户的培训等工作.项目要求在11个月的时间内完成.实施一个大型的ERP系统有着各种的风险,这些风险如果不加分析和控制,将会给整个项目造成致命的影响.我作为项目经理,主要从控制进度风险,人员流动风险和系统功能风险三个方面去进行风险的管理.最后这三方面的风险都得到了有效的控制,从而使项目顺利完成.

  正文

  2003年1月,我参与了西门子集团下某公司的SAP留系统的实施,提任项目经理.该公司之前运行着另一套ERP软件:QAD的MFG/PRO系统.由于集团总部的要求,要用SAP 系统替换原先的MFG/PRO系统,并且要在2003年11月前完成.整个项目完成以下阶段,首先是项目的引进,包括成立项目小组,由顾问对项目小组成员进行初步的培训,让小组成员对SAP的标准流程有个大概的认识.接下来是要分模块进行讨论,制定出各模块的实施蓝图(blueprint).该公司实施了以下的模块:SD(销售与分销),MM(物料管理),CO(成本控制),QM(质量管理),PP(生产控制),FI(财务核算),CO(成本控制)等.在Blueprint 完成后,由顾问根据定下的流程配置一个测试的系统,用户在该测试环境下进行练习和测试.测试完成后就是数据的准备和切换了,要从MFG/PRO系统把需要的数据下载下来然后你上传到SAP系统。完成数据的切换,SAP系统正式上线,同时不再使用原先的系统。

  因为整个项目要在11个月的时间内完成,时间是非常紧迫的.如何在如此短的时间内使项目能顺利进行,控制各种可能出现的风险是必要的.为此,在项目的初始阶段,我召开了小组成员开会,专门针对项目的风险进行了讨论.会上,大家把想得到的风险都提了出来.经过分析筛选,我最后确定了三个重点进行控制的风险,并采取了相应的措施进行控制.

  1、控制进度风险

  ERP的实施是一个大型的项目,涉及到企业的流程改造和其它方方面面的东西.而该项目的上线时间不能改变,所以,项目进度在这里是个潜在的风险,如果不能如期上线,则公司的运作将会受到重大的影响.为此,我在项目启动后,召集了项目小组成员开会制定项目计划.我首先用Microsoft Project制定了项目的总体计划,在这个总体计划中,明确了各个阶段的任务和完成时间.如什么时候完成设计蓝图(Blueprint),什么时候进行关键用户的培训,什么时候进行测试和练习,什么时候进行数据的切换等.总体计划制定出来后,各顾问在总体计划下制定各模块的实施计划,把每个模块在每一阶段的问题细化.各模块的实施计划要在总体计划的基础上进行,在任务和时间上不能滞后于总体计划.无论是总体计划和实施计划,都要求明确各步完成的时间,要精确到哪一天,而不能用模糊的描述,比如“3 月初完成Blueprint”这样的低描述是不充许的.为保证项日照进度进行,每周五都要召开项目会议,检讨项目的进展情况,发现有超期的任务,分析原因,及时解决.在进度的控制方面,还要应付突发的事件造成的影响,及时地调整计划以适应新的情况.2003年4月一5月,由于受到“非典”的影响,外部顾问不能出差来我公司,这使项目的进度受到了很大的影响.为了把这种影响降到最低,我即时调整了项目计划,把这段时间安排为关键用户的培训和对系统的熟悉。因为之前顾问已对关键用户进行了一些培训,所以用户对SAP 系统有了一定的认识.通过上机的操作,更进一步了解系统.有问题我们通过E-Mail与顾问联系。通过这种方法,把原本以后进行的用户练习提到了前面.虽然没有顾问的现场指导,但通过自己的摸索对系统的印象更加深刻,为之后的工作打好的基础.

  2、控制人员流失的风险

  在实施SAP过程中,有两种可能会导致人员的离职,一是工作繁重乏昧,压力大;二是积累了一定的SAP经验后找工作相对比较容易,这时如果有其它更好的机会,员工会考虑跳槽.而项目小组人员流动将会对项目造成很大的影响,甚至导致项目的失败.所以如何控制这些风险,是作为项目经理要考虑的问题.为此,我首先与人力资源部一起,制定了一套有效的激励机制.包括,把参加SAP项目作为年终的一个绩效考核内容,因为项目需要加班加点的,公司免费提供晚餐;设立项目基金,对表现突出的小组成员进行物质上的奖励;在整个公司的范围内大力宣传SAP,让项目小组成员感觉到SAP 的重要性和实施项目的价值等.其次,为了避免出现某个项目小组成员离职导致项目不能进展的情况出现,我在每个模块都安排了两个人员负责,一个是主负责,一个是次要负责.这样,可以减少人员流失造成的损失。在这里,我没有采用让项目小组成员签合同的方法,即实施项目后要在公司工作多少年。我觉得这种方法会给小组一种压抑的感觉,而公司主要靠企业文化来吸引员工.事实证明,我所采用的措施是有效的:在整个项目的实施过程中,没有一个小组成员退出或是离职.在项目运行一年多来,只有两个当时的关键用户离职,而他们离职后后备人员可以马上顶上来,对系统没有造成什么影响.

  3、控制系统的功能

  有人戏称SAP是“Stop All Production”,这也从一个方面反映了实施SAP的风险所在.而造成上了系统后停产的一个原因就是系统功能不能满足物流和生产的需要,这也是我担心的一个问题.因为切换后系统不能再使用,如果这时候新系统满足不了需要,就真的会造成停产.为此,我在项目中采用了演化型的原型开发方法,用演化型的开发方法,可以让用户针对已配置好的原型进行测试,发现不能实现的功能及时提出来,改进后再测试,再改进.在这里,测试工作显得很重要.为此,我强调一定要做好测试工作.在系统测试阶段,我把所有的项目成员集中在会议室中进行系统测试.在测试中,我要求用真实的数据,模拟真实的环境进行.系统测试通过后,我还特别做了一次上线前的演习,即把所有相关的数据都导致SAP,配置一个上线后要用的系统,在此系统上进行操作.这次演习成功后,坚定了大家使用系统的信心.系统上线后也没有出现什么大的问题.

  通过以上措施,使把SAP的主要风险基本上都控制在萌芽状态,项目没有因为这些风险受到影响,最后项目如期上线,受到了管理层和用户的肯定.

  在项目进行过程中,有些风险并没有事先预计出来.比如说顾问的问题.有的顾问水平高,但项目也多.用在我们这个项目上的时间就比较少,这给项目带来了不利影响.为此,我通过和该项顾问所在的公司签定合同,注明顾问在我们公司的工作时间,否则属违约,通过这一方式使顾问的管理得到改善.

信息系统项目管理师论文范例5:利用CMM保证软件质量

  【摘要】

  本文论述了如何在一个规模较大的网上管理系统的开发中结合CMM二级的框架要求,以及软件工程学的质量保证策略进行项目的软件质量保证工作.

  本项目的特点有:

  ( 1 )开发人员多,有40人左右;

  ( 2 )采用面向对象分析与建模技术,JAVA语言,WebLogic应用服务器等以前项目中未采用过的开发模式和技术.因此不确定性因素很多,急需采用有效的质量保证策略.公司为了提高软件开发能力,已经于近期全面引入了当今软件界正在流行、且行之有效的CMM质量保证体系,并在顾问公司和主评审员的帮助下,由公司的SEPG结合公司实际,制定了初步的规范体系和模板文件,并决定将本项目作为试点项目.

  本文详细论述了作为SEPG 负责人之一,并且担任本项目质量保证人员的笔者,是如何在本项目中有效推行CMM二级质量保证措施的,并指出了其中的经验教训和有关的建议.

  【正文】

  本项目是一个面向政府管理部门,全市房地产企业和个人用户的网上管理系统,它既是一个电子商务项目,又是一个电子政务项目.本系统采用了B / S 结构,融合了政府部门和房地产企业的内部网上管理系统于一身,同时作为全国建设系统信息化的一部分而实现Inter-net平台上的上下集成.它还提供信息发布、房屋交易等电子商务功能。

  本项目对系统的安全以及可靠性等方面有着较高要求,公司决定采用三层架构模式的J2EE环境作为运行环境.另外,本项目参与人员众多,面临看新技术、工期紧等影响软件质量的不利因素,对软件质量保证工作提出了很高的要求.本人作为公司CMM实施工作的负责人之一,以质量保证人员的角色参与到项目的开发和管理工作中,主要负责质量保证策略的建立以及实施工作.

  一、以CMM二级理论为指导,采取措施保证开发过程与开发规范的符合性,以过程质量的提高来保证产品的高质量

  1、建立起明确的权责制度,减少因权责不明而产生的混乱

  为确保质量保证人员有独立的途径向公司反映开发中的问题,同时为了避免质保经理与项目经理、软件配置经理之间过分隔阂,本人在项目启动阶段,起草了《项目管理人员责任书》,并由相关人员评审通过;并提议公司设立了高级经理交涉,以快速处理纠纷.为防止开发人员与项目管理人员在规范化开发过程中过度依赖规范而主动性不高,以及可能产生的相互埋怨,制定并实施了《项目开发人员守则》,由各项目级每个成员在参加项目之初进行签名式确认,以解决开发过程中应规范滞后和实施不力而引起的混乱问题.

  2、以制定的《质量保证计划》为纲,全程监控各开发工作的过程建立和符合性问题

  在项目启动阶段,就依据CMM二级要求和公司发布的项目开发规范,制定并基线化《XX项目质量保证计划书》,在计划书中详细地制定了质量保证工作的内容和进度安排。

  计划书中主要有职责、培训工作、检查评审及组织工作等四方面的内容.

  职责方面详细说明本人作为质量保证人员在项目中的全责以及主要活动,澄清了与各开发角色的关系,主要起到项目成员监督质量保证人员的作用.

  培训方面指明了为有效推行CMM质量体系而进行的有关培训,有CMM基础理论方面的,也有本项目特色的规范方面的培训内容。

  检查评审方面指出了要检查评审的过程及提交产品,并列举了相应的通过准则,即CHECK-LIST.比如要评审的过程有项目规划阶段;检查项目经理和配置经理是否按有关规范制定了各自的计划书;项目组的技术评审活动是否符合评流程和规范;风险分析过程和任务分解过程是否符合规范的执行.对提交的工作产品,如需求文档和设计文档,是否经过了正式技术评审并基线化.这些都指明了切入时间和建议人员.

  组织工作方面指明QA(质保人员的简称)在开发过程要做的组织工作,如技术评审工作、测试工作、估计和工作细分等工作.这些组织工作主要是为了协助项目经理开展工作并能有效且及时地获得第一手质量方面的资料.

  对项目开发过程中的跟踪和检查,主要采取了现场参与、分析项目成员日报和周报、个别交流以及项目周例会的形式.

  二、以RUPCN和软件工程方面的理论为指导.制订了行之有效的技术规范文件

  CMM质量体系更多的关注软件开发过程方面的事情,也就是建义由谁在什么时候做哪些工作,但没有指明各个工作如何开展,也就是偏重于管理,偏轻于技术指导.为了避免在框架方面很有效,但应实现细节不明确而出现的“一条腿走路”的现象,特在项目启动之初就制定了要建立的技术规范,如需求文档编写指南、界面设计规范等.这些都列入QA的计划中了.考虑到本项目采用了面向对象的分析和设计技术,急需UML和Rose技术方面的指导性文档,因此将与UML高度相关的RUPCN体系为主要参考,其他软件工程理论为辅助参考,组织资源开发人员制定了各个开发阶段的规范性和指导性文档.

  实践证明,项目组成员有了CMM过程方面的规范,又有了指导开发工作的详细技术文档后,开发质量有了质的提高.主要体现在以下几点:

  1、各个过程的效率提高了,从而保证了各个交互成功的质量.

  比如,人员的选择,时间的必备,开展的流程方面真正按照CMM的建议做了,这些都保证了开发过程的高效.一个显著的例子就是技术评审过程.如果选择的人员资格不够,所花的评审时间很少,开展的时机不对,就很难保证提交成果的质量.

  2、人员之间的交流变得有效,自信心更强了.

  三、不足亟待改进之处

  由于是初次按照CMM的要求在项目中实践QA工作,因此不可避免地有一些不足之处,主要有:

  .因培训工作的不及时、不全面,导致QA实施工作遇到了一些麻烦.

  .度量数据的收集和分析工作做得还不够.仅仅有少量的度量数据,分析工作也很少.总的原因是缺少一个有效的度量数据收集和分析机制.

  总之,这次项目的质量保证工作基本达到了CMM二级的框架要求,证明了过程质量是产品质量的重要因素,为本项目顺利地、高质量地完成做出很大的贡献.但也有很多教训值得吸取,需要在培训工作和QA度量数据收集和利用方面下更大气力.

信息系统项目管理师论文范例6:论信息系统的需求管理和范围管理

  摘要

  在2003年9月,我参与了“某省毕业生就业公共网”项目的建设.在项目中担任项目经理职务.该项目作为“数字**”的重点工程,受到了省政府和“数字**”领导小组领导的高度重视.系统以省人事厅为依托,面向全省各级政府人事部门,大中专院校,中介机构、用人单位和毕业生.集就业指导、政策宣传,人才交流,就业手续办理,政府宏观管理于一体。堪称我省至今为止,最大的电子政务项目之一。本文结合作者的经验就项目管理的需求管理和范围管理作了翔实的论述;并就项目过程中采取的措施、方法作了介绍.最后,列举了该项目范围管理的一些不足之处.

  正文

  一、项目概述

  为进一步加强我省毕业生就业服务体系建设,加强我省人才资源的宏观管理与合理配置,为我省广大毕业生和用人单位提供便捷的人事人才服务;在省领导、省人事厅和“数字**”建设领导小组的高度重视和支持下,“**省毕业生就业公共网”(下简称:就业网)项目作为“数字**”的重点工程于2003年9月启动了。

  项目总投资150万元,要求在2004年5月1日前全面竣工并投入使用.

  系统要求采用先进的技术手段,以省人事厅为依托,以Internet为载体,大中专毕业生就业创业为导向;面向全省各级人事部门,大中专院校,人才中介机构,用人单位和毕业生;连接人事部、教育部和其他兄弟省市就业主管部门、高等院校;构筑一个大容量,宽辐射的全省毕业生就业创业公共服务平台。为我省广大毕业和用人单位提供全面、便捷、快速的人事人才服务;为大中专院校提供集学生学籍管理与就业相关工作的办公自动化平台。预计系统建成后将成为我省第一个面向全省的、大容量的、跨区域的毕业生就业创业电子政务应用服务平台。

  通过公司的项目经理竞争上岗机制,我有幸获得了公司领导与业主的信任,成为该项目的项目经理,全面主持项目的管理工作.

  在省政府与“数字**”小组领导的亲切关怀下,业主的通力配合与支持下,我与项日组全体同志们一起并肩作战,通过近8个月的努力,终于在2004年4月15日全面通过验收,项目花费总成本为96万元.比计划提起了15天,为公司挣得近50万的利润.

  二、项目范围难以管理

  范围管理是项目管理的基础,也是项目管理工作的重点和难点。含糊的需求和频繁变更的范围让项目的甲乙双方吃尽了苦头.如何做好项目的需求管理与范围管理常常是项目经理最头疼的间题。就业网项目的成功,笔者一直认为得益于有效的项目范围管理机制。在此笔者就就业网项目采取的项目范围管理的一些方法做简略介绍,望各位读者批评指正.

  三、项目需求与范围的区别和联系

  项目范围(Project-scope)包括项目的最终产品或服务以及实现改产品或服务所需的各项具体工作。从这个意义上讲就是项目应该做什么,不应该做什么,以及如何做。也就是说,项目范围事实包括2个方面的内容:项目需求和项目过程.项目需求确定做什么.项目过程确定如何做.

  项目范围管理也就是对项目应该做什么和怎么做做出相应的定义和控制.事实上就是对需求的管理和项目过程的管理.

  四、就业网项目需求特点

  1 、项目干系人多

  就业网是面向全省各级人事部门(省、市、县三级近100个人事行政单位)、大中专院校(近200所)、人才中介机构(200多家)、用人单位(近百万家)、毕业生的大型电子政务项目.项目涉及面广、用户量大.在项目管理中我们必须收集广大用户的意见,获得广大项目干系人的支持。才能打造一个用户乐于使用的电子政务平台,为项目的使用推广打下基础.

  2 、业务涉及面广

  毕业生就业公共网集毕业生就业创业指导、政策宣传、咨询,人才与用人单位的双向交流互动,网上人才市场,毕业生就业手续办理,院校学生学籍管理与就业管理,就业工作监控管理与宏观管理,资源收集整理于一体.涉及毕业生就业工作与人才管理工作的方方面面。

  3 、全省毕业生就业工作流程不一致

  就业网项目涉及我省各级人事部门,但由于政府人事工作的区域性,各设区市都有各自不同的人事制度与毕业生引进制度.造成我省各设区市人事部门毕业生就业工作流程的不一致.

  就业网项目涉及我省近200所大中专院校.各个学校也均有各自的就业管理工作方法和习惯.

  4 、各级政府部门、院校信息化程度参差不齐

  我省是一个沿海城市,各设区市经济条件不一样,信息化程度更是参差不齐.沿海城市信息化程度比较高,山区城市信息化较为落后。有些单位甚至没有一台电脑.

  五、项目范围管理工作方法

  就业网项目需求的特点使我们对项目的范围管理狡尽了脑汁.通过专家顾问的指导与项目团队全体同志们的共同努力,采取了相关措施、方法才使的项目的范围管理工作变的更加容易.

  1、全省三百多项目干系人参与的项目启动大会

  考虑到项目的涉及面广,干系人众多.项目正式启动之初,在业主省人事厅的通力配合下,我们召集了全省各级人事部门、大中专院校负责毕业生就业工作的领导和业务办理同志,重点中介机构和省直重点单位的人事主管三百多人参与项目的启动大会.在这次会议上,我作为项目经理向各项目干系人,就项目的主要目标、范围、范围管理计划、进度计划安排、沟通方式作了详细介绍.希望各项目干系人能够积极配合我们的工作,我们将尽量满足他们的要求,将就业网建设成为他们乐于使用,能确实帮助他们的网站系统。

  2、有效的项目范围管理

  这个项目可以说是我通过PMP后的第一次将项目管理知识体系知识灵活运用于实践之中.

  在项目管理中我们采用了MS Project2002作为项目管理工具.通过Project,我们建立了项目的WBS.对WBS的每个任务明确了其可交付物.对每一个任务我们都要求细化到每个人在一周内可以完成。保证每一项任务都是可控的.

  同时我们还制定了完善的项目范围管理计划,WBS字典,范围变更计划及规程,项目核实标准(含质量控制标准).并交由业主、项目监理单位审核后,由业主和项目监理单位共同实施。

  3、多饮的项目评审大会

  在项目进度计划中我们确定了5个重要里程碑.在这些里程碑结束后,我们将邀请相关项目干系人参与项目的评审工作.目的是为了防止需求偏差、遗漏,和收集新的需求.

  第一个重要里程碑是系统原型完成之后,邀请了所有项目干系人代表参与了原型的评审工作.

  第二个重要里程碑是政府人事部门业务平台完成之后,邀请了相关政府人事部门的相关业务负责人参与项目评审工作.

  第三个重要里程碑是院校端业务平台完成之后,邀请了各重点高校、中等职业学校的相关业务代表参与了项目的评审工作.

  第四个重要里程碑是网上人才市场平台完成之后,邀请了重点中介机构,省直重点单位、毕业生代表参加项目的评审工作.

  第五个重要里程碑系统基本成型之后,我们再一次组织了全体项目干系人,参加项目评审会议。

  每一次的项目评审都给我们带来了很多很好的建议.让我们充分发现了我们系统的不足之处,发现了许多业务上的偏差.当然也有许多项目干系人提出了系统易用性上的建议。会后,我们按照项目范围变更计划和业主、监理单位一起对这些建议作了逐一评估,将那些有益的建议包含进项目范围管理计划中。

  4、全体项目干系人的共同努力

  其实这个项目的成功是全体项目干系人的成功;是全体项目干系人努力的结果.省领导的重视和项目干系人的激情是这次项目成功的关键.在项目进行过程中许多单位都给我们提出了很多很好的建议;在项目进展过程中,许多院校的负责就业工作的老师,各级人事部门的相关负责同志都纷纷给我们提建议、出点子.我们还设立了热线电话专门接听、收集他们的建议.

  六、不足与展望

  目前系统运行稳定,到目前为止已经成功的完成了2届(近30万)毕业生就业管理及派遣工作。并于今年7月份获得了省项目科技进步二等奖。

  但回顾过去,确也可以发现许多不足之处.如:

  1、项目需求分析做的不够充分,没有充分考虑到各设区市业务流程的差异性。造成毕业生就业手续办理流程模块的全面返工。

  2、项目可行性研究做的不够充分,没有充分考虑到各设区市信息化程度的差异.造成到目前为止,许多落后的设区市、县无法真正使用就业网系统.

  3、除此之外,还存在许多的不足;这里不在逐一列举.

  在以后的工作中,我将继续努力学习、总结经验,继续为我国电子政务建设、企业信息化建设作贡献.

信息系统项目管理师论文范例7:论项目的风险管理

  摘要

  风险就是会给项目带来威胁或机会的一些不确定性事件.2003年5月,我参与了某机场信息系统集成项目的建设,并担任项目经理工作。整个项目总投资近亿元,建设工期为3年.因为信息系统集成在当时的国内民航系统来说,还是新兴技术,熟悉民航业务和信息集成技术的专家和技术人员很少,加上项目投资规模大、建设周期长,因此,该项目的风险很大。

  为了按照既定的进度、成本和质量完成项目的目标,在该项目中,我充分重视了风险管理,根据风险管理理论,结合自己的项目实践,按照风险管理计划编制、风险识别、风险分析、风险应对计划编制、风险监控等过程,有条不紊地进行风险管理.加之进行了良好的配置管理,整个项目建设过程中,始终遵循了变更控制程序,使该项目顺利完成了其目标.2006年3月,该项目建设完成,并在机场开通时投入生产运行,目前运行稳定.

  正文

  项目是在复杂的自然和社会环境中进行的,受众多因素的影响.对于这些内外因素,项目管理人员往往认识不足或者没有足够的力量加以控制.项目的过程和结果常常出乎人们的意料,有时不但未达到项目主体预期的目的,反而使其蒙受各种各样的损失,而有时又会给他们带来很好的机会。项目同其他经济活动一样带有风险.要避免和减少损失,将威胁化为机会,我们就必须了解和掌握项目风险的来源、性质和发生规律,进而实行有效的管理.

  项目风险是一种不确定的事件或条件,一旦发生,会对项目目标产生某种正面或负面的影响.风险有其成因,同时,如果风险发生,也导致某种后果.当事件、活动或项目有损失或收益与之相联系,涉及到某种或然性或不确定性和涉及到某种选择时,才称为有风险.以上三条,每一个都是风险定义的必要条件,不是充分条件.具有不确定性的事件不一定是风险.

  2003年5月,我所在的单位承接了双机场的机场信息系统集成项目的建设工作.该项目是国家重点建设工程项目的一个子项目,其主要工作是应用EAI框架,集成机场内其它各个重要信息系统,实现数据共享,整个项目总投资近亿元,建设工期3年.2006年3月,该项目建设完成,并在机场开通时投入生产运行,该信息系统集成项目以ORACLE 9i为平台,建立了一个可存储机场航班信息、管理信息和运营信息的综合中心数据库,开发了航班信息管理系统、机位自动分配系统、外场管理系统、机场资源管理综合系统等,构造了千兆以太网统一的网络平台,采用了EAI框架集成了这些新开发的系统外,还集成了机场内其它各个重要信息系统如航班信息显示系统、离港系统、广播系统等,连接机场外的许多相关系统如空管飞行信息系统、财务系统、航空运营系统等,实现不同应用操作平台的集成、异构数据库的集成,达到数据共享,应用集成。在该项目中,我担任项目管理工作.

  到2003年为止,我虽然已经负责了近10个项目的开发和管理工作,但当时被安排担任该项目的项目经理时,感觉确实是一大挑战.因为信息系统集成在当时(2003年)的国内民航系统来说,还是新兴技术,熟悉民航业务和信息集成技术的专家和技术人员毕竟很少,因此,这种项目的风险很大。为了按照既定的进度、成本和质量,完成项目的目标,在该项目中,我充分重视了风险管理,按照项目风险管理理论,结合自己的项目实践,有条不紊地完成了该项目.具体来说,我是按照以下基本的管理过程来进行风险管理的。

  1.风险管理计划编制

  在项目初期,我组织有关人员编制了风险管理计划,具体描述如何为该项目处理和执行风险管理活动.我们采用会议的方法来制定风险计划的,因为该项目投资规模比较大,所有的项目干系人代表都被邀请参加了风险管理计划会议,全面地考虑了风险对项目的影响,制订充分的风险管理计划。

  在计划中,我们确定了基本的风险管理活动(如每15天召开一次风险评估会议),根据项目管理理论和我公司的项目实践,定义了项目中的风险管理过程,估计了风险管理的时间表和费用,并把风险管理活动纳入了项目计划,把风险管理费用纳入了成本费用计划。

  2.风险识别

  根据项目的实际情况,我们把项目中的风险划分为技术风险、团队风险、外部风险三大类,采用风险分解结构(RBS)形式列举了已知的风险。

  在识别了上述风险后,我们还确定了这些风险的基本特性,引起这些风险的主要因素,以及可能会影响项目的方面,形成了详细的风险列表记录.根据试题的需要,在这里我只列出引起风险的主要因素,其他的方面限于时间和篇幅,不再介绍.

  风险名称

  引起风险的主要因素

  对工作的分析和评估不足

  缺乏类似的项目管理管理经验,对项目工作不熟悉

  对EAI 架构不熟

  行业内没有使用先例

  关键人员流动

  项目周期长,需要长期出差

  缺乏合适的技术人员

  项目周期长,异地开发

  没有正确理解业务问题

  项目干系人对业务的认识不足、信息化水平低

  预算不能按时到位

  甲方资金受限

  3.风险定性分析

  我们根据风险管理计划中的定义,确定每一个风险的发生可能性,并记录下来.除了风险发生的可能性,还分析了风险对项目的影响,包括对时间、成本、范围等各方面的影响.其中不仅仅包括对项目的负面影响,还分析了风险带来的机会。

  在这个过程中,我们还是采用会议的方式来进行的.不过,在风险分析的会议中,除了有关项目干系人外,我们还邀请了相关领域的专家参加,以提高分析结果的准确性。例如,对于技术类风险的分析,我们就邀请了业内著名的架构专家参与评估。在确定了风险的可能性和影响后,接下来需要进一步确定风险的优先级。风险优先级是一个综合的指标,其高低反映了风险对项目的综合影响.我们采用了风险优先级矩阵来评定风险优先级的.最后得出的结果是架构风险排在第一位,该风险的可能性很高,影响也很大。

  4.定量风险分析

  对已知风险进行定性分析后,我们还进行了定量分析,定量地分析了各风险对项目目标的影响.在这个过程中,我们采用了专家评估的方法,组织相关成员对项目进行乐观、中性和悲观估计,同时,也利用了我公司历史项目的数据,用来辅助评估.进行定量分析之后,更新了风险记录列表.

  5.风险应对计划编制

  根据定性和定量分析的结果,我们对已识别的风险,制订了应对计划。对不同的风险,采取了不同的措施.

  风险名称

  应对措施

  对工作的分析和评估不足

  利用已有经验,加强学习,利用标准的技术和理论

  对EAI 架构不熟

  聘请EAI专家做技术顾问,加强对有关人员进行架构培训

  关键人员流动

  紧密团结“少数人”,提高顶目完成奖金,实行人才备份制

  缺乏合适的技术人员

  在当地招聘部分技术人员,加强制度建设,加强培训

  没有正确理解业务问题

  加强对机场人员的培训,提高其信息化水平

  预算不能按时到位

  在合同中明确规定,由此引起的后果由甲方负责

  6.风险监控

  经过上述5个过程后,该项目中的风险已经比较清晰,这时就要进入风险跟踪与监控过程.在这个过程中,我们对已经识别出的风险的状态进行跟踪,监控风险发生标志,更深入地分析已经识别出的风险,继续识别项目中新出现的风险,复审风险应对策略的执行情况和效果。根据目前风险监控的结果修改风险应对策略,根据新识别出的风险进行分析并制定新的风险应对措施.

  在这个过程中,我们主要采用了偏差分析、项目绩效分析和监控会议的方式来进行的。

  总之,该机场项目由于技术领先、投资规模大、建设周期长、异地开发等原因,充满着风险,但由于我们+分重视项目的风险管理,加之进行了良好的配置管理,整个项目建设过程中,始终遵循了变更控制程序,使该项目顺利完成了其目标.2006年3月,该项目建设完成,并在机场开通时投入生产运行,目前运行稳定,得到了机场方的肯定,由此,我得到了公司董事会的嘉奖.

 

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics