it项目风险评估报告

1、it项目风险评估报告 ：评估报告 项目风险 3a项目风险评估公司 项目风险评估报告范本 风险评估的三个要素 篇一：软件项目风险评估报告 引言 本文档的范围和目的 本文主要针对软件开发涉及到的风险，包括在软件开发周期过程中可能出现的风险以及软件实施过程中外部环境的变化可能引起的风险等进行评估。在文中对所提到的风险都一一做了详细的分析，并提出了相应的风险回避措施。 由于风险是在项目开始之后才开始对项目的开发起负面的影响，所以风险分析的不足，或是风险回避措施不得力，都很有可能造成软件开发的失败。风险分析是在事前的一种估计，凭借一定的技术手段和丰富的经验，基本能够对项目的风险做出比较准确的估计，经过慎

2、重的考虑提出可行的风险回避措施，是避免损失的重要环节。 主要风险综述 任何软件的开发，其主要风险均来自于两个方面，一是软件管理，二是软件体系结构。软件产品的开发是工程技术与个人创作的有机结合。软件开发是人的集体智慧按照工程化的思想进行发挥的过程。软件管理是保证软件开发工程化的手段。软件体系结构的合理程度是取决于集体智慧发挥的程度和经验的运用。软件管理将影响到软件的下列因素： 软件是否能够按工期的要求完成：软件的工期常常是制约软件质量的主要因素。很多情况下，软件开发商在工期的压力下，放弃文档的书写，组织，结果在工程的晚期，大量需要文档进行协调的工作时，致使软件进度越来越慢。软件的开发不同于其他的

3、工程，在不同的工程阶段，需要的人员不同，需要配合的方面也不同，所有这些都需要行之有效的软件管理的保证。 软件需求的调研是否深入透彻：软件的需求是确保软件正确反映用户的对软件使用的重要的文档，探讨软件需求是软件开发的起始点，但软件的需求却会贯穿整个软件的开发过程，软件管理需要对软件需求的变化进行控制和管理，一方面保证软件需求的变化不至于造成软件工程的一改再改而无法按期完成；同时又要保证开发的软件能够为用户所接受。软件管理需要控制软件的每个阶段进行的成度，不能过细造成时间的浪费，也不能过粗，造成软件缺陷。 软件的实现技术手段是否能够同时满足性能要求：软件的构造需要对软件构造过程中的使用的各种技术进

4、行评估。软件构造技术通常是这样：最成熟的技术，往往不能体现最好的软件性能；先进的技术，往往人员对其熟悉程度不够，对其中隐含的缺陷不够明了。软件管理在制定软件开发计划和定义里程碑时必须考虑这些因素，并做出合理的权衡决策。 软件质量体系是否能够被有效地保证：任何软件管理忽略软件质量监督环节都将对软件的生产构成巨大的风险。而制定卓有成效的软件质量监督体系，是任何软件开发组织必不可少的。软件质量保证体系是软件开发成为可控制过程的基础，也是开发商和用户进行交流的基础和依据。 软件体系结构影响到软件的如下质量因素： 软件的可伸缩性：是指软件在不进行修改的情况下适应不同的工作环境的能力。由于硬件的飞速发展和

5、软件开发周期较长的矛盾，软件升级的需要显得非常迫切。如果软件的升级和移植非常困难，软件的生命期必定很短，使得化费巨大人力物力开发出的软件系统只能在低性能的硬件或网络上运行，甚至被废弃不用，造成巨大的浪费。 软件的可维护性：软件的维护也是必然的事情，为了保证软件的较长使用寿命，软件就必须适应不断的业务需求变化，根据业务需求的变化对软件进行修改。修改的成本和周期都直接和软件的体系结构相关。一个好的软件体系结构可以尽可能地将系统的变化放在系统的配置上，即软件代码无需修改，仅仅是在系统提供的配置文件中进行适当的修改，然后软件重新加载进入运行状态，就完成了系统部分功能和性能要求的变化。对于重大改动，需要

