/ IT風險管理

IT風險管理

逾期&超預算?如何避免專案管理災難性問題

開始執行一個大型IT專案,就好像進入一個長長的漆黑隧道,不知道從哪裡找到出口。這就是法國英吉利海峽隧道專案成本達到46億英鎊、超出預算80%的原因。 Philip Moscoso和Jaume Ribera Segura為《富比世》撰稿,闡述專案管理方法的運用,以確保專案不會以同樣的命運告終。 他們發現,所有專案通常都會經歷五個階段組成的生命週期:選擇、定義、規劃、實施&監控以及完工。但是,傳統的模式也有多種替代。如果公司擔心低價中標的投標者在簽署合約之後提高其價格,他們可以考慮“成本+激勵費用”合約,其內容如下: 由於客戶對專案全面負責,並且承諾向中標者支付其成本,加上一定比例的利潤,這樣就會在兩者之間建立一種激勵機制,促使他們通力合作,尋找創新的解決方案,以改善各種功能、降低成本並且以更快速度執行專案工作。 如需獲得另一個降低成本的方式,可以考慮將一個專案的各個方面細分為四個類型:增加價值的工作、必須但不會增加價值的工作、非必須並且不會增加價值的工作、以及在各項工作之間增加等待時間的工作。您將會希望盡可能消除後兩類工作,以便僅僅保留至關重要的專案支出。 如需閱讀原文(英文版):http://www.forbes.com/sites/iese/2015/03/09/late-and-over-budget-a-method-to-avoid-project-management-disasters/

閱讀更多 »

您是否應該將專案延期?

如果某個獨特的專案需要再多幾週的時間,才能充分實現其全部潛能,您可能應該允許其延期。那麼,如果各種專案一直都沒法按期完工,怎麼辦? Bruce Benson將告訴您,在決定是否允許專案延期方面所應該做出的選擇。 Benson將講述一個關於他和他的團隊如何搶在競爭對手之前將某個產品投放市場的故事。這是一款充滿缺陷的產品,但是,因為是市場上唯一可選的產品,其銷量非常好。然而,競爭對手推出了他們的產品,通過提供更高的品質來彌補失去的時間優勢。由於Benson公司的新軟體建立在諸多缺陷的基礎之上,Benson和他的團隊很難及時發佈新的產品,而競爭對手則不斷地擴大他們的競爭優勢。 Benson公司的執行長希望加速產品交付,而Benson發現,交付新產品所花費的平均時間已經達到18個月,超出了原來承諾的12-15個月的時間窗口。在這種情況下,Benson並不認為延期專案交付會帶來幫助,因為他們已經延期了,並且沒有收到什麼好的效果。反過來,Benson提出了這個解決方案: 我們比我們通常開始下個專案的時間提前3個月啟動專案…結果怎麼樣?是的,該專案和我們之前所有專案一樣困難重重且危機纏身。不同的是,當我們完成該專案並且當客戶接受我們的產品時,我們按時交付,並且我們的品質得到了改善——顯著改善! 如需閱讀原文(英文版):http://pmtoolsthatwork.com/delaying-projects-lessons-learned-from-electronic-arts/

閱讀更多 »

4 個簡單步驟避免專案恐慌

你可能是一位王牌專案經理,但你遲早會遇到你力所不能及的問題。當那個時候到來之時,幸好我們有一些步驟可以幫助你駕馭恐慌並戰勝困難。 Kenneth Darter 寫了一篇文章,其中列出了進攻計畫。 在令人不安的環境中,第一步就是要保持冷靜。當你感到不知所措時,這種感覺通常是因為你無法理解手上的任務而引發的。為了驅除這種焦慮,你必須把問題分解成你可以理解的也更容易管理的各項小問題。 下一步是向別人求助。請記住,當你向別人求助時不要讓你的聲音聽上去很絕望!用清晰自信的聲音將“挑戰”(而不是“問題”)轉交給同事。你會驚喜地發現,當你用自己理性的聲音傳達問題時,你的聲音聽上去是那麼平靜。 避免恐慌的實際任務包括重組挑戰,以便讓其變得更利於實現積極的改變。當然,在有些情況下,這一步驟無法在一天甚至一周內完成。重寫專案計畫就是一個例子。儘管如此,首先必須只關注絕對重要的內容。一切事情都可以等一等、緩一緩。 最後,你將到達克服挑戰的關鍵時間點。如果你適當地管理挑戰,也許你會用一些新技能、一件更好的產品/服務或僅僅一個全新的視角就戰勝了挑戰。在任何情況下,最困難的障礙常常會產生最大的回報。 閱讀原文(英文): http://www.projectsmart.co.uk/getting-in-over-your-head.php

