当前位置：文档之家 › 项目风险检查表

项目风险检查表

  • 格式：docx
  • 大小：10.63 KB
  • 文档页数：3

下载文档原格式

  / 3

合集下载

项目风险检查表

项目风险检查表
项目风险检查表
商业风险
风险源
检查项
法律
市场
政府或其他机构对本项目的开发是否有限制
是否有不可预测的市场动荡
竞争对手是否有不正当的竞争行为
是否有不利于我方的官司要打
是否在开发市场前景把握不定的产品
是否在开发可能亏本的产品
客户
客户的需求是否含糊不清
客户是否反复的改动需求
客户指定的需求和交付期限在客观上是否可行
需求开发人员是否与客户对有争议的需求达成共识
技术能力
本项目是否为新行业、新领域
本项目是否包含有新技术
本项目是否需要创建新的算法或输入、输出技术
本项目是否要求采用特定的用户界面
软件是否需要使用新的或未经证实的硬件接口
是否需要与开发商提供的未经证实软件产品接口
需求中是否要求使用新的分析、设计或测试方法
开发人员是否掌握了本项目的关键技术
客户对产品的健壮性可靠性、性能等质量因素是否有特殊要求
与客户签订的合同是否公正、是否双方互利
客户是否有良好的信誉
客户领导是否重视不足
客户是否合作难度大
客户基础是否太差
子承包商
供应商
签订产品
是否有能力做好售后服务
是否可能倒闭
是否有良好的信誉
管理风险
风险源
开发人员是否有开发类似产品的经验
是否选择了合适的分析、设计、编程和测试工具
开发环境
是否有可用的项目管理工具
是否有可用的软件过程管理工具
是否有可用的分析及设计工具，是否适用于待建造产品
是否有可用的编译器或代码生成器，且适用于待建造产品
是否有可用的测试工具，且适用于待建造产品
是否有可用的软件配置管理工具

风险识别检查表

风险识别检查表

进一步的调 研，以评估 潜在的风险 。 03士 气 b项目是否存在导致士气低下的因素（如裁员、离职、公司 亏损、行业不景气、政治混乱等）？ 10资源限制 a进度是否不够稳定？ b进度是否不切实际？ b.a如果否，那么估计方法是否没有基于历史数据？ 01进 度 b.b如果否，那么估计方法在过去是否运用的不好？ c是否还有没列入计划中的事情（如分析和研究、QA、培训 、运行和维护等） d是否有外部依赖有可能影响进度？ a是否缺乏在所需技术技能领域（如软件工程与需求分析方 法、算法专门技术、设计方法、程序语言、集成和测试方 法、可靠性、可维护性、配置管理、质量保证、目标环境 、安全水平、重用软件、操作系统、数据库、应用领域、 性能分析等方面）的相关人员？
02人 员 b项目成员数量是否不够？ c项目成员是否够稳定？
d在你需要的时候是否不能获得合适人选？ e项目是否依赖于几个关键人员？ f获得项目成员是否存在问题？ a预算是否不够稳定？ 03预 b预算是否基于不切实际的估计？ 算 b.a如果否，那么估计方法是否没有基于历史数据？ b.b如果否，那么估计方法在过去是否运用的不好？ 04设 a开发设备是否不够？ 备 b集成环境是否不够？ 11合同 01合 a数据（COTS软件、开发的软件、没有开发的项目等）的专 同约 利是否存在问题？ 束 02合 a关于外部产品或服务的一路是否影响产品、预算或进度？ 同依 （这些依赖如相关定约人、主要合同方、转包商、供应商 赖 、客户完成的设备或软件等）
如果对于这
01客 户 f管理者与客户一同决策（如需求理解、测试标准、进度调 整、接口变更等）是否没有以及时的方式进行？ g与客户达成一致的机制（如合同规定的工作组、技术交换 会议等）是否无效？ h涉及达成一致的问题时，客户是否内讧？ a外部接口变化时，是否没有适当的通知、协调或正式变更 流程？ 02相 b是否没有恰当的转变计划？ 关定 b.a如果否，那么是否有订约人不支持转变计划？ 约人 c从相关定约人那里获得进度或接口数据是否存在问题？ c.a如果否，那么他们是否不正确？ a给子商的任务定义是否有含糊不清的地方？ b子商的报告和跟踪监控过程是否与项目要求的汇报不同？ 03子 c对子商的管理是否没有一个独立的部门进行？ 商 d在某个领域你是否非常依赖子商的专家技术？ e公司所了解的子商是否经常变动？ f从子商那里获得的进度和接口数据是否存在问题？ 04供 a是否依赖于供应商提供的关键部件（如编译器、硬件、 应商 COTS等）？

