商业专项计划书风险分析写法.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计划 Ddo实施 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%在技术实现上是公用）。在实际设计操作过程中，可能有时候项目组内部组员几乎没有一个有经验，那么最好还是聘用部分外部教授来帮忙，我在实际项目中，发觉这个效果会比很好。有了这些有效纲领性技术文件，会在实际开发过程中大大降低多种潜在风险。采取主动应对风险方法让人遗憾是，即便我们做了很多事情来预防风险发生，通常还会有风险发生。一旦突如其来风险发生了，比如：项目组关键组员忽然病倒，用户组织结构发生调整或即使当初签署了协议确定了需求，不过用户业务调整了，那么我们总不能一意孤行还是移交给用户一套其实已经无法运转系统吧。这些风险一旦发生，躲避不是措施，作为一个项目主管来说，愈加行之有效措施是率领整个团体，用主动心态、科学合理方法来以最小代价克服它。当然，这也需要项目组经验和项目主管综合素质来支撑。通常处理风险过程分为三步走：识别? 量化?应对。经过风险识别确定哪些风险可能影响项目，并把风险归档作为以后过程财富很好积累，把产品、历史信息、其它相关信息作为输入，利用检验表、步骤图、面谈等手段，得出风险起源、征兆等结论；风险量化是指评价风险和它们之间相互作用，从而评定项目可能结果大约范围。假如你想开启风险量化过程，那么你需要首先知道这些风险起源，量化是一项比较复杂活动，除了采取货币、时间等来衡量以外，最好借助教授判定。有了比较量化结果以后，项目主管就能清楚意识到风险严重性，从而做出愈加贴切应对方法；有了以上结果以后，就能够制订风险应对方法来制订应对方法了。总而言之，知道了项目风险原因和应对方法，对项目标顺利进行有很关键意义，很多情况下，能否很好处理好项目标风险会成为项目成败关键，这种处理突发风险能力也成为衡量一个项目主管人员关键指标。