項目管理與案例分析分析題

1、.案例分析一：項目管理過程項目背景某市電子政務信息系統(tǒng)工程，總投資500 萬，主要包括網(wǎng)絡平臺建設和業(yè)務辦公應用系統(tǒng)開發(fā)，通過公開招標，確定工程的承建單位是A 公司，按照合同法的要求與A 公司簽訂了工程建設合同，并在合同中規(guī)定A 公司可以將機房工程這樣的非主題、非關鍵性子工程分包給具備相關資質(zhì)的專業(yè)公司B， B 公司將子工程轉手給了C 公司。在隨后的應用系統(tǒng)建設過程中，監(jiān)理工程師發(fā)現(xiàn)A 公司提交的需求規(guī)格說明書質(zhì)量較差，要求A 公司進行整改。此外，機房工程裝修不符合要求，要求A 公司進行整改。項目經(jīng)理小丁在接到監(jiān)理工程師的通知后，對于第二個問題拒絕了監(jiān)理工程師的要求，理由是機房工程由B 公司承

2、建，且 B 公司經(jīng)過了用戶方的認可，要求追究B 公司的責任，而不是追究自己公司的責任。對于第一個問題，小丁把任務分派給程序員老張進行修改，此時，系統(tǒng)的設計工作已經(jīng)開始，程序員老張獨自修改了已進入基線的程序，小丁默許了他的操作。老張在修改了需求規(guī)格說明書后采用郵件通知了系統(tǒng)設計人員。合同生效后，小丁開始進行項目計劃的編制，開始啟動項目。由于工程緊張，甲方要求提前完工，總經(jīng)理比較關心該項目，詢問項目的一些進展情況，在項目匯報會上，小丁向總經(jīng)理遞交了進度計劃，公司總經(jīng)理在閱讀進度計劃后，對項目經(jīng)理小丁指出任務之間的關聯(lián)關系不夠清晰，要求小丁重新更改一下計劃, 新的項目計劃出來了，在計劃實施過程中，由

3、于甲方的特殊要求，需要項目提前2 周完工，小丁又更改了項目進度計劃，項目最終按時完工。案例問題問題 1小丁在合同生效后進行的項目計劃編制工作應該如何進行？小丁在接到任務后開始項目計劃的編制工作，應包括：項目總計劃：范圍計劃、工作范圍定義、活動定義、資源需求、資源計劃、活動排序、費用估算、進度和費用計劃項目輔助計劃：質(zhì)量計劃、溝通計劃、人力資源計劃、風險計劃、采購計劃等問題 2小丁在處理監(jiān)理工程師提出的問題上處理是否正確？你作為項目經(jīng)理，應該如何處理？依據(jù)中華人民共和國招投標法第 48 條：中標人應當根據(jù)合同約定履行義務，完成中標項目。中標人不得向他人轉讓中標項目，也不得將中標項目肢解后分別向他

4、人轉讓。中標人按照合同約定或經(jīng)招標人同意，可以將中標項目的部分非主體、非關鍵性工作分包給他人完成。接受分包的人應具備相應的資格條件，并不得再次分包。本案例中， A 公司將子項工程分包給B， B 又將其分包給C，顯然違背了招標法第48 條規(guī)定“中標人應當就分包項目向招標人負責，接受分包的人就分包項目承擔連帶責任” ， A 公司顯然要承擔責任， B 公司也負連帶責任問題 3在項目執(zhí)行過程中，由于程序員老張獨自修改了以進入基線的程序，小丁默許了他的操作，小丁的處理方式是否正確？你作為項目經(jīng)理，應該如何處理？項目經(jīng)理小丁不應默許老張的行為，且修改后的東西沒有經(jīng)過評審。項目缺乏變更控制體系，同時，項目團

5、隊其他成員不清楚變更程序的步驟和要求。建立配置管理體系建立變更請求流程組建變更控制委員會CCB問題 4該案例中，項目管理的哪些方面需要改進？從項目管理9 大知識體系出發(fā)闡述改進方面；本項目管理交弱的方面是重點改進方向：項目經(jīng)理法律法規(guī)的理解（招投標管理）項目進度管理項目變更控制配置管理和計劃的變更將導致成本、質(zhì)量的變化案例分析二：項目變更控制.項目背景某軟件中心（ A 方）承擔了某大型上市公司（ B 方） ERP系統(tǒng)開發(fā)與實施項目。項目計劃確定后，在實施過程中，幾次發(fā)生計劃變更，原因如下：（ 1）證監(jiān)會要求上市公司執(zhí)行新的會計制度，需要修改ERP系統(tǒng)財務子系統(tǒng)；（ 2） B 方首付資金未能按時