6、打开源代码进行修改的，也仅仅是先继承原先的代码，然后用新的功能接替原先的调用接口，这样将把软件改动量减小到最低。 软件易用性：软件的易用性是影响软件是否被用户接受的关键之关键因素。在软件产品中，设计复杂，功能强大而完备，但因为操作繁复而被搁置者屡见不鲜。造成的主要原因在于缺乏软件开发中软件体系结构的宏观把握能力。另一方面，缺乏有效的手段进行软件需求的确定和对潜在需求的挖掘。 项目管理的风险软件项目管理的风险来自于软件项目自身的特点： 软件产品不可见：开发的进展以及软件的质量是否符合要求难于度量，从而使软件的管理难于把握。软件的生产过程不存在绝对正确的过程形式：可以肯定的是不同的软件开发项目应当

7、采用不同的或者说是有针对性的软件开发过程，而真正合适的软件开发过程是在软件项目的开发完成才能明了的。因此项目开发之初只能根据项目的特点和开发经验进行选择，并在开发过程中不断的调整。 大型软件项目往往是一次性的。以往的经验可以被借鉴的地方不多。回避和控制软件管理风险的唯一办法就是设立监督制度，项目开发中任何较大的决定都必须有主要技术环节甚至是由用户参与进行的。在该项目中项目监督由项目开发中的质量监督组来实施。 一般参与软件开发的人员（包括管理者和技术人员）和其责任进行分析如下： 参与者 项目经理1人 主要职责：进行全局把握，侧重于项目的商务方面，充当项目组同客户正式交流的接口环节。 项目负责人1

8、人 主要职责：制定项目开发计划和开发策略，参与项目核心系统的分析设计，同时努力保证开发计划的按时完成和开发策略的真正贯彻落实。 领域专家1或2人 主要职责：在软件分析阶段帮助分析人员界定系统实现边界和实现的功能，对特定检测点进行算法审核，同时对测试策略和软件操作界面提出参考意见。 质量监督组1或2人 主要职责：编制软件质量控制计划，并负责落实；控制必要文档的生产，通过文档，监督项目实施过程中软件的质量，并产生软件质量报告，提请项目经理和项目负责人审阅；对于项目中出现的质量问题，主持召开质量复审会议。 系统分析员1或2人 主要职责：协同项目负责人进行软件系统的分析和设计工作，书写软件需求分析和系

9、统设计相关文档。在软件实现阶段进行测试策略的编制和对性能测试的指导。 程序员2或3人 主要职责：协助分析人员进行详细设计，和软件系统的代码实现，并进行适当的白盒测试。 测试员2或3人 主要职责：已经实现的软件组件、构件或系统进行正确性验证测试，整合后的系统的性能测试等。书写测试报告和测试统计报告提请质量监督组复审。 技术支持2或3人 主要职责：协同系统分析人员听取用户需求，对需求分析进行参考性复审。协同测试人员进行测试，书写操作手册和在线帮助，在项目交付用户之后进行跟踪服务。 文档组1或2人 主要职责：对各部门产生的文档进行格式规范、版本编号和控制、存档文件的检索；协助质量监督组进行软件质量监

10、督。 通过适当的人员配备和职责划分，能有效的降低软件开发在后期的失控的可能性，和软件对关键人员的依赖性。 软件技术风险 本系统拟订采用的两个重大的软件技术是面向对象的构件和基于微软的COM组件技术。组件和构件技术都是为了提高软件的可靠性和软件的可扩展性而采用的技术手段。从技术成熟度上说不存在风险，但为了实现良好的软件构架和稳定的组件，与传统开发方法比较，有相当的多的额外工作需要做，这会给项目工期带来较大的风险。 回避和控制这部分风险的办法是在项目进行的过程不断的对该阶段进行风险估计和指定有效的里程碑。同时(转载于:www.xiElw.coM 写论文 网:it项目风险评估报告)采用范例方式提高开

