第一篇：項目管理中可能存在的風險

1.最常見的進度計劃風險

1）功能無限蔓延；

2）需求鍍金或開發(fā)人員鍍金；

3）質量不定

4）計劃過于樂觀

5）設計欠佳

6）銀彈綜合癥

7）研發(fā)導向開發(fā)

8）人員薄弱

9）來自上級對項目需求的干預

2.進度計劃風險完整列表

2.1 計劃編制風險

1）計劃、資源和產(chǎn)品定義全憑決策組或上層領導口頭指令，并且不完全一致；

2）計劃是優(yōu)化的，是“最佳狀態(tài)”；

3）計劃忽略了必要的任務；

4）計劃基于使用特定的小組成員，而那個小組成員其實指望不上。

5）在限定的時間內(nèi)無法建成已定規(guī)模大小的產(chǎn)品；

6）產(chǎn)品規(guī)模比估計的要大一些；

7）工作量大于估算數(shù)；

8）進度已經(jīng)拖延的項目在重新評估時過于優(yōu)化或忽視項目歷史；

9）過度的進度壓力造成生產(chǎn)率下降；

10）目標日期提前，但沒有相應地調(diào)整產(chǎn)品范圍或可用資源；

11）一個任務的延遲導致相關任務的連鎖反應；

12）涉足不熟悉的產(chǎn)品領域，花費在設計和實現(xiàn)上的時間比預期的要多。

2.2 組織和管理

1）項目缺乏一個有凝聚力的最高領導人；

2）由于前期乏力，項目長時間被擱置；

3）解雇和削減開支導致項目小組能力下降；

4）僅由管理層或市場人員進行技術決策，導致計劃進度延長；

5）低效的項目組結構降低生產(chǎn)率；

6）管理層審查/決策的周期比預期時間長；

7）預算削減打亂項目計劃；

8）管理層做出了打擊項目組織積極性的決定；

9）非技術的第三方的工作比預期延長（如審批，采購等）；

10）計劃性太差，無法適應期望的開發(fā)速度；

11）項目計劃由于壓力而放棄，導致開發(fā)混亂、低效；

12）管理層強調(diào)英雄主義，而忽視客觀確切的狀態(tài)報告，這會降低發(fā)現(xiàn)和改正問題的能力。

2.3 開發(fā)環(huán)境

1）設施沒有及時到位；

2）設施到位，但不配套；

3）設施擁擠、雜亂或者破損；

4）開發(fā)工具未能及時到位；

5）開發(fā)工具不如期望那樣有效，開發(fā)人員需要時間創(chuàng)建工作環(huán)境或切換新的工

具；

6）開發(fā)工具的選擇不是基于技術需求，不能提供計劃要求的性能；

7）新開發(fā)工具的學習期比預期的長，內(nèi)容繁多。

2.4 最終用戶

1）最終用戶堅持新的需求；

2）最終用戶對于最后交付的產(chǎn)品不滿意，要求重新設計和重做；

3）最終用戶不買進項目產(chǎn)品，無法提供后續(xù)支持；

4）最終用戶的意見未被采納，造成產(chǎn)品最終無法滿足用戶期望，而必須重做。

2.5 決策組

1）決策組堅持新的需求；

2）決策組對規(guī)劃、原型和規(guī)格的審核/決策周期比預期長；

3）決策組沒有或不能參與規(guī)劃、原型和規(guī)格階段的審核，導致需求不穩(wěn)定和耗時的重復；

4）決策組答復的時間比預期長（如回答需求中需澄清的問題）；

5）決策組堅持技術決策而導致進度計劃延長；

6）決策組對開發(fā)進度管理過細，導致實際進展變慢；

7）決策組提供的組件無法與開發(fā)的產(chǎn)品匹配，導致額外的設計和集成工作；

8）決策組提供的組件質量欠佳，導致額外的測試、設計和集成工作，以及額外的決策組關系管理工作；

9）決策組要求的支持工具和環(huán)境不兼容、性能差或者功能不完善，導致生產(chǎn)率降

低；

10）決策組不接受交付的軟件，盡管它滿足了所有的規(guī)格；

11）決策組期望的開發(fā)速度是開發(fā)人員無法達到的。

2.6 承包商

1）承包商沒有按承諾交付組件；

2）承包商遞交的組件質量低下無法接收，必須花時間改進質量；

3）承包商沒有買進項目開發(fā)需要的工具，進而無法提供需要的性能水平。

2.7 需求

1）需求已經(jīng)成為項目基準，但變化還在繼續(xù)；

2）需求定義欠佳，而進一步的定義會擴展項目范疇；

3）添加額外的需求；

4）產(chǎn)品定義含混的部分比預期需要更多的時間。

2.8 產(chǎn)品

1）錯誤發(fā)生率高的模塊需要比預期更多的測試、設計和實現(xiàn)工作；

2）校正質量低下不可接受的產(chǎn)品，需要比預期更多的測試、設計和實現(xiàn)工作。

3）在一個或多個新興領域推廣計算機技術使得計劃進度的延長不可預期；

4）由于軟件功能的錯誤，需要重新設計和實現(xiàn)；

5）開發(fā)額外不需要的功能（鍍金）延長了計劃進度；

6）要滿足產(chǎn)品規(guī)格與速度要求，需比預期更多時間，包括重新設計和實現(xiàn)的時間；

7）嚴格要求與現(xiàn)有系統(tǒng)兼容，需要進行比預期更多的測試、設計和實現(xiàn)工作；