6、支付，導致A 方開發(fā)計劃推遲；（ 3） A 方盲目確定進度目標，實際難以完成；（ 4） B 方因機構重組改變了業(yè)務流程，需要修改項目范圍；（ 5） A 方的前期設計有疏漏，需要修改設計方案；（ 6） B 方提出增加合同審計功能，需要修改項目范圍；（ 7）由于 B 方需求表達不清， A 方理解有誤，雙方溝通不夠，導致項目實施時發(fā)現(xiàn)需求偏差，需要糾偏；（ 8） B 方自行負責的機房工程延誤，影響了實施進度；（ 9） A 方開發(fā)人員跳槽，影響了開發(fā)進度；（ 10） B 方行業(yè)主管部門發(fā)布了新的行業(yè)ERP實施規(guī)范，需要修改項目實施方案。案例問題問題 1項目變更的內(nèi)部因素和外部因素分別指什么？由項目執(zhí)行

7、偏差導致項目計劃變更的各種誘發(fā)因素稱為項目變更的內(nèi)部因素。由項目目標變化導致項目計劃變更的各種誘發(fā)因素稱為項目變更的外部因素。問題 2上述 5 條變更，哪些屬于內(nèi)部因素？哪些屬于外部因素？（ 2）（ 3）（5）（ 7）（8）（ 9）屬于項目變更的內(nèi)部因素；（ 1）（ 4）（6）（ 10）屬于項目變更的外部因素問題 3由于內(nèi)部因素導致變更，從而可能增加建設經(jīng)費？是否一定要由承建方承擔？（ 3）（ 5）（9）屬于 A 方責任，由此增加的項目費用由A 方承擔；（ 7）屬于雙發(fā)責任， A、 B 雙方協(xié)商分攤；其余各條，無論B 方是否負有責任，均應承擔由此增加的項目費用。問題 4對于由于內(nèi)部因素和外部因

8、素引發(fā)的變更請求，變更評估的重點有何不同？對于由內(nèi)部因素引起的變更請求，變更評估的重點是確定最優(yōu)變更方案；對于由外部因素引起的變更請求，應重點評估變更的必要性。案例一：范圍定義項目背景黎明信息技術有限公司原本是一家專著于企業(yè)信息化的公司，在電子政務如火如荼的時候，開始進軍電子政務行業(yè)。在電子政務的市場中，承接的第一個項目是開發(fā)一套工商審批系統(tǒng)。由于電子政務保密要求（國家要求），該系統(tǒng)涉及到兩個互不聯(lián)通的子網(wǎng)：政務內(nèi)網(wǎng)和政務外網(wǎng)。政務內(nèi)網(wǎng)中儲存著全部信息，其中包含部分機密信息；政務外網(wǎng)可以對公眾開放，開放的信息必須得到授權。系統(tǒng)要求在這兩個子網(wǎng)中的合法用戶都可以訪問到被授權的信息，訪問的信息必須

9、一致可靠，政務內(nèi)網(wǎng)的信息可以發(fā)布到政務外網(wǎng)，政務外網(wǎng)的信息在經(jīng)過審批后可以進入政務內(nèi)網(wǎng)系統(tǒng)。丁偉是該項目的項目經(jīng)理，在捕獲到這個需求后認為電子政務項目建設和企業(yè)MIS 項目有很大不同，有其特殊性，若照搬企業(yè)信息化項目原有的經(jīng)驗和方法必定失敗。丁偉在該項目中采用了嚴格的瀑布模型，并專門招聘了熟悉網(wǎng)絡互聯(lián)互通的技術人員參與設計了解決方案，在經(jīng)過嚴格評審后開始實施項目。在項目交付時，雖然系統(tǒng)完全滿足了項目保密性要求，但用戶對系統(tǒng)用戶界面提出了較大異議，認為不符合政務信.息系統(tǒng)的要求和風格，操作也不夠便捷，要求徹底更換。由于最初設計的缺陷，系統(tǒng)表現(xiàn)層和邏輯層緊密耦合，導致70%的代碼重寫，而第二版的用

10、戶界面仍然沒有達到用戶的要求，最終又重寫了部分代碼才勉強通過用戶驗收。由于整個項目反復變更，項目組成員產(chǎn)生了強烈的挫折感，士氣低落，項目工期也必原先的計劃超出一倍，項目成本超出預算的100%，項目用戶滿意度較低。該項目最終的結果與公司的期望偏差很大，黎明公司決定暫時放棄進軍電子政務市場，并要求相應的事業(yè)部進行業(yè)務轉型，大幅度裁員，骨干技術人員流失嚴重！問題 1如何評估丁偉的項目管理行為？1. 注意到了系統(tǒng)運行環(huán)境的特殊性，在良好設計和實現(xiàn)的情況下滿足了用戶要求2. 忽略了系統(tǒng)用戶的潛在要求，在用戶界面和操作風格上范圍定義不清，造成項目交付時產(chǎn)生重大變更3. 第一次問題發(fā)生后仍沒有對范圍進行有效

