发布: 2008-5-10 17:50 | 作者: 网络转载 | 来源: 网络转载 | 查看: 446次 | 进入软件测试论坛讨论
MSF 风险管理过程与整体项目生命周期紧密集成。风险评估可以在预想中开始,跟着项目团队和投资人开始设置约束。对于每个加入项目的约束和假定,额外的风险都可能形成。项目团队应该尽可能早的在项目中进行识别工作。在风险分析和计划阶段,所需的风险缓解和意外事故计划应该直接建入项目进度表和整体计划中。风险计划的进度应该由标准项目管理过程进行监控。
尽管风险管理过程通常由预定的初始风险识别和分析会议开始,但之后的风险计划、跟踪和控制阶段将对主导风险清单上的不同风险采取不同措施。在 MSF 风险管理原则中,持续风险管理假定:项目团队 “总是”同时地进行风险识别和跟踪阶段。他们将在触发事件、风险进度表和计划启动后参加风险控制工作。然而,在整个项目生命周期中,新的风险会不断出现,这就需要开始额外分析和计划会议。不需要用任何特定生命周期事件来同步风险管理阶段。一些项目团队将在主要事件发生时开始风险识别和分析,以方便项目状态的再评估。同时总结风险中的知识是非常方便的。
一般而言,风险识别和风险跟踪是长期持续的工作。项目团队成员应该坚持不懈地在项目中寻找风险,并处理它们,持续地跟踪特定风险计划的进度。对风险的分析、再分析以及对风险管理行动计划的更改工作可能是断断续续的,有时是提前计划(或许围绕着重大事件),还有时是不按时间表的项目事件导致(在跟踪和控制阶段发现的其他风险)的。学习大都发生在重大事件和项目的结束期。
随着阶段的变化,风险的种类也会改变。在项目早期,商业、范围、需求和风险相关的规划占主导地位。随着时间的进展,执行过程中的技术风险变得更加突出,接着又转化为操作风险。在项目生命周期的主要阶段,利用风险检查表或审查风险分类清单来指导风险识别工作是非常有用的。
为了实现风险管理工作回报的最大化,对于一个企业来说,保持风险管理的企业观点是非常重要的。
尽管很少有项目实施组织反对在项目中进行风险管理,但很多组织发现完全采用前摄风险管理过程相关的原则非常困难。它们常常在每个项目的开始进行风险评估,却不能在项目进行时维护过程。
这通常有两个原因:
• |
项目团队的时间压力。 |
• |
对风险的关注将破坏客户的信心,或留下反面印象。 |
这些信任的根本原因一般是管理人员本身并没有意识到在项目中实施风险管理的重要性。结果他们很难在项目预算中计划足够的风险管理时间(和其他风险管理活动)。在预算面临压力的时候,他们会首先抛弃风险管理工作。
因此,确保所有的投资人认识到风险管理重要性,从而建立有注意风险管理成长的文化,是非常重要的。在把风险管理作为一致原则建立过程中,下面的阶段非常有效:
• |
保护管理任务。 |
• |
向风险管理人员寻求建议,他能向你提供失败的个人经验和知识。 |
• |
引导投资人理解风险管理的重要性和失败带来的成本损失。 |
• |
培训核心风险管理人员,他们能为其他人提供角色模型和指导;一种有效的培训方法是组合风险管理理论和基于实际项目的真实体验。 |
• |
邀请所有项目投资人参加风险审查会议,并确保他们了解到状态报告。 |
• |
为有效识别和管理风险的风险团队成员引入识别机制。 |
• |
确保项目团队在项目调度中考虑风险,并做出关键决策。 |
• |
寻找投资人对风险管理过程效率的反馈,并有规律地对其进行审查,从而保证价值提升。 |
• |
为解决风险的团队成员提供酬劳。 |
项目实施组织可以通过引入一个过程来管理项目中公文包的风险而受益。通常有以下好处:
• |
依照他们面临的风险,资源可以通过公文包分配给项目。 |
• |
每个项目的风险管理人员都有一个外部增长点来提供团队评估的第二种意见。 |
• |
项目团队可以通过别处的经验来快速学习更多的知识。 |
• |
风险管理过程的质量保证在每个项目中实施。 |
应该注意:公文包风险审查补充了被每个项目团队实施的风险评估。审查团队没有识别风险所需的项目知识,也没有可用的时间来进行风险缓解工作。然而,它可以进行风险分析和计划工作。
因为审查团队通常包含更多经验丰富的管理人员,所有它的成员常常可以利用经验向面临重大风险的项目团队提出建议,帮助项目团队对风险分级。它们也可以向团队推荐他们曾经遇到过的、能够高效使用的缓解和意外事故策略。
下面是被应用到公文包风险管理的成功做法:
• |
为公文包审查过程保护执行支持。通过常规发现报告和知识对其进行维护。 |
• |
提前安排好会议;并最好使之成为多数项目领导预期会出席时的经常性的定期活动。提前向评估委员会发出邀请,优秀的评估员可能会有许多其它的安排。 |
• |
仔细选择待评估的项目。您可能希望每月都评估最大的项目,但是请确保内容广泛的中型项目也得到评估。 |
• |
为每个项目遵循标准议程,这样项目领导便了解会议的主旨。例如,一种做法允许用20分钟表达现有的风险评估,接着进行 20 分钟的缓解和意外事故策略讨论,再对和其他项目团队分享的知识内容进行 5 分钟的审查。 |
• |
使用标准文档记录项目状态报告和风险评估。 |
• |
保证所有的文档都被更新,并在会议前分发到所有参与者的手中;这让您可以减少会议的时间。 |
• |
鼓励项目团队领导参加审查,可以是个人的或电话的。 |
• |
确保项目团队从审查中获得价值。这常常可以通过审查非技术风险的进度实现, 而不是审查板成员的经验能帮助项目团队来实现。 |
• |
避免对项目局势的指责。 |
• |
允许任何项目成员请求他们项目的审查。 |
文章来源于领测软件测试网 https://www.ltesting.net/