IT项目方案风险评估分析及其管控.doc
《IT项目方案风险评估分析及其管控.doc》由会员分享,可在线阅读,更多相关《IT项目方案风险评估分析及其管控.doc(6页珍藏版)》请在得力文库 - 分享文档赚钱的网站上搜索。
1、XXX 项目风险评估分析与应对措施项目风险评估分析与应对措施XXX 项目建设涉及项目实施规划与设计、数据采集、UI 设计、软件开发与实施、硬件采购与安装、网络与数据中心工程、基建工程、弱电工程、工程施工、商务谈判与合同、资金管理、公共关系维护、供应商管理、项目管理等众多方面的专业性建设与综合性统筹管理。项目建设存在整体跨度大、专业性强、复杂度高低不同、工作量大等特征。一、一、缺乏共识的风险缺乏共识的风险1、与业主方的共识风险。业主方对项目建设的难度、时间需求、具体解决方案等没有清晰认识,同时片面追求政绩、成果展示等项目驱动,从而对项目提出不现实或多变的要求。2、项目组内部(包括企业方与供应商方
2、) 、企业内部的共识风险。内部人员对项目定位、具体解决方案有多种理解与认识,而产生对项目建设走向、时间进度、成本等各方面造成至关重要影响。从建设的角度可以这么概括,在一个解决方案上达成共识比这个解决方案本身的先进性重要得多,但往往形成不了共识。3、各方的项目驱动力的不同且存在变化,造成共识风险加大。业主方注重政绩、特定的项目诉求及其它利益点;企业方注重项目正常完结、各方公共关系维护及项目款项收取;供应商注重既定需求的项目快速交付与项目款项收取,但各方项目驱动力是变化的。应对:与各方就大的共识点达成意向,同时注意项目驱动力的不同并对各方不同策略响应;无法达成共应对:与各方就大的共识点达成意向,同
3、时注意项目驱动力的不同并对各方不同策略响应;无法达成共识时,由决策人作决策。识时,由决策人作决策。二、二、组织和管理风险组织和管理风险1、项目组织架构是否存在?成员分工是否清晰明确? 决策人是否明确?沟通机制?会议制度?2、仅由项目经理制下的相关人员进行的项目决策,会导致权限不够、计划进度缓慢、计划时间延长;3、公司高层在参与度不够的情况下,审查决策的周期比预期的时间长;4、各种因素影响下的预算削减,将打乱项目计划;5、公司高层作出了打击项目组织积极性的决定;6、项目缺乏必要的规范,导致工作失误与重复工作;7、非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期
4、的延长。 应对:项目应为一把手工程,最高领导的支持力度及参与情况将是项目稳健的保证;健全的项目组织、应对:项目应为一把手工程,最高领导的支持力度及参与情况将是项目稳健的保证;健全的项目组织、沟通汇报机制、会议制度、项目进度管理等;沟通汇报机制、会议制度、项目进度管理等;三、业主方风险三、业主方风险1、业主方没有或不能参与规划、原型和规格阶段的审核,导致需求不稳定和产品生产周期的变更;2、业主方对规划、方案、原型和规格的审核决策周期比预期的要长;3、业主方协调或答复的时间(如回答或澄清与需求相关问题的时间、提供相关信息资料、协调相关资源落实)比预期长;4、业主方对于最后交付的产品不满意,要求重新
5、设计和重做;5、业主方涉项目人员广,项目利益对众多相关人直接驱动不明显,存在工作进度被堵或拖延的情况;6、部分建设需在现有资源或设备上进行整合,而这部分内容前期并未竣工或验收等情况;其它施工条件、施工配合等问题。应对:多加强与业主方的沟涌、客情关系维护,客情维护不限于一、二把手概念,对项目影响较深的相应对:多加强与业主方的沟涌、客情关系维护,客情维护不限于一、二把手概念,对项目影响较深的相关人物一并考虑。对子项目系统的建设,多进行事前需求引导及原型设计开发。利用现有设备问题,由关人物一并考虑。对子项目系统的建设,多进行事前需求引导及原型设计开发。利用现有设备问题,由业主方从上而下进行统一,不能
6、利用的则进行新采购机制。业主方从上而下进行统一,不能利用的则进行新采购机制。 加强沟通,严谨工作作风与态度,并与各方加强沟通,严谨工作作风与态度,并与各方保持良好项目关系。保持良好项目关系。四、需求风险四、需求风险1、目前需求状态:业主方未能提出明确需求、致远方自身探索而自定义需求、供应商根据合约执行既有需求。2、惯例上,需求已经成为项目建设的基准,但本项目具体需求属各方仍在探索中,并无具体确明的需求存在,新需求的提及将贯穿整个项目建设;3、现有需求定义欠佳,而进一步的定义会扩展项目范畴,或者添加额外的需求;4、缺少有效的需求变化管理过程。 应对:致远方对需求做好明确,并以此宣贯引导给业主方形
7、成业主方的需求,与供应商的沟通或合作,应对:致远方对需求做好明确,并以此宣贯引导给业主方形成业主方的需求,与供应商的沟通或合作,则寻求对需求变化宽泛变动的空间。同时对需求的变动,进行严格项目管控。则寻求对需求变化宽泛变动的空间。同时对需求的变动,进行严格项目管控。五、技术五、技术/设备设备/产品的风险产品的风险 1、项目的顶层设计是否合理,是否可行,缺少相对权威的评估,同时智慧城市作为新生事物,也缺乏真正有效的设计评估。2、 在缺乏一家供应商可满足整体解决方案情况,只能分拆由多家供应商来建设的实施策略,是否真正达到预期效果,对项目实施带来挑战。3、在供应商或产品的选型上,存在需求理解、沟通表达
8、、信息不对称或欺诈等情况,产生选型风险;4、需求调研是否详细具体,可否支撑转换为软硬件产品的设计与实现;产品的设计是否科学、开放、规范;产品实现的技术是否先进、满足要求;5、软件产品开发的程序把控可高可低的风险,项目的业务需求模糊或复杂化,软件开发的过程中需求和满意度都是以客户为准,在软件实施开发的过程中,需求获取和计划的落实都是需要每一步都要不停的沟通和进行确认,确保主方向不会变。6、软件的实现技术手段是否能够同时满足大量用户并发及实际使用体验的性能要求,相应技术难点与服务器资源的解决;7、软件开发过程可能的问题:设计质量低下,导致重复设计;一些必要的功能无法使用现有的代码和库实现,开发人员
9、必须使用新的库或者自行开发新的功能;代码和库质量低下,导致需要进行额外的测试,修正错误,或重新制作;过高估计了增强型工具对计划进度的节省量;分别开发的模块无法有效集成,需要重新设计或制作。8、软件产品外包开发的质量的是否保证,能否做到可伸缩性、可维护性、易用性、先进性、代码的规范性;9、各方对项目亮点需求、功能的把握不太到位,或实现不到位;10、各方产品在系统集成上的考虑与对接机制的实现、配合问题;同时存在多地沟通对接的难度大的情况;11、提供给软件产品使用的系统运行环境是否满足各家供应商的要求,由此可以产生新费用;12、产品完成后相应带的售后服务问题(跨地区、商务条款、支持的有效性等) ;1
10、3、硬件产品的采购周期,现有设备的匹配支持程度或改造程度等设备资源保障的问题;应对:设计上多学习多接触智慧城市项目,借鉴别人好的经验,在项目实施开展初期采用一至二个项目应对:设计上多学习多接触智慧城市项目,借鉴别人好的经验,在项目实施开展初期采用一至二个项目先开展的实施策略,以控制整体风险;对供应商严挑细选,并做好有备用供应商机制;先开展的实施策略,以控制整体风险;对供应商严挑细选,并做好有备用供应商机制; 加强直接沟通,加强直接沟通,以达到对项目统一的认识,对需求有明确的认知,对需求调研做好充分的准备;明确开发计划与资源需以达到对项目统一的认识,对需求有明确的认知,对需求调研做好充分的准备;
11、明确开发计划与资源需求计划,并做好项目管理,严格跟踪进度;软件开发尽可能采用原型开发模式,提前看到原型效果,并求计划,并做好项目管理,严格跟踪进度;软件开发尽可能采用原型开发模式,提前看到原型效果,并与业主方进行宣讲以作需求引导;软件开发过程监督,节点内容及时交付,我方提前界入产品质量或性与业主方进行宣讲以作需求引导;软件开发过程监督,节点内容及时交付,我方提前界入产品质量或性能测试,并对可能产生的问题尽早提出让对方响应预防;加强有效沟通,减少磨合带来的问题;商务合能测试,并对可能产生的问题尽早提出让对方响应预防;加强有效沟通,减少磨合带来的问题;商务合同对产品不能交付等情况进行约束;对设备资
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- IT 项目 方案 风险 评估 分析 及其
限制150内