11、管理，造成項目第二次變更4. 沒有對用戶界面是否能夠滿足要求的風險進行有效的管理，而采用抗風險較弱的瀑布模型組織開發(fā)5. 沒有對設計的質(zhì)量進行有效控制，造成表現(xiàn)層和業(yè)務邏輯層緊密耦合，直接導致增加了變更代價問題 2從項目范圍管理的角度找出項目實施過程中的管理問題？1. 沒有挖掘到系統(tǒng)的全部隱形需求，缺乏精確的范圍定義2. 當發(fā)生第一次變更時，丁偉仍沒有進行有效的范圍管理，直接造成項目的第二次變更3. 重復的系統(tǒng)變更說明丁偉對項目范圍控制不足，導致項目范圍接二連三的變更、反復問題 3從范圍管理的角度出發(fā)，如何避免類似問題的發(fā)生？有效的范圍管理包括了從范圍定義到范圍控制等眾多方面的工作，每一項工作

12、都是重要的1. 結合行業(yè)特點進行需求分析充分挖掘系統(tǒng)隱形需求2. 通過原型法來驗證需求的定義，避免范圍定義不清的問題3. 在發(fā)生需求變更時應進行有效的需求控制，在滿足用戶需求前提下縮小需求范圍，避免需求再次變更案例點評這是一個失敗的項目，丁偉在項目管理過程中既有閃光的地方，也要失敗的地方；項目范圍管理的失誤是造成失敗的關鍵原因: 模糊的范圍定義錯誤的工作分解缺失的范圍確認無力的范圍控制也暴露出風險管理、系統(tǒng)設計方面的問題案例分析丁偉對項目范圍有一定把握（閃光點）發(fā)現(xiàn)了不同行業(yè)間具有不同的特點捕獲到了政務內(nèi)、外網(wǎng)的需求，并進行了定義，嚴格控制了這一需求的設計和實現(xiàn)如果忽視這一行業(yè)標準，項目將招致

13、更大的失敗丁偉對于像用戶界面的風格和操作便捷性的需求沒有充分考慮，導致一而再，再而三的變更沒有意識到系統(tǒng)“隱形需求”的重要性行業(yè)特點決定范圍約束（用戶界面、操作便捷性）丁偉對項目范圍和需求的定義理解并不完整電子政務行業(yè)特點，使對項目范圍定義更加困難最終用戶不參加需求和開發(fā)工作需求的間接性丁偉在范圍確認和范圍控制方面存在失誤第一次變更就應該充分認識界面、操作的重要性.應該立即采取措施清晰的定義界面風格、操作風格丁偉沒有進行充分的風險管理隱形行規(guī)和行業(yè)特點意味著項目范圍定義的風險采用瀑布模型增加了風險發(fā)生后帶來的損失這個案例中，缺乏良好的設計也是明顯的缺陷用戶界面中耦合了大量的業(yè)務邏輯，增加了變更

14、代價總結語項目的閃光點在于對項目運行環(huán)境進行了清晰的定義，并最終滿足了用戶的要求不充分的范圍定義和范圍確認導致了項目的失敗采用抗風險較弱的瀑布模型和低質(zhì)量的設計增加了項目范圍變更得代價案例二：范圍管理工作要點項目背景A 集團是黎明信息技術有限公司的多年客戶，黎明公司已經(jīng)為其開發(fā)了多個信息系統(tǒng)，最近A 集團又和公司簽訂了新的開發(fā)合同，以擴充整個企業(yè)信息系統(tǒng)的業(yè)務范圍；張凡被任命為該項目的項目經(jīng)理。項目經(jīng)理張凡組織相關人員對該項目的工作進行了分解，并參考了黎明公司和A集團曾經(jīng)合作的項目，評估得到項目總工作量為60 人月，計劃工期為6 個月。項目剛剛開始不久， 張凡的高層經(jīng)理孫總找到張凡， 孫總表示

15、由于公司運作的需要， 要求張凡在 4 個月內(nèi)完成項目，考慮到壓縮工期的現(xiàn)實，可以為該項目增派兩名開發(fā)人員。張凡認為，整個項目的工作量是經(jīng)過仔細分解后評估得到的，評估過程也參考了歷史上與A 集團合作的項目度量數(shù)據(jù)，該工作量是客觀現(xiàn)實的。目前項目已經(jīng)開始，增派新的開發(fā)人員還需要一定時間的熟悉，因此即使增派兩人也很難在四個月內(nèi)完成項目，如果強行要求項目組成員通過加班加點方式追逐4 個月完成項目的目標，肯定會降低項目的質(zhì)量，造成用戶的不滿。對此，張凡提出的解決方案是：將整個項目分成兩部分實現(xiàn)，第一部分使用三個半月的時間，第二部分使用三個月的時間，分別制定出兩部分的驗收標準，這樣不增派開發(fā)人員也能完成項