8）要求與其他系統(tǒng)、復雜系統(tǒng)或不受本項目控制的系統(tǒng)相連，導致無法預料的設

計、實現(xiàn)和測試工作。

9）要求在不同操作系統(tǒng)下運行將花費比預期更長的時間；

10）在不熟悉或未經(jīng)檢驗的軟（硬）件環(huán)境中運行產(chǎn)生未預料的問題；

11）開發(fā)一種對組織全新的模塊將比預期花費更長的時間；

12）依賴正在開發(fā)中的技術將延長計劃進度。

2.9 外部環(huán)境

1）產(chǎn)品依賴政府規(guī)章，而規(guī)章的改變將是不可預期的；

2）產(chǎn)品依賴草擬中的技術標準，而最后的標準將是不可預期的。

2.10 人員

1）招聘人員所花時間比預期的長；

2）作為先決條件的任務不能按時完成（如培訓、其它項目）；

3）開發(fā)人員和管理層之間關系不佳導致決策緩慢，影響全局；

4）項目組成員沒有全身心投入項目，進而無法達到需要的產(chǎn)品性能水平；

5）缺乏激勵措施，士氣低下，降低了生產(chǎn)能力；

6）缺乏必要的規(guī)范，增加了工作失誤與重復工作；

7）某些人需要更多時間適應不熟悉的軟件工具和環(huán)境、硬件環(huán)境、編程語言；

8）項目結束前，合同制人員離開團隊，或雇員辭職；

9）項目后期加入新的開發(fā)人員，額外的培訓和溝通降低現(xiàn)有成員的效率；

10）項目組成員不能有效地一起工作；

11）由于項目組成員間的沖突，導致溝通不暢、設計欠佳、接口錯誤和額外的重復工作；

12）有問題的成員沒有調(diào)離項目組，損害了項目組其他成員的積極性；

13）項目的最佳人選未加入項目組；

14）項目的最佳人選已加入項目組，但因其他原因未能合理使用；

15）沒有找到項目急需的具有特定技能的人；

16）關鍵人物只能兼職參與；

17）項目人員不足；

18）任務的分配與人員技能不匹配；

19）人員工作的進展比預期的慢；

20）項目管理人員怠工導致計劃和進度失效；

21）技術人員怠工導致工作遺漏或質量低下，工作需要重做。

2.11 設計與實現(xiàn)

1）設計過于簡單，無法確定主要事件，并導致重新設計和實現(xiàn)；

2）設計過于復雜，導致一些不必要的工作，影響實現(xiàn)效率；

3）設計質量低下，導致重復設計和實現(xiàn)

4）使用不熟悉的方法，導致額外的培訓時間，并重犯前期使用這種方法時導致的錯誤；

5）產(chǎn)品采用低級語言來實施，導致生產(chǎn)率比預期的低；

6）一些必要的功能無法使用現(xiàn)有的代碼和庫實現(xiàn)，開發(fā)人員必須使用新庫或自選

開發(fā)所要的功能；

7）代碼和庫質量低下，導致需要額外的測試、錯誤修正或重做；

8）過高估計了增強型工具對計劃進度的節(jié)省量；

9）分別開發(fā)的模塊無法有效集成，需要重新設計或重做。

2.12 過程

1）大量的紙面工作導致進程比預期的慢；

2）進程跟蹤不準確，導致無法預知項目是否已落后于計劃進度；

3）前期的質量保證行為不真實，導致后期的重復工作；

4）質量跟蹤不準確，導致無法得知影響進度的質量問題；

5）太不正規(guī)，導致溝通不足，質量問題和工作重做；

6）過于正規(guī)，導致過多耗時無用的工作；

7）向管理層撰寫進度報告占用的開發(fā)人員的時間比預期的多；

8）風險管理粗心，導致沒有發(fā)現(xiàn)重大的項目風險；

9）軟件項目風險管理花費的時間比預期的多。

第二篇：IT運維管理中可能存在的關鍵問題

IT運維管理中可能存在的關鍵問題

一、IT運維管理可能存在的問題

1.1 IT運維機制不完善，流程操作層面缺乏統(tǒng)一

沒有建立起穩(wěn)定、規(guī)范的IT運維機制?，F(xiàn)有的IT運維流程的操作層面缺乏統(tǒng)一。如事件單提交之后，事件預判和優(yōu)先級的設定缺少統(tǒng)一、規(guī)范的指導文檔，僅以人員的主觀經(jīng)驗或約定俗成的方式指導事件的處理過程。有識別但無規(guī)范，有處理但無管理，有人員但忙于救火，有工具但支持力度不足。因此，“輕規(guī)范、重維護”的IT運維現(xiàn)狀容易造成因個體技能差異帶來IT運維的不穩(wěn)定，直接影響維護體系的效果。

1.2 經(jīng)驗不少，知識不多，過度依賴核心人員

在實際工作中積累的、有價值的經(jīng)驗僅存在于頭腦之中，未能作為書面的知識記錄規(guī)范地保存下來。經(jīng)驗始終僅能在小范圍內(nèi)得到傳播和繼承，無法在更大的范圍內(nèi)體現(xiàn)其價值。這樣導致了無論是事件性質的識別、優(yōu)先級的界定，還是疑難問題的分析診斷，均匯總至少數(shù)核心人員進行處理。這樣不僅增加了少數(shù)核心人員的工作量，也容易產(chǎn)生工作流程的“瓶頸”，降低運維團隊整體的事件及問題處理效率。

