8.5 案例五：合作項目的風險
   閱讀以下關于信息系統項目管理過程中風險管理方面問題的敘述，回答問題1至問題3。
8.5.1案例場景
    中培信息技術有限公司(Z公司)為某省某運營商建立一個商務業務平臺，并采用合作分成的方式。也就是說所有的投資由Z公司方負擔，商務業務平臺投入商業應用之后運營商從所收取的收入中按照一定的比例跟Z公司作分成。
    同一時間，平臺有兩個軟件公司(Z公司)和Z公司)一起進行建設，設備以及技術均獨立，也就是說同時有兩個平臺提供同一種服務，兩個平臺分別負責不同類型的用戶。
    但是整個項目進行了10個月，并經歷了一個月試用期之后。準備正式投入商業應用的第一天，運營商在沒有任何通知的情況下，將該商務業務平臺上所有的用戶都轉到了Z公司競爭對手Z公司的平臺上去了，也就是停止使用Z公司的商務業務平臺。
    整個項目Z公司投資超過兩百萬，包括軟、硬件，以及各種集成、支持、差旅費用，等等。現在Z公司所有的設備被擱置但不能搬走，并沒有被遺棄，運營商口頭聲稱還會履行合同，按照原來的分成比例給Z公司分成。但是Z公司無法得知每個月的使用情況、用戶多少，所以根本無法知道他們究竟應該拿到多少分成。所以，運營商的口頭承諾根本如同雞肋。
    在出事當天，項目經理王剛呆若木雞。
    【問題1】(8分)
    請用200字以內文字描述該項目存在的主要問題和原因。
    【問題2】(8分)
    請用300字以內文字描述發生這樣的事情，項目經理有沒有責任？如果有責任，那么具體有哪些責任？
    【問題3】(9分)
    請用400字以內文字結合你本人的實際項目經驗，說明如果你是王經理，你覺得應如何避免這樣的事情發生？
8.5.2案例分析
    【問題1】
    類似本案例這種結局的項目很多，風險管理不再只是紙上談兵，而應有具體的量化評估體系，具體的風險應對對策。由此可見國內企業在項目管理的實施上還沒有深入。有很多是整體環境和管理層的問題，但項目經理也具有不可推卸的責任。
    其一，國內企業對項目管理的實施很淺薄：一個普遍現象就是購買所謂專業的項目管理軟件來做項目管理，以為這樣就可以解決一切問題，就很專業很規范了。但企業本身的管理體系和軟件的項目管理思想格格不入，至少沒有融合，或者是根本沒有深入，在這種背景下的項目管理充其量也就是定期搞個報表哄哄領導。所以一旦項目出現任何風險就會岌岌可危。
    其二，項目管理體系不健全：由于企業管理層對項目管理知識的匾乏，導致公司沒有一個比較健全的項目管理體系，正是因為缺乏項目生存環境，所以項目經理們在實施項目的時候四處碰壁，無可奈何。當然這并不是為項目經理推脫責任，這個道理就好像外企的職業經理人空降后全都天折了一樣。別忘了項目經理的權利最重要，項目經理沒有決策權，做什么都白做。
    其三，項目管理的量化時代遲遲沒有到來：這個案例的直接原因就是風險管理的缺乏，如果有一個好的風險預警體系，這種問題應該很早能預料到，能夠增加一些防范措施。我們現在所謂的風險管理只是象征性地列個risk list，沒有一個很好的量化和評估過程，基本只是個文檔。所以這樣的管理都是些面子過程。項目經理的職責是跟蹤監控，那么沒有具體的數據，所謂的監控只能淪為例行公事。
    其實，導致這種狀況的原因可能還有些更深層次的外部因素，比如國內企業目前基本是以市場為導向，而中國處于一種市場經濟的發展階段，市場化并不成熟，各種因素導致了企業為了市場而急于求成，本來就缺乏規范管理的企業就更談不上項目管理了。
    當然種種原因不足以說明我們的項目管理就不能進行了，在這個案例中，項目經理負有不可推卸的責任，你的風險列表里是否已經識別到了這種合同風險或市場風險呢？如果有，那么你是否采取過什么溝通手段和措施。也許你沒有根本解決這個問題權利，但你有努力挽救這種結局的責任和義務。
    【問題2】
    軟件項目風險是指在軟件開發過程中遇到的預算和進度等方面的問題，以及這些問題對軟件項目的影響。軟件項目風險會影響項目計劃的實現，如果項目風險變成現實，就有可能影響項目的進度，增加項目的成本，甚至使軟件項目不能實現。如果對項目進行風險管理，就可以最大限度地減少風險的發生。但是，目前國內的軟件企業不太關心軟件項目的風險管理，結果造成軟件項目經常性的延期、超過預算，甚至失敗。成功的項目管理一般都對項目風險進行了良好的管理。因此任何一個系統開發項目都應將風險管理作為軟件項目管理的重要內容。
    在項目風險管理中，存在多種風險管理方法與工具，軟件項目管理只有找出最適合自己的方法與工具并應用到風險管理中，才能盡量減少軟件項目風險，促進項目的成功。
