浅析IT项目监理工作意义

　　调查表明，大约70%的企业IT项目超出预定的开发周期，大型项目平均超出计划交付时间20%～50%，90%以上的软件项目开发费用超出预算，并且项目越大，超出项目计划的程度越高。如何避免并减少潜伏在项目中的各种失控风险，提高项目成功率，成为所有IT项目负责人最关心的话题。

　　因而，一种用来规避这些风险的管理机制——IT监理正在我国逐步蓬勃开展。工程建设监理制是是国际上确保工程项目质量和进度的一种通行惯例和行之有效的方法。下边将结合案例从三个角度对其作用与意义加以具体剖析：

　　一、事前控制：确定项目计划与总体方案；发现并预警问题，预防危险于损害发生之前

　　相较于事中、事后控制，事前控制成本最低、效果最明显，该项工作能否得到有效开展对于项目成败经常是决定性的。

　　项目管理与项目监理对于事前控制的范畴比较相近，监理的主要关注点为：审核与评估承包商的项目计划、总体方案、项目管理方法、质量控制体系，发现其中的隐患及时向用户方与承建方通报、预警。

　　案例一：某市经济开发区电子政务项目——PM问题

　　经济开发区内驻有多家世界500强企业，总投资额上百亿。为了进一步改善开发区的软环境，为企业提供优良的政府服务，开发区管委会投入了大量资金进行了电子政务系统的建设。国内一家知名的系统集成商，承接了该项目。

　　监理方在评审其提交的项目计划中发现其中的项目组织计划有重大隐患，尤其是项目经理的背景、经验与能力明显不符合该经济开发区电子政务这样一个大型工程项目的需求。

　　为此，监理方正式向用户方开发区管委会与承建方提交了项目预警报告，经过协商与考察，承建方承认了自己的错误并及时更换了合格的项目经理。

　　一些很有名气的院校和公司承接IT项目建设业务之后，由于各种业务量太大，对其中一些项目投入精力不够，雇请一些新手作项目、甚至于担任项目经理，对用户非常不负责任。而项目经理的优劣对于一个项目的成败有相当重要的的意义。不合格的项目经理在职一天，项目就向失败走向一步，而这对甲乙双方都是一种灾难。

　　同一个缺陷在早期与晚期的解决代价与造成损害是有数量级差别的，项目前期的小问题在收尾时可能就会演变成致命错误。正因如此，国家电子政务监理规范制定组的专家一致认为，监理方应该在工程招标阶段就开始介入项目。但由于一些众所周知的原因，国内IT项目监理方经常要在项目中期（实施阶段）才能介入，而错过了事前控制的时机，项目也往往变得积重难返。

　　大量项目失败的根源都可以追溯到项目启动时期，选用不合格的项目经理只是其中一例，常见的典型问题有：

　　 需求分析不到位：用户未能清晰完整地表达自己的需求或者承建方未能充分地领会、挖掘出用户的真实需求，设计与开发工作就贸然开始

　　 总体方案存在漏洞：方案缺乏可行性、可扩展性、可维护性，性能价格比差、无法与现有系统集成等等。比如，很多承建方还往往从自身角度出发来选用技术先进、功能完备的系统，并不充分考虑系统的应用性和现行结构的容纳性问题。

　　 多个开发商的协调与管理：一个典型的灾难场景就是，由于在系统前期未作周密规划与协调，各子系统开发完毕后无法通过联调测试，排查原因后发现问题产生在设计阶段，为此必须修改相关子系统的设计并重新开发，而此时项目周期已近Deadline、预算也所剩无几….。这给甲乙双方的压力都很巨大，各开发商为自身利益着想，也会就技术与业务细节纠缠不清。

　　这里需要补充解释一下监理方与专家委员会的区别，二者都是促进项目成功的有效手段，但重点互有不同，这是由其各自特点决定的。专家委员会成员都是某一领域的专家，有着繁重的本职公务，参与项目只能是短期的、临时性的，不可能对用户需求、项目背景、现有系统以及技术与业务知识有深入地了解与研究，因此在讨论项目过程中的问题与涉及项目背景知识以及业务与技术细节的问题时往往力不从心。专家组更适合对与项目具体情况关系不密切的重大问题或一些绝对性指标做出决策与判断。

