任何項目都需要獲得客戶或用戶的輸入信息，沒有它，系統(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ā)生變動是不可避免，管理項目的變動非常重要。的變動控制過程并難于管理，但是它們確實需要對細節(jié)保持關(guān)注。高效的變動控制要求同客戶或軟件解決方案的商務(wù)屬主密切合作。
不幸的是，某些項目仍然在沒有管理變動的過程的情況下運轉(zhuǎn)。要不是項目的范圍含糊不清，或者不討論變動控制，或者客戶或業(yè)務(wù)主人不斷地根據(jù)自己的意愿改變解決方案。沒有變動控制過程的項目是不可能得到準確估計的，這是因為解決方案的規(guī)�？傇诓粩嗟刈儎又小Ａ硗�，變動通常會導(dǎo)致某些重復(fù)性的工作，從而進一步推遲了開發(fā)過程令項目團隊失去動力。
記住，客戶不是變動的來源。有時團隊自身也能引起范圍的變動。畢竟，團隊成員也是人，而人總會犯錯誤的。團隊的成員可能聽說或“假設(shè)”解決方案因客戶的實際要求而發(fā)生了變動。另外還有一種可能，那是項目需求比較含糊，因此團隊成員從不同方面對其進行解釋�；蛘�，團隊成員可能無意中創(chuàng)造出一個相比客戶需求更漂亮或更復(fù)雜的解決方案。這是所謂的“鍍金”操作。
如果你所在的團隊沒有執(zhí)行變動策略，你應(yīng)該問一下原因何在。如果你找不出答案，那可要警惕了，項目很可能正在失去控制而且失敗的風險顯著增大了。
問題 #4 ：沒有準確的工作報告
準確的工作報告是項目的活命源。這些報告把有關(guān)的信息報告給負責人，同時提供一種有效的機制來確定是否采取正確的行動。準確的工作報告還能起到記分卡的作用，可以顯示出項目的計劃完成情況。所有的項目都需要工作報告。
為什么項目離不開工作報告呢？主要有兩個原因：項目經(jīng)理需要認識到項目的需求，或者工作不妙以至于項目經(jīng)理決定干脆啥也不說了。在這兩個原因之中，后者可能更壞。如果某個項目落在了既定目標之后或者超出了預(yù)算而有沒有上報，顯然這樣的項目不如取消。
如果你的項目缺乏工作報告，我看也沒什么必要找出原因了。你趕快跑吧。
項目陷入麻煩該怎么辦？
如果你不是項目經(jīng)理，那么你對瀕臨失敗的項目只能無可奈何。然而，如果你確定項目已經(jīng)遇到麻煩了那么你應(yīng)該采取一些行動。
如果你的用戶拒絕參與項目，或者沒有給你足夠的項目運做時間，那么你應(yīng)該同項目的用戶方做一番開誠布公的對話。雖說不一定能拯救項目但也不至于給項目造成傷害。
尋找可以轉(zhuǎn)移的其他項目（反正比你現(xiàn)在的好一些）。順便說一句，別到處說你為什么離開當前的項目。事成之后，每個人都會認為你采取了正確的行動。
如果事情糟透了，請打其他公司項目的主意吧。 如果你一直堅守在某個一兩年之后瀕于完蛋的項目之內(nèi)，它對你的身體、精神或職業(yè)都不會帶來半點好處�，F(xiàn)在采取行動。如果你不能拯救項目至少得拯救你自己。
八個信號篇
作為項目經(jīng)理，當你面對成堆的Microsoft Project工作任務(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ā)起人生活在“洞穴”里。當你需要額外資源時知道這將造成多大的損害了！當你的老板要求給項目提供更多資助時，老板的老板卻只是眨巴眼睛——想想看，這有多糟糕。
不能應(yīng)對變化的管理系統(tǒng)：調(diào)試程序是小兒科。此外，我的代碼運行正確！——這可能嗎
沒有進度報告系統(tǒng)。你蹣跚前行，根本沒有什么準確的項目進度報告系統(tǒng)，也許的解釋是到目前為止，壓根沒人想提到這個項目。
在項目工作會議上，與會人員只會扯皮說“都是接口問題”、“必須采取行動”以及“該找某某人”。
當然，單獨地看，出現(xiàn)這些癥狀并不意味著你的項目必死無疑。但它們確實都是需要你立即采取行動的紅色警報。如果你的項目出現(xiàn)了以上8個癥狀，那么只能說你已經(jīng)在泰坦尼克號上了。準備自救吧。