项目确立时的风险及可行性检查表

项目确立时的风险及可行性检查表

称：顾客零部件号：风险评价：0=无风险1=小风险2=中风风险点数总计不超过5，且不存在小风险以上的风险时，可行性评审通过。

日期：编号:表号:合同类型：项目：厂内为料号：称：顾客零部件号：风险评价：0=无风险1=小风险2=中风风险点数总计不超过5，且不存在小风险以上的风险时，可行性评审通过。

日期：编号:表号:合同类型：项目：厂内为料号：称：顾客零部件号：风险评价：0=无风险1=小风险2=中风风险点数总计不超过5，且不存在小风险以上的风险时，可行性评审通过。

日期：编号:表号:合同类型：项目：厂内为料号：称：顾客零部件号：风险评价：0=无风险1=小风险2=中风风险点数总计不超过5，且不存在小风险以上的风险时，可行性评审通过。

日期：编号:表号:合同类型：项目：厂内为料号：称：顾客零部件号：风险评价：0=无风险1=小风险2=中风风险点数总计不超过5，且不存在小风险以上的风险时，可行性评审通过。

日期：编号:表号:合同类型：项目：厂内为料号：称：顾客零部件号：风险评价：0=无风险1=小风险2=中风风险点数总计不超过5，且不存在小风险以上的风险时，可行性评审通过。

日期：编号:表号:合同类型：项目：厂内为料号：称：顾客零部件号：风险评价：0=无风险1=小风险2=中风风险点数总计不超过5，且不存在小风险以上的风险时，可行性评审通过。

日期：编号:表号:合同类型：项目：厂内为料号：称：顾客零部件号：风险评价：0=无风险1=小风险2=中风风险点数总计不超过5，且不存在小风险以上的风险时，可行性评审通过。

日期：编号:表号:合同类型：项目：厂内为料号：D环境检查称：顾客零部件号：风险评价：0=无风险1=小风险2=中风风险点数总计不超过5，且不存在小风险以上的风险时，可行性评审通过。

日期：编号:表号:合同类型：项目：厂内为料号：称：顾客零部件号：风险评价：0=无风险1=小风险2=中风风险点数总计不超过5，且不存在小风险以上的风险时，可行性评审通过。

施工现场潜在危险排查表

施工现场潜在危险排查表

施工现场潜在危险排查表1. 项目信息
- 项目名称：
- 项目地点：
- 施工单位：
- 施工负责人：
- 监理单位：
- 监理负责人：
- 施工日期：
- 完工日期：
2. 潜在危险点排查
3. 风险等级定义
- 高风险：可能导致重大伤害或生命危险，需要立即采取紧急
措施。

- 中风险：可能导致一般伤害或健康影响，需要采取相应措施。

- 低风险：可能导致轻微伤害或影响，需要注意但风险较小。

4. 防控措施建议
- 高风险：立即采取措施，如隔离、警示标识、限制进入等。

- 中风险：采取必要措施，如佩戴个人防护装备、安全培训等。

- 低风险：加强注意，如保持整洁、定期维护等。

5. 补充说明
- 根据实际施工情况，对危险点进行详细描述。

- 提供必要的照片、示意图或图纸，以便更加清晰地展示危险点。

- 确保施工人员对危险点的风险等级和防控措施有清晰的理解。

以上是施工现场潜在危险排查表的基本内容，根据实际情况进行补充和修改，以确保施工过程中的安全性和风险控制。

项目交付前风险检查表(模板)

项目交付前风险检查表(模板)

*
销售说辞、口头承诺 与实际不符、或导致客户 有无升值、融资、投资回报的承
、对客户的个别承诺
误解
诺
*
商业有无可做餐饮承诺（煤气是
否能开通、有无烟道、隔油池，
*
是否有上下水）
销售时主要口径、说辞等与交付 后实际有无较大出入
*
销售时是否有承诺特殊优惠政策 （如减免物管费等）
*
合同中约定的交付及产权登记时 间是否与实际相符
议处理补充条款、付款补充协议
合同
条款及补充、房屋价格、税费、
代收税费约定、前期物业管理约
定条款、协议是否与现实或现场
有争议；
合同附图及交楼标准与实 际不符合
开放区、样板房以及现场实际是 否存在与合同附图、交楼标准等
不符合的情况
*
工地检查
设计变更未知会,导致现 是否存在现状与模型、平面图等
状与承诺不符合
洞
宣传的设备和材料是否与实际的
交付标准一致；是否提示有替代
*
的可能，提示语是否准确、醒目
涉及的交通、商业、文化教育设
施及其他市政条件等，在规划或
*
者建设中的有无注明
是否存在口头承诺与实际不符的
情况，如果已承诺，是否对此做 了补救措施；是否存在个别的、
*
少数的特殊承诺
有无为购房者办理户口、就业、 升学等事项的承诺
不符合情况，
*
附加条款
附加条款存在法律风险
附加条款是否经过评估，是否对 附加条款进行汇总备案
*
填写说明：
1.本表中所列销售承诺为项目建设
交付评估一览表（营销）全部
问题描述
涉及房号
整改措施 跟进责任部门（人）