　　二、事中控制：确保项目依照既定方案进行；推动并跟踪问题的解决

　　在土木工程项目监理中，此阶段的主要问题是防止偷工减料，杜绝豆腐渣工程。IT监理也同样：

　　一方面，由于信息化热潮的影响，信息化工程承建商往往不顾自己的能力、信誉、资质状况，眼中只看到信息化工程项目投资额度大、利润高，“把项目争取到手”成为了承建商们追求的首要目标。

　　另一方面，随着IT技术的飞速发展，信息系统的规模越来越大、应用日趋复杂而用户能力与水平却提高有限，鸿沟越来越宽。由于用户方在项目管理、IT技术和工程经验方面的不足，许多IT项目的建设过程基本上都是IT公司说了算，对如何入手，如何实施，用户了解得很少，用户一厢情愿地将信息化规划和实施希望寄托在IT承建商身上。

　　一些IT公司正是利用这种信息的不对称，在招标中拼命压低价格争标书，但在实际建设中却以各种借口搪塞用户、以各种手段欺骗、蒙蔽用户或要用户加钱，使项目陷入进退两难的境地，出了问题则百般推卸责任，要么说用户当时没有说清楚，要么说用户水平太低不会用，最后使用户蒙受巨大的损失。

　　案例二：某重大政府信息化系统工程——故障问题

　　该项目为期三年，投资数亿元人民币，项目情况非常复杂、涉及单位众多（数百家政府机构与事业单位与开发这些单位原有系统的数十家软件开发商），而且时间紧、任务急，使得系统建设难度极大，而同时由于其又关系到该市数百万市民的切身利益，若有差池不仅会给国家和人民造成巨大的损害，而且也将影响到社会的稳定。

　　2002年初该系统中心服务器发生重大故障，由于系统采用了集中处理的体系结构，全部网点均陷于瘫痪。

　　监理公司立即督促工程总指挥部启动了紧急故障处理程序，成立了由各开发商参加的紧急故障处理小组，并由其对故障及时进行排查，分析和处理。但由于事故责任重大，各开发商为保护自己，在现场发生了激烈争执，故障处理小组工作陷于停滞。

　　由于该系统关系着百姓利益，每拖延一天都会给政府和社会造成巨大的损害。为此，监理公司在征得工程总指挥部的同意后，出面保留了事故现场的数据，中止了纷争，并督促、协调各开发商及时将系统恢复。

　　系统运行正常后，监理方认为隐患尚未排除，系统仍然可能随时出事，一方面督促工程总指挥部加大对系统的监控力度与快速反应能力、提前开始防灾中心与备用系统的建设，一方面先后多次召集各开发商与设备供应商HP、Oracle对故障原因进行分析、排查，最终几个月后Oracle公司公布了其OPS系统的一个Bug与相应的Patch，问题得以最终排除。

　　几个月后，系统再次出现故障，两个业务量最大的分中心业务长达一周无法正常运行。开发方坚持认为不是软件失误产生的问题，而是业务人员的操作问题，具体原因可能包括操作员对电脑的使用水平较低、对政策实施办法的理解不到位、操作前的培训不够、时间紧工作量大情况下而出现疏漏等。并同时声称使系统恢复正常难度较大，需要花费大量人力物力。

　　监理方立即从公司总部借调了技术专家进行实地调研，结果发现，每季度末系统均有一次大规模的汇总工作，但该模块一直不稳定，前几次均是有开发方人员现场支持下完成，这次故障正是由于开发方停止了技术支持服务以至于业务人员操作失误所造成。最终，在经过用户方领导、监理方的积极协调后，开发方技术人员只花了1个小时即将故障排除。

　　该事件发生的背景原因是：开发方为进入此工程，在一期投标中不惜亏本压低价格并最终获得开发与维护两个合同，但由于有消息传言此项目二期将改换为其他公司，故此开发方用此下策以要挟用户。