1.3 IT運維的績效考核機制尚不完善

主觀的績效考核難執(zhí)行，客觀的績效考核難制定，模糊的績效考核難見效。目前在績效考核方面雖然采用填寫工作表的方式對不同崗位的工作時間進行收集、評測和考核，在一定程度上體現(xiàn)了IT運維人員的工作量情況，但還是很難全面準確的反映IT運維人員真實的工作績效表現(xiàn)。因此，IT運維人員績效考核機制需要進一步完善，幫助組織構建獎懲分明的文化和環(huán)境，推動IT運維團隊的良性持續(xù)的發(fā)展。

1.4 IT基礎架構管理工具欠缺

基于門戶、財務管理、采購管理、人事管理、文件服務等構成了公司的核心業(yè)務系統(tǒng)。這些復雜的核心系統(tǒng)保證了整體業(yè)務的順暢運行。但作為支撐核心系統(tǒng)運行的IT基礎架構，目前僅有H3C的網(wǎng)絡監(jiān)控和基于Landesk的桌面管理系統(tǒng)?，F(xiàn)有的IT管理工具偏重于技術層面的故障發(fā)現(xiàn)及預警，對于發(fā)現(xiàn)的事件雖有相應的管理流程匯報，但仍未找到合適的工具為其提供全面、安全、穩(wěn)定的運行支持。

1.5 缺乏有效、完善的CMDB（配置項管理數(shù)據(jù)庫）

目前運行維護室僅有對關鍵應用系統(tǒng)相關IT設備設施的初步梳理，雖然在一定程度上收集了部分配置項信息，但是當前僅限于關鍵業(yè)務的、缺乏工具支持的、簡單的CMDB建設很難滿足今后全面實施信息化的需求。CMDB的建設是一個長期而艱巨的任務，不僅需要更詳細的配置項屬性數(shù)據(jù)、更準確的相互關系信息，而且也需要一個科學有效的配置管理模式及工具予以支持。

1.6 缺少面向用戶的IT服務報告 運行維護室對核心系統(tǒng)運行提供固定周期的IT 管理報告，如：系統(tǒng)運行報告、機房環(huán)境報告、備份報告、報告等等。但由于IT管理報告的內(nèi)容多以技術語言提交且僅限部門內(nèi)部和少數(shù)領導使用。作為外部用戶的業(yè)務部門不僅無法接觸，而且受專業(yè)所限難以理解，無法充分利用IT管理報告提供的信息。

在期望從成本中心向利潤中心轉型的過程中，運行維護室面向外部用戶時不能再以技術語言提交IT管理報告，而應該提交符合一般用戶閱讀需要的IT服務報告，實現(xiàn)IT運維的“服務于用戶，為用戶所用”的目的。

二、加強IT運維管理的措施

2.1 建立統(tǒng)一的IT運維管理體系，完善并規(guī)范IT運維流程

參照ITIL最佳實踐并結合公司的實際情況，將IT運維管理規(guī)范化為一系列標準流程，包括服務臺、事件管理、問題管理、變更管理、發(fā)布管理、配置管理和服務級別管理等。然后通過IT服務管理工具將各個IT運維流程集中在同一個平臺上進行管理?；跇藴实牧鞒腆w系和統(tǒng)一的管理平臺，與IT運維相關的資源（包括部門、人員）得以有效整合，并采用相互識別的“相同語言”進行深入、充分的溝通，提高生產(chǎn)效率和信息傳遞的及時性。

2.2 建立基于IT運維管理流程的IT人員績效管理和激勵機制 根據(jù)公司全面實施信息化的要求，建議運行維護室組建具備完善的專業(yè)知識和管理能力的IT運維管理團隊。因此，建立與IT運維管理流程體系相符的人員績效管理及激勵機制顯得尤為重要。建立量化KPI，對包括服務效率及服務質量等多方面進行業(yè)績考核。通過IT運維管理系統(tǒng)平臺，對IT運維人員的工作進行數(shù)量和質量上的記錄、統(tǒng)計和分析。在基于ITIL流程明確IT人員崗位職責的基礎上，定義關鍵考核指標并通過IT運維管理系統(tǒng)收集數(shù)據(jù)，進行整理、分析產(chǎn)生績效報告，最終實現(xiàn)IT績效管理的信息化。

2.3 提供面向客戶的IT服務報告，為業(yè)務部門和IT運維管理提供決策依據(jù)

參考ITIL及ISO20000的最佳實踐，可建立專門的工作流程對IT服務報告及IT運維服務管理信息作進一步的完善。實現(xiàn)向客戶或業(yè)務部門以“客戶化的語言”提供約定的服務信息，同時也能為內(nèi)部IT運維提供有價值的管理信息。如：某個時間段內(nèi)那些方面的故障出現(xiàn)的數(shù)量最多；那些方面的故障解決的效率最高或最低；IT維護人員的工作負荷統(tǒng)計；問題分布在哪些系統(tǒng)或設備等。這些服務信息統(tǒng)計，能幫助IT運維管理和決策部門進行決策和趨勢分析，從而做到對IT系統(tǒng)中的各類問題和相應的服務狀況進行全面掌握和了解。

2.4 支持經(jīng)驗和知識的共享化

