信息项目风险管理措施.docx

信息项目风险管理措施
管理项目可能存在的风险，在进行项目计划时需要进行风险分析并制订风险管理计划，该计划作为项目计划的一部分进行描述。风险管理应贯穿于项目工程的始终。风险管理不是项目经理一人的任务，也不是一次性的任务。它是一个迭代的过程，各项目成员都有责任进行风险管理。建立一种有助于对潜在的风险及其发生的可能性和影响进行交流的环境对项目经理来说是相当重要的。
风险管理是项目管理者最重要的工作之一。风险管理是一个持续的过程,贯穿于整个项目过程中，风险管理包括风险识别、风险评估、风险解决以及风险管理策略。
在项目的实施过程中需要不断地识别和应对风险，并加以有效的控制，风险管理的好与坏直接影响项目的实施效果，从某种意义上讲，项目实施对于项目管理者就是识别、分析、应对、控制风险的过程，使项目的约束性目标和质量目标朝有利的方向发展。
项目不同于日常任务，它有明确的起止时间和目标，要在明确的范围、时间和成本约束下,达到相应的质量标准，并取得用户的满意。影响项目成败的因素涉及方方面面，并且风险伴随着项目的始终，是客观存在的，作为一个项目管理者，应该具备良好的风险控制意识，善于识别风险并分析风险的影响，从中发现影响目标的风险点，并施加影响或采取应对措施,把风险的负面影响降到最低，并且风险控制应该贯穿项目始终。
风险引起的负面后果集中体现在进度延后、成本超支、质量不达标等方面，导致这些问题的因素主要包括目标以及需求不明确、范围蔓延以及需求变更、代码质量或返工风险、人员技能和资源的不足、缺乏良好的团队协作等。
在制定风险管理计划时，主要包括如下活动：
1、在项目规划时，通常要对项目进行风险分析。风险分析通常是由项目经理和项目组成员参照《组织风险选择列表》以及曾经开发过的项目所积累的经验来进行。
2、项目经理《组织风险选择列表》以及曾经开发过的项目所积累的经验识别风险，并将识别出的风险记录到《风险管理》之项目风险计划中。
3、项目经理将每类风险的可能性和影响程度记录到《风险管理》之项目风险计划中。
4、计算风险值和风险等级。对每个风险计算风险值，风险值=可能值*影响值。然后对每个风险确定其等级。
5、确定风险优先级。由于每个项目的资源都是有限的，所以风险管理（处理、减缓、监视和控制）必须把精力集中在这种最重要的风险子集上。
6、对风险分类。可以把风险进行分类，即相关的风险分组到一起：这些风险可能需要相似的风险处理或者可能会在同一领域发生反面影响。这种分组有助于理解风险的本质，并且会导致更为有效的风险处理和减缓计划。
7、确定风险的复评估间隔，对于1级风险在项目周例会上要定期进行跟踪并报告执行情况；对于2级风险则在里程碑会议上对风险进行报告。
8、项目经理将风险等级、排出的风险优先级以及对每个风险的分类，记录到《风险管理》的项目风险计划表中。
下面将详细描述一下这些问题以及出现这些问题时的应对方案：
1、目标以及需求不明确
为了市场竞争或内部管理决策的需要，业务部门提出的需求往往要求的时间比较紧迫，需求的提出大多停留在几张纸或头的传达上,没有形成正式的业务需求文档，在没有明确的需求范围的情况下，有时为了迎合业务部门的味匆匆开工，过程中用户不断地提出新的想法，技术人员开始疲于奔命和应付，很难保证项目的进度和质量，也难以取得业务部门的认可。所以，在项目的前期一定要采取相应的手段或措施，与业务部门共同明确项目目标、需求范围，充分考虑现有的时间和资源约束，将需求排定优先级，
对于关键的需求优先实现，其他辅助性的根据过程中的具体情况进行滚动式计划，并取得业务部门的书面确认。在此过程中要注重挖掘用户的隐性需求，可以通过引导、系统原型等手段让用户在前期充分暴露自己的想法和需求。
2、范围蔓延以及需求变更
在有了明确的目标和需求范围的情况下，需求的变更还是不可避免的，业务部门在看到具体系统的真实雏形之后，源源不断地要求、新想法随之产生，如果不对此加以控制，新的需求的加入通常会影响已实现的需求，并且对项目进度和成本产生很大的影响。项目管理者针对这种情况一定要采取严格的变更控制流程，不能碍于面子，否则最终的结果往往是出力不讨好。针对用户提出的新需求，按照正式流程提出变更申请，组织相关团队成员进行分析及评估，作为是否实施的依据，变更控制负责人根据分析结果判断是否批准，如果批准，那项目组可以安排实施，否则，正式拒绝用户的请求，当然实际情况下可以采取一些软措施缓解矛盾。需求变更风险：需求已经打上了基线，但此后仍然有变更发生，对项目造成影响。如何减少此类风险的发生？前期的需求讨论要详细、充分。需求文档中需求的范围要明确、功能描述要清楚。找出项目中需求的决策者（通常会是产品经理、相关职能主管、客户，所有的需求要经过他们的认可。客户在项目过程中的全程参与有助于降低此类风险。需求讨论、需求确认、User Case确认、测试阶段的客户验收等环节，都要要求客户参与。在发生需求变更时，严格按照需求变更流程执行。在分析设计阶段的中的确认和评审也是降低此类风险的重要手段。
3、代码质量或返工风险
质量风险主要指开发代码的质量。如何提高开发人员开发的质量？在制定项目计划时，对开发时间的评估要尽可能的合适。合理的开发时间对开发质量的影响也很大。有时开发人员为了赶进度在比较紧张的时间需要完成指定的任务，可能就存在很大的开发质量问题。开发要有一套严格可行的代码规范，编码时严格遵守，到现在为止，我们这个方面做的不是很规范，做的也很不足，大家编写的代码随意性比较大，代码编写者的主观意识性比较强。要建立一套大家认可并且规范可行的编码规范和考核规范，code review时严格考核。在编码前，开发人员要对框架熟练掌握；一份好的系统设计文档对指导开发非常重要。返工是项目组最不愿意看到的，既浪费人力、物力和财力，又影响团队积极性。需求不明确或范围没有有效控制都可能造成返工，另外造成返工的原因是质量没有达到用户要求。往往有这样一种情况，每个团队成员按照项目计划报告进度都是1%完成，但一到最后系统交互测试或集成的时候就会发现一大堆问题，不得不花费很大精力回头排查、修改程序，造成这种情况的主要原因是过程中质量保证没有做到位，把大部分问题留在了后面。这就需要在项目实施过程中采取有效的措施来规避返工的风险，通常的做法有同行评审，比如概要设计完成之后，邀请其他项目组的技术专家进行技术评审以发现架构设计问题；管理评审，通过组织级的质量审计看产品以及实施过程是否满足质 量要求；代码走查，在编码过程中加入至少一次的代码走查，排查不符合规范或性能要求的代码，走查通常能够发现50%-70%的错误；每日构建，这是一种非常有效的方法，可以避免把各部分的集成问题拖到最后，并且能够及时发现相应的错误，日构建一般在项目的中后期开始，每天自动从版本服务器上获取源代码进行自动编译和测试。
4、人员技能和资源的不足
项目实施过程中由于人员技能欠缺造成的进度延后和软件质量问题并不少见，一个熟练的技术人员完成同样一个任务需要3天，但一个生手可能就需要7-10天。项目管
理者应该在前期就分析清楚项目所要采用的技术以及相应的人员技能要求，针对不同的角色，及时采取相应的技能培训，以保证项目的顺利实施。如果对于项目中某些部分专业性特别强或新技术，短期内又不能快速建立技能的情况，可以考虑将该块任务外包，借鉴合作商的力量降低实施风险，当然要进行外购人力成本与自建人力成本的效益分析。开发过程中遇到技术难题，导致开发时间延迟或者需求不得不发生变更。如何减少 此类风险的发生？在项目开始前的技术评估阶段，明确技术难点，提前安排人员进行攻克。如果在可预期的时间内无法解决，如果可以，将向需求提出方要求变更需求或寻找可替代方案。这样的风险应该在项目的前期阶段就应该解决在萌芽状态来避免这样的风 险在后期或中期出现。项目所需人力资源无法按时到位，导致资源风险。如何减少此类风险的发生？这个 就需要在项目计划制定的时候提前申请确认资源，并在项目过程中不断沟通协调。
5、缺乏良好的团队协作
软件项目实施属于知识型，要发挥团队成员的创造力，不同于制造业计件生产，各模块最终要集成在一起形成一个有机的整体，这就需要各小组之间的密切配合，界定清楚工作界面及接关系，并在实施过程中持续地沟通交流和共享，首先团队要融为一体，产出的软件才能融为一体。这是一个团队的软实力，团队之间的协作好坏也将是个潜在的风险问题，在项目启动和团队组建的时候就应该加以规避这样的风险出现。
项目风险管理的要点：
1、上述我们所说的风险管理都是指可以预期将要发生的风险，那些不可预期将要发生的风险不属于风险管理的范畴。这也将是考验一个项目管理者的经验和知识对能否管理好风险至关重要的内容。
2、对不可预期的风险，项目管理者要有潜在的风险意识评估，做好一些可操作性的预案准备。
3、详细明确的项目计划、以及项目执行过程中每个要点的质量保证是降低项目风险的必要条件。
4、风险报告是项目团队以及领导了解项目风险的一个有效手段。风险报告的格式：序号风险简介对项目的影响解决方案或对策。
5、团队管理
团队就是一组个体为实现共同的目标而相互依赖、一起工作的共同体。团队工作顾名思义就是团队成员为实现这个共同的目标而付出的共同努力，项目团队的工作是否有效直接关系到项目的成败。团队管理是个渐进的过程。世界上只有完美的团队，没有完美的个人。好的高效的团队不是管理出来的，而是营造出来的。团队成员需要有大家可认同的团队文化，这需要大家共同的努力。
a）营造良好的工作环境和氛围。
b）建设优秀或鲜明的团队文化。
c）保持高效的沟通。
6、项目会议
组织会议是项目管理者日常工作中一项非常重要的工作任务，项目过程中很多重要的决 定都是在会议中做出的，也有很多由于不成功的会议而对项目本身造成了不好的影响。
首先看看不成功的会议常常表现为哪些形式：
1）会议氛围不好，参与者发言不踊跃；
2）会议讨论常常偏离主题；
3）会议没有取得预期的结果；
4）会议时间常常一拖再拖。这些不成功的会议最终的结果就是：既浪费了大家的宝贵时间又没有达到会议的目的，很多人都对这样的会议都有抵触情绪，
对此也是深恶痛绝。
以下是组织会议时应该注意的问题，也可看作组织会议的最佳实践。在列出最佳实践之前有三点我们必须要清楚：
1）会议是否会取得成功很大程度上取决于会议的组织者。只有组织得有力，会议才有可能取得成功，这是会议成功的充分条件。
2）会议的组织者和参与者的想法通常是不一致的，有时候甚至会大相径庭。所以不要希望会议的参与者和你一样，对会议有着如此的期待，对大多数参与者而言，在会议中他只是一个发表想法的人，他不用对会议的成功承担责任。
3）以下十一条最佳实践是形式上的约定，具体的实施可以根据实际情况来做。
组织会议的十一条最佳实践：
1）只有需要开会时才开会。有时候两三个人单独小范围沟通会更加有效。
2）提前发出会议议程，以便会议参与者知道他们来做什么。
3）请对人很重要，不要把非必要的人召来开会，当然也不要漏掉那些关键人物。在确保必要人物都在的情况下一次会议参与者越少效果越好。
4）提前预约参与者的时间，以确保他们能按时到场。
5）会议的开场很重要。会议组织者要在开始前做好几件事情。通常我建议有几点要在开场时说：
A. 再一次强调会议的目标，我们来做什么。
B. 强调会议的主题与基调。比如：本次会议是一个需求确认会，而非需求讨论会，主要是讨论做还是不做以及告知大家我们要做什么，而不要把太多的精力放在讨论如何做上面。
C. 说明一下会议的规则。如要发言，请举手；不要有小圈子讨论；不要打断别人的讲话，等别人说完你再说等等。
6）会议过程中时刻注意引导和控制会议，以确保会议按照目标进行。一次会议的氛围是否良好，讨论是否充分，好的引导至关重要。比如多提一些开放式的问题。
7）会议记录很重要，把一些结论和有价值的内容记录下来，这些是本次会议的重要成果之一。
8）会议要有结论。我们常在会议上听到有人说：”大家讨论了这么半天，结
论呢？”。没有结论的会议是没有意义的。
9）会议后别忘发会议纪要，以及一些Action，什么人什么时候做什么。
10）会议后的action执行情况的反馈很重要。反馈是对会议参与者的尊重，同时也告知了会议的效果。否则会让大家感觉到这是一个可无可无的会议，大家以后参与的积极性也会降低。很多会议往往都不注意这一点。
11）按时结束的会议会受到所有人的欢迎。
7、版本控制
版本控制也是项目管理者的一个重要工作内容之一，一个项目或产品的完成不可能是一步到位的，在项目完成的后期可能会有多个不同的版本的发布（开发版本，测试版本，发布版本等）。需要做好版本的管理和控制。
8、项目总结
在项目完成后，总结整个完成项目的过程和经历，为下一次的项目启动提供参考经验，完善不足，避免在类似的项目中出现可能存在的相同的错误发生。