　　尽管项目失控的原因多种多样,但可以明确的是，用户本身需要在项目中肩负判断取舍的责任，不论是在事前的项目规划和咨询，还是在项目实施之中的细节。但这往往是用户方之力所不能及。

　　在本案例中，主要由政府官员组成的工程总指挥部显然并不能完全承担这一任务，尤其当多家开发方为逃避责任就技术细节各执一词、互不相让时。同时因为涉及到很多复杂的项目背景情况与大量的业务知识，项目外部的计算机专家一时之间也无法发挥作用。

　　此时，监理方由于具备丰富的工程管理经验、相当的技术能力，加之熟悉项目的背景情况与业务流程，从而发挥了关键性的作用。

　　同时，本案例也进一步说明了事前控制的重要，尤其是项目风险控制机制的建设、多分包商的管理与协调。

　　三、事后控制：评估确认项目实现预定目标；防止同类问题再次发生

　　事后控制的作用是采用相应补救措施，防止损失扩大，并预防同类问题再次发生。

　　测试、验收是常见的事后控制方式。其意义不仅在于确认承建方完成了预定的任务，更在于发现问题和隐患，减少进一步的损失（软件的Bug出现在开发工作完成后，是一种既成损失，无法减少或弥补，在测试中发现并修正它只是防止了损失的进一步扩大，如果在上线运行后才发现就会造成更严重的损失）

　　案例三：某市社会保障信息系统工程——上线问题

　　该项目服务于某市数百万年龄超过16岁的城镇户口居民，其项目性质与特点类似于案例二，关乎百姓生活、社会安定，工程浩大而复杂，持续数年。

　　由于项目旷日持久，各承建商为尽快收回项目款，在系统尚未成熟、稳定的情况下，多次提出上线申请，同时采用各种手段积极推动用户方的政府经办人员，并获得相当一批中层人员的支持。

　　但是，监理方经过对系统状态的评估审计，并在分析了贸然上线的利弊后，认定系统不符合上线条件。为此他们顶住了重重压力，先后两次一票否决了系统的上线请求，使系统推迟了8个月上线。

　　但即便如此，在最后系统正式运行时，该市社保中心Call Center最多一个小时有5万个咨询电话，这个数目太大了，当时整个电话都瘫痪了，连电话局都来找麻烦。一个不成熟的系统上线将是一场灾难

　　阻碍项目成功的因素很多，不仅是开发方的利益因素，用户方人员的个人利益或者用户方内部小团体的利益有些时候也会不同于用户方的整体利益。

　　总之，在信息化建设中，存在着两个利益主体：用户方和承建方，并且在两方之间存在一个合同关系。由于双方在技术和业务上的信息互不对称，就很有可能发生通过损害对方使自己受益的事情。作为委托人的用户方要改变自己的信息不对称地位，就需要设计一套机制和合同来激励或约束作为代理人的开发方。聘请专业公司提咨询和监理供服务就是委托人采取的一种行之有效的对策。

　　事实上，不仅电子政务需要监理、咨询服务，银行、电信以及其他有大型复杂应用项目的企业也有着同样的需求，不久前笔者曾经参与了一家银行的网上银行系统建设，纷乱的场面使我对这一点有了更加深切的体会。当然，国内IT监理行业同样也仍处于稚嫩状态，从业者更多地集中于综合布线、网络系统、弱电系统等与建筑工程类似的项目上，做过大型复杂应用系统工程监理的还寥寥无几。

　　最后，对于甲方，掌握PMI的项目管理知识体系与SEI的SA-CMM也是绝对有益的。【SEI SA-CMM（Software Acquisition Capability Maturity Model，软件采办能力成熟度模型），它是专为需要采购或分包软件系统的公司或组织设计的能力成熟度模型，用来评估、改善或控制软件系统的获取过程。与通常所说的SW-CMM不同的是，SA-CMM关注的是软件购买者的软件能力成熟度而不是软件系统开发商的软件能力成熟度。软件采办能力成熟度模型也分为5级：初始级、可重复级、已定义级、定量管理级、优化级，适用于软件生命周期的各个阶段，包括维护过程。】

