前言：本站為你精心整理了互聯網項目監理范文，希望能為你的創作提供參考價值，我們的客服老師可以幫助你提供個性化的參考范文，歡迎咨詢。

調查表明，大約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個月上線。

但即便如此，在最后系統正式運行時，該市社保中心CallCenter最多一個小時有5萬個咨詢電話，這個數目太大了，當時整個電話都癱瘓了，連電話局都來找麻煩。一個不成熟的系統上線將是一場災難

阻礙項目成功的因素很多，不僅是開發方的利益因素，用戶方人員的個人利益或者用戶方內部小團體的利益有些時候也會不同于用戶方的整體利益。

總之，在信息化建設中，存在著兩個利益主體：用戶方和承建方，并且在兩方之間存在一個合同關系。由于雙方在技術和業務上的信息互不對稱，就很有可能發生通過損害對方使自己受益的事情。作為委托人的用戶方要改變自己的信息不對稱地位，就需要設計一套機制和合同來激勵或約束作為人的開發方。聘請專業公司提咨詢和監理供服務就是委托人采取的一種行之有效的對策。

事實上，不僅電子政務需要監理、咨詢服務，銀行、電信以及其他有大型復雜應用項目的企業也有著同樣的需求，不久前筆者曾經參與了一家銀行的網上銀行系統建設，紛亂的場面使我對這一點有了更加深切的體會。當然，國內IT監理行業同樣也仍處于稚嫩狀態，從業者更多地集中于綜合布線、網絡系統、弱電系統等與建筑工程類似的項目上，做過大型復雜應用系統工程監理的還寥寥無幾。

最后，對于甲方，掌握PMI的項目管理知識體系與SEI的SA-CMM也是絕對有益的。【SEISA-CMM（SoftwareAcquisitionCapabilityMaturityModel，軟件采辦能力成熟度模型），它是專為需要采購或分包軟件系統的公司或組織設計的能力成熟度模型，用來評估、改善或控制軟件系統的獲取過程。與通常所說的SW-CMM不同的是，SA-CMM關注的是軟件購買者的軟件能力成熟度而不是軟件系統開發商的軟件能力成熟度。軟件采辦能力成熟度模型也分為5級：初始級、可重復級、已定義級、定量管理級、優化級，適用于軟件生命周期的各個階段，包括維護過程。】