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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

17、協(xié)調(diào)了多個項目關(guān)系人之間的矛盾問題 2結(jié)合案例指出項目范圍管理的工作要點(diǎn)？1.制定范圍管理計劃2.進(jìn)行項目范圍定義3.項目工作分解 WBS4.進(jìn)行項目范圍確認(rèn)5.對項目范圍進(jìn)行控制本案例中，張凡首先進(jìn)行了范圍定義和工作分解，得到清晰的項目范圍；在出現(xiàn)新的項目目標(biāo)后，張凡進(jìn)行了范圍控制，重新定義了兩個階段的項目范圍；最后，將重新定義的范圍與項目干系人進(jìn)行了確認(rèn)案例點(diǎn)評1.這是一個成功的項目管理案例，項目經(jīng)理張凡有效的運(yùn)用范圍管理手段，在不同項目干系人中達(dá)成一致，使項目的結(jié)果同時滿足了公司高層經(jīng)理、客戶、項目組成員的要求。2.作為一個項目經(jīng)理，必須熟練掌握和應(yīng)用項目管理九大知識領(lǐng)域的技能，對于信息

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

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

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

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

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

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

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

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

26、的緊后活動是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)絡(luò)圖該項目的單代號網(wǎng)路圖案例分析六：網(wǎng)絡(luò)圖時間參數(shù)及關(guān)鍵路徑確定項目背景某公司弱電布線工程項目，雙代號工程網(wǎng)絡(luò)圖如下所

27、示，確定該項目關(guān)鍵路徑。一般網(wǎng)絡(luò)時間計算第 1：計算工作最早時間 ES、EF第一個活動 ES=0ES = max緊前工作的 EF EF = ES +工作延續(xù)時間 (t)第 2：計算工作最遲時間 LS、LF最后一個活動 LF(n) = EF(n) LF = min緊后工作的 LS LS = LF -工作延續(xù)時間 (t)第 3：計算總時差 TF總時差是指不影響整個項目最早完成時間的前提下，一項工作的完工期可推遲的時間TF = LF EF 或者 TF = LS ES第 4：計算自由時差 FF自由時差是指不影響緊后工作的最早開始時間的前提下，一項工作的完工期可推遲的時間FF = minES(緊后工作

28、) EF確定關(guān)鍵路徑案例分析七：軟件項目的時間管理和成本管理項目背景小張為藍(lán)德公司技術(shù)總監(jiān)，最近接到公司任務(wù)，負(fù)責(zé)開發(fā)一個電子商務(wù)平臺，由于公司業(yè)務(wù)發(fā)展需要，公司總裁急于啟動電子商務(wù)平臺項目，要求小張盡快準(zhǔn)備關(guān)于啟動電子商務(wù)平臺的立項報告小張粗略估算該項目正常速度下的時間和成本在第一次項目策劃會議上，項目團(tuán)隊確定了與項目相關(guān)的任務(wù)在第一次項目策劃會議上，項目團(tuán)隊確定了與項目相關(guān)的任務(wù)，具體任務(wù)情況如下第一項任務(wù)：調(diào)研現(xiàn)有的電子商務(wù)平臺按正常速度估算完成該任務(wù)需10 天，成本 15000 元允許最多加班情況下，需要7 天，成本 18750 元第二項任務(wù)：制定項目計劃并提交管理層評審估計正常情況下

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

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

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

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

33、0元案例分析活動排序、編號繪制工程網(wǎng)絡(luò)圖案例分析八：活動排序和進(jìn)度控制項目背景藍(lán)德公司承擔(dān)一項網(wǎng)絡(luò)工程項目的實(shí)施，公司系統(tǒng)集成工程師小丁接到任務(wù)后分析了項目任務(wù)，并開始進(jìn)行活動手工排序小丁分析出活動 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完成后才能開始活

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

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

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

37、得值 BCWP=計劃工作量 x 預(yù)算定額由表 9-1 預(yù)算情況和表 9-2 實(shí)際工作完成情況可計算出各期掙得值，如表 9-4 【問題 2】根據(jù)第 8 周檢查結(jié)果，預(yù)測該項目完成的總費(fèi)用和進(jìn)度情況。費(fèi)用偏差 CV = BCWP ACWP = 54 68 = -14 進(jìn)度偏差 SV = BCWP BCWS = 54 64 = -10 費(fèi)用執(zhí)行指標(biāo) CPI = BCWP/ACWP = 54 / 68 = 0.79 進(jìn)度執(zhí)行指標(biāo) SPI = BCWP/BCWS = 54 / 64 = 0.84 費(fèi)用預(yù)測 預(yù)測值 = 總預(yù)算 /CPI = 100/0.79 = 126.58 進(jìn)度預(yù)測預(yù)計完成時間= 計劃

38、完成時間 /SPI = 12/0.84 = 14.29案例分析十：甘特圖成本分析項目背景某小型項目有 4 項任務(wù)，圖 10-1 是這個項目進(jìn)度安排的甘特圖，預(yù)算在藍(lán)色甘特圖右側(cè)第 6 周末項目檢查時各項任務(wù)完成情況如圖 10-2 所示，圖中紅色甘特圖是項目實(shí)際情況，各項任務(wù)的實(shí)際費(fèi)用如圖中第 2 列數(shù)據(jù)所示【問題 1】根據(jù)第 6 周檢查所得信息，計算 BCWS、BCWP、CV、SV，預(yù)測項目完成時的費(fèi)用和進(jìn)度？【解答 1】計算結(jié)果如圖 10-3 所示成本和費(fèi)用偏差： CV=BCWP-ACWP SV=BCWP-BCWS 計算結(jié)果如圖 10-3 所示費(fèi)用執(zhí)行指標(biāo) CPI=BCWP/ACWP=285