16、目。高層經(jīng)理孫總認為該方案可以滿足公司運作的要求，用戶也同意按照這種方案進行實施。六個半月以后，項目在沒有增加人員投入的情況下順利完成，雖然整個項目比最初的計劃延長了半個月，但既達到了公司的要求，客戶對交付的系統(tǒng)也比較滿意，項目成員也沒有感受到很大的壓力。問題 1點評張凡是如何應對項目范圍變更的，采取了哪些措施？1. 首先對最初的項目范圍進行了清晰的定義，并根據(jù)定義對項目任務進行了分解，制定了WBS2. 對項目進行了估算，且估算結果真實可信，對項目工作量有量化的把握3. 在出現(xiàn)新的項目目標后，對項目范圍進行了控制，縮小了第一階段實現(xiàn)的項目范圍4. 對重新定義的項目范圍進行了確認，與高層經(jīng)理和客

17、戶達成了一致5. 對項目進行了溝通管理，協(xié)調(diào)了多個項目關系人之間的矛盾問題 2結合案例指出項目范圍管理的工作要點？1. 制定范圍管理計劃2. 進行項目范圍定義3. 項目工作分解 WBS4. 進行項目范圍確認5. 對項目范圍進行控制本案例中，張凡首先進行了范圍定義和工作分解，得到清晰的項目范圍；在出現(xiàn)新的項目目標后，張凡進行了范圍控制，重新定義了兩個階段的項目范圍；最后，將重新定義的范圍與項目干系人進行了確認案例點評1. 這是一個成功的項目管理案例，項目經(jīng)理張凡有效的運用范圍管理手段，在不同項目干系人中達成一致，使項目的結果同時滿足了公司高層經(jīng)理、客戶、項目組成員的要求。.2. 作為一個項目經(jīng)理

18、，必須熟練掌握和應用項目管理九大知識領域的技能，對于信息系統(tǒng)開發(fā)項目而言，范圍管理是其中最重要的技能之一。3. 軟件項目的范圍主要是由系統(tǒng)需求構成的，而系統(tǒng)需求既是難以把握的，也是容易調(diào)整和控制的(1) 在滿足項目目標前提下，可以定義出不同的系統(tǒng)需求(2) 根據(jù)經(jīng)驗，軟件項目管理總是從范圍管理開始，先定義系統(tǒng)的邊界，然后再在明確的范圍內(nèi)進行時間、成本、質(zhì)量和風險的管理(3) 范圍、時間、成本、質(zhì)量之間的邏輯關系是項目管理的客觀規(guī)律(4) 當范圍因素已經(jīng)確定的條件下，不妨根據(jù)時間、資源（成本）的重新計劃來調(diào)整合理的項目范圍4. 軟件項目的范圍變更應重新進行項目計劃的調(diào)整將項目分解成兩部分，實際上

19、項目范圍已經(jīng)被擴大了范圍變化導致任務、任務之間的邏輯關系的重新調(diào)整需要考慮分割項目的驗收標準，這是與用戶達成一致的前提5. 范圍控制并非總是針對客戶的要求而進行的控制項目范圍控制需求，這個公式是錯誤的設計策略是項目經(jīng)理可以把握的（夠用策略、犧牲質(zhì)量特性策略、過度設計）即使需求已經(jīng)確定，有效的范圍管理仍能給項目帶來巨大收益范圍管理的空間很大，帶來的收益是降低成本、縮短工期6. 案例中，張凡還運用了其他范圍管理手段項目剛開始，對項目范圍進行了定義劃分了項目WBS，并對項目進行了估算、計劃在孫總提出縮短工期的要求后，首先進行了范圍控制，縮小了第一步需要完成的項目范圍，接著又對兩階段需要完成的項目范圍

20、進行了重新定義制定了兩階段驗收標準對重新定義的范圍進行了確認，與客戶、高層經(jīng)理達成一致7. 總結語張凡在范圍管理方面進行全面的控制，此外也運用了其他項目管理手段，包括對項目估算計劃（時間管理），協(xié)調(diào)多個項目干系人之間的矛盾（溝通管理）案例三：范圍確認黎明信息技術有限公司和M企業(yè)簽訂了一份合同，合同的主要內(nèi)容是處理黎明公司以前為M公司開發(fā)的信息系統(tǒng)的升級工作。升級后的信息系統(tǒng)可以滿足M 公司新的業(yè)務流程和范圍；王強被任命為該項目的項目經(jīng)理, 由于該項目是一個現(xiàn)有系統(tǒng)的升級項目，王強特意請來了原系統(tǒng)的需求調(diào)研人員李偉擔任該項目的需求調(diào)研負責人。在李偉的幫助下，很快完成了需求分析的工作，并進入設計和