11、发人员的构件组件的分析识别能力，适时调整构件组件的数量和粒度。软件过程风险 软件需求阶段的风险 软件的开发是以用户的需求开始，在大多数情况下，用户需求要靠软件开发方诱导才能保证需求的完整，再以书面的形式形成用户需求这一重要的文档。需求分析更多的是开发方确认需求的可行性和一致性的过程，在此阶段需要和用户进行广泛的交流和确认。需求和需求分析的任何疏漏造成的损失会在软件系统的后续阶段被一级一级地放大，因此本阶段的风险最大。 设计阶段的风险 设计的主要目的在于软件的功能正确的反映了需求。可见需求的不完整和对需求分析的不完整和错误，在设计阶段被成倍地放大。设计阶段的主要任务是完成系统体系结构的定义，使之

12、能够完成需求阶段的即定目标；另一方面也是检验需求的一致性和需求分析的完整性和正确性。 设计本身的风险主要来自于系统分析人员。分析人员在设计系统结构时过于定制，系统的可扩展性较弱，会给后期维护带来巨大的负担，和维护成本的激增。对用户来说系统的使用比例会有明显的折扣，甚至造成软件寿命过短。反之，软件结构的过于灵活和通用，必然引起软件实现的难度增加，系统的复杂度会上升，这又会在实现和测试阶段带来风险，系统的稳定性也会受到影响。从另一个角度上看，业务规则的变化，或说用户需求和将来软件运行环境的变化都是必然的情况，目前软件设计的所谓通用性是否就能很好的适应将来需求和运行环境的的变化，是需要认真折衷的。这

13、种折中也蕴涵着很大的风险。 设计阶段蕴涵的另一种风险来自于设计文档。文档的不健全不仅会造成实现阶段的困难，更会在后期的测试和维护造成灾难性的后果，例如根本无法对软件系统进行版本升级，甚至是发现的简单错误都无从更正。实现阶段引入的风险软件的实现从某种意义上讲是软件代码的生产。原代码本身也是文档的一部分，同时它又是将来运行于计算机系统之上的实体。源代码书写的规范性，可读性是该阶段的主要风险来源。规范的代码生产会把属于程序员自身个性风格的成分引入代码的比例降到最低限度，从而减小了系统整合的风险。 维护阶段的风险 软件维护包含两个主要的维护阶段，一个是软件生产完毕到软件试运行阶段的维护，这个阶段是一种

14、实环境的测试性维护，其主要目的是发现在测试环境中不能或未发现的问题；另一个阶段是当软件的运行不再能适应用户业务需求或是用户的运行环境（包括硬件平台，软件环境等）时进行的软件维护，具体可能是软件的版本升级或软件移植等。 从软件工程的角度看，软件维护费用约占总费用的55%70%，系统越大，该费用越高。对系统可维护性的轻视是大型软件系统的最大风险。在软件漫长的运营期内，业务规则肯定会不断发展，科学的解决此问题的做法是不断对软件系统进行版本升级，在确保可维护性的前提下逐步扩展系统。 在软件系统运营期间，主要的风险源自于技术支持体系的无效运转。科学的方法是有一支客户支持队伍不断收集运行中发现的问题，并将

15、解决问题的方法传授给软件系统的所有使用者。 项目风险表 风险评估表中所提到的风险是一般项目在开发过程中都客观存在的，表中所列出的风险系数是指在不对风险进行深入的分析和有效的规避的情况下，该风险项发生的概率。比如软件产品的设计目标是运行十年，体系结构不合理的风险是40%的含义是，如果不对系统进行深入的分析，未采用最合理的软件技术进行设计，则生产出一个不具备可扩展性的软件系统的概率是40%。由于客户公司是仍将不断发展的，在十年内，该软件系统都能满足公司运营要求的可能性极低。由此而可能产生的灾难性后果是公司在业务发展的时候，必须重新开发新系统。 向客户提供风险评估，是按照国际惯例进行的例行操作，一方

