為你的專案把脈-提防十種專案病

當專案半路拋錨時，在沒有有效的外部干預下，將專案拉回正軌的機會將與日俱減。而接下來的問題將會成倍增長，團隊成員的行為將會惡化，錯誤也會一犯再犯。

　　發現並對專案中出現的問題的具體症狀進行觀察，是進行專案救助及干預的前提。將症狀與問題的起因區分開來尤為重要。一個問題的起因並不見得就會阻礙項 目的進展。例如，缺乏具體的業務需求可能導致將來出現問題。然而，若專案小組成員之間擁有默契，就有可能透過與使用者的有效合作，彌補該問題所帶來的不便。

　　徵兆性的症狀其實是一個預警系統，它告訴專案小組應該對問題的具體情況進行進一步瞭解，同時也告訴專案經理應該深入探究是否需要進行專案救助，以及如果需要進行救助的話，救助的範圍和程度應該如何掌握。

　　我們需留意的專案症狀有十種型別，下文列出了進一步緩和這些症狀的重要措施，以及一些亟需考慮的問題。如果你發現你的專案出現了其中任何一種症狀，就可能需要對之重新進行審視。

　　症狀之一：工期一拖再拖

　　專案的最後期限總是一延再延，其原因也各式各樣，其中包括計劃不周、意外頻發及業務複雜等等。你也可以下一道死命令，要求專案必須趕在最後期限內完 成，因為這很重要，但是這無異於自欺欺人。然而，不能遵循專案的進度安排或者不斷地將專案延期，將會導致專案團隊成員的行為變得非常糟糕。如果你的團隊總 是一而再再而三地貽誤專案期限，那麼你憑什麼認為他們會改變這種行為呢？這些問題是貫穿於整個專案，還是僅僅侷限於專案早期的幾個階段呢？誰應該為此負責 呢？沒有專案最終期限也意味著紀律渙散，缺乏約束。

　　專案經理可以將可交付成果分解開來，要求專案團隊每兩個星期就要完成一部分有價值且可衡量的成果。這樣成果會逐漸越積越多。對於風險較高的專案來說，這個時間可以設得更短一些。對可交付成果進行管理使得專案監管變得更加容易，同時也能在連貫的基礎上對風險進行管理。

　　症狀之二：要求不斷改變

　　即使大家都盡了最大的努力，還是有很多因素會導致專案要求經常發生變化。例如，新的想法被提出；原先的計劃考慮不周；業務的利益相關者改弦更張等等。 技術通常會帶來更多的變化。關鍵是要搞清楚，是要求發生變化了、被修改了，還是有所補充和完善，抑或是被其他要求所取代，還是說一直保持穩定沒有變過？如 果某人一直在改變主意，那你就要懷疑他是否真的知道自己要的是什麼。這種症狀是專案出現問題的徵兆，它預示著在專案預備階段就有可能蘊藏著深層次的矛盾和 問題。也許是對專案的預期並不明朗，抑或真正的決策者沒有參與專案的決策。也許真正的利益相關者並沒有被識別出來，或者雖然被識別卻沒有好好地向他們請教 過。
要求不斷髮生變化，這對任何行業的任何專案來說都是不可避免的狀況。其背後的動機是為了讓客戶和使用者感到滿意。然而，計劃周全的專案建立在早先擬定的專案 章程的基礎之上，且該章程中所確立的時間表建立在具體的業務要求之上。這筆賬很好算。專案要求的改變會影響到專案進度及專案成本，因此計劃需要更新，而擬 定的最終期限可能需要延期。

　　在專案啟動之初，即應明確變更流程是如何操作的，以及何時需要應用這一流程。讓相關方瞭解，未來的要求變更將要求專案團隊再次釋出專案資訊。在要求發 生改變之初，就應該讓相關方瞭解它將對成本、利益和專案本身造成的影響。讓使用者或利益相關者在這些事實的基礎上做出決策。
　　症狀之三：決策搖擺不定

　　業務決策有始無終、搖擺不定是風雨欲來的徵兆。這看起來雖然顯而易見，然而許多專案，不論是二人小組還是價值五千萬美金的大型專案，都有可能是建立在 某個高層的業務願景之上，而該願景則是由若干尚未完成的“故事”大綱和業務章程組成的半成品。這樣的願景只能帶著專案團隊前進一小段，直到你發現由於專案 缺乏清晰的目標而必須不斷返工為止。

　　在專案生命週期之初，我們就應該確定以下幾項關鍵業務決策：
　　·誰是企業的所有者-誰決定最終的專案驗收條件？
　　·專案的最終產品應該是怎樣的？
　　·缺陷率為多少是可以接受的？
　　·最終解決方案的績效以及運作指標有哪些？
　　·業務準則有哪些？哪些是關鍵？在剩下的準則中，優先次序如何？哪些將會被使用者所接受？
　　症狀之四：行百里，半九十

　　當某位專案經理第一次聽到專案已經完成了90%，肯定會覺得異常興奮和開心。專案完成到這個程度應該是一週一週不斷累積的成果，而且其成果應該是在定 期的進度報告或進度會議上予以彙報的。然而進度報告可能會存在若干問題。該資料通常都是建立在對專案的不精確評估之上，或出自於專案經理、專案協調員的直 覺。剩下10%有多複雜依然是個未知數，而且這個看起來較小的百分比還有可能讓人掉以輕心。

　　事實上，專案傾向於滯留在這個階段。當專案進度在相連的進度報告期間內停滯不前時，你就需要深挖其中的原因了。另一個預警訊號是，專案進度突然驟減。 例如，某個專案正以每週完成20%到30%的速度前進，而突然間你發現進度降到了1%或2%。這個時候專案小組也許才剛剛開始認真研究真正的專案要求，也 許在早先的進度報告會議上他們都過於樂觀了。

