【92】項目管理:項目中的風險及管理-1
02-05
我們對風險和風險管理的認知不是那麼多,所以在實際的工作過程中,很多項目經理在提及風險管理時候,總是輕描淡寫,認為項目的風險是領導重視不足,溝通不夠,項目人力資源不足,這三條足以應付所有的項目風險了,但實際上這些遠遠不足以說明項目的風險。
n風險管理起源於美國,由於受到1930年左右的世界性經濟危機的影響,導致金融行業的危機和經濟的倒退,很多企業開始設立保險管理的方法來 應對,後來開始採用科學的方法來應對,到50年,風險管理髮展成為一門學科,也深入到其他行業。風險管理是一個管理過程,包括對風險的定義、測量、分析評估和應對。
n
項目的風險就是項目的不確定性,基本目標是以最小的成本收穫最大的安全保障。風險不僅包括威脅,也包括機會,風險管理是貫穿於整個項目生命周期的,風險管理和項目的每一部分都相關,處理風險也需要成本。在項目中,風險管理不需要像編排計劃、分解任務那麼複雜,不需要很多的時間,但風險管理也是項目經理每周甚至每天的必修課之一。在項目的會議或日常溝通中,如果出現了「可能」或「如果」的字眼,這就是一個風險點,除了上面提到的老三樣風險以外,風險存在於IT項目的方方面面,列舉部分如下:
n- 組織和管理過程風險:例如項目干係人的部門組織結構的調整,項目所在職能部門的組織結構調整,項目干係人或項目領導組織的人員更迭,因為組織結構的影響造成項目的決策周期、合同周期、採購周期、付款周期延長,組織級領導不支持項目等。正是因為有了組織風險,會帶來管理過程風險,公司或部門沒有必要的標準和規範等組織過程資產,不是很正規的管理方式,造成重複工作和無用功。
- 計劃風險,計劃最大的風險是對項目的工作量、工期估算不準確,特別是新進入一個行業或領域,沒有歷史項目的估算作為參考的情況下,計劃風險也是最常見的風險。我們經常對項目進度過於樂觀,當樂觀發生時就是一種風險,計劃風險的導致另一個重大風險是資金和成本的風險,舉一個最簡單的例子,很多公司在投標時一個軟體系統交付以後要有一年到三年的運維期,如果計劃不當,運維的結果就是項目的虧損。
- 業務流程重組和業務變革風險,特別在國內的一些IT項目中,項目管理和業務諮詢是同時進行的,IT項目改變或提高了業務的執行效率或方法,牽扯到人員角色、職責的重新定義,而業務管理人員或高層領導還沒有思想轉變的意識,或者存在一些阻力,這種風險甚至直接影響到項目的成敗。
- 需求風險,業務的風險直接導致系統需求的風險,即使採用敏捷框架執行軟體項目,需求變化、定義不清晰、項目干係人參與度不夠都是項目的需求風險,此外缺乏對需求的有效跟蹤和管理,風險就會成為問題。
- 技術風險,從工作空間配套,個人工具配備,業務知識的準備,到測試環境的搭建等,都存在很多不確定因素,某一項因素存在問題,都會影響人員的工作效率,例如採用了第三方的代碼庫或工具,但又不支持某些集成功能等。做軟體項目的都非常清楚技術風險的可控性的難度和技術問題應對方法是多麼耗時。技術風險還包括在系統設計質量低,沒有有效的代碼庫,對系統介面的工作理解不到位或文檔不充分,需要額外的集成工作,需要更多的測試,系統升級等。此外,當前信息技術發展非常快,如果不是自行開發,而是使用了過於先進的技術、購買軟體產品和租賃系統等,會存在技術支持的風險,當然,如果能快速掌握新技術,反而這是一個技術機會。
- 信息與系統安全的風險,安全的風險在很多時候,我們都停留在口頭上,而沒有真正去認真執行那些安全制度,包括許可權分配,病毒預防,數據的更新許可權,備份等內容,想一下,我們有多少系統的測試用戶的密碼是「123456」或者「password」?如果在測試階段還不要緊,畢竟方便測試,但是系統正式啟用以後,而測試用戶還沒有被清理,這就是信息與系統安全的風險。系統安全的風險有的時候來來源於項目外部的不可控因素,例如機房系統管理、設備環境等。
以上是一些客觀存在的組織、業務和技術風險,在實際項目中,人是最難以管理的,也是最大的風險源。例如有數據統計,使用一個沒有經驗的項目經理,也是一個管理過程風險,因為他可能沒有發現項目風險。按照項目的人員角色,每一類角色都有不同的人的風險。
推薦閱讀:
※關於項目管理,如何理解CAPM證書在中國的作用?
※怎樣的可行性報告才會讓客戶滿意?
※技術團隊的管理體系
※光環國際PMP—3步解讀:什麼是項目經理
※有哪些比較好用的開源項目管理工具?
TAG:项目管理 |