16、面让客户对潜在的风险有更充分的了解，表明公司诚信 为本的态度，另一方面也用以鞭策和激励全体开发人员严格执行开发标准，共同监督项目开发过程，努力避免风险的发生。风险 概率 影响 -规模估计过低 60% 严重的 交付期限太紧张 50% 严重的 用户需求变化频繁 75% 严重的 技术达不到预期效果 30% 轻微的 质量保证体系的措施实施不利 60% 严重的软件体系结构设计不合理 40% 灾难性的人员流动 30% 严重的篇二：软件项目管理之风险评估 软件项目管理之风险评估 很多时候不知道大家有没有发现，项目成为我们见面或茶余饭后的谈资，其中软件项目开发尤为多，但由于种种原因，这个项目并不能如期的完成。

17、那么，如何在项目实施过程中进行有效地评估和预防这些风险呢，这就涉及到风险的评估。 项目管理教会我们如何在复杂多变的环境中做好一件事，风险评估是其中非常重要的一项。本文就软件项目管理中的风险评估方面做详细介绍。 风险评估 软件项目风险是指在整个项目周期中所涉及的成本预算、开发进度、技术难度、经济可行性、安全管理等各方面的问题，以及由这些问题而对项目所产生的影响。项目的风险与其可行性成反比，其可行性越高，风险越低。软件项目的可行性分为经济可行性、业务可行性、技术可行性、法律可行性等四个方面。而软件项目风险则分为产品规模风险、需要风险、相关性风险、管理风险、安全风险等六个方面： 1. 产品规模风险

18、项目的风险是与产品的规模成正比的，一般产品规模越大，问题就越突出。尤其是估算产品规模的方法，复用软件的多少，需求变更的多少等因素与产品风险息息相关： (1) 估算产品规模的方法 (2) 产品规模估算的信任度 (3) 产品规模与以前产品规模平均值的偏差 (4) 产品的用户数 (5) 复用软件的多少 (6) 产品需求变更的多少 2. 需求风险 很多项目在确定需求时都面临着一些不确定性。当在项目早期容忍了这些不确定性，并且在项目进展过程当中得不到解决，这些问题就会对项目的成功造成很大威胁。如果不控制与需求相关的风险因素，那么就很有可能产生错误的产品或者拙劣地建造预期的产品。每一种情况对产品来讲都可能

19、致命的，这些的风险因素有: (1) 对产品缺少清晰的认识 (2) 对产品需求缺少认同 (3) 在做需求分析过程中客户参与不够 (4) 没有优先需求 (5) 由于不确定的需要导致新的市场 (6) 不断变化需求 (7) 缺少有效的需求变化管理过程 (8) 对需求的变化缺少相关分析等 3. 相关性风险 许多风险都是因为项目的外部环境或因素的相关性产生的。控制外部的相关性风险， 能缓解策略应该包括可能性计划，以便从第二资源或协同工作资源中取得必要的组成部分，并觉察潜在的问题,与外部环境相关的因素有： (1) 客户供应条目或信息 (2) 交互成员或交互团体依赖性 (3) 内部或外部转包商的关系 (4)

20、经验丰富人员的可得性 (5) 项目的复用性 4. 技术风险 软件技术的飞速发展和经验丰富员工的缺乏，意味着项目团队可能会因为技巧的原因影响项目的成功。 在早期，识别风险从而采取合适的预防措施是解决风险领域问题的关键，比如：培训、聘请顾问以及为项目团队招聘合适的人才等。关于技术主要有下面这些风险因素： (1) 缺乏培训 (2) 对方法、工具和技术理解的不够(3) 应用领域的经验不足 (4) 对新的技术和开发方法应用不熟悉 5. 管理风险 尽管管理问题制约了很多项目的成功，但是不要因为风险管理计划中没有包括所有管理活动而感到惊奇。在大部分项目里，项目经理经常是写项目风险管理计划的人，他们有先天性的