房产项目交付风险检查表

房产项目交付风险检查表
交付风险评估一览表（文件约定的交付证明文件
合同要求 《房地产（住宅）质量保证书》
《房地产（住宅）使用说明书》
规划验收证明
主体工程验收证明
室内环境验收证明
供电、给排水达到使用条件的证明
消防验收证明
中间文件类 人防验收证明
电梯验收证明
燃气验收证明
档案验收证明
竣工面积测丈报告
…… 1.本表中所列文件为交付过程中必要的证明文件及各类交付必须的单项验收证明；
填写说明： 2.因各地合同、法规以及项目验收流程的差异，以上所列文件可能存在超出或不足的可能， 需根据当地情况，制作相应的交付应检查文件列表，并根据合同、法规、验收流程及时调整
险评估一览表（文件类）
备注 《竣工备案证》、《准许交付使用证》等
预计获得时间 实际获得时间
各地法规、验收流程要求的工程单项验收证明文件
程中必要的证明文件及各类交付必须的单项验收证明； 目验收流程的差异，以上所列文件可能存在超出或不足的可能，也可能随着时间发生调整。各地公司 的交付应检查文件列表，并根据合同、法规、验收流程及时调整。

项目危大风险检查表

4
导向件与导轨之间间隙小于5mm
4
架体构造（20分）
★架体高度应小于5倍层高，宽度应小于1.2m
3
技术负贵
★架体全高与支承跨度乘积应小于IIOm2
3
★直线架体支承跨度应小于7m；折线、曲线架体支承点直线距离应小于5.4m
5
★架体悬臂高度应小于2/5架体高度，且小于6m
3
★架体水平悬挑长度应小于2m且应小于跨度的1/2
3
管井设置数量应满足施工方案要求
3
基坑开挖（25分）
★①对采用预应力锚杆的支护结构，应在施加预加力后，方可开挖下层土方
★②对土何墙，应在士旬\喷射混凝土面层的养护时间大于2天后，方可开挖下层土方
★③对采用内支撑的支护结构，支撑结构达到设计要求的强度后，方可开挖下层土方
4
生产经理（技术负责）
★基坑分层、分段开挖应满足设计及施工方案要求
5
技术负责
合计总分
应得分：
实得分，
得分率I
技术负费
应得分：
实得分：
/
生产经理
应得分I
实得分，
/
备注
表中责任岗位为“生产经理（技术负责）”的条目：深基坑工程则由生产经理与技术负责共同负责，普通基坑工程由生产经理单独负责。
陪同人员：检查人：日期：
注:各小项根据完成情况分八个评价等级：A+:l.O.A:0.9、B+:0.8、B:0.7、C+:0.6、C：0.5、D:0・3、E:0；缺项采用加权处理。
6
主框架整体垂直度好，平面内、平面外变形小，导轨无扭曲，垂直度偏差小于5%o
4
附墙支座（25分）
★竖向主框架所覆盖的每个楼层应设置一道附墙支座；

项目 风险检查表及评估报告

项目所需的软件、硬件能按时到位吗？
项目的经费够用吗？
进度安排是否过于紧张？有合理的缓冲时间吗？
进度表中是否遗忘了一些重要的（必要的）任务？
进度安排是否考虑了关键路径？
是否可能出现某一项工作延误导致其它一连串的工作也被延误？
任务分配是否合理？（即把任务分配给合适的项目成员，充分发挥其才能）
是否为了节省钱，不采用（购买）成熟的软件模块，一切从零做起？
子承包商
供应商
与子承包商、供应商签订的合同公正吗？双方互利吗？
子承包商、供应商的信誉好吗？
子承包商、供应商有可能倒闭吗？
子承包商、供应商能及时交付质量合格的产品（或部件）吗？
子承包商、供应商有能力做好售后服务吗？
管理风险
风险类型
检查项
项目计划
对项目的规模、难度估计是否比较正确？
人力资源（开发人员、管理人员）够用吗？合格吗？
…
项目团队
项目成员团结吗？是否存在矛盾？
是否绝大部分的项目成员对工作认真负责？
绝大部分的项目成员有工作热情吗？
团队之中有“害群之马”吗？
技术开发队伍中有临时工吗？
本项目开发过程中是否会有核心人员辞职、调动？
是否能保证“人员流动基本不会影响工作的连续性”？
项目经理是否忙于行政事务而无暇顾及项目的开发工作？
机构是否有较好的奖励和惩罚措施？
本项目的合作部门的态度积极吗？是否应付了事？或者做事与承诺的不一致？
技术风险
风险类型
检查项
需求开发
需求管理
需求开发人员懂得如何获取用户需求吗？效率高吗？
需求开发人员懂得项目所涉及的具体业务吗？能否理解用户的需求？
需求文档能够正确地、完备地表达用户需求吗？