項目風險管理是指為了達到項目的目標，識別、分配、應對項目生命周期內風險的科學與藝術。項目風險管理的目標是使潛在機會或回報最大化，使潛在風險最小化。風險管理涉及的主要過程包括：風險識別，風險量化，風險應對計劃制定和風險監控，如圖8-3所示。風險識別在項目的開始時就要進行，并在項目執行中不斷進行。就是說，在項目的整個生命周期內，風險識別是一個連續的過程。
    (1)風險識別：風險識別包括確定風險的來源，風險產生的條件，描述其風險特征和確定哪些風險事件有可能影響本項目。風險識別不是一次就可以完成的事，應當在項目的自始至終定期進行。
    (2)風險量化：涉及對風險及風險的相互作用的評估，是衡量風險概率和風險對項目目標影響程度的過程。風險量化的基本內容是確定哪些事件需要制定應對措施。
    (3)風險應對計劃制定：針對風險量化的結果，．為降低項目風險的負面效應制定風險應對策略和技術手段的過程，風險應對計劃依據風險管理計劃、風險排序、風險認知等依據，得出風險應對計劃、剩余風險、次要風險以及為其他過程提供的依據。
    (4)風險監控：涉及整個項目管理過程中的風險進行應對。該過程的輸出包括應對風險的糾正措施，以及風險管理計劃的更新。
每個步驟所使用的工具和方法詳見表8- 1。

    【問題3】
軟件項目的風險無非體現在以下四個方面：需求、技術、成本和進度。IT項目開發中常見的風險有如下幾類：

    1．需求風險
    (l)需求已經成為項目基準，但需求還在繼續變化。
    (2)需求定義欠佳，而進一步的定義會擴展項目范疇。
    (3)添加額外的需求。
    t4)產品定義含混的部分比預期需要更多的時間。
    (5)在做需求中客戶參與不夠。
    (6)缺少有效的需求變化管理過程。
    2．計劃編制風險
    (1)計劃、資源和產品定義全憑客戶或上層領導口頭指令，并且不完全一致。
    (2)計劃是優化的，是“最佳狀態”，但計劃不現實，只能算是“期望狀態”。
    (3)計劃基于使用特定的小組成員，而那個特定的小組成員其實指望不上。
    (4)產品規模(代碼行數、功能點、與前一產品規模的百分比)比估計的要大。
    (5)完成目標日期提前，但沒有相應地調整產品范圍或可用資源。
    (6)涉足不熟悉的產品領域，花費在設計和實現上的時間比預期的要多。
    3.組織和管理風險
    (1)僅由管理層或市場人員進行技術決策，導致計劃進度緩慢，計劃時間延長。
    (2)低效的項目組結構降低生產率。
    (3)管理層審查決策的周期比預期的時間長。
    (4)預算削減，打亂項目計劃。
    (5)管理層做出了打擊項目組織積極性的決定。
    (6)缺乏必要的規范，導致工作失誤與重復工作。
    (7)非技術的第三方的工作(預算批準、設備采購批準、法律方面的審查、安全保證等)時間比預期的延長。
    4.人員風險
    (l)作為先決條件的任務(如培訓及其他項目)不能按時完成。
    (2)開發人員和管理層之間關系不佳，導致決策緩慢，影響全局。
    (3)缺乏激勵措施，士氣低下，降低了生產能力。
    (4)某些人員需要更多的時間適應還不熟悉的軟件工具和環境。
    (5)項目后期加入新的開發人員，需進行培訓并逐漸與現有成員溝通，從而使現有成員的工作效率降低。
    (6)由于項目組成員之間發生沖突，導致溝通不暢、設計欠佳、接口出現錯誤和額外的重復工作。
    (7)不適應工作的成員沒有調離項目組，影響了項目組其他成員的積極性。
    (8)沒有找到項目急需的具有特定技能的人。
    5．開發環境風險
    (1)設施未及時到位。
    (2)設施雖到位，但不配套，如沒有電話、網線、辦公用品等。
    (3)設施擁擠、雜亂或者破損。
    (4)開發工具未及時到位。
    (5)開發工具不如期望的那樣有效，開發人員需要時間創建工作環境或者切換新的工具。
    (6)新的開發工具的學習期比預期的長，內容繁多。
    6.客戶風險
    (1)客戶對于最后交付的產品不滿意，要求重新設計和重做。
    (2)客戶的意見未被采納，造成產品最終無法滿足用戶要求，因而必須重做。
    (3)客戶對規劃、原型和規格的審核決策周期比預期的要長。
    t4)客戶沒有或不能參與規劃、原型和規格階段的審核，導致需求不穩定和產品生產周期的變更。
    (5)客戶答復的時間(如回答或澄清與需求相關問題的時間)比預期長。
    (6)客戶提供的組件質量欠佳，導致額外的測試、設計和集成工作，以及額外的客戶關系管理工作。
    7．產品風險
    (1)矯正質量低下的不可接受的產品，需要比預期更多的測試、設計和實現工作。
    (2)開發額外的不需要的功能(鍍金)，延長了計劃進度。
    (3)嚴格要求與現有系統兼容，需要進行比預期更多的測試、設計和實現工作。
    (4)要求與其他系統或不受本項目組控制的系統相連，導致無法預料的設計、實現和測試工作。
    (5)在不熟悉或未經檢驗的軟件和硬件環境中運行所產生的未預料到的問題。
    (6)開發一種全新的模塊將比預期花費更長的時間。
    (7)依賴正在開發中的技術將延長計劃進度。
    8.設計和實現風險
    (1)設計質量低下，導致重復設計。
    (2)一些必要的功能無法使用現有的代碼庫實現，開發人員必須使用新的庫或者自行開發新的功能。
    (3)代碼和庫質量低下，導致需要進行額外的測試，修正錯誤或重新制作。
    (4)過高估計了增強型工具對計劃進度的節省量。
    (5)分別開發的模塊無法有效集成，需要重新設計或制作。
    9．過程風險
    (1)大量的紙面工作導致進程比預期的慢。
    (2)前期的質量保證行為不真實，導致后期的重復工作。
    (3)太不正規(缺乏遵循軟件開發策略和標準的意識)，導致溝通不足，質量欠佳，甚至需重新開發。
    (4)過于正規(教條地堅持軟件開發策略和標準)，導致過多耗時于無用的工作。
    (5)向管理層撰寫進程報告占用開發人員的時間比預期的多。
    (6)風險管理粗心，導致未能發現重大的項目風險。
    軟件項目管理從某種意義上講，就是風險管理。我們盡量去定義明確不變的需求，以便進行計劃并高效管理，但商業環境總是快速變化的，甚至是無序的變化。所以，軟件企業在進行項目管理的過程中，必須采用適合自己的風險管理方法進行風險管理，以確保軟件項目在規定的預算和期限內完成項目。