提供豐富知識庫和完善管理。用戶通過知識庫，如FAQ、關鍵詞檢索等，可以初步搜尋解決方法，這樣問題就會以最小的資源開銷和最快的處理效率得以解決；IT維護人員通過知識庫及時、準確地選擇解決最優(yōu)方案，可解決大部分常規(guī)問題；資深運維人員、專家，可以根據(jù)故障發(fā)生的頻度，把經(jīng)過實踐證明正確的解決方案形成知識庫，供其他運維人員使用；另外，相關應用系統(tǒng)的業(yè)務處理人員可以通過共享的知識庫或實踐指導庫，提交或者獲取相關業(yè)務處理的知識。

2.5 建立并完善CMDB

實現(xiàn)用戶、資產(chǎn)、以往問題的歷史記錄等可查詢、可追溯IT運維管理系統(tǒng)通過組建CMDB對用戶信息、資產(chǎn)信息進行記錄和維護，并把每個事件/問題與用戶以及發(fā)生故障的資產(chǎn)對應起來，形成歷史記錄以便查詢和借鑒。如：某個用戶報告某路由器通訊故障，維護人員就可以根據(jù)資產(chǎn)編號查詢到該路由器以往的故障狀況。如該路由器出現(xiàn)過多次故障，并且都是線路質量較差，維護人員則可以根據(jù)這一依據(jù)向有關部門提出線路維護申請。

2.6 推行服務級別管理，提高客戶對IT運維的服務滿意度

在“內(nèi)部市場化”的要求下，最終用戶的服務滿意與否將成為IT運維質量的考評尺度。為此，推行服務級別管理有利于明確用戶/客戶的業(yè)務需求并使之規(guī)范化、標準化。因為只有在服務雙方都認可的服務范圍內(nèi)提供合乎需求的IT服務才能最終獲得用戶/客戶滿意的評價。比如：故障的響應時間約定、備品備件的替換原則、約定的設備巡檢日期等。通過服務級別管理不僅可以提供清晰、規(guī)范的IT運維服務，根據(jù)服務級別管理的流程可以對服務的結果進行持續(xù)改進。

三、結束語

加強IT運維管理，及時發(fā)現(xiàn)問題及解決問題，從根本上提高IT運維效率和效果，實現(xiàn)IT運維知識規(guī)范化、模板化，提高客戶滿意度，并提升運維服務的核心競爭力。

第三篇：化妝品中可能存在的安全性風險物質風險評估指南

化妝品中可能存在的安全性風險物質風險評估指南

2018.01.11 匯誠佳業(yè)

一、化妝品中可能存在的安全性風險物質的含義

化妝品中可能存在的安全性風險物質是指由化妝品原料帶入、生產(chǎn)過程中產(chǎn)生或帶入的，可能對人體健康造成潛在危害的物質。

二、風險評估基本程序

（一）危害識別：根據(jù)物質的理化特性、毒理學試驗數(shù)據(jù)、臨床研究、人群流行病學調(diào)查、定量構效關系等資料來確定該物質是否會對人體健康造成潛在的危害。

（二）危害特征描述（劑量反應關系評估）：分析評價該物質的毒性反應與暴露之間的關系。對有閾值的化學物質，確定“未觀察到有害作用的劑量水平（NOAEL）”或“觀察到有害作用的最低劑量水平（LOAEL）”。對于無閾值的致癌物，可根據(jù)試驗數(shù)據(jù)用合適的劑量反應關系外推模型來確定該物質的實際安全劑量（VSD）。

（三）暴露評估：一般可通過申報化妝品的產(chǎn)品類型和使用方法，結合化妝品中可能存在的安全性風險物質的含量或檢出量，在充分考慮可能的化妝品使用人群（包括特殊人群，如嬰幼兒、孕婦等）的基礎上，定性和定量評價化妝品中可能存在的安全性風險物質對人體可能的暴露劑量。

（四）風險特征描述：確定該物質對人體健康造成危害的概率及范圍。對具有閾值的物質，計算安全邊際（MOS）。對于沒有閾值的物質（如無閾值的致癌物），應確定暴露量與實際安全劑量（VSD）之間的差異。

三、評估資料的提交形式

申請人可按以下兩種形式提交化妝品中可能存在的安全性風險物質評估資料：

（一）申請人通過危害識別，判斷產(chǎn)品中不含可能存在的安全性風險物質的，可以提交相應的承諾書。承諾書應當陳述申請人對產(chǎn)品進行危害識別的分析過程及該產(chǎn)品不含可能存在的安全性風險物質的理由等。

（二）經(jīng)危害識別后申請人認為產(chǎn)品中含有可能存在的安全性風險物質的，則應當提交相應的風險評估資料。

四、風險評估資料要求

我國化妝品相關規(guī)定中已有限量值的物質，不需要提供相關的風險評估資料；國外權威機構已建立相關限量值或已有相關評價結論的，申請人可以提供相應的安全性評價報告等資料，不需要另行開展風險評估。

申請人提交的風險評估資料，應包括以下內(nèi)容：

（一）化妝品中可能存在的安全性風險物質的來源。

（二）可能存在的安全性風險物質概述，包括該物質的理化特性、生物學特性等。

（三）化妝品（或原料）中可能存在的安全性風險物質的含量及其相應的檢測方法，并提供相應資料。

（四）國內(nèi)外法規(guī)或文獻中關于可能存在的安全性風險物質在化妝品和原料以及食品、水、空氣等介質（如果有）中的限量水平或含量的簡要綜述。

（五）毒理學相關資料：

1.化妝品中可能存在的安全性風險物質的毒理學資料簡述，至少包括是否被國際癌癥研究機構（IARC）納入致癌物。

