CIOI:正如刘海滨所说，CIO应该对项目潜在的风险有所预知，并制定相应的应对方案。那么，CIO该如何预知项目中可能出现的风险呢？

　　刘海滨：对项目潜在风险的分析，经验是很重要的一个方面。不仅是CIO的经验，项目核心成员的经验也很重要。CIO应该与项目核心成员进行讨论，开展头脑风暴，找出项目中的潜在风险。同时，也可以聘请一些比较高级的项目管理人员或专家对项目提出一些建议和想法。

　　还有一个方法，就是通过知识管理的手段，在公司内部或者外部的知识库中，寻找曾经发生过的类似项目，看看他们曾经发生过哪些问题和风险。高爱琴：初期制订项目计划时，我们会以各种方式评估项目风险并制定对策，却经常忘记要时时去更新执行后的项目实际状态，忽略了新风险出现的警示或未能尽全力降低已发现的威胁，导致项目执行逐步陷入窘境，这是一种常见的风险管理缺陷，CIO不可不注意。

　　另外，有经验的CIO会由一些不寻常的信息或内外部环境变化判断出可能出现的风险，对此风险进行辨识与评估，与项目经理共同安排应对的策略，在负面威胁尚未实现之前先降低其可能发生的几率，或减少对项目施行的冲击。

　　CIOI:如果潜在的风险变成了项目群实施中真正的威胁，最直接的后果就是造成项目预算或者进度与计划的出入，如果这种情况真的发生了，又该如何处理？

　　高爱琴：无论是预算或时间的出入，都要了解背后真正造成出入的原因，才能有效克服这些难题。项目群之间彼此相关，预算或时间的出入未必是项目本身造成的，也可能是受到其他项目的影响，项目经理应先找到导致偏离的根本原因，迅速寻求CIO的协助。预算与时间都是CIO掌握的项目核心，越早发现实际与规划的出入对异常的矫正越有效力。若是忽略了偏差分析的重要性可能会形成巨大的预算或时间出入，使项目陷入恶性循环，只得借助更多资源的投入进行弥补。时间的延迟最常用的克服方法是赶工，由CIO调动其他项目的设备或成员来齐力追赶进度，或是寻求外部厂商的资源来协助解决，虽然成本增加了但风险较低。另一种常见方法是并行法，拉近项目间的时间差来调整资源分配赶上进    管度，这个方法增加的费用较少，但资源理风险会增高，使用时要有所斟酌。预算的超支是IT项目实施中常见的问题，要正确评估项目成本，需要丰富的经验以及需求单位（使用部门）的配合。例如ERP项目，使用者若无法克服以往的旧习惯就容易变成需要大量的定制化开发，项目费用自然高涨。所以预算要能与实际贴切，就要先清楚哪些是影响成本的关键点，保留合理的弹性空间，并严加管控。

　　对于项目群主管来讲，除了要特别关注前面探讨的风险、进度、预算和资源等方面以外，质量也是他们必须关注的，因为质量才是决定项目成败最核心的生命线。那么IT项目群的质量该怎么去控制呢？

　　刘海滨：对项目群的控制，以前大多是从进度、经费预算和资源等方面进行控制，因为这些比较容易量化，控制起来也相对容易。现在，越来越强调对质量进行控制。

　　从我的经验来看，对质量进行控制首先要对质量目标进行层层分解，在分解过程中，尽量把潜在的质量问题消化掉，逐渐减少到最少。在这个过程中，质量计划就显得很重要，要明确按照什么样的方法、措施和手段来保证质量目标。比如，到什么时间点要对项目进行评审、测试，评审或者测试该怎么操作，哪些人参与等，都要有相应的计划。详细的质量计划可以使质量在过程中就能得到保证，而不是发生质量问题之后再去追溯。

　　高爱琴：明确的质量目标、周详的质量测试与实时的质量控制，是项目获得完整质量保证的不二法则。首先在项目规划过程中要注意质量目标是否明确，一般常用质量政策、范畴声明书（SOW）、系统分析书、产出规格书等工具，将IT需求逐步展现为量化目标（例如程序错误率需低于5%等）。在系统开发期间要了解系统稳定性、正确性、完整性、安全性、兼容性等IT特性的发展方向是否正确。项目施行过程中采用检查表（Checklists）检核对质量功能的绩效与达标率，同时避免因为分析不精确、程序重复、用户投诉等因素造成时间与预算的偏差，以维持项目产出质量与项目施行过程的质量。系统开发结束之后，紧接着就是上线前的测试阶段，IT测试方法有很多，但此阶段要注意的是测试程序以及改版过程都需要被完整地记录，因为这些经验对于往后的项目质量规划有相当大的帮助。