此文檔收集于網絡，如有侵權請聯系網站刪除案例分析一：項目管理過程項目背景某市電子政務信息系統工程，總投資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集團又和公司簽訂了新的開發合同，以擴充整個企業信息系統的業務范圍；張凡被任命為該項目的項目經理。項目經理張凡組織相關人員對該項目的工作進行了分解，并參考了黎明公司和A集團曾經合作的項目，評估得到項目總工作量為60人月，計劃工期為6個月。項目剛剛開始不久，張凡的高層經理孫總找到張凡，孫總表示由于公司運作的需要，要求張凡在4個月內完成項目，考慮到壓縮工期的現實，可以為該項目增派兩名開發人員。張凡認為，整個項目的工作量是經過仔細分解后評估得到的，評估過程也參考了歷史上與A集團合作的項目度量數據，該工作量是客觀現實的。目前項目已經開始，增派新的開發人員還需要一定時間的熟悉，因此即使增派兩人也很難在四個月內完成項目，如果強行要求項目組成員通過加班加點方式追逐4個月完成項目的目標，肯定會降低項目的質量，造成用戶的不滿。對此，張凡提出的解決方案是：將整個項目分成兩部分實現，第一部分使用三個半月的時間，第二部分使用三個月的時間，分別制定出兩部分的驗收標準，這樣不增派開發人員也能完成項目。高層經理孫總認為該方案可以滿足公司運作的要求，用戶也同意按照這種方案進行實施。六個半月以后，項目在沒有增加人員投入的情況下順利完成，雖然整個項目比最初的計劃延長了半個月，但既達到了公司的要求，客戶對交付的系統也比較滿意，項目成員也沒有感受到很大的壓力。問題1點評張凡是如何應對項目范圍變更的，采取了哪些措施？1.首先對最初的項目范圍進行了清晰的定義，并根據定義對項目任務進行了分解，制定了WBS2.對項目進行了估算，且估算結果真實可信，對項目工作量有量化的把握3.在出現新的項目目標后，對項目范圍進行了控制，縮小了第一階段實現的項目范圍4.對重新定義的項目范圍進行了確認，與高層經理和客戶達成了一致5.對項目進行了溝通管理，協調了多個項目關系人之間的矛盾問題2結合案例指出項目范圍管理的工作要點？1.制定范圍管理計劃2.進行項目范圍定義3.項目工作分解WBS4.進行項目范圍確認5.對項目范圍進行控制本案例中，張凡首先進行了范圍定義和工作分解，得到清晰的項目范圍；在出現新的項目目標后，張凡進行了范圍控制，重新定義了兩個階段的項目范圍；最后，將重新定義的范圍與項目干系人進行了確認案例點評1.這是一個成功的項目管理案例，項目經理張凡有效的運用范圍管理手段，在不同項目干系人中達成一致，使項目的結果同時滿足了公司高層經理、客戶、項目組成員的要求。2.作為一個項目經理，必須熟練掌握和應用項目管理九大知識領域的技能，對于信息系統開發項目而言，范圍管理是其中最重要的技能之一。3.軟件項目的范圍主要是由系統需求構成的，而系統需求既是難以把握的，也是容易調整和控制的(1)在滿足項目目標前提下，可以定義出不同的系統需求(2)根據經驗，軟件項目管理總是從范圍管理開始，先定義系統的邊界，然后再在明確的范圍內進行時間、成本、質量和風險的管理(3)范圍、時間、成本、質量之間的邏輯關系是項目管理的客觀規律(4)當范圍因素已經確定的條件下，不妨根據時間、資源（成本）的重新計劃來調整合理的項目范圍4.軟件項目的范圍變更應重新進行項目計劃的調整將項目分解成兩部分，實際上項目范圍已經被擴大了范圍變化導致任務、任務之間的邏輯關系的重新調整需要考慮分割項目的驗收標準，這是與用戶達成一致的前提5.范圍控制并非總是針對客戶的要求而進行的控制項目范圍控制需求，這個公式是錯誤的設計策略是項目經理可以把握的（夠用策略、犧牲質量特性策略、過度設計）即使需求已經確定，有效的范圍管理仍能給項目帶來巨大收益范圍管理的空間很大，帶來的收益是降低成本、縮短工期6.案例中，張凡還運用了其他范圍管理手段項目剛開始，對項目范圍進行了定義劃分了項目WBS，并對項目進行了估算、計劃在孫總提出縮短工期的要求后，首先進行了范圍控制，縮小了第一步需要完成的項目范圍，接著又對兩階段需要完成的項目范圍進行了重新定義制定了兩階段驗收標準對重新定義的范圍進行了確認，與客戶、高層經理達成一致 7.總結語張凡在范圍管理方面進行全面的控制，此外也運用了其他項目管理手段，包括對項目估算計劃（時間管理），協調多個項目干系人之間的矛盾（溝通管理）案例三：范圍確認黎明信息技術有限公司和M企業簽訂了一份合同，合同的主要內容是處理黎明公司以前為M公司開發的信息系統的升級工作。升級后的信息系統可以滿足M公司新的業務流程和范圍；王強被任命為該項目的項目經理, 由于該項目是一個現有系統的升級項目，王強特意請來了原系統的需求調研人員李偉擔任該項目的需求調研負責人。在李偉的幫助下，很快完成了需求分析的工作，并進入設計和編碼，由于M公司的業務非常繁忙，M公司的業務代表沒有足夠時間投入到項目中，確認需求的工作一拖在拖。王強認為雙方已經建立了密切合作的關系，李偉也已經參加了原系統的需求開發工作，對M公司的業務比較熟悉，因此定義的需求是清晰的，故王強并沒有催促業務代表在需求說明書中簽字。進入編碼階段后，李偉因故移民加拿大，需要離開項目組，王強考慮到系統需求已經定義，項目也進入編碼階段，李偉的離職雖然會對項目造成一定影響，但影響較小，因此很快為其辦好離職手續。在系統交付的時候，M公司的業務代表認為甲方已經提出的需求很多沒有實現，實現的需求也有很多不能滿足M公司現有的業務要求，必須全部實現這些需求后才能驗收。此時，李偉已經離開項目組，沒有人能夠清晰地解釋乙方已經完成的需求說明書。最終系統需求發生重大變更，項目延期超過50%，M的業務代表也因為系統的延期表示了強烈的不滿。案例問題問題1對王強在項目管理工作中的行為進行點評。1.王強為了更明確地把握系統需求，聘請了原系統需求調研人員李偉，提高了需求定義的效率和質量；2.王強沒有對李偉提供的系統需求進行評審核復查，從而使需求的缺陷沒有被及時發現；3.王強沒有要求用戶對已經定義的需求進行確認，從而導致需求理解的偏差；4.王強對需求缺乏有效控制，最終導致項目延期50%問題2從項目范圍管理的角度找出項目實施過程中的管理問題？項目實施過程中的主要問題包括：1.在范圍定義過程中，王強沒有對李偉定義的需求進行評審，造成需求中的質量缺陷沒有被及時發現；2.在范圍確認過程中，王強沒有主動要求用戶對需求進行確認；3.在范圍控制過程中，王強無法進行有效的范圍控制，最終造成了重大的需求變更。問題3從范圍管理的角度出發，如何避免類似問題的發生？本案例說明項目范圍管理中應采取以下規避措施：1.項目經理需要對需求定義的結果進行質量控制，采取評審等方式減少需求定義中存在的缺陷；2.對已經定義的需求要及時與用戶進行確認，保證雙方理解的一致；3.在發生需求變更時，應采取靈活手段，在滿足用戶需求的前提下，盡量減少需求變更得范圍。案例點評1.這是一個失敗的項目，和很多失敗的軟件項目一樣，王強在項目范圍（或軟件需求）方面栽了跟頭；項目經理王強即重視需求，又沒有控制好需求的案例開發和定義軟件系統的需求是整個項目過程的關鍵管理項目范圍是常識，但往往因為一時的疏忽而造成需求的重大缺陷2.項目實施過程經歷了波折，但未引起重視，最終失敗！項目開局：充滿光明項目中期：出現烏云項目交付：下雨了3.王強在項目管理中成功的方面找到合適的資源進行需求的定義可以快速準確地把握新系統的需求4.王強在范圍確認和范圍控制方面存在失誤認為緊逼客戶確認需求不近人情，抱著僥幸心里進入開發階段未履行需求評審和確認過程，造成缺陷未及時發現需求控制失去基準，導致重大變更5.從項目管理的角度分析，項目范圍直接決定了工作量和工作目標，項目范圍管理中的關系范圍定義：管理的基礎范圍確認：基線化已定義的范圍范圍控制：減少變更，保持范圍的穩定6.項目范圍確認的方法客戶代表確認需求說明書（需求報告）召集客戶的業務骨干對需求進行評審詳細記錄原始的調研材料，讓客戶確認調研報告迭代開發逐步確認需求案例分析五：項目工程網絡圖的繪制項目背景某化工廠擬進行管道安裝工程，工程進度如下表所示，繪制該項目的工程網絡圖。繪制雙代號網路圖步驟第1：從起始活動開始，畫出第一個活動的緊后工作畫出 A 活動和其緊后活動，即 B、C、E、F 圖2 圖1 第2：從左到右依次找出緊后活動找出 B、C、E、F 的緊后活動B、C 的緊后活動是 DF 的緊后活動是 GD、E 的緊后活動是 I由于 B、C 活動對 D 是平行工作因此引入虛活動 第3：從左到右依次找出緊后活動找出 I、G 的緊后活動D、E、G 的緊后活動為 HD、E、G 對 H 來說是平行工作，因此引入虛活動H、I 活動的緊后活動是 J第4：從左到右依次找出緊后活動找出 J 的緊后活動 K、L第5：從左到右依次找出緊后活動找出 K、L 的緊后活動 M、N由于 K、L 活動對 M 是平行工作因此引入虛活動第6：從左到右依次找出緊后活動找出 M、N 的緊后活動 P完成初步工程網絡圖該項目的單代號網路圖案例分析六：網絡圖時間參數及關鍵路徑確定項目背景某公司弱電布線工程項目，雙代號工程網絡圖如下所示，確定該項目關鍵路徑。一般網絡時間計算第1：計算工作最早時間 ES、EF第一個活動 ES=0ES = max緊前工作的EFEF = ES + 工作延續時間 (t)第2：計算工作最遲時間 LS、LF最后一個活動 LF(n) = EF(n)LF = min緊后工作的LSLS = LF - 工作延續時間 (t)第3：計算總時差TF總時差是指不影響整個項目最早完成時間的前提下，一項工作的完工期可推遲的時間TF = LF EF 或者 TF = LS ES第4：計算自由時差FF自由時差是指不影響緊后工作的最早開始時間的前提下，一項工作的完工期可推遲的時間FF = minES(緊后工作) EF確定關鍵路徑案例分析七：軟件項目的時間管理和成本管理項目背景小張為藍德公司技術總監，最近接到公司任務，負責開發一個電子商務平臺，由于公司業務發展需要，公司總裁急于啟動電子商務平臺項目，要求小張盡快準備關于啟動電子商務平臺的立項報告小張粗略估算該項目正常速度下的時間和成本在第一次項目策劃會議上，項目團隊確定了與項目相關的任務在第一次項目策劃會議上，項目團隊確定了與項目相關的任務，具體任務情況如下第一項任務：調研現有的電子商務平臺按正常速度估算完成該任務需10天，成本15000元允許最多加班情況下，需要7天，成本18750元第二項任務：制定項目計劃并提交管理層評審估計正常情況下需要5天，成本約3750元加班趕工時可在3天完成，成本為4500元第三項任務：需求分析、系統設計歷史估計為15天，成本45000元加班時約需10天，成本58500元設計完成后，有三項工作必須同時進行開發電子商務后臺數據庫在不加班情況下估計需10天，成本9000元加班情況下估計僅需要7天，成本11250元開發和編碼前臺網頁腳本項目團隊估計可在10天完成，成本17500元如果允許加班可縮短2天時間，成本19500元電子表單控件設計與開發采用外包方式進行，需要7天，外包成本8400元沒有加班趕工方案整個電子商務平臺集成、測試約3天，成本4500元，如果允許加班可節省1天，成本6750元案例問題【問題1】如果不加班，完成此項目的成本和時間是多少？考慮加班，項目可以完成的最短時間和最短時間內完成項目的成本是多少？【解答】需要進行關鍵路徑的計算，根據關鍵路徑法（CPM）注意：最短完成時間路徑并不是加班情況下的最短路徑，而是最長路徑-關鍵路徑關鍵路徑： 累計關鍵路徑工期，完成項目需43天，累計成本即項目成本約103,150元累計關鍵路徑中加班后的最短時間，為30天，成本為127,650元【問題2】假定調研其他電子商務平臺的任務需要13天而不是原先估算的10天，項目經理小張應采取什么行動來保持項目按正常速度進行且增加的成本最少？【解答】由于調研電子商務平臺活動在關鍵路徑上，導致整個項目工期延長3天，因此應考慮加班趕工來保證整個項目進度，為保證項目進度，需趕工3天趕工原則是“優先考慮趕工費率最低的工作”根據趕工費率分析， 活動和費率最低活動只有2天可趕工時間，還差1天但選擇活動趕工1天將導致也需趕工1天活動趕工1天的實際趕工費率是1,750元因此，應選擇趕工1天，費率是1,250元【答案】選擇趕工1天， 趕工2天，此方案增加的成本是2,000元（=1250+275*2）【問題3】假定老總想在35天內完成項目，項目經理應采取什么措施達到預期要求？在35天完成項目將花費的成本是多少？【解答】顯然需要在制定趕工調整方案，但必須考慮關鍵路徑上活動的變化導致其他非關鍵路徑的變化情況，關鍵路徑上的工期：10+5+15+10+3=43天關鍵路徑上正常工期43天，需趕工8天（=43-35）根據趕工費率分析，趕工方案為趕工2天，趕工3天，/各趕工2天趕工1天總成本=103,150+750+3750+3500+2250=113,400元趕工2天，趕工3天，/各趕工2天，趕工1天總成本 = 18750+4500+45000+11250-750+19500+8400+6750=113,400元案例分析活動排序、編號繪制工程網絡圖案例分析八：活動排序和進度控制項目背景藍德公司承擔一項網絡工程項目的實施，公司系統集成工程師小丁接到任務后分析了項目任務，并開始進行活動手工排序小丁分析出活動A所需時間為5天，完成活動B所需時間為6天，完成活動C所需時間為5天，活動D所需時間4天，活動C、D必須在活動A完成后才能開工。完成活動E所需時間為5天，且在活動B、C完成后開工，活動F在活動E之后才能開始，所需時間為8天，完成活動B、C、D完成后，才能開始G、H，所需時間分別為12天、6天。活動F、H完成后才能開始活動I、K，所需時間分別為2天、5天。完成活動J所需時間為4天，只有當活動G和I完成后才能進行。項目經理據此畫出工程施工進度網絡圖案例問題【問題1】該項目經理在制定進度計劃中有哪些錯誤？請計算相關活動時間的6個基本時間參數？ 錯誤 沒有表現出活動 G 的前置條件是B、C、D的完成 改正 增加虛活動 順推法確定最早開始、最早結束時間項目工期29天，逆推法確定最晚開始、最晚結束時間【問題2】項目經理于12天檢查時，活動D完成了一半的工作，活動E完成了2天的工作，以最早時間參數為準判斷D、E的進度是否正常？ 分析 1.由表中分析活動D最早完成時間應為9日 ，2.活動E最晚時間應為15日 結論 1.活動D已延期，還需2天 ，2.活動D實際完成（12+4/2）=14天完成，延期5天 3.活動E在第15天完成，實際（12+3）=15，進度正常【問題3】由于D、E、I使用同一臺設備施工，以最早時間參數為準，計算設備在現場的空閑時間？【解答】活動D、E、I的時間跨度分析如下，由于使用同一設備，完成活動所需時間累計為4+5+2=11天，三個活動最早開始與5（活動D），最早完成為25日（活動I）跨度20，因此設備閑置累計9天（20-11） 結論 1.活動D最早完成為第9天，E最早開始于第10天，設備閑置1天2.E最早完成為第15天，I在第23天開始，設備閑置8天【問題4】H工作由于工程師的變更指令，持續時間延長為14天，計算工期延遲天數 結論 1.活動H延長導致最早時間遞延變化，2.最終項目在30天完成3.整個項目延期1天（30-29）案例分析根據案例信息，編制項目工作分解結構（WBS）案例分析九：項目狀態分析項目背景某工程項目各個項目周期預算如表9-1第8周項目檢查點任務完成情況如表9-2第8周項目實際費用花費如表9-3案例問題【問題1】根據上述項目實際數據，計算該項目每期累計掙得值？掙得值BCWP=計劃工作量x預算定額由表9-1預算情況和表9-2實際工作完成情況可計算出各期掙得值，如表9-4【問題2】根據第8周檢查結果，預測該項目完成的總費用和進度情況。費用偏差 CV = BCWP ACWP = 54 68 = -14進度偏差 SV = BCWP BCWS = 54 64 = -10費用執行指標 CPI = BCWP/ACWP = 54 / 68 = 0.79進度執行指標 SPI = BCWP/BCWS = 54 / 64 = 0.84費用預測 預測值 = 總預算/CPI = 100/0.79 = 126.58進度預測 預計完成時間 = 計劃完成時間/SPI = 12/0.84 = 14.29案例分析十：甘特圖成本分析項目背景某小型項目有4項任務，圖10-1是這個項目進度安排的甘特圖，預算在藍色甘特圖右側第6周末項目檢查時各項任務完成情況如圖10-2所示，圖中紅色甘特圖是項目實際情況，各項任務的實際費用如圖中第2列數據所示 【問題1】根據第6周檢查所得信息，計算BCWS、BCWP、CV、SV，預測項目完成時的費用和進度？【解答1】計算結果如圖10-3所示成本和費用偏差： CV=BCWP-ACWP SV=BCWP-BCWS計算結果如圖10-3所示費用執行指標 CPI=BCWP/ACWP=285/300 = 0.95進度執行指標 SPI=BCWP/BCWS=285 /350 = 0.81費用預測 EAC預測值 = 總預算/CPI = 500/0.95 = 526預測值 = ACWP+（總預算-BCWP）/CPI = 300+(500-285) /0.95 = 526進度預測 預計完成時間 = 計劃完成時間/SPI = 9/0.81 = 11【問題2】用圖分析項目的成本情況，即繪制項目的預算費用曲線、實際費用曲線和掙值曲線。【解答2】首先，進行預算費用（Budg）按時間分攤其次，進行實際費用（ACWP）按時間分攤第三，進行掙得值（BCWP）按時間分攤得到圖10-4，據此繪制掙值曲線用圖分析項目的成本情況，即繪制項目的預算費用曲線、實際費用曲線和掙值曲線。案例案例分析十一：項目成本管理項目背景藍德公司決定開發一個保險管理系統（SMIS），該項目任務重、進度要求緊并且成本要求盡可能節省。該公司有著豐富的保險行業項目經驗，項目經理在完成系統分析后，預計該軟件規模約20萬行左右，計劃160天完成項目，平均每天完成1250行代碼，每天項目成本約2000元，為達到控制項目成本的目標，項目經理仔細記錄了項目組第一階段的工作情況項目團隊在對系統的設計開發過程中，花了10天進行部分系統的開發平均完成代碼設計1300行，按項目的設計成本，平均每天花費2100元案例問題【問題1】項目在前10天的PV、AC、EV值是多少？判斷該項目照此效率是否能按期完成？是否超出原先預算？【解答1】掙值分析的關鍵指標： PV=計劃工作量x預算定額 ，AC=持續時間x實際日成本 EV=已完成工作量x預算定額 ，CV=EV-AC，SV=EV-PVPV = 10天x2000元/天 = 20000元AC = 10天x2100元/天 = 21000元EV = 1.6元/行x1300行/天 = 20800元CV = 20800 21000 =-200元項目處于超支狀態SV = 20800 20000 = 800元項目進度提前與計劃進度【問題2】根據項目前10天的數據，畫出項目的掙值圖。根據前10天開工情況，計算項目完工時的總預算（假設后面的開發仍舊照此進度和花費），并說明原因。【解答2】由問題1計算得出結論，ACEVPV CPI=EV/ACCPI=20800/21000=99%EAC=AC+(BAC-EV)/CPI=21000+(1.6x200000-20800)/0.99=323077元【問題3】請簡述針對項目情況，應該采取何種措施既能保證進度計劃，又能保證成本預算？【解答3】因為存在ACEVPV，所以可以得出此項目第一階段開發中，效率不高（較低），進度較快，投入超前的結論應該采取的措施可以總結為：降低開發成本，稍微放緩開發進度，同時應保證項目質量采取抽調出部分開發人員來放緩開發進度，節省部分費用案例分析從案例來看，已收集數據為“規模”和“費用”數據，應從成本管理的角度分析問題掙值方法是對項目進度和成本進行綜合控制的一種方法，是測量項目績效、效率的常用方法掙值方法通過與計劃完成的工作量、實際掙得收益、實際的成本進行比較，可以確定成本、進度是否按計劃執行掙值分析有幾個關鍵值預算成本（PV）、實際成本（AC）、實現價值（EV）和完成尚需估算（ETC）掙值方法有四個評價指標成本偏差（CV）、進度偏差（SV）成本績效指數（CPI）、進度績效指數（SPI）使用掙值方法可以確定該項目開工情況（績效）案例分析十二：項目范圍與需求的質量管理項目背景X公司承接了B銀行軟件開發項目。該公司與B銀行以前有過長期的合作，此次項目是一個與證券業相關的新研發項目，沒用相同項目開發經驗，公司同意在沒有完全確定需求的情況下先進行開發，策略是希望在開發過程中不斷完善項目需求。公司為此項目配備的項目經理是張工，三個程序員參與項目開發，B銀行派技術人員趙工參與項目的需求分析和進度監督。項目開發初期比較順利，隨著項目的推進，漸漸暴露出一些問題1、項目需求的不確定性導致開發效率很低，比如一個界面上的小問題由于銀行技術人員趙工的不滿而導致開發進度停滯不前；2、由于公司項目組成員和銀行技術人員缺乏證券相關知識，導致對業務邏輯理解不一致，使得系統的幾個主要流程存在錯誤；類似質量問題不斷出現，導致最終項目嚴重延期，項目最終暫停案例問題【問題1】該公司和B銀行同意在不確定需求就投入研發，這種做法對軟件質量有什么影響？如果這種做法有一定客觀原因，如何在開發前期彌補？軟件項目的需求決定了項目的功能和目標，如果不能在項目開發進行前確定需求，就不能確定項目的目標目標不明確就沒法制定下一階段的工作計劃沒有明確的項目計劃就不能保證項目的質量項目質量管理也無從開展如果由于時間等其他客觀原因導致無法在軟件項目開發之前明確需求，可采取以下措施彌補將待定項目分解成幾個部分、階段開發之前分析、明確一部分需求，然后制定一個子工作計劃完成該部分需求的設計和開發繼續分析另一部分需求，然后相應制定另一個子工作計劃來實現通過保證分階段目標的項目質量來確保整體項目的目標和質量【問題2】該項目經理在事情中負有什么責任，如何履行他的責任？B銀行的趙工在事情中負有什么責任，如何履行他的責任？該項目經理不了解需求對于項目質量的