21、編碼，由于M公司的業(yè)務非常繁忙，M公司的業(yè)務代表沒有足夠時間投入到項目中，確認需求的工作一拖在拖。王強認為雙方已經(jīng)建立了密切合作的關系，李偉也已經(jīng)參加了原系統(tǒng)的需求開發(fā)工作，對M 公司的業(yè)務比較熟悉，因此定義的需求是清晰的，故王強并沒有催促業(yè)務代表在需求說明書中簽字。進入編碼階段后，李偉因故移民加拿大，需要離開項目組，王強考慮到系統(tǒng)需求已經(jīng)定義，項目也進入編碼階段，李偉的離職雖然會對項目造成一定影響，但影響較小，因此很快為其辦好離職手續(xù)。在系統(tǒng)交付的時候，M公司的業(yè)務代表認為甲方已經(jīng)提出的需求很多沒有實現(xiàn)，實現(xiàn)的需求也有很多不能滿足M公司現(xiàn)有的業(yè)務要求，必須全部實現(xiàn)這些需求后才能驗收。此時，李

22、偉已經(jīng)離開項目組，沒有人能夠清晰地解釋乙方已經(jīng)完成的需求說明書。最終系統(tǒng)需求發(fā)生重大變更，項目延期超過 50%，M的業(yè)務代表也因為系統(tǒng)的延期表示了強烈的不滿。案例問題問題 1對王強在項目管理工作中的行為進行點評。1. 王強為了更明確地把握系統(tǒng)需求，聘請了原系統(tǒng)需求調(diào)研人員李偉，提高了需求定義的效率和質(zhì)量；2. 王強沒有對李偉提供的系統(tǒng)需求進行評審核復查，從而使需求的缺陷沒有被及時發(fā)現(xiàn)；.3. 王強沒有要求用戶對已經(jīng)定義的需求進行確認，從而導致需求理解的偏差；4. 王強對需求缺乏有效控制，最終導致項目延期50%問題 2從項目范圍管理的角度找出項目實施過程中的管理問題？項目實施過程中的主要問題包括

23、：1. 在范圍定義過程中，王強沒有對李偉定義的需求進行評審，造成需求中的質(zhì)量缺陷沒有被及時發(fā)現(xiàn)；2. 在范圍確認過程中，王強沒有主動要求用戶對需求進行確認；3. 在范圍控制過程中，王強無法進行有效的范圍控制，最終造成了重大的需求變更。問題 3從范圍管理的角度出發(fā)，如何避免類似問題的發(fā)生？本案例說明項目范圍管理中應采取以下規(guī)避措施：1. 項目經(jīng)理需要對需求定義的結果進行質(zhì)量控制，采取評審等方式減少需求定義中存在的缺陷；2. 對已經(jīng)定義的需求要及時與用戶進行確認，保證雙方理解的一致；3. 在發(fā)生需求變更時，應采取靈活手段，在滿足用戶需求的前提下，盡量減少需求變更得范圍。案例點評1. 這是一個失敗的

24、項目，和很多失敗的軟件項目一樣，王強在項目范圍（或軟件需求）方面栽了跟頭；項目經(jīng)理王強即重視需求，又沒有控制好需求的案例開發(fā)和定義軟件系統(tǒng)的需求是整個項目過程的關鍵管理項目范圍是常識，但往往因為一時的疏忽而造成需求的重大缺陷2. 項目實施過程經(jīng)歷了波折，但未引起重視，最終失??！項目開局：充滿光明項目中期：出現(xiàn)烏云項目交付：下雨了3. 王強在項目管理中成功的方面找到合適的資源進行需求的定義可以快速準確地把握新系統(tǒng)的需求4. 王強在范圍確認和范圍控制方面存在失誤認為緊逼客戶確認需求不近人情，抱著僥幸心里進入開發(fā)階段未履行需求評審和確認過程，造成缺陷未及時發(fā)現(xiàn)需求控制失去基準，導致重大變更5. 從項

25、目管理的角度分析，項目范圍直接決定了工作量和工作目標，項目范圍管理中的關系范圍定義：管理的基礎范圍確認：基線化已定義的范圍范圍控制：減少變更，保持范圍的穩(wěn)定6. 項目范圍確認的方法客戶代表確認需求說明書（需求報告）召集客戶的業(yè)務骨干對需求進行評審詳細記錄原始的調(diào)研材料，讓客戶確認調(diào)研報告迭代開發(fā)逐步確認需求案例分析五：項目工程網(wǎng)絡圖的繪制項目背景某化工廠擬進行管道安裝工程，工程進度如下表所示，繪制該項目的工程網(wǎng)絡圖。.繪制雙代號網(wǎng)路圖步驟第 1：從起始活動開始，畫出第一個活動的緊后工作畫出 A 活動和其緊后活動，即 B 、 C、E、 F圖2圖1第 2：從左到右依次找出緊后活動找出 B 、 C、

