風(fēng)險評估管理三個問題篇

風(fēng)險評估管理三個問題篇風(fēng)險評估管理三個問題篇風(fēng)險評估管理三個問題篇風(fēng)險管理三個問題篇

三個問題篇

在你的職業(yè)生涯里，總有些時候需要你當(dāng)機立斷地終結(jié)一個失敗的開發(fā)項目。當(dāng)然，那是我們最希望避免出現(xiàn)的結(jié)果。從好的方面看失敗會令人沮喪，從壞的方面看項目的完蛋或許會威脅到你的職業(yè)安全性了。如果你能采取行動拯救一個項目，那么你就可能有機會影響項目的成敗。然而，除非你是項目經(jīng)理，否則你只能束手無策。不過，你倒可以想法了解迫近的問題以便尋找機會逃跑。

這篇文章闡述了3個同業(yè)務(wù)有關(guān)的預(yù)警信號，希望它們能有助于你看清項目是否在走向崩潰。雖然這些總結(jié)并不太具備科學(xué)意義上的準確性，但是，這些跡象能為你提供一些早期警告。而且，盡管你無法拯救項目但你或許能通過這些警示拯救你自己。在文章的末尾還提出了一些建議性的應(yīng)對措施，這樣一來，萬一你發(fā)現(xiàn)自己正身陷項目失敗的泥沼，那么你好歹可以采取相應(yīng)的合理行動自救。

概述

針對成功的IT項目的統(tǒng)計報告不具備太大的意義。根據(jù)Standish商業(yè)研究公司的一份報告，將近三分之一的信息系統(tǒng)項目在最終完成之前都被取消了。另外，在所有的項目中幾乎有一半左右會超出其預(yù)算。

令人驚訝的是，項目失敗的原因很少同技術(shù)有關(guān)。大多數(shù)項目都是因為技術(shù)以外的其他原因而招致失敗的。可是，既然不是技術(shù)原因造成的項目失敗，那么又該是什么原因令這些項目失敗的呢？答案是項目所牽扯的人和工作過程。具有諷刺意味的是，普通開發(fā)人員在處理技術(shù)問題的時候應(yīng)對有道但他們在同其他人以及工作流程打交道的時候卻不是這樣。

問題#1：缺乏有意義的商務(wù)案例

真的叫人很吃驚，有些項目從一開始就找不出有意義的商務(wù)案例來支持它們。商務(wù)案例很重要，因為它為項目提供了基礎(chǔ)。商務(wù)案例應(yīng)該能提出效益分析，同時還能考慮到商業(yè)風(fēng)險和項目之外事件的影響。機構(gòu)會采用商務(wù)案例把它們有限的資源劃分出優(yōu)先級別從而為其提供最大回報。

這樣說來，在沒有商務(wù)案例的情況之下，一個項目該如何起步呢？這也是可能的，因為項目的商業(yè)屬主也許僅僅是需要實現(xiàn)什么特定的目標，而且有能力達到自己需要實現(xiàn)的目標。另外還有一種可能性，那就是IT機構(gòu)認為商業(yè)單位需要它因此它們自己先創(chuàng)建出來再說。

最近兩年，因為許多人相信他們必須開發(fā)某些項目來維持競爭力，所以好多同Web關(guān)聯(lián)的項目在不存在商務(wù)案例的情況下就紛紛上馬了。那爭先恐后的樣子就好象不奮力一搏就趕不上趟似的，“.com”的崩潰意味著商務(wù)實踐回歸原來的基礎(chǔ)，這其中自然也包括商務(wù)案例。

對策：探詢你目前著手的項目是否受到了商務(wù)案例的支持。找一份商務(wù)案例來仔細閱讀它。你所在項目的商業(yè)動力是什么？這一商務(wù)案例符合邏輯而且可理解嗎？該商務(wù)案例存在怎樣的前天條件？其風(fēng)險是什么？什么外部因素會影響商務(wù)案例？如果你無法為自己的項目找到可理解、有意義的商務(wù)案例，那么你得知道為什么沒有開發(fā)出有關(guān)的商務(wù)案例。

問題#2：沒有獲得同意的需求或系統(tǒng)規(guī)范

缺乏需求確實是一件非常危險的事情。挑戰(zhàn)項目正常運行的三個最常見因素都和系統(tǒng)需求有關(guān)。系統(tǒng)需求能給出將要創(chuàng)建的系統(tǒng)的大小和結(jié)構(gòu)。它們定義了系統(tǒng)應(yīng)該和不應(yīng)該實現(xiàn)的任務(wù)。

