本期話題:項目處于整改階段，臨近驗收節點上如何交付不延期?

一、背景介紹

受診人職位： 交付項目經理(救火項目)

公司：從事于政府機關單位業務系統開發的公司，以事業部劃分業務，我處于負責政府業務的事業部。事業部架構由項目管理、開發、實施等崗位組成。

情況：由于公司近期轉型：項目由一個很熟悉業務的機構部門，轉至了一個陌生業務的機構部門。由于前期調研不清楚，開發出的業務系統，在試運行期間出現了大量的返工。

前項目經理，主要開發骨干都已離職，雖然補上了新人，在我接手之后發現項目進度依然落后太多。由此，我向事業部高層申請了 傾斜一些開發資源對項目進行攻堅，但質量問題依然頻繁的出現。

問題：在臨近交付時間的節骨眼上，項目依然處在攻堅上。目前事業部高層對此事很關注，用戶又非常較真的情況下(不想做延期)。

我個人的意見是：先向用戶提出驗收申請，后面繼續整改。

但在流程上肯定會被用戶打回來先整改，項目也會延期。

在這種形式，請問怎么更好的破局?

二、嘉賓分享

01

一、問題的分析和解決：

從案例反饋的信息來看，提到幾個點是需要請各位關注的，抽取出來，后面的總結，我也會提出自己的疑問和思考，供大家參考。

1、“項目轉到陌生業務部門”——是否可以理解部門對該項目業務陌生，目前狀況如何，如果依然對項目的業務陌生，那問題就有點過分了。

2、“試運行期間出現大量返工”——已經到試運行階段了，從字面來看，猜測是業務流程契合度不夠造成，返工是否找到符合業務邏輯的路徑。

3、“質量問題依然頻繁出現”——這里我的疑問，這個質量，是業務滿足用戶需求，只是功能性bug還是說業務流程不符合造成的質量問題。

解決方案：

“面對的是政府機關單位的業務系統，臨近驗收時間”，軟件產品的交付，一定都是有個磨合的過程，先把自己建議的關鍵路徑開門見山，然后提出一些認為需要大家反思的點。

(一)關鍵路徑：

1、這個事情比較好的一面是，其實已經前面已經有人試錯了;關鍵的業務流一定要重點保障，如果這個到現在都還沒有明確，那這個事情基本上就沒法玩了。

2、內部一定是要多次組織需求和業務流程的討論會，召集真正懂業務，了解用戶一手需求的相關干系人，多次討論，并且把階段性結論與用戶多碰幾次。

3、政府單位，現在要著急驗收，其實要考慮他的痛點，到年底了，他們報的預算想辦法都要把錢花出去，業務系統一定要能用起來，不然過不了審計考核。

所以我是贊同受診人的意見，肯定是要驗收，不過這個驗收不是一廂情愿，一定是要跟用戶交底的，首先核心業務一定能保障，然后在驗收前，詳細的跟用戶交底能做到什么程度，在這個問題上與用戶需要達成一致。

用戶核心訴求滿足之后，用戶較真歸較真，這個時候需要打配合的，市場人員和交付都要配合著來，有必要高層也出面，該搞關系要搞搞關系。

4、快到驗收節點了，其實能做到什么程度，已經是能心里有數的，一方面能做到什么程度，另一方面，剩下的一定是不影響主業務流程的功能模塊，然后有明確的計劃安排，給到用戶承諾，一般以備忘錄或者承諾函的形式讓用戶放心敢給你簽字。

確定明確目標，方向沒問題了，剩下就是投入了，這個就是每天確定任務，996是福報，該加班加班了。

5、確定明確目標，方向沒問題了，剩下就是投入了，這個就是每天確定任務，996是福報，該加班加班了。

二、需要反思的點：

1、首先最重要需要反思或者搞清楚的是，“前項目經理，主要開發骨干都已離職”!!!

這個是非常反常的事情，大家都是霧里看花，摸清楚這個深層次的原因，前期調研不清楚是一方面，不熟悉業務是一方面，衍生的，用戶的需求變更是否頻繁發生，為什么會出現重要組成成員都離職，這個是需要找找冰山下的東西。