项目风险检查表完整版

风险可能性等级
参数
等级
值
描述
风险
可能性
很高
5
风险发生的几率为～
比较高
4
风险发生的几率为～
中等
3
风险发生的几率为～
比较低
2
风险发生的几率为～
很低
1
风险发生的几率为～
风险系数等级
风 险
系 数
风险可能性
很高5
比较高4
中等3
比较低2
很低1
风险
严重性
很高5
25
20
15
10
5
较高4
20
16
12
8
4
中等3
15
12
项目风险检查表
风险严重性等级
参数
等级
值
描述
风险
严重性
很高
5
例如进度延误大于30％，或者费用超支大于30％
比较高
4
例如进度延误20%－30％，或者费用超支20%－30％
中等
3
例如进度延误低于20％，或者费用超支低于20％
比较低
2
例如进度延误低于10％，或者费用超支低于10％
很低
1
例如进度延误低于5％，或者费用超支低于5％
需求文档能够正确地、完备地表达用户需求吗？
需求开发人员能否与客户对有争议的需求达成共识？
需求开发人员能否获得客户对需求文档的承诺？以保证客户不随便变更需求？
综合技术
开发能力
包括设计
编程、测试等
开发人员是否有开发相似产品的经验？
待开发的产品是否要与未曾证实的软硬件相连接？
对开发人员而言，本项目的技术难度高吗？

软件项目风险检查表模板

1）了解旧系统的功能，继承旧系统的优点，并提供用户需求但旧系统又无法满足的功能或质量；2）提供数据迁移功能。
严重
0
1.4
需要用户提供的资料、设备、工具不能及时提供
1）在项目计划中明确用户要提供的交付物及其交付时间，并与客户及时沟通；
严重
0
2）从其他项目借鉴相关资料等或者构建模拟的用户环境。
2
公司内部风险
1）加强QA和配置管理的力度；2）加强阶段交付物的评审。
一般
0
2.4
绝大多数项目组成员之间以前没有合作过
1）进行适当的管理培训和经验交流学习；2）组织相关的业余活动。
一般
0
2.5
可能选择了错误的技术方案或者供应商
1）应用正式的DAR决策过程，并参考以前的决策经验；2）选择一个备选方案；3）进行快速验证。
一般
0
2.6
组织内其他部门和项目组的不能提供积极的配合
制定合作制度，定期与部门进行沟通。
一般
0
2.7
项目是在已有的软件或产品的基础上进行相关应用开发，可能由于原有代码的质量问题或对原业务不了解，影响本项目的开发进度
适当的安排对原有模块学习时间。
一般
0
2.8
项目组成员由于还参与了别的项目的工作，无法保证参与本项目的时间，影响本项目的开发进度
1）通过客户向合作厂家发出邀请或索要资料；2）寻找替代选择方案。
一般
0
软件
编号
风险检查项
建议应对措施
影响程度
出现次数
1
客户相关风险
1.1
项目需求不是客户或用户直接提出的
寻找合适的客户、用户或业务专家在适当的时机进行确认
严重
  1. 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