来源:项目管理者联盟[mypm.net]

　　因而，一种用来规避这些风险的管理机制——IT监理正在我国逐步蓬勃开展。工程建设监理制是是国际上确保工程项目质量和进度的一种通行惯例和行之有效的方法。下边将结合案例从三个角度对其作用与意义加以具体剖析：

　　一、事前控制：确定项目计划与总体方案；发现并预警问题，预防危险于损害发生之前

　　相较于事中、事后控制，事前控制成本最低、效果最明显，该项工作能否得到有效开展对于项目成败经常是决定性的。

　　项目管理与项目监理对于事前控制的范畴比较相近，监理的主要关注点为：审核与评估承包商的项目计划、总体方案、项目管理方法、质量控制体系，发现其中的隐患及时向用户方与承建方通报、预警。

　　案例一：某市经济开发区电子政务项目——PM问题

　　经济开发区内驻有多家世界500强企业，总投资额上百亿。为了进一步改善开发区的软环境，为企业提供优良的政府服务，开发区管委会投入了大量资金进行了电子政务系统的建设。国内一家知名的系统集成商，承接了该项目。

　　监理方在评审其提交的项目计划中发现其中的项目组织计划有重大隐患，尤其是项目经理的背景、经验与能力明显不符合该经济开发区电子政务这样一个大型工程项目的需求。

　　为此，监理方正式向用户方开发区管委会与承建方提交了项目预警报告，经过协商与考察，承建方承认了自己的错误并及时更换了合格的项目经理。

　　一些很有名气的院校和公司承接IT项目建设业务之后，由于各种业务量太大，对其中一些项目投入精力不够，雇请一些新手作项目、甚至于担任项目经理，对用户非常不负责任。而项目经理的优劣对于一个项目的成败有相当重要的的意义。不合格的项目经理在职一天，项目就向失败走向一步，而这对甲乙双方都是一种灾难。

　　同一个缺陷在早期与晚期的解决代价与造成损害是有数量级差别的，项目前期的小问题在收尾时可能就会演变成致命错误。正因如此，国家电子政务监理规范制定组的专家一致认为，监理方应该在工程招标阶段就开始介入项目。但由于一些众所周知的原因，国内IT项目监理方经常要在项目中期（实施阶段）才能介入，而错过了事前控制的时机，项目也往往变得积重难返。

　　大量项目失败的根源都可以追溯到项目启动时期，选用不合格的项目经理只是其中一例，常见的典型问题有：

　　 需求分析不到位：用户未能清晰完整地表达自己的需求或者承建方未能充分地领会、挖掘出用户的真实需求，设计与开发工作就贸然开始

　　 总体方案存在漏洞：方案缺乏可行性、可扩展性、可维护性，性能价格比差、无法与现有系统集成等等。比如，很多承建方还往往从自身角度出发来选用技术先进、功能完备的系统，并不充分考虑系统的应用性和现行结构的容纳性问题。

　　 多个开发商的协调与管理：一个典型的灾难场景就是，由于在系统前期未作周密规划与协调，各子系统开发完毕后无法通过联调测试，排查原因后发现问题产生在设计阶段，为此必须修改相关子系统的设计并重新开发，而此时项目周期已近Deadline、预算也所剩无几….。这给甲乙双方的压力都很巨大，各开发商为自身利益着想，也会就技术与业务细节纠缠不清。

　　这里需要补充解释一下监理方与专家委员会的区别，二者都是促进项目成功的有效手段，但重点互有不同，这是由其各自特点决定的。专家委员会成员都是某一领域的专家，有着繁重的本职公务，参与项目只能是短期的、临时性的，不可能对用户需求、项目背景、现有系统以及技术与业务知识有深入地了解与研究，因此在讨论项目过程中的问题与涉及项目背景知识以及业务与技术细节的问题时往往力不从心。专家组更适合对与项目具体情况关系不密切的重大问题或一些绝对性指标做出决策与判断。

