在項目管理中，經常會遇到一些實際問題，那麼作爲項目管理師如何收拾爛攤子呢?我們一起來分析分析!
問題:中途接手
我是項目中期接手的。原來時間限期達到的時候，項目只完成了10% 不到。只有 1/5 的設備給了客戶，軟件一點都沒有，環境完全沒有建立，甚至需要的網絡環境都不具備。所有供應商代理商的資訊我都沒有，所有的價格都掌握在少數人手裏。甚至開始的時候，我要自己去找網線在牆的什麼地方(以前的項目經理撒手不做之後，什麼都不想理會了，只給了我一張那時已經過期的，過去項目的進度表)。
分析:在沒有接手前就應該先搞清楚項目的現狀和麪臨的問題，你接手後是否可以獲取到高層的支援，可以利用的干係人和資源以估計項目風險和勝算。只要接手了就要承擔項目失敗的責任而不是去找客觀的原因推脫責任，項目存在的任何問題只要轉變心態都是可以找到解決方法的'。所以我們強調的是中途接手項目第一重要的就是充分的分析項目的現狀，理解項目目標，重樹項目團隊信心。但這絕對不是操之過急可以解決的，你越急會增加整個團隊的混亂。價格掌握到少數人手裏可能需要考慮的如何獲得他人的信任和高層的支援，自己找網線更不是什麼大不了的事情，團代隊沒有穩定前項目經理可能充當任何一個團隊成員的角色。
問題:沒有需求管理
我甚至不清楚過去項目進行中，以前的項目經理、業務甚至是公司總經理對客戶口頭做出了什麼樣的承諾。客戶經常把我問的一楞一楞的。他說：以前你們公司都滿口答應了，爲什麼你還推三阻四的。其實不是我不答應，我是要負責任的啊，有些根本就是不現實的，或者對項目進度有重大影響的。我回公司問相關人員，沒有人可以確認相關問題。
分析:完全是公司自身的工作交接出現問題，你和以前的項目經理，業務和公司總經理應該進行完整的工作交接，以前項目經理有過的口頭承諾雖然沒有透過需求管理很好的管起來的，並不代表這些資訊無法獲取到。新項目經理去和客戶溝通之前必須對整個項目有完整的理解，透過工作交接將用戶的需求文檔化下來，如果不這樣倉促和用戶溝通是很被動的，而且用戶本身也不應該承擔這些重複講解需求的業務。
要讓對方讓步首先要表明你已經付出了巨大的努力，客戶也不希望整個項目搞砸，這樣的話客戶方的相關人員應會承擔相關的責任。所以明白2/8原則哪些是用戶真正關心的功能和模組，這些纔是需要重點考慮和滿足的。
問題:客戶拒絕交流
由於中途接手，客戶告訴我，相關的需求已經同我們公司不同的人員講述了三次，不想再多講一次了。而且，要求直接和我們的程序員對話。但是那個程序員已經走了，不再做了，他連一份書面文檔都沒留下。只有代碼。
分析:工作交接和過程管理真的太多問題了，這種項目沒有最終失敗真的都是奇蹟，在這種焦油坑下已經不是去改進工作現有的過程可以挽救的了。先給公司內部人員溝通吧，用戶給公司講需求不會每次都給那個走了的程序員一個人講吧?這種情況下要麼項目經理是業務技術超牛的能人，要麼項目經理能夠找到1-2個類似的能人。能人的作用就是項目經理他們創造良好的環境後，他們往往能夠創造奇蹟，從代碼逆向分析需求不是什麼不可能的事情。
問題:沒有資源
要人沒人要錢沒錢。客戶要我們程序員配合，沒有。要錢請民工，因爲我是中途接手，甚至成本都算完了，我不能申請。要項目獎金，沒有。甚至我當初要求給客戶的設備，推遲了四次，累計三週的時間纔給到客戶。項目能不延遲麼?
分析:暈倒，再死亡之旅的項目能大逆轉的前提一定是資源能保證和項目高層的支援，如果這點還不能滿足，項目基本註定失敗。聰明的項目經理對於這種項目一定是不會盲目接手的。如果接了，你唯一的期望就是如何死的好看點，如何爲這次承擔替罪羊後撈取其它的資本補償。
問題:無法控制的進度
沒的說了，各種以前遺留的問題冒出來打擾我的進度。而且公司經常調我的人手去做其他的事情(小公司麼)。甚至問程序員那邊要進度表，給我的表嚇我一跳，整整比預計推遲了兩個月(要知道，總共才兩個月的項目時間要求，而且已經是和客戶協商推遲的了)。其實程序不復雜啊。
項目做到現在，我已經把所有的硬件問題解決了，並且客戶要求的主要工作，我也做好了大半。但是最關鍵的程序卻一直沒有辦法給到客戶，客戶越來越惱火了。他們計劃的是上個月就一定要用上我們的軟件!
分析:生於憂患，死於安樂。項目經理沒有很好的風險意識而防患於未然，再好的進度跟蹤和控制都沒有用。