4
20
16
12
8
4
中等
3
15
12
9
6
3
比较低
2
10
8
6
4
2
很低
1
5
4
3
2
1
本表灰色部分的风险系数为
10〜25，应当优先处理
风险检查表
商业风险
风险类型
检查项
政治
法律
市场
政府或者其它机构对本项目的开发有限制吗？
有不可预测的市场动荡吗？
有不利于我方的官司要打吗？
本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗？
是否对所有重要的工作成果进行了同行评审（正式评审或快速检查）？
开发人员懂得版本控制、变更控制吗？能够按照配置管理规范执行吗？
开发人员重视质量吗？是否会在进度延误时降低质量要求？
开发人员是否已经掌握了本项目的关键技术？
如果某项技术尚未实践过，开发人员能否在预定时间内掌握？
开发小组是否采用比较有效的分析、设计、编程、测试工具？
分析与设计工作是否过于简单、草率，从而让程序员边做边改？
开发小组采用统一的编程规范吗？
开发人员对测试工作重视吗？能保证测试的客观性吗？
项目有独立的测试人员吗？懂得如何进行高效率地测试吗？
竞争对手有不正当的竞争行为吗？
本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗？
是否在开发很少有人真正需要却自以为很好的产品？
是否在开发可能亏本的产品？
客户
客户的需求是否含糊不清？
客户是否反反复复地改动需求？
客户指定的需求和交付期限在客观上可行吗？
客户对产品的健壮性、可靠性、性能等质量因素有非常过分的要求吗？
需求文档能够正确地、完备地表达用户需求吗？
需求开发人员能否与客户对有争议的需求达成共识？
需求开发人员能否获得客户对需求文档的承诺？以保证客户不随便变更需求？
综合技术
开发能力
包括设计 编程、测试等
开发人员是否有开发相似产品的经验？
待开发的产品是否要与未曾证实的软硬件相连接？
对开发人员而言，本项目的技术难度高吗？
是否能保证“人员流动基本不会影响工作的连续性”？
项目经理是否忙于行政事务而无暇顾及项目的开发工作？
上级领导
行政部门
合作部门
本项目是否得到上级领导的重视？
上级领导是否随时会抽调本项目的资源用于其它“高优先级”的项目？
上级领导是否过多地介入本项目的事务并且瞎指挥？
行政部门的办事效率是否比较底，以至于拖项目的后腿？
管理风险
风险类型
检查项
项目计划
对项目的规模、难度估计是否比较正确？
人力资源（开发人员、管理人员）够用吗？合格吗？
项目所需的软件、硬件能按时到位吗？
项目的经费够用吗？
进度安排是否过于紧张？有合理的缓冲时间吗？
进度表中是否遗忘了一些重要的（必要的）任务？
进度安排是否考虑了关键路径？
是否可能岀现某一项工作延误导致其它一连串的工作也被延误？
客户的合作态度友善吗？
与客户签的合同公正吗？双方互利吗？
客户的信誉好吗？例如按客户的需求开发了产品，但是客户可能不购买。
子承包商
供应商
与子承包商、供应商签订的合同公正吗？双方互利吗？
子承包商、供应商的信誉好吗？
子承包商、供应商有可能倒闭吗？
子承包商、供应商能及时交付质量合格的产品（或部件）吗？
子承包商、供应商有能力做好售后服务吗？
行政部门是否经常干一些无益于生产力的事情，以至于骚扰本项目？
机构是否能全面、公正地考核员工的工作业绩？
机构是否有较好的奖励和惩罚措施？
本项目的合作部门的态度积极吗？是否应付了事？或者做事与承诺的不一致？
技术风险
风险类型
Байду номын сангаас检查项
需求开发
需求开发人员懂得如何获取用户需求吗？效率高吗？
需求管理
需求开发人员懂得项目所涉及的具体业务吗？能否理解用户的需求？
任务分配是否合理？（即把任务分配给合适的项目成员，充分发挥其才能）
是否为了节省钱，不采用（购买）成熟的软件模块，一切从零做起？
项目团队
项目成员团结吗？是否存在矛盾？
是否绝大部分的项目成员对工作认真负责？
绝大部分的项目成员有工作热情吗？
团队之中有“害群之马”吗？
技术开发队伍中有临时工吗？
本项目开发过程中是否会有核心人员辞职、调动？
风险严重性等级
参数
等级
值
描述
风险
很高
5
例如进度延误大于
30 %，或者费用超支大于
30 %
严重性
比较高
4
例如进度延误20%— 30 %，或者费用超支
20%— 30 %
中等
3
例如进度延误低于
20 %，或者费用超支低于
20 %
比较低
2
例如进度延误低于
10 %，或者费用超支低于
10 %
很低
1
例如进度延误低于
5%，或者费用超支低于
5 %
风险可能性等级
参数
等级
值
描述
风险
可能性
很高
5
风险发生的几率为〜
比较高
4
风险发生的几率为〜
中等
3
风险发生的几率为〜
比较低
2
风险发生的几率为〜
很低
1
风险发生的几率为〜
风险系数等级
风
系
险
数
风险可能性
很高 5
比较高 4
中等
3
比较低 2
很低 1
风险
很咼
5
25
20
15
10
5
严重性
较高