　　當專案進度走下坡路的時候，要好好想一想原因。這可能是由於新的專案要求所導致的，也可能是早期的進度彙報不真實的結果。通常，你所看到的下降比率可能並不會很低，因為專案團隊出於主觀願望，會對進度報告進行一些修飾。所以問題可能遠比報告上所顯示的要嚴重得多。
症狀之五：一切正常的假象

　　所有專案，只要不是太過微不足道，都會時不時碰到這樣或那樣的阻礙和問題。雖然其中的許多困難也許很容易被克服，但還是會出現。如果這些困難沒有上報，就說明專案團隊要麼是對專案探究得不夠深入，要麼就是沒有就相關資訊進行溝通。

　　專案經理也許需要仔細研究當前的專案進展和可交付的成果，以確保所提出的問題正是要旨所在。如果專案真的進展得非常順利，那麼在到達某個階段性里程碑時則理應慶祝一番。

　　症狀之六：沒有設定階段性目標

　　專案的關鍵可交付成果，有時也被稱作階段性目標，不僅僅指的是專案的最終成果，還包括用以確保專案順利進展的階段性可交付成果。

　　沒有階段性或者最終可交付成果的目標預示著麻煩將至。如果要求提交階段性或者最終可交付成果會造成混亂，那麼就必須藉助專案救助方案了。

　　當專案正處於下滑狀態時，專案救助方案是一項旨在迅速改變其方向的階段性的應對措施。這要求專案團隊必須為實現某些利益而做出相應的妥協。同時救助方案還須為專案設定發展的步調及氛圍，從而使得團隊成員能夠興奮起來並做到人盡其才。

　　症狀之七：人際紛爭四起

　　在推進專案的過程中，人際關係問題不可避免會發生。然而，對人際關係處理不當，會導致難以挽留員工、員工揚言離職，造成員工間的不愉快、士氣低下，出現恃強凌弱、自保反抗的局面，甚至引發無謂的口水戰，以及各個層面上的政治紛爭。

　　人際關係問題的出現警示我們應該探尋更為深層次的原因。由此而引發的其他問題將會浮出水面，包括質量不過關及貽誤最終期限等。

　　症狀之八：過多的質量問題

　　質量問題在專案的正常發展階段也許並不明顯，因為現在還尚未交付或尚未實現正常運作的成果可在日後另行交付。然而，質量問題的數量也不能超過一定的界 限。質量問題誠然是困難的一種，但是你也可以在出現質量問題時決定是按下求救的按鈕，還是認為這尚在可接受的範圍之內而予以承受。
　　我們應在專案的各個階段透過回答下列問題，對質量期望值及質量保證流程進行界定：何種型別的錯誤是可以接受的？錯誤孰輕孰重，如何解決？應進行怎樣的測試，從而發現錯誤？

　　症狀之九：面臨未知因素

　　從專案管理的角度來說，在不顯著增加專案成本或延長專案週期的情況下，試圖預測或緩和專案的每一個風險變數是不可能的。
然而，利用有效的風險管理流程對機率較高、影響較大的風險進行定期的評估，將有助於讓整個專案團隊的成員瞭解，在風險真正來臨之時應做出何種預期行為。專案計劃無法解決的風險則需要藉助專案救助方案來解決。
　　症狀之十：缺乏專案報告工具
　　你肯定曾經多次聽到過這種言論：“別把時間浪費在什麼進度報告上了，實實在在地幹活才是最重要的。”這種言論背後的觀點都是非常高尚的，也可以被運用 到任何專案管理工具或程式上。然而，在宣佈進度報告完全無用武之地之前，我們還須從以下幾個方面多加考慮。首先，如果出了問題，必須依靠這些報告工具來解 決。其次，如果沒有這些工具，當你知道有問題出現的時候已經悔之晚矣了。
　　由於缺乏專案報告工具，在那些沒有向專案團隊進行過彙報或溝通的領域內，鐵定會出現問題。如能較早發現這些問題，也許能夠將其克服。但是，缺乏報告工具通常意味著這些徵兆將被忽視，直到已經太遲。
　　專案細節也許有所不同，然而專案出現磕磕絆絆、停滯不前，甚至完全短路的原因卻是一致的。找出那些預示著問題的徵兆，那麼解決方案也就唾手可得了。這 也就是為什麼一個準確、及時的“診斷”是成功復甦和走向深淵之間的區別所在。診斷包括與管理層和團隊成員進行面談，以及對所有檔案，包括進度安排、資源、 業務和市場要求等進行深入而全面的分析。
　　“有大量的資訊等著你去分析，”PRTM管理諮詢公司的合夥人洛（Joe Lo）說道，“對那些剛起步的公司來說也許只是幾天，而對大公司來說可能意味著幾個星期。這取決於專案的大小。”
　　一旦發現了核心問題，就可以實施補救措施。“讓一個專案獲得新生這本身就是一個新的專案，”Project Corps.的總裁加迪（Shelley Gaddie）說道，“最重要的一步就是講出事實，並儘快把事實擺到桌面上。”
　　原文經許可摘自Joseph Zucchero和Sanjiv Purba發表在Projects@Work雜誌（）上的Symptoms & Sources一文（2005年3月24日）。Projects@Work登記2005年版權。魏力譯。
　　Joseph Zucchero和Sanjiv Purba是Project Rescue: Avoiding a Project Management Disaster一書的作者。Zucchero是Casey Group Project Turnaround Practice的執行副總裁和總監。他在專案管理方面有著24年的經驗。Purba是Purba Computer Solutions公司的執行長，並有著20多年的專案管理經驗，曾管理過多個不同行業、規模和複雜程度的專案



[@more@]