26、 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完成初步工程網(wǎng)絡圖該項目的單代號網(wǎng)路圖.案例

27、分析六：網(wǎng)絡圖時間參數(shù)及關鍵路徑確定項目背景某公司弱電布線工程項目，雙代號工程網(wǎng)絡圖如下所示，確定該項目關鍵路徑。一般網(wǎng)絡時間計算第 1：計算工作最早時間ES、 EF第一個活動ES=0ES = max 緊前工作的EFEF = ES +工作延續(xù)時間(t)第 2：計算工作最遲時間LS、 LF最后一個活動LF(n) = EF(n)LF = min緊后工作的LSLS = LF -工作延續(xù)時間(t).第 3：計算總時差TF總時差是指不影響整個項目最早完成時間的前提下，一項工作的完工期可推遲的時間TF=LFEF 或者 TF=LS ES第 4：計算自由時差FF自由時差是指不影響緊后工作的最早開始時間的前提下

28、，一項工作的完工期可推遲的時間FF = minES(緊后工作 ) EF確定關鍵路徑案例分析七：軟件項目的時間管理和成本管理項目背景小張為藍德公司技術總監(jiān)，最近接到公司任務，負責開發(fā)一個電子商務平臺，由于公司業(yè)務發(fā)展需要，公司總裁急于啟動電子商務平臺項目，要求小張盡快準備關于啟動電子商務平臺的立項報告小張粗略估算該項目正常速度下的時間和成本在第一次項目策劃會議上，項目團隊確定了與項目相關的任務在第一次項目策劃會議上，項目團隊確定了與項目相關的任務，具體任務情況如下.第一項任務：調(diào)研現(xiàn)有的電子商務平臺按正常速度估算完成該任務需10 天，成本 15000 元允許最多加班情況下，需要7 天，成本 18

29、750 元第二項任務：制定項目計劃并提交管理層評審估計正常情況下需要5 天，成本約3750 元加班趕工時可在3 天完成，成本為4500 元第三項任務：需求分析、系統(tǒng)設計歷史估計為 15天，成本45000 元加班時約需 10天，成本58500 元設計完成后，有三項工作必須同時進行開發(fā)電子商務后臺數(shù)據(jù)庫在不加班情況下估計需10 天，成本9000 元加班情況下估計僅需要7 天，成本11250 元開發(fā)和編碼前臺網(wǎng)頁腳本項目團隊估計可在10 天完成，成本17500 元如果允許加班可縮短2 天時間，成本 19500 元電子表單控件設計與開發(fā)采用外包方式進行，需要7 天，外包成本 8400 元沒有加班趕工方

30、案整個電子商務平臺集成、測試約3 天，成本 4500 元，如果允許加班可節(jié)省1 天，成本6750 元案例問題【問題 1】如果不加班，完成此項目的成本和時間是多少？考慮加班，項目可以完成的最短時間和最短時間內(nèi)完成項目的成本是多少？【解答】需要進行關鍵路徑的計算，根據(jù)關鍵路徑法（CPM）注意：最短完成時間路徑并不是加班情況下的最短路徑，而是最長路徑- 關鍵路徑關鍵路徑： 累計關鍵路徑工期，完成項目需43 天，累計成本即項目成本約103,150元累計關鍵路徑中加班后的最短時間，為30天，成本為 127,650元【問題 2】假定調(diào)研其他電子商務平臺的任務需要13天而不是原先估算的10 天，項目經(jīng)理小張

31、應采取什么行動來保持項目按正常速度進行且增加的成本最少？【解答】由于調(diào)研電子商務平臺活動在關鍵路徑上，導致整個項目工期延長3 天，因此應考慮加班趕工來保證整個項目進度，為保證項目進度，需趕工3 天趕工原則是“優(yōu)先考慮趕工費率最低的工作”.根據(jù)趕工費率分析，活動和費率最低活動只有 2 天可趕工時間，還差 1 天但選擇活動趕工1 天將導致也需趕工1 天活動趕工1 天的實際趕工費率是1,750 元因此，應選擇趕工1 天，費率是1,250 元【答案】選擇趕工1 天，趕工2 天，此方案增加的成本是2,000 元（ =1250+275*2 ）【問題 3】假定老總想在35 天內(nèi)完成項目，項目經(jīng)理應采取什么措

