为有效地控制项目的资源和进度，使项目按照计划、预算和质量标准实现预期目标，一般需对项目的整体规划、组织、控制、监测、验证、报告等过程进行系统管理。以下为常规的项目管理中对风险和问题的相关要求和方法。
一、项目风险管理
根据项目实际，识别项目建设过程中不可规避的各种风险，包括从范围、技术、需求满足度、进度、人力资源、沟通协调等多角度识别项目实施风险，衡量风险级别，并提出具体风险管控方案，详细描述项目实施过程中的风险及问题管理方法，提出有效对策，提出风险及问题管理计划、问题升级管理方法和工作流程，并建立跟踪定期报告制度。
项目风险管理主要针对项目实施涉及到的风险，包括在项目实施周期过程中可能出现的风险以及外部环境的变化可能引起的风险等进行评估。在本方案中对本项目可能遇到的风险进行分析，并提出了相应的风险回避措施。由于风险是在项目开始之后才开始对项目的开发起负面的影响，所以风险分析的不足，或是风险回避措施不得力，都很有可能造成项目开发的失败。风险分析是在事前的一种估计，凭借一定的技术手段和丰富的经验，基本能够对项目的风险做出比较准确的估计，经过慎重的考虑提出可行的风险回避措施，是避免损失的重要环节。具体如下：
1、风险分析：根据以往的项目经验，我们列举出本项目的风险类别，再采用概率分布法，列出具体风险事件在风险类别上的分布，针对风险概率评估标准，具体如下表所示：
表：风险事件及定级
类别 | 潜在风险事件 | 风险发生概率的定性等级 | 风险后果影响的定性等级 |
业务风险 | 客户方资源可用性 | 中 | 高 |
业务流程准确性 | 高 | 高 |
产品规模风险 | 功能点估计不精确 | 中 | 轻度 |
分析模型过于复杂 | 中 | 严重 |
需求风险 | 业务需求把握不准 | 高 | 轻度 |
与其他部门沟通不协调 | 高 | 轻度 |
分析员对业务了解不全面中 | 中 | 轻微 |
需求不断变化，由于不确定的需求导致新的市场 | 中 | 轻度 |
相关性风险 | 资源调动能力不足 | 中 | 轻度 |
项目经理管理经验不足 | 极高 | 严重 |
不可抗力造成的危害 | 低 | 灾难性的 |
高层管理人员对项目的时间要求不合理 | 极高 | 灾难性的 |
管理风险 | 项目规范定义不清楚 | 高 | 严重 |
进度拖延 | 极高 | 严重 |
沟通不善 | 中 | 轻度 |
技术风险 | 企业其他部门人员缺乏培训 | 中 | 轻度 |
数据安全问题 | 极高 | 灾难性 |
特殊功能不能及时交付 | 中 | 轻度 |
缺少测试计划 | 低 | 轻度 |
缺少质量跟踪 | 高 | 轻度 |
环境风险 | 网络环境达不到要求 | 中 | 严重 |
设备不能按时到位 | 低 | 严重 |
备份环境不稳定 | 中 | 严重 |
人员风险 | 人力资源有限 | 中 | 轻度 |
实施人员没有接受过正规培训 | 高 | 轻微 |
实施人员不能按时到位 | 中 | 轻度 |
实施人员经验不足 | 高 | 严重 |
2、风险应对措施
在风险未发生时针对风险分析结果列出风险应对措施，避免风险发生时的措手不及，风险应对报告如下表所示：
表：风险应对报告
| 风险意识 | 风险应对措施 |
项目 管理 过程 | 潜在风险事件 | 风险发生 后果 | 应急措施 | 预防措施 |
业务风险 | 客户方资源可用性 | 项目质量下降 | 要求额外资源 申请第三方资源 延长上线日期 |
资源整合 | 实施效率低下 | 为了避免延误或者项目周期内交付物整合不充分的风险，每个整合交付物必须在项目计划早期被详细说明。所有整合交付物的工作流必须被映射，并且必须仔细留意格式和迁移类型。必须使用一个标准化的通讯协议。 |
业务流程设计 | 业务流程错误 | 对政策和业务领域的重要变更流程不应该在项目周期内进行，如果发生应放入后期的项目完善。业务流程评审案例会包括（但不限于）：国家政策，风险政策，重要的结构变更。 |
产品 规模 风险 | 功能点估计不精确 | 工期延误 | 追加资源 | 加班加点 |
分析模型过于复杂 | 计算结果不准确 | 请顾问专家 | 简化模型 |
需求 风险 | 对在线活跃用户缺少确定的把握 | 系统崩溃 | 修改系统 | 采用大型服务器 |
与其他部门沟通不协调 | 软件不能满足业务需求 | 立即与部门进行沟通 | 指定沟通管理计划 |
分析员对业务了解不全面 | 系统不能满足业务需求 | 根据部门经理要求修改 | 让用户确认需求报告 |
需求不断变化，由于不确定的需求导致新的市场 | 项目变得没完没了 | 提交讨论，决定 | 建立范围变更程序 |
相关 性风 险 | 资源有限 | 项目不能按期完成 | 追加成本 | 减少资源消耗 |
项目经理管理经验不足 | 项目拖期，阻碍员工能力的发挥 | 培训或者换人 | 配备有经验的管理者 |
高层管理人员对项目的时间要求不合理 | 项目不能完成 | 及时沟通 | 平时加强沟通 |
管理 风险 | 项目规范定义不清楚 | 项目没完没了 | 按照用户要求变更 | 事先定义清楚并获得用户确认 |
进度拖延 | 项目拖期 | 加班加点 | 制定详尽工作计划 |
沟通不善 | 项目拖期 | 及时沟通 | 制定详尽沟通计划 |
技术 风险 | 企业其他部门人员缺乏培训 | 系统功能不能完全实现 | 一对一培训 | 制定培训计划 |
数据加密技术不够安全 | 被商业间谍盗取 | 备份 | 加强安全管理 |
特殊功能不能及时交付 | 不能满足用户需求 | 追加模块 | 沟通机制 |
缺少测试计划 | 项目拖期，质量问题发现不了 | 追加测试计划 | 事先评审测试计划 |
缺乏质量跟踪 | 质量问题 | 及时解决问题 | 制定质量跟踪计划 |
开发 环境 风险 | 网络环境达不到要求 | 产品不能部署 | 更新网络 | 提前调研和规划网络环境 |
设备不能按时到位 | 项目进度拖期 | 催设备供应商 | 提前采购或合同约束 |
设备固定折损严重 | 项目拖期 | 修改或换设备 | 加强设备预防性维修 |
系统崩溃 | 高管理要求承担损失 | 加紧修复 | 事先备份 |
备份环境不稳定 | 用户投诉 | 重新生成数据 | 做好备份 |
人员 数据 及经 验风 险 | 人力资源有限 | 项目拖期 | 添加人手 | 制定合理的时间管理计划 |
开发人员没有接受过正规培训 | 项目拖期 | 增加专人开发 | 提前培训 |
开发人员不能按时到位 | 项目拖期 | 增加专人开发 | 项目前约定到位时间 |
开发人员经验不足 | 项目拖期 | 增加专人开发 | 做好培训 |
3、风险分析报告
在项目实施过程中，双方项目人员发现风险或预计到有风险发生时，可通过风险分析报告描述风险、提出防范措施、跟踪风险，以及相互沟通，经过双方同意后，按防范措施实施，避免风险损失。风险分析报告如下表所示。
表：风险分析报告
风险名称 | | 风险识别人 | |
风险编号 | | 风险识别日期 | |
风险描述 | |
风险严重性 | | 风险系数 | |
风险可能性 | | 风险处理人 | |
风险减缓措施 | |
对方意见 | |
跟踪记录 | （1）记录何人在何时做了什么事情 （2）记录当前风险状态（正在处理，已经解决，不作处理） |
二、项目问题管理
1、问题及早报告原则：对于一个问题，问题发起人必须在问题发生的三日之内，向项目经理提交报告。问题没有及早报告，导致的项目影响，由延误报告人承担。
2、报告方式：如报告人认为口头报告即可，可以采用口头报告，但是如果口头报告没有使问题得以解决，则视同报告人没有作报告。
3、争议管理：在项目中，任何不能达成一致的观点均为争议，争议应立即向项目的上级机构呈报。
4、问题日志：项目经理与项目实施方咨询顾问之间将要保持一个联合的问题日志。