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