2、這個攻堅，傾斜開發資源，我個人覺得這些都是在明確了目標之后做的事情。

整體來看，這個軟件項目做到現在的狀況，癥結是不了解業務造成的，把握業務需求，在標準化的業務流程基礎上，可以做一些個性化定制，理論的東西就不在這里老生常談了。

三、最后總結下：

1、一般這種救火項目，短時間要說做多大扭轉其實很難，之前做的那些工作推翻重來不太現實，我們重點還是以核心業務出發，抓住這個之后再去修剪其他枝節。

2、接到救火任務那沒辦法，就是要往上頂了，回過頭來想，正常帶的項目過程。

印象里有這么一個說法，提給大家共勉：好的項目經理不是說多么擅長收拾爛攤子的項目，而是會規避風險不讓自己的項目陷入爛攤子的境地。

02

個人介紹：

房愛德，10年以上信息系統集成項目領域從業經驗。主要從事城市公用事業領域的信息化建設，主要包括水氣熱公司的綜合抄表、收費、客服呼叫、安檢等方面的信息化建設。先后擔任過十一五期間發改委發起的全國能源監控項目項目經理、北京 濟南等大型水司燃氣公司的信息化項目的項目經理等職務。

項目問題診斷：

問題一：“由于前期調研不清楚，再加上更換了承建機構部門，導致需求與客戶真正需求差距較大。”這說明項目的“需求管理”存在問題。

問題二：“前項目經理及技術骨干離職，造成返工。”這說明項目的“資源管理”存在問題。

問題三：“在臨近交付時間的節骨眼上，項目依然處在攻堅上”這說明項目的“進度管理”存在問題。

問題四：“先向用戶提出驗收申請，后面繼續整改。”這是PMP^®標準管理中不推薦但一般行業內比較常用的策略。且不說結果是否按題目中項目經理所料，這種方式的處理一定要做好“風險管理”。

項目問題剖析和解決方案：

1、“由于前期調研不清楚，再加上更換了承建機構部門，導致需求與客戶真正需求差距較大。”這是導致返工及項目延期的根本原因之一。

項目的“需求管理”過程包括需求收集、定義范圍、創建wbs(需求分解)、需求確認、需求控制。

在項目前期，要重視需求管理，并做好項目文件的及時整理、細化，和確認。在需求原型、項目文件充足、客戶及時確認需求的情況下，即使出現更換建機構部門也不至于出現因需求問題而出現返工的問題。

2、“資源管理”最重要一塊是團隊的建設，前項目經理及骨干的離職也更一步加劇了項目返工和延期問題的出現。項目經理要運作項目管理技巧，建設團隊，處理沖突，建設一個穩定高效的團隊是項目成功的基礎。

3、“進度管理”在貫穿項目各階段，字義好項目活動，評估出優先級，列好關鍵路徑，始終監控項目進度是否符合計劃。而不是在臨近交付結點時才想到要重點監控。

4、“先向用戶提出驗收申請，后面繼續整改。”這種方式不推薦，若一定要采取這種方式則要做好“風險管理”。評估出這樣的各種風險情況，包括項目范圍，后期成本，預防成本超支造成的項目失敗。

最后的話：

1. 項目管理最關鍵不是在于問題出現后的解決，而是預防。預防問題出現遠遠重要于出現問題后的解決。

2. 重視項目范圍管理，特別是需求的明確與確認。還要重視項目的文件的重要性，它會是溝通管理的重要支撐。

03

/ 我有話說 /

?佚名氏?-上海-IT：

“整理清楚有哪些要整改的東西，是已經全部整理出來了但是來不及整改，還是說還在不停的冒出未知的問題來? 對于已經出現的問題，羅列優先級，哪些必須什么時候改完，哪些可以拖到驗收中再整改(驗收也需要過程)，什么樣的整改需要投入什么樣的人。 根據整改的狀況，需要加班的加班，實時監控進站。 需要公司高層向政府部門展開公關，看是不是可以延期，或者分批次驗收。”

小明童鞋-長沙-集成：