閱讀更多 »

7大致命專案管理問題

懂得如何持續處理問題的專案經理(PM)會脫穎而出並且在這個專業上取得長遠的發展。而對於其他的人員,您可能會聽到蕭邦的《葬禮進行曲》。通過定義專案經理需要解決的7大最關鍵問題,Jennifer Lonoff Schiff為這兩者劃出了明顯的界限: 責任 資源 期限 範圍 意外因素 距離 溝通 從一開始,必須建立期望,Schiff 說道。通過使用RACI責任分配矩陣(責任、當責、諮詢、告知)圖表,專案經理可向各個專案職位分配其所需要的結構和可見度,並且讓員工承擔責任。 期限是一個較為普遍的問題,但是,對於專案經理來說,它們擁有一個全新的維度。 Ashley Schwartau是Security Awareness Company公司的生產主管,其通過人為提前各種期限來促進團隊成員滿足期限要求,從而預留了一個緩衝期,對偶發性錯誤進行補救或進行審查。另一個普遍問題是範圍的蔓延。一個優秀的專案經理會對各種變化、驗證、資產和影響進行完整的文件記錄。一個偉大的專案經理則會通過執行風險和品質管理戰略而先行一步。 然後,還存在意外因素。在這種情況下,其並非專案經理所希望的東西。定期的狀態會議應該能夠搶在任意意外破壞之前做好準備,但是,協作型任務追踪軟體是一個很好的第二選擇。關於第6個問題,團隊在全國或者全球範圍內分散分佈。在這裡,這是一個技術方案問題。通過適當的行動合作工具,我們可以克服距離的限制。最後,不和諧的團隊將毫無疑問會摧毀即使是經過最充分準備的專案。其解決方法是通過定期的電話諮詢和親自走訪,保持每個團隊成員參與到專案中來。 如需查閱原始文章(英文版),請至:http://www.cio.com/article/2876701/project-manager/7-ways-project-managers-can-anticipate-avoid-and-mitigate-problems .html

閱讀更多 »

做一個合格專案經理的三大盲點是哪些?

專案領導能力教練蘇珊娜·瑪德森(Susanne Madsen)認為,專案經理必須時不時地激勵團隊,從利害關係人那裡尋求支持,或是從團隊及利害關係人處獲得一定的專案成果。在一篇部落格文章中,瑪德森列出了你成為聰明而專業的專案經理人需避免的三大盲點。 最大盲點 專注於做事,而非領導; 著眼於當下緊急事情,而非著眼於其重要性; 固執於事無鉅細,都要掌控。 如果專案經理專注於分配任務、制定計畫,工作很大可能可以順利完成。但如果他們停止思考專案為何重要與專案如何影響真實的人們,那專案經理只會協助執行別人的願景,而不是形塑一個願景。 時間,至關重要。如果突發危機,奪取大家的注意力,我們便無法專注於其他更為重要的事情。專案經理或許會覺得,忽視一個當下的緊急郵件警告,只為騰出時間策劃好下個月的專案策略,多少有些內疚。但如果放任自己處於“看上去很忙”的狀態,將精力投入於處理每一個小的危機事件,我們便無法解決專案的那些深層次問題;而這些深層次問題,才是保證專案健康運行的關鍵。 另一個更為普遍的現像是,專案經理人傾向於想要了解專案運作的一切資訊,事無大小都要全權掌控。這必然會讓你覺得疲倦不堪,因為在這種情況下,專案經理人不得不同時牽涉到多個決策中。由此產生的負面影響是,閒置了本可以處理該事件、本可以分擔的專案團隊成員,他們不得不等著你的下一個命令。 閱讀本文原文(英文): http://www.pmhut.com/what-are-the-3-biggest-mistakes-that-project-managers-make

閱讀更多 »

解決問題的策略ABC

