项目风险检查表完整版
项目风险检查
是否有单设的水电表（1分）
人员管理
（16分）
项目部人员是否有明确权限分工（2分）
项目部人员名单、职责、权限是否有建设单位确认（2分）
总包项目管理人员更换是否有建设单位同意资料（1分）
是否存在对非本单位人员授权现象（3分）
是否存在分包代表总包参加项目例会或以总包名义对外沟通情况（3分）
检查内容表
所属单位：
项目名称：
检查时间：
类别
内容
检查情况
整改建议
合同管理（15分）
总包合同是否签署、是否经过招投标（3分）
是否放弃工程优先权，如放弃是否有审批手续（2分）
是否进行了合同交底，有无记录（2分）
分包单位是否为适格主体、是否具有相应资质及按政府管理部门要求的其他证照（3分）
办理工程签证（2分）
向建设单位报送资料是否由我方人员办理，是否有对方签收（2分）
实际利润与目标利润简要分析（2分）
材料管理
（8分）
甲供材是否由总包单位人员领用（2分）
拨付分包材料是否有完备调拨单（2分）
自购材料是否有批价，批价是否合格（2分）
退料是否由总包人员进行，流程是否符合要求（2分）
分包现场管理人员是否有书面确认，是否有签字样本（2分）
分包管理人员变更是否有变更通知及新进人员签字样本（1分）
劳务人员的考勤、进、出场是否完备（2分）
资料管理
（12分）
例会资料、工程签证及来往函件是否有原件、签字是否完善（2分）
设计变更签证是否有设计单位批准手续（1分）
是否存在将分包盖章或签字的经济资料直接加盖我方印章报送建设单位情况（3分）
其他需要注意的风险情况
项目风险评估排查表
工程质量管理可能存在的风险
9
工程环境管理可能存在的风险
10
工程分包管理可能存在的风险Biblioteka 11工程进度管理可能存在的风险
12
合同管理可能存在的风险
13
成本管理可能存在的风险
14
资源（人力、材料、设备等）管理可能存在的风险
……
（基层单位根据实际情况添加）
附件：×××风险评估排查表
序号
排查内容
排查结果
是否重要风险因素
管理制度/流程/措施
责任人
部门
控制有效性评价
存在的问题
相关建议
备注
1
项目审批是否合规
2
合同订立是否有效
3
专项资金是否落实
4
征地拆迁合法性及补偿是否足额到位
5
项目所在地治安环境的风险影响
6
农民工资专项资金账户设立、发放情况
7
工程安全管理可能存在的风险
项目安全风险评估表
项目安全风险评估表1. 项目范围安全风险：- 未明确定义项目的范围和目标，导致项目组无法全面了解项目要求和期望，可能影响项目的安全性。
- 项目变更管理不完善，导致项目范围的不断扩大和变化，可能引入新的安全风险。
2. 项目人员安全风险：- 项目组成员缺乏安全意识和知识，可能不充分考虑项目的安全要求。
- 项目组成员不适当地处理和保护项目的安全信息和资产，导致泄露或损失。
3. 项目资源安全风险：- 项目使用的技术和工具存在安全漏洞，可能被攻击者利用进行非法入侵。
- 项目所需的硬件和软件资源未得到充分保护，可能受到病毒、恶意软件等威胁。
4. 项目沟通安全风险：- 项目组成员之间的沟通不畅，可能导致信息的不完整或误传，影响项目决策和安全性。
- 项目组成员使用不安全的通信渠道或设备进行沟通，可能被监听或攻击。
5. 项目合作伙伴安全风险：- 项目合作伙伴的安全措施不足，可能引入安全风险到项目中。
- 项目合作伙伴的员工缺乏安全意识和知识，可能泄露项目的安全信息。
6. 项目外部环境安全风险：- 政策法规和监管要求的变化，可能导致项目的安全要求发生变化。
- 自然灾害、社会安全事件等外部因素的发生，可能对项目安全造成影响。
7. 项目数据安全风险：- 项目的敏感数据未得到妥善的保护和加密，可能被盗取或篡改。
- 项目的备份和恢复机制不完善，可能导致数据丢失或不可恢复。
8. 项目安全管理风险：- 项目缺乏有效的安全管理计划和流程，可能导致安全事故发生或无法及时处理。
- 项目团队对安全事故的应急响应不合理或不充分，可能导致事态扩大或后果严重化。
注：以上只是项目安全风险评估表的一些例子，实际项目安全风险需要根据具体项目的特点进行具体评估。
项目危大风险检查表
导向件与导轨之间间隙小于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分）
★竖向主框架所覆盖的每个楼层应设置一道附墙支座；
项目 风险检查表及评估报告
项目的经费够用吗？
进度安排是否过于紧张？有合理的缓冲时间吗？
进度表中是否遗忘了一些重要的（必要的）任务？
进度安排是否考虑了关键路径？
是否可能出现某一项工作延误导致其它一连串的工作也被延误？
任务分配是否合理？（即把任务分配给合适的项目成员，充分发挥其才能）
是否为了节省钱，不采用（购买）成熟的软件模块，一切从零做起？
子承包商
供应商
与子承包商、供应商签订的合同公正吗？双方互利吗？
子承包商、供应商的信誉好吗？
子承包商、供应商有可能倒闭吗？
子承包商、供应商能及时交付质量合格的产品（或部件）吗？
子承包商、供应商有能力做好售后服务吗？
管理风险
风险类型
检查项
项目计划
对项目的规模、难度估计是否比较正确？
人力资源（开发人员、管理人员）够用吗？合格吗？
…
项目团队
项目成员团结吗？是否存在矛盾？
是否绝大部分的项目成员对工作认真负责？
绝大部分的项目成员有工作热情吗？
团队之中有“害群之马”吗？
技术开发队伍中有临时工吗？
本项目开发过程中是否会有核心人员辞职、调动？
是否能保证“人员流动基本不会影响工作的连续性”？
项目经理是否忙于行政事务而无暇顾及项目的开发工作？
机构是否有较好的奖励和惩罚措施？
本项目的合作部门的态度积极吗？是否应付了事？或者做事与承诺的不一致？
技术风险
风险类型
检查项
需求开发
需求管理
需求开发人员懂得如何获取用户需求吗？效率高吗？
需求开发人员懂得项目所涉及的具体业务吗？能否理解用户的需求？
需求文档能够正确地、完备地表达用户需求吗？
软件项目风险检查表模板
严重
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. 引言本文档旨在识别和评估当前项目的各类风险，以便及时采取相应的措施进行预防和应对，确保项目的顺利实施和成功完成。
2. 风险识别在项目实施过程中，可能面临以下风险：2.1 技术风险- 技术选型不合理导致实施难度增加- 技术人员能力不足影响项目进展- 系统可靠性和稳定性问题2.2 资源风险- 项目所需资源供应不足- 预算不足导致项目进展受限- 项目所需人力资源的流失和不稳定性2.3 时间风险- 进度延误导致项目交付延迟- 项目开发周期过长导致后续环节受影响- 项目中的关键节点无法按时完成2.4 运营风险- 用户需求变化导致产品功能不匹配- 竞争对手的产品在市场上占有优势- 相关政策法规的变化对项目实施产生影响3. 风险评估为了评估风险的严重程度和影响程度，将采用以下等级进行评估：- 高风险：可能导致项目无法顺利完成，且对组织产生重大影响- 中风险：可能导致项目进展受限，且对组织产生一定影响- 低风险：对项目进展和组织影响较小，但仍需要关注4. 风险应对措施针对各类风险，制定相应的应对措施将有助于降低风险发生的概率和严重程度。
具体的应对措施如下：- 技术风险：加强技术人员培训和沟通交流，对技术选型进行评估和优化。
- 资源风险：及时预测和计划所需资源，合理控制成本并保障人力资源的稳定性。
- 时间风险：合理制定项目进度计划，加强项目管理和团队协作。
- 运营风险：不断关注市场变化和竞争动态，持续优化产品功能和服务。
5. 总结项目风险表(新版)旨在为项目开展提供风险识别和应对的参考，通过合理评估和有效控制风险，有助于保证项目的顺利进行和成功完成。
对于项目组的相关人员来说，需要认真对待风险，并积极采取措施以应对和化解潜在的风险。
项目风险管理工作检查表
项目风险管理工作检查表一、项目背景和目标项目名称：_____________________项目背景：_____________________项目目标：_____________________二、风险识别风险识别方法：_____________________风险识别结果：_____________________三、风险评估风险评估方法：_____________________风险评估结果：_____________________四、风险响应风险响应方法：_____________________风险响应措施：_____________________五、风险监控风险监控方法：_____________________风险监控结果：_____________________六、风险报告风险报告对象：_____________________风险报告频率：_____________________七、风险管理文件风险管理文件包括：_____________________八、风险沟通与培训风险沟通方式：_____________________风险培训方式：_____________________九、风险管理工作评估风险管理工作评估方法：_____________________ 风险管理工作评估结果：_____________________十、改进措施改进措施：_____________________十一、评估完成情况评估完成日期：_____________________评估完成人：_____________________以上为项目风险管理工作检查表，用于指导和记录项目中的风险管理工作，确保项目进展顺利并最大程度降低风险的影响。
请按照实际情况填写和执行，及时跟进并改进风险管理工作。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
参数
等级
值
描述
风险
可能性
很高
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％
需求文档能够正确地、完备地表达用户需求吗？
需求开发人员能否与客户对有争议的需求达成共识？
需求开发人员能否获得客户对需求文档的承诺？以保证客户不随便变更需求？
综合技术
开发能力
包括设计
编程、测试等
开发人员是否有开发相似产品的经验？
待开发的产品是否要与未曾证实的软硬件相连接？
对开发人员而言，本项目的技术难度高吗？
是否能保证“人员流动基本不会影响工作的连续性”？
项目经理是否忙于行政事务而无暇顾及项目的开发工作？
上级领导
行政部门
合作部门
本项目是否得到上级领导的重视？
上级领导是否随时会抽调本项目的资源用于其它“高优先级”的项目？
上级领导是否过多地介入本项目的事务并且瞎指挥？
行政部门的办事效率是否比较底，以至于拖项目的后腿？
9
6
3
比较低2
10
8
6
4
2
很低1
5
4
3
2
1
本查表
商业风险
风险类型
检查项
政治
法律
市场
政府或者其它机构对本项目的开发有限制吗？
有不可预测的市场动荡吗？
有不利于我方的官司要打吗？
本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗？
竞争对手有不正当的竞争行为吗？
本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗？
是否在开发很少有人真正需要却自以为很好的产品？
是否在开发可能亏本的产品？
客户
客户的需求是否含糊不清？
客户是否反反复复地改动需求？
客户指定的需求和交付期限在客观上可行吗？
客户对产品的健壮性、可靠性、性能等质量因素有非常过分的要求吗？
客户的合作态度友善吗？
与客户签的合同公正吗？双方互利吗？
客户的信誉好吗？例如按客户的需求开发了产品，但是客户可能不购买。
子承包商
供应商
与子承包商、供应商签订的合同公正吗？双方互利吗？
子承包商、供应商的信誉好吗？
子承包商、供应商有可能倒闭吗？
子承包商、供应商能及时交付质量合格的产品（或部件）吗？
子承包商、供应商有能力做好售后服务吗？
管理风险
风险类型
检查项
项目计划
对项目的规模、难度估计是否比较正确？
人力资源（开发人员、管理人员）够用吗？合格吗？
项目所需的软件、硬件能按时到位吗？
项目的经费够用吗？
进度安排是否过于紧张？有合理的缓冲时间吗？
进度表中是否遗忘了一些重要的（必要的）任务？
进度安排是否考虑了关键路径？
是否可能出现某一项工作延误导致其它一连串的工作也被延误？
行政部门是否经常干一些无益于生产力的事情，以至于骚扰本项目？
机构是否能全面、公正地考核员工的工作业绩？
机构是否有较好的奖励和惩罚措施？
本项目的合作部门的态度积极吗？是否应付了事？或者做事与承诺的不一致？
技术风险
风险类型
检查项
需求开发
需求管理
需求开发人员懂得如何获取用户需求吗？效率高吗？
需求开发人员懂得项目所涉及的具体业务吗？能否理解用户的需求？
开发人员是否已经掌握了本项目的关键技术？
如果某项技术尚未实践过，开发人员能否在预定时间内掌握？
开发小组是否采用比较有效的分析、设计、编程、测试工具？
分析与设计工作是否过于简单、草率，从而让程序员边做边改？
开发小组采用统一的编程规范吗？
开发人员对测试工作重视吗？能保证测试的客观性吗？
项目有独立的测试人员吗？懂得如何进行高效率地测试吗？
任务分配是否合理？（即把任务分配给合适的项目成员，充分发挥其才能）
是否为了节省钱，不采用（购买）成熟的软件模块，一切从零做起？
…
项目团队
项目成员团结吗？是否存在矛盾？
是否绝大部分的项目成员对工作认真负责？
绝大部分的项目成员有工作热情吗？
团队之中有“害群之马”吗？
技术开发队伍中有临时工吗？
本项目开发过程中是否会有核心人员辞职、调动？
是否对所有重要的工作成果进行了同行评审（正式评审或快速检查）？
开发人员懂得版本控制、变更控制吗？能够按照配置管理规范执行吗？
开发人员重视质量吗？是否会在进度延误时降低质量要求？