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