”項目的核心問題應該是業務需求不清晰導致的返工，造成的工期延誤。項目的進度管理沒有做好，那么解決的辦法只有兩種可能。與客戶協商，小批量交付或者內部解決，趕工和追加資源，既然公司領導重視，那么從內部的解決來說可能力度更大一些。另外還的看看當初和客戶協商的交付方式，幾個方面結合起來看怎么解決。“

MISS丁 杭州 軟件：

”破局處理： 1.了解此項目成敗對公司的影響有多大?會不會影響其他項目的進展?客戶對此項目的成敗持什么態度? 2.進度延遲的根本原因是什么 有沒有解決方案? 3.方案實施后?能否解決?方案實施的難度有多大? 4.如果方案能解決且客戶對項目成功很重視，與客戶溝通列出整改里程碑計劃及整改后的成果優勢。 5.預估可能的成本增加。“

李潔蘭-廣州-軟件：

”1、梳理交付設計的確認版本需求文檔，檢查整體業務流、功能模塊。 2、對比當前項目成果，全部開發完成沒有?哪些是不符合驗收標準的?哪些是變更的? 3、跟接口人確認驗收標準、協商計劃。 4、先按初始版本驗收、上線，變更部分再協商為優化版本。”

“對外：協商。 對內：協調資源，掃坑。“

Fiona-福州-軟件：

”我覺得， 可以先交付已經可以交付的小的模塊 ，暫時還不能交付、 還在整改的東西 ，羅列出來 。跟客戶講明白為什么還在整改 ，是因為客戶需求變更 還是其他原因 ，并且要說明大概需要多久整改 ，什么時候可以提交給客戶。“

”重新梳理需求，然后確認優先級， 與客戶經常溝通進度 ，已經做完部分成品就可以先演示給客戶看，然后再加加班，趕進度。“

木凡-沈陽-醫療IT：

”完成的模塊簽字驗收，未完成的部分通過備忘錄的方式進行驗收，并與客戶確認修改方式，明確可實現的開發交付計劃。”

小糊涂仙-重慶-物聯網

“趕工、增加資源、提升質量避免返工、外包，培訓或引入高技能項目成員，無非這幾種方法。”

Bysing-廣東-珠寶：

“向領導匯報當前進度，重新做好進度規劃，把控時間點，可交付哪些，延后交付哪些，內部協調好后再找項目接口人協商，提出自己的建議想法。”

精髓總結：

1、與客戶溝通協商，明確客戶態度，再確認需求優先級，找準病根，重點攻堅。

2、好的項目經理不是說多么擅長收拾爛攤子的項目，而是會規避風險不讓自己的項目陷入爛攤子的境地。

三、討論內容整理

[以上關于項目團隊管理的內容都來自于希賽「PM創造營」群內話題討論，由?@小M妹妹? 妹妹整理，由以下小伙伴分享完成@浙江-小王-汽配PM@啊潮-廣州-互聯網@涼風有信-廣州-ERP@踏風而至-北京-通信@王金陽?杭州?IT@星子-廣州-智能建筑-軌道交通@Fiona-福州-軟件@Zen.Wu-政務教育高校@MISS丁 杭州 軟件@追星騎士-深圳-金融IT@?佚名氏?-上海-IT@簡單-西安-軟件@熊貓-拉薩-系統集成@huang—上海—通信@小明童鞋-長沙-集成@?云淡風清?-大連-電控@Soda-寧波-汽車@小唐-鄭州-軟件@kawasaky-哈爾濱-金融@阿敏敏-武漢-互聯網產品@李潔蘭-廣州-軟件@涼風有信-廣州-ERP@浩-深圳南山-金融行業@阿德-淄博-城市公用@Bysing-廣東-珠寶@黑科技-貴陽-IT@天天-北京-鐵路自動化@閃光創世-上海-IT@木凡-沈陽-醫療IT@D-深圳-OTA@Roy-濟南-智慧停車@牧云-成都-互聯網產品@山東-軟件-李工@建慶-深圳-智慧城市-GIS@Kerwin-成都-政務@阿正-北京-物聯網@彭祥-上海-供應鏈SCM]