某軟件項目工程延期的處理案例
某公司是一家專門從事系統集成和應用軟件開發的公司，公司目前有員工50多人，公司有銷售部、軟件開發部、系統網絡部等業務部門，其中銷售部主要負責進行公司服務和產品的銷售工作，他們會將公司現有的產品推銷給客戶，同時也會根據客戶的具體需要，承接應用軟件的研發項目，然后將此項目移交給軟件開發部，進行軟件的研發工作。軟件開發部共有開發人員有18人，主要是進行軟件產品的研發，及客戶應用軟件的開發。
經過近半年的跟蹤后，今年元旦，銷售部門與某銀行簽訂了一個銀行前置機的軟件系統的項目，合同規定，5月1日之前系統必需完成，并且進行試運行。在合同鑒定后，銷售部門將此合同移交給了軟件開發部，進行項目的實施。
王偉被指定為這個項目的項目經理，王偉做過5年的金融系統的應用軟件研發工作，有較豐富的經驗，可以作系統分析員，系統設計，但作為項目經理還是第一次。另外項目組還有另外4名成員， 1個系統分析員（含項目經理），2個有1年工作經驗的程序員，1個技術專家（不太熟悉業務）。項目組的成員均全程參加項目。
在被指定負責這個項目后，王偉制定了項目的進度計劃，簡單描述如下為：
1) 1月10日～2月1日需求分析
2) 2月1日～2月25日系統設計，包括概要設計和詳細設計
3) 2月26日～4月1日編碼
4) 4月2日～4月30日系統測試
5) 5月1日試運行
但在2月17日王偉檢查工作時發現詳細設計剛剛開始，2月25日肯定完不成系統設計，您建議王偉應該如何做？他在項目的管理中有問題嗎？
分析列表：
題目：項目在2.1完成需求分析 作者：forgiveme (moto ltd. wuweihua@sina.com.cn)
項目在2.1完成需求分析，在設置檢查點的時候，在此是否應該考慮有個點；在項目計劃中應該對項目的關鍵路徑進行設置，并依據此路徑設置必要檢查點。
問題既然已經發生，5.1已成為必定的時間，那么，首先必須對原因進行分析，在之基礎之上再進行重新構建，我會考慮對項目范圍作些調整，也會作些相應的加班
題目：否有例會 作者：forgiveme (moto ltd. wuweihua@sina.com.cn)
延期前：
1、5月1日這個日期是如何定下的？定期Deadline之前是否考慮了公司的研發資源/力量？
2、項目開始前是否做過風險分析？進度是否是該項目的風險？
3、項目是否有例會？例會的頻度是否與項目的周期相匹配？例會的議程是否包含對目前項目面臨的問題/風險的跟蹤？
4、項目組的組成：項目經理同時又是系統分析員。項目經理應該懂業務，最好不要當系統分析員，不然會陷入技術細節糾纏不清。
5、項目計劃是怎么做出來的？是否經過工作量的詳細估計？是誰估計的？應該由具體執行人員估計，再加上技術專家的意見。
6、是否識別出了關鍵路徑？是否對關鍵任務進行了重點監控？
7、項目的人力資源是如何獲取的？是否與該項目的難度、進度相匹配？資源的數量是如何確定的？是根據工作量確定的嗎？
題目：計劃調整是必須的 作者：寇震 (中鐵十八局集團 18kz@vip.sina.com)
軟件開發計劃包含了需求分析，這是造成開發計劃不準確的最大風險來源，我們的開發計劃必須是根據需求分析后，進行工作分解得到的，而我們通常都不能這么做。我認為需求分析后，再次進行計劃調整變更，確定項目的最終時間表，并和領導、客戶溝通是最可靠的。
題目：常見現象 作者：李子軍 (北京諾德信科技開發有限公司 zijun.li@nordsan.com)
雖然王偉第一次做項目經理，但僅從本文描述來看，并不能完全斷定王偉的管理有問題：
1、階段性的時間延遲是常有的事，資深的項目經理也不能完全控制每個階段一定遵循預定時間
2、對于需求不明確、業務背景復雜的項目，適當延長需求分析的時間，有利于保證后期設計的準確性和減少需求變更的幅度和次數
3、需求分析是與客戶共同開展的，你所做的工作、所花費的時間，客戶是有目共睹的，是能夠容忍的
4、延誤的時間只有從后面幾個階段中擠出來，例如編碼和測試同步進行等
5、萬不得已，由于客戶原因導致項目延期，適當延長工期，是必不可少的，總比開發成果與客戶預期相悖要好
為政府實施電子政務項目的案例
公司A是市政府背景很強的股份制企業，機制比較靈活（shanghai），目前該公司的正在進行的一個項目是政府機關的一個Mis系統，現在整個開發全部完成，系統已經試運行2個月左右，目前運行情況比較順利，但是，目前有幾個比較大的問題如下：
1. 客戶同公司關系特別密切（畢竟客戶是機關），不能完全按照合同進展。
2.政府的工作節奏比較慢，在項目實施進程中，嚴重單方面拖延實施進度，造成項目延期。（他們很小的項目決定需要開會討論）
3.不可預測的項目變更風險（機關領導一句話，項目經理就要處理變更需求；可稱其為領導人風險）。
4.客戶沒有項目周期（軟件項目）等認識，對合同規定的驗收不予回應。這個需要該公司老總才能協調。（項目經理沒有這方面的權利）
項目經理在項目組中本來負責軟件開發設計，開發后期被部門經理任命為項目主管，對于客戶主關需求變更，項目管理目前溝通的比較好。但對于一些政策性的變更，則非常的難處理（需要必須改動），沒辦法，只有進行變更處理。該公司應該怎么才能結束該項目呢。
分析列表：
題目：維護方式 作者：丁丁 (m ccdingr@hotmail.com)
客戶是政府機關，單位機制。不太適應常規的市場經濟運營方式。那就軟件公司適應客戶吧。
1、列舉重要的指標點，讓客戶確認。
2、在合適的時間點，把項目由開發階段過渡到穩定維護階段。而且可以收取所謂的驗收費用（運作～～）
3、抽出原班人馬，穩定一個階段后，指定個人，就在現在做維護和簡單開發（不限期），也是保持良好的客戶關系，和公司名譽。
題目：分析干系人 作者：張清儉 (大連 zqjcep@vip.sina.com)
這是中國現階段制度決定的。在接政府的項目時，干系人分析顯得異常重要，一定要有風險分析和應對計劃，管理儲備的比例也要增加，同時項目經理的溝通時間提高到95%。
題目：服務客戶，培養人才 作者：賀煒 (西北工業大學 ishewei@163.com)
以前我們也曾接手這樣的兩個政府信息化項目，最終通過為對方培養人才脫手的。最后項目完成后一個月，還偶爾要求我們過去，后來就完全由我們培養的政府自己的技術人員接手了。
題目：電子政務實施中的服務意識 作者：冷酷到底 (EXOA exoa2002@163.com)
電子政務建設必須經歷“從無到有，從有到好”的過程，所以我們在事實電子政務的時候也必須向用戶灌輸一個這樣的理念，明白電子政務的建設需要過程需要時間，如果達成一個這樣的共識的話項目的實施相對來說風險會小的很多，所以曉川先生分析的非常的精辟，但是電子政務建設出現了“用而不驗”或“驗而不用”那就是項目組的悲哀，所以實施電子政務項目必須要樹立一個服務意識，項目靠服務產生利潤，而不是單純的靠產品產生利潤！政府向企業買產品，也要買服務。項目應該將設計和實施劃分開來，明確設計和實施的區別和界定，這樣項目作的輕松，政府用的放心，用戶當然也是開心了（特別是領導，電子政務是很大的業績），總結一句電子政務項目實施要企業要作好定位，服務才是最能產生利潤的。
題目：關系與商務不能等同 作者：陳榮森 (深圳市佳創 meid998@21cn.com)
與客戶關系親密固然是好事，但不能等同于在做項目時都事事遷就于客戶，朋友是朋友，商務是商務，不能等同，否則會陷入很被動的局面。建議：
如果客戶領導提出變更的想法，你不好意思明說，但你必須每次都向他列舉這樣的變更會給系統帶來很大的變更和變更的困難，以便給提出變更的客戶壓力，隨著壓力的積累，客戶再次提變更時會有壓力而變得謹慎。
題目：如何實施電子政務項目 作者：石靈 (SIM shilingchen@sina.com.cn)
我同意曉川先生的說法。在我國的行政機構中存在的兩個突出問題就是領導意志和作風拖沓。相信在短期內這一現象難以消除。因此，階段目標的制定就變得非常重要。管理水平的提高，往往不在于某項重大制度的變革，而是基于許多細微的、漸進的變化。因此，在進行階段目標的設定時，要首先提供讓政府各級部門感到方便的功能，使他們逐漸具有興趣，從而形成一種良性循環，其過程如同微軟公司的軟件發布一樣。
我們做的是一個財務管理軟件，在項目初期我們的項目經理做的售前工作，跟客戶了解了大體的需求，并且制定了項目方案，而項目方案是一個很籠統的框架性的東西，而我被指派與客戶詳細的調研需求，整個項目的與客戶面對面接觸調研需求共3次，第一次我已完全理解客戶的需求和意圖，而第二次并沒有什么實質性的收獲，因為客戶給我的時間就很少，我們只簡單討論了與客戶現存系統的接口問題，第三次談需求，客戶提出了一些需求而針對他的子系統的結構是很難實現的，當時我極力反對，但反對無效，因為我們的客戶分兩部分：轉包客戶、最終客戶。
這還是個二包項目。而這種很難實現的需求是最終客戶提出而轉包客戶不反對反倒支持。這樣三次需求調研的結果就是得到一個業務邏輯異常復雜的業務模型。有了詳細的業務模型之后，我很快初步估算出代碼最少5萬行，并且向項目總監通報了情況，但是項目總監認為項目不可能這么簡單，也沒去與客戶溝通。
我只好按著這個需求繼續往下進行（當我與客戶做二次需求調研時，我就已經變為項目經理的角色，當然此時我就是項目經理了，而原來的項目經理就是現在的項目總監了），當然了，在有了詳細業務模型后，我們先設計了軟件原型，用了兩個星期，這階段解決了幾乎所有的界面組件（有很強的通用性）。然后再與客戶討論原型，不過客戶那邊的反映很遲緩，光讓他確認這個原型就浪費了二十天時間，不過這段時間我也沒閑著，開始著想考慮他那個難纏的需求是不是有什么解決方法，結果分析來分析去，最終得出結論，根本不存在什么合適的解決方案，而這塊需求倒底做不做一直困惑我很長時間，其實與客戶溝通很不方便，因為我們開發的地點與客戶不在一個城市里，對于這樣的問題我跟客戶在msn上溝通過多次，客戶都不明白我要說的問題的本質是什么，他還是堅持要實現這個需求，結果為此我又努力償試尋找解決方案。
客戶催要一個初步的軟件版本，因為但是因業務邏輯的核心問題，我們無法進行業務模塊的編碼，已經完成的是與業務關系不大的部分。而此時我又進一步估算，代碼量應該有8萬行了，因為更細致的架構接口已經有了，也就是說一個完整的框架都有了，估算出的代碼行數就比較準了。
8萬行代碼遠遠超出了原來的預算，就是去掉與客戶不斷的爭論業務需求的時間都用來寫代碼，8萬行代碼也不是這個費用夠用的，目前我處在騎虎難下的境地，公司要求我能拿出有利于我們有說服力的證據來，但事實上，客戶除了那個比較難纏的需求外，沒有更多多余的需求，而我也只對需求做了一些潤色，我覺得這是很有必要的，去掉反倒不妥，并沒有增加多余的需求。但就是這樣的需求完成他確實需要寫8萬行代碼，如果去掉業務員的功能，我想能精減個一萬行代碼。那還有7萬呢啊。
公司要求我在盡可能短的時間內先完成一些基本的功能，但我不知道應該如何劃分基本功能，在我看來，這些功能都很必要嘛，可以說大部分功能都是緊扣客戶需求的，只有少部分可以暫時省掉。與其說在最短的時候內完成一個基本功能版與客戶談，還不如說在最短的時候內完成軟件第一個完整版本（只缺少很少的一點兒功能），短時間肯定沒戲。完成了再跟客戶談價錢嗎？其實這個項目我們是賠大發了，繼續做，公司也是支持不下去的。
這個問題難道就無解了嗎？
案例太長了，大概了解了一下意思：
我的建議如下：
1.軟件開發前期準備做的不到位，項目的準備成本是永遠低于實際操作成本（當然在項目完成時間內）；
2.將用戶需求明細在合同中；
3.項目開發的所有功能均按照合同的確定后方案執行，期間用戶需求一但有變動，需讓用戶直接與項目管理人溝通，并明確需求的變動不在我方。
個人建議，請參考！
題目：重新梳理需求，評估項目和預算，適量要求追加預算 作者：游永明 (廣東省計算中心 yym@gdcc.com.cn)
通過對案例的分析，我們了解到
1、對于項目的需求比較清晰，但是核心業務了解不夠，同時還存在不合理需求
2、項目進度控制存在問題，和客戶溝通因為2次轉包存在一定的弊端，對客戶的引導不夠
3、對系統基本功能把握不夠，其實也是對客戶業務不夠深入了解
4、工作量估計出現很大出入，導致預算超支
我的建議：前面有朋友提出加強和客戶溝通，確定基本功能等，我再補充一下。針對客戶急需初步版本，我認為可以選取兩個業務流程來重點實現，作為demo版本演示給客戶以增加客戶信心。另外比較重要的是重新梳理需求，刪除自己認為合理但是得不到客戶認同的，列出客戶重點需求。根據梳理后得需求重新估計工作量，確定項目預算。最后就是針對梳理后的需求，進行合理的調整與客戶溝通增加投資的問題。適當采用需求增加導致費用增加的方法，因為案例并沒有提到客戶對需求的完全確認，這是一個突破口。
讓客戶對你們有信心，同時你們要顯示出自己的實力，最后就是雙方的妥協適量增加投資預算，達到項目的最終完成。
題目：確定客戶要的基本模塊,并只保障之 作者：黃飛生 (保留 SZFISION@YAHOO.COM.CN)
1 確定客戶要的基本模塊,并只保障之.
2 下狠心的把自己很滿意的部分也按實際的客戶基本需求情況進行刪除.
除非充分與客戶溝通,得到新的資源.沒其他辦法!
題目：項目執行所需要的人員成本超出了預算，而且項目已經嚴重泄后 作者：kitty (南京 jiwei1030@163.com)
既然是用戶型的項目，那就應該好好的利用客戶。其實客戶有時自己都不明白自己要做的是什么，要實現的是哪些功能。所以在前期需求階段要花費很多的時間與客戶討論，究竟做哪，怎么做，然后達成一致的意見。這種意見不是口頭的，而是要經過雙方具體代表性的人物簽字確認的。。否則后面的變更會變得不可追溯。。
題目：軟件的基本功能！ 作者：趙宏偉 (東信北郵 zhaohongwei@ebupt.com)
其實針對一個軟件的基本功能完全可以和用戶談判或者討論來決定的！ 在規定好的時間內完成相應的內容！ 這樣子也是一個項目執行過程中的調整！ 你自認為的“在我看來，這些功能都很必要嘛，“ 這都是你自己認為的 并不表示客戶真正需求的！
所以在最短的時候內完成一個基本功能版 完全可以在自己的控制之下完成呢！
題目：確認需求 作者：唐旭東 (電子有限公司 zhengwest@163.com)
其實對于需求調研工作,我覺得這個是在培養客戶,而不是在讓客戶任意發揮,因為客戶不會對自己隨口說出的話負責,只是覺得有這個需要,想這么做,在這個時候:
1.我覺得關鍵是要引導客戶,把客戶引導到自己的思路上,這樣才有助于項目的進展,因為客戶在自己心中不會有系統的模型;
2.其次,是要控制需求,抓主要矛盾,把主要的功能先實現,保證在主要的業務上系統能夠實現,不會出問題;
3.再次,我覺得原因在于沒有完全了解客戶的業務,也就是說以前沒有這方面的業務經驗,對于需要調研那些方面,那些范圍,沒有在調研前做一個詳細的分析和整理;
題目：精簡需求 作者：陳晨 (河北保定智能電腦有限公司 seesunny@126.com)
1、最主要的還是要有機會與最終用戶溝通。了解所作項目用戶最關心的是那部分。這部分作完成后等于完成了80%的工作。
2、確定哪些部分不用臆想出來的，把這部分僅僅做個界面，和簡單的功能模擬就可以了。
3、如果希望項目成功，建議，不要僅僅看需求文檔。要看用戶的工作是否真的非常緊迫的需要某些功能。如果是沒有什么含糊的努力做，如果不是就可以簡單帶過，功能有了就可以了。
當前最需要做的是把自己需要的工作，理順出來，看看那些才是最重要的中心環節，這些弄明白了，個人認為可以按步就班的開發了
題目：一點拙見 作者：于先生 (南方數碼 eolia_yu@126.com)
1、看來應該是前期調研補充分的結果，那么現在在時間和資金緊張的情況下，可不可以只考慮客戶最急需的部分，而不是自己認為有用的部分，此后在試運行期間完善呢？
2、可以根據項目進展情況，做一份項目實施估算報告，體現出導致緊張的各方面，這樣更有說服力，并且一定要和總監與客戶三方對話，因為這種情況下客戶只認總監。
3、給出新的項目需求、實施計劃及困難所在，必要時重新談價格。
最近遇到了一個版本控制的難題，導致多次上線后系統大面積癱瘓。正在進行的項目是一個二期開發項目，一期、二期在一個同一個環境，目前項目內的工作內容有：對于一期中Bug的修改、更新和對于二期內容的開發。其中：一期內容和二期內容有很強的關聯性；一期內容的Debug結果要求用戶方面測試，測試后及時更新上線；二期開發內容要求分階段上線。所以結果導致：有時一期Debug結果上線后，影響二期開發、已上線內容；有時二期開發內容上線后，影響一期內容，或一期Debug上線內容。
最常見的頭疼問題比如：功能A是一期Debug結果、兩個月前開發完成，近日用戶測試完成，A功能完成后，Debug開發進程繼續。功能B是二期功能，一個月前開發完成，二期開發進程繼續。在A功能開發完，但未上線的時候，對于A功能相關的類進行了更新。
昨天，用戶要求對于A、B功能進行上線，但不能有其他內容上線。結果：A功能上線后，由于修改了某二期內容（已上線）的公用函數，導致原二期系統癱瘓；B功能上線后，加入了B功能之后開發的代碼內容，但是由于DB更新沒有進行，導致系統報錯。
抽象化一下就是：N久以前，項目組開發了若干個功能（比如20個，其中有復雜的公用類和接口），之后繼續進行開發（此時有嚴格的版本管理），之后，用戶要求對于其中的1，2，6，8，19號功能上線，結果上線系統癱瘓，但開發，測試環境的測試過程，是最新的結果，包括所有功能，沒有任何報錯。
分析列表：
題目：應該加強產品管理 作者：游永明 (廣東省計算中心 yym@gdcc.com.cn)
（剛才按錯了，重發）
案例的項目問題在于將開發管理和產品管理分離開來，或者說沒有嚴格進行產品管理導致。
一般來講開發人員手頭會同時擁有兩個版本的開發權限, 一個稱為trunk分支,又叫做功能變化分支, 一個稱為bugfix分支, 簡單理解, trunk會有功能的增加, bugfix沒有功能的增加。
案例提到的一期和二期就是bugfix分支和trunk分支的關系，雖然案例中提到嚴格的版本管理，我分析應該僅僅是指開發庫的管理，沒有涉及產品庫。其實我們知道版本庫應該包括兩個：開發庫和產品庫。
案例應該加強的是產品庫管理。一期的bugfix正常發布，但是二期的發布應該是對一期bugfix發布的一個merge才正確。公共庫還是統一維護，并且整個作為一條產品線來維護才對。
題目：應該加強產品管理 作者：游永明 (廣東省計算中心 yym@gdcc.com.cn)
樓主的項目問題在于將開發管理和產品管理分離開來，或者說沒有嚴格進行產品管理導致。
題目：版本控制的難題 作者：arkingchen (tn arkingchen@hotmail.com)
對公用函數庫進行版本區分
一期和二期使用不同版本的公用函數
項目管理需要溝通－wadcom公司案例
-------------------------------------------------------------------------------
Wadcom是一家跨國電信設備公司，在中國設有分支機構。公司在中國的組織結構如圖1所示。
2000年7月，Wadcom公司與中國的運營商A公司簽訂了全國29個城市的IP電話設備供貨合同，合同總值超過1.5億元人民幣，計劃一年完成。
為此，Wadcom公司成立了專門的項目團隊，由銷售工程經理Harrison擔任項目經理。項目團隊的其他成員如表一所示。項目的干系人還包括A公司在國內29個城市負責確保現場安裝環境的工程師，以及A公司聘請的負責系統測試的工程師。
7月20日，Wadcom公司中國區總裁Peter召開了第一次項目大會，開發團隊中的Grant和Art以及生產項目經理Nick 和訂單管理經理Jerry通過電話參加會議。會上宣布了項目團隊的組建事宜。
隨后的一周，Harrison和助手Jane一起完成了項目說明書和項目計劃的起草，并提請相關人員確認。之后，項目正式啟動。
項目初期進展得很順利。很快，Harrison和Jane就制定出了項目時間計劃、資源管理計劃和風險管理計劃等。
此時，位于美國總部的開發團隊項目經理Art提出，希望銷售工程師能夠提供更多的用戶需求細節以便提高開發效率和準確性。為此，Harrison制定了為期一個半月的每周開發例會，要求Art和售前工程師Bing以及相關人員參加。
緊接著，訂單管理經理Jerry告訴Harrison，由于事先沒有溝通，出于“零庫存”的考慮，公司沒有過多備件，需要延長交貨時間。Harrison與生產項目經理Nick討論后得知，交貨時間可能比預期要晚兩個月。顯然，這是無法接受的。因此，Harrison將此問題提交給Peter。Peter要求Harrison制定了為期兩個月的每周兩次的訂單狀態報告和協調會議，并要求相關的高層經理參加，盡量縮短交貨時間。
在即將交貨的前兩周，在一次和A公司的研討會上，Harrison突然得知A公司項目中有些輔助的備件現場沒有，這將影響施工進度。無奈之下，Harrison 要求系統安裝和支持隊伍在兩周內到現場做實地勘察，并將所需的材料和備件統一上報。由于工期緊迫，這些輔助備件不得不在國內單獨采購。因而，Harrison需要組織采購工作會議，并設置采購的工作程序。
此外，由于A公司各省局的相對獨立性，項目的培訓和準備工作比預期更為復雜。雖然合同中規定了較詳細的內容，但Harrison還是不得不參與本應屬于A公司的一些具體工作。
最后，所有貨物運到安裝現場比預期晚了近一個月。在此期間，項目相關的培訓工作也結束了，項目進入現場安裝階段。
Harrison本以為項目前期那些繁雜的會議可以減少了，然而很快他就發現新的問題接踵而來。由于恰逢國內春節時期，A公司各省局全部封網，項目不能按計劃進行。Harrison需要重新計劃各地的實施日期，這給原本緊張的工期又增加了壓力。另外，由于工期的延誤，負責施工的技術人員已開始忙其它工程，Harrison還得重新與負責技術支持的經理磋商安排。
經過近3個月的安裝和調試，系統開始試運行。按照合同規定，尾款要等到驗收合格才能支付，雙方都組織了各自的測試隊伍。3個月后，系統通過測試，項目在2001年9月底結束。
在一些大型項目中，通常涉及的項目人員眾多，并且會有多個職能部門參與。如何將這些職能人員組成一個有效的項目團隊，是項目成功的關鍵因素之一。
管理需要溝通
管理學指出，通常，管理者要用70%的時間用于與人溝通。而對于項目經理來說，需要花費90%或更多的時間來進行溝通。
就像上文的案例中，Harrison不但要與公司內部的銷售、開發、生產、安裝、培訓等多個部門打交道，還需要與公司外部的客戶打交道。因而，溝通就不是一件容易的事情。
在上面的案例中，由于項目經理在溝通管理方面做得不夠，“麻煩”接踵而至。先是庫存不足需要延長交貨時間，然后又出現安裝現場缺乏輔助備件等問題。原本項目經理制定好了項目計劃，安排好了項目進度，卻總是被一些“突發事件”搞得措手不及，最終還影響了項目進度。
溝通管理的六要素
那么，如何在項目中進行行之有效的溝通管理呢？一般說來，要從以下六個方面來考慮。
首先，項目經理應該將溝通本身加以計劃，也就是要有具體的溝通計劃。雖然在各類項目管理教材中有許多關于溝通管理的論述，但是真正的IT項目環境中，大多沒有具體的溝通管理計劃，一般都只是簡單羅列了項目的干系人。溝通計劃的制定至少要包括以下幾個方面：
1、項目干系人的列表。最好以團隊為基礎建立干系人列表。
2、確定以團隊為基礎的項目干系人的信息需求和溝通需求，即何人何時需要何種信息。一般來講，由于大的項目溝通渠道實在太多，以團隊為基礎能夠大大減少這種渠道。
3、信息分發的渠道和方式。對于重要的項目一定要有定期的項目績效報告和問題狀態報告。
4、項目定期會議，最好是每周例會。這樣，項目干系人知道有了問題在何時能夠得到討論和解決，并可避免突發組織會議找不到人的局面。
5、特殊問題的溝通對策。
其次，項目經理要盡量利用好干系人的首次會議，將項目的內容做較為詳細的交待，并提請所有干系人對項目可能出現的問題提出建議。
在本案例中，需求不清和備件不足的問題如果很快被識別，就不會出現臨時組織會議的復雜局面。因此，除了項目成立大會外，項目經理最好再召開一到兩次全體項目干系人大會（或以團隊為基礎的會議）。也就是說，在解釋了項目的背景并分發相關的信息以后，留給項目干系人一到兩周時間仔細考慮可能面對的問題，并及早識別加以解決。這與風險識別并不完全一樣。有時候，識別的可能是風險，有的時候可能根本就是一種實際情況，如案例中公司備件不足的問題。
第三，項目經理要嚴格控制會議的次數和內容，全面管理自己的時間分配。在上文的案例中，Harrison組織了很多的例會，與不同的項目團隊交流。此時，項目經理要明確自己的職責，要努力將會議的時間限制在一定范圍。并且，會議最好要形成具體可行的活動內容，并指派具體的實施人員。
第四，項目經理要理解溝通的不同層次，同時要利用這些層次為自己的項目服務。即使項目經理本身就是一個高級管理人員，他通常也無法解決所有的問題。因此，項目經理需要定期與高層管理人員進行交流，需要高層解決的問題一定要及時上報。
第五，溝通的目的一定要非常明確，項目經理要對溝通的內容進行管理，要注意防止跑題。跑題的情況通常在項目的后期中容易出現，隨著項目人員的熟悉，很多與項目無關的話題都有可能占用項目會議的時間，并且通常還不易察覺。因此無論是項目會議還是相關文件，都要明確所要討論的內容。
第六，溝通不僅局限在公司內部，同時也要同外部，尤其是客戶進行交流。特別是對項目重要的里程碑，需要征得客戶的支持。這包括客戶的準備活動（最好有一份準備文檔）、施工的時間、客戶的工作日歷等等。
事實上，溝通管理是一門復雜的管理科學，需要項目經理在實踐中加以總結。項目管理中的溝通與日常管理中溝通的不同之處在于，項目經理要在最短的時間內，達到滿足項目需求的溝通效果。
某一家軟件公司，近來接到一個B/S結構的PHP網絡應用程序項目。此項目由五個開發人員組成，項目經理亦充當開發人員的角色。
開發的初級階段，使用的是Windows為基礎的IIS 網絡服務器，而有的開發人員卻使用了Linux 為基的Apeche網絡服務器。
當項目開發到了中級階段時，項目經理決定進行一次“里程碑”的第一次整合測試，結果很顯然的，不同服務器的代碼不能正確的整合在一起，而項目經理命令繼續開發下去。
當項目開發到了終級階段時，出現文件路徑問題，和諸多沖突，有的開發人員不得不進行很大程度的修改。同時發現，很多開發者開發的代碼，在項目進展過程中也未能及時得到整合。
項目管理的處于失控狀態，請問這個項目的問題要主在哪里，應該如何處理？
分析
題目：教訓 作者：高華 (中國石油 ghchianren@bgp.com.cn)
我認為這個項目沒有按照項目管理要求去做．
項目初期沒有規劃，團隊人員思想不一致，沒有方案的詳細設計或是接口沒設計好，就開始行動了．顯然的無組織，無紀律，無目標．第一步就導致了項目的失敗．
在項目經理發現問題后沒有和團隊成一起分析問題，找出補救措施．是錯上加錯．
如果要補救已經是不可能的了．和隊員達成共識意見后從頭在來吧．
題目：補課！ 作者：張翼 (SHPM Dill_Jacob@hotmail.com)
在項目中采用異構整合，不見得不可行，關鍵要先做好架構設計，至少是接口設計。
不少軟件公司在做項目時，都急著寫代碼，結果是生產出許多無效代碼。既然樓主來到了聯盟，就應該運用你的項目管理知識，設法扭轉這種局面。
項目經理兼做開發，不應該陷入具體的技術問題的研發，不妨擔負起技術經理是職責，把這個項目的設計做好。
問題主要出現在哪里？這個問題實在讓我無語！
現在解決問題最有效的辦法就是補課，把5名開發人員招集在一起，討論清楚每個人開發的模塊之間的接口，接口不清楚，寫出再好的代碼都是無效的，不要惋惜各個模塊中創意的設計，無法整合在一起，再好的創意都是徒然的。
在這個項目中，做好組織、協調工作，才是項目經理的職責。
題目：防患于未然！ 作者：安安 (北京 lilac_bk@126.com)
這個項目的主要問題很明顯，在開發的初級階段，就鋪下了問題的隱患。而在中級階段時，盡管問題已經很明顯，而且會制約項目的進行，項目經理依然命令繼續開發而沒有采取任何的補救措施，導致最后項目處于失控狀態。
對這個項目而言沒，其實在最初已經可以預見最后的結果。
題目：項目管理技術管理 作者：嚴長洪 (484789 ychych123456@126.com)
問題：計劃，控制，監督，里程碑的檢察和反省自已，工作的安排和整理，工作的可靠性。
題目：很糟糕的事情 作者：daijiangbao (自由職業 daijiangbao@hotmail.com)
作項目經理就不能去做開發，尤其不能深入到開發過程中，技術不能代替管理
沒有必要談失控，連個計劃都沒有，控制的基線都沒有，談什么失控，沒有意義的
題目：管理學基礎知識掌握不牢 作者：桂良民 (江西新余學院 guiliangming1012@yahoo.com.cn)
文字
從以上不難看出，該公司出現了管理問題。上述提到的代碼問題應歸結為該公司沒有統一指揮。沒有統一的指揮就會導致組織混亂。
違反了法約耳14原則中的統一指揮的原則。我對項目管理的具體知識不是很精通，只能用管理學的內容分析，如有錯誤請與本人聯系
對像項目管理這樣高深的理論來講，無用說，對管理學掌握要更牢
這方面的知識可以參考 武漢大學出版社文字管理學 譚力文 有關法約耳14像管理原則。上海復旦大學出版社 周三多 管理學原理與方法 中有關原理與方法部分和計劃部分。
題目：管理學基礎知識掌握不牢 作者：桂良民 (江西新余學院 guiliangming1012@yahoo.com.cn)
文字
從以上不難看出，該公司出現了管理問題。上述提到的代碼問題應歸結為該公司沒有統一指揮。沒有統一的指揮就會導致組織混亂。
違反了法約耳14原則中的統一指揮的原則。我對項目管理的具體知識不是很精通，只能用管理學的內容分析，如有錯誤請與本人聯系
對像項目管理這樣高深的理論來講，無用說，對管理學掌握要更牢
這方面的知識可以參考 武漢大學出版社文字管理學 譚力文 有關法約耳14像管理原則。上海復旦大學出版社 周三多 管理學原理與方法 中有關原理與方法部分和計劃部分。
題目：項目整體管理問題 作者：制造太陽海 (開發部 makesunsea@vip.sina.com.cn)
對于軟件開發項目,項目管理的流程應該結合軟件生命周期進行,并每一步進行嚴格的控制,項目啟動階段應該選擇項目經理,并由項目經理指導作好項目的可行性分析,需求獲取等工作,在計劃階段,應該對需求進行分析,設計,并相應的培訓相應的開發人員,統一項目使用的平臺,開發工具,以及應該遵守的編碼規范,然后再是執行和控制軟件的開發和測試及項目的培訓和上線.整個項目管理的過程應該緊緊結合軟件生命周期進行,并且要求整個團隊都依一種軟件工程的思想,使用相同的平臺,相同的工具和相同生命周期進行項目的開發.
題目：質疑？ 作者：SP (成都信息工程學院 sp-58911985@163.com)
公司為什么讓沒有一點經驗的人當這個項目的項目經理~高層應有一點責任吧~？
題目：Fire the PM 作者：douglas chan (secret douglas_chan@163.com)
只能說那個PM對技術沒經驗，同時沒有對現場問題進行分析、
合理應對的能力。fire him
題目：這能叫項目管理嗎？ 作者：穆海成 (北京亞杰科技發展有限公司 mu_haicheng@263.net)
不管項目經理是以什么身份參與項目的，也不管成員之間的溝通是否到位（當然在這個項目中肯定連最基本的溝通都沒做好）。我覺得此項目中的PM根本就沒把這個開發任務當成一個項目來做，而僅僅是一次技術練兵。以下是我的一些看法，有說的不對的請大家指正，謝謝。
1、項目管理最基礎的就是計劃，這個項目從一開始就沒有一個很詳細的計劃作為指導，從一開始就為以后出現的混亂情況埋下了禍根。
2、項目進入執行階段，總會在適當的時候對項目運作情況進行考核，也就是文中提到的“里程碑”式的整合測試，這個考核是以實際項目運行情況和項目開始時的計劃進行對照的，如果有問題，就一定要馬上進行處理，讓問題自己消失根本不可能。這一點在這個項目中也沒看到。造成最后的失控局面也就不足為奇了。
題目：pm的領導不力和團隊整體的不協調 作者：許劍明 (Briontech xjmshanghai@gmail.com)
首先，PM對自己角色定位不對，很多PM都是從技術人員上去的，往往把自己當作一個programmer，動不動就當救火隊員。在一個團隊工作中，協調者•溝通者•觀測者的角色甚為重要，PM應當側重這些方面，轉換自己的觀念。
第二，SCM環節缺失，Team的團隊開發環境在項目構思前就應該要有統一標準和專人維護。
第三，開發計劃失利，在團隊開發中，PM應該對先期的規劃和安排有所澄清，讓每個成員了解項目思路，統一認識。這樣才不會等到中級階段才發現脫節問題。
第四，PM應變能力不強，當發現中期有問題時，適當的要有所調整，很多項目由于是Time—driven，很多PM顧頭不顧尾，決策欠妥，往往是雪上加霜。
其他的也不寫了，我想項目做成這樣，整個團隊都是有責任的，不光是PM的領導不力，成員中的協作和上下級溝通肯定有脫節。
題目：項目經理的工作 作者：sangsang (新聞傳媒 zhs@btc.sh.cn)
我認為主要還是項目經理的管理能力存在問題,在項目實施初期,項目經理應該很明確的做幾點說明:
1.軟件開發的工具,或者說應該是軟件開發的平臺是什么,應該統一.
2.項目里程碑,讓每一位team member 知道項目的實施計劃.
另外該經理的失誤在于當第一次里程碑整合時已經發生風險時,他沒有做及時的規避,沒有采用溝通的方式,及時控制TM的行動方向.
題目：管理問題 作者：韋少才 (桂林空軍學院7053 we26@163.com)
我覺得，經理的技術能力值得懷疑。在不同服務器上的計算機程序運行時本來就不大相同。在中期測試時已經出現端倪了，卻還要進行開發，也不要求修改程序代碼，讓程序在不同的服務器上無法兼容。這本來就是一般的常識嘛！
雖然這么說，但是下面的開發人員，卻也跟著做。在項目的整體結果就可想而知了。
題目：軟件開發項目的失控 作者：nbwzy (kd nbwzy@163.com)
項目管理出了問題：
１、該項目經理可以說根本就沒有什么項目管理的經驗或者是完全按照自己的經驗在做事情。而且中期檢查時發現了問題，卻不知道其嚴重性，試問該項目經理該承擔什么樣的責任？
２、這不是一個好的開發團隊。應該說為什么連隊友是在什么環境下開發都不知道，那還叫團隊嗎？
３、項目沒有一個尺度把握，更沒有一個周期控制。
４、公司的管理制度存在很大問題：沒有相關的制度對項目進行監控
５、各部門協調有問題：一個項目９０%以上來自銷售部，等到項目出了這么大問題銷售還不知道項目情況，那就有問題了！
總結：該開發團隊如不在項目管理上加大學習力度，那該團隊只能接手一些小型項目（各做各的），稍微大點的項目就會出問題，而且該公司也很快就會被淘汰。
題目：軟件開發項目的失控 作者：林 (成都西南交大 linsizhu2006@173.com)
開始時沒把網絡服務器交代好，前期缺乏溝通
題目：對項目管理沒有概念的必然結果 作者：安乃紅 (AMDOCS-LONGSHINE yulongan007@gmail.com)
案例中的項目經理對項目管理沒有概念導致現在的局面。現在要重新對項目管理進行認識和補救。在總結這一段時間的經驗教訓后，制定相應的項目管理計劃和制度。分析合并兩種代碼的代價，選擇代價和運行成本性價比較好的方案。但是學習項目管理和軟件開發的相關知識是基礎。
題目：項目規劃 作者：coolgh (dfasdf gongchp@163.com)
項目開始的時候，項目經理沒有做好規劃，不能把控全局。
題目：技術問題 作者：何暉 (大眾科技 hehuii@sina.com)
我認為還是項目經理的技術能力不足，另外也不應該充當開發人員
某通信公司的交換擴容項目案例分析
2006-7-5
--------------------------------------------------------------------------------
項目背景：根據200X年以前的工作情況，基站網點的分布和容量，社會對移動電話的需求，省公司制定了200X年的總體業務增長計劃，分配到我公司的建設任務工程。
可行性分析：根據省公司要求，對公司現階段的工程建設進行了調研，認為工程在適量的投資下是可以進行的，包括新建、擴容，總體能夠達到省公司要求。
實施過程：
1.公司傳達上級公司的要求，工程管理中心按要求進行項目建設規劃。
2.將規劃上報領導進行審批，上報省公司進行審批3.省公司對建設規劃的工程量進行了擴大，認為部分建設內容對以后的擴容要留有更大的空間，對投資資金計劃進行了壓縮。
4.根據審批后的建設規劃工程管理中心對項目進行分解，制定項目計劃，包括資金的投放計劃和額度、建設進度計劃、質量驗收標準、建設范圍、風險規方案等等，進行任務分配；工程建設部負責設備采購、工程建設；工程管理中心負責項目進度監管和驗收；財務部門進行資金配合；人力資源部進行人力調配；網絡部、后勤部等部門進行協助；5.在分配任務時，工程建設部認為公司投資額度不足，工作量大，按現有人手和設備難以完成認為，要求增加人手和工具設備的投入。工作只能跟著感覺走，沒錢再說。
6.人事部認為工程建設部門的人手不夠可以配合，但是公司員工編制有限，只能在社會聘請，費用由工程建設部門從工程費用中支付。工程建設部理解公司人事制度，勉強同意，但要工程管理中心協調省公司。
7. 8月份，財務報告，工程建設資金告緊，工程管理中心提交資金追加申請。
8. 9月份省公司同意追加資金，工程繼續。
9. 10月份大量工程進入驗收階段，工程中心疲于奔命，發現不少工程有質量問題，限定工程建設部門改進。
10. 12月份工程基本都按進度完工，進行驗收，工程質量還是有不少問題，但是為了按時完成省公司的工程計劃，否則獎金沒有，小問題放過，不大不小的問題口頭責令整改，大問題瞞上不瞞下，責令承建商繼續整改。
11. 每月上交進度報告，召開業務協調會議，有需要時召開臨時會議。
根據案例分析以下問題：
1. 對當前問題描述
2.對組織結構建議
3.對溝通管理的建議
4.對成本管理的建議
5.對進度管理的建議
6.其他建議
分析： 電信運營商的基礎網絡設施之項目管理 作者：howard_hong (普華 howard_hong2001@yahoo.com)
1.對當前問題描述
A:中國式項目管理的情形是：項目目標終就會實現，只是在過程中大家辛苦成都有所不同；深究其原因所在，計劃的龍頭指揮作用沒有得到很好的貫徹，大多數電信運營商在過程中對于最終的目標能否實現沒有提前預見能力，因為他們對于項目的控制依賴于統計，類似CHECKLIST，失去基線，也就失去問題可預見性；跟著感覺走、經驗主義，累是必然的。
2.對組織結構建議
A:電信運營商網絡基礎設施項目的管理組織架構屬于職能型，誰都不直接對項目結果負責，經常出現問題了，找不著可以挨板子的人。工程管理部和工程管理中心職責不清。
3.對溝通管理的建議
A: 工程管理部和工程管理中心應該充分借用監理的力量，讓自己處于內部協調、外部支持、監督執行，階段評審的角色。運營商自己管得越多，也不見得是好事，有些事情自己并不擅長。
4.對成本管理的建議
A:電信運營商由于項目個數眾多，并不是每個項目都進行招標，選擇承包商基本都是從年度資格入圍的承包商中進行選擇，大家都有飯吃，所以給個項目沒有合同標的；其次，承包商、供應商的費用基本是按實際工程量進行結算的方式。所以成本管理是一個空架子，項目群的預算總額并沒有分解到具體的一個個項目上，實際成本超支是必然的，除非你人為放大了預算總額。
5.對進度管理的建議
A:建議多設置項目群階段評審、階段驗收的里程碑；在項目群的收尾階段集中評審，只能使市移動公司對驗收刷漿糊；
6.其他建議
國外電信運營商基礎網絡設施項目群普遍采用TURN KEY的項目運作方式，將風險轉嫁給實施商，運營商自己在項目中只承擔監督、協調和支持，費用不會超，人員也少，管理也輕松，何樂而不為？ 管理體制問題：什么事情總想自己管，累是必然的，可能還不討好。
分析2：
題目：一個非常成功的項目 作者：王勇 (遠達網絡 fwang@uninetsystems.com)
通信公司案例，尤其是甲方提交的案例，真的是難得一見！絕對的精華貼！
總體而言，我認為這是一個成功的項目管理案例。
首先，項目參與各方滿意，目標完成了。
1.省公司的工程計劃按時完成了。
2.工程項目部門的獎金保證了，工程質量問題在有效的范圍內得到了控制。
3.承建商拿到了項目，完成了項目，盡管會有遺留問題要處理。
其次，工程溝通順利。
1.審批階段各部門協調不錯，遇到問題了，沒有糾纏，而是找到可行的解決，或者留待后期處理。例如工程部門處理投資不夠問題， 人事部門處理人手不夠問題。遇到了問題，不是消極等待，而是提出積極有效的建議。綠燈行，黃燈跑3，遇到紅燈繞著行。
2.財務處理有效。在8月份工程費用不夠的問題出現了，2個月內就解決。
3.定期的業務協調會議，臨時會議。
4.團隊合作。盡管樓主沒有特意的談到團隊合作的問題。但是從文中可以發現，該通信公司團隊合作比較順暢，而且各個職能部門配合較好，沒有推諉和拖拉的現象。
最后，質量控制
1.工程中心發現問題，工程建設部們整改問題。
綜上所述，樓主的案例是一個比較成功的案例。樓主所在的公司也是管理比較成功的公司。當然，工程項目中會遇到各種各樣的問題，不可能完全避免。 如果樓主所在的公司管理水平還要提高的話，估計就要從戰略層面考慮了，如何節約成本，提高效率。例如建設ERP系統，建設PM 信息系統。
BTW:說了這么多好話，最后說一些反話。 俗話說，有錢好辦事。現在通信運營商大都是有錢的主。而且工程建設，工程項目內容比較單一，工作知識和經驗轉移比較容易，不成功就怪了。