成功的項目管理案例分析 引導語：項目管理：計劃、進度和控制的系統方法。以下是為大家的關于成功項目管理案例分析，希望對大家有所幫助。 某公司準備開發一個軟件產品。在項目開始的第一個月，項目團隊給出了一個非正式的、粗略的進度計劃，估計產品開發周期為1218個月。一個月以后，產品需求已經寫完并得到了批準，項目經理制定了一個12個月期限的進度表。因為這個項目與以前的一個項目類似，項目經理為了讓技術人員去做一些“真正的”工作(設計、開發等)，在制定計劃時就沒讓技術人員參加，自己編寫了詳細進度表并交付審核。每個人都相當樂觀，都知道這是公司很重要的一個項目。然而沒有一個人重視這個進度表。公司要求盡早交付客戶產品的兩個理由是： 1)為下一個財年獲得收入;2)有利于確保讓主要客戶選擇這個產品而不是競爭對手的產品。團隊中沒有人對盡快交付產品產生懷疑。 在項目開發階段，許多技術人員認為計劃安排的太緊，沒考慮節假日，新員工需要熟悉和學習的時間也沒有考慮進去，計劃是按最高水平的人員的進度安排的。除此之外，項目成員也提出了其他一些問題，但基本都沒有得到相應的重視。 為了緩解技術人員的抱怨，計劃者將進度表中的計劃工期延長了兩周。雖然這不能完全滿足技術人員的需求，但這還是必要的，在一定程度上減少了技術人員的工作壓力。技術主管經常說：產品總是到非做不可時才做，所以才會有現在這樣一大堆要做的事情。 計劃編制者抱怨說：項目中出現的問題都是由于技術主管人員沒有更多的商業頭腦造成的，他們沒有意識到為了把業務做大，需要承擔比較大的風險，技術人員不懂得做生意，我們不得不促使整個組織去完成這個進度。 在項目實施過程中，這些爭論一直很多，幾乎沒有一次能達成一致意見。商業目標與技術目標總是不能達成一致。為了項目進度，項目的規格說明書被匆匆趕寫出來。但提交評審時，意見很多，因為很不完善，但為了趕進度，也只好接受。 在原來的進度表中有對設計進行修改的時間，但因前期分析階段拖了進度，即使是加班加點工作，進度也很緩慢。這之后的編碼、測試計劃和交付物也因為不斷修改規格說明書而不斷進行修改和造成返工。 12個月過去了，測試工作的實際進度比計劃進度落后了6周，為了趕進度，人們將單元測試與集成測試同步進行。但麻煩接踵而來，由于開發小組與測試小組同時對代碼進行測試兩個組都會發現錯誤，但是對測試人員發現的錯誤響應很遲緩，開發人員正忙于完成自己的工作。為了解決這個問題，項目經理命令開發人員優先解決測試組提出的問題，而項目經理也強調測試的重要性，但最終的代碼中還是問題很多。 現在進度已經拖后10周，開發人員加班過度，經過如此長的加班時間，大家都很疲憊，也很灰心和急躁，工作還沒有結束，如果按照目前的進度方式繼續的話，整個項目將比原計劃拖延4個月的時間。 問題： 1.在本案例中，我們能吸取什么教訓嗎? 2.編制計劃時，邀請項目組成員參與有哪些好處? 3.學習曲線對軟件項目有哪些影響? 1本例存在的問題 (1)前期制定工作計劃沒做好 項目啟動時沒有就項目的范圍、技術可行性、資源可利用性等進行充分論證和評估，計劃制定時沒有做好評審，項目干系人的溝通工作沒有做好。風險控制沒有做好。做計劃時，沒有像做預算一樣留出風險控制期。什么都按照最緊張的來做，一旦有地方出現問題，進度延誤就成了必然的了。 項目組成員沒有參加，這個問題就很嚴重，項目經理認為一個完全合格的程序員是可以在規定時間里完成指定的任務的，但是事實是這樣嗎?開發期間難免會遇到技術瓶頸，這些都是需要時間去研究的，新員工不熟悉的項目也沒有考慮。制定工作計劃的時候，項目經理最好是給一個大概的框架，在自己判斷的基礎上征求項目組成員的意見，盡量安排一個大家都認可的計劃。 (2)管理問題 項目組的成員在做完這個項目后，都很疲憊，另外自信心也很受打擊，花了時間沒有交出一個好的項目，問題就不止在技術層面了，這大部分是管理的問題，從長遠來看，這個項目組的成員離開的幾率很大，公司的人才會流失。 整個案例中沒有發現項目經理的工作是什么，項目經理的定位一定要明確，本案例中計劃編制者更像是一個系統推銷人員，是從市場出發的，完全沒有考慮到開發的難度。 項目經理不知道各部門人員的立足點。即便項目經理制定了限期，也應該把項目的各個階段策劃目標向大家進行報告，讓各個職能部門能夠在框架下、限期內合理安排各自的工作內容。 對與大項目，項目組內的分層管理也很有必要。項目經理把指標分解給各個開發組組長，具體的開發工作讓他們安排下去，項目經理可以花點時間去考慮一下項目組的整體問題，例如：成員疲憊等問題。抽一個晚上不加班，組織點活動讓項目成員透透氣，比加班效果好得多。例如風險的審視、計劃統籌調整、組織層面的一些問題推動。 (3)溝通問題 項目實施階段，商業目標與技術目標意見分歧很大，這個就是溝通嚴重有問題了，為什么在實施前沒有討論好? 做項目計劃之前要充分和項目干系人溝通。尤其是技術主管和發起人。一個是從技術角度考慮，一個是從商業角度考慮。要讓兩個人的要望都得到滿足，這樣的計劃才可行。案例中，只是從商業角度去考慮了這個問題，根本沒有考慮技術上的實現難度，單純的計算出所需的人月數。人月神話本身就是一個錯誤的理論。 員工抱怨。員工的抱怨并不是無理的，正是因為他們沒有得到動員和鼓勵，更沒有得到階段性的工作目標。員工也都有自己的想法和構思，應該統一大家的思想，便捷的方法就是讓他們知道他們在做什么，價值在那里，他們的各自工作安排如何，才能讓整個團隊步調一致，協調統一。 (4)項目跟蹤沒有做好，應該定時開進度研討會。關鍵的里程碑沒有得到有效控制，規格說明書等關鍵節點沒有控制好。 (5)單元測試與集成測試一起做 在時間緊的情況下，這樣做也是沒有辦法，但是研發人員和測試人員一定得分清問題的嚴重程序，功能性的BUG，導致系統不能正常使用，必須優先修改，用戶體驗方面的修改，可以等系統試用后征求用戶的需求再進行修改 (6)項目的人力資源問題 有新老員工，做計劃時一定要考慮新員工前期的培訓周期，這是影響計劃的一個重要因素。不能按照人月來定周期，還要考慮實際的工作能力。 2.編制計劃時，邀請項目組成員參與有哪些好處? 做項目計劃時，商務、客戶代表、項目管理人員、QA、項目技術骨干、甚至公司的技術委員會成員等都要參與，至少在評審時一定要參與。讓大家都了解項目的背景，意義和要求。可以統一思想，減少溝通風險和技術風險。對進度計劃評估的更貼近實際。讓參與的各部門人員明白自己將要完成工作的時間和未能按期完工對其他部門會產生的影響，還有就是根據時間節點分配自己任務。成員自己給出的承諾，他會對計劃的結果上心一點。 3.學習曲線對軟件項目有哪些影響? 學習曲線對項目的影響： (1)需要有一個過程，前面比較慢、技術的儲備、熟練程度的把握; (2)計劃編制時前期安排一定的緩沖時間，便于學習&掌握技能，對設計、架構等關鍵節點做好相應的評