8.5.3參考答案
    【問題1】(8分)
    首先，Z公司由于被項目“合作分成”的利益所迷惑，所以對項目的可行性分析和風險分析做得很不夠，才會出現全額承擔項目費用的情況，將自己的成本控制得非常高，所以項目經理、行政主管都有錯。
    其次，雖然Z公司自身承擔高額的成本，但對于合同條款的管理沒有嚴格約束，這是導致運營商出現平臺停用后沒有足夠法律條款約束其的后果。所以律師、項目經理需要反省。
    最后，公司需要對項目的技術進一步審核，修正存在的問題，以免運營商提出種種沒有達標的借口，并整理相關合同簽訂時，項目實施中，事后運營商出具的相關的文檔為日后可能出現的官司準備。所以整個項目團隊都要積極參與。
    【問題2】(8分)
    (1)從本案的商業模式來看，Z公司與運營方實際上首先都是投資方，運營方投入的是品牌和渠道，貴公司投入的是技術和資金，而從本案來看，Z公司好像將自己定位為一個項目執行方，那么一開始已經注定成功的可能性不大，出現這樣的問題也在情理之中。
    (2)這個商業模式本身沒有問題，有問題的是項目經理在出現了一個潛在的競爭者卻“渾然不覺”，畢竟在利益和商業道德之間至少在目前多數人會選擇利益，拋棄道德，這個是項目經理在做項目可行性計劃時的失誤，至少，可行性計劃中對這方面的風險分析是有缺陷的。
    (3)項目經理不缺乏項目管理的經驗，而缺乏必要的商業運作經驗，本項目的失敗項目經理要承擔部分責任，畢竟在項目執行過程中一定會有很多“蛛絲馬跡”表明運營商將會有違約的可能，這時候項目經理應該及時向自己的組織通報項目存在的風險，便于貴公司的高層及時與運營商溝通并約束對方履行合同，當然，本項目失敗的根本原因在W公司的高層，至少他們應該承擔項目失敗成本85％的責任。
    (4)項目經理應提高自己的法律意識和商業意識。
    【問題3】(9分)
    首先，項目的風險管理應該在項目實施之前就應該做好，準備好風險出現時的應急措施。任何項目可能都存在風險性，如何圓滿處理和化解風險才是項目經理在管理項目時應該考慮的。
    其次，項目經理如果在與運營商談此項目之時，就參與進入的話，項目經理是有推卸不了的責任，因為項目經理應該知道項目各方的權責利問題，盡可能把項目風險把握在自己可控之中，并且有一定的法律依據。
    再次，“合作分成”這樣的搭建平臺的方式本身就具有很大的風險性，但是現在工作中這種合作方式又普遍存在的，這樣就要求項目經理應該具有很強的自我法律保護意識，在簽署項目合作協議時，應該規范合作各方的權責利，規避項目風險！