32、施達到預期要求？在 35 天完成項目將花費的成本是多少？【解答】顯然需要在制定趕工調(diào)整方案，但必須考慮關鍵路徑上活動的變化導致其他非關鍵路徑的變化情況，關鍵路徑上的工期： 10+5+15+10+3=43 天關鍵路徑上正常工期43 天，需趕工8 天（ =43-35 ）根據(jù)趕工費率分析，趕工方案為趕工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元案

33、例分析活動排序、編號.繪制工程網(wǎng)絡圖案例分析八：活動排序和進度控制項目背景藍德公司承擔一項網(wǎng)絡工程項目的實施，公司系統(tǒng)集成工程師小丁接到任務后分析了項目任務，并開始進行活動手工排序小丁分析出活動 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，所需時間分

34、別為2 天、 5 天。完成活動J 所需時間為4 天，只有當活動G和 I完成后才能進行。項目經(jīng)理據(jù)此畫出工程施工進度網(wǎng)絡圖案例問題【問題 1】該項目經(jīng)理在制定進度計劃中有哪些錯誤？請計算相關活動時間的6 個基本時間參數(shù)？ 錯誤 沒有表現(xiàn)出活動G 的前置條件是 B、 C、 D 的完成 改正 增加虛活動順推法確定最早開始、最早結束時間.項目工期29 天，逆推法確定最晚開始、最晚結束時間【問題 2】項目經(jīng)理于 12 天檢查時，活動 D完成了一半的工作，活動 E 完成了 2 天的工作，以最早時間參數(shù)為準判斷 D、 E 的進度是否正常？分析 1. 由表中分析活動 D 最早完成時間應為 9 日， 2. 活動

35、 E 最晚時間應為15 日結論 1. 活動 D 已延期，還需2 天， 2. 活動 D實際完成（ 12+4/2 ）=14 天完成，延期 5 天3.活動 E 在第 15 天完成，實際（12+3） =15，進度正常【問題 3】由于 D、 E、 I 使用同一臺設備施工，以最早時間參數(shù)為準，計算設備在現(xiàn)場的空閑時間？【解答】活動 D、 E、 I 的時間跨度分析如下，由于使用同一設備，完成活動所需時間累計為4+5+2=11 天，三個活動最早開始與 5（活動 D），最早完成為 25 日（活動 I ）跨度 20，因此設備閑置累計9 天（ 20-11 ）結論 1. 活動 D 最早完成為第9 天， E 最早開始于

36、第 10 天，設備閑置1 天.2.E 最早完成為第15 天， I 在第 23 天開始，設備閑置8 天【問題 4】H工作由于工程師的變更指令，持續(xù)時間延長為14 天，計算工期延遲天數(shù)結論 1.活動 H 延長導致最早時間遞延變化，2. 最終項目在30 天完成3. 整個項目延期 1 天（ 30-29 ）案例分析根據(jù)案例信息，編制項目工作分解結構（WBS）案例分析九：項目狀態(tài)分析項目背景某工程項目各個項目周期預算如表9-1第 8周項目檢查點任務完成情況如表9-2第 8周項目實際費用花費如表 9-3.案例問題【問題 1】根據(jù)上述項目實際數(shù)據(jù)，計算該項目每期累計掙得值？掙得值 BCWP=計劃工作量x 預算

37、定額由表 9-1 預算情況和表9-2 實際工作完成情況可計算出各期掙得值，如表9-4【問題 2】根據(jù)第 8 周檢查結果，預測該項目完成的總費用和進度情況。費用偏差CV = BCWP ACWP = 54 68 = -14進度偏差SV = BCWP BCWS = 54 64 = -10費用執(zhí)行指標CPI = BCWP/ACWP = 54 / 68 = 0.79進度執(zhí)行指標SPI = BCWP/BCWS = 54 / 64 = 0.84費用預測預測值=總預算 /CPI = 100/0.79 = 126.58進度預測預計完成時間= 計劃完成時間/SPI = 12/0.84 = 14.29案例分析十：甘

38、特圖成本分析項目背景某小型項目有4 項任務，圖10-1 是這個項目進度安排的甘特圖，預算在藍色甘特圖右側第 6 周末項目檢查時各項任務完成情況如圖 10-2 所示，圖中紅色甘特圖是項目實際情況，各項任務的實際費用如圖中第 2 列數(shù)據(jù)所示.【問題 1】根據(jù)第 6 周檢查所得信息，計算BCWS、 BCWP、 CV、 SV，預測項目完成時的費用和進度？【解答 1】計算結果如圖10-3 所示成本和費用偏差：CV=BCWP-ACWPSV=BCWP-BCWS計算結果如圖10-3 所示費用執(zhí)行指標CPI=BCWP/ACWP=285/300 = 0.95進度執(zhí)行指標SPI=BCWP/BCWS=285 /350

39、 = 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 ，據(jù)此繪制掙值曲線用圖分析項目的成本情況，即繪制項目的預算費用曲線、實際費用曲線和掙值曲線。案例

