由于相关的业务流程复杂，环节多，涉及到的单位多，协调困难，谁都不认为自己有问题，甚至出了问题都不知道该向谁反应，结果导致系统的最终服务对象—老百姓的利益受损。僵持了一段时间后，监理方意识到了问题的严重性。经过大量调研，发现在流程中若干环节相对问题集中，而且这几个环节都由一个单位(甲)负责，于是提出问题解决方案，包括详细的处理流程。
两个层次，第一层次是：出了问题将直接向甲单位反应，该单位负责协调相关各方解决问题；第二层次是：成立问题协调小组，成员包括各单位领导，若有甲单位协调解决不了的问题向协调小组汇报，由协调小组协调解决。解决问题的机制建立后，对最终用户来说有了反应问题的场所，各方责任清楚，提高了解决问题的效率，和政府的办事效率，老百姓的利益得到了保障。后来事实证明只有少数问题反应到了协调小组。在这个问题上，监理作用得到充分发挥。
B类问题既然其他各方可以把它解决好，那么此时如果监理方再试图推动的话，会让其他各方感到多余，甚至更糟的话可能会有干涉对方内部工作的嫌疑。比如在某项目中，用户方反应承建方对系统故障排查和服务相应的速度太慢，在这个问题上，承建方没有异议。事实上，问题的存在是由于他们的其他工作太忙而没有顾得上及时解决。因此，对于这个问题上，监理方在态度上立场鲜明，支持用户方的态度。
C类问题同A类一样也有可能体现监理价值，但不同的是，其他各方没有意识到问题的严重性，甚至根本没有注意到问题的存在，这种情况下监理方必须立场鲜明地站出来，并指出问题的隐患，这是监理的职责所在。例如在某项目中，由于用户方的需求改动频繁，而且往往没有给承建方流出合理的时间，造成承建方疲于应付新需求变动而缺少时间完善系统。
此时监理方注意到这个问题是由于缺少规范的需求管理造成的，于是我们拟订出管理制度文件并最终促成各方签署。在监理方多次阐明利害关系之后，各方均认识到需求管理流程被规范后会提高系统建设总体效率，对谁都有好处。
有很多问题在我们初步调研后即发现它们不影响大局，或者向“问题定义”一节中提到的操作适应性等问题，这些问题各方都不关注，也确实不重要，甚至过了一段时间问题的提出者都把这件事忘了。这就是图中表示的D类问题，这类问题自然不用花费很多精力。
4.1问题跟踪
根据问题分类原则确定了监理方策略后，监理方需要跟踪问题发展状况和解决进程。我们的问题跟踪机制总的思路是：建立《问题列表》，所有问题按某一特定的顺序排列，比如提出的时间。每个问题需包括问题编号、提出时间、提出人、描述、重要性级别、解决方案、解决方案批准人、要求解决时间、目前状态等信息。而对于某一具体问题，我们建立《XX问题跟踪表》，目的是记录问题发生、发展、解决整个过程中与问题有关的活动、讨论、决议和监理方观点。
表中应该包括问题编号、活动类型、活动日期、决议、监理方观点等信息。这样做可以为将来撰写问题报告打好基础。《XX问题跟踪表》和《问题列表》通过两个表中某些共同项目建立映射关系，比如问题编号或问题描述，如果是电子文件可以考虑建立超级链接。当然，由问题的重要程度不同，并不是每个具体问题都有必要建立问题跟踪表。
4.2流程说明
根据《问题跟踪表》的内容，每周定期更新《问题列表》的“当前状态”；
如有新问题产生，问题列表将即时更新，并即时产生该问题的《问题跟踪表》；
跟踪一般分为两条线路，即承建方和用户方，因为每个问题都可能涉及到系统和业务两个方面；
每个问题一般由两个人共同跟踪，分别负责承建方和用户方两条线，其中一个是该问题的负责人；
针对重点问题跟踪所获得的全部信息都及时按时间顺序记录在一个确定的问题跟踪表中。《问题跟踪表》和《问题列表》通过两个表中某些共同项目建立映射关系，比如问题编号或问题描述，如果是电子文件可以考虑建立超级链接。；
由问题负责人即时更新《问题跟踪表》，并且每周三下午确定时间更新《问题列表》中的相应问题项目；
5.问题报告
问题报告是在问题的某一阶段监理方对该问题认识的总结，可以是在问题发现阶段、问题解决阶段，也可以在问题解决后。问题报告的对象是监理方的客户，在客户的授权下可以抄送给项目其他相关各方。因此问题报告是监理方客户了解项目进展的重要渠道。
报告的内容应包括对问题的描述，即问题的发生和发展过程，信息来源于《问题跟踪表》，还应包括监理方对问题的分析和监理方建议。
问题报告是监理方客户了解项目进展的重要渠道，监理方应尽量多报告。（责任编辑：黄重来）
<<上一页
1
2
