案例分析一：專案管理過程
專案背景
某市電子政務資訊系統工程，總投資500萬，主要包括網路平台建設和業務辦公應用系統開發，通過公開招標，確定工程的承建單位是a公司，按照《合同法》的要求與a公司簽訂了工程建設合同，並在合同中規定a公司可以將機房工程這樣的非主題、非關鍵性子工程分包給具備相關資質的專業公司b，b公司將子工程轉手給了c公司。
在隨後的應用系統建設過程中，監理工程師發現a公司提交的需求規格說明書質量較差，要求a公司進行整改。此外，機房工程裝修不符合要求，要求a公司進行整改。
專案經理小丁在接到監理工程師的通知後，對於第二個問題拒絕了監理工程師的要求，理由是機房工程由b公司承建，且b公司經過了使用者方的認可，要求追究b公司的責任，而不是追究自己公司的責任。對於第乙個問題，小丁把任務分派給程式設計師老張進行修改，此時，系統的設計工作已經開始，程式設計師老張獨自修改了已進入基線的程式，小丁默許了他的操作。老張在修改了需求規格說明書後採用郵件通知了系統設計人員。
合同生效後，小丁開始進行專案計畫的編制，開始啟動專案。由於工程緊張，甲方要求提前完工，總經理比較關心該專案，詢問專案的一些進展情況，在專案匯報會上，小丁向總經理遞交了進度計畫，公司總經理在閱讀進度計畫後，對專案經理小丁指出任務之間的關聯關係不夠清晰，要求小丁重新更改一下計畫,新的專案計畫出來了，在計畫實施過程中，由於甲方的特殊要求，需要專案提前2周完工，小丁又更改了專案進度計畫，專案最終按時完工。
案例問題
問題1小丁在合同生效後進行的專案計畫編制工作應該如何進行？
小丁在接到任務後開始專案計畫的編制工作，應包括：
專案總計畫：範圍計畫、工作範圍定義、活動定義、資源需求、資源計畫、活動排序、費用估算、進度和費用計畫
專案輔助計畫：質量計畫、溝通計畫、人力資源計畫、風險計畫、採購計畫等
問題2小丁在處理監理工程師提出的問題上處理是否正確？你作為專案經理，應該如何處理？
依據《中華人民共和國招投標法》第48條：中標人應當根據合同約定履行義務，完成中標專案。中標人不得向他人轉讓中標專案，也不得將中標專案肢解後分別向他人轉讓。
中標人按照合同約定或經招標人同意，可以將中標專案的部分非主體、非關鍵性工作分包給他人完成。接受分包的人應具備相應的資格條件，並不得再次分包。
本案例中，a公司將子項工程分包給b，b又將其分包給c，顯然違背了《招標法》第48條規定「中標人應當就分包專案向招標人負責，接受分包的人就分包專案承擔連帶責任」，a公司顯然要承擔責任，b公司也負連帶責任
問題3在專案執行過程中，由於程式設計師老張獨自修改了以進入基線的程式，小丁默許了他的操作，小丁的處理方式是否正確？你作為專案經理，應該如何處理？
專案經理小丁不應默許老張的行為，且修改後的東西沒有經過評審。
專案缺乏變更控制體系，同時，專案團隊其他成員不清楚變更程式的步驟和要求。
建立配置管理體系
建立變更請求流程
組建變更控制委員會ccb
問題4該案例中，專案管理的哪些方面需要改進？
從專案管理9大知識體系出發闡述改進方面；
本專案管理交弱的方面是重點改進方向：
專案經理法律法規的理解（招投標管理）
專案進度管理
專案變更控制
配置管理和計畫的變更將導致成本、質量的變化
案例分析二：專案變更控制
專案背景
某軟體中心（a方）承擔了某大型上市公司（b方）erp系統開發與實施專案。專案計畫確定後，在實施過程中，幾次發生計畫變更，原因如下：
（1）證監會要求上市公司執行新的會計制度，需要修改erp系統財務子系統；
（2）b方首付資金未能按時支付，導致a方開發計畫推遲；
（3）a方盲目確定進度目標，實際難以完成；
（4）b方因機構重組改變了業務流程，需要修改專案範圍；
（5）a方的前期設計有疏漏，需要修改設計方案；
（6）b方提出增加合同審計功能，需要修改專案範圍；
（7）由於b方需求表達不清，a方理解有誤，雙方溝通不夠，導致專案實施時發現需求偏差，需要糾偏；
（8）b方自行負責的機房工程延誤，影響了實施進度；
（9）a方開發人員跳槽，影響了開發進度；
（10）b方行業主管部門發布了新的行業erp實施規範，需要修改專案實施方案。
案例問題
問題1專案變更的內部因素和外部因素分別指什麼？
由專案執行偏差導致專案計畫變更的各種誘發因素稱為專案變更的內部因素。
由專案目標變化導致專案計畫變更的各種誘發因素稱為專案變更的外部因素。
問題2上述5條變更，哪些屬於內部因素？哪些屬於外部因素？
（2）（3）（5）（7）（8）（9）屬於專案變更的內部因素；
（1）（4）（6）（10）屬於專案變更的外部因素
問題3由於內部因素導致變更，從而可能增加建設經費？是否一定要由承建方承擔？
（3）（5）（9）屬於a方責任，由此增加的專案費用由a方承擔；
（7）屬於雙發責任，a、b雙方協商分攤；
其餘各條，無論b方是否負有責任，均應承擔由此增加的專案費用。
問題4對於由於內部因素和外部因素引發的變更請求，變更評估的重點有何不同？
對於由內部因素引起的變更請求，變更評估的重點是確定最優變更方案；
對於由外部因素引起的變更請求，應重點評估變更的必要性。
案例一：範圍定義
專案背景
黎明資訊科技****原本是一家專著於企業資訊化的公司，在電子政務如火如荼的時候，開始進軍電子政務行業。在電子政務的市場中，承接的第乙個專案是開發一套工商審批系統。
由於電子政務保密要求（國家要求），該系統涉及到兩個互不聯通的子網：政務內網和政務外網。政務內網中儲存著全部資訊，其中包含部分機密資訊；政務外網可以對公眾開放，開放的資訊必須得到授權。
系統要求在這兩個子網中的合法使用者都可以訪問到被授權的資訊，訪問的資訊必須一致可靠，政務內網的資訊可以發布到政務外網，政務外網的資訊在經過審批後可以進入政務內網系統。
丁偉是該項目的專案經理，在捕獲到這個需求後認為電子政務專案建設和企業mis專案有很大不同，有其特殊性，若照搬企業資訊化專案原有的經驗和方法必定失敗。
丁偉在該專案中採用了嚴格的瀑布模型，並專門招聘了熟悉網路互聯互通的技術人員參與設計了解決方案，在經過嚴格評審後開始實施專案。
在專案交付時，雖然系統完全滿足了專案保密性要求，但使用者對系統使用者介面提出了較大異議，認為不符合政務資訊系統的要求和風格，操作也不夠便捷，要求徹底更換。
由於最初設計的缺陷，系統表現層和邏輯層緊密耦合，導致70%的**重寫，而第二版的使用者介面仍然沒有達到使用者的要求，最終又重寫了部分**才勉強通過使用者驗收。由於整個專案反覆變更，專案組成員產生了強烈的挫折感，士氣低落，專案工期也必原先的計畫超出一倍，專案成本超出預算的100%，專案使用者滿意度較低。
該專案最終的結果與公司的期望偏差很大，黎明公司決定暫時放棄進軍電子政務市場，並要求相應的事業部進行業務轉型，大幅度裁員，骨幹技術人員流失嚴重！
問題1如何評估丁偉的專案管理行為？
1.注意到了系統執行環境的特殊性，在良好設計和實現的情況下滿足了使用者要求
2.忽略了系統使用者的潛在要求，在使用者介面和操作風格上範圍定義不清，造成專案交付時產生重大變更
3.第一次問題發生後仍沒有對範圍進行有效管理，造成專案第二次變更
4.沒有對使用者介面是否能夠滿足要求的風險進行有效的管理，而採用抗風險較弱的瀑布模型組織開發
5.沒有對設計的質量進行有效控制，造成表現層和業務邏輯層緊密耦合，直接導致增加了變更代價
問題2從專案範圍管理的角度找出專案實施過程中的管理問題？
1.沒有挖掘到系統的全部**需求，缺乏精確的範圍定義
2.當發生第一次變更時，丁偉仍沒有進行有效的範圍管理，直接造成專案的第二次變更
3.重複的系統變更說明丁偉對專案範圍控制不足，導致專案範圍接二連三的變更、反覆
問題3從範圍管理的角度出發，如何避免類似問題的發生？
有效的範圍管理包括了從範圍定義到範圍控制等眾多方面的工作，每一項工作都是重要的
1.結合行業特點進行需求分析充分挖掘系統**需求
2.通過原型法來驗證需求的定義，避免範圍定義不清的問題
3.在發生需求變更時應進行有效的需求控制，在滿足使用者需求前提下縮小需求範圍，避免需求再次變更
案例點評
這是乙個失敗的專案，丁偉在專案管理過程中既有閃光的地方，也要失敗的地方；
專案範圍管理的失誤是造成失敗的關鍵原因:
模糊的範圍定義
錯誤的工作分解
缺失的範圍確認
無力的範圍控制
也暴露出風險管理、系統設計方面的問題
案例分析
丁偉對專案範圍有一定把握（閃光點）
發現了不同行業間具有不同的特點
捕獲到了政務內、外網的需求，並進行了定義，嚴格控制了這一需求的設計和實現
如果忽視這一行業標準，專案將招致更大的失敗
丁偉對於像使用者介面的風格和操作便捷性的需求沒有充分考慮，導致一而再，再而三的變更
沒有意識到系統「**需求」的重要性
行業特點決定範圍約束（使用者介面、操作便捷性）
丁偉對專案範圍和需求的定義理解並不完整
電子政務行業特點，使對專案範圍定義更加困難
終端使用者不參加需求和開發工作
需求的間接性
丁偉在範圍確認和範圍控制方面存在失誤
第一次變更就應該充分認識介面、操作的重要性
應該立即採取措施清晰的定義介面風格、操作風格
丁偉沒有進行充分的風險管理
**行規和行業特點意味著專案範圍定義的風險
採用瀑布模型增加了風險發生後帶來的損失
這個案例中，缺乏良好的設計也是明顯的缺陷
使用者介面中耦合了大量的業務邏輯，增加了變更代價
總結語專案的閃光點在於對專案執行環境進行了清晰的定義，並最終滿足了使用者的要求
不充分的範圍定義和範圍確認導致了專案的失敗
採用抗風險較弱的瀑布模型和低質量的設計增加了專案範圍變更得代價
案例二：範圍管理工作要點
專案背景
a集團是黎明資訊科技****的多年客戶，黎明公司已經為其開發了多個資訊系統，最近a集團又和公司簽訂了新的開發合同，以擴充整個企業資訊系統的業務範圍；
案例分析題
倪潤峰，男，1944年出生於山東，大連理工學院畢業，重慶大學名譽教授，現任長虹集團董事長兼總經理。1985年，倪潤峰由長虹機器廠工程師調任廠長。14年中，長虹由乙個不知名的軍工生產企業發展成為國內外都有相當知名度的大型企業集團，連續幾年獲中國電子百強第一名。在中國，談到彩電就要談到長虹，談到長虹就要...
案例分析題
背景資料 某電力工程土建施工專案雙代號網路計畫如下圖所示，該工程工期為15個月，在該施工進度網路計畫中，工作b e i均為土方工程，土方工程量分別為5000m3 7500m3 5500m3共計18000 m3，土方單價為18元 m3。在合同中規定，當土方工程量增加超出原估算工程量10 時，新的土方單...
個人與團隊管理」案例分析題複習
個人與團隊管理 課程考核 2015年複習材料 為了進一步提高學生的課程複習效率，個人與團隊管理 課程專案組按照2012年個人與團隊管理考試改革方案，在 個人與團隊管理 課程考核2012年秋期末複習資料 基礎上，特別對2015年 春 秋 期末複習資料進行了更新，以鞏固學生課堂學習內容，幫助學生在考試中...