胡百师老师经典文章回顾：为什么应该保留TOP 10 风险列表?

为什么应该保留TOP 10 风险列表?
文/胡百师

　　我想大家对“项目管理就是在做风险的管理”这句话一定记忆犹新，这是我在2007年11月29日CSDN举办的“2007软件开发2.0大会”中对项目管理心得的重点建议。一个项目的执行，从起始至结案的各个阶段中均存在不同的风险必须去克服与解决。项目经理在深切地去了解了这些风险之后，要懂得如何去规避。风险的掌控是要防患于未然，这一点在项目管理中对项目经理来说，是十分重要的管理理念。
　　从EssUP的角度来看，EssUP将项目发展过程区分为I（Inception，初始阶段）、E（Elaboration，精制阶段）、C（Construction，建造阶段）、T（Transition，交付阶段）等四个阶段。每一个阶段都有不同的风险必须被管控：
● I阶段：主要是确定项目目标及范围，并确定关键技术可行，控制商业风险。
● E阶段：主要是让计划稳定的执行，控制架构设计与系统设计的风险。
●C阶段：项目已进入大量生产阶段，要注意建构管理并控管项目完成的风险。
●T阶段：主要是进行产品交付的活动（如教育训练、交付文件的整理……等），要控制系统上线的风险。

　　从上面这段话，大家可以清楚得知道：一个项目从开始进行到产品交付（项目验收），每个不同的阶段会遭遇到不同方面的风险挑战，项目经理要想办法去规避各阶段将会发生的风险。以往所谓瀑布式（Waterfall）的开发模式，相关的风险往往要等到即将发生时才会被项目经理注意到，那个时候可以采取相关避险行动的时间与空间都已被压缩。当处理风险的缓冲区域不够伸展时，要么风险的处理会变得很粗糙，不然只有眼睁睁地让“风险”转化成“问题”，我想这绝不是一个项目经理所乐见的。在EssUP中要求项目经理在项目进行之初，就需要把“关键技术”在项目初始阶段做清楚的辨识，将其视为风险去面对，并提出具体可行的避险行动。

　　举个实际的案例。我曾经遇到这么一个项目，它的限制条件之一是“500位使用者可以同时Online使用，每一笔交易的回应时间不可超过三秒”。经过项目小组的内部讨论，大家一致认为这是一个“关键技术”，必须在项目开始时进行验证，以保证我们提供的系统架构是可行的；否则，即使其他客户作业需求被系统开发过程满足，最终整个项目仍然无法通过验收。项目经理当下决定这是一个高优先的商业风险，在确认使用者业务需求的同时，架构设计小组的系统工程师应该完成该“关键技术”的验证。如果无法通过则需对客户提出系统架构变更，进入“变更管理”程序，并应于获得客户同意后进行系统架构调整。若无法通过变更委员会（Change Control Board, CCB）的同意，则项目将面临被终结（Terminate）的危机。后来因为这个风险在项目开始进行时即被提出，而获得了相当充裕的处理时间，得以安全的被规避。试想，如果这个风险在软件已完成系统测试，即将进入与硬件结合进行整体测试的阶段才被发现，那又会是个什么样的状况？我想项目经理可能会被吓出一身冷汗。在思绪混乱、时间紧急的情形下，是很难做出完满的行动计划的。如果因此而铸成大祸，项目经理将难辞其咎。这种不应该发生的“天上掉下来的礼物”，任谁都无法承受。切记：“风险”没有得到适当的处理，一定会变成“问题”，“问题”不去解决就会为项目带来“灾难”。

　　所以对一个项目经理来说，如何保持头脑清楚，能在项目进行的当下，去发现风险、面对风险，进而化解风险是一件十分重要的事。项目进行的时间轴不会因你的思考停顿而停止，请记住“风险是活的，风险是会变化的”。当某一风险被一连串的行动消弥之后，可能会衍生出新的风险，或者是后续行动，这个时候风险清单的内容就做了改变。所以“当下”指的是一个项目的最新状态，每个“当下”都可能面对不同的风险。

　　在我从事项目管理的生涯中，看过太多太多的项目经理对风险管理掉以轻心。严格地说：他们对风险的管控是无知的，是盲目的。大部份的项目经理在一个项目开始之初，都会被要求在项目管理计划（Project Master Plan）或相关文件中提出他对“风险”的“管理计划”。我曾经亲眼见过：有项目经理抄袭别的项目的风险管理计划，或者好不容易把“当下”的风险列出来之后，随便糊弄一下处理对策就交差了事。从风险清单被客户同意的那一天起，就把其中的风险项目束诸高阁不去管他。等到“一个不小心，项目幸运地验收结案”时，再去看看那张所谓的风险清单，还是长得跟项目刚开始时一样，从来不曾移动过。这就是一般不负责任的风险管理。很抱歉，我说错了，这不叫管理，这应该叫打混。

　　一直以来，我都客观地认为：项目管理的核心就是在做风险管理。一个风险管理做得不好的项目，我不认为他的项目会被管理得好，可以如期交付。前面说过“风险是活的，风险是会变化的”，一个优秀项目经理的口袋中，应该随时都可以掏出一张项目当下状况的风险清单（如何界定风险，我们将在下一次探讨），清楚地让自己、让项目成员、让领导甚至让客户知道，目前项目进行的危机在哪里？该如何去规避？让大家放心，即使放不下心也知道要如何去面对。风险管理的重要观念，就是不要让项目的进行充满了“惊吓”与“地雷”，虽然说项目经理要有一颗比一般人更强壮的心脏，但还是让这颗心脏去面对项目其他的挑战吧。

　　为什么应该保留TOP 10风险列表？道理其实很间单，因为处理不当而让项目崩溃的原因，往往都是这“前十大风险”。请项目经理务必记住，TOP 10 风险列表的可变性：它会随着项目的进行而改变，千万不要做一个从头到尾只有一份“供交代用”风险清单的项目经理，不要愧对项目经理的神圣任务。