說明：項目管理案例系列由項目管理者聯(lián)盟[PMU]制作推出，版權所有。該系列以PMU會員實際項目案例為藍本，結合項目管理專家點評和PMU會員分析，真實、深入、可鑒。

（一）案例正文

某系統(tǒng)集成公司現(xiàn)有員工50多人，業(yè)務部門分為銷售部、軟件開發(fā)部、系統(tǒng)網(wǎng)絡部等。經(jīng)過近半年的醞釀后，在今年一月份，公司的銷售部直接與某銀行簽訂了一個銀行前置機的軟件系統(tǒng)的項目。合同規(guī)定，6月28日之前系統(tǒng)必須投入試運行。在合同簽訂后，銷售部將此合同移交給了軟件開發(fā)部，進行項目的實施。項目經(jīng)理小丁做過5年的系統(tǒng)分析和設計工作，但這是他第一次擔任項目經(jīng)理。小丁兼任系統(tǒng)分析工作，此外項目還有2名有1年工作經(jīng)驗的程序員，1名測試人員，2名負責組網(wǎng)和布線的系統(tǒng)工程師。項目組成的成員均全程參加項目。在承擔項目之后，小丁組織大家制定了項目的WBS，并依照以外的經(jīng)歷制訂了本項目的進度計劃，簡單描述如下：

1、應用子系統(tǒng)
1）1月5日～2月5日需求分析
2）2月6日～3月26日系統(tǒng)設計和軟件設計
3）3月27日～5月10日編碼
4）5月11日～5月30日系統(tǒng)內(nèi)部測試

2、綜合布線：2月20日～4月20日完成調(diào)研和布線

3、網(wǎng)絡子系統(tǒng)：4月21日～5月21日設備安裝、聯(lián)調(diào)

4、系統(tǒng)內(nèi)部調(diào)試、驗收
1）6月1日～6月20日試運行
2）6月28日系統(tǒng)驗收

春節(jié)后，在2月17日小丁發(fā)現(xiàn)系統(tǒng)設計剛剛開始，由此推測3月26日很可能完不成系統(tǒng)設計。請問問題發(fā)生的可能原因，小丁應該如何保證項目整體進度不拖延？

（二）專家點評

王樹文 畢業(yè)于中南大學，獲碩士學位，現(xiàn)就職于廣州華南資訊科技有限公司（上市公司），從事過多個大型項目的開發(fā)和管理工作，目前任廣州華南資訊科技有限公司軟件質(zhì)量保障總監(jiān)，兼任公司SEPG執(zhí)行主席和軟件測試部經(jīng)理。

王樹文點評：

問題一：我分析主要有如下兩方面的可能原因：
1、 小丁在進行項目進度計劃安排時，可能沒有考慮春節(jié)法定假日的情況，在工作安排上存在嚴重不合理；
2、 小丁對項目的監(jiān)控力度不夠，如果真有進度延誤的問題，那么這個問題應該在春節(jié)放假前（或更早）被發(fā)現(xiàn)。

問題二：小丁可以采用如下的措施來保證項目整體進度不被拖延：
1、 在編碼階段和測試階段適當增加資源或安排適當加班，將這兩個階段的工期適當縮短些（建議最好不要通過增加設計人員的辦法來縮短設計工期）；
2、 將試運行時間往后挪一點（因為從目前的計劃來看，試運行的截止時間和系統(tǒng)驗收時間中間有一周的可“活動”時間），因此可以在這方面也做一點文章。

（三）案例分析

分析1：初看后得3點感言 作者：梁楨

首先，因為小丁第一次做項目經(jīng)理，而且兼任系統(tǒng)分析工作，所以在完成自身工作同時便有了自身工作已經(jīng)完成，剩下就是系統(tǒng)設計人員的工作，難免事不關己高高掛起的感覺，這是項目成員升為項目經(jīng)理后常會發(fā)生的慣性做法，此為其一。

其次，從時間上來看，2月正好是春節(jié)時間，在春節(jié)前往往沒有嚴格的管理都會出現(xiàn)工作松懈的情況，再加上春節(jié)放假7天，工作勢必會拖延，這是在做WBS時沒有考慮到的問題，其為二。
最后，做為項目經(jīng)理對項目負責，需要全程監(jiān)督和控制項目，對于新升任項目經(jīng)理必須對于風險、成本、質(zhì)量、溝通有全面的準備。