　　二、事中控制：确保项目依照既定方案进行；推动并跟踪问题的解决

　　在土木工程项目监理中，此阶段的主要问题是防止偷工减料，杜绝豆腐渣工程。IT监理也同样：

　　一方面，由于信息化热潮的影响，信息化工程承建商往往不顾自己的能力、信誉、资质状况，眼中只看到信息化工程项目投资额度大、利润高，“把项目争取到手”成为了承建商们追求的首要目标。

　　另一方面，随着IT技术的飞速发展，信息系统的规模越来越大、应用日趋复杂而用户能力与水平却提高有限，鸿沟越来越宽。由于用户方在项目管理、IT技术和工程经验方面的不足，许多IT项目的建设过程基本上都是IT公司说了算，对如何入手，如何实施，用户了解得很少，用户一厢情愿地将信息化规划和实施希望寄托在IT承建商身上。

　　一些IT公司正是利用这种信息的不对称，在招标中拼命压低价格争标书，但在实际建设中却以各种借口搪塞用户、以各种手段欺骗、蒙蔽用户或要用户加钱，使项目陷入进退两难的境地，出了问题则百般推卸责任，要么说用户当时没有说清楚，要么说用户水平太低不会用，最后使用户蒙受巨大的损失。

　　案例二：某重大政府信息化系统工程——故障问题

　　该项目为期三年，投资数亿元人民币，项目情况非常复杂、涉及单位众多（数百家政府机构与事业单位与开发这些单位原有系统的数十家软件开发商），而且时间紧、任务急，使得系统建设难度极大，而同时由于其又关系到该市数百万市民的切身利益，若有差池不仅会给国家和人民造成巨大的损害，而且也将影响到社会的稳定。

　　2002年初该系统中心服务器发生重大故障，由于系统采用了集中处理的体系结构，全部网点均陷于瘫痪。

　　监理公司立即督促工程总指挥部启动了紧急故障处理程序，成立了由各开发商参加的紧急故障处理小组，并由其对故障及时进行排查，分析和处理。但由于事故责任重大，各开发商为保护自己，在现场发生了激烈争执，故障处理小组工作陷于停滞。

　　由于该系统关系着百姓利益，每拖延一天都会给政府和社会造成巨大的损害。为此，监理公司在征得工程总指挥部的同意后，出面保留了事故现场的数据，中止了纷争，并督促、协调各开发商及时将系统恢复。

　　系统运行正常后，监理方认为隐患尚未排除，系统仍然可能随时出事，一方面督促工程总指挥部加大对系统的监控力度与快速反应能力、提前开始防灾中心与备用系统的建设，一方面先后多次召集各开发商与设备供应商HP、Oracle对故障原因进行分析、排查，最终几个月后Oracle公司公布了其OPS系统的一个Bug与相应的Patch，问题得以最终排除。

　　几个月后，系统再次出现故障，两个业务量最大的分中心业务长达一周无法正常运行。开发方坚持认为不是软件失误产生的问题，而是业务人员的操作问题，具体原因可能包括操作员对电脑的使用水平较低、对政策实施办法的理解不到位、操作前的培训不够、时间紧工作量大情况下而出现疏漏等。并同时声称使系统恢复正常难度较大，需要花费大量人力物力。

　　监理方立即从公司总部借调了技术专家进行实地调研，结果发现，每季度末系统均有一次大规模的汇总工作，但该模块一直不稳定，前几次均是有开发方人员现场支持下完成，这次故障正是由于开发方停止了技术支持服务以至于业务人员操作失误所造成。最终，在经过用户方领导、监理方的积极协调后，开发方技术人员只花了1个小时即将故障排除。

　　该事件发生的背景原因是：开发方为进入此工程，在一期投标中不惜亏本压低价格并最终获得开发与维护两个合同，但由于有消息传言此项目二期将改换为其他公司，故此开发方用此下策以要挟用户。

　　尽管项目失控的原因多种多样,但可以明确的是，用户本身需要在项目中肩负判断取舍的责任，不论是在事前的项目规划和咨询，还是在项目实施之中的细节。但这往往是用户方之力所不能及。