解決問題,依賴於人的專注以及實踐的經驗,在緊要關頭,其價值是不可估量的。布魯斯·哈珀姆(Bruce Harpham)提出了解決問題的ABC策略。如果你樂於接受新知識,下面的內容,你或許會認真學習一二。 A——評估關係影響 在採取關鍵舉措前,必須先了解事件的全貌及過程。哈珀姆認為,風險處理中所說的“全貌”,牽涉到事件影響人。他列出了家庭,同事,組織及利害關係人,這些都是需要考慮的重量關係。發生任何事件,其他人才是救援力量的最大來源,才是最需要獲得保護的。 B——吹響警報 在組織機構中,最大力量來源於團隊合作;在這種背景設定下,“自我”不再是單一個體,而是該企業的總稱。為此,利用他人就像是你自身免疫系統召集力量幫助戰勝來襲的病毒一樣。通過合作,可以讓你解決困難。 C——改變日程 哈珀姆引用了社交媒體專家克里斯·布羅根(Chris Brogan)的觀點,布羅根在一般只會給一天中40%的工作量做好計畫。 “我覺得,很多人的生活[適得其反],”哈珀姆說道,“他們計畫了120%,然後總是無法達成,狀況混亂不堪,然後感覺忙死了。”雖然看上去有點難,但在最為關鍵的事情上留出緩衝時間,可以讓你處理一些意料之外的事。 閱讀本文原文(英文): http://projectmanagementhacks.com/problem-solving-strategy/#sthash.RfLj2AcK.7diuAs3r.dpbs

閱讀更多 »

停止欺騙自己:怎樣衡量您的風險承受能力

無論是決定避免、轉移、緩和還是接受風險,所有的風險回應策略都有成本風險和殘留風險。避免風險通常會帶來機會成本,或者至少使利益滯 後,但是也會使殘留風險最低。例如,通過從範圍中移出某​​些要求、對進度風險作出回應,以避免風險;而其機會成本是未具備該要素提供的能力。 選擇風險回應策略 我之所以提出這一點,是因為我看到了太多的組織和經理人選擇了減輕或者接受他們本來可以避免或者轉移的風險。在一些情況下,這關係到某 些更安全回應的感知成本。但是,我看到這是在企業併購之後,許多組織都會出現這種情況,而在他們的進化文化之中,他們未能達到最終的階段。可能之前的某個 先導企業對風險具有更大的偏好;可能中等管理​​者已經將併購行為內部化,以作為承擔重大風險的一種意願。再或者,他們對特定類型風險的偏好高於新同事的 偏好。 去年,我與一家被規模更大的公司併購的客戶進行合作。他們發起了一個專案,旨在實現其減少法律不符合可能性的目標,儘管他們的風險可能 性已經非常小。該專案的成本已經遠超其被認定不符合的潛在成本,或者對現有處理流程進行改進的成本。但是,決策者覺得,必須減輕不符合風險。也就是說,無 論是進度還是品質方面,專案本身就具有風險。該專案啟動較晚,專案發起者在關鍵位置安排了一名相對缺乏經驗的團隊成員,並且,對應當在過程中插入何種業務 規則,其內部沒有達成一致。最後,併購公司的一名高級管理者終止了該專案。他們關於風險類別的看法具有很大的差異,並且,他們決定接受那些他們認為相對較 低成本的、低影響風險,而不是完全解決所有的殘留風險。 風險偏好衡量 衡量風險承受能力極其困難,或者,使用更為有意義的詞彙來進行描述更為困難。在一次採訪中,對於組織風險承受能力,我詢問過一名專案管 理辦公室主任。他也承認,他之前就遇到過同樣的問題,並且,他試圖努力採用對一名專案經理來說更具有行動意義的方式進行回答。簡單地說,沒有組織願意承認 他們不願意承擔風險,儘管有少部分可以說明他們認為可以接受的風險級別。但是,最優化各種風​​險成本的能力取決於組織如何看待和理解替換方案。因此,我 特此提出一些互動問題,其可能能夠引導開始風險偏好衡量的過程: 為了減少成本,您願意和一名新的供應商簽訂合約嗎?如果答案是肯定的,那麼這應當可被視為具有較高的風險偏好。 為了避免增加臨時員工而產生的費用,您願意接受較高的離職風險嗎?如果答案是肯定的,您更願意接受風險。 為了按時完成,您願意接受更高品質的風險嗎?如果專案沒有固定的結束日期,則表示較高的風險承受能力。 為了保持較低的運營成本,您願意接受較高的資本成本嗎?如果答案是肯定的,其可視為轉移風險的意願。 為了減少日程風險,您願意推遲一些交付物的日期嗎?如果答案是肯定的,其可視為避免風險的意願。 為了減少執行風險,您願意增加行政管理複雜性嗎?這也意味著轉移風險的意願。 上述清單並非特別詳盡全面,但我認為,可通過這個清單在一定程度上了解組織的風險偏好——或者,至少可了解他們對提議專案的風險偏好。

閱讀更多 »

突發事件管理入門的 6 個技巧

