XX項目風險評估表項目名稱:報告人:日期 (年/月/日):1. 項目風險評估表使用指南第一部分風險評估問卷 第二部分常見的高風險問題/應對行動注意：不同的風險承受度應制定不同的應對計劃。第一部分風險評估問卷Characteristics 風險特征Low Risk 低Medium Risk 中High Risk 高ORGANIZATION 組織A. 范圍A1項目范圍是: 明確且了解的 大部分確認但可能改變 不明確且/或可能改變A2.公司/商務需求: 了解且符合 瞭解但極為復雜,或符合但未明確定義 非常復雜或非常模糊A3.系統可用性包括 可使用的通路及其停工期 需連續使用A4.預估總需求人力小時數: 低于1,000小時 1,000 至 5,000小時 遠大于5,000小時A5.現有資料的質量: 好且易于使用 明確但難以使用,或不明確但易于使用 差或難以使用A6.項目的執行: 不需客制化 需要客制化 需要高度客制化A7.項目的執行: 穩定的產品或市場宣傳模式 新產品或新的市場宣傳模式B. 時程B1.項目主要里程碑和完成日期: 彈性 可由用戶和項目組員商議后決定 確定 已定且脫期后可能會影響商機 剛性 已由具體的營運委員會決定,或規定的要求超過項目團隊的掌控能力B2.預估項目周期: 低于 3 個月 3 到 12 個月 遠大于 12 個月C. 預算C1.預算是由有經驗的人,使用已證實有效的成本預估程序來生成: 是 由有經驗的人操作有效的預算程序 有一些經驗或程序 否 人員無經驗且無程序C2.項目資金符合或大于成本預算和穩定性. 預算大于需求且/或預期穩定. 預算等于成本且預期相對穩定. 預算低于需求且/或穩定性高度不確定.D. 項目關聯性D1.本項目依賴相關項目的關系可以形容為: 輕微依賴, 即使沒有相關項目的產出仍可完成 有些依賴,沒有相關項目的產出可能造成延期 高度依賴, 無相關項目的產出無法繼續進行E. 人力資源E1.項目經理的經驗和培訓是: 最近在類似項目管理上取得了成功 最近在非類似項目管理上取得了成功或經過培訓但無經驗 無近期經驗或未經項目管理培訓E2.依需要管理工具和技術的使用來描繪項目組員. 熟練使用工具和技術 對使用工具和技術經過正式的培訓,但少或無實際經驗 無正式培訓或無實際使用經驗E3.項目組員是: 同處一地 分處多處F. 發起人/高層領導的支持F1.項目發起人是: 明確的，對項目認可且充滿熱情的 明確的，但缺乏熱情的 既不明確也缺乏熱情G. 其他生意或組織上的影響G1.是否需要能夠提供項目所需相關知識技能的項目參與人： 項目中不需要或項目組成員已經具有豐富的相關知識 在某些方面經驗不足 沒有或當下沒有找到合適的人選G2是否需要改變組織流程和政策： 完全不需要或很少 偶爾到經常性的改變 實質性的改變G3.描述項目結果對業務流程或組織變革的影響： 沒有或只是很微小的變遷 中度變遷 重大變革或目前還不清楚G4.將受到此改變影響的部門： 一個或兩個 三個或四個 五個以上G5.項目的接收部門和利益相關部門對于該項目將帶來的變化的接受度，你會怎么評分？ 高接受度（充滿熱情和期待） 一般接受度 低接受度（消極且很難融入）GENERAL Technical and Performance Risks 整體 技術和績效風險H. 技術H1.將會用到的技術是： 成熟的（已在使用的軟件，硬件，專業術語，數據庫和工具） 演進中的 實驗性的（新的軟件，硬件，語言，數據庫，工具或最新推出的） H2.對技術的要求： 與公司其他使用的類似 全新的，復雜的H3.技術的重點： 項目組成員都很清楚 項目組成員并不清楚I. 績效I1.績效目標： 明確，合理 不清晰，不明確，不現實（例如：每件事都要很完美） 項目管理計劃，問題和變革管理，質量保障J. 風險評估J1.通過項目管理風險評估檢查表來進行項目風險管理的整體評估 制定了很完整的項目計劃，并且能夠運用組織中的項目管理方法來實現 合理的，基本完成的項目計劃和流程，但是仍然有一些問題沒有明確 沒有連續性的完整的項目計劃，即使有質量也不高，同時/或者在項目流程中有許多關鍵性的問題沒有明確外部供應商，法律，環境，條例K. 供應商K1.如果需要局部的委外執行： 供應商對市場很熟悉 供應商剛剛進入該市場K2.項目是否需要承包商？承包商是否對項目做出了承諾？ 不需要承包商 需要一些承包商（少于50%），而且在項目開始之前承包商會接到明確的任務 50%以上的項目工作將交給承包商，但是在項目開始之前承包商并不清楚其全部任務L. 其他（根據項目實際情況來添加）L1.第二部分典型的高風險問題/應對行動高風險要素/潛在問題 風險應對行動A. 范圍A1.項目范圍模糊不清： 難以作出合理的預測評估 可能會花時間和成本在項目范圍之外 難以收集準確的需求信息 難以明確項目定義和工作計劃 難以制定范圍變更程序 無法明確項目交付品 在計劃中嚴格地定義項目范圍 明確項目范圍的各要素，例如哪些部門會受到影響，需要哪些項目交付品，需要哪類信息 清晰明確哪些是項目范圍之外的(本項目不包含:) 從一開始就將業務需求定義在較高的層次，然后以此由下至上的來定義項目范圍 讓項目發起人對沖突的項目范圍作出決策 在對項目任務，成本或周期進行評估時記錄下所有的范圍假設 運用圖表來標識項目范圍和替代方法 預先制定嚴格的范圍變更程序 確保正式性地通過項目定義和業務需求并且獲得相應的資源配備 將范圍說明分發給所有的項目利益相關人以獲得確認 在項目范圍沒有清晰明確之前不要開始項目A2.項目的業務需求很模糊或復雜： 難以正確地記錄相關需求 難以使用工具來記錄相關需求 難以明確項目期望是什么 有可能項目最終交付品無法達到業務的要求 可能是缺乏客戶關注和信息的信號 運用合作應用程序設計（JAD）來收集所有項目利益相關人的需求 使用原型重復式開發的技術來幫助發掘使用者對新系統的需求 與項目發起人，高層管理者溝通以獲得全面的指導 為客戶提供培訓，讓其明白如何思考和表達其業務需求 確保將最終明確的業務需求記錄在案，并執行相應的變更管理程序A3.需要連續地使用系統： 檢修或事故問題可能會導致產量的降低或收益的減少 可能需要創造部分冗余，因此增加系統的復雜度 可能需要更新，更先進的技術 需要更多的程序和流程來維護系統環境 分配更多的時間來分析，設計，測試系統并實施全面質量保障行動 將更多的時間和精力放在技術架構上 將更多的時間和精力放在數據庫設計上 使用行業最優的技術和流程 為項目組提供相應的培訓，使其了解連續地使用系統意味著什么 準確地指出究竟需要連續地使用系統的哪個部分 尋求內部或外部的專家來驗收整體的技術設計和架構 制定堅實可靠的災難復原計劃 與軟件和硬件供應商建立和發展良好的伙伴關系A4.高預期工作量： 高工作量意味著項目很復雜，需要投入大量的人力 更難以有效地與團隊溝通 當需要快速決策時瓶頸就會出現 更可能出現人員問題 可能會有更高的人員流動率 需要培訓更多的人 使用項目管理工具來控制資源的使用 讓項目組成員使用周報表來監控他們所分配的工作任務的進展程度 任命小組長來管理下屬小組 通過組織團隊建設活動來建立團隊凝聚力 召開計劃進度會議，讓人們知曉項目進展狀況 使用內部系統流程進行范圍，問題，質量和風險管理 將項目分解成更小的，周期更短的小項目 為了讓項目組成員意識到其他相關的人員和小組活動，減少每個人每天可用的項目工作時間A5.目前數據質量太低難以進行轉換： 需要做更多的工作來把舊的數據轉換到新的系統中 過濾后的數據仍然可能在新系統中造成問題 數據轉換問題能夠導致嚴重的項目延期 確保所有舊數據都毫無差錯地轉換到了新的系統中 在進行最終的轉換前要嚴格地測試轉換程序 評估由于轉換數據而花費的成本和造成的困難是有價值的。弄清楚新的系統是否只能運轉新的數據 讓舊的系統維持運轉一段時間以獲取舊的數據 在數據轉換之前盡可能地對舊的數據進行人工過濾A6.需要高度定制化的打包執行： 定制化會使項目更加復雜 對某一部分的修改可能會導致其他部分的問題 定制化會導致績效低下 定制化會讓新技術的運用變得更復雜 大量的定制化可能意味著之前選擇了錯誤的打包工具 很有可能要花更長的時間來實施打包工具 定制化會需要更多地依賴供應商 考慮其他的打包工具 考慮定制化的發展 減少業務需求，這樣也不用定制化了 從供應商處獲得確定的修改成本和周期，并將其記錄進你的整體工作計劃 管理與供應商的關系，確保所有必須的工作都能按時完成 確保項目發起人通過定制化方案 為保證正常運作和績效，全面徹底地測試修改后的打包工具 利用供應商日志來追蹤問題和項目里程碑A7.打包執行是一個全新的產品： 會有更大的問題風險 更多地依賴供應商來確保迅速地解決問題 安裝，測試和配置使用將需要更長的周期 幾乎很難預知這個打包工具是否符合所有的業務需求 盡早為項目組成員安排打包工具的相關培訓 為項目增派一個有相關產品經驗的內部資源或咨詢師 在全面實施之前安排打包工具的試點，使項目組盡快熟悉起來 與供應商就支持度和問題解決時間達成共識 如果有其他公司也在使用同樣的產品，看看能不能將項目延期到其使用時間之后 搜尋其他使用過該產品的公司，尋求他們的反饋和關鍵所得B.時程B1.項目重要里程碑和/或完成日期是固定的，但這是由于業務承諾或法律要求而被事先固定的，不受項目組的控制： 工作必須以這個日期期限為指導 可能無法在期限內完成所有必需的項目活動 很有可能無法達到排程的要求 趕工和時程的壓力很有可能導致項目工作中無法改正的錯誤 根據必需的項目活動對排程再進行協商和談判 對范圍再進行協商和談判，使項目活動能夠在規定的時間內完成 根據實際的預測評估與客戶/項目所有者/項目發起人重新建立新的共識 執行積極的項目跟蹤和監控計劃 進行常規性的時程報告及溝通B2.預測項目周期會很長: 更難管理項目排程 使項目組和客戶更加容易失去焦點和重心 項目很有可能會失去組織的支持和承諾 業務需求很有可能會變化 軟件或硬件版本(技術和工具)很有可能會變化 很難在項目開始時營造緊迫感 很有可能造成項目組成員和客戶的流失 將項目分解成更小的，周期更短的小項目 明確項目里程碑，使其按進度發展和完成 要持續不斷地使用正式的變動管理程序 輪換項目組成員的角色，保持其持續較高的興趣度 盡可能地走在預計進度前面 在項目初始階段就營造一種緊迫感 組織團隊建設活動，建立團隊凝聚力防止人心渙散 確保所有的重要交付品都正式通過，然后再引入變革管理 使技術設計和架構決策盡可能的靈活，為潛在的變更做好準備C.預算C1.預算不是使用已證實有效的成本預估程序或有經驗的個人建立的： 預算很有可能不準確 設計的預算計劃不便于跟蹤和監控 對于哪些工作能在預算內完成會有不現實的期望 使用成熟的工具或有經驗的個人重新評估項目 修改項目范圍, 使其能夠納入可用的資金范圍內 在未優化原預算計劃之前不要開始項目C2.項目資金到位比預算少，而且不穩定： 項目不可能完成預期的目標 項目很有可能超出其預備資金 對項目范圍再進行協商和談判，使其能夠納入可用的資金范圍內 在獲得充足的預算或減少項目范圍之前不要開始項目D.項目關聯性D1.項目高度依賴于另外一個獨立的關聯項目，如果沒有收到關聯項目的最終交付品就無法展開： 不在項目控制范圍內的事情能夠嚴重地影響項目的產出和實現目標的能力 關聯項目的交付品如果延期就很有可能造成項目進度的延遲 修改其中一個或所有的項目排程，使項目交付品能夠整合起來 對項目范圍和/或排程再次進行協商和談判 就滿足項目的需求與關聯項目達成共識，并將其記錄在案 為了最大限度地減少沖突，兩個項目要緊密合作和相互監控E.人力資源E1.缺乏項目管理經驗： 可能要花更長的時間來定義項目和建立工作計劃 可能會有更多判斷上的失誤，導致返工或項目延期 更難以組織和管理一個復雜的項目 可能對全面的項目管理實踐不熟悉 可能不知道何時應該尋求幫助 提供事前的項目管理培訓 指派一個更高層管理者來輔導項目經理 建立并執行有力的質量保障流程來確保項目正常的開展 確保重要交付品正式通過 通過有力的團隊領導和團隊成員帶來更多相關經驗E2.不熟悉或并不準備使用項目管理流程： 項目團隊可能無法知曉如何提出問題，范圍變更和風險 當內部流程越來越復雜和難以管理時，項目有可能不受控制 將缺乏良好的溝通 完成的項目交付品可能樣式不統一 無法及時地提出問題，由于無法考量對項目的影響，范圍變更也可能無法實行，風險可能被忽略，最終無法實現最優的質量 很有可能無法預期項目潛在的問題和困難 向項目經理和項目團隊提供完整的項目管理流程和程序培訓 為項目分派一位有經驗的項目管理教練或導師 將整體項目分解成更小的項目，從而能夠進行較不嚴謹的項目管理 在項目開始之前明確并認同一套項目管理程序，包括問題管理，變更管理，風險管理，和質量管理 建立一個強有力的溝通計劃，以確保每個成員都知道項目的進展并提供反饋 申請并獲得隨時對問題，風險，范圍變更和質量管理的投入E3.分處多地的項目團隊： 更難以有效地溝通 缺乏充分的團隊互動和凝聚力 很難與整個團隊建立私人的關系 有些成員可能會感到被孤立，而非團隊的一員 技術問題可能導致生產力下降 試著將團隊聚集到一個地方，或至少在項目啟動的階段 建立一個積極的溝通計劃確保有效地團隊溝通 召開例會，讓整個團隊能夠進行面對面的溝通 安排團隊建設活動，讓整個項目組碰面 準備后備的溝通工具和方式，以防主要的技術出現問題 與遠距離的團隊成員保持經常性的電話聯系 建立一個中央數據庫，方便所有的團隊成員來查閱存儲項目文件F. 發起人/高層領導支持F1.沒有明確的或正式授權的項目發起人： 項目也許無法獲得其所需的資源 項目也許無法獲得所必需的長期的承諾 政治斗爭可能會使項目延期 問題和變更申請可能無法及時地得到解決 建立一個強有力的指導委員會來幫助指導整個項目 為解決部門間的沖突建立一套流程 嘗試更換成另一個發起人 請求發起人向另一個能夠從項目利益出發的人授權 不要開始項目G.業務或組織的影響G1.提供項目知識的項目參與人或是無法加入項目或是仍未明確： 缺乏所需的項目知識將會為準確的完成項目帶來負面的影響 項目接收人將不會滿意 為了獲得所需的項目知識，就資源承諾進行再次協商和談判 為獲得所需的項目知識，就項目進展進行再次協商或談判 不要開始項目G2.業務流程和政策需要實質性的改變： 政策的改變會使項目延期 新的流程會使人們感到困惑，從而影響他們使用此流程的能力 有可能開始時無法完全地整合新的流程 如果新的流程無法完全地應對所有的突發狀況，那它將是無用的 如果沒有正確的程序支持，系統功能將會癱瘓 實質性的流程改變可能會導致破壞性行為 記錄目前所有的政策和流程，確保他們的正確性 準確地闡述新舊流程之間的差別 盡可能早地就潛在的變遷進行溝通 確保客戶了解流程和政策的改變 指定一個人來負責所有流程和政策的改變 建立一個積極的溝通計劃，使客戶能夠隨時了解和獲得相關的信息 對新的流程進行試點，以確保他們的有效性和準確性 將是否成功的實施新的政策和流程作為項目經理績效評估的一部分 向客戶公開流程的改變以獲得更好的建議，同時讓他們感到自己的影響力G3.組織結構需要實質性的改變： 組織的不確定會導致組織內的畏懼感 如果項目團隊的注意力都放在了組織層面，那他們將不會集中精力于項目上 在新的組織中人們可能會擔憂失去工作 如果人們不歡迎組織的變革，那他們可能不會使用新的系統 不確定性可能會延遲決策 組織變革可能會造成以政治為目的的決策 記錄新的組織中存在的擔憂，并尋找相應的辦法來減輕這些擔憂 盡早地經常性地就潛在的變革和相應的業務原因進行溝通 讓所有利益相關者的代表都投入到組織的設計和規劃中 投入人力資源來解決潛在的人員問題G4.大量的部門將會受到影響： 協同合作會更加復雜 通過或批準某項決議會更加麻煩和費時 更難以達成共識 計劃和需求將涉及更多的人和團隊 更難以了解不同部門的主要利益相關人 執行會更加困難和復雜 建立一個正式的決議批準流程 建立一個代表整個利益相關團體的指導委員會 讓項目發起人參與到項目中，并隨時準備干涉不同的部門 讓每個組織的代表參與需求提出，質量保證和測試 讓來自不同部門的人有機會見面和互動 讓項目組嚴格遵循整個項目目標和優先順序 在所有可能的情況下使用建立共識的技巧G5.客戶的對項目的認可度低/很難互動： 可能會導致對商業價值的信心不足 更難以從客戶處獲得所需的時間和資源 更難以收集業務需求 客戶可能會破壞或阻礙項目的開展 建立一個積極的溝通計劃，讓客戶參與到項目中，并讓其了解其中的商業利益 建立用戶小組，明確其關心的問題并激發其積極性 讓用戶加入到計劃和需求收集過程中 讓項目發起人幫助激起客戶對項目的積極性 尋找機會在輕松有趣的環境中推銷項目 當需要客戶的資源時，要積極地去得到客戶對此的承諾 不要開始項目H.技術H1.新的和不熟悉的項目技術（或新發布的）： 學習曲線可能會導致較低的初期產出 可能存在新舊技術整合的問題 對技術變化的抵制可能會導致項目的延期 在測試新技術時可能會有困難 可能無法正確的安裝或架構技術，而導致項目的延期 新的技術工具會導致更長的交付時間 新的技術可能會需要大量的轉換工作 當專業技術都用于優化和架構技術時，系統績效可能會很差 盡早提供對于新技術的實踐性的培訓 向需要對新技術進行安裝，使用和支持的人員進行培訓 當需要時要充分利用供應商的技術專家 利用外部熟悉此技術的專業顧問 確保有足夠的測試環境，這樣使用新的技術也不會影響產出 確保對新技術的功能，特性和性能都進行了徹底扎實的分析 對如何使用新的技術建立一套程序和規范 一開始在小范圍對新技術實行試點H2.新的,復雜的技術： 可能很難理解需求和所需的設計 新舊技術間可能有整合問題 可能很難測試復雜的技術 技術越復雜，問題風險越大 在整合或系統測試完成后才能發現技術無法解決的問題 利用系統和技術設計檔案來弄清各項技術是如何組合起來的 明確整體系統技術架構，并請公司中有經驗的專業人員進行審查通過 請外部的顧問審查架構建議書以獲得更多的反饋和確認 一開始在小范圍內對新的技術進行試點 盡可能多的在架構中使用經過驗證的和熟悉的技術 使用同一供應商的復合產品以使整合系統的過程更加流暢和容易 使用有公開標準和架構的產品以減少整合問題帶來的風險H3.項目團隊對項目重點并不了解： 項目團隊成員需要更長的學習曲線 項目可能會在開始階段就脫節 無法了解業務需求是否有意義 關鍵的特性和功能可能會被遺漏 需要從最初就依靠客戶來提供有關項目重點所有的專業知識和技術 盡早地提供實踐性的培訓 將關鍵客戶帶入項目團隊中 花額外的時間來了解和記錄需求 對所需的多重項目重點建立相關專家審批的流程 通過合作應用程序設計（JAD）來收集所有利益相關人的需求 更頻繁的與客戶進行項目的預排 在評估時安排更多的時間進行使用分析和設計活動I.績效I1.績效目標不清,不明確或不現實（例如一切都要完美）： 項目團隊會因為主次目標不清而陷入困境 如果績效需求沒有在一開始就記錄在案，那項