项目管理中可能存在的风险5则范文

第一篇：项目管理中可能存在的风险

1.最常见的进度计划风险

1）功能无限蔓延；

2）需求镀金或开发人员镀金；

3）质量不定

4）计划过于乐观

5）设计欠佳

6）银弹综合症

7）研发导向开发

8）人员薄弱

9）来自上级对项目需求的干预

2.进度计划风险完整列表

2.1 计划编制风险

1）计划、资源和产品定义全凭决策组或上层领导口头指令，并且不完全一致；

2）计划是优化的，是“最佳状态”；

3）计划忽略了必要的任务；

4）计划基于使用特定的小组成员，而那个小组成员其实指望不上。

5）在限定的时间内无法建成已定规模大小的产品；

6）产品规模比估计的要大一些；

7）工作量大于估算数；

8）进度已经拖延的项目在重新评估时过于优化或忽视项目历史；

9）过度的进度压力造成生产率下降；

10）目标日期提前，但没有相应地调整产品范围或可用资源；

11）一个任务的延迟导致相关任务的连锁反应；

12）涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多。

2.2 组织和管理

1）项目缺乏一个有凝聚力的最高领导人；

2）由于前期乏力，项目长时间被搁置；

3）解雇和削减开支导致项目小组能力下降；

4）仅由管理层或市场人员进行技术决策，导致计划进度延长；

5）低效的项目组结构降低生产率；

6）管理层审查/决策的周期比预期时间长；

7）预算削减打乱项目计划；

8）管理层做出了打击项目组织积极性的决定；

9）非技术的第三方的工作比预期延长（如审批，采购等）；

10）计划性太差，无法适应期望的开发速度；

11）项目计划由于压力而放弃，导致开发混乱、低效；

12）管理层强调英雄主义，而忽视客观确切的状态报告，这会降低发现和改正问题的能力。

2.3 开发环境

1）设施没有及时到位；

2）设施到位，但不配套；

3）设施拥挤、杂乱或者破损；

4）开发工具未能及时到位；

5）开发工具不如期望那样有效，开发人员需要时间创建工作环境或切换新的工

具；

6）开发工具的选择不是基于技术需求，不能提供计划要求的性能；

7）新开发工具的学习期比预期的长，内容繁多。

2.4 最终用户

1）最终用户坚持新的需求；

2）最终用户对于最后交付的产品不满意，要求重新设计和重做；

3）最终用户不买进项目产品，无法提供后续支持；

4）最终用户的意见未被采纳，造成产品最终无法满足用户期望，而必须重做。

2.5 决策组

1）决策组坚持新的需求；

2）决策组对规划、原型和规格的审核/决策周期比预期长；

3）决策组没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和耗时的重复；

4）决策组答复的时间比预期长（如回答需求中需澄清的问题）；

5）决策组坚持技术决策而导致进度计划延长；

6）决策组对开发进度管理过细，导致实际进展变慢；

7）决策组提供的组件无法与开发的产品匹配，导致额外的设计和集成工作；

8）决策组提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的决策组关系管理工作；

9）决策组要求的支持工具和环境不兼容、性能差或者功能不完善，导致生产率降

低；

10）决策组不接受交付的软件，尽管它满足了所有的规格；

11）决策组期望的开发速度是开发人员无法达到的。

2.6 承包商

1）承包商没有按承诺交付组件；

2）承包商递交的组件质量低下无法接收，必须花时间改进质量；

3）承包商没有买进项目开发需要的工具，进而无法提供需要的性能水平。

2.7 需求

1）需求已经成为项目基准，但变化还在继续；

2）需求定义欠佳，而进一步的定义会扩展项目范畴；

3）添加额外的需求；

4）产品定义含混的部分比预期需要更多的时间。

2.8 产品

1）错误发生率高的模块需要比预期更多的测试、设计和实现工作；

2）校正质量低下不可接受的产品，需要比预期更多的测试、设计和实现工作。

3）在一个或多个新兴领域推广计算机技术使得计划进度的延长不可预期；

4）由于软件功能的错误，需要重新设计和实现；

5）开发额外不需要的功能（镀金）延长了计划进度；

6）要满足产品规格与速度要求，需比预期更多时间，包括重新设计和实现的时间；

7）严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作；

8）要求与其他系统、复杂系统或不受本项目控制的系统相连，导致无法预料的设

计、实现和测试工作。

9）要求在不同操作系统下运行将花费比预期更长的时间；

10）在不熟悉或未经检验的软（硬）件环境中运行产生未预料的问题；