突發事件管理 (IM) 沒什麼神秘之處。但正如“IT 哥”Joe 所建議的,你進行突發事件管理的原因應該和你實際進行該工作同等重要;它應該是由需要而不僅僅是由規程來驅動的。在他的部落格裡,Joe 列出了6 個技巧來幫助你以正確的方式和正確的原因開始突發事件管理。 不要只因為它“聽起來不錯”而進行突發事件管理。 你很可能已經在進行突發事件管理了。 思考你進行突發事件管理的原因。 把突發事件管理視為一項服務,而不是一個流程。 注意你的用語。 從客戶的角度來看待問題。 如果只是把突發事件管理作為一種希望投入最小努力以達標的規程來對待,那麼這將會表現出來。既然IT 把突發事件管理作為一種外部資源提供給其客戶,那麼理解為什麼它原本就具有重大意義就很重要。即使沒有到位的正式流程,大多數企業和它們各自的IT 部門也會需要某種形式的突發事件管理,因為他們將不可避免地需要處理密碼重置、斷電和其他不幸發生的事件: (對於“為什麼我要進行突發事件管理”的問題,)如果你的回答是“當IT 出現問題時對其進行修復”,那麼我勸你再多用一點時間,好好思考下這個問題。突發事件當然不僅僅是關於技術故障或不可用的IT 服務? Joe 勸我們把突發事件管理視為一項服務而非一個流程。人們執行這一流程並使用它來為他們的客戶提供卓越的服務。此外,IT 是否真的存在“突發事件”?當然是的,突發事件是你在IT 領域所管理的事件,但從用戶的角度來看,它們即是問題或故障。經驗法則是,絕不要把IT 術語強加給客戶。最後,在你因新發現的對突發事件管理的喜愛而得意忘形之前,請記得只去實現客戶真正需要的,而不是你所想要的。 請點擊鏈結閱讀原文(英文):http://www.joetheitguy.com/2014/12/05/12-tips-for-getting-started-with-incident-management-part-1/

閱讀更多 »

IT 專案失敗的三大因素

對IT 專案的業務需求已從“持續運過”目標轉變為“為改變而設計”目標,同時也造成讓專案頻頻失敗的困境。在Pearl Zhu的部落格中,她指出導致專案失敗的三大根本原因: 贊助者的自負 損失規避程度 忽略概率 通常情況下,贊助者將試圖引導專案清除故障,即使以潛在成功為代價。其原因可能是簡單規避風險或由於他們操作專案是為了其個人利益。在其他情況下,專案贊助者在最初之時樂於參與其中並監督任何必要的改變。但是,隨著時間的流逝,他們的興趣連同熱情和支持逐漸消逝。 為客戶開展專案工作常常是說時容易做時難。沒有適當的成功指標,專案團隊也可能是無的放矢: 您可以談論需求、專案管理者或所有您想談論的糟糕準則;基本上,專案失敗皆緣於三大因素的綜合影響:缺乏企業知識、一成不變或過時的IT能力,及整個企業的不良溝通結構。 據估計至少30% 的IT 專案徹底失敗,而且多達70% 的專案未能滿足客戶期望。對專案風險的適當分析,當然,第一步是控制專案風險。畢竟,您無法避免您不相信的但卻正在發生的事情。 欲閱讀原文(英語),請前往: http://futureofcio.blogspot.com/2015/01/three-aspects-of-it-project-failures.html

閱讀更多 »

不到萬不得已時,請勿停止 IT 專案

雖然停止IT 專案是專案管理者最不情願做的事情,但是當專案正處於失控時,它又是首選的解決辦法。 Mary Shacklett 對何時應停止問題專案發表了相關看法。但是在您向利害關係人簡要闡述該消息前,請考慮一些能夠挽救專案生命的變通方法及防禦措施。 大型專案時常夭折。在某些情況下,專案管理者不得不鼓足勇氣對利害關係人說:“情況很糟糕,但這是我們所能做的挽救措施。”考慮周全的專案贊助者將了解情況並與您一起合作來扭轉局面。 另一種重啟危機專案的方法就是停止工作進程並花一些時間考慮軟體虛擬化。讓利害關係人觀看最終產品真實模擬的益處多次讓他們自行買單: 當終端商業使用者進行最終軟體產品的“驗收測試”時,他們經常向IT 部門反應:“這壓根不是我們所期待的!”到此時,產品已被寄予太多的希望和期望,這可能會讓專案管理者失去其工作。 事實是, 45% 的軟體開發專案都未滿足其預定目標。根據一份有效的統計數字, 當您考慮可以節約的時間和資源數量時,您會願意通過簡單方式向贊助者進行展示。 欲閱讀原文(英語),請前往: http://www.techrepublic.com/article/pull-the-plug-on-an-it-project-as-a-last-resort/

閱讀更多 »