为了让项目经理有主动上报问题的动力，老Q修改了原来的问题汇报机制，有三个重要的改变：
■项目中出现重大问题的时候，如果事前项目经理已经汇报上级而未获解决，则上级承担主要责任；如果事前项目经理明知问题却不上报，则项目经理承担主要责任。
■如果项目经理请求直接上级帮助但没有结果，则问题自动升级。项目经理向项目总监上报问题后如果3天内还未解决，则升级到事业部总经理那里；如果1周后还没有解决，则会升级到分管副总裁那里，直到最后升级到CEO。
■为了确保发生事故的时候公司能够第一时间知道，规定重大事故1个小时以内必须上报给公司，上报对象包括从项目总监到CEO的相关人员。这样一来，项目经理主动上报问题的积极性大大提高，因为上报了责任就变成上级的了，而且上级还必须来帮忙，否则上级的上级就知道了，这样的好事何乐而不为呢？
为了确保这个机制的有效执行，老Q还请公司IT部门在项目管理信息系统中增加了问题自动升级的工作流，并与邮件系统连接了起来，问题升级时自动给上级发邮件。
也许是矫枉过正吧，制度执行之后喜忧参半。
好消息是突然之间好像所有项目同时打开了一个口子，大量的“重大问题”从项目组中冒了出来。
坏消息是项目组中无论什么问题都成了“重大问题”，从“笔记本坏了影响项目整体进度”到“关键岗位人员失恋影响工作情绪”都成了重大问题。
因为系统直接与邮箱相连，一时间各级领导的邮箱中都堆满了“重大问题”。虽然“重大问题”鱼龙混杂，但从没想到平静的表面下有这么多问题。这下项目中情况可真够透明的了。不过，也忙坏了各级领导，不断地沟通、过滤、调兵遣将。(www.xing528.com)
面对满满的邮箱，小M苦笑着找到老Q，开玩笑地说：“原来是想让项目经理捂不住问题，现在是我自己捂不住了——问题太多、捂不过来了！”怎么才能防止什么问题都上报呢？这是新课题。
几天之后，老Q再次发通知对问题升级机制进行了补充说明，明确定义了什么才是“重大问题”，以及重大问题该发送给谁（见表9-3）。这样，项目重大问题的上报终于慢慢平稳了。
对于小M和老Q引起的这场混乱，S总还是给予了肯定。凡事有利有弊嘛，现在问题满天飞，总比不期而至的“意外”强。
表9-3 重大问题汇报机制
说明：V—正常 ○—预警 ×—有问题
（续）
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