11）开发一种对组织全新的模块将比预期花费更长的时间；

12）依赖正在开发中的技术将延长计划进度。

2.9 外部环境

1）产品依赖政府规章，而规章的改变将是不可预期的；

2）产品依赖草拟中的技术标准，而最后的标准将是不可预期的。

2.10 人员

1）招聘人员所花时间比预期的长；

2）作为先决条件的任务不能按时完成（如培训、其它项目）；

3）开发人员和管理层之间关系不佳导致决策缓慢，影响全局；

4）项目组成员没有全身心投入项目，进而无法达到需要的产品性能水平；

5）缺乏激励措施，士气低下，降低了生产能力；

6）缺乏必要的规范，增加了工作失误与重复工作；

7）某些人需要更多时间适应不熟悉的软件工具和环境、硬件环境、编程语言；

8）项目结束前，合同制人员离开团队，或雇员辞职；

9）项目后期加入新的开发人员，额外的培训和沟通降低现有成员的效率；

10）项目组成员不能有效地一起工作；

11）由于项目组成员间的冲突，导致沟通不畅、设计欠佳、接口错误和额外的重复工作；

12）有问题的成员没有调离项目组，损害了项目组其他成员的积极性；

13）项目的最佳人选未加入项目组；

14）项目的最佳人选已加入项目组，但因其他原因未能合理使用；

15）没有找到项目急需的具有特定技能的人；

16）关键人物只能兼职参与；

17）项目人员不足；

18）任务的分配与人员技能不匹配；

19）人员工作的进展比预期的慢；

20）项目管理人员怠工导致计划和进度失效；

21）技术人员怠工导致工作遗漏或质量低下，工作需要重做。

2.11 设计与实现

1）设计过于简单，无法确定主要事件，并导致重新设计和实现；

2）设计过于复杂，导致一些不必要的工作，影响实现效率；

3）设计质量低下，导致重复设计和实现

4）使用不熟悉的方法，导致额外的培训时间，并重犯前期使用这种方法时导致的错误；

5）产品采用低级语言来实施，导致生产率比预期的低；

6）一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新库或自选

开发所要的功能；

7）代码和库质量低下，导致需要额外的测试、错误修正或重做；

8）过高估计了增强型工具对计划进度的节省量；

9）分别开发的模块无法有效集成，需要重新设计或重做。

2.12 过程

1）大量的纸面工作导致进程比预期的慢；

2）进程跟踪不准确，导致无法预知项目是否已落后于计划进度；

3）前期的质量保证行为不真实，导致后期的重复工作；

4）质量跟踪不准确，导致无法得知影响进度的质量问题；

5）太不正规，导致沟通不足，质量问题和工作重做；

6）过于正规，导致过多耗时无用的工作；

7）向管理层撰写进度报告占用的开发人员的时间比预期的多；

8）风险管理粗心，导致没有发现重大的项目风险；

9）软件项目风险管理花费的时间比预期的多。

第二篇：IT运维管理中可能存在的关键问题

IT运维管理中可能存在的关键问题

一、IT运维管理可能存在的问题

1.1 IT运维机制不完善，流程操作层面缺乏统一

没有建立起稳定、规范的IT运维机制。现有的IT运维流程的操作层面缺乏统一。如事件单提交之后，事件预判和优先级的设定缺少统一、规范的指导文档，仅以人员的主观经验或约定俗成的方式指导事件的处理过程。有识别但无规范，有处理但无管理，有人员但忙于救火，有工具但支持力度不足。因此，“轻规范、重维护”的IT运维现状容易造成因个体技能差异带来IT运维的不稳定，直接影响维护体系的效果。

1.2 经验不少，知识不多，过度依赖核心人员

在实际工作中积累的、有价值的经验仅存在于头脑之中，未能作为书面的知识记录规范地保存下来。经验始终仅能在小范围内得到传播和继承，无法在更大的范围内体现其价值。这样导致了无论是事件性质的识别、优先级的界定，还是疑难问题的分析诊断，均汇总至少数核心人员进行处理。这样不仅增加了少数核心人员的工作量，也容易产生工作流程的“瓶颈”，降低运维团队整体的事件及问题处理效率。

1.3 IT运维的绩效考核机制尚不完善

主观的绩效考核难执行，客观的绩效考核难制定，模糊的绩效考核难见效。目前在绩效考核方面虽然采用填写工作表的方式对不同岗位的工作时间进行收集、评测和考核，在一定程度上体现了IT运维人员的工作量情况，但还是很难全面准确的反映IT运维人员真实的工作绩效表现。因此，IT运维人员绩效考核机制需要进一步完善，帮助组织构建奖惩分明的文化和环境，推动IT运维团队的良性持续的发展。