　　在本案例中，主要由政府官员组成的工程总指挥部显然并不能完全承担这一任务，尤其当多家开发方为逃避责任就技术细节各执一词、互不相让时。同时因为涉及到很多复杂的项目背景情况与大量的业务知识，项目外部的计算机专家一时之间也无法发挥作用。

　　此时，监理方由于具备丰富的工程管理经验、相当的技术能力，加之熟悉项目的背景情况与业务流程，从而发挥了关键性的作用。

　　同时，本案例也进一步说明了事前控制的重要，尤其是项目风险控制机制的建设、多分包商的管理与协调。

　　三、事后控制：评估确认项目实现预定目标；防止同类问题再次发生

　　事后控制的作用是采用相应补救措施，防止损失扩大，并预防同类问题再次发生。

　　测试、验收是常见的事后控制方式。其意义不仅在于确认承建方完成了预定的任务，更在于发现问题和隐患，减少进一步的损失（软件的Bug出现在开发工作完成后，是一种既成损失，无法减少或弥补，在测试中发现并修正它只是防止了损失的进一步扩大，如果在上线运行后才发现就会造成更严重的损失）

　　案例三：某市社会保障信息系统工程——上线问题

　　该项目服务于某市数百万年龄超过16岁的城镇户口居民，其项目性质与特点类似于案例二，关乎百姓生活、社会安定，工程浩大而复杂，持续数年。

　　由于项目旷日持久，各承建商为尽快收回项目款，在系统尚未成熟、稳定的情况下，多次提出上线申请，同时采用各种手段积极推动用户方的政府经办人员，并获得相当一批中层人员的支持。

　　但是，监理方经过对系统状态的评估审计，并在分析了贸然上线的利弊后，认定系统不符合上线条件。为此他们顶住了重重压力，先后两次一票否决了系统的上线请求，使系统推迟了8个月上线。

　　但即便如此，在最后系统正式运行时，该市社保中心Call Center最多一个小时有5万个咨询电话，这个数目太大了，当时整个电话都瘫痪了，连电话局都来找麻烦。一个不成熟的系统上线将是一场灾难

　　阻碍项目成功的因素很多，不仅是开发方的利益因素，用户方人员的个人利益或者用户方内部小团体的利益有些时候也会不同于用户方的整体利益。

　　总之，在信息化建设中，存在着两个利益主体：用户方和承建方，并且在两方之间存在一个合同关系。由于双方在技术和业务上的信息互不对称，就很有可能发生通过损害对方使自己受益的事情。作为委托人的用户方要改变自己的信息不对称地位，就需要设计一套机制和合同来激励或约束作为代理人的开发方。聘请专业公司提咨询和监理供服务就是委托人采取的一种行之有效的对策。

　　事实上，不仅电子政务需要监理、咨询服务，银行、电信以及其他有大型复杂应用项目的企业也有着同样的需求，不久前笔者曾经参与了一家银行的网上银行系统建设，纷乱的场面使我对这一点有了更加深切的体会。当然，国内IT监理行业同样也仍处于稚嫩状态，从业者更多地集中于综合布线、网络系统、弱电系统等与建筑工程类似的项目上，做过大型复杂应用系统工程监理的还寥寥无几。

　　最后，对于甲方，掌握PMI的项目管理知识体系与SEI的SA-CMM也是绝对有益的。【SEI SA-CMM（Software Acquisition Capability Maturity Model，软件采办能力成熟度模型），它是专为需要采购或分包软件系统的公司或组织设计的能力成熟度模型，用来评估、改善或控制软件系统的获取过程。与通常所说的SW-CMM不同的是，SA-CMM关注的是软件购买者的软件能力成熟度而不是软件系统开发商的软件能力成熟度。软件采办能力成熟度模型也分为5级：初始级、可重复级、已定义级、定量管理级、优化级，适用于软件生命周期的各个阶段，包括维护过程。】

来源:项目管理者联盟[mypm.net]