項目管理綜述

項目管理綜述研究背景IT項目可以定義為“解決信息化需求而產(chǎn)生的軟件、硬件、網(wǎng)絡系統(tǒng)、信息系統(tǒng)、信息服務等一系列與信息技術相關的項目”，它涵蓋的項目范圍非常廣泛:軟件開發(fā)、系統(tǒng)集成、網(wǎng)絡通訊、電子商務、電子政務、信息規(guī)劃咨詢等等。根據(jù)世界銀行的統(tǒng)計資料表明，發(fā)展中國家的電子政務項目大約有35%完全失敗，而50%的項目部分歸于失敗，只有15%的項目可以看作是完全取得了成功。美國項目管理專業(yè)資質認證委員會主席PaulGrace指出：“當今社會，一切都是項目，一切也將成為項目疽'這種泛項目化的發(fā)展趨勢正逐漸改變著組織的管理方式，使項目管理成為各行各業(yè)的熱門話題,受到前所未有的關注。人們紛紛反思傳統(tǒng)的組織形式，期望通過項目化的思想，使組織中的行為更加有效。項目管理的方法，傳統(tǒng)上一直用于工程領域、建筑行業(yè)、國防軍事領域以及國家掌控下的大型項目，比如著名的三峽工程、國家的大飛機項目等等。但進入21世紀，隨著IT行業(yè)成為最具前景的新興產(chǎn)業(yè)之一，無數(shù)年輕的IT精英對項目管理的相關理論和模式進行著實踐和探索，不斷開發(fā)出新的硬件和軟件產(chǎn)品。我國信息中心的專家也表明，我國電子政務項目建設完全成功的比例約1/3[1]其實并非電子政務項目才存在這樣的問題，所有的IT項目都面臨這樣的問題。雖然IT項目的失敗率比較高，但是企業(yè)高層或項目經(jīng)理并沒有意識到風險管理的重要性,所有1T項目的風險管理并未受到重視。其中一個重要的原因IT行業(yè)目前來說仍然是一個高利潤的行業(yè)，雖然有失敗，但仍能夠讓企業(yè)生存下來，贏利的壓力并不大，從而造成眾多IT企業(yè)忽視了項目風險管理的作用。從理論上講,IT項目風險管理是為了使IT項目能夠按照預定的成本、進度、質量順利完成，而對成本、人員、進度、質量等進行風險分析和管理的活動。實際上,IT項目風險管理的意義不僅僅如此，進行IT項目風險管理有利于將開發(fā)人員的個人開發(fā)能力轉化成企業(yè)的開發(fā)能力，企業(yè)的開發(fā)能力越高，表明這個企業(yè)的生產(chǎn)越趨向于成熟，企業(yè)越能夠穩(wěn)定發(fā)展。研究意義風險管理的重要性和對企業(yè)的意義在上文中都已經(jīng)做了清楚的描述，但是中國企業(yè)關于風險管理的現(xiàn)狀卻不容樂觀，很大程度上存在著學術滯后，專業(yè)人才嚴重缺乏的現(xiàn)象，遠遠落后于國際水平，我選題研究的目的在于我想就我比較熟悉的通信行業(yè)在風險管理上存在的問題進行一些分析和研究，以便于在今后的工作中起一定的指導作用，同時也希望企業(yè)的管理者能對風險管理給與更多的關注，改變以往陳腐的項目管理模式，以便獲得更大的利益。通過對風險管理的學術性探討和學習，尋求的更有效果的管理和控制方式，形成最有利于生產(chǎn)力解放的體制機制，從而持續(xù)的增加管理的科學性、系統(tǒng)性和具體指向性，更有益于增強的長久生存與發(fā)展，對企業(yè)立足當前面向長遠有重大意義在企業(yè)的日常運營電通過對風險的管理與控制，能維持企業(yè)的可持續(xù)發(fā)展。有統(tǒng)計表明:約80%企業(yè)的失敗,并不是敗在市場和技術上，而是敗在了缺乏企業(yè)風險管理上面。有五分之三的民營企業(yè)在五年內(nèi)倒閉，有近九成的在十年里消亡，它們的平均生命僅為三年左右。另一方面風險管理還能為企業(yè)帶來額外的經(jīng)濟收入，數(shù)據(jù)顯示:在國外八成的投資人員更傾向于對風險管理優(yōu)秀的公司支付超過證券或股票的名目價值更多的金額。在西方一些國家的股市上更好的風險管理能給公司帶來近3成的高額溢價。據(jù)統(tǒng)計，幾乎70%的投資人員非常排斥不善于風險管理的公司，甚至采取拒絕投資的態(tài)度，相反對于那些善于風險管理的企業(yè)他們則紛紛出手投資，即使支付更高的價格。研究發(fā)現(xiàn)風險管理在通信工程建設中所起到的不容忽視的作用，特別是對于通信行業(yè)中這種機構龐大的國有企業(yè)，項目管理中的各項管理都還很難形成規(guī)范的管理模式，就單個的項目而言，項目進程中的每個階段都是由不同部門中的人來完成的，沒有獨立的項目團隊，也沒有真正意義上對整個項目各個環(huán)節(jié)負責的總管理者?，這種管理模式非常陳舊，不適應現(xiàn)代競爭激烈，風險倍出的社會大環(huán)境，我的研究當然無力改變整個企業(yè)的管理模式，只是希望可以以合理化建議的方式引起管理者的關注，市場經(jīng)濟中，企業(yè)運行的根本是效益，風險管理直接影響的也是效益，所以它一定是指導我們工作并且值得我們研究的重要方向國外研究現(xiàn)狀國外軟件項目風險管理的研究始于1989年的美國［2。由美國軍方資助，設立在卡內(nèi)基梅隆大學的SEI則是190年來研究和實踐軟件風險管理的最大基地。此外英國和由芬蘭、挪威、荷蘭、瑞典等國組成的北歐經(jīng)濟圈以及澳大利亞、日本、韓國也有一定的成果問世。而在其他國家和地區(qū)只有零星的相關報道，與國內(nèi)情況類似,尚未形成規(guī)模形式。3.1理論方面總結當前幾種經(jīng)典的IT項目風險管理體系［3］,可以分為:普遍認為Boehm的《軟件風險管理》［4］奠定了該領域的理論基礎,Boehm認為⑸，軟件風險管理指的是“試圖以一種可行的原則和實踐，規(guī)范化地控制影響項目成功的風險”，其目的是“識別、描述和消除風險因素，以免它們威脅軟件的成功運作”;同期charette從不同角度也構造出了類似的風險管理結構［6】。由美國軍方資助,設立在卡內(nèi)基?梅隆大學的SEI則是1990年來研究和實踐軟件風險管理的最大基地。SEI［7】提出的持續(xù)風險管理管理模型(CRMContinuousRiskManagement)，其主要思路是不斷地評估可能造成惡劣后果的因素，決定最迫切需要處理的風險，實現(xiàn)控制風險的策略,評測并確保風險策略實施的有效性。他們認為［8］軟件風險評估、持續(xù)的風險管理和團隊風險管理構成了軟件風險管理的基本框架。SE工和Boehm的模型都以風險管理的過程為主體,研究每個步驟所需的參考信息及其操作。微軟認為［9】風險管理可分為5個步驟:風險辨識、風險分析、風險活動計劃、風險跟蹤和風險控制。而Leavitt大學于1964年提出的Aalborg思路則是以模型為基礎(稱為Leavitt模型)［1。］,著重從導致軟件開發(fā)風險的不同角度出發(fā)探討風險管理,Leavitt模型將形成各種系統(tǒng)的組織劃分為4個組成部分:任務、結構、角色和技術。該模型的關鍵思路是:各個組成部分是密切相關的，一個組成部分的變化會影響其他的組成部分，如果一個組成部分的狀態(tài)和其他的狀態(tài)不一致，就會造成比較嚴重的后果，并可能降低整個系統(tǒng)的性能。DaleKarolak于1999年提出的SERIM(SoftwareEngineeringRiskModel)模型是工EEE推薦的方法°SERIM從技術和商業(yè)兩個角度對軟件風險管理進行剖析，考慮的問題涉及開銷、進度、技術性能等。它還提供了一些指標和模型來估量和預測風險，由于這些數(shù)據(jù)來源于大量的實際經(jīng)驗，因此具有很強的說服力。Karolak認為SERIM模型是基于“及時”JIT(JustinTime)策略，將軟件開發(fā)過程中的風險影響最小化在開發(fā)過程早期的管理將會縮短開發(fā)周期;在開發(fā)過程中使用了風險管理的產(chǎn)品將更傾向于節(jié)省開銷和滿足進度要求。軟件的3個JIT關鍵思想是:進度計劃、早期風險識別以及并行開發(fā)。另外,Tallon等［11進一步地把風險管理提前到口項目投資階段,walsh等叫臏］認為軟件項目風險管理只有方法是不夠的，決策者的動機和行為對項目成敗有很大影響，應用了行為學和代理理論成果。而文獻［14】作為大學教科書，收錄了經(jīng)過十幾年發(fā)展比較成熟的技術、方法和工具。RIChardMu:Ch在他2001年出版的《IT項目經(jīng)理實踐入門》［任］一書中，強調了貧項目風險管理的問題。他把項目管理中的風險劃分為5類:外部風險，如市場變化、新的行業(yè)標準、合并與收購事件、政策法規(guī)、網(wǎng)絡故障和災難、自然災害等;成本風險，如未能預見的項目范圍偏離、擴展和變更，對項目成本的估計出現(xiàn)差錯，預算和進度超計劃等;進度風險,如技術和內(nèi)部溝通出現(xiàn)障礙，貨源缺乏和資源不恰當?shù)恼{度等；技術風險,缺乏有效的軟件測試和系統(tǒng)測試，未能預見技術與系統(tǒng)的復雜性，技術與業(yè)務的整合缺陷等；執(zhí)行風險,如未能給關鍵人物授權，系統(tǒng)發(fā)布時機出現(xiàn)判斷錯誤等。3.2實踐方面Powell等［16］研究了一般項目風險管理的技術、方法和步驟在軟件項目開發(fā)中的應用，并開發(fā)了一個完整的輔助風險分析的決策支持系統(tǒng)。詹姆斯?江等［17］認為軟件項目的成功可從4個方面度量,而不同風險對各個方面的影響不同，并通過調查和建模求解找出了主要項目風險源與不同成功方面的關系。David基于知識的總結、分析和可視化技術探討了從風險陳述文本識別風險源的規(guī)范程序。SEI提出了基于分類的風險辨識(Taxonomy-BasedRiskidentification)方法"】項目管理研究院(PMI)采用風險評估方法學度量軟件開發(fā)風險。SEI在其著名的能力成熟度模型(SW--CMM)基礎上又提出了軟件采購能力成熟度模型(SA一CMM)［19］,主要面向大型團隊的復雜項目。Reifer［20］［2i］闡解了當今廣泛的網(wǎng)絡信息系統(tǒng)應用所面臨的特殊風險。工EEE于2001年制訂了工EEE154O標準［22］,結合軟件生命周期模型給出了風險管理過程規(guī)范。事實上的國際標準“軟件能力成熟度集成(CMMI)”模型在第3級將風險管理列為了關鍵過程域(KPA)。這些風險管理體系主要是從軟件工程的角度出發(fā),以大型系統(tǒng)軟件為研究對象提出的，而以企業(yè)IT項目風險為背景的應用研究函待拓展。4國內(nèi)研究現(xiàn)狀相比國外而言，我國由于IT行業(yè)發(fā)展較晚，對工T項目的風險管理也還處在以經(jīng)驗管理為主的起步階段。經(jīng)過國內(nèi)學者的不懈努力探索,我國在IT項目風險管理理論研究方面已經(jīng)取得了階段性成果。但大家也應清楚的認識到，在現(xiàn)階段我國IT企業(yè)在項目風險管理方面還存在很多不足。文亞棟［23】提出的風險評估步驟為:l)定義項目的風險參考水平值;2)建立每一組(風險、風險發(fā)生的概率、風險產(chǎn)生的影響)與每一個參考水平值的關系。3)預測一組臨界點以定義項目終止區(qū)域，該區(qū)域由一條曲線或不確定區(qū)域界定。4)預測什么樣的風險組合會影響參考水平值。其將軟件項目的風險因素劃分為四個方面，即性能風險、成本風險、支持風險、進度風險，而這四個方面又可以詳細的劃分為:產(chǎn)品規(guī)模風險，商業(yè)影響風險,客戶特性風險，過程定義風險,開發(fā)環(huán)境風險，技術風險，人員數(shù)目及經(jīng)驗帶來的風險。田件祥［24］主要從風險分析和風險控制兩個方面進行，在風險分析的過程中，提出了利用風險清單的方法來識別風險，然后根據(jù)各風險因素可能帶來的影響程度、發(fā)生頻率，建立一個三元組(Ri,Pi,Xi)的風險評估方法，并考慮如何控制這些風險的方法。而陳忠［25］則將風險管理劃分為四個相關階段，即風險識別、風險評估、風險處理、風險監(jiān)控。田中敏［26］,將JT項目開發(fā)中常見的風險歸結為十類:需求風險，計劃編制風險,組織和管理風險,人員風險,開發(fā)環(huán)境風險,客戶風險，承包商風險,產(chǎn)品風險,設計和實現(xiàn)風險和過程風險。張金隆等刀］將IT項目風險分為業(yè)主風險、能力風險、業(yè)務風險、開發(fā)風險和技術風險等5大類,15個風險要素。薛四新等［28］將軟件項目的生命周期階段劃分為立項、設計、實現(xiàn)和收尾四大主要工作階段。每個階段又包含多個不同的子過程，立項階段包括項目定義和項目啟動;設計階段包括需求分析和設計;實現(xiàn)階段包括編碼、測試和試運行;收尾階段包括驗收、運行維護和交接。各個子過程之間關系緊密，而且并行的、反復循環(huán)的工作內(nèi)容比較頻繁。各階段之間的工作既有嚴格的工作接續(xù)關系，即前一階段工作完成以后，后一階段工作才能開始,前一階段的輸出文檔是后一階段的輸入文檔。同時又存在一定的工作并行性以及工作反饋與循環(huán),如在前一階段工作即將結束前，開始著手下一階段的計劃制定；軟件的編碼與測試工作就需要經(jīng)過多次的循環(huán)反復等。因此,IT項目風險并不是由一個因素造成或產(chǎn)生于某一個階段，而是由多重風險構成并貫穿于生命周期的全過程。陳濤［29］在其碩士論文中提出了采用實物期權的方法，對IT項目進行風險評估與控制決策，創(chuàng)新的將實物期權的方式引入IT項目的風險控制中。盧新元［3。］提出利用模糊集的方法，解決IT項目中的風險決策的問題，提出以粗糙集理論為主、多方法融合的風險決策過程中的規(guī)則挖掘方法，其目的是在信息不完整、不精確的前提下，無需傳統(tǒng)意義上復雜的建模過程，直接從大量的客觀數(shù)據(jù)中發(fā)現(xiàn)隱含知識，實現(xiàn)對IT項目的風險等級預測、以及對風險決策規(guī)則進行挖掘的目的，從而提高風險決策和判斷能力，促進IT項目風險管理向著智能化、科學化、定量化的方向發(fā)展，并最終提高項目的成功率。吳超提出的通過某金融軟件IT企業(yè)CMMI5級的實施過程分析及應用研究,來闡述如何提升IT企業(yè)的項目管理過程能力，使過程變得可預測和可度量，并且控制或消除了造成質量低劣和生產(chǎn)率不高的主要因素。國］范學勝提出通過文件審查法、頭腦風暴法、德爾菲技術等手段對本項目中的風險進行了識別和記錄，并進一步對風險識別方法作了改進性的應用，以及對實際的應用效果進行了評價。然后對這些風險進行定性分析和定量分析，得到了數(shù)值化和貨幣化的結果，為風險應對提供重要的參考。針對風險分析得出的結果，制定相應的應對策略，這些應對策略包括風險回避、風險減緩、風險分離、風險轉移和風險自留。通過對這些應對策略的綜合運用，取得了良好的效果。本文還對風險管理的全過程進行監(jiān)控，以及對風險管理過程中的相關文檔進行評審、歸檔，形成組織過程資產(chǎn)。在每種理論和方法的論述之后，分別結合交行新一代業(yè)務系統(tǒng)案例，進行了實踐分析和論述。肉袁辛［33］在文章中提出構建以項目整個生命周期為主線，將不同階段參與的干系人以及所帶來的風險串聯(lián)在一起的三維立體的全方位風險管理模型。進一步完善對IT項目的風險管理。在劉汕［34］的文章中以企業(yè)IT項目績效為研究對象，構建企業(yè)IT項目風險和控制交互影響績效的理論框架，從項目經(jīng)理和用戶代表的角度論證正式控制的兩種模式（行為控制和結果控制）和非正式控制的兩種模式（價值觀控制和自我控制）與績效的關系。接著采用Delphi法從項目經(jīng)理和企業(yè)高層領導的角度對我國企業(yè)IT項目風險進行測度。最后，本文建立需求風險和用戶風險調節(jié)影響控制和績效之間關系的實證模型并驗證所提理論框架的有效性和合理性。王東［35］在其論文中提出將FMEA引入IT項目管理中，創(chuàng)新性的設計了針對亶項目的FMEA分析流程、評分標準和對策制定方法。余菡［36］在文章中根據(jù)實際情況，分析得出了IT項目中各類風險的對策。田曉靜［37］在根據(jù)模糊數(shù)學模糊度的計算原理，設計一個評價指標自動篩選的指標生成模型。利用模糊度進行指標篩選，實現(xiàn)了評價模型的簡單、有效、因地制宜。柴勇哲［38］提出在通信企業(yè)實施IT項目的過程中，為風險管理者提供可參考的模板及可操作的流程和方法，是風險管理者在項目生命周期中對風險進行主動的、預防式的管理,以達到改善通信企業(yè)面臨風險管理問題的現(xiàn)狀王琦、劉詠梅、衛(wèi)旭華［39］信任控制與外包合作績效呈正相關關系，并且通過感知不確定性的完全中介作用對外包合作績效產(chǎn)生正向影響;而契約控制與外包合作績效的相關關系未得到實證支持;項目獲取途徑對控制機制與外包合作績效間關系的調節(jié)效應不顯著。此外，在項目風險管理的某一具體方法探討中，也涌現(xiàn)了許多好方法，例如:利用聚類分析的方法分析在高、中、低風險的軟件項目中風險類的變化趨勢以及重要程度。利用風險發(fā)生的可能性一危害性網(wǎng)格圖來評估風險對項目的影響程度的方法［4。］、風險度量指標［41］、評估風險的指標選用、項目區(qū)域風險的模糊綜合評價方法［42］。引入AHP層次分析法建立E即系統(tǒng)實施風險評估模型，利用AHP算法找出影響實施成功的關鍵風險因素等。決策行為對項目風險的影響，如決策者行為與風險效應的風險效應一行為決策模型等43］。通過對IT項目風險管理體系的比較研究,提出全面風險管理的概念并構建全面風險管理體系框架［44］。進而,我國于2001年2月，由中國優(yōu)選法統(tǒng)籌法與經(jīng)濟數(shù)學研究會項目管理研究委員會(PMRC)正式推出了中國的項目管理知識體系文件《中國項目管理知識體系》(CPMBOK),對風險管理也進行了詳細規(guī)范，作為項目管理規(guī)范化運作的理論基礎和技術指南5IT項目中的風險識別5.1風險識別概述風險識別是指依據(jù)公司目標，搜集公司內(nèi)外部導致風險產(chǎn)生的原因，明確風險類別及其涉及的歸屬部門，描述風險，并進行預評估的過程［4頭風險通常具有隱蔽性，而人們常常容易被一些表面現(xiàn)象所迷惑，或被一些細小利益所引誘而看不到內(nèi)在的危險［46］。因此，風險識別在項目風險管理中是非常重要的第一步，是風險管理的基礎。人們?nèi)缦氩扇∵m當有效的方法對風險進行管理、規(guī)避，必須正確識別出項目所面臨的風險。風險識別的目標是通過識別出項目面臨的風險，分析出風險本身的特征以及風險的源頭，以文檔、數(shù)據(jù)庫、書面記錄等方式記錄下來，在后續(xù)的風險分析、風險應對、風險監(jiān)控環(huán)境使用這些識別出來的風險數(shù)據(jù)。風險識別過程一般包含感知風險和分析風險兩個環(huán)節(jié)。感知風險是風險識別的基礎，分析風險是風險識別的關鍵。5.2風險識別的方法和技術從理論上來講，風險識別可以從因素查影響，也可以從影響反過來找因素。風險因素是造成論證結果不確定的原因和影響論證結果概率分布的因素［4刀。在具體進行風險識別的過程中，一般要借助一些方法、技術和工具，這樣不僅可以提高項目組織識別風險的效率，實現(xiàn)規(guī)范的操作，還可以不容易造成風險遺漏。在具體應用的過程中，一般都需要結合多種方法、技術和工具。風險識別的各種方法在實際應用中都有其有利和不利的方面，風險識別的實際效果取決于所選擇的方法是否適合于當時的場合48］。在交行新一代業(yè)務系統(tǒng)中，主要通過以下幾種方法和技術對風險進行識別。5.2.1文件審查法文件審查是指對項目計劃、假設、先前的項目文檔和其他信息等項目文件進行系統(tǒng)和結構性的審查以嘰通過對這些資料的審查、分析、比較，再根據(jù)項目組成員的經(jīng)驗，可以預先對以往遇到過的風險、將來有可能遇到的風險進行識別、分析，制訂應對預案，消除風險因素，大大減少風險對整個項目的影響程度。5.2.2頭腦風暴法在群體決策中，群體成員心理會相互影響，大多數(shù)的成員會容易屈服在權威或大多數(shù)人意見，形成所謂的“群體思維”。群體的思維削弱了群體的批判精神和創(chuàng)造力，損害了決策的質量。為了解決這個問題，管理上發(fā)展了一系列改善群體決策的方法，以使集思廣益更加有效。而頭腦風暴法就是較為典型的一種方法，該方法已經(jīng)成為非常流行而且有效的風險識別的手段。頭腦風暴法在某些組織中也叫“神仙會”，就是說讓項目團隊中盡可能多的成員和干系人就某問題提出主張和想法。頭腦風暴法可分為直接頭腦風暴法（通常簡稱為頭腦風暴法）和質疑頭腦風暴法（也稱反頭腦風暴法）。前者就是我們通常所說的頭腦風暴法，盡可能地激發(fā)創(chuàng)造性，產(chǎn)生盡可能多的想法和方案，并不對想法和方案進行評價；后者則是對產(chǎn)生出來的想法和方案進行逐一質疑、分析和討論。一般說來，頭腦風暴法指的是前者。通常頭腦風暴法需要遵循庭外判決原則、各抒己見原則、追求數(shù)量原則、取長補短原則等等。5.2.3德爾菲技術德爾菲技術是專家就某一專題達成一致意見的一種方法。項目風險管理專家以匿名方式參與此項活動。主持人用問卷征詢有關重要項目風險的見解。問卷的答案交回并匯總后，隨即在專家中傳閱，請他們進一步發(fā)表意見。此過程進行若干輪之后，就不難得出關于主要項目風險的一致看法。德爾菲技術有助于減少數(shù)據(jù)中的偏倚，并防止任何個人對結果不適當?shù)禺a(chǎn)生過大的影響。德爾菲技術本來是決策學中的一種方法，1946年，蘭德公司首次用這種方法用來進行預測，后來該方法被迅速廣泛運用。德爾菲法本質上是一種集體匿名思想交流過程，也是反饋匿名函詢法［5。］。德爾菲技術的發(fā)揮了以下的優(yōu)點：（1） 能充分發(fā)揮出各位專家的作用，集思廣益，準確性比較高。（2） 能把各專家意見的分歧點表達出來，取各家之長，避各家之短。德爾菲技術同時避免了以下的缺點：（1） 權威人士的意見影響他人。（2） 有些專家礙于情面，不愿意發(fā)表與他人不同的意見。（3） 出于自尊心不愿意修改自己原來不全面的意見。德爾菲技術的主要缺點是過程比較復雜，花費時間較長。但由于該方法簡便可靠，在風險識別的過程中仍是常用的方法之一。5.2.3訪談法在項目進行的過程中，項目風險管理人員免不了需要經(jīng)常與各項目干系人進行溝通。項目風險管理員有意識地通過和項目參與者、利害關系者或相關問題的專家進行交流面談，同時收集不同人員對項目風險的看法、意見和建議，同時把訪談內(nèi)容進行記錄，然后進行歸類、分析，這將大大有助于識別那些在常規(guī)計劃中容易被忽略的風險因素。訪談法和德爾菲技術的區(qū)別在于，訪談法并沒有德爾菲技術那么正式以及對相關專家有那么高的要求，相對來說獲得信息比較快、比較及時。5.2.4風險核對表法風險核對表是指將項目可能發(fā)生的若干潛在風險列于一張表上，在風險管理人員進行檢查核對時，用于判別項目是否存在著表中所列或者是類似的風險。風險核對表中所列的是歷史上類似項目曾經(jīng)發(fā)生過的風險，是項目風險管理經(jīng)驗的結晶，對于項目管理人員來說，具有啟發(fā)聯(lián)想、拋磚引玉、開闊思路的作用。5.2.5假設分析法每個項目都是根據(jù)一套假定、設想或者假設進行構思與制定的。假設分析是檢驗假設有效性的一種技術。它辨認不清確、不一致、不完整的假設對項目所造成的風險。5.2.6因果圖分析法因果圖又名石川圖或魚刺圖。因果圖分析法是利用“頭腦風暴法”，發(fā)動各項目相關人員，集思廣益，尋找影響項目的范圍、時間、成本、質量等問題的潛在因素，然后用圖形直觀地表示出它們?nèi)绾闻c各種潛在問題或結果聯(lián)系起來的一種方法。該方法能幫助風險管理人員集中注意力尋找產(chǎn)生問題的根源，并為收集數(shù)據(jù)指出方向。在具體操作上，先畫一條直線（稱為脊），然后在該直線的兩旁畫上與該直線成一定夾角的直線（稱為大枝），在其端點標上造成問題的大因，再在這些直線上畫若干條水平線（稱為中枝），在線的端點寫上中因，如果需要，還可以對這些中因分枝上作進一步的分析，提出小原因。這就好像魚的骨頭一樣，先從頭開始，通過大的脊梁骨，逐步推導到周邊小的魚刺。參考文獻:蔣力群.如何提高電子政務項目成功率.上海信息化,2007.(12)WilliamsTM.AclassedbibliographyofrecentresearchrelatingtoProjectriskmanagement.EuroPeanJounralofOPerationalResearch,1995.85:18-38方德英、李敏強.IT項目風險管理理論體系構建.合肥工業(yè)大學學報(自然科學版)，2003.26:907-911徐璐.多屬性決策方法及其在軟件項目風險管理中的應用研究合肥工業(yè)大學學歷碩士畢業(yè)論文,2007年吳勇華.軟件項目風險投資評估決策方法.科技管理研究,2002(5):94-97青琳、黃洪.軟件項目的風險評價模型.計算機工程與應用,2004(10):227-229Ronald p.HigueraandYacovY.Haimes.SoftwareRiskManagement-CMU/SEI-96-TR-012ESC-TR-96-012楊冰之.信息化項目風險從何而來.企業(yè)管理,2003(8):101-102MicrosoftCorpMSFriskmanagementprocess.http://www.Micr0S0,1999:6王寓辰.IT項目風險預警系統(tǒng)研究與實現(xiàn).華中科技大學碩士學位論文,2006年P.P.Tallon,etal,UsingRealOptionsAnalysisforEvaluatingUncertainInvestmentsinInformationTechnology[A]:InsightsFromTheICIS2001DebateCommunicationsoftheAssociationforInformationSystems,2002.9:136-167MeyerR.L.AvoidingtheRisksinLargeSoftwareSystemAcquisitions?InformationStrategy1998,14(4):18一33Walsh,K.R.&SehneiderH.TheroleofmotivationandriskbehaviorsinSoftwaredeVelopmentsueeess.InformationReseareh,2002,7(3)BlaekbumJ.D.,HoedemakerG.,etal.ConeurrentSoftwareEngineering:ProspeetsandPitfalls.IEEETransactionsonEngineeringManagement,1996,43:179一188RichardMurch著.簡學譯.《IT項目經(jīng)理實踐入門(ProjectManagement:BestpracticesForITprofessional)》.電子工業(yè)出版社，2002P.L.Powell,J.H.Klein.Riskmanagementforinformationsystemsdevelopment.JournalofInformationTeehnolog,1996,11(4):0307-0317JamesJ.Jiangetal.Riskstodifferentaspeetsofsystemsueeess.Information&Management,1999,(36):263-272方德英、李敏強.IT項目風險管理理論體系構建.合肥工業(yè)大學學報(自然科學版),2003,26:907-912Brianp.Gallagher.SoftwareaequisitionriskmanagementkeyProeessarea(KPA)-aguidebookversion.OZ.CMU/SEI-99-HB-001,1999/10DonaldReifer.TendeadlyrisksinInternetandintranetsoftwaredevelopment.IEEESoftware,May/June1997,126-127,130-133LyytinenK,MathiassenL,RopponenJ.AttentionShapingandsoftwareRisk:ACategorialAnalysisofFourClassicalApproaches.InformationSystemsResearch,1996,9(3):52-63IEEE.IEEEstandard1540-2001.IEEEStandard