39、/300 = 0.95 進(jìn)度執(zhí)行指標(biāo) SPI=BCWP/BCWS=285 /350 = 0.81 費(fèi)用預(yù)測 EAC預(yù)測值 = 總預(yù)算 /CPI = 500/0.95 = 526預(yù)測值 =ACWP+（總預(yù)算 -BCWP）/CPI= 300+(500-285) /0.95 = 526進(jìn)度預(yù)測預(yù)計完成時間= 計劃完成時間 /SPI = 9/0.81 = 11【問題 2】用圖分析項目的成本情況，即繪制項目的預(yù)算費(fèi)用曲線、實(shí)際費(fèi)用曲線和掙值曲線?！窘獯?2】首先，進(jìn)行預(yù)算費(fèi)用（ Budg）按時間分?jǐn)偲浯危M(jìn)行實(shí)際費(fèi)用（ ACWP）按時間分?jǐn)偟谌?，進(jìn)行掙得值（ BCWP）按時間分?jǐn)偟玫綀D 10-4，據(jù)此繪

40、制掙值曲線用圖分析項目的成本情況，即繪制項目的預(yù)算費(fèi)用曲線、實(shí)際費(fèi)用曲線和掙值曲線。案例分析十一：項目成本管理項目背景藍(lán)德公司決定開發(fā)一個保險管理系統(tǒng)（ SMIS），該項目任務(wù)重、進(jìn)度要求緊并且成本要求盡可能節(jié)省。該公司有著豐富的保險行業(yè)項目經(jīng)驗(yàn)，項目經(jīng)理在完成系統(tǒng)分析后，預(yù)計該軟件規(guī)模約 20 萬行左右，計劃 160 天完成項目，平均每天完成 1250 行代碼，每天項目成本約 2000 元，為達(dá)到控制項目成本的目標(biāo)，項目經(jīng)理仔細(xì)記錄了項目組第一階段的工作情況項目團(tuán)隊在對系統(tǒng)的設(shè)計開發(fā)過程中，花了 10 天進(jìn)行部分系統(tǒng)的開發(fā)平均完成代碼設(shè)計1300 行，按項目的設(shè)計成本，平均每天花費(fèi)2100

41、元案例問題【問題 1】項目在前 10 天的 PV、AC、EV 值是多少？判斷該項目照此效率是否能按期完成？是否超出原先預(yù)算？【解答 1】掙值分析的關(guān)鍵指標(biāo)： PV=計劃工作量 x 預(yù)算定額 ，AC=持續(xù)時間 x 實(shí)際日成本EV=已完成工作量 x 預(yù)算定額 ，CV=EV-AC， SV=EV-PVPV = 10天 x2000 元/ 天 = 20000元AC = 10天 x2100 元/ 天 = 21000 元EV =1.6 元 / 行 x1300 行 / 天 = 20800 元CV = 2080021000 =-200元項目處于超支狀態(tài)SV = 2080020000 = 800元項目進(jìn)度提前與計劃

42、進(jìn)度【問題 2】根據(jù)項目前 10 天的數(shù)據(jù)，畫出項目的掙值圖。根據(jù)前 10 天開工情況，計算項目完工時的總預(yù)算（假設(shè)后面的開發(fā)仍舊照此進(jìn)度和花費(fèi)） ，并說明原因。【解答 2】由問題 1 計算得出結(jié)論， AC>EV>PV CPI=EV/ACCPI=20800/21000=99%EAC=AC+(BAC-EV)/CPI=21000+(1.6x200000-20800)/0.99=323077元【問題 3】請簡述針對項目情況，應(yīng)該采取何種措施既能保證進(jìn)度計劃，又能保證成本預(yù)算？【解答 3】因?yàn)榇嬖?AC>EV>PV，所以可以得出此項目第一階段開發(fā)中， 效率不高（較低），進(jìn)度較快

43、，投入超前的結(jié)論應(yīng)該采取的措施可以總結(jié)為：降低開發(fā)成本，稍微放緩開發(fā)進(jìn)度，同時應(yīng)保證項目質(zhì)量采取抽調(diào)出部分開發(fā)人員來放緩開發(fā)進(jìn)度，節(jié)省部分費(fèi)用案例分析從案例來看，已收集數(shù)據(jù)為“規(guī)?！焙汀百M(fèi)用”數(shù)據(jù)， 應(yīng)從成本管理的角度分析問題掙值方法 是對項目進(jìn)度和成本進(jìn)行綜合控制的一種方法，是測量項目績效、效率的常用方法掙值方法 通過與計劃完成的工作量、 實(shí)際掙得收益、實(shí)際的成本進(jìn)行比較， 可以確定成本、進(jìn)度是否按計劃執(zhí)行掙值分析有幾個關(guān)鍵值預(yù)算成本（ PV）、實(shí)際成本（ AC）、實(shí)現(xiàn)價值（ EV）和完成尚需估算（ ETC）掙值方法有四個評價指標(biāo)成本偏差（ CV）、進(jìn)度偏差（ SV）成本績效指數(shù)（ CPI）

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