專案遇險的3個問題，4個因素和8個訊號(轉)

專案遇險的3個問題，4個因素和8個訊號
三個問題篇
　　在你的職業生涯裡，總有些時候需要你當機立斷地終結一個失敗的開發專案。當然，那是我們最希望避免出現的結果。從好的方面看失敗會令人沮喪，從壞的方面看專案的完蛋或許會威脅到你的職業安全性了。如果你能採取行動拯救一個專案，那麼你就可能有機會影響專案的成敗。然而，除非你是專案經理，否則你只能束手無策。不過，你倒可以想法瞭解迫近的問題以便尋找機會逃跑。
　　這篇文章闡述了3個同業務有關的預警訊號，希望它們能有助於你看清專案是否在走向崩潰。雖然這些總結並不太具備科學意義上的準確性，但是，這些跡象能為你提供一些早期警告。而且，儘管你無法拯救專案但你或許能通過這些警示拯救你自己。在文章的末尾還提出了一些建議性的應對措施，這樣一來，萬一你發現自己正身陷專案失敗的泥沼，那麼你好歹可以採取相應的合理行動自救。 概述
　　針對成功的IT專案的統計報告不具備太大的意義。根據Standish商業研究公司的一份報告，將近三分之一的資訊系統專案在最終完成之前都被取消了。另外，在所有的專案中幾乎有一半左右會超出其預算。
　　令人驚訝的是，專案失敗的原因很少同技術有關。在軟體管理手冊Peopleware: Productive Projects and Team一書中，作者之一Tom Demarco提醒讀者注意，大多數專案都是因為技術以外的其他原因而招致失敗的。可是，既然不是技術原因造成的專案失敗，那麼又該是什麼原因令這些專案失敗的呢？答案是專案所牽扯的人和工作過程。具有諷刺意味的是，普通開發人員在處理技術問題的時候應對有道但他們在同其他人以及工作流程打交道的時候卻不是這樣。
問題 # 1 ：缺乏有意義的商務案例
　　真的叫人很吃驚，有些專案從一開始就找不出有意義的商務案例來支援它們。商務案例很重要，因為它為專案提供了基礎。商務案例應該能提出效益分析，同時還能考慮到商業風險和專案之外事件的影響。機構會採用商務案例把它們有限的資源劃分出優先順序別從而為其提供最大回報。 這樣說來，在沒有商務案例的情況之下，一個專案該如何起步呢？這也是可能的，因為專案的商業屬主也許僅僅是需要實現什麼特定的目標，而且有能力達到自己需要實現的目標。另外還有一種可能性，那就是IT機構認為商業單位需要它因此它們自己先建立出來再說。
　　最近兩年，因為許多人相信他們必須開發某些專案來維持競爭力，所以好多同Web關聯的專案在不存在商務案例的情況下就紛紛上馬了。那爭先恐後的樣子就好象不奮力一搏就趕不上趟似的，“.com”的崩潰意味著商務實踐迴歸原來的基礎，這其中自然也包括商務案例。
　　對策：探詢你目前著手的專案是否受到了商務案例的支援。找一份商務案例來仔細閱讀它。你所在專案的商業動力是什麼？這一商務案例符合邏輯而且可理解嗎？該商務案例存在怎樣的前天條件？其風險是什麼？什麼外部因素會影響商務案例？如果你無法為自己的專案找到可理解、有意義的商務案例，那麼你得知道為什麼沒有開發出有關的商務案例。
問題 #2 ：沒有獲得同意的需求或系統規範
　　缺乏需求確實是一件非常危險的事情。在Standish的報告裡，挑戰專案正常執行的三個最常見因素都和系統需求有關。系統需求能給出將要建立的系統的大小和結構。它們定義了系統應該和不應該實現的任務。
　　需求管理就是在整個專案週期之內定義、記錄、追蹤以及管理需求的過程。需求管理保證了最終的解決方案能夠滿足使用者的需要。
　　對策：密切注意你的需求管理過程。如果看起來沒人負責管理系統的需求，或系統的需求老是在變，那麼你可能會遇到麻煩了。
問題 #3 ：缺乏專案計劃
　　有些專案竟然會在沒有專案計劃的情況下運做。這簡直就是不用圖紙造房子。每個專案都是一個事業，都應當具備相應的專案計劃。專案計劃對那些專案決策人來說是非常必要的交流手段，專案計劃為專案的進展以及確定需要進一步完成的其他工作提供了指導。 有一種說法稱不需要告訴有關開發人員具體的計劃內容；他們只需要知道做什麼就可以。這種看法對只有一個人的專案隊伍來說管用，但要做大事就站不住腳了。開發人員確實需要接受計劃的指導。他們想要知道什麼任務排在前面。他們不想猜測哪些東西是最重要的。
　　僅僅有了一個計劃還是不夠的：計劃必須跟隨專案的發展保持最新狀態。舉個例子吧，有些專案剛開始的時候房間裡貼滿了五花八門的甘特圖和波特圖，結果幾個月乃至數年過去了這些圖表還是老樣子放在那裡，沒有任何變化。這可不是一個當前計劃。為了讓計劃與時俱進，專案計劃就必須反映實際完成的工作，同時還要預計將要完成的工作。計劃更新的頻率倒不至於達到每週一次的程度，但也不能低於每兩週一次。計劃應該準確地反映完成專案的時間和開銷。只有在這樣的情況下才可以說計劃保持在最新的狀態。 過於頻繁變更的計劃同過期的計劃一樣令人恐懼。我曾經見過這樣的專案計劃，該專案計劃每週都要修改，結果把專案的階段終止日期超出了一週的範圍。計劃每週都在更新，但專案工程仍然失去了控制。
　　對策：如果沒有公開的專案計劃你無論如何得趕快弄出一個來。如果你被告知，因為資訊的機密性你不能查閱專案計劃，那麼，你不妨把這一事件看做一個嚴重的警示跡象。除非你在開發新一代的原子彈，否則祕密專案計劃根本沒有存在的道理。保持資訊的隱祕通常意味著管理層知道專案出了問題，他們正試著把問題掩蓋起來。 一定要保證計劃常新而且還得具有合理的更新間隔。它不該是個不斷變動的目標，但它一定得是最新的。如果你不能保證專案計劃的最新狀態，那麼專案會出問題的。
專案快完蛋了，我該怎麼辦？
　　你發現自己的專案已經出現了以上一個或者多個預警訊號嗎？對這個問題的回答取決於你的個人狀況。如果你感到你能採取行動改變現狀，那麼你一定要立即行動。同專案經理、顧客或你隊伍中的其他成員對話。用一種就事論事、不具威脅性的方式討論你所關心的問題。試著儘可能提出正面意見。看看你能否給專案帶來轉機。 如果專案瀕於失敗而且你發現自己沒有辦法控制事態的發展，那麼你最好想辦法離開現在的專案。你也許能在同一家機構內找到一個好一些的專案，要不你乾脆離開現在的單位算了。反正走為上策。到這份兒上已經不是告訴某人該如何運做專案的時候了。
　　如果你粘在專案上了，或者正等著走人，那你也不妨換個看問題的角度。就當你在長經驗吧。比方說，你能從現狀中獲得什麼？如果得到授權你將採取什麼行動改變現狀？將來你該如何避免撞上這樣的專案？從當前專案進展中學到的知識和掌握的經驗必定能在你著手的將來專案上給你帶來莫大的幫助。 僅僅是個開始
　　以上的3個問題主要牽扯到業務和計劃方面，但是，專案遇險的跡象還並不止於這些。接下來，我們將繼續討論在失敗的專案中涉及到使用者和專案主管人員的4個因素，討論下這些因素是如何給你提出專案遇險警告的。
四個因素篇
　　總有一些專案會最終獲得成功，可是，相當大數量的專案卻沒這麼好的命。如果你不幸遭遇到這樣的處境，在事情惡化到不可收拾之前你如何知道專案遇到危險了呢？在《專案遇險的三個訊號》一文裡，談到前景不妙的某些專案時，我們已經針對和業務有關的跡象做了闡述。接下來，我們繼續探討一些牽扯到專案人員的危險跡象，它們大致上可以表現為4種預警訊號。
　　導致專案失敗的大部分原因不在於技術而在於同專案有關的人和過程，認為到這些更具“軟性”的問題是相當重要的。具體地說，其原因同使用者和專案發起人以及缺乏開發人員之間的交流有關（改變管理和工作報告）。如果你發現自己涉及的專案已經出現這樣的跡象，那就表明專案正在滑向失敗的邊緣了。
問題#1：你的客戶或使用者組不跟你說話
　　客戶或使用者不和你交流只能說明情況不妙。這意味著他們幾乎毫無積極性。不過也可能說明業務組太關注於具體的工作或者太忙了，難以同你合作，這就是說。如果正是那樣的情況，那麼專案正在向災難邁進了。你必須同客戶和使用者合作，這樣才能成功地實現專案。
　　缺乏使用者的參與只能意味著使用者抗拒變動。我們知道，所謂的“變動管理”，就其全部領域而言就是建立在贏得終端使用者的支援以及接受新系統和過程的基礎之上。這一方面不應該與被用來管理專案範圍的變動控制過程相混淆。變動管理不在這篇文章所涉及的範圍之內。但我們必須清楚地認識到，系統要想得到有效的實現就必須把使用者包含進來。
　　其他原因也可能造成客戶或使用者缺乏參與精神。比如，具體的業務決定了專案不得不取消或者實現一個不同的解決方案。專案贊助者可能讓使用者遠離專案，原因是系統實現之日就是他們失業之時。
　　任何專案都需要獲得客戶或使用者的輸入資訊，沒有它，系統需求和設計就等於在真空中呼吸。最終的解決方案根本不可能滿足業務需要。
　　如果你的客戶或使用者沒有在專案上與你一道工作，顯然。你的麻煩來了。
問題#2：專案發起人效率低或者角色不明確
　　有一位良好的專案發起人是專案成功交付的一個關鍵因素。他或她有助於專案目標的集中，為團隊搬走主要的絆腳石，從企業政治上講尤其如此。
　　專案發起人必須有清除障礙的能力，他們一定得有權力在利益發生衝突的情況下解決問題。他們還需要做出堅定的決策支援開發隊伍。
　　如果專案沒有明確的發起人，在開發過程中那些形形色色的障礙就必然會影響專案的進展。企業政治也會開始給團隊和工作說事。在專案發起人離開公司的情況下更會產生很多的問題。發起人為什麼要離開公司？他或她是被迫出走的嗎？發起人的政敵會試圖停止專案或者改變其範圍嗎？你的職業將會受到這些政敵的影響嗎？也許你壓根就不打算繼續逗留在這裡非要弄出個子醜寅卯。
問題 #3 ：沒有管理變動的機制
　　我們都知道，專案發生變動是不可避免，管理專案的變動非常重要。優秀的變動控制過程並難於管理，但是它們確實需要對細節保持關注。高效的變動控制要求同客戶或軟體解決方案的商務屬主密切合作。
　　不幸的是，某些專案仍然在沒有管理變動的過程的情況下運轉。要不就是專案的範圍含糊不清，或者不討論變動控制，或者客戶或業務主人不斷地根據自己的意願改變解決方案。沒有變動控制過程的專案是不可能得到準確估計的，這是因為解決方案的規模總在不斷地變動之中。另外，變動通常會導致某些重複性的工作，從而進一步推遲了開發過程令專案團隊失去動力。
　　記住，客戶不是變動的唯一來源。有時團隊自身也能引起範圍的變動。畢竟，團隊成員也是人，而人總會犯錯誤的。團隊的成員可能聽說或“假設”解決方案因客戶的實際要求而發生了變動。另外還有一種可能，那就是專案需求比較含糊，因此團隊成員從不同方面對其進行解釋。或者，團隊成員可能無意中創造出一個相比客戶需求更漂亮或更復雜的解決方案。這就是所謂的“鍍金”操作。
　　如果你所在的團隊沒有執行變動策略，你應該問一下原因何在。如果你找不出答案，那可要警惕了，專案很可能正在失去控制而且失敗的風險顯著增大了。
問題 #4 ：沒有準確的工作報告
　　準確的工作報告是專案的活命源。這些報告把有關的資訊報告給負責人，同時提供一種有效的機制來確定是否採取正確的行動。準確的工作報告還能起到記分卡的作用，可以顯示出專案的計劃完成情況。所有的專案都需要工作報告。
　　為什麼專案絕對離不開工作報告呢？主要有兩個原因：專案經理需要認識到專案的需求，或者工作不妙以至於專案經理決定乾脆啥也不說了。在這兩個原因之中，後者可能更壞。如果某個專案落在了既定目標之後或者超出了預算而有沒有上報，顯然這樣的專案不如取消。
　　如果你的專案缺乏工作報告，我看也沒什麼必要找出原因了。你趕快跑吧。
專案陷入麻煩該怎麼辦？
　　如果你不是專案經理，那麼你對瀕臨失敗的專案只能無可奈何。然而，如果你確定專案已經遇到麻煩了那麼你應該採取一些行動。
　　如果你的使用者拒絕參與專案，或者沒有給你足夠的專案運做時間，那麼你應該同專案的使用者方做一番開誠佈公的對話。雖說不一定就能拯救專案但也不至於給專案造成傷害。
　　尋找可以轉移的其他專案（反正比你現在的好一些）。順便說一句，別到處說你為什麼離開當前的專案。事成之後，每個人都會認為你採取了正確的行動。
　　如果事情糟透了，請打其他公司專案的主意吧。 如果你一直堅守在某個一兩年之後就瀕於完蛋的專案之內，它對你的身體、精神或職業都不會帶來半點好處。現在就採取行動。如果你不能拯救專案至少得拯救你自己。
八個訊號篇
　　作為專案經理，當你面對成堆的Microsoft Project工作任務報告時，想到已經花了好幾個小時陷入在扯不清、說不明的專案工作會議的泥沼之內，也許這是你感覺最令人惱火和沮喪的時刻。
　　可是，像這樣的痛苦會議還不僅僅意味著一種失敗感。它們的本質問題可能掩蓋得更深，這些問題會最終毀滅你經手的專案。這裡我想與你一道分析和了解專案即將陷入困境的一些跡象：
　　沒有引人注目的業務案例。那種“超酷”的Flash網站在增加業務收入方面的作用值得懷疑。
　　自作主張地編寫程式碼。如果你不同意業務需求或系統規範，你怎麼知道所交付的工作或規範是最新的？實際上你不可能知道。
　　沒有專案規劃。這是針對專案經理的。比如說，通過電子郵件交流的內容儼然成為系統的功能規範。這簡直是沒有藍圖就造房子。
　　你和你的顧客各說各話。發生這種情況時，你必須打消咒罵專案發起人家庭成員的慾望（比如誰誰母親的）。
　　專案發起人生活在“洞穴”裡。當你需要額外資源時就知道這將造成多大的損害了！當你的老闆要求給專案提供更多資助時，老闆的老闆卻只是眨巴眼睛——想想看，這有多糟糕。
　　不能應對變化的管理系統：除錯程式是小兒科。此外，我的程式碼執行絕對正確！——這可能嗎
　　沒有進度報告系統。你蹣跚前行，根本沒有什麼準確的專案進度報告系統，也許唯一的解釋就是到目前為止，壓根就沒人想提到這個專案。
　　在專案工作會議上，與會人員只會扯皮說“都是介面問題”、“必須採取行動”以及“該找某某人”。
　　當然，單獨地看，出現這些症狀並不意味著你的專案必死無疑。但它們確實都是需要你立即採取行動的紅色警報。如果你的專案出現了以上8個症狀，那麼只能說你已經在泰坦尼克號上了。準備自救吧。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7942439/viewspace-21093/，如需轉載，請註明出處，否則將追究法律責任。