吉宁博士观点
本文出处：牛津管理评论
一、项目风险发生的根源
极少听见有项目主管说他的项目没有任何风险而一切尽在掌握。对于一个项目来讲，风险的出现非常常见，把所有风险都拒之门外几乎没有可能，你几乎没有可能完美的解决“工期”、“资源”、“质量”三者的天生的冲突，这些导致项目不可能完全在规定的时间内、按规定的预算由规定的人员完成。这是因为项目计划和预算本质上只是一种预测，在执行过程中与实际情况肯定会有差异，这些预测和实际情况的差异性，就为项目各种各样的风险埋下了伏笔。经过一些项目实践，我总结出项目风险产生的原因主要有以下几条。
1.项目计划中对风险管理没有引起足够的重视，导致风险发生以后手足无措。
2.轻视前期需求工作，导致项目实际产品与客户预期的差别较大。
3.项目过程中过渡轻视文档管理，导致风险发生以后要么无据可依（通常指需求发生变更以后，发现当初需求文档不完善），要么后继无人（通常是一些设计类文档，在人员发生变动的时候，其它人看不懂文档，无法接手工作）。
4.轻视质量控制，导致主管得到的信息与实际差距较大，不能清晰的及时判断出真正的风险是否已经发生。在项目运作过程中，如果只靠员工的报告来掌握项目进展是不够的。事实上，员工都愿意报喜不报忧，在项目初期就出现的问题苗头，如果不能传递上来，将在后续阶段造成大更大的纰漏。缺乏质量控制机制，也就是缺乏有效的“监督”人员来制约，是造成这种情况的主要原因。
5.轻视架构和概要设计。一般项目时间紧、资源有限，这样一些项目经理人在缺乏对系统架构和其它技术方面的设计缺乏有效的论证的前提下，就凭借着经验匆匆启动项目，很可能导致以后一旦因为客户需求变化等因素对整个系统的架构产生影响，导致系统大量的修改。以前就我曾经经历过这种事情，简直让人崩溃。
6.缺乏积极的应对风险的措施。实际上，项目发生风险非常正常，很多风险甚至可以预料是肯定会发生的，一旦比较大的风险发生，会直接对项目组每个成员产生一些负面影响，此时很多项目经理人不能以积极的态度应对，而是自乱了阵脚，很可能导致项目计划频繁变更，项目节奏感被打乱并且逐渐开始失控。
二、解决措施
任何问题，如果找到了真正原因，其实已经向解决问题迈进了一大步。针对以上风险发生的原因，我们可以采取以下一些策略来降低风险带来的损失甚至规避大多数风险。
在项目计划中重视风险的评估
很多项目主管在项目启动的时候认为既然团队已经建立好了，项目计划已经制定好了，就可以憧憬着项目成功了。其实没有任何两个项目是一模一样的，任何项目都会有风险的。在项目初期认真做好风险的评估，并且能让你的项目干系人（尤其是项目主管的掌控项目资源的负责人）清楚这些风险，那么一旦风险发生，也可以更加从容不迫的应对，并且有理由更好的协调资源，不至于让大家不知所措。
要重视需求工作
一个好的需求是连接业务层面和技术层面两类人，让他们达成一致的目标的关键，对于大型的复杂的项目尤其重要。好的需求可以很好的控制客户需求变更给项目带来的负面影响，（很多项目都是这样，不断的需求变更导致不断的修改，如此反复，最后陷入无法自拔的泥潭），因为客户一旦签字确认以后，这份需求就应该与商业合同一起具备法律效力而对客户进行必要的约束；另外一份清晰的没有二义性的需求可以让开发人员非常清晰自己应该完成什么工作，测试人员很好的编写测试用例，就是这份需求，可以大大降低项目组以后在沟通、修改方面的成本，提升效率和产品质量。
其实大部分人都知道“需求”的重要性，有些人肯定会说：“项目时间和资源有限，怎么可能化那么多精力专门做需求呢？”。这是一种误区，需求并不一定要长篇累犊、事无具悉，但是一定要有需求。具体需求怎么写，应该对整个项目做评估以后制定一个策略。比如因为公司长期从事某方面业务，那么这些就可以写简单点；或者项目时间太紧，那么需求文档的模版可以根据实际情况做一些必要的简化。
不合格的需求，往往会因为当初一时的懒惰而让项目最终付出几倍的惨重代价。需求是项目的一份纲领性文件，是以后项目路线的指挥棒，好的需求一定能清晰的描述出整个项目：包括都要做什么以及这些事情的优先级。比如知道优先级以后，项目的经理人就可以根据重要性、难以程度而因人制宜的分派工作，尤其遇到时间特别紧张的情况下，可以说服客户先上最重要的系统模块而把一些不重要的放在以后逐渐实施，这样把好钢都用在刀刃上，在资源等方面受到很多限制的前提下，尽量做到大家的满意，这也为降低日后的风险打下了坚实的基础。
重视项目文档管理
让项目主管最痛苦的事情莫过于：当一个重要成员半途离开项目组时，才发现他根本就没有留下任何可用的文档。尤其在IT项目中，人员流动性强，文档就是成员之间交接的重要工具。但是很多主管很容易陷入“重技术实现，轻文档”的误区，他们总是认为项目实施时间紧迫，为了节省时间，可以在项目收尾阶段突击写文档。要是项目周期稍长一点，到了最后，谁还会清清楚楚记得每个实现细节呢？如果下一个项目与此类似，以前的劳动成果还有谁能继承得下来呢？
当然，现在越来越多的公司已经注意到了管理好文档的重要性，一般可以借助VSS、CVS、PVCS等工具来很好的对文档进行版本控制，但是有一点要特别引起注意：单单关注文档本身远远不够，还要重视文档的质量！即使是在现在很多管理很规范（比如已经通过了CMM3、ISO9000等认证）的公司，“重过程、轻质量”也是一个突出问题。一般在每一份文档入基线以前，都要通过评审、同行评审等方式来对文档进行专门的“轰击”以保证文档的有效性，这些评审小组中如果能包括一些行业、技术方面的专家将经常能达到更好的效果，这些专家完全可以从公司外面聘请。
有了完善和有效的文档做基础，能降低很多项目过程中的风险。
重视质量过程控制
很多人通常认为，在的项目组中最重要的是主管和设计开发人员，而认为项目中的质量过程控制没有什么必要。但是在实际项目过程中，单靠研发人员提供的报告来判断项目进程、确认是否有或者将有风险发生远远不够。因为大部分人喜欢报喜不报忧，而且汇报的内容大部分只是他本人主管的认知，也缺乏通盘的考虑。越复杂的项目，越需要量化的管理，必须有一种机制能让经理人真正掌握项目的实际进展情况，最有效的办法就是建立质控部门与实际的研发部门相互制约，监控测试项目实际情况和实际的问题，而不参与项目的具体实施。
作为一个项目经理人，明确这种研发和质控的关系，除了更好的保证项目质量以外，还能客观的反映项目实际情况，通过这些文档来表明每个基线、每个成员的工作量和完成质量，对识别、预测项目风险意义重大，当然，这些措施也大大降低了项目过程中可能的风险发生的概率。
重视架构和概要设计
在IT项目中，编码实施固然重要，但是对于一个比较复杂项目中的项目组来讲，如何让不同角色的研发人员高效协作，将是更加要紧的问题。
设计文档，尤其是架构设计就是能够让这些研发资源更加高效协作，降低返工的有效手段。有了这些设计作为指引，研发人员就可以同步工作，共享公用的资源（比如，经过设计分析以后，发现客户业务方面有A、B、C三个业务模块，但是其实这三个模块中有几乎50%在技术实现上是公用的）。在实际设计的操作过程中，可能有时候项目组内部成员几乎没有一个有经验，那么最好还是聘请一些外部的专家来帮忙，我在实际的项目中，发现这个效果会比较好。
有了这些有效的纲领性的技术文件，会在实际开发过程中大大降低各种潜在的风险。
采用积极的应对风险的措施
让人遗憾的是，即便我们做了很多的事情来防止风险的发生，通常还会有风险发生。一旦突如其来的风险发生了，例如：项目组核心成员突然病倒，客户组织结构发生调整或者虽然当初签订了合同确认了需求，但是客户业务调整了，那么我们总不能一意孤行的还是移交给客户一套其实已经无法运转的系统吧。这些风险一旦发生，躲避不是办法，作为一个项目主管来说，更加行之有效的办法是带领整个团队，用积极的心态、科学合理的方法来以最小的代价克服它。当然，这也需要项目组的经验以及项目主管的综合素质来支撑。
通常处理风险的过程分为三步走：识别?量化?应对。通过风险识别确定哪些风险可能影响项目，并把风险归档作为以后过程财富的很好的积累，把产品、历史信息、其它相关信息作为输入，利用检查表、流程图、面谈等手段，得出风险的来源、征兆等结论；风险量化是指评价风险和它们之间的相互作用，从而评估项目可能结果的大概范围。如果你想启动风险量化过程，那么你需要首先知道这些风险的来源，量化是一项比较复杂的活动，除了采取货币、时间等来衡量以外，最好借助专家的判断。有了比较量化的结果以后，项目主管就能清晰的意识到风险的严重性，从而做出更加贴切的应对措施；有了以上的结果以后，就可以制定风险应对措施来制定应对措施了。
总之，知道了项目风险的原因和应对措施，对项目的顺利进行有非常重要的意义，很多情况下，能否很好的处理好项目的风险会成为项目成败的关键，这种处理突发风险的能力也成为衡量一个项目主管人员重要指标。