從筆者的文字來看工作被拖延了2周（10個工作日）左右，所以需要加大工作強度，同時必須嚴格把關系統(tǒng)設計的質(zhì)量，時間緊迫的代價往往時質(zhì)量的下降。文字結束前希望日后能看到筆者對于已經(jīng)完成的項目的分析和采取的措施和最終結果。

分析2：不見得正確 作者：lxj

1.項目計劃不切合實際，如：對困難估計不足
2.項目計劃太粗，存在較大水分
3.各階段目標及具體工作不明確，時間浪費
4.團隊建設環(huán)節(jié)薄弱，工作效率不高，協(xié)作精神差
解決的方法
1.明確目標，爭得團隊認同
2.調(diào)整、細化各階段計劃
3.通過溝通，激勵等方式建立良好的團隊精神

分析3：跟著感覺走 作者：張文銳

僅根據(jù)背景的簡單描述，憑著文字表面的東西，可以簡單分析原因如下幾點：
1、小丁的WBS設置應該有問題。
項目組的成員均全程參加，在不同階段應該有具體直接的責任人，責任人直接對項目負責，小丁則需要保持與直接責任人的溝通，了解進度、發(fā)現(xiàn)問題；從字面上根本看不出除了小丁之外的階段負責人；
2、小丁對進度計劃的控制有問題。
進度計劃確定后，應定期進行核對和調(diào)整。春節(jié)之后小丁才發(fā)現(xiàn)有問題，可見第一和第二階段的計劃是失控的。
3、小丁的管理方式有問題。
從小丁的背景看，應屬于技術出身轉型作管理的技術型管理人才。應該說在解決技術問題上具備得天獨厚的優(yōu)勢，但是第一次作項目經(jīng)理，難免亦從技術人員而非管理人員的角度出發(fā)，安排人員、計劃進度，從而在管理上有不到之處。

鑒于以上三點，建議小丁盡快做到：

1、馬上停止著手發(fā)現(xiàn)問題癥結所在，調(diào)整人員組成和職責劃分；
2、和所有成員溝通，修正計劃進度，并加強里程碑的控制；
3、轉換管理方式，跳出純技術管理的圈子。

分析4：個人意見 作者：pty
談幾點個人意見：
1.由于剛從技術人員轉為管理人員，制定的計劃更多是從技術方面考慮，對于人員管理方面考慮不足。
2.對于春節(jié)對人員影響考慮不足。
3.管理過程中反饋環(huán)節(jié)存在不足。
建議：
1.調(diào)整、明確人員職責。
2.細化目標。
3.對整個團隊說明目前情況，改變激勵機制，加大工作力度，按時、保質(zhì)完成目標。

分析5：可惜。 作者：夏雪松

第一需求分析好像時間太長了，一個月，這個項目好像不是很大.
項目計劃沒有制定完善.控制還沒有做好，春節(jié)后才發(fā)現(xiàn)進度存在問題，說明項目溝通也不是很好.
解決辦法:
采取加班趕工，詳細的做好剩余工作的wbs，以及責任矩陣圖.
每天都要監(jiān)控項目的進度，加強溝通.如果開發(fā)人員的水平存在問題，那么可以向高層申請高水平的開發(fā)人員.

分析6：項目處于不可控狀態(tài) 作者：許春飛

我覺得項目的前期準備不是非常充分，存在如下問題：
1、項目的WBS沒有做到位，過于粗粒度，沒有達到能夠完成項目分配的粒度，因此小丁根本就沒有辦法跟蹤和評估項目的正確進度，因此導致在第一階段就出現(xiàn)了項目延期。
2、不僅系統(tǒng)設計將延期，實際上后續(xù)的綜合布線計劃有問題，完全可以提前到需求分析結束后馬上開始，因為這樣安排不會造成資源和工期的沖突。
3、項目過程采用瀑布模型，無形中將增加項目風險。
建議：
1、重新考慮WBS結構，盡量符合可分配、可實現(xiàn)的原則；
2、考慮部分工作同步開始，節(jié)約時間
3、適當?shù)倪M行加班。

