1、 1 / 6 XXX 项目风险评估分析与应对措施 XXX 项目建设涉及项目实施规划与设计、数据采集、UI 设计、软件开发与实施、硬件采购与安装、 网络与数据中心工程、基建工程、弱电工程、工程施工、商务谈判与合同、资金管理、公共关系维护、 供应商管理、项目管理等众多方面的专业性建设与综合性统筹管理。 项目建设存在整体跨度大、专业性强、复杂度高低不同、工作量大等特征。 一、 缺乏共识的风险 1、与业主方的共识风险。 业主方对项目建设的难度、时间需求、具体解决方案等没有清晰认识，同时片面追求政绩、成果展示等 项目驱动，从而对项目提出不现实或多变的要求。 2、项目组内部（包括企业方与供应商方） 、企业
2、内部的共识风险。 内部人员对项目定位、具体解决方案有多种理解与认识，而产生对项目建设走向、时间进度、成本等各 方面造成至关重要影响。从建设的角度可以这么概括，在一个解决方案上达成共识比这个解决方案本身 的先进性重要得多，但往往形成不了共识。 3、各方的项目驱动力的不同且存在变化，造成共识风险加大。 业主方注重政绩、特定的项目诉求及其它利益点；企业方注重项目正常完结、各方公共关系维护及项目 款项收取；供应商注重既定需求的项目快速交付与项目款项收取，但各方项目驱动力是变化的。 应对：与各方就大的共识点达成意向，同时注意项目驱动力的不同并对各方不同策略响应；无法达成共 识时，由决策人作决策。 二、
3、组织和管理风险 1、项目组织架构是否存在？成员分工是否清晰明确？ 决策人是否明确？沟通机制？会议制度？ 2、仅由项目经理制下的相关人员进行的项目决策，会导致权限不够、计划进度缓慢、计划时间延长； 3、公司高层在参与度不够的情况下，审查决策的周期比预期的时间长； 4、各种因素影响下的预算削减，将打乱项目计划； 5、公司高层作出了打击项目组织积极性的决定； 6、项目缺乏必要的规范，导致工作失误与重复工作； 7、非技术的第三方的工作（预算批准、设备采购批准、法律方面的审查、安全保证等）时间比预期的延 长。 应对：项目应为一把手工程，最高领导的支持力度及参与情况将是项目稳健的保证；健全的项目组织、 沟
4、通汇报机制、会议制度、项目进度管理等； 2 / 6 三、业主方风险 1、业主方没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和产品生产周期的变更； 2、业主方对规划、方案、原型和规格的审核决策周期比预期的要长； 3、业主方协调或答复的时间（如回答或澄清与需求相关问题的时间、提供相关信息资料、协调相关资源 落实）比预期长； 4、业主方对于最后交付的产品不满意，要求重新设计和重做； 5、业主方涉项目人员广，项目利益对众多相关人直接驱动不明显，存在工作进度被堵或拖延的情况； 6、部分建设需在现有资源或设备上进行整合，而这部分内容前期并未竣工或验收等情况；其它施工条件、 施工配合等问题。 应
5、对：多加强与业主方的沟涌、客情关系维护，客情维护不限于一、二把手概念，对项目影响较深的相 关人物一并考虑。对子项目系统的建设，多进行事前需求引导及原型设计开发。利用现有设备问题，由 业主方从上而下进行统一，不能利用的则进行新采购机制。 加强沟通，严谨工作作风与态度，并与各方 保持良好项目关系。 四、需求风险 1、目前需求状态：业主方未能提出明确需求、致远方自身探索而自定义需求、供应商根据合约执行既有 需求。 2、惯例上，需求已经成为项目建设的基准，但本项目具体需求属各方仍在探索中，并无具体确明的需求 存在，新需求的提及将贯穿整个项目建设； 3、现有需求定义欠佳，而进一步的定义会扩展项目范畴，或
6、者添加额外的需求； 4、缺少有效的需求变化管理过程。 应对：致远方对需求做好明确，并以此宣贯引导给业主方形成业主方的需求，与供应商的沟通或合作， 则寻求对需求变化宽泛变动的空间。同时对需求的变动，进行严格项目管控。 五、技术/设备/产品的风险 1、项目的顶层设计是否合理，是否可行，缺少相对权威的评估，同时智慧城市作为新生事物，也缺乏真 正有效的设计评估。 2、 在缺乏一家供应商可满足整体解决方案情况，只能分拆由多家供应商来建设的实施策略，是否真正 达到预期效果，对项目实施带来挑战。 3 / 6 3、在供应商或产品的选型上，存在需求理解、沟通表达、信息不对称或欺诈等情况，产生选型风险； 4、需求
7、调研是否详细具体，可否支撑转换为软硬件产品的设计与实现；产品的设计是否科学、开放、规 范；产品实现的技术是否先进、满足要求； 5、软件产品开发的程序把控可高可低的风险，项目的业务需求模糊或复杂化，软件开发的过程中需求和 满意度都是以客户为准，在软件实施开发的过程中，需求获取和计划的落实都是需要每一步都要不停的 沟通和进行确认，确保主方向不会变。 6、软件的实现技术手段是否能够同时满足大量用户并发及实际使用体验的性能要求，相应技术难点与服 务器资源的解决； 7、软件开发过程可能的问题： 设计质量低下，导致重复设计；一些必要的功能无法使用现有的代码 和库实现，开发人员必须使用新的库或者自行开发新的
8、功能；代码和库质量低下,导致需要进行额外的 测试，修正错误，或重新制作；过高估计了增强型工具对计划进度的节省量；分别开发的模块无法 有效集成,需要重新设计或制作。 8、软件产品外包开发的质量的是否保证，能否做到可伸缩性、可维护性、易用性、先进性、代码的规范 性； 9、各方对项目亮点需求、功能的把握不太到位，或实现不到位； 10、各方产品在系统集成上的考虑与对接机制的实现、配合问题；同时存在多地沟通对接的难度大的情 况； 11、提供给软件产品使用的系统运行环境是否满足各家供应商的要求，由此可以产生新费用； 12、产品完成后相应带的售后服务问题（跨地区、商务条款、支持的有效性等） ； 13、硬件产
9、品的采购周期，现有设备的匹配支持程度或改造程度等设备资源保障的问题； 应对：设计上多学习多接触智慧城市项目，借鉴别人好的经验，在项目实施开展初期采用一至二个项目 先开展的实施策略，以控制整体风险；对供应商严挑细选，并做好有备用供应商机制； 加强直接沟通， 以达到对项目统一的认识，对需求有明确的认知，对需求调研做好充分的准备；明确开发计划与资源需 求计划，并做好项目管理，严格跟踪进度；软件开发尽可能采用原型开发模式，提前看到原型效果，并 与业主方进行宣讲以作需求引导；软件开发过程监督，节点内容及时交付，我方提前界入产品质量或性 能测试，并对可能产生的问题尽早提出让对方响应预防；加强有效沟通，减少
10、磨合带来的问题；商务合 同对产品不能交付等情况进行约束；对设备资源等情况提前考虑采购周期等进行计划；现有设备考虑兼 容性与牵涉问题，牵涉面太大则以新采购机制作考虑。 六、人力资源的风险 4 / 6 1、人员短缺，找不到项目急需的具有特定技能的人，并可能长期招不到人；项目人员经验不够，能力欠 缺； 2、某些人员需要更多的时间适应还不熟悉的软件工具和环境，或经过较长时间后发现不能达到要求； 3、项目后期加入新的开发人员，需进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率降低； 4、由于项目组成员之间（与合作伙伴间、与公司内部）发生意见冲突，导致沟通不畅、设计欠佳、接口 出现错误和额外的重复工
11、作； 5、技术人员和管理层之间关系不佳，导致决策缓慢，影响全局； 6、 团队成员是否能齐心协力为项目的共同目标服务，是影响进度和质量的关键因素； 7、缺乏激励措施，士气低下，降低了生产能力； 8、人员相对熟悉项目情况的较稳定状态下，出现人员离职等流动情况； 9、人员在技术、管理能力的短板或短视，对项目的全局或局部把握不太到位； 10、各供应商也可能存在以上相同情况。 应对：加强招聘环节的把握，寻找“志同道合”与素质能力俱备的员工与合作伙伴，对项目的定位与建 设达成共识；加强沟通表达，形成畅通的沟通机制，且探讨问题做到对事不对人；加强对 XXX 项目综合 素质的学习提升；建立有效的项目管理及公平
12、公正的激励措施。 七、财务的风险 1、公司高层对项目成本心理定位不够，执行层对项目预算不准，实际建设过程因需求变动等因素造成的 成本增加频繁；溢价实施的可能性较高； 2、工期内并行子项目建设较多，支出种类繁多且频繁，突发费用需求可能性大增； 3、业主方不能按合同及时支付款项，影响项目的正常支出，严重的情况，影响项目建设导向； 4、我方不能按合同及时支付供应商款项，影响供应商方的项目支出，产生项目障碍或增加沟通成本，情 况严重的可能影响影响项目建设导向； 5、项目运营大量资金的需求，对正常资金链产生影响或中断； 6、因财务因素对项目选型的影响，或导致建设需求的调整变化。 应对：执行层尽可能考虑各
13、种因素，将预算做得相对准确；领导层对项目的复杂性、资金支出大、资金 需求急等有较好的心理预期；财务管理制度相对灵活高效；备用金管理； 质量时间成本的项目原则。 八、时间的风险 1、项目本身的特定诉求，导致建设工期短，同时商务、调研、沟通等占用较大时间，真正开展项目建设 5 / 6 的时间更短； 2、各子项目的建设工期相应的缩短，将需投入的更多的人力，将产生高协同、高沟通、高决策等挑战要 求，同时对工作量的评估是否合理产生误差； 3、开发时间把控不足，在开发过程中由于种种因素影响导致可能无法在期限内完成所有必需的项目活动， 很有可能无法达到时间计划的需求，出现匆忙赶工，赶工和时程的压力很有可能导
14、致项目工作中无法改 正的错误。 4、项目管理中，各方对时间成本意识不高的现象； 应对：对各子项目的建设需求区分 A、B 、C 类，对 A 类的时间内的完成要有保证， B 类、C 类相对灵活处 理；严格执行项目计划，加强项目细节掌控；加强沟通机制，内部沟通不拖延，外部沟通准确高效；适 宜时机宣导业主方对工期的预期，留更多缓冲时间；坚持质量时间成本的项目原则； 九、项目管理的风险 1、项目计划项残缺，未能对所有的事项做好预估与管理，产生突发事件较多；项目计划不能明确责任人、 时间节点等，造成混乱、并行事件多；计 划 是 优 化 的 ,是 “最 佳 状 态 “,但 计 划 不 现 实 ,只 能 算
15、是 “期 望 状 态 “； 2、计划执行不到位，受客观与主观因素影响，形成空计划；计 划 、 资 源 和 产 品 定 义 全 凭 业 主 方 或 上 层 领 导 口 头 指 令 ,并 且 不 完 全 一 致 ； 涉 足 不 熟 悉 的 产 品 领 域 ,花 费 在 设 计 和 实 现 上 的 时 间 比 预 期 的 要 多 ； 3、项目经理缺乏项目管理经验，可能要花更长的时间来定义项目，会有更多的判断上失误，导致返工或 项目延期，项目复杂，更难以组织和管理，可能不知道何时应该寻求帮助。缺乏良好的沟通，无法及时 地提出问题，由于无法考量对项目的影响，范围变更也可能无法实行，风险可能被忽略，最终无
16、法实现 最优的质量，无法预期项目潜在的问题和困难。 4、没有明确的或正式授权的项目发起人：项目无法获得所需的资源，无法获得所必需的长期承诺，可能 产生内部矛盾，斗争可能会使项目延期，项目中出现的问题和变更申请可能无法及时的得到解决。 5、项目状态不清：项目进展中，各成员沟通不力，信息交流不畅。 6、项目干系人利益关系不明确：利益关系不明确在项目开展过程多有阻碍，一方面工作目的模糊不清， 关系不清，责任问题不明确。另一方面增加个人顾虑影响积极性。 7、分处多地的项目团队或供应商管理：由于项目很大一部分都是外包和寻求合作开发团队的形式，在项 目跟进和监管方面将增加难度，更难以有效沟通，缺乏充分的团
17、队互动和凝聚力，关系分散不容易建立， 技术问题把控难，可能导致生产力下降。 6 / 6 8、对开发团队和供应商认知不足：由于受时间和工期影响，且很多供应商都是在短时间之类建立起来的 新合作关系，在相互的熟悉和信任度将导致不足，供应商的资质、能力、团队规模、组织架构的完整性、 开发团队的严谨性和逻辑思维、沟通能力、经验、工作态度和效率等都将与项目息息相关。 应对：明确项目组织干系人，明确工作划分、明确会议制度、沟通机制；做好项目计划，细化各事件项， 明确时间节点、责任人员，落实项目跟进机制；供应商管理在考虑商务合同作相应约束，进度中深化沟 通，建立日常及异常的沟通方式，开发进度细化跟进；紧急或重
18、大情况，采用客户现场办公制； 十、商务谈判与合同的风险 1、 签订的合同不科学、不严谨，项目边界和各方面责任界定不清等风险，特别是在不熟悉的领域内的商 务合同。 2、谈判能力与技巧的局限，可能使得价格、有利条款的争取不利。 3、合同种类涉及软件、硬件、数据库、网络工程、工程施工、土建或弱电工程等。 4、文字的表达博大精深，可能有多种歧义解释。 应对：与各家供应商在洽谈需求、功能阶段尽早进入商务合同样版、内容、模糊或不明确的地方进行探 讨沟通；多方供应商沟通并比价，以得到相对较准确的项目成本；对模糊或不明确的地方，尽可能让对 方接受我方灵活的处理机制；过程中发现的边界模糊的问题，及时进行补充协议的沟通、签订；合同条 款的审阅； 十一、环境影响的风险 1、工程施工、硬件调配等受天气影响较大，特别是雨水，对项目进度产生停工的影响。同时天气因素对 大件设备采购周期可能影响。 应对：提早进行户外项目的施工建设；相应项目工期延长，并与各方沟通； 十一、安全的风险 1、工程施工相关的监督、质量、管理安排、人身安全等问题； 应对：工程施工采用外包（包含安全） ，由工程方自行承担，同时项目实施中加强对工程施工方的监督； 质量以能达到要求为准。
