IT项目风险评估分析及管控.pdf

XXX项目建设涉及项目实施规划与设计、数据采集、UI设计、软件开发与实施、硬件采购与安装、网络与数据中心工程、基建工程、弱电工程、工程施工、商务谈判与合同、资金管理、公共关系维护、供应商管理、项目管理等众多方面的专业性建设与综合性统筹管理。项目建设存在整体跨度大、专业性强、复杂度高低不同、工作量大等特征。一、缺乏共识的风险1、与业主方的共识风险。业主方对项目建设的难度、时间需求、具体解决方案等没有清晰认识，同时片面追求政绩、成果展示等项目驱动，从而对项目提出不现实或多变的要求。2、项目组内部（包括企业方与供应商方）、企业内部的共识风险。内部人员对项目定位、具体解决方案有多种理解与认识，而产生对项目建设走向、时间进度、成本等各方面造成至关重要影响。从建设的角度可以这么概括，在一个解决方案上达成共识比这个解决方案本身的先进性重要得多，但往往形成不了共识。3、各方的项目驱动力的不同且存在变化，造成共识风险加大。业主方注重政绩、特定的项目诉求及其它利益点；企业方注重项目正常完结、各方公共关系维护及项目款项收取；供应商注重既定需求的项目快速交付与项目款项收取，但各方项目驱动力是变化的。应对：与各方就大的共识点达成意向，同时注意项目驱动力的不同并对各方不同策略响应；无法达成共识时，由决策人作决策。二、组织和管理风险1、项目组织架构是否存在？成员分工是否清晰明确？决策人是否明确？沟通机制？会议制度？2、仅由项目经理制下的相关人员进行的项目决策，会导致权限不够、计划进度缓慢、计划时间延长；3、公司高层在参与度不够的情况下，审查决策的周期比预期的时间长；4、各种因素影响下的预算削减，将打乱项目计划；5、公司高层作出了打击项目组织积极性的决定；6、项目缺乏必要的规范，导致工作失误与重复工作；7、非技术的第三方的工作（预算批准、设备采购批准、法律方面的审查、安全保证等）时间比预期的延长。应对：项目应为一把手工程，最高领导的支持力度及参与情况将是项目稳健的保证；健全的项目组织、沟通汇报机制、会议制度、项目进度管理等；/61、业主方没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和产品生产周期的变更；2、业主方对规划、方案、原型和规格的审核决策周期比预期的要长；3、业主方协调或答复的时间（如回答或澄清与需求相关问题的时间、提供相关信息资料、协调相关资源落实）比预期长；4、业主方对于最后交付的产品不满意，要求重新设计和重做；5、业主方涉项目人员广，项目利益对众多相关人直接驱动不明显，存在工作进度被堵或拖延的情况；6、部分建设需在现有资源或设备上进行整合，而这部分内容前期并未竣工或验收等情况；其它施工条件、施工配合等问题。应对：多加强与业主方的沟涌、客情关系维护，客情维护不限于一、二把手概念，对项目影响较深的相关人物一并考虑。对子项目系统的建设，多进行事前需求引导及原型设计开发。利用现有设备问题，由业主方从上而下进行统一，不能利用的则进行新采购机制。加强沟通，严谨工作作风与态度，并与各方保持良好项目关系。四、需求风险1、目前需求状态：业主方未能提出明确需求、致远方自身探索而自定义需求、供应商根据合约执行既有需求。2、惯例上，需求已经成为项目建设的基准，但本项目具体需求属各方仍在探索中，并无具体确明的需求存在，新需求的提及将贯穿整个项目建设；3、现有需求定义欠佳，而进一步的定义会扩展项目范畴，或者添加额外的需求；4、缺少有效的需求变化管理过程。应对：致远方对需求做好明确，并以此宣贯引导给业主方形成业主方的需求，与供应商的沟通或合作，则寻求对需求变化宽泛变动的空间。同时对需求的变动，进行严格项目管控。五、技术/设备/产品的风险1、项目的顶层设计是否合理，是否可行，缺少相对权威的评估，同时智慧城市作为新生事物，也缺乏真正有效的设计评估。2、在缺乏一家供应商可满足整体解决方案情况，只能分拆由多家供应商来建设的实施策略，是否真正达到预期效果，对项目实施带来挑战。3、在供应商或产品的选型上，存在需求理解、沟通表达、信息不对称或欺诈等情况，产生选型风险；/64范；产品实现的技术是否先进、满足要求；5、软件产品开发的程序把控可高可低的风险，项目的业务需求模糊或复杂化，软件开发的过程中需求和满意度都是以客户为准，在软件实施开发的过程中，需求获取和计划的落实都是需要每一步都要不停的沟通和进行确认，确保主方向不会变。6、软件的实现技术手段是否能够同时满足大量用户并发及实际使用体验的性能要求，相应技术难点与服务器资源的解决；7、软件开发过程可能的问题：①设计质量低下，导致重复设计；②一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发新的功能；③代码和库质量低下,导致需要进行额外的测试，修正错误，或重新制作；④过高估计了增强型工具对计划进度的节省量