风险无处不在，而且几乎无可避免。作为项目经理，我们不能乞求谁会给我们一个安全的项目。事实上没有真正意义上的风险，项目注定是要失败的：全无风险的同时，它们也几乎全无价值。这些项目我们大可不以理会，给自己节省一点时间和精力，去做些真正有价值的事。正视无可避免的风险，加以适当的识别、分析、制定计划对其管理与应对，使项目能够更加好地达到目标。

　　我曾在SOVO担任项目经理，项目关于SOVO内部信息共享与考勤。我们的工作一直受不断更变的需求所困扰。在初的计划中，由于经验不足等原因，需求分析的工作不足。问题的在于初期的计划中根本没有考虑到公司的内部项目的需求会不断更变，导致项目的时间、范围、成本难以控制。虽然后项目终于完成，但已大大超出了计划的成本，严格来说项目可以说失败了。

　　我们选择的系统开发语言是现在已经成熟的网站设计语言JSP(Java)+Servlet。采用基于 J2EE平台的MVC(模型(Model)－视图(View)－控制器(Controller))模式的应用架构框架---Structs+Spring架构， 主要是采用Servlet和JSP技术来实现的。而在数据库访问技术方面：应用程序采用JDBC连接数据库，并采用数据库连接池技术。连接池技术可以减少应用程序与数据库连接的时间，提高数据总体访问速度。数据库采用Microsoft SQL2000，WEB服务器使用TOMCAT5.0，系统采用WINDOWS 2000 SERVER，开发软件为ECLIPSE 3.1。

　　本项目从2005年10月11日开始，计划在12月11日两个月时间完成项目。在任务分配方面采用两个经理，一为执行经理，主要负责需求分析，客户联系及相关的文档整理，二为技术经理，主要负责项目开发中的项目开发规范、采用技术、解决方案等技术问题。在开发前期的需求分析中，由于客户没有及时提供资料，导致需求分析时间延迟两个星期，故整个项目延迟两个星期。在执行经理进行需求分析的同时，技术经理也在进行新技术的学习与框架的架设，其他项目代码编写成员也作相关技术的学习。而美工则进行首页及二级页面的设计并确定客户的需求。

　　经过一个月时间的努力，完成了需求分析，系统概要设计，页面设计，框架也架设完。但由于在短时间未能灵活使用新技术原因，同时也因为部分小组人员的辞退，没有在计划的两个星期中完成代码编写工作，而用了三个星期。剩余的一个星期作相应的系统测试和调整。

　　后由于期末项目组人员要进行备考，不得不停止项目后开发阶段。直至2006年2月28日才重新进行开发。计划在2006年3月28日完成项目。前两个星期重新设计了一些功能模块和修复上一学期遗留下来的BUG。后两个星期是进行系统测试并修复相关的BUG。终经过两次回归测试完成了整个项目。

　　无论用何种方法或模式开发IT项目，风险总是比较高的，这正是IT行业有高利润的原因。在众所周知的项目管理九大知识领域中，个人认为风险管理在每一个其他管理范围内都有体现。可以说项目经理的工作是在与风险打交道。风险管理对项目的成功有很大作用。

　　风险管理过程的重要作用在于风险效率。这也是不该把风险管理看做是“附加内容”或“辅助内容”，不该把重点放在“实施风险管理是不是值得”这个问题上的主要原因。风险管理应该被看作是与项目管理融为一体的“内在内容”，贯穿于项目开发的每一个过程中，是对基本项目计划过程的扩大和完善。实施风险管理要考虑的关键问题是：在这种情况下，应该以何种方式正式实施多少风险管理才合适？

　　在进行风险管理时，所选择的风险分析方式必须
与寻求改善风险效率的机会相适应。通常要识别出应该把额外的资金或资源用在何处将会降低今后的风险和总预期成本。判别能够改善风险效率的基准计划或应急计划中潜在的变更是有效项目风险管理的主要目的。