2.參照現(xiàn)行《化妝品衛(wèi)生規(guī)范》毒理學試驗方法總則的要求，提供相應的毒理學資料摘要。根據(jù)可能存在的安全性風險物質的特性，可增加或減少某些相應項目的資料。

（六）風險評估應遵循風險評估基本程序，結合申報產(chǎn)品的特點進行。風險評估報告應包括具體評估內(nèi)容及其結論。

（七）配方中含有植物來源原料的,對于僅經(jīng)機械加工后直接使用的植物原料，應當說明可能含有農(nóng)藥殘留的情況；對于除機械加工外，需經(jīng)進一步提取加工的植物來源原料，必要時，也應說明可能含有農(nóng)藥殘留的情況。

（八）在現(xiàn)有技術條件下，能夠降低產(chǎn)品中可能存在的安全性風險物質含量的有關技術資料，必要時提交工藝改進的措施。

上述風險評估的相關參考文獻和資料包括申請人的試驗資料或科學文獻資料，其中包括國內(nèi)外官方網(wǎng)站、國際組織網(wǎng)站發(fā)布的內(nèi)容。

五、風險評估資料的審評原則

(一）對于申請人提交承諾書的，應對產(chǎn)品中是否含有與《化妝品衛(wèi)生規(guī)范》規(guī)定的禁用物質等相關的可能存在的安全性風險物質及其依據(jù)進行審評。

（二）對于申請人提交風險評估資料的，應對其完整性、合理性和科學性進行審評：

1.評估資料內(nèi)容是否完整并符合上述有關資料要求，不能完整提供的應有合理說明；

2.資料來源是否可靠，所提供資料是否為試驗、檢測報告或公開發(fā)表的科學文獻；

3．可能存在的安全性風險物質來源是否清楚，該物質的理化特性、生物學特性是否明確，是否提供該物質的含量及相應的檢測方法，必要的毒理學評價資料，風險評估過程和評估結論等；

4.依據(jù)是否科學，資料是否充分，關鍵數(shù)據(jù)是否合理，分析是否科學、符合邏輯，結論是否正確。

（三）經(jīng)審評認為承諾書存在問題的，審評專家應根據(jù)化妝品監(jiān)管相關規(guī)定提出具體意見及其相關依據(jù)。申請人應當在規(guī)定的時限內(nèi)提供不含可能存在的安全性風險物質的依據(jù)或相應的風險評估資料。

（四）隨著科學認識的發(fā)展，國家食品藥品監(jiān)督管理局可對已經(jīng)批準或備案的化妝品中可能存在的安全性風險物質有關的風險評估資料進行再審評。

第四篇：IT項目管理中的風險控制

IT項目管理中的風險控制

無論是系統(tǒng)集成或是軟件開發(fā)，IT公司經(jīng)常面臨著各種項目的實施和管理，面臨著如何確定項目的投資價值、評估利益大小、分析不確定因素、決定投資回收時間等眾多問題。并且，一個IT項目，無論其規(guī)模大小，必然會為被實施方（用戶）在管理、業(yè)務經(jīng)營等多方面帶來變革，這就使IT項目必然具有高風險性的特點。尤其是近年來，IT項目的廣泛實施，一方面為眾多的企業(yè)帶來了管理、經(jīng)營方面的革新，而另一方面，夭折、中斷、失敗的項目也不在少數(shù)。因此，如何在項目實施中有效地管理風險、控制風險，已經(jīng)成為了項目實施成功的必要條件。

項目風險的管理不僅貫穿于整個項目過程，而且在項目事件發(fā)生之前風險的分析就已經(jīng)開始。我們可以根據(jù)風險控制與項目事件發(fā)生的時間將風險管理劃分為三個部分：事前控制——風險管理規(guī)劃，事中控制——風險管理方法，事后控制——風險管理報告。

一、事前控制——風險管理規(guī)劃

風險管理規(guī)劃是在項目正式啟動前或啟動初期對項目的一個縱觀全局的基于風險角度的考慮、分析、規(guī)劃，也是項目風險控制中最為關鍵的內(nèi)容，包括風險形勢評估、風險識別、風險分析和風險評價等幾部分。

1、風險形勢評估

風險形勢評估以項目計劃、項目預算、項目進度等基本信息為依據(jù)，著眼于明確項目的目標、戰(zhàn)略、戰(zhàn)術以及實現(xiàn)項目目標的手段和資源。從而實現(xiàn)：通過風險的角度審查項目計劃認清項目形勢，并揭示隱藏的一些項目前提和假設，使項目管理者在項目初期就能識別出一些風險。尤其是項目建議書、可行性報告或項目計劃一般都是在若干假設、前提、預測的基礎上完成的，這些假設、前提、預測在項目實施期間有可能成立，也有可能不成立。而這其中隱藏的風險問題又通常是被忽視的。一旦問題發(fā)生，往往造成項目管理方的措手不及和無一應對。例如項目計劃中假設用戶實施小組全力支持、脫產(chǎn)或幾乎脫產(chǎn)投入IT項目的實施，但在實際過程中，用戶方人員卻不得不抽出大量時間處理原有的業(yè)務，造成IT項目實施進度的拖延和實施效果不盡人意的風險。諸如此類的例子還有很多。為了找出這些隱藏的項目條件和威脅，就需要對與項目相關的各種計劃進行詳細審查，如人力資源計劃、合同管理計劃、項目采購計劃等等。由此我們可以得出，風險形勢評估一般應重視以下內(nèi)容：項目的起因、目的、項目的范圍、組織目標與項目目標的相互關系、項目的貢獻、項目條件、制約因素等。

2、風險識別

在對項目的基礎的風險形勢評估之上，就需要對各種顯露的和潛在的風險進行識別。風險識別實際上是對將來可能發(fā)生的風險事件的一種設想和猜測。因此，一般的風險識別結果應包括風險的分類、來源、表現(xiàn)及其后果、以及引發(fā)的相關項目管理要求。在具體識別風險時，一方面可利用一些常識、經(jīng)驗和判斷，通過以前經(jīng)歷的項目中積累起來的資料、數(shù)據(jù)、經(jīng)驗和教訓，或者請教相關的專家和資深從業(yè)人員，采用集體討論的方式。另一方面，可以通過分解項目的范圍、結構來識別風險，理清項目的組成和各個組成部分的性質、之間的關系、與外因的聯(lián)系等內(nèi)容，從而減少項目實施過程中的不確定性。除此之外，還可以利用一些技術和工具。比如，結合經(jīng)驗和教訓，將項目成功和失敗的原因羅列成一張核對表，或者是項目的實施范圍、質量控制、項目進度、采購與合同管理、人力資源與溝通等。以上都是風險識別常用的一些手段和方法，當然還有其他更多的途徑，因項目而異，靈活運用。

3、風險分析和評價

在進行風險識別并整理之后，必須就各項風險對整個項目的影響程度做一些分析和評價，通常這些評價建立在以特性為依據(jù)的判斷和以數(shù)據(jù)統(tǒng)計為依據(jù)的研究上。風險分析的方法非

常多，一般采用統(tǒng)計學范疇內(nèi)的概率、分布頻率、平均數(shù)眾數(shù)等方法。但無論是哪一種工具，都各有長短，而且不可避免的會受到分析者的主觀影響。可以通過多角度多人員的分析或者采取頭腦風暴法等盡可能避免。此外，我們應當明確，風險是一種變化著的事物，基于這種易變條件上的預測和分析，是不可能做到十分的精確和可靠的。所有的風險分析都只有一個目的，即盡量避免項目的失控和為具體的項目實施中的突發(fā)問題預留足夠的后備措施和緩沖空間。

風險評價之后，項目面臨著兩種選擇，即面臨著不可承受風險和可承受風險。對于前者，或者終止項目，或者采取補救措施，降低風險或改變項目；對于后者，則需要在項目之中進行風險控制。

二、事中控制——風險管理方法

管理風險，即控制風險，通過風險監(jiān)視和風險規(guī)避消除一些潛在的威脅項目健康實施的事件。風險的管理在整個項目生命周期中是連續(xù)、反復進行的，消除了某些風險來源后，有可能又會出現(xiàn)其他的風險，而且，為減少風險損失而進行的風險管理本身也會帶來新的風險。比如，管理風險所耗用的項目資源造成項目其他部分的可用資源減少，規(guī)避風險的行動影響原定項目計劃而帶來風險等。因此，在項目實施過程中，項目管理人員必須制訂標準并按階段衡量項目進展狀況，時時監(jiān)視項目實際進展情況，根據(jù)風險情況果斷調(diào)整和糾正項目行動。

1、風險監(jiān)視

由于時間對項目的影響是很難預計的，因此風險監(jiān)視是項目實施過程中的一項重要工作。監(jiān)視風險即監(jiān)視項目產(chǎn)品、以及項目過程的進展和項目環(huán)境的變化，通過核查項目進展的效果與計劃的差異來改善項目的實施。一般情況下，隨著時間的推移，有關項目風險的信息會逐漸增多，風險的不確定性會逐漸降低，但風險監(jiān)視工作也隨信息量的增大而日漸復雜。我們一般可采取項目的審核檢查的方式，通過各實施階段的目標、計劃、有關項目風險的信息會逐漸增多，風險的不確定性會逐漸降低，但風險監(jiān)視工作也隨信息量的增大而日漸復雜。我們一般可采取項目的審核檢查的方式，通過各實施階段的目標、計劃、實際效果的對比、分析，尋找問題的根源，提出解決問題的方法。

2、風險規(guī)避

在風險管理規(guī)劃基礎上進行風險控制，一旦監(jiān)視到風險，就應采取合理措施進行風險規(guī)避，可以從改變風險性質、改變風險發(fā)生的概率、改變風險的影響大小等多方面著手。風險規(guī)避的策略一般有預防、轉移、回避、接受、后備措施等幾種方式。

其中，預防風險尤其不能忽視項目的教育培訓和按程序辦事兩個方面。由于項目實施成員的任何不當行為都會構成項目的風險因素，要減輕與之相應的影響，就必須對有關人員進行詳細和有效的風險教育和項目培訓，教育培訓的內(nèi)容應該包含項目相關的策略、計劃、標準、規(guī)章規(guī)范、項目知識、產(chǎn)品知識等。在項目活動中，應該嚴格按照項目制度，如進度、人力調(diào)配、文檔管理、資源分配等。

轉移風險，在IT項目中使用最頻繁的應該要數(shù)合作伙伴、項目外包、保險與擔保等手段了。無論是與合作伙伴的協(xié)同實施還是項目的外包，都能在人力資源、成本費用、項目進度等方面分散風險，開脫責任。但轉移風險的同時也必然帶來利潤的一部分流失。

回避風險，是指當項目風險潛在威脅的可能性極大，并會帶來嚴重的后果，無法轉移又不能承受時，通過改變項目來規(guī)避風險。通常會通過修改項目目標、項目范圍、項目結構等方式來回避風險的威脅。

接受風險，作為規(guī)避風險的常見方法，主要是指主動將風險事件的不利后果承擔下來，這種后果通常主要反映在實施周期、成本費用的有限增加上，以犧牲項目收益而不影響項目整體。

用于規(guī)避風險的后備措施，主要體現(xiàn)在后備費用、預留進度時間、后備技術力量三個方

面，這些后備措施在項目計劃中就應預留，保證在項目實施過程中，能充分調(diào)用后備力量解決問題。

三、事后控制——風險管理報告

無論項目進展的情況如何，都必須將風險管理的計劃、行動、結果整理、匯總、進行分析，形成風險管理報告。風險管理的持續(xù)性要求風險管理報告的連貫性和不間斷性，因此，該報告不是僅僅在項目結束之后才制作的，而是應該視項目的進展狀況、項目計劃、報告的對象等條件采取書面或口頭、不定期的或階段性的等多種方式，為項目的實施、控制、管理、決策提供信息基礎。

我們在項目管理中進行風險控制的同時，還應該問自己幾個問題：所制訂的風險管理策略本身是否可行？實施風險控制的措施和手段是否與項目總目標保持一致？通過不斷地在實踐中反思、嘗試、總結、分析，提高風險管理的水平。風險總是和效益并存的。只有正確地識別風險、分析風險、規(guī)避風險，才能確保每一個項目的順利實施和成功完成，才能給企業(yè)帶來更多的效益。

第五篇：項目管理風險

1.功能無限蔓延；

2.需求鍍金或者開發(fā)人員鍍金；

3.質量不定；

4.計劃過于樂觀；

5.設計欠佳；

6.銀彈綜合癥；

7.研發(fā)導向的開發(fā)；

8.人員薄弱；

9.簽約商失敗；

10.研發(fā)人員和客戶的摩擦；

1.計劃編制風險：

1.1 計劃、資源和產(chǎn)品定義完全靠客戶或者上層領導的口頭命令，并且不完全一致；

1.2 計劃是優(yōu)化的，但是是不現(xiàn)實的；

1.3 計劃忽略了必要的任務；

1.4 計劃基于使用特定的小組成員，而那個小組成員基本上指望不上；

1.5 在限定時間內(nèi)無法建立成已定規(guī)模的產(chǎn)品；

1.6 產(chǎn)品規(guī)模比估計的大；

1.7 進度已經(jīng)拖延的項目在重新評估時過于優(yōu)化和忽略項目歷史；

1.8 過度的進度壓力造成生產(chǎn)率下降；

1.9 目標日期提前，沒有相應調(diào)整產(chǎn)品范圍和可用資源；

1.10 一個任務的拖延導致相關任務的連鎖反應；

1.11 涉足不熟悉的產(chǎn)品領域，花費在設計和實現(xiàn)上的時間比預期的要多；組織和管理：

2.1 項目缺乏一個有凝聚力的最高領導人；

2.2 由于前期乏力，項目長時間擱置；

2.3 解雇和削減開支導致項目小組能力下降；

2.4 僅由管理層或市場人員來進行技術決策，導致計劃進度延長；

2.5 低效的項目組結構降低生產(chǎn)率；

2.6 管理層審查/決策的周期比預期時間長；

2.7 預算削減打亂項目計劃；

2.8 管理層做出了打擊項目積極性的決定；

2.9 非技術的第三方工作比預期延長（預算批準、設備采購批準……）

2.10 計劃性太差，無法適應期望的開發(fā)速度；

2.11 項目計劃由于壓力而放棄，導致開發(fā)混亂，低效；

2.12 管理層強調(diào)英雄主義，而忽略客觀確切的狀態(tài)報告，降低發(fā)現(xiàn)和改正問題的能力； 3 開發(fā)環(huán)境：

3.1 設施沒有及時到位；

3.2 設施到位，但是不配套；

3.3 設施擁擠，雜亂或者破損；

3.4 開發(fā)工具沒有及時到位；

3.5 開發(fā)工具不如期望那樣有效，開發(fā)人員需要時間創(chuàng)建工作環(huán)境或者切換新的工具；

3.6 開發(fā)工具的選擇不是基于技術需求，不能提供計劃所需要的性能；

3.7 新開發(fā)工具的學習比預期的長，內(nèi)容多；最終用戶：

4.1 最終用戶堅持新的需求；

4.2 最終用戶對于最后交付產(chǎn)品不滿意，要求重新設計和重做；

4.3 最終用戶不買進項目產(chǎn)品，無法提供后續(xù)支持；

4.4 最終用戶的意見沒有被采納，造成產(chǎn)品最終無法滿足用戶期望，而必須重做； 5 客戶：

5.1 客戶堅持新的需求；

5.2 客戶對規(guī)劃、原型和規(guī)格的審核/決策周期比預期要長；；

5.3 客戶沒有或不能參加規(guī)劃、原型、規(guī)格階段的評審，導致需求不穩(wěn)定和耗時的變更；

5.4 客戶堅持技術決策導致進度計劃延長；

5.5 客戶對于開發(fā)進度管理過細，導致實際進度變慢；

5.6 客戶提供的組件無法和開發(fā)產(chǎn)品匹配，導致額外的設計和集成工作；

5.7 客戶提供的組件質量欠佳，導致額外的測試、設計和集成工作，以及額外的客戶管理管理工作；

5.8 客戶要求的支持工具和環(huán)境不兼容，性能差或者功能不完善，導致生產(chǎn)率下降；

5.9 客戶不接受交付的軟件，盡管已經(jīng)滿足了所有的規(guī)格；

5.10 客戶期望的開發(fā)速度是開發(fā)人員無法達到的；承包商：

6.1 承包商沒有按承諾交付組件；

6.2 承包商遞交的組件質量低下無法接收，必須花費時間改進質量；

6.3 承包商沒有買進項目開發(fā)所需要的公舉，進而無法提供需要的性能水平；需求：

7.1 需求已經(jīng)成為項目的基準，但是變化還在繼續(xù)；

7.2 需求定義欠佳，而進一步的定義會擴展項目范疇；

7.3 添加額外的需求；

7.4 產(chǎn)品定義含糊的部分比預期需要更多時間；產(chǎn)品：

8.1 錯誤發(fā)生幾率高的模塊需要比預期更多的測試，設計和實現(xiàn)工作；

8.2 校正質量低下不可接受的產(chǎn)品，需要比預期更多的測試，設計和實現(xiàn)工作；

8.3 在一個或多個新興領域推廣計算機技術使得計劃進度的延長不可預期；

8.4 由于軟件功能的錯誤，需要重新設計和實現(xiàn)；

8.5 開發(fā)額外不需要的功能，延長了計劃進度；

8.6 要滿足產(chǎn)品規(guī)模和進度要求，需要比預期更多的事件，包括重新設計和實現(xiàn)工作；

8.7 嚴格要求與現(xiàn)有系統(tǒng)兼容，需要進行比預期更多的事件進行測試，設計和實現(xiàn)工作；

8.8 要求在不同操作系統(tǒng)下運行將花費比預期更長的時間；

8.9 在不熟悉或沒有經(jīng)驗的軟件環(huán)境中運行產(chǎn)生沒有預料的問題；

8.10 在不熟悉或者沒有經(jīng)驗的硬件環(huán)境中運行產(chǎn)生沒有預料的問題；

8.11 開發(fā)一種對組織全新的模塊將比預期花費更長的時間；

8.12 依賴于正在開發(fā)中的技術將延長計劃進度；外部環(huán)境：

9.1 產(chǎn)品依賴于政府規(guī)章，而規(guī)章的改變是不可避免的；

9.2 產(chǎn)品依賴于草擬中的技術標準，而最后的標準是不可預期的；人員：

10.1 招聘人員所花費時間比預期長；

10.2 做為先決條件的任務不能萬丞，比如培訓，其他項目的萬丞，工作許可證； 10.3 開發(fā)人員和管理層關系不佳導致決策緩慢，影響全局；

10.4 項目組乘員沒有全身心投入項目，進而無法達到需要的產(chǎn)品性能水平；

10.5 缺乏激勵機制，士氣低下，降低了生產(chǎn)能力；

10.6 缺乏必要的規(guī)范，增加了工作失誤和重復工作；

10.7 某些人需要更多時間適應不熟悉的軟件工具和環(huán)境；

10.8 某些人需要更多時間適應不熟悉的硬件工具和環(huán)境；

10.9 某些人需要更多時間適應不熟悉的編程語言；

10.10 項目結束前，合同制人員離開團隊；

10.11 項目結束前，雇員辭職；

10.12 項目后期加入新的開發(fā)人員，額外的培訓和溝通降低現(xiàn)有成員的效率；

10.13 項目組成員不能有效地一起工作；

10.14 由于項目組成員的沖突，導致溝通不暢，設計欠佳，接口錯誤和額外的重復工作； 10.15 有問題的成員沒有調(diào)離項目組，損害了項目組其他成員的積極性；

10.16 項目組的最佳人員沒有加入項目組；

10.17 項目組的最佳人員已經(jīng)加入項目組，但是因為政治或其他原因沒有合理使用； 10.18 關鍵人員只能兼職參與；

10.19 項目人員不足；

10.20 人員工作的進展比預期的慢；

10.21 任務的分配合人員技能不匹配；

10.22 項目管理人員的怠工導致計劃和進度失控；

10.23 技術人員怠工導致工作遺漏或質量低下，工作需要重做；設計和實現(xiàn)：

11.1 設計過于簡單，無法確定主要事件，并導致重新設計和實現(xiàn)；

11.2 設計過于復雜，導致一些不必要工作，并影響效率；

11.3 設計質量低下，導致重復設計和實現(xiàn)；

11.4 采用不熟悉的方法，導致額外的培訓時間，并重犯以前的錯誤；

11.5 產(chǎn)品采用低級語言來實現(xiàn)，導致生產(chǎn)率比預期低；

11.6 一些必要的功能無法是用現(xiàn)有的代碼和庫實現(xiàn)，開發(fā)人員必需使用新的庫或者自行開發(fā)所需要的功能；

11.7 代碼和庫質量低下，導致需要額外的測試，錯誤修正或重做；

11.8 過高估計增強型工具對項目進度的節(jié)省量；

11.9 分別開發(fā)的模塊無法有效集成，需要重新設計或者重做；過程

12.1 大量紙面工作導致進展比預期慢；

12.2 進度跟蹤不準確，導致無法預知項目是否已經(jīng)落后計劃進度；

12.3 前期的質量保證行為不真實，導致后期的重復工作；

12.4 質量跟蹤不準確，導致無法得知影響進度的質量問題；

這是快速軟件開發(fā)一書中的內(nèi)容，我覺得比較全，就記錄下來了，但是還不完全。也懶得寫了。