分析7：問題 作者：張立人

感覺主要問題是wbs的分解太粗。這樣對項目的計劃，控制都會出現(xiàn)問題。
第一：要做好計劃，計劃就要盡量的細致，否則就無法采用項目管理的方法保證項目進度。
第二：資源也無法加載到工作任務上去。
第三：項目的質(zhì)量也無法控制到點。
于是進度，費用，質(zhì)量都得不到很好的保障。

分析8：補充兩點關于溝通和如何編制WBS 的建議 作者：王勇

前面的許多高手已經(jīng)發(fā)表了看法。有的從溝通的角度談問題，有的從計劃控制的角度談問題，還有的節(jié)假日影響的角度談問題，等等。較多的人談到了溝通的重要性。

我也來補充兩點：

首先：溝通。項目中如果出現(xiàn)了問題，首先要檢查的就是溝通管理。
1.團隊的成員是否明確項目的計劃，是否真的認可該計劃？
2.各個工作的執(zhí)行情況是否定期匯報了？從上文中可以看到，項目從1月5日開始，直到2月17日樓主才剛剛發(fā)現(xiàn)比原來計劃晚了并且于可能原計劃無法按期完成。
3.出現(xiàn)了問題，樓主沒有主動和團隊成員自行分析。（或許分析了，只是沒有在上文中談到。）如果有樓主自行分析的項目可能延期的原因的話，我想大家會提出更多的建議。
其次，WBS編織過于簡單。我認為樓主提供的項目計劃是提供給老板或者客戶看的，而不是團隊內(nèi)部使用的WBS，這種粗糙的WBS更不能作為編織項目計劃基石。樓主只是給出了一個項目的大概框架和子系統(tǒng)的各部分的期望完成時間。從該WBS上面可以看出最底層的任務的工期至少也在半個月左右。

如果任何一個任務出現(xiàn)了問題，再加上上面第一點談到的溝通問題，就必然會出現(xiàn)樓主現(xiàn)在遇到的問題。即延期和延期發(fā)生了較長時間才知道。
那么既然問題出現(xiàn)了，如何解決哪？

首先，檢查溝通。大家一起分析出現(xiàn)延期，倒是是什么原因導致的。是否存在溝通問題？如果存在的話，如何解決？

其次，溝通后重新Update WBS和項目的Schedule.
關于WBS 和Schedule的編制。記不清是在PMBOK還是在其他的什么書上面看到的，WBS中的任務的工期最好不要長于一周。如果長于一周，就可能出現(xiàn)失去控制的情況。

分析9：項目風險分析 作者：王淼

各位同行已經(jīng)談了很多有價值的觀點，我這里再補充一點：
作為項目經(jīng)理在接受項目時就應該充分考慮項目可能遇到這樣或那樣的的風險，并應作詳細的風險評估。案例中的小丁顯然沒有足夠的經(jīng)驗。如果預計到進度滯后風險，則應在項目中預留準備資源，如預留額外的設計人員，這樣在風險真正發(fā)生時，可以避免整個項目進度滯后。

分析10：團隊協(xié)作，加班加點 作者：wxh

1. 項目估計有問題，項目管理必然要占用很多時間。導致小丁自己成了短木板，缺少一個備份的系統(tǒng)分析人員。
2. 前期小丁對項目進度控制不力.系統(tǒng)設計延遲了10天的時間，這么長的時間后才發(fā)現(xiàn)。可見平時對項目控制較差。
2. 溝通協(xié)調(diào)不夠，有些事情可以證其它人去做，包括系統(tǒng)分析及設計工作.如果只是自己做，項目可能會延遲更大。

解決:

1. 調(diào)整目標，協(xié)調(diào)人力加入項目。
2. 一般來講，項目中質(zhì)量是第1位的，考慮調(diào)整計劃，延期完成。
3. 同項目組人員溝通，加班加點. 可以在軟件設計，編碼階段壓縮時間。

文章來源: 網(wǎng)友推薦

【?發(fā)表評論?0條?】