21、不足不能检查到自己的错误。因而，使项目的成功变得更加困难。如果不正视这些棘手的问题，它们就很有可能在项目进行的某个阶段影响项目本身。当我们定义了项目追踪过程并且明晰项目角色和责任，就能处理这些风险因素： (1) 计划和任务定义不够充分 (2) 对实际项目状态不了解 (3) 项目所有者和决策者分不清 (4) 不切实际的承诺 (5) 不能与员工之间的进行充分地沟通 6. 安全风险 软件产品本身是属于创造性的产品，产品本身的核心技术保密非常重要。但一直以来，我们在软件这方 面的安全意识比较淡薄，对软件产品的开发主要注重技术本身，而忽略了专利的保护。软件行业的技术人员流动是很普遍的现象，随着技术人员的

22、流失、变更，很能会导致产品和新技术的泄密，致使我们的软件产品被它公司窃取，导致项目失败。而且在软件方面关于知识产权的认定目前还没有明确的一个行业规范，这也是我们 软件项目潜在的风险。 了解了软件项目管理中的风险评估，相信大家更想了解的是如何规避这些风险吧。规避风险的方式有： (1) 以开发方诱导能保证需求的完整，使需求与客户的真实期望高度一致。再以书面方便形成用户需求这一重要的文档，避免疏漏造成的损失在软件系统的后续阶段被逐步地放大。 (2) 设立监督制度，项目开发中任何较大的决定都必须有客户参与进行的，在该项目中项目监督由项目开发中的质量监督组来实施。 (3) 需求变更需要经过统一的负责人提

23、出,并且要用户需求的审核领导认可,需求变更应该是定期而不是随时的提出,而且开发方应该做好详细的记录,让客户了解需求变更的实际情况。(4) 控制系统的复杂程度，过于简单的系统结构，对用户来使用比例会有明显的折扣，甚至造成软件寿命过短。反之，软件结构的过于灵活和通用，必然引起软件实现的难度增加，系统的复杂度会上升，这又会在实现和测试阶段带来风险。适当控制系统的复杂程度有利于降低开发的风险。 (5) 从软件工程的角度看，软件维护费用约占总费用的55%70%，系统越大，该费用越高。对系统可维护性的轻视是大型软件系统的最大风险。在软件漫长的运营期内，业务规则肯定会不断发展，科学的解决此问题的做法是不断对

24、软件系统进行版本升级，在确保可维护性的前提下逐步扩展系统。 (6) 设定应急计划，每个开发计划都至少应该设定一个应急预案去应对出现突发情况和不可遇知的风险。 以上就是针对软件项目管理中的风险评估做的相关介绍，从上文的介绍中也不难看出，系统的学习项目管理PMP认证也是非常有必要的，而且PMP对项目管理者来说，是含金量最高的证书，更是项目管理者的必要通行证!篇三：IT项目风险评估分析及管控 XXX项目风险评估分析与应对措施 XXX项目建设涉及项目实施规划与设计、数据采集、UI设计、软件开发与实施、硬件采购与安装、网络与数据中心工程、基建工程、弱电工程、工程施工、商务谈判与合同、资金管理、公共关系维

25、护、供应商管理、项目管理等众多方面的专业性建设与综合性统筹管理。 项目建设存在整体跨度大、专业性强、复杂度高低不同、工作量大等特征。 一、 缺乏共识的风险 1、与业主方的共识风险。 业主方对项目建设的难度、时间需求、具体解决方案等没有清晰认识，同时片面追求政绩、成果展示等项目驱动，从而对项目提出不现实或多变的要求。 2、项目组内部（包括企业方与供应商方）、企业内部的共识风险。 内部人员对项目定位、具体解决方案有多种理解与认识，而产生对项目建设走向、时间进度、成本等各方面造成至关重要影响。从建设的角度可以这么概括，在一个解决方案上达成共识比这个解决方案本身的先进性重要得多，但往往形成不了共识。