需求管理就是在整個項目周期之內(nèi)定義、記錄、追蹤以及管理需求的過程。需求管理保證了最終的解決方案能夠滿足用戶的需要。

對策：密切注意你的需求管理過程。如果看起來沒人負責(zé)管理系統(tǒng)的需求，或系統(tǒng)的需求老是在變，那么你可能會遇到麻煩了。

問題#3：缺乏項目計劃

有些項目竟然會在沒有項目計劃的情況下運做。這簡直就是不用圖紙造房子。每個項目都是一個事業(yè)，都應(yīng)當(dāng)具備相應(yīng)的項目計劃。項目計劃對那些項目決策人來說是非常必要的交流手段，項目計劃為項目的進展以及確定需要進一步完成的其他工作提供了指導(dǎo)。

有一種說法稱不需要告訴有關(guān)開發(fā)人員具體的計劃內(nèi)容；他們只需要知道做什么就可以。這種看法對只有一個人的項目隊伍來說管用，但要做大事就站不住腳了。開發(fā)人員確實需要接受計劃的指導(dǎo)。他們想要知道什么任務(wù)排在前面。他們不想猜測哪些東西是最重要的。

僅僅有了一個計劃還是不夠的：計劃必須跟隨項目的發(fā)展保持最新狀態(tài)。舉個例子吧，有些項目剛開始的時候房間里貼滿了五花八門的甘特圖和波特圖，結(jié)果幾個月乃至數(shù)年過去了這些圖表還是老樣子放在那里，沒有任何變化。這可不是一個當(dāng)前計劃。為了讓計劃與時俱進，項目計劃就必須反映實際完成的工作，同時還要預(yù)計將要完成的工作。計劃更新的頻率倒不至于達到每周一次的程度，但也不能低于每兩周一次。計劃應(yīng)該準確地反映完成項目的時間和開銷。只有在這樣的情況下才可以說計劃保持在最新的狀態(tài)。

過于頻繁變更的計劃同過期的計劃一樣令人恐懼。我曾經(jīng)見過這樣的項目計劃，該項目計劃每周都要修改，結(jié)果把項目的階段終止日期超出了一周的范圍。計劃每周都在更新，但項目工程仍然失去了控制。

對策：如果沒有公開的項目計劃你無論如何得趕快弄出一個來。如果你被告知，因為信息的機密性你不能查閱項目計劃，那么，你不妨把這一事件看做一個嚴重的警示跡象。除非你在開發(fā)新一代的原子彈，否則秘密項目計劃根本沒有存在的道理。保持信息的隱秘通常意味著管理層知道項目出了問題，他們正試著把問題掩蓋起來。

一定要保證計劃常新而且還得具有合理的更新間隔。它不該是個不斷變動的目標，但它一定得是最新的。如果你不能保證項目計劃的最新狀態(tài)，那么項目會出問題的。

項目快完蛋了，我該怎么辦？

你發(fā)現(xiàn)自己的項目已經(jīng)出現(xiàn)了以上一個或者多個預(yù)警信號嗎？對這個問題的回答取決于你的個人狀況。如果你感到你能采取行動改變現(xiàn)狀，那么你一定要立即行動。同項目經(jīng)理、顧客或你隊伍中的其他成員對話。用一種就事論事、不具威脅性的方式討論你所關(guān)心的問題。試著盡可能提出正面意見?？纯茨隳芊窠o項目帶來轉(zhuǎn)機。

如果項目瀕于失敗而且你發(fā)現(xiàn)自己沒有辦法控制事態(tài)的發(fā)展，那么你最好想辦法離開現(xiàn)在的項目。你也許能在同一家機構(gòu)內(nèi)找到一個好一些的項目，要不你干脆離開現(xiàn)在的單位算了。反正走為上策。到這份兒上已經(jīng)不是告訴某人該如何運做項目的時候了。

如果你粘在項目上了，或者正等著走人，那你也不妨換個看問題的角度。就當(dāng)你在長經(jīng)驗吧。比方說，你能從現(xiàn)狀中獲得什么？如果得到授權(quán)你將采取什么行動改變現(xiàn)狀？將來你該如何避免撞上這樣的項目？從當(dāng)前項目進展中學(xué)到的知識和掌握的經(jīng)驗必定能在你著手的將來項目上給你帶來莫大的幫助。

