从案例材料可以看出，员工经过培训之后，他们似乎可以对系统进行操作了，但他们对系统并没有很深入的理解，不知道系统数据是怎么来的，数据之间是什么关系。如果没有对系统的完整理解，就是对系统的知其然而不其所以然，这种情况下，员工就不可能独立主动地思考和解决系统中发生的各种问题，一旦发生误操作，往往会造成系统数据的一致性、准确性和完整性问题，在以数据为基础的信息系统中，数据错误有时可能导致整个系统的失真。此外，大家觉得咨询公司的项目实施文档太复杂，看不懂;使用的过程中，发现手工帐和系统帐对不起来，他们不知道是操作不当，还是方案有问题;即使是作为财务总监的格雷斯，虽然他对业务问题了如指掌，但是业务到了系统中以后是如何运作的，他心里也没有底。员工经过培训和指导可以独立操作系统，这并不表明他们已经可以驾御所有的系统问题，这个时候让实施顾问离开显然是不合适的。

　　这些问题表明，项目领导层在项目范围和质量管理方面可能存在以下三个方面的问题：1、项目在员工培训的内容与要求、项目技术文档、项目实施文档以及其他实施成果等阶段性或最终交付成果方面没有作出清楚的定义与沟通;2、没有严格履行项目的质量计划与控制措施，3、没有进行完整的项目阶段控制点的范围验收核实和范围变更控制。由于这些问题没有及时发现并得到适当解决，项目绩效的负偏差不断扩大，系统累计的错误越来越多，以至于根本查不出错误的源头所在，最终整个系统的数据自然就乱了。

　　3、项目风险管理问题

　　从案例中可以发现，执行过程中发生了不少令格雷斯始料不及的事情，比如，咨询公司提交方案和系统上线已经12个月后，公司财务部门还是两条腿走路;有些员工忍受不了白天手工做帐、晚上还要将数据录入系统这样的高强度工作而选择了离职;在没有手工帐可以核对的情况下，系统数据间的勾稽关系出现了混乱，不知道这些数据是否正确，用户对系统越来越没底。如果当初知道会发生这些意外的话，应该可以通过适当的方式解决这些问题，这就是一个风险管理的问题(图3、风险管理的过程)。

　　首先，项目组需要建立风险管理的意识，制定风险管理职责和相应的管理计划，风险管理意识的有无往往对这种变革项目产生很大的影响;然后按照计划识别项目过程中可能发生的风险，通常项目工作分解结构是识别项目风险的有效工具，通过该工具可以识别提交各种交付成果过程中可能发生的风险或者可能出现的困难，比如本案例中，当格雷斯为了吸取教训决定破釜沉舟，不给员工留任何后路，下令所有的员工必须丢掉手工帐，迫使他们去彻底理解系统的时候，这样做最终会发生怎样的风险呢?

　　识别风险后并不是马上就制定风险应对计划，而是首先对这些识别出来的风险进行分析和排序，识别出需要优先考虑的风险，至少需要重点考虑排在前十位的风险事项，成熟的项目管理团队针对特定的项目通常都会建立起经过排序的风险检查表，比如说许多公司将领导与员工参与度作为管理信息化项目最大的风险，这实际上也是造成所有变革类项目失败的最大风险;制定风险应对计划并执行是项目成功的关键。对该项目而言，风险应对措施至少应该包括选择恰当的手工帐和自动帐并行的时间、建立合理的数据稽核机制、咨询顾问离开时间或离开方式选择、问题识别和解决机制以防止问题扩大或重复发生、建立领导和员工的参与计划并确保用户对系统的正确掌握和理解等。最后要对应对措施的有效性以及风险发生的变化进行全过程监控。

　　总之，困扰格雷斯的是一个与项目管理和变革管理相关的典型问题，解决这些问题需要有具体可操作的实施方法论的指导，其中范围管理、质量管理与风险管理是与项目管理有关的三个方面，这并不是说项目管理的其它方面(如进度管理)不重要，而只是关注的焦点不同罢了。同时要注意这是一个复杂的变革项目，需要发现变革项目中一些规律性的问题，采用正确的方法加以解决。如果要建议几点具体的行动步骤，应该可以包括如下几点：1、重新进行项目干系人分析，并制定相应的管理计划;2、制定问题的识别与解决机制，防止类似的问题扩大化或者重复发生;3、长时间外包某些技术性很强的实施工作以转移风险;4、对项目的交付成果加强质量控制和范围验收核实工作。