1.4 IT基础架构管理工具欠缺

基于门户、财务管理、采购管理、人事管理、文件服务等构成了公司的核心业务系统。这些复杂的核心系统保证了整体业务的顺畅运行。但作为支撑核心系统运行的IT基础架构，目前仅有H3C的网络监控和基于Landesk的桌面管理系统。现有的IT管理工具偏重于技术层面的故障发现及预警，对于发现的事件虽有相应的管理流程汇报，但仍未找到合适的工具为其提供全面、安全、稳定的运行支持。

1.5 缺乏有效、完善的CMDB（配置项管理数据库）

目前运行维护室仅有对关键应用系统相关IT设备设施的初步梳理，虽然在一定程度上收集了部分配置项信息，但是当前仅限于关键业务的、缺乏工具支持的、简单的CMDB建设很难满足今后全面实施信息化的需求。CMDB的建设是一个长期而艰巨的任务，不仅需要更详细的配置项属性数据、更准确的相互关系信息，而且也需要一个科学有效的配置管理模式及工具予以支持。

1.6 缺少面向用户的IT服务报告 运行维护室对核心系统运行提供固定周期的IT 管理报告，如：系统运行报告、机房环境报告、备份报告、报告等等。但由于IT管理报告的内容多以技术语言提交且仅限部门内部和少数领导使用。作为外部用户的业务部门不仅无法接触，而且受专业所限难以理解，无法充分利用IT管理报告提供的信息。

在期望从成本中心向利润中心转型的过程中，运行维护室面向外部用户时不能再以技术语言提交IT管理报告，而应该提交符合一般用户阅读需要的IT服务报告，实现IT运维的“服务于用户，为用户所用”的目的。

二、加强IT运维管理的措施

2.1 建立统一的IT运维管理体系，完善并规范IT运维流程

参照ITIL最佳实践并结合公司的实际情况，将IT运维管理规范化为一系列标准流程，包括服务台、事件管理、问题管理、变更管理、发布管理、配置管理和服务级别管理等。然后通过IT服务管理工具将各个IT运维流程集中在同一个平台上进行管理。基于标准的流程体系和统一的管理平台，与IT运维相关的资源（包括部门、人员）得以有效整合，并采用相互识别的“相同语言”进行深入、充分的沟通，提高生产效率和信息传递的及时性。

2.2 建立基于IT运维管理流程的IT人员绩效管理和激励机制 根据公司全面实施信息化的要求，建议运行维护室组建具备完善的专业知识和管理能力的IT运维管理团队。因此，建立与IT运维管理流程体系相符的人员绩效管理及激励机制显得尤为重要。建立量化KPI，对包括服务效率及服务质量等多方面进行业绩考核。通过IT运维管理系统平台，对IT运维人员的工作进行数量和质量上的记录、统计和分析。在基于ITIL流程明确IT人员岗位职责的基础上，定义关键考核指标并通过IT运维管理系统收集数据，进行整理、分析产生绩效报告，最终实现IT绩效管理的信息化。

2.3 提供面向客户的IT服务报告，为业务部门和IT运维管理提供决策依据

参考ITIL及ISO20000的最佳实践，可建立专门的工作流程对IT服务报告及IT运维服务管理信息作进一步的完善。实现向客户或业务部门以“客户化的语言”提供约定的服务信息，同时也能为内部IT运维提供有价值的管理信息。如：某个时间段内那些方面的故障出现的数量最多；那些方面的故障解决的效率最高或最低；IT维护人员的工作负荷统计；问题分布在哪些系统或设备等。这些服务信息统计，能帮助IT运维管理和决策部门进行决策和趋势分析，从而做到对IT系统中的各类问题和相应的服务状况进行全面掌握和了解。

2.4 支持经验和知识的共享化

提供丰富知识库和完善管理。用户通过知识库，如FAQ、关键词检索等，可以初步搜寻解决方法，这样问题就会以最小的资源开销和最快的处理效率得以解决；IT维护人员通过知识库及时、准确地选择解决最优方案，可解决大部分常规问题；资深运维人员、专家，可以根据故障发生的频度，把经过实践证明正确的解决方案形成知识库，供其他运维人员使用；另外，相关应用系统的业务处理人员可以通过共享的知识库或实践指导库，提交或者获取相关业务处理的知识。

2.5 建立并完善CMDB