僅僅是個開始

以上的3個問題主要牽扯到業(yè)務(wù)和計劃方面，但是，項目遇險的跡象還并不止于這些。接下來，我們將繼續(xù)討論在失敗的項目中涉及到用戶和項目主管人員的4個因素，討論下這些因素是如何給你提出項目遇險警告的。

四個因素篇

總有一些項目會最終獲得成功，可是，相當(dāng)大數(shù)量的項目卻沒這么好的命。如果你不幸遭遇到這樣的處境，在事情惡化到不可收拾之前你如何知道項目遇到危險了呢？接下來，我們繼續(xù)探討一些牽扯到項目人員的危險跡象，它們大致上可以表現(xiàn)為4種預(yù)警信號。

導(dǎo)致項目失敗的大部分原因不在于技術(shù)而在于同項目有關(guān)的人和過程，認為到這些更具“軟性”的問題是相當(dāng)重要的。具體地說，其原因同用戶和項目發(fā)起人以及缺乏開發(fā)人員之間的交流有關(guān)（改變管理和工作報告）。如果你發(fā)現(xiàn)自己涉及的項目已經(jīng)出現(xiàn)這樣的跡象，那就表明項目正在滑向失敗的邊緣了。

問題#1：你的客戶或用戶組不跟你說話

客戶或用戶不和你交流只能說明情況不妙。這意味著他們幾乎毫無積極性。不過也可能說明業(yè)務(wù)組太關(guān)注于具體的工作或者太忙了，難以同你合作，這就是說。如果正是那樣的情況，那么項目正在向災(zāi)難邁進了。你必須同客戶和用戶合作，這樣才能成功地實現(xiàn)項目。

缺乏用戶的參與只能意味著用戶抗拒變動。我們知道，所謂的“變動管理”，就其全部領(lǐng)域而言就是建立在贏得最終用戶的支持以及接受新系統(tǒng)和過程的基礎(chǔ)之上。這一方面不應(yīng)該與被用來管理項目范圍的變動控制過程相混淆。變動管理不在這篇文章所涉及的范圍之內(nèi)。但我們必須清楚地認識到，系統(tǒng)要想得到有效的實現(xiàn)就必須把用戶包含進來。

其他原因也可能造成客戶或用戶缺乏參與精神。比如，具體的業(yè)務(wù)決定了項目不得不取消或者實現(xiàn)一個不同的解決方案。項目贊助者可能讓用戶遠離項目，原因是系統(tǒng)實現(xiàn)之日就是他們失業(yè)之時。

任何項目都需要獲得客戶或用戶的輸入信息，沒有它，系統(tǒng)需求和設(shè)計就等于在真空中呼吸。最終的解決方案根本不可能滿足業(yè)務(wù)需要。

如果你的客戶或用戶沒有在項目上與你一道工作，顯然。你的麻煩來了。

問題#2：項目發(fā)起人效率低或者角色不明確

有一位良好的項目發(fā)起人是項目成功交付的一個關(guān)鍵因素。他或她有助于項目目標的集中，為團隊搬走主要的絆腳石，從企業(yè)政治上講尤其如此。

項目發(fā)起人必須有清除障礙的能力，他們一定得有權(quán)力在利益發(fā)生沖突的情況下解決問題。他們還需要做出堅定的決策支持開發(fā)隊伍。

如果項目沒有明確的發(fā)起人，在開發(fā)過程中那些形形色色的障礙就必然會影響項目的進展。企業(yè)政治也會開始給團隊和工作說事。在項目發(fā)起人離開公司的情況下更會產(chǎn)生很多的問題。發(fā)起人為什么要離開公司？他或她是被迫出走的嗎？發(fā)起人的政敵會試圖停止項目或者改變其范圍嗎？你的職業(yè)將會受到這些政敵的影響嗎？也許你壓根就不打算繼續(xù)逗留在這里非要弄出個子丑寅卯。

問題#3：沒有管理變動的機制

我們都知道，項目發(fā)生變動是不可避免，管理項目的變動非常重要。優(yōu)秀的變動控制過程并難于管理，但是它們確實需要對細節(jié)保持關(guān)注。高效的變動控制要求同客戶或軟件解決方案的商務(wù)屬主密切合作。