40、 案例分析十一：項目成本管理項目背景藍德公司決定開發(fā)一個保險管理系統(tǒng)（SMIS），該項目任務重、進度要求緊并且成本要求盡可能節(jié)省。該公司有著豐富的保險行業(yè)項目經(jīng)驗，項目經(jīng)理在完成系統(tǒng)分析后，預計該軟件規(guī)模約20 萬行左右，計劃160 天完成項目，平均每天完成1250 行代碼，每天項目成本約2000 元，為達到控制項目成本的目標，項目經(jīng)理仔細記錄了項目組第一階段的工作情況項目團隊在對系統(tǒng)的設計開發(fā)過程中，花了10 天進行部分系統(tǒng)的開發(fā)平均完成代碼設計1300 行，按項目的設計成本，平均每天花費2100 元案例問題【問題 1】項目在前 10 天的 PV、 AC、 EV值是多少？判斷該項目照此效率是

41、否能按期完成？是否超出原先預算？【解答 1】掙值分析的關鍵指標：PV=計劃工作量 x 預算定額， AC=持續(xù)時間 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元.項目處于超支狀態(tài)SV = 2080020000 = 800元項目進度提前與計劃進度【問題 2】根據(jù)項目前10 天的數(shù)據(jù)，畫出項目的掙值圖。根據(jù)前10 天開工情況，計算項目完工時的總預算（假設后面的開

42、發(fā)仍舊照此進度和花費） ，并說明原因?！窘獯?2】由問題 1 計算得出結論，AC>EV>PVCPI=EV/ACCPI=20800/21000=99%EAC=AC+(BAC-EV)/CPI=21000+(1.6x200000-20800)/0.99=323077元【問題 3】請簡述針對項目情況，應該采取何種措施既能保證進度計劃，又能保證成本預算？【解答 3】因為存在AC>EV>PV，所以可以得出此項目第一階段開發(fā)中，效率不高（較低） ，進度較快，投入超前的結論應該采取的措施可以總結為：降低開發(fā)成本，稍微放緩開發(fā)進度，同時應保證項目質(zhì)量采取抽調(diào)出部分開發(fā)人員來放緩開發(fā)進度，

43、節(jié)省部分費用案例分析從案例來看，已收集數(shù)據(jù)為“規(guī)?！焙汀百M用”數(shù)據(jù)，應從成本管理的角度分析問題掙值方法 是對項目進度和成本進行綜合控制的一種方法，是測量項目績效、效率的常用方法掙值方法 通過與計劃完成的工作量、實際掙得收益、實際的成本進行比較，可以確定成本、進度是否按計劃執(zhí)行掙值分析有幾個關鍵值預算成本（ PV）、實際成本（ AC）、實現(xiàn)價值（EV）和完成尚需估算（ETC）掙值方法有四個評價指標成本偏差（ CV）、進度偏差（ SV）成本績效指數(shù)（CPI）、進度績效指數(shù)（SPI）使用掙值方法可以確定該項目開工情況（績效）案例分析十二：項目范圍與需求的質(zhì)量管理項目背景X 公司承接了B 銀行軟件開發(fā)

44、項目。該公司與B 銀行以前有過長期的合作，此次項目是一個與證券業(yè)相關的新研發(fā)項目，沒用相同項目開發(fā)經(jīng)驗，公司同意在沒有完全確定需求的情況下先進行開發(fā)，策略是希望在開發(fā)過程中不斷完善項目需求。公司為此項目配備的項目經(jīng)理是張工，三個程序員參與項目開發(fā)， B 銀行派技術人員趙工參與項目的需求分析和進度監(jiān)督。項目開發(fā)初期比較順利，隨著項目的推進，漸漸暴露出一些問題1、項目需求的不確定性導致開發(fā)效率很低，比如一個界面上的小問題由于銀行技術人員趙工的不滿而導致開發(fā)進度停滯不前；.2、由于公司項目組成員和銀行技術人員缺乏證券相關知識，導致對業(yè)務邏輯理解不一致，使得系統(tǒng)的幾個主要流程存在錯誤；類似質(zhì)量問題不斷出現(xiàn)，導致最終項目嚴重延期，項目最終暫停案例問題【問題 1】該公司和B 銀行同意在不確定需求就投入研發(fā)，這種做法對軟件質(zhì)量有什么影響？如果這種做法有一定客觀原因，如何在開發(fā)前期彌補？軟件項目的需求決定了項目的功能和目標，如果不能在項目開發(fā)進行前確定需求，就不能確定項目的目標目標不明確就沒法制定下一階段的工作計劃沒有明確的項目計劃就不能保證項目的質(zhì)量項目質(zhì)量管理也無從開展如果由于時間等其他客觀原因?qū)е?/p>