实现用户、资产、以往问题的历史记录等可查询、可追溯IT运维管理系统通过组建CMDB对用户信息、资产信息进行记录和维护，并把每个事件/问题与用户以及发生故障的资产对应起来，形成历史记录以便查询和借鉴。如：某个用户报告某路由器通讯故障，维护人员就可以根据资产编号查询到该路由器以往的故障状况。如该路由器出现过多次故障，并且都是线路质量较差，维护人员则可以根据这一依据向有关部门提出线路维护申请。

2.6 推行服务级别管理，提高客户对IT运维的服务满意度

在“内部市场化”的要求下，最终用户的服务满意与否将成为IT运维质量的考评尺度。为此，推行服务级别管理有利于明确用户/客户的业务需求并使之规范化、标准化。因为只有在服务双方都认可的服务范围内提供合乎需求的IT服务才能最终获得用户/客户满意的评价。比如：故障的响应时间约定、备品备件的替换原则、约定的设备巡检日期等。通过服务级别管理不仅可以提供清晰、规范的IT运维服务，根据服务级别管理的流程可以对服务的结果进行持续改进。

三、结束语

加强IT运维管理，及时发现问题及解决问题，从根本上提高IT运维效率和效果，实现IT运维知识规范化、模板化，提高客户满意度，并提升运维服务的核心竞争力。

第三篇：化妆品中可能存在的安全性风险物质风险评估指南

化妆品中可能存在的安全性风险物质风险评估指南

2018.01.11 汇诚佳业

一、化妆品中可能存在的安全性风险物质的含义

化妆品中可能存在的安全性风险物质是指由化妆品原料带入、生产过程中产生或带入的，可能对人体健康造成潜在危害的物质。

二、风险评估基本程序

（一）危害识别：根据物质的理化特性、毒理学试验数据、临床研究、人群流行病学调查、定量构效关系等资料来确定该物质是否会对人体健康造成潜在的危害。

（二）危害特征描述（剂量反应关系评估）：分析评价该物质的毒性反应与暴露之间的关系。对有阈值的化学物质，确定“未观察到有害作用的剂量水平（NOAEL）”或“观察到有害作用的最低剂量水平（LOAEL）”。对于无阈值的致癌物，可根据试验数据用合适的剂量反应关系外推模型来确定该物质的实际安全剂量（VSD）。

（三）暴露评估：一般可通过申报化妆品的产品类型和使用方法，结合化妆品中可能存在的安全性风险物质的含量或检出量，在充分考虑可能的化妆品使用人群（包括特殊人群，如婴幼儿、孕妇等）的基础上，定性和定量评价化妆品中可能存在的安全性风险物质对人体可能的暴露剂量。

（四）风险特征描述：确定该物质对人体健康造成危害的概率及范围。对具有阈值的物质，计算安全边际（MOS）。对于没有阈值的物质（如无阈值的致癌物），应确定暴露量与实际安全剂量（VSD）之间的差异。

三、评估资料的提交形式

申请人可按以下两种形式提交化妆品中可能存在的安全性风险物质评估资料：

（一）申请人通过危害识别，判断产品中不含可能存在的安全性风险物质的，可以提交相应的承诺书。承诺书应当陈述申请人对产品进行危害识别的分析过程及该产品不含可能存在的安全性风险物质的理由等。

（二）经危害识别后申请人认为产品中含有可能存在的安全性风险物质的，则应当提交相应的风险评估资料。

四、风险评估资料要求

我国化妆品相关规定中已有限量值的物质，不需要提供相关的风险评估资料；国外权威机构已建立相关限量值或已有相关评价结论的，申请人可以提供相应的安全性评价报告等资料，不需要另行开展风险评估。

申请人提交的风险评估资料，应包括以下内容：

（一）化妆品中可能存在的安全性风险物质的来源。

（二）可能存在的安全性风险物质概述，包括该物质的理化特性、生物学特性等。

（三）化妆品（或原料）中可能存在的安全性风险物质的含量及其相应的检测方法，并提供相应资料。

（四）国内外法规或文献中关于可能存在的安全性风险物质在化妆品和原料以及食品、水、空气等介质（如果有）中的限量水平或含量的简要综述。

（五）毒理学相关资料：

1.化妆品中可能存在的安全性风险物质的毒理学资料简述，至少包括是否被国际癌症研究机构（IARC）纳入致癌物。

2.参照现行《化妆品卫生规范》毒理学试验方法总则的要求，提供相应的毒理学资料摘要。根据可能存在的安全性风险物质的特性，可增加或减少某些相应项目的资料。

