愛華網(wǎng)說明：項目管理案例系列由項目管理者聯(lián)盟[PMU]制作推出，版權所有。該系列以PMU會員實際項目案例為藍本，結(jié)合項目管理專家點評和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)設計和軟件設計aihuau.com3）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ì)量的下降。文字結(jié)束前希望日后能看到筆者對于已經(jīng)完成的項目的分析和采取的措施和最終結(jié)果。 分析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、小丁的管理方式有問題。從小丁的背景看，應屬于技術出身轉(zhuǎn)型作管理的技術型管理人才。應該說在解決技術問題上具備得天獨厚的優(yōu)勢，但是第一次作項目經(jīng)理，難免亦從技術人員而非管理人員的角度出發(fā)，安排人員、計劃進度，從而在管理上有不到之處。鑒于以上三點，建議小丁盡快做到：1、馬上停止著手發(fā)現(xiàn)問題癥結(jié)所在，調(diào)整人員組成和職責劃分；2、和所有成員溝通，修正計劃進度，并加強里程碑的控制；3、轉(zhuǎn)換管理方式，跳出純技術管理的圈子?！?p>分析4：個人意見 作者：pty 談幾點個人意見：1.由于剛從技術人員轉(zhuǎn)為管理人員，制定的計劃更多是從技術方面考慮，對于人員管理方面考慮不足。2.對于春節(jié)對人員影響考慮不足。3.管理過程中反饋環(huán)節(jié)存在不足。建議：1.調(diào)整、明確人員職責。2.細化目標。3.對整個團隊說明目前情況，改變激勵機制，加大工作力度，按時、保質(zhì)完成目標?！?p>分析5：可惜。 作者：夏雪松 第一需求分析好像時間太長了，一個月，這個項目好像不是很大.項目計劃沒有制定完善.控制還沒有做好，春節(jié)后才發(fā)現(xiàn)進度存在問題，說明項目溝通也不是很好.解決辦法:采取加班趕工，詳細的做好剩余工作的wbs，以及責任矩陣圖.每天都要監(jiān)控項目的進度，加強溝通.如果開發(fā)人員的水平存在問題，那么可以向高層申請高水平的開發(fā)人員. 分析6：項目處于不可控狀態(tài) 作者：許春飛 我覺得項目的前期準備不是非常充分，存在如下問題：1、項目的WBS沒有做到位，過于粗粒度，沒有達到能夠完成項目分配的粒度，因此小丁根本就沒有辦法跟蹤和評估項目的正確進度，因此導致在第一階段就出現(xiàn)了項目延期。2、不僅系統(tǒng)設計將延期，實際上后續(xù)的綜合布線計劃有問題，完全可以提前到需求分析結(jié)束后馬上開始，因為這樣安排不會造成資源和工期的沖突。3、項目過程采用瀑布模型，無形中將增加項目風險。建議：1、重新考慮WBS結(jié)構，盡量符合可分配、可實現(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)延期，倒是是什么原因?qū)е碌?。是否存在溝通問題？如果存在的話，如何解決？其次，溝通后重新Update WBS和項目的Schedule.關于WBS 和Schedule的編制。記不清是在PMBOK還是在其他的什么書上面看到的，WBS中的任務的工期最好不要長于一周。如果長于一周，就可能出現(xiàn)失去控制的情況。分析9：項目風險分析 作者：王淼 各位同行已經(jīng)談了很多有價值的觀點，我這里再補充一點：作為項目經(jīng)理在接受項目時就應該充分考慮項目可能遇到這樣或那樣的的風險，并應作詳細的風險評估。案例中的小丁顯然沒有足夠的經(jīng)驗。如果預計到進度滯后風險，則應在項目中預留準備資源，如預留額外的設計人員，這樣在風險真正發(fā)生時，可以避免整個項目進度滯后?！?p> 分析10：團隊協(xié)作，加班加點 作者：wxh 1. 項目估計有問題，項目管理必然要占用很多時間。導致小丁自己成了短木板，缺少一個備份的系統(tǒng)分析人員。
![項目管理案例系列[10]：項目管理與進度計劃管理](http://img.aihuau.com/images/a/0602020606/020609310976587331.jpeg)
2. 前期小丁對項目進度控制不力.系統(tǒng)設計延遲了10天的時間，這么長的時間后才發(fā)現(xiàn)?？梢娖綍r對項目控制較差。2. 溝通協(xié)調(diào)不夠，有些事情可以證其它人去做，包括系統(tǒng)分析及設計工作.如果只是自己做，項目可能會延遲更大。解決:1. 調(diào)整目標，協(xié)調(diào)人力加入項目。2. 一般來講，項目中質(zhì)量是第1位的，考慮調(diào)整計劃，延期完成。3. 同項目組人員溝通，加班加點. 可以在軟件設計，編碼階段壓縮時間。
愛華網(wǎng)本文地址 » http://www.klfzs.com/a/9101032201/392851.html