26、3、各方的项目驱动力的不同且存在变化，造成共识风险加大。 业主方注重政绩、特定的项目诉求及其它利益点；企业方注重项目正常完结、各方公共关系维护及项目款项收取；供应商注重既定需求的项目快速交付与项目款项收取，但各方项目驱动力是变化的。 应对：与各方就大的共识点达成意向，同时注意项目驱动力的不同并对各方不同策略响应；无法达成共识时，由决策人作决策。 二、 组织和管理风险 1、项目组织架构是否存在？成员分工是否清晰明确？ 决策人是否明确？沟通机制？会议制度？ 2、仅由项目经理制下的相关人员进行的项目决策，会导致权限不够、计划进度缓慢、计划时间延长； 3、公司高层在参与度不够的情况下，审查决策的周期比

27、预期的时间长； 4、各种因素影响下的预算削减，将打乱项目计划； 5、公司高层作出了打击项目组织积极性的决定； 6、项目缺乏必要的规范，导致工作失误与重复工作； 7、非技术的第三方的工作（预算批准、设备采购批准、法律方面的审查、安全保证等）时间比预期的延长。 应对：项目应为一把手工程，最高领导的支持力度及参与情况将是项目稳健的保证；健全的项目组织、沟通汇报机制、会议制度、项目进度管理等； 三、业主方风险 1、业主方没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和产品生产周期的变更； 2、业主方对规划、方案、原型和规格的审核决策周期比预期的要长； 3、业主方协调或答复的时间（如回答或澄清

28、与需求相关问题的时间、提供相关信息资料、协调相关资源落实）比预期长； 4、业主方对于最后交付的产品不满意，要求重新设计和重做； 5、业主方涉项目人员广，项目利益对众多相关人直接驱动不明显，存在工作进度被堵或拖延的情况； 6、部分建设需在现有资源或设备上进行整合，而这部分内容前期并未竣工或验收等情况；其它施工条件、施工配合等问题。 应对：多加强与业主方的沟涌、客情关系维护，客情维护不限于一、二把手概念，对项目影响较深的相关人物一并考虑。对子项目系统的建设，多进行事前需求引导及原型设计开发。利用现有设备问题，由业主方从上而下进行统一，不能利用的则进行新采购机制。 加强沟通，严谨工作作风与态度，并与

29、各方保持良好项目关系。 四、需求风险 1、目前需求状态：业主方未能提出明确需求、致远方自身探索而自定义需求、供应商根据合约执行既有需求。 2、惯例上，需求已经成为项目建设的基准，但本项目具体需求属各方仍在探索中，并无具体确明的需求存在，新需求的提及将贯穿整个项目建设； 3、现有需求定义欠佳，而进一步的定义会扩展项目范畴，或者添加额外的需求； 4、缺少有效的需求变化管理过程。 应对：致远方对需求做好明确，并以此宣贯引导给业主方形成业主方的需求，与供应商的沟通或合作，则寻求对需求变化宽泛变动的空间。同时对需求的变动，进行严格项目管控。 五、技术/设备/产品的风险 1、项目的顶层设计是否合理，是否可

30、行，缺少相对权威的评估，同时智慧城市作为新生事物，也缺乏真正有效的设计评估。 2、 在缺乏一家供应商可满足整体解决方案情况，只能分拆由多家供应商来建设的实施策略，是否真正达到预期效果，对项目实施带来挑战。3、在供应商或产品的选型上，存在需求理解、沟通表达、信息不对称或欺诈等情况，产生选型风险； 4、需求调研是否详细具体，可否支撑转换为软硬件产品的设计与实现；产品的设计是否科学、开放、规范；产品实现的技术是否先进、满足要求； 5、软件产品开发的程序把控可高可低的风险，项目的业务需求模糊或复杂化，软件开发的过程中需求和满意度都是以客户为准，在软件实施开发的过程中，需求获取和计划的落实都是需要每一步