（六）风险评估应遵循风险评估基本程序，结合申报产品的特点进行。风险评估报告应包括具体评估内容及其结论。

（七）配方中含有植物来源原料的,对于仅经机械加工后直接使用的植物原料，应当说明可能含有农药残留的情况；对于除机械加工外，需经进一步提取加工的植物来源原料，必要时，也应说明可能含有农药残留的情况。

（八）在现有技术条件下，能够降低产品中可能存在的安全性风险物质含量的有关技术资料，必要时提交工艺改进的措施。

上述风险评估的相关参考文献和资料包括申请人的试验资料或科学文献资料，其中包括国内外官方网站、国际组织网站发布的内容。

五、风险评估资料的审评原则

(一）对于申请人提交承诺书的，应对产品中是否含有与《化妆品卫生规范》规定的禁用物质等相关的可能存在的安全性风险物质及其依据进行审评。

（二）对于申请人提交风险评估资料的，应对其完整性、合理性和科学性进行审评：

1.评估资料内容是否完整并符合上述有关资料要求，不能完整提供的应有合理说明；

2.资料来源是否可靠，所提供资料是否为试验、检测报告或公开发表的科学文献；

3．可能存在的安全性风险物质来源是否清楚，该物质的理化特性、生物学特性是否明确，是否提供该物质的含量及相应的检测方法，必要的毒理学评价资料，风险评估过程和评估结论等；

4.依据是否科学，资料是否充分，关键数据是否合理，分析是否科学、符合逻辑，结论是否正确。

（三）经审评认为承诺书存在问题的，审评专家应根据化妆品监管相关规定提出具体意见及其相关依据。申请人应当在规定的时限内提供不含可能存在的安全性风险物质的依据或相应的风险评估资料。

（四）随着科学认识的发展，国家食品药品监督管理局可对已经批准或备案的化妆品中可能存在的安全性风险物质有关的风险评估资料进行再审评。

第四篇：IT项目管理中的风险控制

IT项目管理中的风险控制

无论是系统集成或是软件开发，IT公司经常面临着各种项目的实施和管理，面临着如何确定项目的投资价值、评估利益大小、分析不确定因素、决定投资回收时间等众多问题。并且，一个IT项目，无论其规模大小，必然会为被实施方（用户）在管理、业务经营等多方面带来变革，这就使IT项目必然具有高风险性的特点。尤其是近年来，IT项目的广泛实施，一方面为众多的企业带来了管理、经营方面的革新，而另一方面，夭折、中断、失败的项目也不在少数。因此，如何在项目实施中有效地管理风险、控制风险，已经成为了项目实施成功的必要条件。

项目风险的管理不仅贯穿于整个项目过程，而且在项目事件发生之前风险的分析就已经开始。我们可以根据风险控制与项目事件发生的时间将风险管理划分为三个部分：事前控制——风险管理规划，事中控制——风险管理方法，事后控制——风险管理报告。

一、事前控制——风险管理规划

风险管理规划是在项目正式启动前或启动初期对项目的一个纵观全局的基于风险角度的考虑、分析、规划，也是项目风险控制中最为关键的内容，包括风险形势评估、风险识别、风险分析和风险评价等几部分。

1、风险形势评估

风险形势评估以项目计划、项目预算、项目进度等基本信息为依据，着眼于明确项目的目标、战略、战术以及实现项目目标的手段和资源。从而实现：通过风险的角度审查项目计划认清项目形势，并揭示隐藏的一些项目前提和假设，使项目管理者在项目初期就能识别出一些风险。尤其是项目建议书、可行性报告或项目计划一般都是在若干假设、前提、预测的基础上完成的，这些假设、前提、预测在项目实施期间有可能成立，也有可能不成立。而这其中隐藏的风险问题又通常是被忽视的。一旦问题发生，往往造成项目管理方的措手不及和无一应对。例如项目计划中假设用户实施小组全力支持、脱产或几乎脱产投入IT项目的实施，但在实际过程中，用户方人员却不得不抽出大量时间处理原有的业务，造成IT项目实施进度的拖延和实施效果不尽人意的风险。诸如此类的例子还有很多。为了找出这些隐藏的项目条件和威胁，就需要对与项目相关的各种计划进行详细审查，如人力资源计划、合同管理计划、项目采购计划等等。由此我们可以得出，风险形势评估一般应重视以下内容：项目的起因、目的、项目的范围、组织目标与项目目标的相互关系、项目的贡献、项目条件、制约因素等。

2、风险识别

在对项目的基础的风险形势评估之上，就需要对各种显露的和潜在的风险进行识别。风险识别实际上是对将来可能发生的风险事件的一种设想和猜测。因此，一般的风险识别结果应包括风险的分类、来源、表现及其后果、以及引发的相关项目管理要求。在具体识别风险时，一方面可利用一些常识、经验和判断，通过以前经历的项目中积累起来的资料、数据、经验和教训，或者请教相关的专家和资深从业人员，采用集体讨论的方式。另一方面，可以通过分解项目的范围、结构来识别风险，理清项目的组成和各个组成部分的性质、之间的关系、与外因的联系等内容，从而减少项目实施过程中的不确定性。除此之外，还可以利用一些技术和工具。比如，结合经验和教训，将项目成功和失败的原因罗列成一张核对表，或者是项目的实施范围、质量控制、项目进度、采购与合同管理、人力资源与沟通等。以上都是风险识别常用的一些手段和方法，当然还有其他更多的途径，因项目而异，灵活运用。

3、风险分析和评价

在进行风险识别并整理之后，必须就各项风险对整个项目的影响程度做一些分析和评价，通常这些评价建立在以特性为依据的判断和以数据统计为依据的研究上。风险分析的方法非

常多，一般采用统计学范畴内的概率、分布频率、平均数众数等方法。但无论是哪一种工具，都各有长短，而且不可避免的会受到分析者的主观影响。可以通过多角度多人员的分析或者采取头脑风暴法等尽可能避免。此外，我们应当明确，风险是一种变化着的事物，基于这种易变条件上的预测和分析，是不可能做到十分的精确和可靠的。所有的风险分析都只有一个目的，即尽量避免项目的失控和为具体的项目实施中的突发问题预留足够的后备措施和缓冲空间。

风险评价之后，项目面临着两种选择，即面临着不可承受风险和可承受风险。对于前者，或者终止项目，或者采取补救措施，降低风险或改变项目；对于后者，则需要在项目之中进行风险控制。

二、事中控制——风险管理方法

管理风险，即控制风险，通过风险监视和风险规避消除一些潜在的威胁项目健康实施的事件。风险的管理在整个项目生命周期中是连续、反复进行的，消除了某些风险来源后，有可能又会出现其他的风险，而且，为减少风险损失而进行的风险管理本身也会带来新的风险。比如，管理风险所耗用的项目资源造成项目其他部分的可用资源减少，规避风险的行动影响原定项目计划而带来风险等。因此，在项目实施过程中，项目管理人员必须制订标准并按阶段衡量项目进展状况，时时监视项目实际进展情况，根据风险情况果断调整和纠正项目行动。

1、风险监视

由于时间对项目的影响是很难预计的，因此风险监视是项目实施过程中的一项重要工作。监视风险即监视项目产品、以及项目过程的进展和项目环境的变化，通过核查项目进展的效果与计划的差异来改善项目的实施。一般情况下，随着时间的推移，有关项目风险的信息会逐渐增多，风险的不确定性会逐渐降低，但风险监视工作也随信息量的增大而日渐复杂。我们一般可采取项目的审核检查的方式，通过各实施阶段的目标、计划、有关项目风险的信息会逐渐增多，风险的不确定性会逐渐降低，但风险监视工作也随信息量的增大而日渐复杂。我们一般可采取项目的审核检查的方式，通过各实施阶段的目标、计划、实际效果的对比、分析，寻找问题的根源，提出解决问题的方法。

2、风险规避

在风险管理规划基础上进行风险控制，一旦监视到风险，就应采取合理措施进行风险规避，可以从改变风险性质、改变风险发生的概率、改变风险的影响大小等多方面着手。风险规避的策略一般有预防、转移、回避、接受、后备措施等几种方式。

其中，预防风险尤其不能忽视项目的教育培训和按程序办事两个方面。由于项目实施成员的任何不当行为都会构成项目的风险因素，要减轻与之相应的影响，就必须对有关人员进行详细和有效的风险教育和项目培训，教育培训的内容应该包含项目相关的策略、计划、标准、规章规范、项目知识、产品知识等。在项目活动中，应该严格按照项目制度，如进度、人力调配、文档管理、资源分配等。

转移风险，在IT项目中使用最频繁的应该要数合作伙伴、项目外包、保险与担保等手段了。无论是与合作伙伴的协同实施还是项目的外包，都能在人力资源、成本费用、项目进度等方面分散风险，开脱责任。但转移风险的同时也必然带来利润的一部分流失。

回避风险，是指当项目风险潜在威胁的可能性极大，并会带来严重的后果，无法转移又不能承受时，通过改变项目来规避风险。通常会通过修改项目目标、项目范围、项目结构等方式来回避风险的威胁。

接受风险，作为规避风险的常见方法，主要是指主动将风险事件的不利后果承担下来，这种后果通常主要反映在实施周期、成本费用的有限增加上，以牺牲项目收益而不影响项目整体。

用于规避风险的后备措施，主要体现在后备费用、预留进度时间、后备技术力量三个方

面，这些后备措施在项目计划中就应预留，保证在项目实施过程中，能充分调用后备力量解决问题。

三、事后控制——风险管理报告

无论项目进展的情况如何，都必须将风险管理的计划、行动、结果整理、汇总、进行分析，形成风险管理报告。风险管理的持续性要求风险管理报告的连贯性和不间断性，因此，该报告不是仅仅在项目结束之后才制作的，而是应该视项目的进展状况、项目计划、报告的对象等条件采取书面或口头、不定期的或阶段性的等多种方式，为项目的实施、控制、管理、决策提供信息基础。

我们在项目管理中进行风险控制的同时，还应该问自己几个问题：所制订的风险管理策略本身是否可行？实施风险控制的措施和手段是否与项目总目标保持一致？通过不断地在实践中反思、尝试、总结、分析，提高风险管理的水平。风险总是和效益并存的。只有正确地识别风险、分析风险、规避风险，才能确保每一个项目的顺利实施和成功完成，才能给企业带来更多的效益。

第五篇：项目管理风险

1.功能无限蔓延；

2.需求镀金或者开发人员镀金；

3.质量不定；

4.计划过于乐观；

5.设计欠佳；

6.银弹综合症；

7.研发导向的开发；

8.人员薄弱；

9.签约商失败；

10.研发人员和客户的摩擦；

1.计划编制风险：

1.1 计划、资源和产品定义完全靠客户或者上层领导的口头命令，并且不完全一致；

1.2 计划是优化的，但是是不现实的；

1.3 计划忽略了必要的任务；

1.4 计划基于使用特定的小组成员，而那个小组成员基本上指望不上；

1.5 在限定时间内无法建立成已定规模的产品；

1.6 产品规模比估计的大；

1.7 进度已经拖延的项目在重新评估时过于优化和忽略项目历史；

1.8 过度的进度压力造成生产率下降；

1.9 目标日期提前，没有相应调整产品范围和可用资源；

1.10 一个任务的拖延导致相关任务的连锁反应；

1.11 涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多；组织和管理：

2.1 项目缺乏一个有凝聚力的最高领导人；

2.2 由于前期乏力，项目长时间搁置；

2.3 解雇和削减开支导致项目小组能力下降；

2.4 仅由管理层或市场人员来进行技术决策，导致计划进度延长；

2.5 低效的项目组结构降低生产率；

2.6 管理层审查/决策的周期比预期时间长；

2.7 预算削减打乱项目计划；

2.8 管理层做出了打击项目积极性的决定；

2.9 非技术的第三方工作比预期延长（预算批准、设备采购批准……）

2.10 计划性太差，无法适应期望的开发速度；

2.11 项目计划由于压力而放弃，导致开发混乱，低效；

2.12 管理层强调英雄主义，而忽略客观确切的状态报告，降低发现和改正问题的能力； 3 开发环境：

3.1 设施没有及时到位；

3.2 设施到位，但是不配套；

3.3 设施拥挤，杂乱或者破损；

3.4 开发工具没有及时到位；

3.5 开发工具不如期望那样有效，开发人员需要时间创建工作环境或者切换新的工具；

3.6 开发工具的选择不是基于技术需求，不能提供计划所需要的性能；

3.7 新开发工具的学习比预期的长，内容多；最终用户：

4.1 最终用户坚持新的需求；

4.2 最终用户对于最后交付产品不满意，要求重新设计和重做；

4.3 最终用户不买进项目产品，无法提供后续支持；

4.4 最终用户的意见没有被采纳，造成产品最终无法满足用户期望，而必须重做； 5 客户：

5.1 客户坚持新的需求；

5.2 客户对规划、原型和规格的审核/决策周期比预期要长；；

5.3 客户没有或不能参加规划、原型、规格阶段的评审，导致需求不稳定和耗时的变更；

5.4 客户坚持技术决策导致进度计划延长；

5.5 客户对于开发进度管理过细，导致实际进度变慢；

5.6 客户提供的组件无法和开发产品匹配，导致额外的设计和集成工作；

5.7 客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户管理管理工作；

5.8 客户要求的支持工具和环境不兼容，性能差或者功能不完善，导致生产率下降；

5.9 客户不接受交付的软件，尽管已经满足了所有的规格；

5.10 客户期望的开发速度是开发人员无法达到的；承包商：

6.1 承包商没有按承诺交付组件；

6.2 承包商递交的组件质量低下无法接收，必须花费时间改进质量；

6.3 承包商没有买进项目开发所需要的公举，进而无法提供需要的性能水平；需求：

7.1 需求已经成为项目的基准，但是变化还在继续；

7.2 需求定义欠佳，而进一步的定义会扩展项目范畴；

7.3 添加额外的需求；

7.4 产品定义含糊的部分比预期需要更多时间；产品：

8.1 错误发生几率高的模块需要比预期更多的测试，设计和实现工作；

8.2 校正质量低下不可接受的产品，需要比预期更多的测试，设计和实现工作；

8.3 在一个或多个新兴领域推广计算机技术使得计划进度的延长不可预期；

8.4 由于软件功能的错误，需要重新设计和实现；

8.5 开发额外不需要的功能，延长了计划进度；

8.6 要满足产品规模和进度要求，需要比预期更多的事件，包括重新设计和实现工作；

8.7 严格要求与现有系统兼容，需要进行比预期更多的事件进行测试，设计和实现工作；

8.8 要求在不同操作系统下运行将花费比预期更长的时间；

8.9 在不熟悉或没有经验的软件环境中运行产生没有预料的问题；

8.10 在不熟悉或者没有经验的硬件环境中运行产生没有预料的问题；

8.11 开发一种对组织全新的模块将比预期花费更长的时间；

8.12 依赖于正在开发中的技术将延长计划进度；外部环境：

9.1 产品依赖于政府规章，而规章的改变是不可避免的；

9.2 产品依赖于草拟中的技术标准，而最后的标准是不可预期的；人员：

10.1 招聘人员所花费时间比预期长；

10.2 做为先决条件的任务不能万丞，比如培训，其他项目的万丞，工作许可证； 10.3 开发人员和管理层关系不佳导致决策缓慢，影响全局；

10.4 项目组乘员没有全身心投入项目，进而无法达到需要的产品性能水平；

10.5 缺乏激励机制，士气低下，降低了生产能力；

10.6 缺乏必要的规范，增加了工作失误和重复工作；

10.7 某些人需要更多时间适应不熟悉的软件工具和环境；

10.8 某些人需要更多时间适应不熟悉的硬件工具和环境；

10.9 某些人需要更多时间适应不熟悉的编程语言；

10.10 项目结束前，合同制人员离开团队；

10.11 项目结束前，雇员辞职；

10.12 项目后期加入新的开发人员，额外的培训和沟通降低现有成员的效率；

10.13 项目组成员不能有效地一起工作；

10.14 由于项目组成员的冲突，导致沟通不畅，设计欠佳，接口错误和额外的重复工作； 10.15 有问题的成员没有调离项目组，损害了项目组其他成员的积极性；

10.16 项目组的最佳人员没有加入项目组；

10.17 项目组的最佳人员已经加入项目组，但是因为政治或其他原因没有合理使用； 10.18 关键人员只能兼职参与；

10.19 项目人员不足；

10.20 人员工作的进展比预期的慢；

10.21 任务的分配合人员技能不匹配；

10.22 项目管理人员的怠工导致计划和进度失控；

10.23 技术人员怠工导致工作遗漏或质量低下，工作需要重做；设计和实现：

11.1 设计过于简单，无法确定主要事件，并导致重新设计和实现；

11.2 设计过于复杂，导致一些不必要工作，并影响效率；

11.3 设计质量低下，导致重复设计和实现；

11.4 采用不熟悉的方法，导致额外的培训时间，并重犯以前的错误；

11.5 产品采用低级语言来实现，导致生产率比预期低；

11.6 一些必要的功能无法是用现有的代码和库实现，开发人员必需使用新的库或者自行开发所需要的功能；

11.7 代码和库质量低下，导致需要额外的测试，错误修正或重做；

11.8 过高估计增强型工具对项目进度的节省量；

11.9 分别开发的模块无法有效集成，需要重新设计或者重做；过程

12.1 大量纸面工作导致进展比预期慢；

12.2 进度跟踪不准确，导致无法预知项目是否已经落后计划进度；

12.3 前期的质量保证行为不真实，导致后期的重复工作；

12.4 质量跟踪不准确，导致无法得知影响进度的质量问题；

这是快速软件开发一书中的内容，我觉得比较全，就记录下来了，但是还不完全。也懒得写了。