學者齋2022年專案管理失敗的案例分析
- 專案管理
- 關注：1.69W次
都說專案經理的時間分配應該是3-7法則，即30%時間用於管理，70%時間用於溝通，可見溝通的重要性。下面，小編為大家分享專案管理失敗的案例分析，希望能幫助到大家!
溝通管理案例
某系統整合商B負責某大學城A的3個校園網的建設，是某弱電總承包商的分包商。田某是系統整合商B的高階專案經理，對三個校園網的建設負總責。關某、夏某和宋某是系統整合商B的專案經理，各負責其中的一個校園網建設專案。專案建設方聘請了監理公司對專案進行監理。
系統整合商B承攬的大學城A校園網建設專案，計劃從2002年5月8日啟動，至2004年8月1日完工。期間因專案建設方的資金問題，整個大學城的建設延後5個月，其校園網專案的完工日期也順延到2005年1月1日，期間田某因故離職，其工作由系統整合商B的另一位高階專案經理鮑某接替。
鮑某第一次拜訪客戶時，客戶對專案狀況非常不滿。和鮑某一起拜訪客戶的有系統整合商B的主管副總、銷售部總監、銷售經理和關某、夏某和宋某3個專案經理。客戶的意見如下：
你們負責的校園網專案進度一再滯後，你們不停地保證，又不停地延誤。
你們在實施自己的專案過程中，不能與其他承包商配合，影響了他們的進度。
你們在專案現場，不遵守現場的管理規定，造成了現場的混亂。
你們的技術人員水平太差，對我方的詢問，總不能提供及時的答覆。
聽到客戶的意見，鮑某很生氣，而關某、夏某和宋某也向鮑某反映專案現場的確很亂，他們已完成的工作經常被其他承包商攪亂，但責任不在他們。至於客戶的其他指控，關某、夏某和宋某則顯得無辜，他們管理的專案不至於那麼糟糕，他們專案的進展和成績客戶一概不知，而問題卻被擴大甚至扭曲。
問題1
請簡要敘述發生上述情況的可能原因有哪些?
問題2
針對監理的作用，承建方如何與監理協同?
問題3
簡要指出如何制定有多個承包商參與的專案的溝通管理計劃?
案例分析
問題1
田某是系統整合商B的高階專案經理，但後來離職，由鮑某接替。而鮑某接任高階專案經理時，似乎對整個專案一無所知，這至少說明系統整合商B的內部管理有問題，對整個專案監管缺位或不得力，沒有及時把專案經驗累積為組織資產。
“期間因專案建設方的資金問題，整個大學城的建設延後5個月”，這說明客戶自己本身的原因，導致專案發生延遲以後的混亂狀況。
“至於客戶的其他指控，關某、夏某和宋某則顯得無辜，他們管理的專案不至於那麼糟糕，他們專案的進展和成績客戶一概不知，而問題卻被擴大甚至扭曲”，這則說明，系統整合商B沒有或極少與客戶進行直接溝通，導致客戶對自己的工作不熟悉。
客戶從總承包商或其他承包商那裡獲得的資訊有失真。從試題描述來看，顯然，總承包商報告渲染了問題，推卸了責任。
“聽到客戶的意見，鮑某很生氣，而關某、夏某和宋某也向鮑某反映專案現場的確很亂，他們已完成的工作經常被其他承包商攪亂，但責任不在他們”，這說明系統整合商B沒建立現場管理制度，或者現場管理制度不嚴密不明確，或現場管理制度執行不力。
而且，總承包商與分包商(系統整合商B)責任不是十分清楚。
最後，因為在這個專案中，還有第三方(監理方)的參與，監理方是代表建設方對整個專案進行監控的，但在監控之下，專案仍然發生混亂，這說明專案的監理工作沒有到位。
問題2
這是一個理論性問題，與試題的案例描述沒有關係。
監理作為獨立的第三方，需要公平、公正、公立地處理專案建設過程中所出現的問題，維護各方利益。監理方與承建方是沒有合同關係的，監理方與建設方簽訂監理合同，按照監理合同的要求來對承建方的建設工作進行監控，其監控的依據之一就是承建方和建設方所簽訂的建設合同，其目的就是要確保專案按期完成，並達到建設合同的要求。
因此，承建方要正確認識監理方的作用，要認識到承建方和監理方不是對立關係，而是有著共同的目標，就是完成專案目標。
在專案管理方法上，採取的是“三方一法”，即建設方、承建方、監理方都採用專案管理方法來對專案進行管理，監理的主要內容是“四控三管一協調”，承建方也需要在這些方面進行配合，接受監理的監督和協調，有關中間成果需要通過監理的稽核或評審。
另外，承建方要積極主動地與監理方搞好關係，進行週期性的溝通，確保專案“溝通無障礙”。
問題3
這也是一個理論性試題，與試題描述的案例背景的關係不大，考查的內容是專案溝通管理計劃的制定。有關這方面的內容，在第12章中有詳細的介紹，在此不再重複。
解答要點
問題1
(1)系統整合商B內部管理有問題，至少監管缺位或不得力。
(2)系統整合商B沒有或極少與客戶進行直接溝通。
(3)沒建立現場管理制度，或者現場管理制度不嚴密不明確，或現場管理制度執行不力。
(4)總承包商與分包商責任不是十分清楚。專案經理圈子
(5)客戶從總承包商或其他承包商那裡獲得的資訊有失真。總承包商報告渲染了問題，推卸了責任。
(6)客戶自己本身的原因。
(7)監理工作做得不好。
問題2
(1)承建方要正確認識監理的作用，他們和監理方不是對立關係，而是有共同的目標，就是把專案做好。
(2)雙方都採用專案管理的方法，承建方協助和配合監理方對專案的“四控三管一協調”，接受監理方的協調和監督，中間成果需要通過監理方的評審。
(3)承建方和與監理方要進行週期性的溝通。
問題3
(1)調研各整合商的溝通需求，進行專案干係人分析。
(2)發揮總承包商牽頭作用和監理方的協調作用。
(3)對共用資源的可用性進行分析，引入資源日曆。
(4)解決衝突，包括干係人對專案期望之間的衝突、資源衝突等。
(5)建立健全專案管理制度並監管其執行。
(6)採用專案管理資訊系統。
一個失敗的專案管理案例分享
1、背景介紹
從 2020 年三月底開始做一個設計管理平臺的專案，我被指派為這個專案的專案經理，專案成員包括產品經理（1）、後端（4）、前端（2）、UED（1）、UI（1），共 10 位成員。從專案正式啟動，到七月初，第一個被需求方、發起人都認可的 V1.0 版本原型才確定。在這接近四個月的過程中，幾乎專案管理的全部坑都踩了個遍，特別是干係人管理、衝突管理以及變更管理與專案管理的基本要求幾乎完成全部背離。這個專案為何會走到這個幾乎失控的地步呢？
2、原因分析下面全面來進行一下問題的分析，可以從專案籌備階段開始
1、 專案定位不清晰（干係人管理）
關於這個專案的定位，業務方領導與技術方領導有完全不同的定位，技術領導認為應該要設計管理平臺，而業務方領導明確表示我們需要的設計協同平臺，雙方經過幾次交流，但是始終未能夠對產品的定位達成一致。產品經理找需求方確認過的需求，技術領導不認可，不僅技術領導不認可，甚至業務領導也不認可。
此處專案經理有較大責任，需求的確認完全交由產品經理處理，但是在專案的進行過程中，明確發現產品經理確認的需求、設計的原型得不到技術領導與業務方的雙方的認可，此時應該組織需求討論會議，讓相關的干係人（技術領導、業務領導）需同時參加，明確 alpha 版本的需求。而不是隻埋頭在進度控制中，需求沒有得到核心干係人一致認可的時候，做的越多，偏離越遠。
2、 責任許可權不清晰
專案中有產品經理、專案經理，在專案啟動階段並沒有明確說明產品經理與專案經理的職責與許可權。產品經理管理需求，但是未對干係人進行有效管理，專案經理此時要不要去強力干預對干係人進行管理 ？
專案經理是作為整個專案的負責人，但是常常被定義在技術負責人的位置，管理技術選型，開發進度控制，沒有對整體專案的成敗負責，常常對著兩位老總不同的產品定位嘆氣，但是沒有采取有效的措施來解決這種問題。
3、迭代內容週期控制（專案進度計劃管理）
專案節點是在 6.30 號釋出第一版，實際開發時間有兩個月，產品一邊出原型，開發同時同步進行開發。按照約定的第一個原型版本，是有足夠的時間進行開發的。這時對接的業務方要求增加四個審批流程，並且這四個流程可以迴圈往復交替進行。當時接到產品經理的這個需求時，我第一反應是拒絕的。這個地方描述增加一下產品經理背景描述，產品經理有深厚的行業背景，產品開發經驗稍有不足。 我跟產品進行溝通，詢問是否可以放到下個迭代，得到的回覆是可以，但是沒有這個流程，使用者是無法使用這個產品的。我考慮到有當時還有較為充沛的'時間，同時這個需求設計到核心的功能，決定在這個開發週期內將這個新增的流程功能開發完成。最終完成了任務流程功能的開發，但是由於業務邏輯較為複雜，一方面產品並未完全梳理清晰全部業務邏輯，另一方面，此功能為經過充分測試，在一次產品演示的時候，技術領導表示該流程互動太複雜，業務領導表示這這個任務流程完全不是他想要的。
這裡的問題是在需求原型確定的情況下，專案經理應該縮短每個迭代的任務週期，最多不超過三週。一個迭代版本的時間近兩個月的時間，最後核心干係人告訴你這不是他想要的。應該在每完成一次迭代的時候，舉行迭代回顧會議，演示產品，讓核心干係人對階段成果進行演示。必須完成第一個迭代的驗收，才能進行下一個階段的開發工作。 如若不然，還不學學新技術實在。
4、變更控制嚴重缺乏（變更管理）
由於檔案版本管理做為其他應用獲取模型資訊的一個統一入口，技術領導對專案比較關心，時常要求產品演示，同時針對產品提出許多改進意見，態度較為強勢，產品經理與我扛不住壓力，頻繁變更。由於這個變更，業務方是不知情的，所以變更後的產品同時又得不到業務方的認可，這樣最後就導致了一個干係人不認可、目標使用者不接受的產品的產生。
專案經理在這件事情上負有主要責任，作為一個專案經理，一定需要嚴格的管控變更。如果要進行變更，必須核心干係人同意，技術領導的優化意見必須要業務領導認可，才能執行變更。並且變更是不在當前迭代週期內進行的，把變更作為需求記錄起來，在下個迭代內進行討論開發。
3、解決方案這種情況在 PMO 的強力介入後，得到了極大的改善，推了一個核心干係人都滿意的 v1.0 版本原型，那麼是怎麼做到的呢 ？
1、強力的干係人管理。 每次進行需求確認時，確保全部干係人認可。具體流程是先與業務對接人進行需求討論，然後與需求領導進行需求原型評審確認（需求確認時最好技術領導在場），最後與技術領導進行原型評審確認。若有異議，組織與業務領導的討論，直到雙方都同意該原型為止，最終確定原型為 1.0 版本。不管領導多麼強勢，一定要堅持自己的立場，守住自己的原則，不跟著領導天馬行空，只做跟需求方確認過的需求，其他一切需求都要經過討論後再進行設計開發。
2、嚴格的範圍控制。確定一個最小 mvp 進行迭代，迭代週期改為 2~3 周，這兩到三週內任何變更都不做，只記錄變更點，在下一個迭代啟動時，再進行變更的討論。
3、強力推動專案。對於設計管理與設計協同的爭議，先不去管他。將爭議擱置，先看需求方當前最需要什麼東西，我們先在最小範圍內，用最簡單的方式滿足其需求。擱置爭議，推動專案。
4、總結這個專案遇到的問題都是專案管理中較為常見的問題。 PMO 介入後，用這一套組合拳，雖然非常簡單，甚至是許多方法有點老生常談，但是很有效。專案的新原型，業務方與技術方領導都較為滿意。其實許多專案的點，我們開始也有做，但是沒有強有力的去執行，遇到強勢的領導以及需求方就妥協了。這種妥協的結果只能是一個妥協的產品，在可用性、穩健性上都無法得到保證。
專案經理一定要有對整個專案負責的準備，不要只把自己定義在進度管理的小慈祥的微笑裡。此外就是專案經理必須做好乾系人管理，同時在遇到外界壓力時，必須堅持自己的原則，此時的一分妥協，後期需要十分的加班去填坑。
- 文章版權屬於文章作者所有，轉載請註明 https://xuezhezhai.com/zh-tw/qygl/xiangmu/zm3d26.html
