風險管理指南.doc

風險管理指南風險管理指南 1 1 目的目的 2 2 2 適用范圍適用范圍 2 3 3 術語術語 2 4 4 項目風險管理描述項目風險管理描述 2 4 1 4 1 風險分類風險分類 2 4 2 4 2 風險識別風險識別 3 4 3 4 3 風險分析風險分析 4 4 4 4 4 風險處理和減緩活動風險處理和減緩活動 5 5 5 風險監(jiān)控風險監(jiān)控 6 6 6 附錄附錄 6 6 1 6 1 項目風險分析列表項目風險分析列表 6 6 2 6 2 參考資料參考資料 9 7 7 修訂記錄修訂記錄 9 1 1 目的目的 描述項目進行過程中可能產生的風險的識別方法 制定預防風險的措施 及風險發(fā)生時的解決 方法 供項目策劃時根據具體項目的情況選擇或裁剪使用 由此確定項目采用科學的風險識別 方法 制定詳細的預防措施和解決方法 以避免風險的發(fā)生 或者當風險發(fā)生時 將損失減小 到最低程度 2 2 適用范圍適用范圍 適用于公司的所有合同項目和產品項目 風險管理貫穿于項目的整個生命周期 3 3 術語術語 1 項目風險 指項目中不利事件發(fā)生的不確定性 2 軟件風險 指軟件開發(fā)過程中及軟件產品本身可能造成的傷害或損失 3 風險管理 對項目風險進行識別 分析和處理的過程 4 4 項目風險管理描述項目風險管理描述 為了管理項目可能存在的風險 在進行項目策劃時 需要進行風險分析 并制訂風險管理計劃 該計劃可作為項目計劃的一部分 風險管理應貫穿于項目工程的始終 它不是項目經理一人的任務 也不是一次性的任務 而是 一個迭代的過程 任一項目成員都有責任進行風險管理 制定風險管理計劃包括 風險識別 風險分析 風險處理 風險跟蹤 4 1 4 1 風險分類風險分類 要進行風險管理 先明確項目風險怎么分類 4 1 1 4 1 1 按內容分按內容分 范圍風險 與范圍變更有關的風險 質量風險 影響按照要求的技術性能和質量水平完成任務 進度風險 影響在預算的時間范圍內完成任務 成本風險 影響在預算的成本范圍內完成任務 技術風險 技術變化 法律風險 許可權 專利 合同失效 訴訟 不可抗力 外部可預測風險 市場風險 原材料可利用性 需求 日常運作 維修需求 環(huán)境影響 社會影響 貨幣變動 通貨膨脹 稅收 外部不可預測風險 規(guī)章 不可預測的政府干預 自然災害 內部非技術風險 戰(zhàn)略風險 公司的經營戰(zhàn)略發(fā)生了變化 管理風險 公司管理人員是否成 熟等 4 1 2 4 1 2 按可確定性分按可確定性分 已知風險 如當前測試環(huán)境不能滿足用戶真實使用環(huán)境的模擬 可預知風險 如使用技術存在的缺陷 不可預知風險 如外購進口設備運輸途中可能出現(xiàn)的不能如期到達或損壞的風險 4 2 4 2 風險風險識別識別 風險識別是管理風險的第一步 即識別整個項目過程中可能存在的風險 一般是根據項目的性 質 從潛在的事件及其產生的后果和潛在的后果及其產生的原因來檢查風險 收集 整理項目 可能的風險并充分征求各方意見后形成項目的 風險和問題跟蹤列表 過程管理平臺中 填寫和維護 風險列表 4 2 1 4 2 1 要進行風險識別的階段要進行風險識別的階段 在項目開始 每個階段一開始 主要范圍變更批準之前都要進行風險識別 實際上它在整個項 目生命周期內都是一個連續(xù)的過程 4 2 2 4 2 2 風險事件或風險來源風險事件或風險來源 要識別風險 就應該了解在項目各個階段都有可能發(fā)生哪些風險 以軟件開發(fā)為例 初始階段 這個階段包括立項和需求分析及 軟件需求規(guī)格說明書 的設計 大部分業(yè)務建模和需求 少部分分析設計 可能的風險事件有 項目目標不清 項目范圍不明確 范圍太大太小 都不可以 用戶參與少或和用戶溝通少 對業(yè)務了解不夠 對需求了解不夠等 設計階段 在這個階段進行總體設計和詳細設計 可能的風險事件有 項目隊伍缺乏經驗 如缺乏有 經驗的系統(tǒng)分析員 沒有變更控制計劃 以至于變更沒有依據 該變更的不變 不該變的 也變 這樣得來的設計勢必會失敗或者偏離用戶需求 倉促計劃 可能帶來進度方面的風 險 漏項 由于設計人員的疏忽某個功能沒有考慮進去等 實施階段 在這個階段進行大部分編碼和測試 可能有設計變更或補充設計 可能的風險事件有 開 發(fā)環(huán)境沒有具備好 設計錯誤帶來的實施困難 程序員開發(fā)能力差 或程序員對開發(fā)工具 不熟 項目范圍改變 突然要增加或修改一些功能 需要重新考慮設計 項目進度改變 要求提前完成任務等 人員離開 在一個項目內軟件開發(fā)工作有一定的連續(xù)性 需要 移交和交接 有時人員離開對項目的影響會很大 開發(fā)團隊內部溝通不夠 導致程序員對 系統(tǒng)設計的理解上有偏差 沒有有效的備份方案 沒有切實可行的測試計劃 測試人員經 驗不足 沒有進行可行性研究等 收尾階段 在這個階段進行安裝及維護 大部分部署 可能的風險事件有 質量差 客戶不滿意 設備沒有按時到貨 資金不能回收 客戶返饋意見引起大的變更等 4 2 3 4 2 3 風險識別的方法風險識別的方法 不同項目可能發(fā)生的風險事件不同 應該對具體項目識別出真正有可能發(fā)生在該項目的風險事 件 風險識別的有效方法有很多 如 建立風險項目檢查表 可以從以下幾方面來檢查 產品規(guī)模風險 業(yè)務影響風險 與客 戶相關的風險 過程風險 技術風險 開發(fā)環(huán)境風險 與人員的模式和經驗有關的風險 建立因果分析圖 征求意見 就項目可能存在的問題和不確定因素 征求項目組成員的意見 參考以往項目的風險情況 提問的方式 針對所識別的潛在風險 采用提問的方式確定是否應認定為風險 4 2 4 4 2 4 確定所識別的風險類確定所識別的風險類型型 軟件項目一般有如下五類風險 規(guī)模風險 規(guī)模風險 項目產品本身 大系統(tǒng)和小系統(tǒng) 或由項目團隊引起的風險 項目的風險是直 接與產品的規(guī)模成正比的 風險因素有 估計產品的規(guī)模的方法 代碼行 功能點 程序 或文件的數目 產品規(guī)模估計的信任度 產品規(guī)模與以前產品規(guī)模平均值的偏差 產品 的用戶數 復用的軟件有多少 產品的需求改變多少 需求風險 需求風險 不確定的客戶需求引起的風險 很多項目在確定需求時都面臨著一些不確定性 當在項目早期的需求不確定性在項目進展過程當中得不到解決時 就會對項目的成功造成 很大威脅 與客戶相關的風險因素有 對產品缺少清晰的認識 對產品需求缺少認同 在 做需求中客戶參與不夠 沒有優(yōu)先需求 由于不確定的需要導致新的市場 不斷變化需求 缺少有效的需求變化管理過程 對需求的變化缺少相關分析 相關性風險 相關性風險 項目的外部環(huán)境或因素的相關性產生的風險 我們經常不能很好地控制外部 的相關性 因此緩解策略應該包括可能性計劃 以便從第二資源或協(xié)同工作資源中取得必 要的組成部分 并且覺察潛在的問題 與外部環(huán)境相關的因素有 客戶供應條目或信息 內部或外部轉包商的關系 交互成員或交互團體依賴性 經驗豐富人員的可得性 項目的 復用性 管理風險 管理風險 組織自身的管理水平 能力成熟度引發(fā)的風險 應定義項目追蹤過程并且明晰 項目角色和責任 以能處理這些風險因素 計劃和任務定義不夠充分 實際項目狀態(tài) 項 目所有者和決策者分不清 不切實際的承諾 員工之間的沖突 技術風險 技術風險 由人員的技術水平和經驗 使用的工具和技術的成熟度等引發(fā)的風險 在早期 識別風險從而采取合適的預防措施是解決風險領域問題的關鍵 比如 培訓 雇傭顧問以 及為項目團隊招聘合適的人才等 主要有下面這些風險因素 缺乏培訓 對方法 工具和 技術理解的不夠 應用領域的經驗不夠 新的技術和開發(fā)方法 不能正確工作的方法 4 3 4 3 風險分析風險分析 風險分析是對識別出來的風險事件做風險影響分析 確定避免或減輕風險的策略及措施以達到 降低風險 保證項目順利進行的目的 對確定的風險事件還要進行描述 如 可能性 可能后 果范圍 預計發(fā)生時間 發(fā)生頻率等 4 3 1 4 3 1 和風險相關的因素和風險相關的因素 和風險相關的主要四個因素 風險事件 破壞或影響項目的事件 風險概率 事件發(fā)生的可能性 風險得失量 金額 說明可能造成的損失 風險影響 周 等于風險概率 風險得失量周 4 3 2 4 3 2 風險分析步驟風險分析步驟 風險分析要確定每個風險對項目的影響大小 一般是對已經識別出來的項目風險進行量化估計 通過對風險及風險的相互作用的估算來評價項目可能結果的范圍 從成本 進度及性能三個方 面對風險進行評價 評價風險影響 指一旦風險發(fā)生可能對項目造成的影響大小 如果損失的大小不容易直接 估計 可以將損失分解為更小部分再評估它們 風險影響可用相對數值表示 建議將損失 大小折算成對計劃影響的時間表示 估計風險概率 它是風險發(fā)生可能性的百分比表示 是一種主觀判斷 計算風險值和和風險等級 它是評估風險的重要參數 風險值 風險概率 風 險影響 如 某一風險概率是 25 一旦發(fā)生會導致項目計劃延長 4 周 因而 風險值 25 4 周 1 周 風險等級 分為 1 級 2 級 3 級 確定風險優(yōu)先級 哪些風險事件或來源可以避免 哪些可以忽略不考慮 包括可以承受 哪些要采取應對措施 4 3 3 4 3 3 風險分析方法風險分析方法 確定型風險的分析方法 盈虧平衡分析 計算和分析產量 成本和盈利這三者之間的關系 敏感性分析 考察與軟件項目有關的一個或多個主要因素發(fā)生變化時對該項目投資價值 指標的影響程度 概率分析 運用概率論及數理統(tǒng)計方法 來預測和研究各種不確定因 素對軟件項目投資價值指標影響的一種定量分析 不確定型風險的分析方法 有小中取大原則 大中取小原則 遺憾原則 最大數學期望原 則 最大可能原則 隨機型風險的分析方法 最大可能原則 最大數學期望原則 最大效用數學期望原則 貝 葉斯后驗概率法等 4 3 4 4 3 4 建立風險跟蹤列表建立風險跟蹤列表 當風險分析完成后 將風險名稱 風險的分類 風險值 風險等級和排出的風險優(yōu)先級記錄到 風險和問題跟蹤列表 中的 風險跟蹤列表 部分 在過程管理平臺中 填寫和維護 風險列表 一旦完成了 風險和問題跟蹤列表 就可以根據概率及影響來進行綜合考慮 風險影響和出 現(xiàn)概率從風險管理的角度來看 它們各自起著不同的作用 一個具有高影響但低概率的風險因 素不應當占用太多的風險管理時間 但具有中到高概率 高影響的風險和具有高概率及低影 響的風險 就應該進行風險處理 4 4 4 4 風險處理和減緩活動風險處理和減緩活動 當完成了風險分析后 就已經確定了項目中存在的風險以及它們發(fā)生的可能性和對項目的風險 沖擊 并可排出風險的優(yōu)先級 就可以根據風險性質和項目對風險的承受能力制定相應的預防 措施和解決方法的計劃 即風險處理和減緩 對每個高優(yōu)先級風險 項目組都要制定出處理和減緩風險的活動計劃 4 4 1 4 4 1 風險規(guī)避的策略風險規(guī)避的策略 一旦監(jiān)視到風險 就應采取合理措施進行風險規(guī)避 可以從改變風險性質 改變風險發(fā)生的概 率 改變風險的影響大小等多方面著手 風險規(guī)避的策略一般有 避免 避免 通過分析找出來發(fā)生風險事件的原因 消除這些原因來避免一些特定的風險事件發(fā) 生 如避免客戶不滿意 可采用這些措施 客戶參與業(yè)務建模階段 需求階段要多和客戶 溝通 了解客戶真正的需求 目標系統(tǒng)的模型或 DEMO 系統(tǒng)要向客戶演示 并得到反饋 意見 如果反饋的意見和 DEMO 系統(tǒng)出入比較大時 一定要將修改后的 DEMO 系統(tǒng)在次 向客戶演示 直到雙方都達成共識為止 要有雙方認可的驗收方案和驗收標準 做好變更 控制和配置管理 減緩 減緩 通過降低風險事件發(fā)生的概率或得失量來減輕對項目的影響 如經過風險識別發(fā)現(xiàn) 項目組的程序員對所需開發(fā)技術不熟 可以采用熟悉的技術來減緩項目在成本或進度方面 的影響 也可以事先進行培訓來減緩對項目的影響 接受 接受 接收風險造成的后果 如自然災害造成的風險 在一個大的軟件項目中 為了避免 自然災害造成的后果 考慮異地備份中心 轉移 轉移 使用合作伙伴 項目外包 保險與擔保等手段來轉移風險的方法 以減輕風險對項 目帶來的影響 回避 回避 當項目風險潛在威脅的可能性極大 并會帶來嚴重的后果 無法轉移又不能承受時 通過改變項目來規(guī)避風險 通常會通過修改項目目標 項目范圍 項目結構等方式來回避 風險的威脅 后備措施 后備措施 主要體現(xiàn)在后備費用 預留進度時間 后備技術力量三個方面 這些后備措施 在項目計劃中就應預留 保證在項目實施過程中 能充分調用后備力量解決問題 4 4 2 4 4 2 制定風險規(guī)避計劃制定風險規(guī)避計劃 針對需要采取規(guī)避策略的風險事件 要制定規(guī)避計劃 一旦發(fā)生風險事件 就實施規(guī)避計劃 比如 在一個軟件開發(fā)項目中 某開發(fā)人員有可能離職 離職后會對項目造成一定的影響 則 應該對這個風險事件開發(fā)應對計劃 過程可以參照如下 1 進行調研 確定流動原因 2 在項目開始前 把緩解這些流動原因的工作列入風險管理計劃 3 項目開始時 做好計劃一旦人員離開時便可執(zhí)行 以確保人員離開后項目仍能繼續(xù)進行 4 制定文檔標準 并建立一種機制 保證文檔及時產生 5 對所有工作進行細微詳審 使更多人能夠按計劃進度完成自己的工作 6 對每個關鍵性技術人員培養(yǎng)后備人員 在考慮風險成本之后 決定是否采用上述策略 4 4 3 4 4 3 風險管理報告風險管理報告 無論項目進展的情況如何 都必須將風險管理的計劃 行動 結果記錄到 風險和問題跟蹤列 表 在過程管理平臺中填寫和維護 風險列表 風險管理的持續(xù)性要求 風險和問題跟蹤 列表 的連貫性和不間斷性 因此 該報表為項目的實施 控制 管理 決策提供信息基礎 對于項目采用的特殊的風險管理問題和措施 可在項目 開發(fā)計劃的風險管理部分說明 參見 項目 開發(fā)策劃書 也可以形成單獨的風險管理計劃文檔 5 5 風險監(jiān)控風險監(jiān)控 制定了風險防范計劃后 風險并非不存在 在項目推進過程中還可能會增大或者衰退 因此 在項目執(zhí)行過程中 需要時刻監(jiān)督風險的發(fā)展與變化情況 并確定隨著某些風險的消失而帶來 的新的風險 風險監(jiān)控包括兩個層面的工作 其一是跟蹤已識別風險的發(fā)展變化情況 包括在整個項目周期內 風險產生的條件和導致的后 果變化 衡量風險減緩計劃需求 其二是根據風險的變化情況及時調整風險應對計劃 并對已發(fā)生的風險及其產生的遺留風險和 新增風險及時識別 分析 并采取適當的應對措施 對于已發(fā)生過和已解決的風險也應及時在 風險和問題跟蹤列表 進行記錄 在過程管理平臺中填寫和維護 風險列表 風險貫穿于項目的整個生命周期中 因而風險管理是個持續(xù)的過程 建立良好的風險管理機制 以及基于風險的決策機制是項目成功的重要保證 風險管理是項目管理流程與規(guī)范中的重要組 成部分 制定風險管理規(guī)則 明確風險管理崗位與職責是做好風險管理的基本保障 6 6 附錄附錄 6 1 6 1 項目風險分析列表項目風險分析列表 風險風險 分類分類 潛在風險因素潛在風險因素規(guī)避措施建議規(guī)避措施建議 合同類型風險 合同的約束風險 合同中與第三方的合作風險 主承包商風險 子承包商風險 相關承包商風險 協(xié)作管理方風險 賣方因素風險 政治因素風險 商業(yè) 風險 目標 范圍不明確 不知項目何時終結 規(guī)范銷售 采用標準合同 工作任務 書模板 簽訂補充協(xié)議 說明 備忘 錄 客戶的技術素養(yǎng)不足 客戶的承諾風險 客戶內部對需求理解不一致 客戶的需求不明確 對客戶需求變化缺少控制機制 客戶需求頻繁變更 客戶需求發(fā)生重大變化 無法與客戶就交付形式 交付時間和交付內容達成共識 客戶對軟件產品不認可 不在交付清單和試運行報告上 簽字 客戶不驗收或拖延驗收 客戶期望與產品功能差距太大 客戶反映強烈 高級工程師介入售前 提供業(yè)務咨詢 實施策略 方案設計等支持 盡量不 開空頭支票 變通解決 說服客戶 降低客戶需求 客戶 方風 險 客戶對實施人員 最后應用效果不滿意 發(fā)生投訴的情 況 實行工程師認證上崗制度 提高實施 工程師的素質和工作能力 對項目實 施質量管理 由高級工程師對方案進 行審核 及時更換實施工程師 由高 級工程師對方案進行優(yōu)化調整 人員時間和精力不能滿足 人員的質量意識不強 人員的協(xié)作意識不強 人員的溝通意識不強 人員的積極性不夠 人員沒有接受過必要的培訓 人力 資源 風險 人員不穩(wěn)定 發(fā)生變動 在項目組成立時要求所有項目組成員 保持固定 健全項目組成員的激勵措 施 發(fā)生人員變動前及早安排其它人 員接替工作 離開時辦理工作交接 人員數量緊張 缺少必要的軟件 硬件設備不具備 測試所需的資源要求和安排不能滿足 測試環(huán)境準備不充分 軟硬 件資 源和 環(huán)境 風險 關鍵計算機資源 指對計算機內存和硬盤空間這些資源 可能超過目前可能提供的數量這種風險 項目時間緊張 來自項目進度監(jiān)控的風險 軟件產品生命周期各個階段發(fā)生進度延遲 項目計劃任務不明確 進度安排和資源配置不合理 進度 風險 計劃沒有得到切實執(zhí)行 實施進度延期 不能如期完成 階段工作 制定計劃時盡量考慮全面 留有余地 取得客戶高層的支持和推動 克服障 礙 及時調整下步計劃 并將計劃調 整原因形成備忘錄 提交客戶確認 如涉及到工作量的增加 考慮是否追 加實施費用 項目費用是否超過預算成本 風險是否有足夠的資金可用 系統(tǒng)所采用的軟件技術風險 系統(tǒng)所采用新技術 系統(tǒng)所采用的技術是否成熟 項目經理 項目人員技術能力不足 技術 風險 專利風險 需求的范圍界定 需求的穩(wěn)定性 能否獲得客戶對需求文檔的承諾 以保 證客戶不隨便變更需求 需求的完整性 需求的清晰性 需求是否含糊不清 需求的合理性 需求的可行性 需求的可描述性 文檔能否正確 完備地表達用戶需求 需求開發(fā)人員對項目所涉及的具體業(yè)務以及對用戶需求 的理解 沒有正確理解客戶需求 沒有合適的需求分析方法和建模工具 軟件 需求 階段 過程 風險 需求的變更 實施范圍在工作任務書中明確定義 需求調研結果進行確認 需求 實施 范圍的調整必須執(zhí)行項目變動控制程 序 考慮是否追加實施費用 簽訂補 充協(xié)議 設計的功能性 設計的難度 設計的接口 設計的性能 設計的易測性 設計的硬件約束 設計的可實現(xiàn)性 軟件 設計 階段 過程 風險 編碼及單元測試的可行性 設計方案是否能滿足客戶需求 設計的變更 軟件的易用性 軟件的可擴展性 源代碼書寫的規(guī)范性 源代碼的可讀性 單元測試覆蓋率 軟件 編碼 階段 過程 風險 代碼管理風險 集成測試的環(huán)境風險 測試范圍不合理 無法明確定義測試項 測試用例的選擇缺乏代表性 不完備 測試人員的培訓不充分 軟件 測試 階段 過程 風險 測試所需的資源要求和安排不能滿足 工程特性的可維護性 工程特性的可靠性 工程特性的保險措施 軟件 維護 過程 風險 工程特性的安全性 軟件產品出現(xiàn)功能性錯誤 軟件產品出現(xiàn)性能問題 單元測試問題報告數量過多 各單元模塊集成后 整個系統(tǒng)出現(xiàn)重大問題 系統(tǒng)的某些性能指標不能達到客戶需求明確定義的驗收 指標 軟件產品復制過程中發(fā)生質量問題 質量 風險 系統(tǒng)出錯甚至數據丟失 完善產品 上線前的測試 建立規(guī)范 操作 數據備份等系統(tǒng)運行制度 公司高級管理層對本項目不夠重視 人員管理風險 配置管理風險 無法正確標識本項目的風險 不能正確評價項目風險 選擇的風險對策不能有效地化解或減輕風險 無法發(fā)現(xiàn)風險管理計劃中風險識別 風險評價 風險策 略的問題 其他 風險 項目失敗導致的市場風險 提供合適的 穩(wěn)定的產品 按實施方 法論規(guī)范實施 合同 工作任務書的 定義和約束 目