不幸的是，某些項目仍然在沒有管理變動的過程的情況下運轉(zhuǎn)。要不就是項目的范圍含糊不清，或者不討論變動控制，或者客戶或業(yè)務(wù)主人不斷地根據(jù)自己的意愿改變解決方案。沒有變動控制過程的項目是不可能得到準確估計的，這是因為解決方案的規(guī)模總在不斷地變動之中。另外，變動通常會導(dǎo)致某些重復(fù)性的工作，從而進一步推遲了開發(fā)過程令項目團隊失去動力。

記住，客戶不是變動的唯一來源。有時團隊自身也能引起范圍的變動。畢竟，團隊成員也是人，而人總會犯錯誤的。團隊的成員可能聽說或“假設(shè)”解決方案因客戶的實際要求而發(fā)生了變動。另外還有一種可能，那就是項目需求比較含糊，因此團隊成員從不同方面對其進行解釋。或者，團隊成員可能無意中創(chuàng)造出一個相比客戶需求更漂亮或更復(fù)雜的解決方案。這就是所謂的“鍍金”操作。

如果你所在的團隊沒有執(zhí)行變動策略，你應(yīng)該問一下原因何在。如果你找不出答案，那可要警惕了，項目很可能正在失去控制而且失敗的風(fēng)險顯著增大了。

問題#4：沒有準確的工作報告

準確的工作報告是項目的活命源。這些報告把有關(guān)的信息報告給負責(zé)人，同時提供一種有效的機制來確定是否采取正確的行動。準確的工作報告還能起到記分卡的作用，可以顯示出項目的計劃完成情況。所有的項目都需要工作報告。

為什么項目絕對離不開工作報告呢？主要有兩個原因：項目經(jīng)理需要認識到項目的需求，或者工作不妙以至于項目經(jīng)理決定干脆啥也不說了。在這兩個原因之中，后者可能更壞。如果某個項目落在了既定目標之后或者超出了預(yù)算而有沒有上報，顯然這樣的項目不如取消。

如果你的項目缺乏工作報告，我看也沒什么必要找出原因了。你趕快跑吧。

項目陷入麻煩該怎么辦？

如果你不是項目經(jīng)理，那么你對瀕臨失敗的項目只能無可奈何。然而，如果你確定項目已經(jīng)遇到麻煩了那么你應(yīng)該采取一些行動。

如果你的用戶拒絕參與項目，或者沒有給你足夠的項目運做時間，那么你應(yīng)該同項目的用戶方做一番開誠布公的對話。雖說不一定就能拯救項目但也不至于給項目造成傷害。

尋找可以轉(zhuǎn)移的其他項目（反正比你現(xiàn)在的好一些）。順便說一句，別到處說你為什么離開當(dāng)前的項目。事成之后，每個人都會認為你采取了正確的行動。

如果事情糟透了，請打其他公司項目的主意吧。

如果你一直堅守在某個一兩年之后就瀕于完蛋的項目之內(nèi)，它對你的身體、精神或職業(yè)都不會帶來半點好處?，F(xiàn)在就采取行動。如果你不能拯救項目至少得拯救你自己。

八個信號篇

作為項目經(jīng)理，當(dāng)你面對成堆的MicrosoftProject工作任務(wù)報告時，想到已經(jīng)花了好幾個小時陷入在扯不清、說不明的項目工作會議的泥沼之內(nèi)，也許這是你感覺最令人惱火和沮喪的時刻。

可是，像這樣的痛苦會議還不僅僅意味著一種失敗感。它們的本質(zhì)問題可能掩蓋得更深，這些問題會最終毀滅你經(jīng)手的項目。這里我想與你一道分析和了解項目即將陷入困境的一些跡象：

沒有引人注目的業(yè)務(wù)案例。那種“超酷”的Flash網(wǎng)站在增加業(yè)務(wù)收入方面的作用值得懷疑。

自作主張地編寫代碼。如果你不同意業(yè)務(wù)需求或系統(tǒng)規(guī)范，你怎么知道所交付的工作或規(guī)范是最新的？實際上你不可能知道。

沒有項目規(guī)劃。這是針對項目經(jīng)理的。比如說，通過電子郵件交流的內(nèi)容儼然成為系統(tǒng)的功能規(guī)范。這簡直是沒有藍圖就造房子。

你和你的顧客各說各話。發(fā)生這種情況時，你必須打消咒罵項目發(fā)起人家庭成員的欲望（比如誰誰母親的）。

項目發(fā)起人生活在“洞穴”里。當(dāng)你需要額外資源時就知道這將造成多大的損害了！當(dāng)你的老板要求給項