　　为了做到完全有效，风险管理应该针对整个项目生命周期而不是项目管理的某个阶段。通过将风险管理纳入到项目整体管理中，可以利用风险分析指导并丰富管理过程的所有阶段。软件项目的风险体现在以下四个方面：需求、技术、成本和进度。

　　按我对SOVO的实际情况来看，技术、成本和进度都是SOVO生存环境的一个优势。在目前这种气候下，项目风险管理只要把握好需求这个方面能够达到利益大化。

　　为什么这么说呢？正如我给文章定的题目，项目的风险管理是无可避免的。因为无论是做一个项目，还是干一件事情，都有风险的存在，这是不以人的意志为转移的一个客观存在的事实，只不过在实施过程中由于环境动态和时间动态等动态因素的影响，风险出现的几率也会随之变化，可能是增加，也可能是减少，风险可能会暴发，也可能只是一直潜伏，这是一个动态变化的过程。所以从逻辑上讲，风险终会不会出现，会不会在我们的计划内，是只有到项目进行到那一步，事情发展到那一步才能终确定。

　　但需要强调一点是这只是理论逻辑，相对于实实在在的项目，活生生的事物，鲜明的例子来说，所谓的几率只是书本上的符号，逻辑只是教科书上的符号。

　　虽然说理论可以指导实践，可大多数人往往信奉眼见为实，经验指导实际操作。也是说，比较起理论知识的冗长复杂和难于理解，人们更愿意直接去相信一些已经发生的事实和通俗易懂的简单道理。

　　风险的发生存在一定的几率，有的发生的几率大，有的发生的几率小。可以是大于99%几率会有风险，可以是小于1%的几率会有风险。在实际情况中，人往往可以凭借经验，综合考虑，根据外部环境的变量来预测推断项目实施进度过程中哪些风险基本可以忽略，而哪些风险是需要特别注意防范的。

　　象任命一个项目经理，人们往往更愿意，更希望找到一个有类似项目工作经历的人来担当一样，其考虑的根本着眼点在于风险，因为有过相似经历的情况下，首先在考虑项目计划时能更全面周到老练。在市场经济环境下，顾主选择人才一个很重要的标准是工作经历，只要你有经历和经验，胜过那些只会吹嘘理论的书生。

　　事物的发展过程总是有一个阶段性的，经验并不能知道一切的实践。即使是SOVO，当组织规范发展到一定程度的时候，必然要回归到理论逻辑的学习阶段。重新开始一个新的经验积累。这时我们需要注意新的情况。

　　在项目生命周期的每个阶段都会有风险的存在，而每次应用风险分析技术都会包括：定义、集中、识别、结构、所有权、估计、评价、计划和管理九个阶段。同时在没个阶段进行风险管理的过程中，还应该注意以下几个问题。

　　1.风险管理过程的成本
　　与风险管理过程相关的成本会出现在资金或时间方面，但是机会成本可能更重要，而且机会成本在进行长期决策时发挥着重要作用。我们需要在固定的资源约束范围内工作，关键人员的时间会变得极其宝贵。用经济学术语来讲，风险管理过程涉及的所有人员(而不仅仅是风险管理过程的专业人员)每增加一个小时的边际成本，应该用花费这些时间完成其他工作所实现的大价值来衡量。在项目运行的某一关键点上，所涉及人员的时间非常宝贵，可能是他们工资总成本的2倍、3倍甚至10倍，因此对这些人和时间的有效利用至关重要。风险管理过程本身即是一个高风险的项目。如果在基本执行过程中已经出现危机，此时试图增加风险管理过程的资源(包括对人员的更多支持，不只限于风险管理过程的专业人员)并非上策。给一个失控的项目增加人员如同“火上浇油”。

　　2.风险管理的正式程度
　　正式性不仅是指要编制许多正式文件，它的关键内涵是结构，理解这一点有助于我们有效利用时间。风险管理过程的效果很大程度上取决于它提出正确问题的能力，而正式性、规范化正是为了解决这个问题而提出来的。