31、都要不停的沟通和进行确认，确保主方向不会变。 6、软件的实现技术手段是否能够同时满足大量用户并发及实际使用体验的性能要求，相应技术难点与服务器资源的解决； 7、软件开发过程可能的问题：设计质量低下，导致重复设计；一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发新的功能；代码和库质量低下,导致需要进行额外的测试，修正错误，或重新制作；过高估计了增强型工具对计划进度的节省量；分别开发的模块无法有效集成,需要重新设计或制作。 8、软件产品外包开发的质量的是否保证，能否做到可伸缩性、可维护性、易用性、先进性、代码的规范性； 9、各方对项目亮点需求、功能的把握不太到位，或实现

32、不到位； 10、各方产品在系统集成上的考虑与对接机制的实现、配合问题；同时存在多地沟通对接的难度大的情况； 11、提供给软件产品使用的系统运行环境是否满足各家供应商的要求，由此可以产生新费用； 12、产品完成后相应带的售后服务问题（跨地区、商务条款、支持的有效性等）； 13、硬件产品的采购周期，现有设备的匹配支持程度或改造程度等设备资源保障的问题； 应对：设计上多学习多接触智慧城市项目，借鉴别人好的经验，在项目实施开展初期采用一至二个项目先开展的实施策略，以控制整体风险；对供应商严挑细选，并做好有备用供应商机制； 加强直接沟通，以达到对项目统一的认识，对需求有明确的认知，对需求调研做好充分的准

33、备；明确开发计划与资源需求计划，并做好项目管理，严格跟踪进度；软件开发尽可能采用原型开发模式，提前看到原型效果，并与业主方进行宣讲以作需求引导；软件开发过程监督，节点内容及时交付，我方提前界入产品质量或性能测试，并对可能产生的问题尽早提出让对方响应预防；加强有效沟通，减少磨合带来的问题；商务合同对产品不能交付等情况进行约束；对设备资源等情况提前考虑采购周期等进行计划；现有设备考虑兼容性与牵涉问题，牵涉面太大则以新采购机制作考虑。 六、人力资源的风险 1、人员短缺，找不到项目急需的具有特定技能的人，并可能长期招不到人；项目人员经验不够，能力欠缺； 2、某些人员需要更多的时间适应还不熟悉的软件工具

34、和环境，或经过较长时间后发现不能达到要求； 3、项目后期加入新的开发人员，需进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率降低； 4、由于项目组成员之间（与合作伙伴间、与公司内部）发生意见冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作； 5、技术人员和管理层之间关系不佳，导致决策缓慢，影响全局； 6、团队成员是否能齐心协力为项目的共同目标服务，是影响进度和质量的关键因素； 7、缺乏激励措施，士气低下，降低了生产能力； 8、人员相对熟悉项目情况的较稳定状态下，出现人员离职等流动情况； 9、人员在技术、管理能力的短板或短视，对项目的全局或局部把握不太到位； 10、各供应商也可能

35、存在以上相同情况。 应对：加强招聘环节的把握，寻找“志同道合”与素质能力俱备的员工与合作伙伴，对项目的定位与建设达成共识；加强沟通表达，形成畅通的沟通机制，且探讨问题做到对事不对人；加强对XXX项目综合素质的学习提升；建立有效的项目管理及公平公正的激励措施。 七、财务的风险 1、公司高层对项目成本心理定位不够，执行层对项目预算不准，实际建设过程因需求变动等因素造成的成本增加频繁；溢价实施的可能性较高； 2、工期内并行子项目建设较多，支出种类繁多且频繁，突发费用需求可能性大增； 3、业主方不能按合同及时支付款项，影响项目的正常支出，严重的情况，影响项目建设导向； 4、我方不能按合同及时支付供应商款项，影响供应商方的项目支出，产生项目障碍或增加沟通成本，情况严重的可能影响影响项目建设导向； 5、项目运营大量资金的需求，对正常资金链产生影响或中断； 6、因财务因素对项目选型的影响，或导致建设需求的调整变化。 应对：执行层尽可能考虑各种因素，将预算做得相对准确；领导层对项目的复杂性、资金支