商业计划书风险分析写法(共12页).doc

精选优质文档-倾情为你奉上商业计划书风险分析写法 一  资源（原材料/供应商）风险 二  市场不确定性风险 三  研发风险 四  生产不确定性风险 五  成本控制风险 六  竞争风险 七  政策风险 八  财务风险（应收帐款/坏帐） 九  管理风险（含人事/人员流动/关键雇员依赖） 十  破产风险1、引言由于软件项目的研制需要开发新的技术，或使用许多已经过验证的技术和产品，但产品生产数目一般较少，这些技术和加工工艺不容易达到成熟或定型的程度。且大型项目的研制需要长时间大规模的组织、指挥协调工作，以及漫长的研制周期等，都会带来种种难以预见的不确定性因素。这些不确定因素的存在使得软件项目能否按照预定的计划费用、进度和性能完成研制任务往往难以预料，不可能做到研制完全成功，存在着失败的风险。所以在项目研制的可行性分析和方案认证时，加强方案风险分析是十分必要的。对风险的研究自七十年代末开始，其应用的风险分析方法与可靠性分析方法类似，或在此基础上进行扩充。目前，在风险研究方面，比较著名的方法有GERT（图解评审技术），VERT（风险评审技术），RSINET（风险信息系统与网络评审技术）和SLAM（多功能构模仿真语言）等。GERT的基本特点是可以直接对网络模型进行计算机仿真分析，其模型元素与相应的分析程序相配合，可以用来描述复杂的排队系统、项目管理及生产线方面的问题，应用十分简便、灵活，而对时间、费用、性能方面的问题不太适合；SLAM是一种以FORTRAN为基础的构模仿真语言，可进行离散网络、连续系统及离散事件的综合仿真，能适应多种构模需要，但提供资源模块有限，仿真不能进行全过程支持，不能支持图形建模等不足；VERT可处理时间、费用、性能等关键性风险参数，能对多目标优化，具有较大的实用价值。在这些风险方法中，VERT对于时间、费用和性能三个指标在处理水平上平等对待，既可独立地进行并行处理，也可通过数学关系式而相互联系起来进行处理；节点的逻辑功能丰富，活动上的三项指标都可用一定的概率分布、直方图或数学关系式来描述，因而VERT网络模型比较接近实际系统的要求；VERT对于费用和性能这二项指标，可按用户的需要灵活地加以应用。2、风险分析的概念风险的定义是：对目前所采取的行动，在未来没有达到预期结果（失败）的可能性。其大小可用失败的概率和失败的后果两个变量来标识。风险分析有狭义和广义两种，狭义的风险分析是指通过定量分析的方法给出完成任务所需的费用、进度、性能三个随机变量的可实现值的概率分布。而广义的风险分析则是一种识别和测算风险，开发、选择和管理方案来解决这些风险的有组织的手段。它包括风险识别、风险评估和风险管理三方面的内容。本文中论及风险分析时，都采用后一种定义。风险识别是指确定哪些可能导致费用超支、进度推迟或性能降低的潜在问题，并定性分析其后果。在这一步须作的工作是分析系统的技术薄弱环节及不确定性较大之处，得出系统的风险源，并将这些风险源组合成一格式文件供以后的分析参考。它属于定性分析的范围。风险评估是指对潜在问题可能导致的风险及其后果实行量化，并确定其严重程度。这其中可能牵涉到多种模型的综合应用，最后得到系统风险的综合印象。而风险管理则是指在风险识别及风险分析的基础上采取各种措施来减小风险及对风险实施监控。这也可以说是风险分析的最终目的。作为对风险概念的进一步界定，本文将简单介绍风险中的两种不同类型及风险分析与可靠性分析的区别。2.1、系统运行及项目研制风险第一类风险是系统运行风险。指当一部分系统运行时，由于种种不确定性因素或系统本身硬件或组元的失效而造成预定任务的完成不确定性以及由此而带来的系统设备的损坏或人员的伤亡。这类风险由于其明显的危害性及影响性，目前进行研究得较多，有代表性的如大型航天软件的运行风险管理。已经发展成熟的分析方法有如FMECA（失效模式与效应分析）、FTA（故障树分析）、ETA（事件树分析）及事件树/故障树分析量化基础上的PRA（风险概率评估）和DPRA（动态概率风险评估）等。第二类风险是项目研制风险，这也是本文的主要研究范围。它是指大型项目研制开发过程中，由于技术的难以保证、管理的不得力及经费的拖延导致研制出的系统性能降低、费用超标、进度延迟等。这类风险由于其危害呈隐性，目前进行研究得较少。项目研制风险一般包括技术风险、进度风险及费用风险。两类风险的不同之处在于，对于系统运行风险，系统已经存在，因对其分析必须从单个硬件或主元的失效及其综合影响上考虑。而作为项目研制风险，由于并无一确定的系统，系统研制成功本身便是研制任务的状态之一，这决定了它的分析方法与上述不同，不能针对硬件分析，而须从事件的角度上进行考察。两类风险的另一个不同之处在于项目风险的非刚性。所谓非刚性是指当风险源导致风险发生以后，造成的后果可以修复。2.2、系统运行风险与可靠性系统运行风险与可靠性分析是两个极易混淆的概念，它们都是指对于某种工艺过程或设备的失效或运行状态的研究。但其分析的目的却有所不同，有必要在此作一简单的区分。可靠性的定义是系统在一定时间内能够完成规定任务的概率。其研究的范畴在于系统硬件或组元的耐用程度，研究的最后结果是系统整体失效随时间而变化的可能性。而系统运行风险则是研究这种失败可能对社会造成的危害，其最后结果是造成的系统设备损坏的或人员伤亡的期望值。3、风险种类对软件项目的管理部门来说，在做出与规定费用按规定时间交付规定产品或达到规定性能水平的决断时，风险是永远存在的。软件项目管理部门因风险而导致工作失败有三种方式：产品达不到规定的性能水平、实际费用过高、交付过迟等。就一个项目而言，其面临的风险可分为五个方面：技术（与性能有关）、保障性（与性能有关）、计划（与环境有关）、费用和进度。3.1、技术风险技术风险可以定义为发展某项新设计所包含的风险，发展这项设计的目的是要将性能水平在原有基础上提高一步，但也可能因为受到某些新的约束条件的作用而使性能水平原封未动，甚至反而有所下降。技术风险的性质和原因随军用系统的设计而各不相同。许多技术风险往往是由于对新系统和新设备提出前所未有的性能要求造成的。3.2、计划风险计划风险是包括获取和使用一些可能不受软件项目控制但又可能影响软件项目方向的可用资源和活动。计划风险一般不会与改善技术水平有直接关系。计划风险可按一些因素的性质和来源分类，这些因素有可能中断软件项目实施计划。造成软件中断的因素主要以下几种：（1）与软件项目直接有关的高层权力机构决策造成的中断；（2）一些影响软件项目的事件或行动造成的中断；（3）主要由于一些不能预见的与生产有关的问题造成的中断；（4）因能力不足造成的中断。3.3、保障性风险保障性风险是与系统的部署和维修有关的风险，这些系统指目前正在研制或正在部署的系统。保障性风险包含有技术和计划两个方面风险的特征。构成综合后勤保障要素潜在的十种风险源要素是：（1）维修规划；（2）人力和人员；（3）保障设备；（4）技术资料；（5）训练；（6）训练保障；（7）计算机资料保障；（8）设施；（9）包装、装卸、存储和运输；（10）设计接口。3.4、费用和进度风险一些性能和设计技术问题有时要靠增加费用和延长进度来解决，这往往会使问题变得复杂化。费用和进度增长指预计软件项目费用和进度与实际费用和时间之间的差异。因此，费用和进度增长会造成两个主要的费用/进度风险区：预计时定下不合理的低费用/进度目标所造成的风险；要想满足合理的费用/进度目标，软件项目就必须给定一个谨慎的风险。4、风险分析的步骤风险分析试图定量回答一些问题，这些问题与为了完成某个特定任务所研制的软件和硬件性能上固有的效果范围有关，也与人们自身相互因素的作用和影响有关。风险分析人员确定风险的方法是：把不希望的事件发生的概率与每个可预见的后果的大小相结合。一般地，系统运行风险分析可以分为以下四个步骤：(1) 风险识别、检测某种情况，确定潜在的风险范围；(2) 风险量化，确定事件发生的概率以及产生的后果；(3) 风险影响评估和方案选择，定量计算发生风险的后果和选择行动方案；(4) 风险处理计划，描述处理风险的各种方法，并推荐具体的处理风险的行动。项目风险分析步骤也可以这些步骤为参考。5、风险分析的方法我们知道，对于风险分析所作的工作大多局限于任务风险分析当中。这些方法对于考虑项目风险领域的分析方法也有一定意义，风险分析方法可分为定性和定量两种，定量的风险分析方法是在定性的基础上而实现的。下面，我们对这两类风险分析方法作简要的论述。5.1、定性风险分析方法定性风险分析的目的是界定风险源，并初步判明风险的严重程度，以给出系统风险的综合印象，表1是一些定性风险分析方法的简介。易于看出，初步危险分析是用于识别系统中可能存在的风险源，而以下的几种方法则用于定性地量化各种风险源可能对系统造成的破坏，从而判明系统风险大小。5.2、定量风险分析方法定量风险分析是在定性分析的逻辑基础上，给出各个风险源的风险量化指标及其发生概率，再通过一定的方法合成，得到系统风险的量化值。它是基于定性风险分析基础上的数学处理过程。现发展较为成熟的方法有PRA（概率风险评估）,DPRA（动态风险概率评估）及仿真通用软件VERT（风险评审技术）等。PRA和DPRA都是在FTA分析基础上的量化，在可靠性及运行系统风险分析领域内应用广泛。稍作改造，我们便可将其运用到项目风险分析领域。其分析步骤如下：（1）识别项目研制过程中的困难环节，找出风险源；（2）对各风险源考察其在项目研制中的地位，及相互逻辑关系，给出项目的风险源树；（3）标识各风险源后果大小，及风险概率；（4）对风险源通过逻辑及数学方法进行组合，最后得到系统风险的度量。如果是用DPRA进行评估，则尚须考虑它们在时间上的关系。另一种被广泛运用于风险评估的方法是VERT 。VERT是国外在八十年代初期发展的一通用仿真软件，它对项目研制构造过程网络，将各种复杂的逻辑关系抽象为时间、费用、性能的三元组的变化。网络模型面向决策，统筹处理时间、费用、性能等风险关键性参数，有效地解决多目标最优化问题，具有较大的实用价值。它的原理是通过丰富的节点逻辑功能，控制一定的时间流、费用流和性能流流向相应的活动。每次仿真运行，通过蒙特卡洛模拟，这些参数流在网络中按概率随机流向不同的部分，经历不同的活动而产生不同的变化，最后至某一终止状态。用户多次仿真后，通过节点收集到的各参数了解系统情况以辅助决策。如果网络结构合理，逻辑关系及数学关系正确，且数据准确，我们可以较好地模拟实际系统研制时间、费用及性能的分布，从而知道系统研制的风险。6、风险分析的原则在风险分析时，应该遵循一些分析原则。下面是进行风险分析的几个一般性原则：（1）风险分析是软件设计的一部分，就像应力分析是传统软件设计实践的部分一样；（2）风险分析是正式的、严谨的、定量化的；（3）风险分析的目的是为了支持决策，应当把风险分析作为系统软件设计和研制过程的一部分，而不应该过迟而无法做出主要的改变和资金的压力强迫在安全性和可靠性上妥协，而这种妥协不能接受的情况下，作为一种反省进行；（4）风险分析可以按各种等级的详细程度、彻底程度和精密程度来进行；（5）风险分析详细、彻底、精确程度与分析项目的重要性和环境潜在的破坏程度大小相一致；（6）在一个项目的早期概念阶段，能够而且应该实施近似的风险分析，随着设计的逐渐开展，风险分析的精度和详细程度也随之提高。风险分析第十一章 项目项目包括对项目风险进行识别、分析和应对过程。它包括把正面事件影响扩大到最大和把负面事件影响减到最小。风险识别风险识别包括确定可能对项目造成影响的风险,并且把每一风险的特性编制成文档.风险识别不是一次性活动,必须在整个项目过程中经常进行.风险识别应同时注意内部和外部的风险.严格的说,风险仅包括遭受损失或损失的可能性.而在项目的背景中,风险识别同时也与机会和威胁有关.风险识别产品描述产品描述，项目产品的特性将会对识别出的风险产生主要的影响使用成熟的技术与需要革新和发明的产品相比，承担较小的风险。风险识别的工具和技术检查表：检查表通常是由风险来源组织而成的。来源包括：项目内容；其他风险输出；项目产品或技术事宜；内部来源，如项目队伍成员的 技能等。绘制流程图：绘制流程图能帮助项目队伍更好地理解风险的成因及结果。访问调查：走访不同的项目干系人将有助于风险识别，这些风险在通常的计划活动中不易被发现。另外还可以获取以前的调查记录。风险来源风险来源：风险来源是根据可能发生的风险事件分类的。来源清单应该是综合的，通常应该包括所有已识别的事项，如风险发生频率、发生的可能性、得失的大小等。一般风险来源包括：风险来源描述对风险来源的描述通常应包括对以下事项的估算：潜在的风险事件对项目产生影响的潜在的风险事件是离散发生的，如自然灾害或项目队伍的某一成员离开。除了那些发生可能性及造成的损失量都相对教大的风险来源以外还必须对潜在的风险事件仔细识别。在应用领域中，一般的风险事件检查表是具体明确的，而潜在的风险很少 能明确描述，例如：潜在风险的描述对潜在风险的描述应包括以下的估算：风险征兆风险征兆，有时也称触发器，是实际风险事件的非直接证明。如：士气低落可能是进度计划延误逼近的早期预警信号；早期活动的成本超支则可能是估计不正确的结果。风险量化创业的意义 为社会创造价值 一份属于自己的事业 改变自己的生活状况 展示自己的才华   创业准备 激情与理智 立项与完整的计划 资金 风险及对策 良好的心态：胜固欣然，败亦可喜！                             4个95% 95%的失败不是由于项目本身，而是由于创业者缺乏计划性、严密性、系统性 95%的人并不是缺钱，而是缺少良好的资金运作，从而导致资金链断裂 95%的项目不是运作不下去，而是做项目的人没有坚持下去，缺少坚持到底的精神 95%的项目在运作一段时间后完全偏离了当初的项目计划与设想，完全走样了 四个动作 拍脑门 拍胸脯 拍大腿 拍屁股 有效计划的方法  “戴明环” PDCA循环 Pplan  计划 D do    执行 Ccheck检查 Aaction行动 周而复始、大环带动小环、阶梯式上升 项目计划书八部曲 风险 财务风险及对策 技术风险及对策 管理风险及防范 市场风险及防范 人才风险 能力风险 市场分析  品牌竞争策略  组织与人力资源  SOWT分析 企业发展的四个阶段 四个时期相应的人力资源策略人力资源的风险管理人力资源管理中的风险管理是指在招聘、工作分析、职业计划、绩效考评、工作评估、薪金管理、福利、员工培训、员工管理等各个环节中进行风险管理，防范人力资源管理中的风险发生。 在进行人力资源管理时，我们往往重视招聘、培训、考评、薪资等各个具体内容的操作，而忽视了其中的风险管理问题。其实，每个企业在人事管理中都可能遇到风险，如招聘失败、新政策引起员工不满、技术骨干突然离职等等，这些事件会影响公司的正常运转，甚至会对公司造成致命的打击。如何防范这些风险的发生，是我们应该研究的问题。特别是高新技术企业，由于对人的依赖更大，所以更需要重视人力资源管理中的风险管理。 风险分类 一般我们可以按人力资源管理中的各环节对风险进行分类，如招聘风险、绩效考评风险、工作评估风险、薪金管理风险、员工培训风险、员工管理风险等等。对高新技术企业来讲，招聘风险、绩效考评风险、薪金管理风险、员工管理风险等显得更为重要。 另外我们也可从已知风险、可预知风险、不可预知风险的角度对风险进行分类。对于已知风险和可预知风险我们要采取积极地措施进行防范。 风险识别 要想防范风险，首先要进行风险识别。识别风险就是主动地去寻找风险。比如员工管理中，技术骨干离职风险可能会由以下几个方面产生： 1、待遇：他是否对他的待遇满意？ 2、工作成就感：他是否有工作成就感？ 3、自我发展：他是否在工作中提高了自己的能力？ 4、人际关系：他在公司是否有良好的人际关系？ 5、公平感：他是否感到公司对他与别人是公平的？ 6、地位：他是否认为他在公司的地位与他对公司的贡献成正比？ 7、信心：他是否对公司的发展和个人在公司的发展充满了信心？ 8、沟通：他是否有机会与大家沟通、交流？ 9、关心：他是否能得到公司和员工的关心？ 10、认同：他是否认同企业的管理方式、企业文化、发展战略？ 11、其他：他是否有可能因为结婚、出国留学、继续深造等原因离职？ 人事经理要认真了解客观情况，对可能发生的风险进行有效识别，这是防范风险的第一步。 风险评估 风险评估是对风险可能造成的灾害进行分析。主要通过以下几个步骤进行评估： 1、根据风险识别的类型有针对性的进行调研； 2、根据调研结果和经验，预测发生的可能性，并用百分比表示发生可能性的程度； 3、根据程度排定优先队列。 比如说，人事经理可以通过与当事人交谈、发调查表等形式进行调研，并根据调研结果和经验，确定该员工在各风险识别条目中离职的可能性。结果如下： （1）10（2）20（3）10（4）0（5）50（6）20（7）0（8）30（9）0（10）0（11）0。 优先队列是：（5）、（8）、（2）、（6）、（1）、（3）、（4）、（7）、（9）、（10）、（11）。 人事经理可以发现，该员工对公平、沟通较为不满，由于公平问题而离职的可能性最大，其次是沟通问题。 风险驾驭 风险驾驭是解决风险评估中发现的问题，从而消除预知风险。它一般由以下几个步骤构成： 1、针对预知风险进行进一步调研； 2、根据调研结果，草拟消除风险方案； 3、将该方案与相关人员讨论，并报上级批准； 4、实施该方案。 人事经理可针对公平问题和沟通问题，进行专项交谈或调查，找出问题的根源，并草拟相应的方案。如解决公平问题的方案如下： 1、在制定公司规章制度时，广泛征求员工的意见； （通过调查发现，由于没有参与制度的制定，误认为制度本身不公平） 2、向各部门发放公司制度合订本，方便员工了解公司制度； （通过调查发现，由于对某些制度的细节不很清楚，误以为制度执行不公平） 3、将工资晋升标准公开，使工资晋升透明化； （通过调查发现，由于公司工资晋升标准不明确，容易产生待遇不公平感） 4、增加部门间交流； （通过调查发现，误认为其他部门工作轻松，而自己是最辛苦的，也容易产生不公平感） 人事经理可以将上述建议与大家讨论，最后由办公例会或总经理批准通过。 通过上述方案的实施，可能会增加大家的公平感，具体效果如何，还要进行调查得出结论。 风险监控 当旧的风险消除后，可能又会出现新的风险，所以风险识别、风险评估、风险驾驭这几个环节要连续不断的进行下去，形成有效的监控机制。 在一段时间以后，要对风险进行再分析，确保对风险制定的驾驭方案能够切实有效的进行。并且要对执行中的问题进行再评估。 另外要注意总结经验，为将来的风险管理提供数据。规避项目资源风险的几点建议一、项目风险发生的根源极少听见有项目主管说他的项目没有任何风险而一切尽在掌握。对于一个项目来讲，风险的出现非常常见，把所有风险都拒之门外几乎没有可能，你几乎没有可能完美的解决“工期”、“资源”、“质量”三者的天生的冲突，这些导致项目不可能完全在规定的时间内、按规定的预算由规定的人员完成。这是因为项目计划和预算本质上只是一种预测，在执行过程中与实际情况肯定会有差异，这些预测和实际情况的差异性，就为项目各种各样的风险埋下了伏笔。经过一些项目实践，我总结出项目风险产生的原因主要有以下几条。1. 项目计划中对风险管理没有引起足够的重视，导致风险发生以后手足无措。2. 轻视前期需求工作，导致项目实际产品与客户预期的差别较大。3. 项目过程中过渡轻视文档管理，导致风险发生以后要么无据可依（通常指需求发生变更以后，发现当初需求文档不完善），要么后继无人（通常是一些设计类文档，在人员发生变动的时候，其它人看不懂文档，无法接手工作）。4. 轻视质量控制，导致主管得到的信息与实际差距较大，不能清晰的及时判断出真正的风险是否已经发生。在项目运作过程中，如果只靠员工的报告来掌握项目进展是不够的。事实上，员工都愿意报喜不报忧，在项目初期就出现的问题苗头，如果不能传递上来，将在后续阶段造成大更大的纰漏。缺乏质量控制机制，也就是缺乏有效的“监督”人员来制约，是造成这种情况的主要原因。5. 轻视架构和概要设计。一般项目时间紧、资源有限，这样一些项目管理者在缺乏对系统架构和其它技术方面的设计缺乏有效的论证的前提下，就凭借着经验匆匆启动项目，很可能导致以后一旦因为客户需求变化等因素对整个系统的架构产生影响，导致系统大量的修改。以前就我曾经经历过这种事情，简直让人崩溃。6. 缺乏积极的应对风险的措施。实际上，项目发生风险非常正常，很多风险甚至可以预料是肯定会发生的，一旦比较大的风险发生，会直接对项目组每个成员产生一些负面影响，此时很多项目管理者不能以积极的态度应对，而是自乱了阵脚，很可能导致项目计划频繁变更，项目节奏感被打乱并且逐渐开始失控。二、解决措施任何问题，如果找到了真正原因，其实已经向解决问题迈进了一大步。针对以上风险发生的原因，我们可以采取以下一些策略来降低风险带来的损失甚至规避大多数风险。在项目计划中重视风险的评估很多项目主管在项目启动的时候认为既然团队已经建立好了，项目计划已经制定好了，就可以憧憬着项目成功了。其实没有任何两个项目是一模一样的，任何项目都会有风险的。在项目初期认真做好风险的评估，并且能让你的项目干系人（尤其是项目主管的掌控项目资源的负责人）清楚这些风险，那么一旦风险发生，也可以更加从容不迫的应对，并且有理由更好的协调资源，不至于让大家不知所措。要重视需求工作一个好的需求是连接业务层面和技术层面两类人，让他们达成一致的目标的关键，对于大型的复杂的项目尤其重要。好的需求可以很好的控制客户需求变更给项目带来的负面影响，（很多项目都是这样，不断的需求变更导致不断的修改，如此反复，最后陷入无法自拔的泥潭），因为客户一旦签字确认以后，这份需求就应该与商业合同一起具备法律效力而对客户进行必要的约束；另外一份清晰的没有二义性的需求可以让开发人员非常清晰自己应该完成什么工作，测试人员很好的编写测试用例，就是这份需求，可以大大降低项目组以后在沟通、修改方面的成本，提高效率和产品质量。其实大部分人都知道“需求”的重要性，有些人肯定会说：“项目时间和资源有限，怎么可能化那么多精力专门做需求呢？”。这是一种误区，需求并不一定要长篇累犊、事无具悉，但是一定要有需求。具体需求怎么写，应该对整个项目做评估以后制定一个策略。比如因为公司长期从事某方面业务，那么这些就可以写简单点；或者项目时间太紧，那么需求文档的模版可以根据实际情况做一些必要的简化。不合格的需求，往往会因为当初一时的懒惰而让项目最终付出几倍的惨重代价。需求是项目的一份纲领性文件，是以后项目路线的指挥棒，好的需求一定能清晰的描述出整个项目：包括都要做什么以及这些事情的优先级。比如知道优先级以后，项目的管理者就可以根据重要性、难以程度而因人制宜的分派工作，尤其遇到时间特别紧张的情况下，可以说服客户先上最重要的系统模块而把一些不重要的放在以后逐渐实施，这样把好钢都用在刀刃上，在资源等方面受到很多限制的前提下，尽量做到大家的满意，这也为降低日后的风险打下了坚实的基础。重视项目文档管理让项目主管最痛苦的事情莫过于：当一个重要成员半途离开项目组时，才发现他根本就没有留下任何可用的文档。尤其在IT项目中，人员流动性强，文档就是成员之间交接的重要工具。但是很多主管很容易陷入“重技术实现，轻文档”的误区，他们总是认为项目实施时间紧迫，为了节省时间，可以在项目收尾阶段突击写文档。要是项目周期稍长一点，到了最后，谁还会清清楚楚记得每个实现细节呢？如果下一个项目与此类似，以前的劳动成果还有谁能继承得下来呢？当然，现在越来越多的公司已经注意到了管理好文档的重要性，一般可以借助VSS、CVS、PVCS等工具来很好的对文档进行版本控制，但是有一点要特别引起注意：单单关注文档本身远远不够，还要重视文档的质量！即使是在现在很多管理很规范（比如已经通过了CMM3、ISO9000等认证）的公司，“重过程、轻质量”也是一个突出问题。一般在每一份文档入基线以前，都要通过评审、同行评审等方式来对文档进行专门的“轰击”以保证文档的有效性，这些评审小组中如果能包括一些行业、技术方面的专家将经常能达到更好的效果，这些专家完全可以从公司外面聘请。有了完善和有效的文档做基础，能降低很多项目过程中的风险。重视质量过程控制很多人通常认为，在的项目组中最重要的是主管和设计开发人员，而认为项目中的质量过程控制没有什么必要。但是在实际项目过程中，单靠研发人员提供的报告来判断项目进程、确认是否有或者将有风险发生远远不够。因为大部分人喜欢报喜不报忧，而且汇报的内容大部分只是他本人主管的认知，也缺乏通盘的考虑。越复杂的项目，越需要量化的管理，必须有一种机制能让管理者真正掌握项目的实际进展情况，最有效的办法就是建立质控部门与实际的研发部门相互制约，监控测试项目实际情况和实际的问题，而不参与项目的具体实施。作为一个项目管理者，明确这种研发和质控的关系，除了更好的保证项目质量以外，还能客观的反映项目实际情况，通过这些文档来表明每个基线、每个成员的工作量和完成质量，对识别、预测项目风险意义重大，当然，这些措施也大大降低了项目过程中可能的风险发生的概率。重视架构和概要设计在IT项目中，编码实施固然重要，但是对于一个比较复杂项目中的项目组来讲，如何让不同角色的研发人员高效协作，将是更加要紧的问题。设计文档，尤其是架构设计就是能够让这些研发资源更加高效协作，降低返工的有效手段。有了这些设计作为指引，研发人员就可以同步工作，共享公用的资源（比如，经过设计分析以后，发现客户业务方面有A、B、C三个业务模块，但是其实这三个模块中有几乎50%在技术实现上是公用的）。在实际设计的操作过程中，可能有时候项目组内部成员几乎没有一个有经验，那么最好还是聘请一些外部的专家来帮忙，我在实际的项目中，发现这个效果会比较好。有了这些有效的纲领性的技术文件，会在实际开发过程中大大降低各种潜在的风险。采用积极的应对风险的措施让人遗憾的是，即便我们做了很多的事情来防止风险的发生，通常还会有风险发生。一旦突如其来的风险发生了，例如：项目组核心成员突然病倒，客户组织结构发生调整或者虽然当初签订了合同确认了需求，但是客户业务调整了，那么我们总不能一意孤行的还是移交给客户一套其实已经无法运转的系统吧。这些风险一旦发生，躲避不是办法，作为一个项目主管来说，更加行之有效的办法是带领整个团队，用积极的心态、科学合理的方法来以最小的代价克服它。当然，这也需要项目组的经验以及项目主管的综合素质来支撑。通常处理风险的过程分为三步走：识别? 量化?应对。通过风险识别确定哪些风险可能影响项目，并把风险归档作为以后过程财富的很好的积累，把产品、历史信息、其它相关信息作为输入，利用检查表、流程图、面谈等手段，得出风险的来源、征兆等结论；风险量化是指评价风险和它们之间的相互作用，从而评估项目可能结果的大概范围。如果你想启动风险量化过程，那么你需要首先知道这些风险的来源，量化是一项比较复杂的活动，除了采取货币、时间等来衡量以外，最好借助专家的判断。有了比较量化的结果以后，项目主管就能清晰的意识到风险的严重性，从而做出更加贴切的应对措施；有了以上的结果以后，就可以制定风险应对措施来制定应对措施了。总之，知道了项目风险的原因和应对措施，对项目的顺利进行有非常重要的意义，很多情况下，能否很好的处理好项目的风险会成为项目成败的关键，这种处理突发风险的能力也成为衡量一个项目主管人员重要指标。专心-专注-专业