第一篇：2012下半年系統集成項目管理工程師_案例分析(掌中寶)

六、歷年考點分析

考核的題型主要是采用“原因題”與“方法題”的模式，即問題1要求找出問題產生的原因，問題2提出解決問題的方法，比如，試題一種問范圍管理存在的問題，接著問項目經理該如何辦（從項目經理的角度提出解決問題的方法）。

通過上表的分析，我們可以得知進度管理考了4次，整體管理考了4次，質量管理考了4次，合同管理考了2次，成本管理考了4次，范圍管理考了3次，配置管理考了2次，風險管理考了1次，服務管理考了1次，收尾管理考了1次。其中本人2011年5月對案例分析進行了押題，押了7個，命中5個，本人將在2011年11月考試中繼續押題，敬請大家期待！

在進行案例分析答題的時候，遇到自己不會做的，也要寫點東西，另外，案例的評分標準是達到點子上就有分的！還有，比如標準答案只有4條，你答了6條，只要多答2條，沒有理論錯誤，都是不影響的，因此，我建議大家在答題的時候，可以盡量的多寫。前提是不能違背理論知識。本人覺得，案例分析的考察也是對基礎知識的掌握進行一個評測，只是出題的方式不一樣而已，因此，我建議大家一定要掌握好基礎知識，總以為上午選擇很容易，忽悠了基礎知識的學習，其實，我建議大家一定要認真學習好基礎知識，基礎知識掌握好了，不管是以選擇、還是問題、又或是填空的形式出現，這都是沒有問題的，萬變不離其宗！

七、案例分析要點

（1）可行性研究---------不是重點，建議不做過多的學習?。保饕獌热?/p>

１、技術可行性分析；２、經濟可行性分析；３、運行環境可行性分析；４、其他方面的可行性分析，如法律、社會道德等 ２．可能產生的原因

１、沒有進行系統的可行性分析；２、調研不充分，不了解該技術是否成熟；３、沒有調研國家政策或法律法規是否允許 ３.可能遇到的風險

１、技術風險；２、政策風險；３、市場風險（２）整體管理－－－－重點，一定要弄懂！整體管理工程負責項目的全生命周期管理、全局性管理和綜合性管理。全生命周期管理意味著項目整體管理過程負責管理項目的啟動階段直到項目收尾階段的整個項目生命周期。全局性管理意味著項目整體管理過程負責管理項目的整體包括項目管理工作、技術工作和商務工作燈。綜合性管理意味著項目整體管理過程負責管理項目的需求、范圍、進度、成本、質量、人力資源、溝通、風險和采購、根據每個項目的實際情況，項目整體管理的重點隨項目的不同而有所變化。項目整體管理知識域包括保證項目各要素相互協調以完成項目所需要的各個工程。主要包含： １.項目啟動

１）制定項目章程

輸入：合同 工作說明書（ＳＯＷ）組織過程資產 輸出：項目章程 ２）選擇項目經理

２.制定初步范圍說明書 輸出初步的項目范圍說明書 ３．項目計劃管理

１）項目計劃制定 輸出：項目管理計劃 ２）項目計劃執行

３）指導和管理項目執行 ４．整體變更控制 ５．項目收尾

包括合同收尾和管理收尾。合同收尾就是按照合同約定，項目組和業主一項項的合規，檢查是否完成了合同所有的要求，是否可以把項目結束掉。也就是我們通常所講的項目驗收；管理收尾是對于內部

來說的，把做好的項目文檔等歸檔，對外宣稱項目已結束，轉入維護期，把相關的產品說明書轉到維護組，同時進行經驗教訓總結。歷年考了：

項目不能收尾的原因，促使驗收要采取的措施，公司應采取的管理手段？ 項目整體管理計劃的內容，項目整體管理中存在的問題及補救措施？ 如何做好整體管理應該從下面著手，大家考試的時候可以根據案例中主人公的做法和題目要求選擇幾點進行回答：

１、建立企業級的項目管理體系和工作規范，管理上不亂 ２、明確可交付物

３、培訓學習項目管理知識，提高管理能力 ４、做好經驗的總結，和各項計劃 ５、做好整體管理，項目過程

６、加強變更管理與控制，建立變更流程與體系 ７、要有項目啟動―――可行性分析 ８、要制定項目章程

其中，整體管理還有可能會和配置管理一起考 １、可能出現的問題

１、缺乏項目整體管理和權衡；２、缺乏變更管理控制規程；３、缺乏項目干系人溝通；４、缺乏配置管理；５、缺乏整體版本管理；６、缺乏各種單元測試和集成測試； ２、主要內容

１、制定配置管理計劃；２、配置項識別；３、建立配置管理系統；４、基線化；５、建立配置庫；６、變更控制；７、配置狀態統計；８、配置審計 ３、應對措施

１、針對目前系統建立基線；２、梳理變更脈絡，確定統一的最終需求和設計；３、梳理配置項及其歷史版本；４、對照最終需求和設計逐項分析現有配置項及歷史版本的符合情況；５、根據分析結果由干系人確定整體變更計劃并實施；６、加強單元接口測試與系統的集成測試或聯調；７、加強整體版本管理

（３）范圍管理――――重點，一定要弄懂！

范圍管理確定在項目內包括什么工作和不包括什么工作，由此界定的項目范圍在項目的全生命周期內可能因種種原因而變化，項目范圍管理也要管理項目范圍的這種變化。項目范圍的管理，是通過５個項目管理過程來實現的：

（１）編制范圍管理計劃：制定一個項目范圍管理計劃，以規定如何定義、檢驗、控制范圍，以及如何創建與定義工作分解結構。

（２）范圍定義：這個過程給出關于項目和產品的詳細描述，這些描述寫在詳細的項目范圍說明書里，作為將來項目決策的基礎。

（３）創建工作分解結構：將項目的可交付成果和項目工作細分為更小的、更易于管理的單元。在項目范圍管理過程中，最常用工具就是工作分解結構（work breakdown stniture ,WBS）.工作分解結構是一種以結果為導向的分析方法，用于分析項目所涉及的工作，所有這些工作構成項目的整個工作范圍。WBS為項目進度管理、成本管理和范圍變更提供了基礎。

（４）范圍確認：該過程決定是否正式接受已完成的項目可交付成果。（５）范圍控制：監控項目和產品的范圍狀態，管理范圍變更。１、如何定義范圍？

項目范圍的管理就是根據客戶目標形式系統功能，并經過用戶確認的過程。范圍管理是保證對項目應該包括什么和不應該包括什么進行相應的定義和控制。涉及定義和控制哪些是項目范疇內的，哪些不是。功能需求不是由客戶或用戶提供的，是項目組成員在理解目前的人工作也后分析出來的結果。

２、范圍管理的基本內容：確定項目需求、定義規劃項目范圍、范圍管理和實施、范圍的變更控制管理以及范圍核實等。

３、范圍說明書和項目章程、合同的區別：

章程是項目的組織管理文件，章程規定了項目的立項、組織、權限等，范圍說明書詳細說明了為什么要進行這個項目，明確了項目的目標和主要的可交付成果，是項目班子和任務委托者之間簽訂協議的基礎，也是未來項目實施的基礎，并且隨著項目的不斷實施進展，需要對范圍說明書進行修改和細化，以反映項目本身和外部環境的變化。在案例考試中可能會出現這樣的情況：

1、沒有挖掘到全部隱性需求，缺乏精確的范圍定義；

2、沒有有效的范圍管理，造成二次變更；

3、沒有對風險進行有效管理；

4、沒有對質量進行有效控制；

5、對范圍控制不足；

6、沒有和客戶進行需求確認

針對可能出現的問題，那么，我們應該怎么應對呢？（范圍管理應對措施）--但是這只是一個比較綜合性的措施，具體要根據案例中得具體情況進行具體的分析！

1、對項目范圍進行清晰定義，并根據定義對工作進行分解，制定WBS；

2、對項目進行合理估算，對工作量有量化的把握；

3、對項目范圍進行有效控制；

4、重新定義項目范圍必須得到高層和客戶的確認；

5、進行溝通管理，協調多個項目干系人之間的矛盾。（4）進度管理----重點，一定要弄懂 項目進度管理包括6個管理過程：

（１）活動定義：確認一些特定的工作，通過完成這些活動就完成了工程項目的各項目細目。（２）活動排序：明確各活動之間的順序等相互依賴關系，并形成文件。

（３）活動資源估算：估算每一活動所需要的材料、人員、設備以及其他物品的種類與數量。（４）活動歷時估算：估算完成各項計劃活動所需工時單位數。

（５）制定進度表：分析活動順序、歷時、資源需求和進度約束來編制項目的進度計劃。（６）進度控制：監控項目狀態、維護項目進度及必要時管理進度變更。進度管理需要掌握的知識點： １、工作量及工期的計算； ２、制定網絡圖；

３、甘特圖、里程碑圖、網絡圖的區別； ４、PERT;５、如何優化工期；

６、跟蹤項目進度的方法；

①要求WBS盡量細化，明確各項活動間的關系，畫出正確的網絡圖（雙代號或單代號網絡圖），制定出合理的項目計劃；②要對項目計劃的執行進行及時監控，并要有一個執行標準來及時糾偏；③設定項目的里程碑，對每個里程碑進行評審，以確定是否進入下一階段；④要有一個好的變更控制系統來控制變更控制流程，做好變更管理；⑤要使用項目管理的工具軟件，提高項目管理的工作效率。進度管理可能出現的問題以及可以采用的辦法，其中還要注意可能會和成本一起考?。?、團隊成員沒有及早參與，需求分析耗時長，要早起參與進項目

２、經驗不足，進度計劃制定不準，采取有效的歷時估算方法和網絡計劃技術，制定進度計劃 ３、考慮項目期間特定時期會對進度產生影響

４、增加人手，聘請更有經驗的人員，或找兼職人員 ５、加班 ６、并行

７、重新估算后面的工期 ８、加強溝通，減少變更 ９、加強控制，避免返工 １０、外包

１１、加強溝通，先完成關鍵需求

１２、增加資源有時可能壓縮工期有限

１３、關注關鍵路徑，在關鍵路徑上加資源，有效果 １４、關注里程碑

１５、加強進度與成本、風險、質量等知識點的協調

上面說了一下解決措施，但是一定要根據題目中得真實場景案例進行答題！

其中，下面的一些知識點，我建議大家也要掌握：

１、活動定義：為得到工作分解結構中最底層的交付物執行的一系列活動，對這些活動的識別以及歸檔的過程叫做活動定義。

工具：分解、模板、流動式規劃、專家判斷、規劃組成部分

輸入：工作分解結構、項目范圍說明書、組織過程資產、項目管理計劃

輸出：項目活動清單是項目活動的主要輸出，他列出了一個項目所需開展和完成的全部項目活動。項目活動清單是根據WBS通過進一步細化得到。

２、活動排序：確定活動之間的依賴關系，形成文檔

工具：PDM（前導圖，單代號網絡圖）、ADM（箭線圖，雙代號網絡圖）輸入：項目活動清單、活動屬性、項目范圍說明書、組織過程資產 輸出：項目網絡圖、更新的活動清單、更新的活動屬性 ３、活動資源估算

工具：專家判斷、自上而下的估算、估算軟件 輸入：組織過程資產、活動清單、資源可用性 輸出：活動資源需求、活動清單（更新）４、活動歷時估算

工具：專家判斷、類比估算：以過去類似項目活動的實際時間為基礎，通過類比來推測估算當前項目所需的時間、參數估算、三點估算：（樂觀+4個正常+悲觀）÷6 ５、制定項目進度計劃

項目進度計劃要經過多次反復調整才能最后完成，項目進度計劃不變是相對的，而變化是絕對的。工具：CPM（關鍵路線法）--能夠決定項目最早完成時間的一系列活動，他是網絡圖中最長路徑，具有最好的浮動時間或時間差；PERT（計劃評審技術）：活動時間期望值=（樂觀+4個正常+悲觀）÷

6、活動時間的標準差=（悲觀-樂觀）÷6：持續時間的壓縮（縮短關鍵路徑上的活動歷時，可以采用趕工（費用交換），快速跟進（并行處理）等方式。資源對進度的影響

（１）一般情況下，項目活動歷時與投入的資源數量成反比，即投入的資源數量越多，活動歷時越短。但是，當針對某一活動的資源投入數量達到一定規模時，再增加資源的投入不會進一步縮短項目活動歷時，也就是資源投入遞減規律。

（２）非關鍵路徑上的活動歷時只對項目產生較小的影響或不產生影響，而關鍵路徑上活動歷時的延誤，則會直接影響到項目工期。因此每當縮短項目工期時，應對首先考慮在關鍵路徑活動上增加資源。

可以采用哪些方法來跟蹤項目的進度，以確保項目能夠按進度計劃完成？

（1）基于WBS和工時估算制定活動網絡圖，制定項目進度計劃；（2）建立對項目工作的監督和測量機制，依據項目進度基線和日常項目進展報告，比較進度偏差（SV）和進度效率指數（SPI），進行偏差分析；（3）確定項目里程碑，并建立有效的評審機制；（4）對項目中發現的問題，及時采取糾正措施，并進行有效的變更管理；（5）使用有效的項目管理工具，提高項目管理的工作效率。（5）成本管理-----重點，一定要弄懂

項目管理受范圍、時間、成本和質量的約束，項目成本管理在項目管理中占有重要地位。項目成本管理就是要確保在批準的預算內完成項目。具體的項目成本管理要靠制定成本管理計劃、成本估算、成本預算、成本控制等4個過程來完成，其中：

（１）制定成本管理計劃-----制定了項目成本結構、估算、預算、和控制的標準。（２）成本估算----編制完成項目活動所需資源的大致成本。

（３）成本預算----合計各個活動或工作包的估算成本，以建立成本基準。（４）成本控制----影響造成成本偏差的因素，控制項目預算的變更。下面的一些知識點必須掌握： 1.成本估算

步驟：1）識別并分析項目成本的構成科目；2）根據已識別項目成本科目，估算每一成本科目的成本大??；3）分析成本估算結果，找出各種相互替代的成本，協調各成本科目之間的關系工具：類比估算法（專家判斷）、自上而下估算法（優點：簡單易行，花費??；缺點：準確性差）、自下而上估算

法（優點：準確性高；缺點：耗時，成本高）、參數模型估算法 輸入：項目范圍說明書、項目管理章程、WBS和WBS字典、風險事件 輸出：成本估算結果、成本估算支持細節、更新的成本管理計劃 2.成本預算

成本預算的作用：1）按計劃分配項目資源，保證各項工作得獲得需的各種資源；2）一種控制機制，對項目各項工作的成本預算記性適當的調整；3）為項目提供一把標尺，可以及時掌握項目的進度情況

輸入：項目范圍說明書、工作分解結構、WBS字典、活動成本估算、成本管理計劃 輸出：成本基準 項目資金需求 請求的變更 更新的成本管理計劃 3.成本控制

成本控制的主要目的是分析造成實際成本與成本基準計劃發生偏差的因素并采取糾正，確保其向有利的防線發展

成本控制的內容：監控實際成本與計劃成本的偏差、確認費用偏差都被記錄、避免不正確不合適或者無效的費用變更發生、對發生成本偏差的工作包實施管理，有針對性采取糾正措施、防止因成本控制引起的項目范圍、進度和質量方面的問題

輸入：成本基準、績效報告、變更請求和成本管理計劃

輸出：修正的成本估算、預算更新、糾正措施、變更需求、經驗教訓

工具：成本變更控制系統（申請成本變更，批準成本變更，變更成本預算）、績效預測、項目績效評估、偏差分析、趨勢分析、掙值分析、計算機輔助 PV（計劃值)：計劃工作的預算費用

AC（實際成本）：已完成工作的實際費用 EV（掙值）：已完成工作的預算費用

ETC（剩余工作的成本估算）：=總的PV-已完成的EV CV（成本偏差）：CV=EV-AC CV﹥0 成本節約 CV﹤0超支

SV（進度偏差）：SV=EV-PV SV﹥0 超過進度 SV﹤0落后進度

CPI（成本績效指數）：CPI=EV/AC CPI﹥1 成本結余 CPI﹤1成本超支 SPI（進度績效指數）：SPI=EV/PV SPI﹥1 進度超前余 SPI﹤1進度滯后 完工估算（EAC）

公式1：EAC=AC+ETC（實際支出+剩余工作的新估算）

適用情況：過去的實施情況表明原來所作的估算徹底過時，條件變化，原來的估算不合適 公式2：EAC=AC+BAC-EV（實際支出+預計完成項目的總成本-已完工作的預算）適用情況：未來的實施不會發生類似的變化 動態投資回收期：

（累計凈現金流量折現值開始出現正值得年份數-1）+（1-上年累計凈現金流量折現值/當年凈現金流量折現值）

投資收益率=1/動態回收期*u65297*0.0% 項目成本失控原因

項目成本控制工作是在項目實施過程中，通過項目成本管理盡量使項目實際發生的成本控制在預算范圍之內。如果項目建設的實際成本遠遠超出批準的投資預算，就表明出現了成本失控。發生成本失控的原因主要以下幾點。

（1）對工程項目認識不足：

①對信息系統工程成本控制的特點認識不足，對難度估計不足。

②工程項目的規模不合理，一個大而全的項目往往導致工期很長，而且導致工程實施的技術難度太高，導致技術人員的投入方面跟不上工程建設的需要，并且建設單位各部門對信息系統工程的接受能力和觀念的轉變跟不上信息系統建設的需要。

③工程項目的設計人員和實施人員缺乏成本意識，導致項目的設計不滿足成本控制的要求。

④對項目成本的使用 責任感，隨意開支，鋪張浪費。（2）組織制度不健全

①制度不完善

②責任不落實。缺乏成本控制的責任感，在項目各個階段和工作包沒有落實具體的成本控制人員

③承建單位項目經理中沒有明確的投資分工，導致對投資控制的領導督查不力。（3）方法問題

①缺乏用于項目投資控制所需要的有關報表及數據處理的方法。

②缺乏系統的成本控制程序和明確的具體要求，在項目進展不同階段對成本控制制度的要求不明確，在項目進展的整個過程中缺乏連貫性的控制。

③缺乏科學、嚴格、明確而完整的成本控制方法和工作制度。

④缺乏對計算機輔助投資控制程序的利用。

⑤缺乏對計劃值與實際值進行動態的比較分析，并及時提供各種需要的狀態報告及經驗總結。（4）技術的制約

①由于進行項目成本估算發生在工程項目建設的早期階段，對項目相關信息了解不深，項目規劃設計不夠完善，不能滿足成本估算的需求。

②采用的項目成本估算方法不恰當，與項目的實際情況不符，或與所得到的項目數據資料不符。③項目成本計算的數據不準確或有漏項，從而導致計算成本偏低。

④設計者未對設計方案進行優化，導致項目設計方案突破項目成本目標。⑤物資或設備價格的上漲，大大超過預期的浮動范圍。⑥項目規劃和設計方面的變更引起相關成本的增加。

⑦對工程實施中可能遇到的風險估計不足，導致實施成本大量增加。信息系統的項目成本估算的困難主要包括： １）需求信息的復雜性。

２）開發技術與工具的不斷變化。

３）缺乏類似的項目估算數據可供參考。４）缺乏專業和富有經驗的人才。

５）信息系統研發人員技術能力的差異。

６）管理層壓力與誤解在對項目成本估算時，應該避免以下的常見錯誤：①草率的成本估算。②在項目范圍尚未確定時就進行成本估算。③過于樂觀或者保守的估算。（6）質量管理----重點，一定要弄懂

項目質量管理包括了確保項目滿足其各項要求所需的過程。他包括了擔負全面管理職責的各項活動：確定質量方針、目標和責任，并通過質量策劃、質量保證、質量控制和質量改進等手段在質量體系內實施質量管理。

項目的質量管理可以分解為質量策劃、質量保證與質量控制三個過程。

質量策劃是指確定與項目相關的質量標準，并決定如何達到這些質量標準。

質量保證是定期評估總體項目績效的活動之一，以樹立項目能滿足相關質量標準的信心。質量控制是指監控具體的項目結果以判斷其是否符合相關的質量標準，并確定方法來消除績效低下的原因。

整個項目質量管理過程可以分解為以下4個環節：（1）確立質量標準體系

建立適當的質量衡量標準是進行項目質量管理的前提性的關鍵性工作。根據企業在實施項目方面的整體戰略規劃與項目事實上計劃，實施項目的主體企業首先要確立衡量項目質量的標準體系。衡量項目質量的標準一般包括項目涉及的范圍、項目具體的實施步驟、項目周期估計、項目成本預算、項目財務預測與資金計劃，項目工作詳細內容安排、質量指標要求以及客戶滿意度等。需要注意的是，項目質量指標體系一定要具備完整性、科學性與合理性，項目實施各相關主體應該事先進行討論與溝通，以保證其完整、無漏洞，又具備較強的可實施性。（2）對項目實施進行質量監控

要在項目執行過程中采取有效措施來監控項目的實際運行。在項目實施過程中，根據要求收集項目實施過程中得相關信息，觀察、分析項目實施進程中得實際情況以便監控。為了達到有效監控項目的目的，可以利用的監控措施與溝通渠道包括：①正式的監控與溝通渠道，例如項目進度報告、項目例會、里程碑會議、各種會議紀要等。②非正式的監控與溝通渠道，例如與項目小組成員或最終用戶進行交

談與討論，與企業管理層進行非正式的交流等。

在這個環節上，要根據項目質量標準體系的要求，通過有效的監控措施和渠道，全面、客觀地跟蹤及反映項目實施的實際情況。（3）將實際與標準對照

把項目實施過程中的實際表現與項目質量衡量標準進行比較，分析出差異。在監控與跟蹤項目實際運行狀況時，往往需要解決這樣一些問題，比如，“項目進展如何”“如果發生了項目假話執行結果與質量標準偏離的情況，是如何造成的”等。通過對項目實施相關衡量指標的綜合分析，為客觀評價項目質量狀況提供依據，幫助項目決策人迅速、有效地對項目的實際進展情況進行監控與管理，從而可以根據需要采取有效措施來保證項目實施接著既定的軌道運行。（4糾偏糾錯

根據具體情況采取合理的糾正措施。經過比較與分析，如果發生偏差，就要采取適當的措施進行糾正，讓項目實施回到正軌?？晒┻x用的糾正措施包括：重新制定項目計劃、重新安排項目步驟、重新分配項目資源、調整項目組織形式、調整項目管理方式等。一般而言，為了保證項目不偏離正常軌道，按照既定計劃走向成功，保證糾正措施的合理性與有效性，需要項目的實施主體事先了解一些項目質量管理基礎知識與相關案例，確保糾錯措施的有效性。

全面質量管理有4個核心的特征：即全員參加的質量管理、全過程的質量管理、全面方法的質量管理和全面結果的質量管理。1.質量計劃編制

工具：成本績效分析法、質量基準分析、流程圖法（因果分析圖）、實際設計法、質量成本分析（質量成本分為預防成本、評估成本、缺陷成本）

輸入：項目章程、項目管理計劃、項目范圍說明書、組織過程資產

輸出：質量管理計劃、質量測試指標、質量核對表 2.執行質量控制

工具：測試、檢查、控制圖、因果圖（石川圖）、帕累托圖（排列圖或主次因素分析圖）、統計抽樣、流程圖、趨勢分析

3.質量保證與質量控制的區別：質量保證是針對項目實施過程的管理手段，質量控制是針對項目產品的技術手段。

4.軟件質量從六個方面來衡量：性能、可靠性（包括容錯性和健壯性）、可用性、安全性、可修改性（包括可維護性?？蓴U展性。結構重組、可以執行）、功能性

5.造成質量問題的原因有五大方面：人、機器。原材料、方法和環境

項目的質量控制工作是一個系統過程，應從項目的全過程入手，全面、綜合地進行控制，項目的質量控制主要從以下2個方面進行。項目產品或服務的質量控制，項目產品或服務的質量控制是一個診斷和治療的過程，當產品生產出來以后要檢查產品的規格是否符合需要的標準，并消除生產的偏差，質量控制活動包括計劃、測試、記錄和分析。項目管理過程的質量控制，項目管理過程的質量控制，項目管理過程的質量控制是通過項目審計來進行的，項目審計是將管理過程作業和成功實踐標準進行比較所作出的詳細檢查，考慮以下5個方面：度量項目質量的實際情況、與質量標準進行對比、識別存在的質量問題和偏差、分析質量問題產生的原因、如有必要進行糾偏、如何進行質量保證？質量保證是質量系統內實施的所有計劃的系統性活動，是保證質量管理計劃得以實施的一組過程和步驟，旨在證明項目滿足相關的質量標準，質量保證采用主要工具和技術有質量計劃、質量審計、過程分析、和質量控制技術和工具以及其他過程中獲得的變更請求、質量控制測量、實施的變更請求等，通過這些技術和工具得到的信息作為質量保證的依據，提出請求的變更，以提高組織的質量政策、過程和程序的效率和效益。請指出QA與QC的聯系和區別? QA和QC兩者基本職責QC：檢驗產品的質量，保證產品符合客戶的需求：是產品質量檢查者；QA:審計過程的質量，保證過程被正確執行，是過程質量審計者；QC進行質量控制，向管理層反饋質量信息；QA則確保QC按照過程進行質量控制活動，按照過程將檢查結果向管理層匯報。這就是QA和QC工作的關系。

項目質量管理可能問題？

1、沒有制定可行的質量管理計劃并積極實施；

2、沒有全面的質量管理進展情況報告；

3、溝通方式

單一或不全面，容易誤導用戶，致用戶不必要的擔心。項目質量管理主要內容？

質量責任與人員職責；組織結構；程序與過程；質量控制的方法、工具與重點；質量管理所需要的資源；驗收標準

如何實施質量保證？

執行質量管理計劃，采用質量保證的工具和技術，提出相應質量整改措施 如何制定過程改進計劃？

質量管理計劃包括：質量政策，質量目標。質量管理活動。具體歸納為：1.質量責任和人員分工。2.組織結構；3.程序與過程。4.質量控制的方法、工具、重點（質量評審、質量保證方法）。5.質量管理需要的資源。6.驗收標準。質量保證體系包含？

1.是否制定明確的質量計劃；2.是否建立健全專職的質量管理機構；3.是否實現管理業務標準化，管理流程程序化；4.是否配備必要的資源條件。5.是否建立了一套靈敏的質量信息反饋系統。如何進行質量保證？（補充）

制定質量標準，制定質量控制流程，建立質量保障體系。

實施質量保證的方法：1.首先執行項目的質量管理計劃；

2、采用質量保證的工具和技術；

3、提出相應質量整改措施，如建議的糾正措施、對項目計劃可能的更新、對組織資產可能的更新、變更請求。如何控制產品的質量？

1、強有力的領導；

2、建立組織級項目管理體系

3、建立組織級質量管理體系

4、建立項目級激勵制度

5、理解質量成本

6、提高項目文檔質量（項目文檔應有針對性、精確性、清晰性、完整性、靈活性、可追溯性）

7、發展和遵從成熟度模型。

文檔的種類和作用：

1、用戶文檔；

2、開發文檔；

3、管理文檔

作用：

1、橋梁和交流作用；

2、明晰責任；

3、更好的理解系統；

4、進行項目質量管理。

質量文件包括：項目質量文件包括：質量保證大綱，技術文件，質量工作計劃，質量成本分析。救火隊的原因（項目質量常常遇到的問題）：

1、項目交付成果本身有缺陷，例如不穩定或功能不完美；

2、項目交付成果沒有實現預定的功能需求；

3、項目在需求分析階段對用戶的需求分析提煉精度不夠，沒有挖掘到部分重要的需求；

4、隨著時間和環境的變化，客戶產生了新的需求；

5、由于文檔的不完備，一方面導致用戶不能解決一些使用問題，另一方面還使得文虎工作的效率提不高。質量控制的工作應做好以下幾方面內容：

1、對維護工作進行質量控制，做好相關文檔工作；

2、在有條件情況下，開始對已交付系統進行文檔建設，尤其是用戶手冊的建設工作；

3、建立組織級的質量管理體系和相關的標準及規范，取得高層領導的支持和信任，開展整體質量控制關鍵的培養，在以后工作中實施嚴格的質量控制工作。質量保證工作的作用：

1、是保證質量的一個重要環節；

2、為持續的質量改進提供基礎和方法；

3、為項目干系人提供對于質量的信任；

4、項目質量管理的重要內容；

5、與質量控制共同構成對質量的跟蹤和保證。

質量管理強調的是全面質量管理，全過程質量管理，而不僅僅是測試工作所能保證的，項目實施過程中的每一個工作都會對項目質量產生影響。

（7）人力資源管理---比較重點，建議要弄懂！

項目人力資源管理包括制定人力資源管理計劃、項目團隊組建、團隊建設與管理的各個過程，不但要求充分發揮參與項目的個人的作用，還包括充分發揮所有與項目有關的人員-----項目負責人、客戶、為項目作出貢獻的個人及其他人員的作用，也要求充分發揮項目團隊的作用。項目人力資源管理包括如下過程：

（１）項目人力資源計劃編制：確定與識別項目中得角色、分配項目職責和匯報關系，并記錄下來形成書面文件，其中也包括項目人員配備管理計劃。

（２）項目團隊組建：通過調配、招聘等方式得到需要的項目人力資源。

（３）項目團隊建設：培養提高團隊個人的技能，改進團隊合作，提高團隊的整體水平以提升項目績效。

（４）項目團隊管理：跟蹤團隊成員個人的績效和團隊的績效，提供反饋，解決問題并協調變更以

提高項目績效。

這些過程互相之間有影響，并且同項目管理其他知識領域中的過程相互影響。處理人際關系涉及許多技能，其中包括：

（１）領導、溝通、談判、協商及其他管理技能。

（２）授權、激勵士氣、指導、勸告及其他與處理個人關系有關的技能。（３）團隊建設、沖突解決及其他與處理團隊關系有關的技能。

（４）績效評定，招聘，留用，勞工關系，健康與安全規定，及其他與管理人力資源有關的技能。編制項目人力資源計劃

人力資源計劃編制是決定項目的角色，職責以及報告關系的過程。項目的角色有可能是個人，也有可能是團隊。他們要么屬于組織內部，要么屬于組織外部，或是兩者的結合。人力資源計劃編制也會創建一個項目人員配備管理計劃。

工具：組織結構圖、OBS(組織結構分解)、RAM（責任分配矩陣、人力資源模板、非正式的人際網絡 輸入：活動資源估計、環境和組織因素、項目管理計劃

輸出：角色和職責、項目的組織結構圖、人員配備管理計劃 項目團隊建設的兩個目標

１、提高項目團隊成員的個人技能，以提高他們完成項目活動的能力。

２、提高項目團隊之間的責任感和凝聚力，以更好的團隊合作提高工作效率。項目團隊的四個階段：形成→震蕩→正規→表現

團隊建設的關鍵：激勵理論、影響和能力、提高有效性

馬斯洛需求理論有兩個基本論點：

1、人的需求取決于他已經得到的和尚未得到的。

2、人的需求是分層次的。生理的需要、安全的需要、感情的需要、尊重的需要、自我實現的需要。信息系統團隊的建設與發展的建議：

1）對團隊成員要有耐心、友好及信心；2）解決問題而不責備人；3）經常召開會議，注重項目的實現以及長期有效的結果；4）把項目團隊建設計劃放到項目計劃中去，讓項目干系人有更多的了解；5）教育培養團隊成員，提供培訓機會，使團隊成為一個有效的整體；6）認可個人和團隊的成績；7）盡早的進行團隊建設，使整個項目生命周期中進行項目團隊建設。管理項目團隊

工具和技術：1）觀察和談話 1）項目績效評估 3）沖突管理 4）問題日志 知識性員工的特點及管理方法：

具有很強的獨立性和自主性，注重自我引導和自我管理；忠誠度低，流動性強；工作過程難以監控；具有實現自我價值的強烈渴望；個性突出

管理放大：溝通，重視，信任，承諾，支持，創新，學習和合作；管人要想管事轉變，充分體現個人意愿和價值，側重監管工作進度，質量和結果；激活個體的主觀能動性，建立公平公正和公開的內部競爭環境；要完善薪酬激勵機制，全面推行績效考核管理，滿足員工素質不斷提高的個人需求，激發知識員工的工作熱情和創造力；在職業教育和職業生涯設計相結合，營造實現自我價值的廣闊空間。針對選定的項目，根據項目的特點，需要的角色如下： 管理類崗位：如項目經理

工程類：系統分析師，軟件設計師，程序員，測試工程師，美工，網絡工程師，主機人員，實施人員：行業專家

輔助類：文檔管理員、秘書等 組建項目團隊，明確責任

建設項目團隊：提高個人績效，提高責任感和凝聚力

管理項目團隊：（1）跟蹤個人和團隊的執行情況，提供反饋（2）協調變更，以提高項目的績效，保證項目進度（3）注意團隊的行為，管理沖突，解決問題（4）評估團隊成員的績效 人力資源可能問題：

１、缺乏足夠的項目管理能力和經驗；

２、兼職過多，經理和時間不夠用，顧此失彼；

３、沒有進入管理角色，定位錯誤，疏于對項目的管理； ４、新人缺乏培訓和全程的跟蹤和監控；

應對措施

１、事先制定崗位的要求、職責和選人的標準，并選擇合適的人選

２、對工作進行全面估算，如果有人負荷過重，需要找人代替，解決負載平衡問題 ３、事前溝通并對相應人員明確要求，明確角色的輕重緩急，促使盡快轉換角色 ４、上級應該注意平時對人員的培養和監控 ５、采用激勵理論與實際制度相一致 ６、加強團隊建設的活動 ７、形成共同的行為準則

８、爭取公司認可的獎勵機制，認可成員的工作 ９、績效考核

１０、招聘掌握技能的人員加入項目團隊

１１、做好人員風險分析，制定相應的計劃與措施 １２、采用項目管理管理系統，提高工作效率 如何組建團隊成員？

1.實現分派；2.談判；3.采購；4.虛擬團隊。如何激勵團隊？ 1.一般管理技能（如溝通、交流）；2.培訓；3.團隊建設活動（如周例會、共同解決問題、拓展訓練）；4.共同的行為準則（如基本準則、規章制度）；5.盡量集中辦公（如同地辦公、封閉開發）；6.認可和獎勵（恰當的獎勵與表彰措施）成功團隊的標志、特點：

１、團隊的目標明確，成員清楚自己工作對目標的貢獻； ２、團隊的組織結構清晰，崗位明確；

３、有成文或習慣的工作流程和方法，而且流程簡明有效； ４、項目經理對團隊成員有明確的考核和評價標準； ５、組織記錄性強；

６、互相信任，善于總結和學習。如何設別并管理干系人？

作為項目干系人分析的第一步，需要先仔細識別出本項目的全部干系人。項目經理需要對項目干系人有一個全面的了解，在心中有一張完整的項目關系人結構圖，以后無論是啟動、計劃還是執行、問題處理和收尾，都需要系統全局地思考問題，切忌頭痛醫頭、腳痛醫腳。

在項目干系人識別中，對甲方項目干系人的識別和分析更是重中之重，在識別出項目干系人之后，還需要分析干系人之間的關系和歷史淵源，如果不做這進一步的分析，會在項目過程中遇到不小的麻煩。如何對待項目中出現的沖突？

１、運用沖突解決辦法正確解決雙方沖突；

２、提高自己的技術能力，行使專家權力說服沖突雙方，獲得雙方信任； ３、對消極怠工員工行使強制力讓其努力工作；

４、和團隊成員增強溝通和交流，獲得團隊成員的信任； ５、跟蹤個人和團隊的執行情況，及時反饋和協調變更； ６、實行獎勵制度以激勵團隊。管理項目團隊的常用方法：

觀察和對話、項目績效評估、沖突管理和問題日志 沖突產生的原因：

項目的高壓環境、責任模糊、多個上級的存在、新科技的流行。沖突解決的辦法：問題解決、妥協（求同存異、撤退、強迫）

新技術風險解決辦法：培訓、自制—外購分析、招聘掌握該新技術的人員、風險分析與防范。5種權力：合法的權力、強制力、專家權力、獎勵權力、潛示權力 X型管理需要注意：

１、把握好軟硬件措施，有功獎、有錯罰； ２、明確任務分配和跟蹤任務執行情況；

３、和項目團隊成員增強溝通，增進信任；

４、關注資源符合情況，靈活調整任務分配和項目進度計劃，盡量讓資源平衡； ５、注意項目高壓下團隊成員的情緒，正面處理沖突；

６、修改不合理和錯誤的項目進度計劃，聽取各方面意見和建議。（8）溝通管理-----比較重點，建議要弄懂 項目溝通管理包括如下過程：

① 溝通計劃編制。確定項目干系人的信息和溝通需求：哪些人是項目干系人，他們對于該項目的收益水平和影響程度如何，誰需要什么樣的信息，何時需要，以及應怎么樣分發給他們。② 信息分發。以合適的方式及時向項目干系人提供所需信息。③ 績效報告。收集并分發有關項目績效的信息，包括狀態報告、進展報告和預測。④ 項目干系人管理。對項目溝通進行管理，以滿足信息需要者的需求并解決項目干系人之間的問題。

溝通管理計劃編制過程一般分為如下幾個步驟：

（１）確定干系人的溝通信息需求，即哪些人需要溝通，誰需要什么信息，什么時候需要以及如何把信息發送出去。

（２）描述信息收集和文件歸檔的結構。

（３）發送信息和重要信息的格式，主要指創建信息發送的檔案，獲得信息的訪問方法。通常，溝通計劃編制的第一步就是干系人分析，得出項目中溝通的需求和方式，進而形成較為準確的溝通需求表，然后再針對需求進行計劃編制。溝通管理計劃的主要內容：（１）項目關系人溝通要求。

（２）對要發布信息的描述，包括格式、內容和詳盡程度。（３）信息接收的個人或組織。

（４）傳達信息所需的技術或方法，如備忘錄、電子郵件或新聞發布等。（５）溝通頻率，如每周溝通等。

（６）上報過程，對下層無法解決的問題，確定問題上報的時間要求和管理鏈（名稱）。（７）隨項目的進展對溝通管理計劃更新與細化的方法。（８）通用詞語表。

常用的溝通方式的優缺點或特點介紹如下

1、書面與口頭、聽和說

書面的溝通方式優點是清晰，二義性少以及可以作為備忘錄，也可作為雙方溝通的證據。而缺點是缺乏人性化，如某些勇于較為生硬的話，容易使雙方的關系出現矛盾。

2、對內與對外

項目經理通常采用不同的方式進行對內（項目團隊內）和對外（對顧客、媒體和公眾等）的溝通。對內溝通講究的是效率和準確度，對外溝通強調的信息的充分和準確。對內的溝通可以以非正式的方式出現，而對外的溝通要求項目經理以正式的方式進行。

3、正式與非正式

通常情況下，正式（如報告、情況介紹會等）的溝通是在項目會議時進行的，而非正式（如備忘錄、即興談話等）的項目溝通屬于大多數場合的方式。

4、垂直與水平

垂直方向（從下到上或者從上到下）溝通的特點是：溝通信息傳播速度快，準確程度高。水平方向溝通的特點是：復雜程度高，往往不受當事人的控制。溝通管理對組織過程資產的影響表現在如下方面 ① 經驗教訓記錄 包括問題的起因、所采取糾正措施以及有關信息發布的其他各種經驗教訓。記錄下來的經驗教訓可成為本項目和項目實施組織的歷史數據庫的組成部分。② 項目記錄

項目記錄可包括函件、備忘錄以及項目描述文件。這些信息應盡可能地以適當方式有條理地加以保存。項目團隊成員也往往在項目筆記本中保留個人記錄。

③ 項目報告

正式和非正式項目報告將詳細說明項目狀態，其中包括經驗教訓、問題記錄單、項目收尾報告和其他知識領域的成果。④ 項目演示介紹

項目團隊正式或非正式地向任何或所有項目干系人提供信息。這些信息要切合聽眾需要，介紹演示的方法要恰當。⑤ 項目干系人的反饋

可以發布從項目干系人收集的有關項目實施的消息，并根據該信息改進或修改項目的未來績效。⑥ 項目干系人通知

可就解決的問題、審定的變更和一般項目狀態問題向項目干系人通報。溝通管理可能問題：

１、內部管理有問題，監管不力

２、沒有或極少與客戶進行直接溝通 ３、現場管理制度執行不力 ４、總包與分包責任不清

５、客戶獲取的信息失真，總包推卸責任

６、客戶自己本身的問題，包括資金、管理水平等 ７、可能監理工作沒到位 溝通管理應對措施

１、做好干系人分析

２、發揮總包的牽頭和監理的協調作用

３、對共用資源可用性進行分析，引入資源日歷 ４、解決沖突

５、監理健全項目管理制度并監管其執行 ６、采用項目管理信息系統 可能問題和應對措施的補充

１、缺乏溝通，合作氛圍不夠

２、及時信息分發，加強溝通，讓客戶了解項目具體情況 ３、注重溝通技巧，建立融洽的合作氣氛

４、沒有對團隊成員的溝通需求和溝通風格進行分析 ５、沒有開一個高效的會 ６、溝通方式單一 ７、沒有沖突管理

８、開高效會議的做法

９、分析成員的溝通風格，從而采用相應的溝通方式 １０、多種溝通方式

１１、采用一些溝通模板 １２、加強沖突管理

１３、采用一些溝通模板 １４、加強沖突管理 １５、多供應商的溝通

１６、解決沖突，包括干系人對項目期望之間的沖突、資源沖突等 １７、做好干系人分析，調研各集成商的溝通需求 １８、周期性溝通

１９、突發事件的協調 有效溝通的方式有？

１、使用項目信息系統輔助溝通，用于收集、綜合、分析項目管理過程輸出的工具和技術； ２、建立溝通基礎結構，是一套工具、技術和原則，為項目信息傳送提供基礎； ３、使用項目溝通模板；

４、把握項目溝通基本原則，溝通內外有別，非正式溝通有利于關系融洽，采用對方能夠接受的溝通風格、溝通升級原則、掃除溝通的障礙； ５、發展更好的溝通技能；

６、認識和把握人際溝通風格； ７、良好的沖突管理； ８、召開高效的會議 溝通和需求獲?。?/p>

１、制定完善的溝通管理計劃

２、在和客戶溝通之前學習和項目相關的背景知識 ３、用經驗和技巧引導客戶對需求進行明細化

４、對超出需求范圍的需求或不合理的需求，應有技巧地說服客戶 ５、使用多種方式和客戶進行溝通 應該怎么提高項目例會的效率？

１、事先制定一個例會制度。在項目溝通計劃中，確定例會的時間，參加人員范圍以及一般議程等。

２、放棄可開可不開的會議。在決定召開一個會議之前，首先明確會議是否必須舉行，還是可以通過其他方式進行溝通。

３、明確會議的目的和期望結果。

４、發布會議通知、在會議通知中要明確：會議目的，時間，地點，參加人員，會議議程和議題。事先明確會議議程和討論問題，讓參會人員提前做準備。

５、在會議之前將會議資料發送到參會人員。對已需要有背景資料支持的會議，應事先將資料發給參會人員，以提前閱讀，直接在會上討論，可以有效節約時間。

６、可以借助視頻會議設備。對于異地參會人員或者需要演講的場合，可以借用一些必要的視頻設備，可以使會議達到更好的效果。

７、明確會議規則。制定會議主持人，明確會議主持人的職責，支持人要對會議進行有效控制，并營建一個活躍的會議氣氛。

８、支持人要事先陳述基本規則，例如明確每個人的發言時間，每次發言只有一個聲音主持人根據會議議程的規定控制會議的節奏，保證每一個問題都得到討論。

會議后要總結，提煉結論。支持人在會后總結問題的討論結果，重審有關決議，明確責任人和完成時間。

會議要有紀要。如果將工作的成果、完成時間、責任人都記錄在案，則有利于督促和檢查工作的完成情況。

做好工作會議的后勤保障。很對會議兼有聯絡感情的作用，因此需要選擇一個合適地點，提供餐飲、娛樂和禮品，制定一個有張有弛的會議議程。對于客戶或合作伙伴參加的會議更要如此?？刹捎玫拇龠M有效溝通的措施如下：

（１）對項目組成員進行溝通需求和溝通風格的分析

（２）對于具有不同溝通需求和溝通風格的人員組合設計不同的溝通方式

（３）除了進行項目例會外，可以通過電話，電子郵件、項目管理軟件、OA軟件等工具進行溝通（４）正式的溝通的結果應形成記錄，對于其中的決定應有人負責落實（５）可以引入一些溝通模板

（６）在項目組內部培養團結的氛圍并注意沖突管理

溝通渠道的數目：n(n-1)/2(9)合同管理---重點，一定要弄懂 按信息系統范圍劃分的合同分類

１、總承包合同

２、單項項目承包合同 ３、分包合同

按項目付款方式劃分的合同分類 １、總價合同

２、單價合同

３、成本加酬金合同 項目合同簽訂的注意事項

１、當事人的法律資格：當事人訂立合同，應當具有相應的民事權利能力和民事行為能力。２、質量驗收標準：質量驗收標準是一個關鍵指標。如果雙方的驗收標準不一致，就會在系統驗收時產生糾紛。

３、驗收時間：當事人沒有約定設備的交付時間或者約定不明確的，可以協議補充，不能達成協議的，依照合同有關條款或交易習慣確定。若仍不能確定，則供貨可以隨時履行，采購方也可以隨時要求履行，但應當給予對方必要的準備時間。４、技術支持服務

５、損害賠償：原則上，委托方與被委托方都具有損害賠償這項權利，但比較多的情況是因為承建方對于企業實施信息系統的困難估計不足，結果陷入到期后難以完成項目的尷尬局面。

６、保密約定：當事人在訂立合同過程中知悉的商業秘密，無論合同是否成立，不得泄露或者不正當的使用。泄露或不正當地使用該商業秘密給對方造成損失的，應當承擔損害賠償責任。７、合同附件：合同生效后，當事人就質量、價款或者報酬、履行地點等內容沒有約定或者約定不明確的，可以協議補充，不能達成補充協議的，按照合同有關條款或者交易習慣確定。

８、法律公證：為避免合同糾紛，保證合同訂立的合法性，當事人可以將簽訂的合同拿到公證機關進行公證。經過公證的合同，具有法律強制執行效力。關于合同不明確情況的處理

（１）當事人對標的物的質量要求不明確的，按國家標準和行業標準。沒有這些標準的，按產品通常標準或符合合同目的的標準。

（２）履行地點不明確的，按標的性質不同而定：接受貨幣在接受方，交付不動產的在不動產所在地，其他標的在履行義務方所在地。履行地在法律上具有非常重要的意義，他可以確定由誰負擔，貨物的所有權何時何處轉移，貨物丟失風險由誰承擔等，在訴訟中，也是確定管轄權的重要依據，所以簽訂合同對履行地條款要特別注意。

（３）履行期限不明的，債務人可隨時履行，債權人可隨時要求履行，但應給對方必要的準備時間，在這里特別提醒債權人要注意訴訟時效，關于隨時履行受不受訴訟時效的制約目前仍有爭議，不過最好在時效以內主張權利。

（４）履行費用負擔不明確的，由履行義務一方負擔。履行費用是履行義務過程中各種附隨發生的費用。在合同中應該考慮各種費用的分擔，如果沒有約定，視為由履行義務一方承擔。以上關于處理各種條款不明情況的法定標準，是根據長期交易形成的規律確定下來的，不管對誰有利和不利，都得按這個規定去履行。當然，最好還是把合同條款定的明確而嚴密些。１、主要內容（階段）

合同前期管理------合同談判、合同簽訂

合同執行期管理------合同履行、合同變更、合同終止 合同收尾管理--------合同收尾

2、可能會出現的問題

合同沒訂好，沒有就具體完成的工作形成明確清晰的條款 甲方沒有對需求及其變更進行統一的組織和管理 缺乏客戶/用戶參與

甲方無法進行跨部門協調

在合同各階段進行范圍管理（應對措施）合同談判階段：

１、取得明確的工作說明書或更細化的合同條款 ２、在合同中明確雙方的權力和義務，尤其是變更

３、采取措施，確保合同簽約雙方對合同的理解是一致的 計劃階段

編制項目范圍說明書

創建項目的工作分解結構

制定項目的范圍管理計劃 執行階段

在項目執行過程中加強對已分解的各項任務的跟蹤記錄 建立與項目干系人進行溝通的統一渠道 建立整體變更控制的規程并執行

加強對項目階段性成果的評審和確認 項目全生命周期范圍變更管理

在項目管理體系中應該包含一套嚴格、實用、高效的變更程序

規定對用戶的變更請求應正視提出變更申請，并經雙方項目經理審核后，視不同情況，作出相應處理合同和詳細范圍說明書的作用

合同是買賣雙方形成的一個共同遵守的協議，賣方有義務提供合同制定的產品和服務，而買房則有義務支付合同規定的價款

項目范圍說明書詳細描述了項目的可交付物和產生這些可交付物所必須做的項目工作 合同是制定項目范圍說明書的依據（10）采購管理----重點注意招投標 編制采購計劃

對采購作出計劃，以確定哪些項目需求可以通過采購產品、服務或成果。編制采購計劃需要解決的問題是：是否需要采購、如何采購、采購什么、采購多少以及何時采購。

用于采購計劃編制工作的技術和方法主要有自制、外購決策分析，以及專家咨詢 工作說明書與項目范圍說明書的區別：

工作說明書(SOW)是項目對所要提供的產品、成果或服務的描述。SOW與范圍說明書的區別是在于，工作說明書市對項目所要提供的產品或服務的敘述性的描述，項目范圍說明書則通過明確項目應完成的工作而確定了項目的范圍。

工作說明書應相當詳細地規定采購項目，以便潛在的賣方確定他們是否有能力提供這些項目。項目范圍說明書描述了項目的可交付物和產生這些可交付物所必須進行的項目工作，項目范圍說明書在所有項目干系人之間建立了一個對項目范圍的共識，描述了項目的主要目標。詢價

詢價就是從潛在的供應商處獲得項目建議書（項目方案）或標書。招標

按照《中華人民共和國招投標法》，可以分為招標、投標、開標、評標、中標、簽訂合同等過程，招標有可以分為邀請招標和公開招標。公開招標，是指招標人在指定的報刊、電子網絡或其他媒體上發布招標公告，吸引眾多的企業單位參加投標競爭，招標人從中優化選擇中標單位的招標方式。邀請招標，也稱選擇性招標，由招標人根據潛在供應商的資信和業績，選擇一定數目的法人或其他組織（一般不能少于3家），向其發出招標邀請書，邀請他們參加投標競爭。開標

應該在招標文件確定的提交投標文件截止時間的同一時間公開進行，開標地點應該為招標文件中預先確定的地點。開標由招標人主持，邀請所有投標人參加。評標

應有業主組織的評標委員會在開標后獨立進行。評標委員會由招標人的代表和有關技術、經濟等方面的專家組成，成員為5人以上單數，其中技術、經濟等方面的專家不得少于成員總數的2/3.決標：即最后決定中標人。通常由招標機構和業主共同商討決定中標人。

授標：中標人確定后，招標人應當向中標人發出中標通知書，并同時將中標結果通知所有未中標的投標人。

招標人和招標人應當自中標通知書發出之日起三十日內，按照招標文件和中標人投標文件訂立書面合同

幾個法律規定的日期

在招標文件要求提交投標文件截止時間至少十五日前，招標人可以以書面形式對發出的招標文件進行必要的澄清或者修改

招標人有權也應當對在招標文件要求提交的截止日期后送達的投標文件拒收

依法必須進行的招標項目，自招標文件開始發出之日起至提交投標文件截止之日止，最短不得少于二十日

（11）文檔文和配置管理，比較重要要搞懂，喜歡喝變更一起考 配置管理是為了系統的控制配置變更，在系統的整個生命周期中維持配置的完整性和可跟蹤性，而標識系統在不同時間點上配置的學科，配置管理包括四個主要活動：配置識別、變更控制、狀態報告和配置審計

配置庫可以分成動態庫（開發庫、程序員庫、工作庫）、受控庫（主庫）、靜態庫（軟件倉庫）和備份庫4種類型

（1）動態庫：也稱為開發庫、程序員庫或工作庫，用于保存程序員當前正在開發的配置實體。動態庫通常包括新模塊、文檔、數據元素或進行修改的已有元素。動態庫是軟件工程師的工作區，由工程師控制

（2）受控庫：也稱主庫或系統庫，是用于管理當前基線和控制對基線的變更。受控庫包括配置單元和被提升并集成到配置項中的組件。軟件工程師和其它人員可以自由的復制受控庫中的組件或單元，然而，必須有適當的權限授權變更。受控庫中的單元或組件用于創建集成、系統和驗收測試或對用戶發布的構建

（3）靜態庫：也稱軟件倉庫或軟件產品庫，用于存檔各種廣泛使用的已發布的基線；靜態庫用于控制、保存和檢索主媒介

（4）備份庫：包括制作軟件和相關構架、數據和文檔的不同版本的復制品。在各點的及時備價。可以每天、每周或每月實行備份 １、制定配置管理計劃

在項目啟動階段，項目經理首先要制定整個項目的開發計劃，它是整個項目研發工作的基礎?？傮w研發計劃完成后，配置管理的活動就可以展開了，如果不在項目開發之初制定項目配置管理計劃，那么配置管理的許多關鍵活動就無法及時有序的進行，而它的直接后果就是造成項目開發狀態的混亂，并注定使項目管理活動成為一種救火的行為。由此可見，在項目啟動階段制定項目配置計劃是項目成功的重要保證。配置管理計劃由CMO制定，主要內容是制定配置管理策略，編寫配置管理計劃，評審配置管理計劃。

２、配置識別與建立基線 ３、建立配置管理系統 ４、版本管理

５、配置狀態報告 ６、配置審核

（12）變更管理—項目管理過程中，一切可能會變更。要重點掌握 變更的常見原因：

（1）產品范圍（成果）定義的過失或疏忽（2）項目范圍（工作）定義的過失或疏忽（3）增值變更

（4）應對風險的緊急計劃或回避計劃

（5）項目執行過程與項目基準要求不一致帶來的被動調整（6）外部事件

變更管理的基本原則：

變更管理的原則是首先建立項目基準、變更流程和變更控制委員會（也叫變更管理委員會）。包括以下內容：

（１）基準管理。基準是變更的依據。在項目實施工程中，基準計劃確定并經過評審后（通常用戶應參加部分評審工作），建立初始基準。此后每次變更通過評審后，都應重新確定基準。

（２）建立變更控制流程。建議或選用符合項目需要的變更管理流程，所有變更都必須遵循這個控制流程進行控制。流程的作用在于將變更的原因、專業能力、資源運用方案、決策權、干系人的共識和信息流轉等元素有效地綜合起來，按科學的順序進行。

（３）明確組織分工。至少應明確變更相關工作的評估、評審和執行的職能。

（４）完整體現變更的影響。變更的來源是多樣的，即需要完成對客戶可視的成果、交付期等變更

操作，還需要完成對客戶不可視的項目內部工作的變更，如實施方的人員分工、管理工作和資源配置等。

（５）妥善保存變更產生的相關文檔，確保其完整、及時、準確、清晰，適當的時候可以引入配置管理工具。國內使用較多的配置工具有 Rational ClearCase、Visual SourceSafe和Concurrent Versions System。項目變更控制委員會或更完整的配置控制委員會（Configuration Control Board,CCB），或相關職能的類似情況，是項目的所有者權益代表，負責裁定接受哪些變更，CCB由項目所涉及的多方人員共同組成，通常包括用戶和實施方的決策人員。變更的程序：

(1)提出與接受變更申請

變更提出應當及時以正式方式進行，并留下書面記錄，變更的提出可以是各種形式，但在評估前應以書面形式提出。（2）對變更的初審 變更初審的目的如下：

①對變更提出方施加影響，確認變更的必要性，確保變更是有價值的。②格式檢驗，完整性校驗，確保評估所需信息準備充分。③在干系人間就提出供評估的變更信息達成共識。④變更初審的常見方式為變更申請文檔的審核流轉。（3）變更方案論證

變更方案的主要作用，首先是對變更請求是否可實現進行論證，如果可能實現，則將變更請求由技術要求轉化為資源需求，以供CCB決策。常見的方案內容包括技術評估和經濟評估，前者評估需求如何轉化為成果，后者評估價值和風險。（4）項目變更控制委員會審查

審查過程，是項目所有者據變更申請及評估方案，決定是否批準變更。評審過程常包括客戶、相關領域的專業人士等。審查通常是文檔會簽形式，重大的變更審查可以包括正式會議形式。審查過程應注意分工，項目投資人雖有最終的決策權，但通常在專業技術上并非強項。所以應當在評審過程中將專業評審、經濟評審分開，對涉及項目目標和交付成果的變更，客戶的意見應放在核心位置。（5）發出變更通知并開始實施

評審通過，意味著項目基準的調整，同事確保變更方案中的資源需求及時到位。項目基準的調整，包括項目目標的確認、最終成果、工作內容和資源、進度計劃的調整。需要強調的是，變更通知后，不只是包括實施項目基準的調整，更要明確項目的交付日期、成果對相關干系人的影響。如變更造成交付期的調整。應在變更確認時發布，而非在交付前公布。（6）變更實施的監控 要監控的，除了調整過的項目基準中所涉及變更的內容外，還應當對項目的整體基準是否反映項目實施情況負責。通過監控行動，確保項目的整體實施工作是受控的。變更實施的過程監控，通常由項目經理負責項目基準的監控。管理委員會監控變更明確的主要成果、進度里程碑等，可以委托監理單位承擔監控職責。

（7）變更效果的評估

變更評估可以從以下幾個方面進行。①首要的評估依據，是項目基準。

②還需結合變更的初衷來看，變更所要達到的目的是否已達成。

③評估變更方案中的技術論證、經濟論證內容與實施過程的差距并推進解決。（8）判斷發生變更后的項目是否已納入正常軌道

項目基準調整后，需要確認的是相應的資源配置和人員是否及時到位，更需多加關注。之后對項目的整體監控應按新的項目基準進行，涉及變更的項目范圍及進度，在變更后的緊鄰監控中，應更多地關注，當確認新的項目基準已經生效則按正常的項目實施流程進行。有可能的問題：

１、對用戶的要求未進行記錄

２、對變更的請求未進行足夠的分析，也沒有獲得批準 ３、在修改的過程中沒有注意進行版本管理

４、修改完成后未進行驗證

５、修改的內容未和項目干系人進行溝通 導致的后果

１、缺乏對變更請求的記錄可能會導致對產品的變更歷史無法追溯，并會導致對工作產物的整體變化情況失去把握

２、缺乏對變更請求的分析可能會導致后期的變更工作失誤

３、在修改過程中不注意版本管理，一方面可能會導致當變更失敗時無法進行復原；另一方面，對于組織財富和經驗的積累也是不利的

４、修改完成后不進行驗證則難以確認變更是否正確實現

５、未與項目干系人進行溝通可能會導致項目干系人的工作之間出現不一致之處（13）風險管理----稍微重點掌握下

項目風險管理就是項目管理班子通過風險識別、風險估計和風險評價，并以此為基礎合理地使用多種管理方法、技術和手段對項目活動涉及的風險實行有效的控制，采取主動行動，創造條件，盡量擴大風險事件的有利結果，妥善地處理風險事故造成的不利后果，以最少的成本保證安全、可能地實現項目的總目標。簡單地說，項目風險管理就是指對項目風險從識別到分析、評價乃至采取應對措施等一系列過程，它包括將積極因素所產生的影響最大化和使消極因素產生的影響最小化兩方面的內容。項目風險管理過程包括如下內容：

①風險管理規劃：決定如何進行、規劃和實施項目風險管理活動。②風險識別：判斷哪些風險會影響項目，并以書面形式記錄其特點。

③定性風險分析：對風險概率和影響進行評估和匯總，進而對風險進行排序，以便于隨后的進一步分析或行動。

④定量風險分析：就識別的風險對項目總體目標的影響進行定量分析。⑤應對計劃編制：針對項目目標制定提高機會、降低威脅的方案和行動。

⑥風險監控：在整個項目生命周期中，跟蹤已識別的風險、預測殘余風險、識別新風險、實施風險應對計劃，并對其 有效性進行評估。

風險的特性：客觀性、不確定性、隨機性、相對性、可變性、階段性 風險管理計劃編制

工具：風險核對表、風險管理表格、風險數據庫模式

輸入：企業環境因素、組織過程資產、項目范圍說明書、項目管理計劃 風險識別主要內容包括：

１、識別并確定項目有哪些潛在風險：（風險識別的第一目標）２、識別引起這些風險的主要因素：（風險識別的第二目標）

３、識別項目風險可能的后果。（風險識別的第三目標，采用定性分析）工具和方法： １）文件審查

２）信息收集技術：

德爾菲法（有助于減少數據方面的偏見）

頭腦風暴法（也叫集思廣益法，充分發揮集體智慧，提高風險識別的正確性和效率）訪談法

３）檢查表：檢查表的一個優點是它使風險識別工作快而簡單，它的不足之處在于我們不可能編制一個詳盡的風險價差表，檢查表的使用者可能會被表中的條目局限。４）假設分析 ５）圖解技術

因果圖：也叫石川圖或魚刺圖，用于識別風險的成因。

系統或過程流程圖：反映某一系統內部各要素之間是如何項目聯系的，并反映發生的聯系機制 輸出：風險記錄

? 已識別的風險列表

? 風險的征兆或警告信息 ? 潛在風險應對方法列表

? 風險根本原因 ? 更新的風險分類 項目管理計劃（更新）定性風險分析

風險定性分析包括對識別風險進行優先級排序，風險定性分析是建立風險響應計劃優先級的快速有效的方法，為定量分析奠定基礎。定性風險分析的方法：

１）風險概率與影響評估 ２）概率和影響矩陣 ３）風險數據質量評估 ４）風險分類

５）風險緊迫性評估 定量風險分析

定量風險分析是指對定性風險分析過程中作為項目需求存在的重大影響而排序在先的風險進行分析，并就風險分配一個數值。定量風險縫隙是在不確定情況下進行決策的一種量化方法，該過程采用蒙特卡羅模擬以及決策樹分析等技術。風險應對計劃編制

輸入：風險管理計劃、風險記錄 工具和技術：

１、負面風險（消極風險、或威脅）的應對策略：1）規避2）轉移3）減輕 ２、正面風險（積極風險、或機會）的應對策略：1）開拓2）分享3）提高 風險監控

風險監控的目標：

１）識別和度量項目的風險

２）努力避免項目風險事件的發生

３）積極消除項目風險事件的消極后果 ４）重新吸取項目風險管理經驗和教訓 風險管理可能出現的問題 １、項目范圍的風險 ２、項目進度的風險

３、項目人力資源的風險 ４、項目質量的風險 ５、客戶方面的風險 風險管理應對措施

１、項目范圍盡可能清晰的界定

２、項目進度制定需要充分考慮各種潛在因素，適當留有余地和柔性

３、合理利用趕工及快速跟進等方法，充分利用資源，爭取保質保量完成任務 ４、實施雙方因對人員認真的評估，制定適當的獎勵措施 ５、對用戶進行培訓，讓用戶的需求更加合理（14）收尾管理----稍微重點掌握下

項目收尾階段是以某種正式的活動作為結束標志：主要是完成項目交付成果的檢驗，由承建方將完成的成果交與用戶方，業主（用戶）確認成果符合合同規定。項目收尾工作的另一重要內容是從項目中獲得相關經驗，以便指導和改善未來項目的運作和實施。項目收尾的具體內容主要是項目驗收、項目總結和項目評估審計。

項目的正式驗收包括驗收項目產品、文檔及已經完成的交付成果。

驗收需要正式的驗收報告。對于系統集成項目，一般來講，需要正式的驗收測試工作。驗收測試工作可以由業主和承建單位共同進行，也可以由第三方公司進行，但無論哪種方式都需要雙方認可的正式文檔為依據進行驗收測試。

如果驗收測試未獲通過，則應立即查找原因，一般會轉向變更環節進行修改和補救，如果項目驗收測

試正式通過，則標志著項目驗收的完成。通常，系統集成項目的驗收工作包括： １、系統測試

２、系統的試運行 ３、系統的文檔驗收

４、項目的最終驗收報告 項目總結

項目總結屬于項目收尾的管理收尾。而管理收尾有時又被稱為行政收尾，就是檢查項目團隊成員及相關干系人是否按規定履行了所有責任。實施行政結尾過程還包括收集項目記錄、分析項目成敗、收集應吸取的教訓、以及將項目信息存檔供本組織將來使用等活動統一為一個整體。項目總結內容和意義

① 了解項目全過程的工作情況及相關的團隊或成員的績效狀況。② 了解出現的問題并進行改進措施總結。

③ 了解項目全過程中出現的值得吸取的經驗并進行總結。

④ 對總結后的文檔進行討論，通過后即存入公司的知識庫，從而納入企業的過程資產。項目評估、審計

項目評估的意義是將項目的所有工作加以客觀的評價，從而對項目全體人員的成果形成績效結論。好的項目評估會引導后續項目的開展，并對項目過程的改進起到很重要的作用。項目的審計應由項目管理部門與財務部門共同進行，相關的審計項目應在項目成本管理中列出。在項目收尾的時候，對已經列出的支出和收入進行財務審計，對不合理的支出和收入加以分析，為改進項目的管理服務。

存在的問題，如何補救，項目總結的主要內容是什么？（2011年5月的考點）（15）服務管理----稍微重點掌握下

計算機信息系統集成的資質是指從事計算機信息系統集成的綜合能力，包括技術水平、管理水平、服務水平、質量保證能力、技術裝備、系統建設質量、人員構成與素質、經營業績、資產狀況等要素。計算機系統集成資質等級由高到低依次分為一級、二級、三級和四級。監理單位資質由高到低分為甲、乙、丙三個等級。

監理工作的主要內容可以概括為：“四控三管一協調”，即投資控制、進度控制、質量控制、變更控制；合同管理、信息管理、安全管理；溝通協調。

《資質證書》有效期為4年，獲證單位每年進行一次自查，并將自查結果投資認證工作辦公室備案；資質認證工作辦公室對獲證單位每兩年進行一次年檢，每4年進行一次換證檢查和必要的非例行監督檢查。檢查結論分為“通過”“降級”和“取消”三種，每兩年對系統集成項目經理進行一次年審，年審結論分為“合格”“不合格”和“不在崗”三種，一次年審“不合格”或“不在崗”者，降低其資質等級一次，連續兩次年審結論為“不合格”者，取消其資質。連續兩次年審結論為“不在崗”者，需重新申請資質。逾期不參加年審者，視為自動放棄資質。被降低資質等級的系統集成項目經理，一年以后才能重新申請原資質等級，被取消系統集成項目經理資質證書的，兩年以后才能重新申請系統集成項目經理資質。

《信息系統工程監理資質證書》有效期為4年，屆滿4年更換新證。甲級、乙級資質由工業和信息化部負責年檢，丙級由省市信息產業主管部門負責年檢。

信息系統工程實行總監理工程師負責制，總監理工程師行使合同賦予監理單位的權限。當前我國信息系統服務管理的重要內容如下： 計算機信息系統集成單位資質管理 信息系統項目經理資質管理

信息系統工程監理單位資質管理 信息系統工程監理人員資質管理

IT項目審計是指對IT項目的規劃、開發、實施、運行和維護等各個環節進行評價，確保其符合企業經營目標的過程。

信息系統安全的特性：信息的完整性、可用性、保密性、抗抵賴性、可控性（其中完整性、可用性和保密性為基本安全特性要求）。

【案例分析】

J公司是一家系統集成公司，最近公司簽訂了應急項目的合同，是以公司自主產品為主的解決方案，但主方案為在開發產品，包含中心和前端設備種類很多。需要挑選一位項目經理，組建一個項目團隊。由于公司正同步進行多個項目，沒有足夠數量的項目經理，而該項目又必須馬上開始，于是公司領導決定任命L擔任此項目的管理工作。L接到任命后，立即開始著手組建項目團隊，對團隊進行任命，唯一沒有任命生產環節的負責人。產品還在不斷的開發過程中，但是項目實施工期在進一步逼近。采購的設備要到4月中旬才到公司，多設備的聯合調試還要在4月底進行，5月中旬完成設備到現場的任務。

問題1：請問項目本案例中出現幾個問題項目管理相關的問題？

問題2：如果你被臨時委托生產的負責人你應該怎么做才能滿足項目整體連接調試和發貨的需求？ 問題3：如果你是項目經理應該如何制定項目計劃 【案例的分析】

問題1：在該案例中，出現了以下問題。① J公司對項目經理的選擇出現了一些問題 ② 項目團隊組建有重要的紕漏，對自主產品和公司的工作流程不了解。③ 在設備采購的時候沒有進行很好的把控，使大量的任務不能提前實施。④ 整體計劃過于理想化。沒有留出應急的時間，沒有對風險進行分析和規避，產品為正在開發的產品有很多東西需要驗證。

問題2：如果我是生產的負責人應該怎么做： ① 溝通項目經理和項目上下環節的干系人，明確工作范圍和工作說明； ② 將工作結構分解：創建WBS將工作需求分解，進行活動排序以及資源估算。制定進度計劃表。③ 根據進度計劃表，采取必要的措施，如：采取外包、增加資源、快速跟進的方式解決整體聯調以及供貨的時間問題，盡快的趕進度。（由于產品在不斷的開發中完善，所有并行的方式為解決進度問題的最佳方案）

問題3：項目的整體管理計劃內容：

作為本項目的負責人在制定本項目整體計劃的內容： ① 應包含項目整體介紹或概述包括：項目名稱，項目以及項目所需滿足需求的簡單描述，發起人的名稱，項目經理與主要成員的姓名，項目可交付成果，重要資料清單。② 項目組織情況的描述包括：組織結構圖，項目責任，其他與組織或過程相關的信息。③ 項目計劃中用來描述項目的管理和方法主要包括：管理目標，項目控制，風險管理，項目人員，技術過程。④ 項目計劃中用來描述項目任務的那部分應當參考范圍管理計劃的內容，主要包括：主要可交付成果，與工作有關的其他信息。⑤ 項目進度信息部分主要包括：進度概要，進度細要，與進度有關的信息。⑥ 項目計劃整體項目預算主要包括：預算概要，預算細要，與預算相關的其他信息。

第二篇：系統集成項目集成工程師考試知識點掌中寶

1信息化基礎知識2信息系統服務管理3信息系統集成專業技術知識4項目管理的一般知識5立項管理6項目整體管理7項目范圍管理8項目進度管理 9項目成本管理10項目質量管理11項目人力資源管理12項目溝通管理13項目合同管理14項目采購管理15信息文檔和配置管理16變更管理17信息系統安全管理18項目風險管理19項目收尾管理

1)信息化基礎知識

1信息化基礎知識：國家信息化體系要素:1信息技術應用2信息資源3信息網絡4信息技術和產業5信息化人才6信息化政策法規和標準規范

2我國信息化發展的戰略要點:1推進國民經濟信息化2推行電子政務3建設先進網絡文化4推進社會信息化5完善綜合信息基礎設施6加強信息資源的開發利用7提高信息產業競爭力8建設國家信息安全保障體系9提高國民信息技術應用能力，造就信息化人才隊伍 3商業智能：商業智能的三個層次:1數據報表2多維數據分析3數據挖掘 2)信息系統服務管理

1信息系統服務管理體系1計算機信息系統集成單位資質管理：一級、二級、三級、四級系統集成企業；2信息系統項目經理資格管理：項目經理、高級項目經理、資深項目經理3具有信息產業部頒發的《計算機信息系統集成資質證書》（一級或二級）作為“涉密系統集成單位”4利用財政性資金建設的信息化工程，用于購買軟件產品和服務的資金原則上不得低于總投資的30%。

2信息系統工程監理

（1信息系統工程監理單位資質管理：甲、乙、丙三級監理企業 甲級：被監理項目沒有投資規模限制；乙級：被監理項目投資規模在1500萬元以下；丙級：被監理項目投資規模在500萬元以下；

（2信息系統工程監理人員資格管理：高級監理工程師;監理工程師;監理員；（3監理內容：四控：工程質量控制；工程進度控制；工程投資控制；工程變更控制；三管：工程合同管理；工程信息管理；工程安全管理；一協調：協調有關單位及人員之間的工作關系；

（4以質量為中心的信息系統工程控制管理工作是由三方：建設單位（主建方）、集成單位（承建單位）和監理單位分工合作實施的。ITIL 與IT服務管理

（1 20世紀80年代英國商務部提出信息技術基礎結構庫（ITIL）；（2ITIL是有關IT服務管理流程的最佳實踐；

（3實施IT服務管理（IT Service Management, ITSM）的根本目標：以客戶為中心提供IT服務;提供高質量、低成本的服務;提供的服務是可以準確計價的。4信息系統審計

信息系統審計的目的是評估并提供反饋、保證及建議。其關注之處可被分為如下三類:可用性;保密性;完整性 3)信息系統集成專業技術知識

1信息系統集成分類:設備系統集成：智能建筑系統集成，計算機網絡系統集成，安防系統集成;應用系統集成 2信息系統建設

信息系統的生命周期：（1立項階段：概念形成過程和需求分析過程（2開發階段：總體規劃、系統分析、系統設計、系統實施、系統驗收（3運維階段：維護四種類型（排錯性維護、適應性維護、完善性維護、預防性維護）（4消亡階段 6信息系統開發的方法：（1結構化方法：開發過程分成若干階段、依次執行，每個階段又分成若干作業步驟順序作業。其優點：用戶需求在系統建設前被充分了解和理解，注重開發過程的整體性和全局性。其缺點：開發周期長；文檔、設計說明繁瑣；充分預料各種可能的變化并不現實；如果用戶參與程度不高，容易造成系統交接過程不平穩，系統運行與維護管理難度加大。（2原型法：根據對用戶需求的初步理解，先快速開發一個原型系統，然后反復修改來實現用戶的最終系統需求。原型發適合于用戶需求開始時定義不清、結構化程度不高的系統開發。此方法更易于被客戶接受，但如果用戶配合不好，盲目修改，會

拖延開發過程。原型法分為：（1）拋棄型原型（2）進化型原型

（3 面向對象方法：客觀事務由對象組成；對象由屬性和操作組成；對象之間的聯系通過消息傳輸機制來實現，對象可以按其屬性來歸類，子類可以繼承其父類的特性；對象具有封裝的特性；面向對象開發方法主要有分析、設計和實現三個階段。三個階段的界限并非十分明確。在系統的實際開發中，往往根據需要將多種開發方法進行組合應用，最終完成系統開發的全部任務。

4)項目管理的一般知識 1項目的目標：SMART原則：S（Specific 具體）M（Measurable可測量）A（Agree to 達成一致）R（Realistic 現實）T（Time-oriented 有一定時限的）項目目標特性：優先級、多目標性、層次性 2項目的特點：臨時性、獨特性、漸進明細性；傳統意義上的項目三個約束：時間、成本、質量；近幾年的觀點：“范圍、時間和成本”；最新的觀點認為項目成功受“范圍、時間、成本、質量”4個方面的約束；

3項目管理通過執行一系列相關過程來完成，這些過程分布在：核心知識域、保障域、伴隨域和過程域中。核心知識域：整體管理、范圍管理、進度管理、成本管理、質量管理和信息安全管理

保障域：人力資源管理、合同管理、采購管理、風險管理、信息（文檔）與配置管理、知識產權管理、法律法規標準規范和職業道德規范

伴隨域：變更管理和溝通管理

過程域：立項、啟動、計劃、實施、監控和收尾

IPMA、PMI以及項目管理在中國的發展：國際項目管理資質標準（ICB）是國際項目管理協會（IPMA）建立的知識體系，IPMP資質認證分為（A級、B級、C級、D級4個級別）。

項目管理知識體系（PMBOK）是美國項目管理協會（PMI）建立的知識體系，PMP認證只有一個級別，與IPMA的C級相當。4對項目經理的一般要求：足夠的知識、豐富的項目管理經驗、良好的溝通和協調能力、良好的職業道德、一定的領導和管理能力。

5項目干系人：項目干系人也叫“項目利益相關者”“項目利害關系者”。項目管理團隊必須識別項目干系人，確定其需求和期望，然后對這些期望進行管理并施加影響以確保其成功。6項目的組織方式： 職能型組織：其優點在于：強大的技術支持，便于知識、技能和經驗的交流；清晰的職業生涯晉升路線；直線溝通、交流簡單、職責和權限清晰；有利于重復性工作為主的管理過程。其缺點在于：職能利益優先于項目，具有狹隘性；組織橫向之間聯系薄弱、部門之間協調難度大；項目經理極少或缺少權利、權威；項目發展方向不明等。

項目型組織：其優點在于：結構單一，責權明確，利于統一指揮；目標明確單一；溝通簡潔、方便；決策快。其缺點在于：管理成本高，如項目的工作量不足則資源配置效率低；項目環境比較封閉，不利于溝通、技術知識共享等；員工缺乏事業上的連續性和保障等。矩陣型組織：其優點在于：項目經理負責制，有明確的項目目標，改善了項目經理對整體資源的控制，獲得職能組織更多的支持，能最大限度地利用公司的稀缺資源，改善了跨不同職能部門之間的協調合作，團隊成員有歸屬感，士氣高，問題少。其缺點在于：管理成本增加，多頭領導，難以監測和控制，資源分配與項目優先的問題產生沖突，權利難以保持平衡等。復合型組織：根據工作需要，一個組織在運作項目時，或多或少地同時包含上述三種組織形式，這就構成了復合型組織。7PMO在組織結構中的作用：項目管理辦公室（PMO）是在所轄范圍內集中、協調地管理項目的組織單元。根據需要可以為一個項目設立一個PMO，可以為一個部門設立一個PMO，也可以為一個企業設立一個PMO。項目的生命周期：項目的生命周期定義了從項目開始到項目結束的項目階段。階

段的交付物通常要經過技術正確性的評審，并在下一階段開始前得到批準。階段之間要完成技術交接或移交。每個階段都是以一個或一個以上的交付物的完成為標志，這種交付物是一種可度量、可驗證的工作結果。項目階段的結束一般以對完成的工作和可交付物的技術和設計評審為標志。典型的信息系統項目的生命周期模型：瀑布模型：是一種經典的軟件生命周期模型，一般將軟件開發分為：可行性分析、需求分析、軟件設計、編碼、測試、運行維護等幾個階段。

V模型：其價值在于其非常明確地標明了測試過程中存在的不同級別，并清楚描述了這些測試階段和各開發階段的對應關系。

原型化模型：其是為彌補瀑布模型的不足而產生的。建造一個快速原型，以便和用戶針對原型進行討論和交流。

螺旋模型：在螺旋模型中，軟件開發是一系列的增量發布。迭代模型：軟件生命周期時間上被分為4個順序階段，分別是：初始階段、細化階段、構建階段和交付階段。每個階段從核心過程工作流“商業建模”、“需求調研”“分析設計”執行到“部署”，再從核心支持工作流“配置與變更管理”、“項目管理”執行到“環境”從而完成依次迭代。根據需要，在一個階段內部，可以完成一次到多次的迭代。

10項目的管理過程：一般來說，要把一個項目管好，至少需要4種過程：技術類過程、管理類過程、支持類過程和改進類過程。戴明的PDCA（計劃、行動、檢查、改進）與項目管理過程組的對應.5個項目過程組：啟動過程組、計劃編制過程組、執行過程組、監督與控制過程組、收尾過程組。

啟動過程組包括：制定項目章程、制定初步的項目范圍說明書。（共2個流程）計劃過程組包括：制定項目管理計劃，編制項目范圍管理計劃，范圍定義，創建工作分解結構，活動定義，活動排序，活動資源估算，活動歷時估算，制定進度計劃，成本估算，成本預算，制定項目的質量管理計劃，制定項目人力資源管理計劃，制定項目溝通管理計劃，制定項目風險管理計劃，風險識別，風險定性分析，風險定量分析，制定風險應對計劃，制定項目采購管理計劃，編制合同。（共21個流程）執行過程組包括：指導與管理項目執行，執行質量保證，團隊組建，團隊建設，信息發布，詢價，供方選擇。（共7個流程）監督和控制過程組包括：監督和控制項目工作，整體變更控制，范圍確認，范圍變更控制，進度控制，成本控制，質量控制，管理項目團隊，績效報告，管理項目干系人，風險監督和控制，合同管理。（共12個流程）

收尾過程組包括：項目收尾、合同收尾。（共2個流程）

項目組合和項目組合管理：項目組合管理的目標就是通過對準備納入到項目組合的候選項目和大型項目的仔細檢查、定期排除不滿足項目組合戰略目標的項目，以最大化項目組合的價值。5)立項管理

1立項管理的內容：需求分析：確定待開發的信息系統應該“做什么”。項目建議書：是項目建設單位向上級主管部門提交項目申請時所必須的文件，是對擬建項目提出的框架性的總體設想。項目可行性研究報告：一般應包括投資必要性、技術可行性、財務可行性、組織可行性、經濟可行性、社會可行性、風險因素及對策。建設方項目的立項：立項申請書的編寫、申報和審批

項目的可行性研究:(1初步可行性研究：在項目意向確定之后，對項目的初步估計。(2詳細可行性研究：包括經濟評價法、市場預測法、投資估算法和增量凈效益法。(3項目論證：對擬實施項目技術上的先進性、適用性、經濟上的合理性、盈利性、實施上的可能性、風險可控性進行全面科學的綜合分析。(4項目評估：項目評估是指項目在可行性研究的基礎上，由第三方（國家、銀行或有關機構）對項目進行評價、分析和論證，進而判斷其是否可行的一個評估過程。項目評估法和全局評估法;總量評估法和增量評估法;

費用效益分析法;成本效用分析法;多目標系統分析法(5項目可行性研究報告的編寫、提交和獲得批準 項目招標:(1 招標：招標分為公開招標和邀請招標；招標程序；制定招標文件；制定招標評分標準；(2 投標：1）編制標書；2）遞交標書；3）標書的簽收

(3評標：評標委員會由具有高級職稱或同等專業水平的技術、經濟等相關領域專家、招標人和招標機構代表等5人以上單數組成；其中技術、經濟等方面的專家人數不得少于成員總數的2/3；評標委員會成員名單在評標結果前必須保密；

(4 選定項目承建方:自中標通知書發出之日起30日內，招標人和中標人訂立書面合同；中標通知書對招標人和中標人具有法律效力。

3承建方項目的立項：項目識別：是承建方項目立項的第一步，其目的在于選擇投資機會、鑒別投資方向。

項目論證：承建方技術可行性分析;承建方人力資源及其它資源配置能力可行性分析;項目財務可行性分析;項目風險分析;對可能的其他投標者的相關情況分析;投標：獲取招標文件、編寫投標文件、參加投標活動

4簽訂合同合同談判：在確定中標人后，即進入合同談判階段。合同談判的方法一般是先談技術條款，后 談商務條款。簽訂合同：投標人和中標人應當自中標通知書發出之日起30日內，按照招標文件和中標人的投標文件訂立書面合同。

6)項目整體管理

項目整體管理過程負責項目的全生命周期管理、全局性管理和綜合性管理。項目整體管理的過程包括如下7個內容：1項目啟動（制定項目章程）2制定初步的項目范圍說明書3制定項目管理計劃4指導與管理項目執行5監督和控制項目6整體變更控制7項目收尾。

1項目啟動（制定項目章程）：以書面、正式的形式肯定項目的成立與存在，同時以書面的形式為項目經理授權。工作說明書（SOW）是對項目所要提供的產品、成果或服務的描述。環境和組織的因素：包括實施單位的企業文化和組織結構、國標或行業標準、現有的設施和固定資產等基礎設施、當時的市場情況、干系人對風險的承受能力等。組織過程資產包括：項目實施組織的企業計劃、政策方針、規程、指南和管理系統，實施項目組織的知識和經驗教訓。項目管理信息系統（PMIS）：是組織內可用的系統化的自動化工具集。2編制項目范圍說明書（初步）：明確項目及其相關產品和服務的特性和邊界，以及范圍控制和驗收的方法

3制定項目管理計劃：定義、準備、集成和協調所有分計劃，明確了如何執行、監督和控制以及如何收尾項目。項目計劃編制的基本原則：目標的統一管理；方案的統一管理；過程的統一管理;技術工作與管理工作的統一協調；計劃的統一管理；人員資源的統一管理；各干系人的參與；逐步精確；

4指導和管理項目執行：對項目的執行進行統一協調的管理，把握項目實施的全局。

5監督和控制項目：是全面地追蹤、評審和調節項目的進展，以滿足在項目管理計劃中確定的績效目標的過程。6整體變更控制：整體變更控制過程貫穿于整個項目過程的始終。對項目范圍說明書、項目管理計劃和其他項目可交付物必須進行變更管理。

基準：也叫基線，Baseline，被批準的項目管理計劃就是項目的基準。變更控制委員會（CCB）：批準或拒絕影響大的變更

7項目收尾：結束項目某一階段中的所有活動，正式收尾該項目階段的過程。管理收尾： 1)確認滿足干系人需求；2)確認滿足項目的完成標準；3)項目產品或者服務的移交；4)記錄歸檔項目各階段記錄、經驗教訓總結。合同收尾： 包括產品驗證和合同管理的收尾。7)項目范圍管理

其是否可行的一個評估過程。項目評估法

和全局評估法;總量評估法和增量評估法;費用效益分析法;成本效用分析法;多目標系統分析法(5項目可行性研究報告的編寫、提交和獲得批準 項目招標:(1 招標：招標分為公開招標和邀請招標；招標程序；制定招標文件；制定招標評分標準；(2 投標：1）編制標書；2）遞交標書；3）標書的簽收

(3評標：評標委員會由具有高級職稱或同等專業水平的技術、經濟等相關領域專家、招標人和招標機構代表等5人以上單數組成；其中技術、經濟等方面的專家人數不得少于成員總數的2/3；評標委員會成員名單在評標結果前必須保密；

(4 選定項目承建方:自中標通知書發出之日起30日內，招標人和中標人訂立書面合同；中標通知書對招標人和中標人具有法律效力。

3承建方項目的立項：項目識別：是承建方項目立項的第一步，其目的在于選擇投資機會、鑒別投資方向。

項目論證：承建方技術可行性分析;承建方人力資源及其它資源配置能力可行性分析;項目財務可行性分析;項目風險分析;對可能的其他投標者的相關情況分析;投標：獲取招標文件、編寫投標文件、參加投標活動

4簽訂合同合同談判：在確定中標人后，即進入合同談判階段。合同談判的方法一般是先談技術條款，后 談商務條款。簽訂合同：投標人和中標人應當自中標通知書發出之日起30日內，按照招標文件和中標人的投標文件訂立書面合同。

6)項目整體管理

項目整體管理過程負責項目的全生命周期管理、全局性管理和綜合性管理。項目整體管理的過程包括如下7個內容：1項目啟動（制定項目章程）2制定初步的項目范圍說明書3制定項目管理計劃4指導與管理項目執行5監督和控制項目6整體變更控制7項目收尾。

1項目啟動（制定項目章程）：以書面、正式的形式肯定項目的成立與存在，同時以書面的形式為項目經理授權。工作說明書（SOW）是對項目所要提供的產品、成果或服務的描述。環境和組織的因素：包括實施單位的企業文化和組織結構、國標或行業標準、現有的設施和固定資產等基礎設施、當時的市場情況、干系人對風險的承受能力等。組織過程資產包括：項目實施組織的企業計劃、政策方針、規程、指南和管理系統，實施項目組織的知識和經驗教訓。項目管理信息系統（PMIS）：是組織內可用的系統化的自動化工具集。2編制項目范圍說明書（初步）：明確項目及其相關產品和服務的特性和邊界，以及范圍控制和驗收的方法

3制定項目管理計劃：定義、準備、集成和協調所有分計劃，明確了如何執行、監督和控制以及如何收尾項目。項目計劃編制的基本原則：目標的統一管理；方案的統一管理；過程的統一管理;技術工作與管理工作的統一協調；計劃的統一管理；人員資源的統一管理；各干系人的參與；逐步精確；

4指導和管理項目執行：對項目的執行進行統一協調的管理，把握項目實施的全局。

5監督和控制項目：是全面地追蹤、評審和調節項目的進展，以滿足在項目管理計劃中確定的績效目標的過程。6整體變更控制：整體變更控制過程貫穿于整個項目過程的始終。對項目范圍說明書、項目管理計劃和其他項目可交付物必須進行變更管理。

基準：也叫基線，Baseline，被批準的項目管理計劃就是項目的基準。變更控制委員會（CCB）：批準或拒絕影響大的變更

7項目收尾：結束項目某一階段中的所有活動，正式收尾該項目階段的過程。管理收尾： 1)確認滿足干系人需求；2)確認滿足項目的完成標準；3)項目產品或者服務的移交；4)記錄歸檔項目各階段記錄、經驗教訓總結。合同收尾： 包括產品驗證和合同管理的收尾。7)項目范圍管理 個PMO。8 項目的生命周期：項目的生命周期定義了從項目開始到項目結束的項目階段。階段的交付物通常要經過技術正確性的評審，并在下一階段開始前得到批準。階段之間要完成技術交接或移交。每個階段都是以一個或一個以上的交付物的完成為標志，這種交付物是一種可度量、可驗證的工作結果。項目階段的結束一般以對完成的工作和可交付物的技術和設計評審為標志。典型的信息系統項目的生命周期模型：瀑布模型：是一種經典的軟件生命周期模型，一般將軟件開發分為：可行性分析、需求分析、軟件設計、編碼、測試、運行維護等幾個階段。V模型：其價值在于其非常明確地標明了測試過程中存在的不同級別，并清楚描述了這些測試階段和各開發階段的對應關系。原型化模型：其是為彌補瀑布模型的不足而產生的。建造一個快速原型，以便和用戶針對原型進行討論和交流。螺旋模型：在螺旋模型中，軟件開發是一系列的增量發布。迭代模型：軟件生命周期時間上被分為4個順序階段，分別是：初始階段、細化階段、構建階段和交付階段。每個階段從核心過程工作流“商業建?！?、“需求調研”“分析設計”執行到“部署”，再從核心支持工作流“配置與變更管理”、“項目管理”執行到“環境”從而完成依次迭代。根據需要，在一個階段內部，可以完成一次到多次的迭代。

10項目的管理過程：一般來說，要把一個項目管好，至少需要4種過程：技術類過程、管理類過程、支持類過程和改進類過程。戴明的PDCA（計劃、行動、檢查、改進）與項目管理過程組的對應.5個項目過程組：啟動過程組、計劃編制過程組、執行過程組、監督與控制過程組、收尾過程組。

啟動過程組包括：制定項目章程、制定初步的項目范圍說明書。（共2個流程）計劃過程組包括：制定項目管理計劃，編制項目范圍管理計劃，范圍定義，創建工作分解結構，活動定義，活動排序，活動資源估算，活動歷時估算，制定進度計劃，成本估算，成本預算，制定項目的質量管理計劃，制定項目人力資源管理計劃，制定項目溝通管理計劃，制定項目風險管理計劃，風險識別，風險定性分析，風險定量分析，制定風險應對計劃，制定項目采購管理計劃，編制合同。（共21個流程）執行過程組包括：指導與管理項目執行，執行質量保證，團隊組建，團隊建設，信息發布，詢價，供方選擇。（共7個流程）監督和控制過程組包括：監督和控制項目工作，整體變更控制，范圍確認，范圍變更控制，進度控制，成本控制，質量控制，管理項目團隊，績效報告，管理項目干系人，風險監督和控制，合同管理。（共12個流程）

收尾過程組包括：項目收尾、合同收尾。（共2個流程）

項目組合和項目組合管理：項目組合管理的目標就是通過對準備納入到項目組合的候選項目和大型項目的仔細檢查、定期排除不滿足項目組合戰略目標的項目，以最大化項目組合的價值。5)立項管理

1立項管理的內容：需求分析：確定待開發的信息系統應該“做什么”。項目建議書：是項目建設單位向上級主管部門提交項目申請時所必須的文件，是對擬建項目提出的框架性的總體設想。項目可行性研究報告：一般應包括投資必要性、技術可行性、財務可行性、組織可行性、經濟可行性、社會可行性、風險因素及對策。建設方項目的立項：立項申請書的編寫、申報和審批

項目的可行性研究:(1初步可行性研究：在項目意向確定之后，對項目的初步估計。(2詳細可行性研究：包括經濟評價法、市場預測法、投資估算法和增量凈效益法。(3項目論證：對擬實施項目技術上的先進性、適用性、經濟上的合理性、盈利性、實施上的可能性、風險可控性進行全面科學的綜合分析。(4項目評估：項目評估是指項目在可行性研究的基礎上，由第三方（國家、銀行或有關機構）對項目進行評價、分析和論證，進而判斷 項目范圍管理確定在項目內包括什么工作和不包括什么工作。對項目范圍的管理，是通過5個管理過程來實現的。（1）編制范圍管理計劃(2）范圍定義（3）創建工作分解結構（4）范圍確認(5）范圍控制

范圍包括：產品范圍和項目范圍；項目范圍是否完成以項目管理計劃、項目范圍說明書、WBS、以及WBS字典作為衡量標準；產品范圍是否完成以產品要求作為衡量標準。

1編制范圍管理計劃：用于描述如何定義項目范圍、如何制定詳細的項目范圍說明書、如何定義和編制工作分解結構，以及如何驗證和控制范圍。2范圍定義：詳細描述項目和產品的過程，并把結果寫進詳細的項目范圍說明書中。項目范圍說明書在所有項目干系人之間建立了一個對項目范圍的共同理解。項目邊界：嚴格定義了哪些事項屬于項目，哪些事項不屬于項目的范圍。約束：對項目團隊的選擇會造成限制，當一個項目按合同執行時，合同條款通常是約束條件。

假定：描述特定的與項目范圍相關的假設，以及這些假設不成立時對項目的潛在影響。

3創建工作分解結構：創建工作分解結構（WBS）是把一個項目交付物和項目工作逐步分解為更小的、更易于管理的項目單元的過程。

WBS的表示形式主要有：分級的樹形結構（結構性強，不易修改，適用于中小型項目）；列表形式（分類多，容量大，直觀性差，常用在一些大的、復雜的項目中）。一般來說，早期的，或復雜的，或大規模的項目，其WBS的分解顆粒要大一些，粗一些。滾動波式計劃：近期的工作計劃得詳細一些，遠期的工作計劃得相對粗一些。工作包：WBS的最底層的工作單元被稱為工作包（WORK PACKAGE），符合80小時原則，它是定義項目范圍、定義項目組織，設定項目產品質量和規格，估算和控制費用、估算時間周期和安排進度的基礎。

WBS字典：是WBS的配套文檔，用來描述每個WBS元素。范圍基準：項目范圍說明書、WBS、WBS字典作為項目的范圍基準。4范圍確認：范圍確認是客戶等項目干系人正式驗收并接受已完成的項目交付物的過程。范圍確認過程也被稱為范圍核實過程。項目范圍確認應該貫穿項目的始終。范圍確認與質量控制不同，范圍確認是有關工作結果的接受問題，而質量控制是有關工作結果正確與否，質量控制一般在范圍確認之前完成，當然也可以并行進行。范圍控制：監控項目狀態（工作范圍狀態和產品范圍狀態）的過程，也是控制變更的過程。不受控制的變更被稱為“范圍蔓延”。

8)項目進度管理

項目進度管理就是保證項目的所有工作都在一個指定的時間沒完成。項目進度管理包括 6個管理過程：1）活動定義2）活動排序3）活動資源估算4）活動歷時估算5）制定進度計劃6）進度控制 1活動定義：把完成項目的所有活動找出來。

把WBS最底層的工作包分解成一個個的活動是活動定義過程的最基本任務?；顒佣x后得到的活動，為進度安排、成本估算、項目執行、項目監控和控制提供了基礎。

檢查點（Checkpoint）：指在規定的時間間隔內對項目進行檢查，比較實際與計劃之間的差異，并根據差異進行調整。里程碑（Mile Stone）：完成階段性工作的標志，不同類型的項目里程碑不同?；€（Base Line）：是一些重要的里程碑，但相關交付物要通過正式評審，并作為后續工作的基準和出發點，基線一旦建立后其變化需要受控制。周例會是檢查點的表現形式，高層的階段匯報時基線的表現形式。

2活動排序：識別與記載計劃活動之間的邏輯關系。

前導圖法：用方框或長方形代表活動，它們之間用箭頭連接，顯示它們彼此之間存在的邏輯關系。

前導圖法也被稱為：PDM圖法、AON圖法、單代號網絡圖法

前導圖法包括活動之間存在的4種類型的依賴關系：（F-S，F-F，S-S，S-F）；箭線圖法：用箭線表示活動，節點表示事件。箭線圖法也被稱為：ADM圖法、AOA圖法、雙代號網絡圖法

活動的開始事件叫做該活動的“緊前事件”，活動的結束事件叫該活動的“緊隨事件”。

箭線圖法可以借助虛活動（虛線）可以更好地、更清楚地表達活動之間的關系；(1每個事件有唯一的一個代號。

(2任兩項活動的緊前事件和緊后事件代號至少有一個不相同，節點序號沿箭線方向越來越大。

(3流入（流出）同一節點的活動，均有共同的后繼（或先行活動）。三種依賴關系：強制依賴關系、可斟酌處理的依賴關系、外部依賴關系。時間的提前量與滯后量（如：FS-3，FS+3）3活動資源估算：確定在實施項目活動時要使用何種資源，每種使用的數量，以及何時用于項目計劃活動。

活動資源估算過程往往同費用估算過程緊密配合。資源分解結構（RBS）：按照資源種類和形式而劃分的資源層次結構。4活動歷時估算：估算計劃活動持續時間的過程。

歷時估算是逐步細化與完善的，估算過程要考慮數據依據的有無與質量。

活動歷時估算的方法主要包括：專家判斷：可以利用歷史數據和經驗進行分析判斷。

類比估算：從以前類似計劃活動的實際持續時間為根據，估算將來的計劃活動的持續時間。參數估算：欲完成工作的數量乘以生產率可以作為活動持續時間的量化依據。三點估算：考慮原有估算中風險的大小，可以提高活動歷時估算的準確性。三點估算就是在確定三種估算的基礎上做出的。（最樂觀、最可能、最悲觀）。后備分析：應急時間可以取活動歷時估算的某一百分比，或某一固定長短的時間。（5）制定進度計劃：確定項目活動計劃的開始與完成日期。

制定進度計劃采用的主要技術和工具包括：1）進度網絡分析；2）關鍵路線法（總時差、自由時差）；3）進度壓縮（趕進度、快速跟進）；4）假設情景分析：最常用的技術是蒙特卡洛分析；5）資源平衡：這種均勻使用資源的辦法可能會改變原來的關鍵路徑；6）關鍵鏈法：根據有限的資源對項目進度表進行調整；7）項目管理軟件；8）應用日歷：項目日歷和資源日歷標明了可以工作的時間段；9）調整時間提前與滯后量；10）進度模型。項目進度表：包括每項計劃活動的計劃開始日期與計劃完成日期，常用圖形表示：1）項目進度網絡圖：有活動節點表示法（單代號網絡圖），也可以使用時標進度網絡圖。2）橫道圖：用橫道表示活動，注明了活動的開始與結束日期，以及活動的預期持續時間。3）里程碑圖：僅標示出主要交付成果以及關鍵的外部接口的規定開始與完成日期。（6）項目進度控制：監控項目的狀態以便采取相應措施以及管理進度變更的過程。對進度的控制，應當重點關注項目進展報告和項目執行情況報告，它們反映了項目當前在進度、費用、質量等方面的執行情況和實施情況，是進行進度控制的重要依據。

定期舉行項目例會也是進度控制的很好的辦法。

糾正措施往往要求進行根本原因分析，查明造成偏差的原因。9)項目成本管理

1項目成本管理就是要確保在批準的預算內完成項目。具體的項目成本管理的具體流程包括：1）制定成本管理計劃2）成本估算3）成本預算4）成本控制 成本管理中的相關術語：產品的全生命周期成本：在項目過程中不只關心完成項目活動所需資源的成本，也應該考慮項目決策對項目最終產品使用和維護成本的影響。

成本類型：可變成本、固定成本、直接成本、間接成本。

管理儲備：是一個單列的計劃出來的成流程圖：顯示與系統相關的各要素之間相本，以備未來不可預見的事件發生時使互關系的示意圖。用。實驗設計：是一種統計方法，幫助確定影成本基準：經批準的按時間安排的成本支響特定變量的因素。出計劃，用于度量和監督項目的實際執行質量成本分析：預防成本、評估成本和缺成本。陷成本（內部缺陷成本和外部缺陷成本）。學習曲線理論：當重復生產許多產品時，質量功能展開（QFD）：將項目的質量要求、產品的單位成本隨著數量的增多而呈規客戶意見轉化成項目技術要的專業方法。律性遞減。（1）制定成本管理計劃：成本QFD矩陣其形狀看起來像房子，于是又稱管理計劃中列出了相關模板并制定了項“質量屋（quality house）”。目成本結構、估算、預算和控制的標準，過程決策程序圖法（PDPC）：在制定計劃其中包括：精確等級、測量單位、組織程時對實現既定目標的過程加以全面分析，序鏈接（WBS控制賬目與項目實施組織的估計到種種可能出現的障礙及結果，設想會計系統直接連接）、控制下限、掙值規并制定相應的應變措施和應變計劃，保持則（0-100，0-50-100等）、報告格式、計劃的靈活性。過程說明、成本變更控制系統等。項目質量計劃的輸出：質量管理計劃解決沖突的6種方法：1）問題解決2）

合作3）強制4）妥協5）求同存異6）撤退

12)項目溝通管理

項目溝通管理這一知識領域包括保證及時與恰當地生成、搜集、加工處理、傳播、存儲、檢索與管理項目信息所需的各個過程。項目溝通管理包括如下過程：1)溝通計劃編制2)信息分發3)績效報告4)項目干系人管理

阻礙有效溝通的因素：1）溝通雙方的物理距離2）溝通的環境因素3）缺乏清晰的溝通渠道4）復雜的組織結構5）復雜的技術術語6）有害的態度。1溝通計劃編制：確定項目干系人的信息和溝通需求：誰需要什么樣的信息，何時常見的詢價文件：1）方案邀請書（RFP）2）報價邀請書（RFQ）3）投標邀請書（IFB）4）征求供應商意見書（RFI）

3詢價：從潛在的賣方處獲取如何滿足項目需求的答復，如投標書和建議書。4招標：招投標過程涵蓋了本章詢價計劃編制過程、詢價過程和供方選擇過程。招標是采購的一種形式。

招標方式:1）公開招標2）邀請招標 5合同管理及合同收尾。15)信息（文檔）和配置管理

1信息系統項目相關信息（文檔）及其管理：信息系統相關信息（文檔）是指某種數據媒體和其中所記錄的數據?！队嬎銠C軟件產品開發文件編制指南》中指出文檔從重要性和質量要求方面分為：非正式文2成本估算：估算活動的成本，涉及估算完成每項活動所需資源的近似成本。成本估算一般以貨幣為單位。成本估算需要進行以下三個主要步驟:識別并分析成本的構成科目根據已識別的項目成本構成科目，估算每一科目的成本大小。分析成本估算結果，找出各種可以相互替代的成本，協調各種成本之間的比例關系。成本估算的工具與技術包括：類比估算、確定資源費率、自下而上估算、參數估算、項目管理軟件、供貨商投標分析、準備金分析、質量成本。成本應急儲備：用來處理預期但不確定的事件，即“已知的未知事件”。將其賦予一個持續時間為零的活動，該活動跨越該工作包子網絡的開始到結束，隨著活動的績效，根據持續時間不為零的活動的資源消耗測量應急儲備，并進行調整。3成本預算：將單個活動或工作包的估算成本匯總，以確立項目績效情況的總體成本基準。成本預算的特征：計劃性、約束性、控制性。編制項目成本預算應遵循的原則：項目成本預算要以項目需求為依據;項目成本預算要與項目目標聯系，必須同時考慮項目的質量目標和進度目標;項目成本預算要切實可行;項目成本預算應當留有彈性;制定項目成本預算所經過的步驟：將項目總成本分攤到項目工作分解結構的各個工作包。將各個工作包成本在分配到該工作包所包含的各項活動上。確定各項成本預算支出的時間計劃及項目成本預算計劃。成本基準：按時間分段的預算，用作度量和監控項目整體成本執行（績效）的基準。它按時段匯總估算的成本編制而成，通常以S曲線的形式表示。4項目成本控制：監督成本執行（績效），找出與成本基準的偏差，采取措施，將預期的成本超支控制在可接受的范圍內?？冃Ш饬糠治觯簰曛导夹g（EVM）。CV=EV-AC；CPI=EV/AV；CV%=CV/EV*100% ；SV=EV-PV；SPI=EV/PV；SV%=SV/PV*100%； 預測技術：EAC=AC+ETC（原來的估算徹底過時或不再適用了）EAC=AC+BAC-EV（偏差為一種特例，將來不會發生類似偏差）EAC=AC+(BAC-EV)/CPI（目前的偏差被視為將來偏差的典型形式）TCPI=(BAC-EV)/(BAC-AC)10)項目質量管理 項目的信譽是靠質量樹立的，效益是質量帶來的，項目質量管理的重點是質量策劃、質量保證和質量控制。質量管理基礎： 朱蘭博士提出的質量管理三部曲：質量策劃、質量控制和質量改進； 全面質量管理（TQM）：全員參加、全過程、全面方法和全面結果； 六西格瑪：“六倍標準差”；DMAIC（確定、測量、分析、改進、控制）； CMMI：“軟件能力成熟度模型”、5個等級、每個等級包含相應的過程域，每個過程域中設定了通用目標和特殊目標，每個目標由若干實踐組成。1制定項目質量計劃：制定質量目標并規定必要的運行過程和相關資源以實現項目質量目標。效益/成本分析：質量管理的原則就是收益勝過成本?；鶞时容^：將項目的實際做法或計劃做法與其他項目的實踐相比較。質量測量指標質量檢查表過程改進計劃項目管理計劃（更新）2項目質量保證：是質量管理的一個更高層次，是對質量策劃、質量控制過程的質量控制。項目質量保證（QA）活動包括：1)產品、系統、服務的質量保證；2)項目管理過程的質量保證：制定質量標準;制定質量管理流程;提出質量保證所采用的方法和技術;建立質量保證體系;項目質量保證的技術和方法：項目質量管理通用方法過程分析 項目質量審計：可以是預先計劃的，也可以是隨機的；可以是組織內部完成，也可以委托第三方（外部）組織來完成。3項目質量控制：項目質量控制（QC）就是項目團隊的管理人員采取有效措施，監督項目的具體 實施結果，判斷它們是否符合項目有關的質量標準，并確定消除產生不良結果原因的途徑。項目質量控制的方法和技術：測試、檢查、統計抽樣、6e（以客戶為中心）“老七種工具”：因果圖（石川圖/魚骨圖）、流程圖、直方圖、檢查表、散點圖、排列圖（帕累托圖）、控制圖； “新七種工具”：相互關系圖、親和圖（KJ法）、樹狀圖（系統圖、家譜圖、組織圖）、矩陣圖、優先矩陣圖、過程決策方法圖（PDPC）、活動網絡圖（箭頭圖法、矢線圖法）。11)項目人力資源管理 項目人力資源管理就是有效地發揮每個參與項目人員的作用，把適合的人組成一個戰斗力超強的團隊的過程。項目人力資源管理的主要流程包括：1)編制項目人力資源管理計劃2)項目團隊組建3)項目團隊建設4)項目團隊管理 1項目人力資源計劃編制：確定項目的角色、職責以及匯報關系。任務、職責和匯報關系可以分配到個人或團隊三種形式可以描述項目的角色和職責：層次結構圖（WBS、OBS、RBS）;矩陣圖（RAM、RACI負責-執行-咨詢-通知）;文本格式。2組建項目團隊：獲得所需的人力資源（個人或團隊），將其分配到項目中工作。此流程的工具和技術包括：事先分派、談判、采購、虛擬團隊。激勵理論：馬斯洛需要層次理論（生理需要、安全需要、社會交往的需要、自尊的需要、自我實現的需要）赫茨伯格的雙因素理論（第一類是保健因素、第二類是激勵因素）期望理論（目標對人的激勵程度受兩個因素影響：目標效價、期望值）。X理論和Y理論。領導與管理：項目經理帶領團隊管理項目的過程中，具有領導者和管理者的雙重身份。領導權變理論的基本觀點是：認為不存在一種普遍使用、唯一正確的領導方式。影響和能力，5種基本的權力（合法的權力、強制力、專家權力、獎勵權力、感召權力）。3項目團隊建設：提高項目相關人員的技能、改進團隊協作、全面改進項目環境，其目標是提高項目的績效。項目團隊建設的5個階段：形成階段、震蕩階段、規范階段、發揮階段、結束階段； 團隊建設活動的可能形式和應用：通用管理技能、培訓、團隊建設活動、基本規則、集中辦公、獎勵和表彰 4項目團隊管理：跟蹤個人和團隊的績效，提供反饋，解決問題和協調變更，以提高項目的績效。需要，以及怎樣分發給它們。通常，溝通計劃編制的第一步就是干系人分析，得出項目中溝通的需求和方式，進而形成較為準確的溝通需求表，然后再針對需求進行計劃編制。

2信息分發：把所需要的信息及時提供給項目干系人。它包括實施溝通管理計劃，以及對預料之外的信息索取要求做出反應。

常用的溝通方式：書面與口頭、聽與說、對內與對外、正式與非正式、垂直與水平。3績效報告：搜集所有基準數據并向項目干系人提供項目績效信息?？冃蟾嬉话惆ǚ秶⑦M度、成本和質量方面的信息。形成績效報告的主要步驟：收集依據材料、項目績效評審。

4項目干系人管理：對干系人的溝通就是對他們的溝通進行管理，讓不同的項目干系人得到相應等級內容的項目信息并解決項目干系人之間的問題，從而使項目順利按計劃推進。

干系人管理的范圍包括：客戶、高層領導、項目團隊。

13)項目合同管理

信息系統工程的建設過程實際上就是合同的執行和監控過程。合同是工程項目建設的基本依據，也是監理工作的主要依據之一。

1項目合同：合同的概念：廣義合同概念和狹義合同概念。

合同的法律特征：1）合同是一種民事法律行為2）合同以設立、變更或終止民事權利義務關系為目的3）合同是兩個及其以上的當事人意思表示相一致的協議4）合同是當事人各方在平等、自愿的基礎上產生的民事法律行為 2項目合同的分類：按信息系統范圍劃分：1）總承包合同2）單項項目承包合同3）分包合同。

按項目付款方式劃分的合同分類：1）總價合同 2）單價合同3）成本加酬金合同。

3項目合同簽訂：合同簽訂的注意事項：1）當事人的法律資格2）質量驗收標準3）驗收時間4）技術支持服務5）損害賠償6）保密協定7）合同附件8）法律公正 4項目合同管理：管理建設方與承建方的關系，保證承建方的實際工作滿足合同要求的過程。

合同管理的主要內容：1）合同簽訂管理2）合同履行管理3）合同變更管理4）合同檔案管理。

項目合同索賠處理：1）按索賠的目的分類（工期索賠和費用索賠）2）按索賠的依據分類（合同規定的索賠和非合同規定索賠）3）按索賠的業務性質分類（工程索賠和商務索賠）4）按索賠的處理方式分類（單項索賠和總索賠）索賠的處理:1）索賠程序2）索賠審核3）索賠事件處理的原則

14)項目采購管理

項目采購管理是為完成項目工作，從項目團隊外部購買或獲取所需的產品、服務或成果的過程。

1編制采購計劃：決定采購什么，何時采購，如何采購。自制外購分析 合同類型 固定總價合同 成本補償合同（成本加酬金合同、成本加固定酬金合同、成本加鼓勵酬金合同）時間和材料合同（單價合同）2編制詢價計劃：為下一步招標所需要的文件做準備，并確定選擇供方所需要的評定標準。檔和正式文檔；

從項目周期角度可分為：開發文檔、產品文檔、管理文檔。

14類文檔文件：可行性研究報告、項目開發計劃、軟件需求說明書、數據要求說明書、概要設計說明書、詳細設計說明書、數據庫設計說明書、用戶手冊、操作手冊、模塊開發卷宗、測試計劃、測試分析報告、開發進度月報、項目開發總結報告、2配置管理：為了系統的控制配置變更，在系統的整個生命周期中維持配置的完整性和可跟蹤性，而標識系統在不同時間點上配置的學科。配置管理有關的概念：配置項配置庫配置管理活動和流程 配置管理系統 基線 制定配置管理計劃 配置識別與建立基線

建立配置管理系統：1）建立配置管理方案2）建立配置庫 動態庫（開發庫、程序員庫、工作庫）受控庫（主庫）靜態庫（軟件倉庫）備份庫

版本管理：配置項狀態變遷規則：配置項的狀態有三種：草稿（Draft）、正式發布（Released）、正在修改（Changing）。配置項版本號標示：“草稿”狀態：0.YZ，YZ數字范圍（01-99）“正式發布”狀態：X.Y（X的取值范圍：1-

9、Y的取值范圍：1-9）“正在修改”狀態：X.YZ 配置項版本控制

變更控制：1）變更申請2）變更評估3）變更實施4）變更驗證與確認5）變更的發布

配置狀態報告：配置狀態報告也稱配置狀態說明與報告，它是配置管理的一個組成部分，其任務是有效地記錄和報告管理配置所需要的信息，目的是及時、準確地給出軟件配置項的當前狀況，供相關人員了解，以加強配置管理工作。配置審計：1）功能配置審計、2）物理配置審計

16)變更管理

項目變更是指在信息系統項目的實施過程中，由于項目環境或者其他原因而對項目產品的功能、性能、架構、技術指標、集成方法、項目的范圍基準、進度基準和成本基準等方面做出的改變。1項目變更的基本概念：

變更的分類：按性質（重大變更、重要變更、一般變更）按迫切性（緊急變更、非緊急變更）按領域和階段（進度變更、成本變更、質量變更、設計變更、實施變更、工作（產品）范圍變更）按發生的空間（內部變更、外部環境變更）按變更的內容（弱電過程、應用開發、集成、IT咨詢等）2變更管理的基本原則：基準管理建立變更控制流程明確組織分工完整體現變更的影響妥善保存變更產生的相關文檔 3變更管理組織機構與工作程序：1CCB（變更控制委員會）：項目的所有者權益代表，是決策機構，不是作業機構，其工作是通過評審手段來決定項目是否能變更，但不提出變更方案。2項目經理：響應變更提出者的要求；評估變更的影響；根據評審結果實施即調整項目基準。3)工作程序：1）提出與接受變更申請2）對變更初審3）變更方案論證4）項目變更控制委員會審查5）發出變更通知并開始實施6）變更實施的監控7）變更效果的評估8）判斷發生變更后的項目是否已納入正常軌道。4變更管理的工作內容：1）對變更產生的因素施加影響，防止不必要的變更，提高效率2）對變更的確認應當正式化3）變更的操作過程應當規范化。5)嚴格控制項目變更申請的提交。6)變更控制：1）對進度變更控制2）對成本變

更控制3）對合同變更的控制。7)變更管理與其他項目管理要素之間的關系：1）變更管理屬于項目整體變更控制的范疇2）變更管理與配置管理為相關聯的兩套機制；變更管理也可視為配置管理的一部分。

17)信息系統安全管理 1信息安全管理：

信息安全屬性及目標：保密性、完整性、可用性、真實性、可核查性、不可抵賴性、可靠性。

信息安全管理的內容：在ISO/IEC27000系列標準中，它將信息安全管理的內容主要概括為11個方面：1）信息安全方針與策略2）組織信息安全3）資產安全4）人力資源安全5）物理和環境安全6）通信和操作安全7）訪問控制8）信息系統的獲取、開發和保持9）信息安全事件管理10）業務持續性管理11）符合性 2信息系統安全：1信息系統安全概念：信息系統及其所存儲、傳輸和處理的信息的保密性、完整性和可用性的表征，一般包括保障計算機及其相關的和配套的設備、設施的安全，運行環境的安全，保障信息的安全，以保障信息系統功能的正常發揮，以維護信息系統的安全運行。2信息系統安全屬性：1）保密性2）完整性3）可用性4）不可抵賴性3信息系統安全管理體系：管理體系：在組織機構中應建立安全管理機構，不同安全等級的安全管理機構可按下列順序逐步建立自己的信息系統安全組織機構管理體系：1）配備安全管理人員2）建立安全職能部門3）成立安全領導小組4）主要負責人出任領導5）建立信息安全保密管理部門 技術體系：從安全角度，組成信息系統各個部分的硬件和軟件都應有相應的安全功能，確保在其所管轄范圍內的信息安全和提供確定的服務。GB/T20271-2006中將信息系

統安全技術體系具體描述為：1）物理安全（環境安全、設備安全、記錄介質安全2）運行安全3）數據安全 3物理安全管理：

計算機機房與設施安全：計算機機房：1）機房場地選擇2）機房空調、降溫3）機房防水與防潮4）機房接地與防雷擊 電源：根據對機房安全保護的不同要求，機房供、配電分為如下幾種：1）分開供電2）緊急供電3）備用供電4）穩壓供電5）電源保護6）不間斷供電7）電器噪聲防護8）突然事件防護

計算機設備：1）設備的防盜和防毀2）設備的安全可用通信線路：根據對通信線路安全的不同要求，通信線路安全防護分為以下幾種：1）確保線路通暢2）發現線路截獲3）及時發現線路截獲4）防止線路截獲技術控制：1）檢測監視系統2）人員進出機房和操作權限范圍控制環境與人身安全：1）防火2）防漏水和水災3）防靜電4）防自然災害5）防物理安全威脅電磁兼容：1）計算機設備防止泄漏2）計算機設備的電磁輻射標準和電磁兼容標準

4人員安全管理：

安全組織：建立管理框架，以啟動和控制組織范圍內的信息安全的實施。崗位安全考核與培訓離崗人員安全管理 5應用系統安全管理：

應用系統安全管理的實施：1）建立應用系統的安全需求管理2）嚴格應用系統的安全檢測與驗收3）加強應用系統的操作安全控制4）規范變更控制5）防止信息泄漏6）嚴格訪問控制7）信息備份8）應用系統的使用監視

應用系統運行中的安全管理：1）組織管理層在系統運行安全管理中的職責（資源分配、標準和程序、應用系統的過程監控）2）系統運行安全的審查目標3）系統運行安全與保密的層次構成（系統級安全、資源訪問安全、功能性安全、數據域安全）4）系統運行安全檢查與記錄5）系 統運行安全管理制度（安全管理組織、系統運行的安全管理、系統運行的安全監督、系統運行的安全教育）18)

在項目管理中，任何活動都不可避免地存在不確定性，因而也就存在著各種各樣的風險，項目經理的目標和任務就是與風險做斗爭。項目風險管理過程包括如下內容：(1)風險管理規劃(2)風險識別(3)定性風險分析(4)定量風險分析(5)風險應對計劃編制(6)風險監控 風險和風險管理：

風險的含義及其特征：

風險意味著出現了損失,這種損失出現與否是一種不確定性隨機現象。風險管理的含義：在風險成為影響項目成功的威脅前，識別、著手處理并消除風險的源頭。

1制定風險管理計劃：為實現對風險的管理而制定的一份結構完備、內容全面而且相互協調的風險管理策略文件，以盡可能消除風險或盡量降低風險危害。風險管理計劃的內容：方法論、角色和職責、預算、頻率、風險分解結構（Risks Breakdown Structure，RBS）、風險概率和影響的定義、概率和影響矩陣、干系人風險承受限度、匯報格式、跟蹤、應急計劃、應急儲備；制定風險管理計劃的工具與技術：風險核對表、風險管理表格、風險數據庫模式。

制定風險管理計劃的輸入、輸出：輸入：企業環境因素、組織過程資產、項目范圍說明書、項目管理計劃;輸出：風險管理計劃

2風險識別：確定風險的來源、風險產生的條件、描述其風險特征和確定哪些風險事件有可能影響本項目，并將其特性記載成文。

風險事件和風險識別含義：

風險事故：造成損失的直接或外在的原因，是損失的媒介物。

風險識別的特點：全員性、系統性、動態性、信息依賴性、綜合性。風險識別的參與者：項目經理、項目團隊、項目關系人、風險管理專家等。風險識別的方法：

步驟：收集資料、風險形式估計、根據直接或間接的癥狀將潛在的風險識別出來。識別的具體方法：德爾菲技術、頭腦風暴法、SWOT分析法、檢查表、圖解技術。風險識別的輸入、輸出：

輸入：企業環境因素、組織過程資產、項目范圍說明書、風險管理計劃、項目管理計劃 輸出：已識別風險清單、潛在應對措施清單、風險基本原因、風險類別更新 3定性風險分析：通過考慮風險發生的概率，風險發生后對項目目標及其他因素的影響，對已識別風險的優先級進行評估。定性風險分析的方法：風險概率與影響評估、概率和影響矩陣、風險分類、風險緊迫性評估。

定性風險分析的輸入、輸出：輸入：組織過程資產、項目范圍說明書、風險管理計劃、風險登記單;輸出：風險的優先度清單、分類的風險、需要在近期采取應措施的風險清單、需進一步分析的風險清單、低優先級風險觀察清單、風險定性分析結果的趨勢。

4定量風險分析：對定性風險分析過程中識別出的對項目有重大影響的風險進行的量化分析，并就風險分配一個數值。數據收集和表示的方法及應用：期望貨幣值（EMV）、計算分析因子、計劃評審技術（PERT）、蒙特卡洛（Monte Carlo）分析。定量風險分析的輸入、輸出：輸入：組織過程資產、項目范圍說明書、風險管理計劃、風險登記單、項目管理計劃;輸出：項目的概率分析、實現成本和時間目標的概率。

5應對風險的基本措施：（規避、接受、減輕、轉移）：消極風險或威脅的應對策略：規避、轉移、減輕。接受（主動接受和被動接受）積極風險或機會的應對策略：開拓、分享、提高

6風險監控：跟蹤風險、識別剩余風險和新出現的風險，修改風險管理計劃，保證風險計劃的實施，并評估消減風險的效果。

風險監控的目的和主要工作內容：執行風險管理計劃和風險管理流程、采取應急措施、采取權變措施。

用于風險監控的技術、方法： 系統的項目監控方法（一類用于監控與項目、產品有關的風險；另一類用于監控與過程有關的風險）

風險預警系統;風險監控的具體方法（風險再評估、風險審計、變差和趨勢分析、技術績效衡量、儲備金分析、狀態審查會）19)項目收尾管理

1項目收尾的內容：主要是項目驗收、項目總結和項目評估審計。

項目驗收：包括驗收項目產品、文檔及已經完成的交付成果。1）系統測試2）系統的試運行3）系統的文檔驗收4）項目的最終驗收報告

項目總結：屬于項目收尾的管理收尾。項目總結會討論的內容：項目績效、技術績效、成本績效、進度計劃績效、項目的溝通、識別問題和解決問題、意見和建議。項目評估和審計：項目評估多數包括：盈利要求、客戶滿意度要求、后續項目指標要求、內部滿意度要求。項目審計：項目管理部門與財務部門共同進行，對已經列出的支出和收入進行財務審計，對不合理的支出和收入加以分析。

2對信息系統的后續工作的支持：

軟件項目的后續工作：軟件bug的修改、軟件升級、后續技術支持。系統集成項目的后續工作：信息系統日常維護工作、硬件產品的更新、信息系統的新需求。

3項目團隊人員轉移：項目團隊人員的轉移、項目轉移人員的業績評定、項目團隊成員的表彰。

第三篇：系統集成項目案例分析

系統集成項目案例分析

本章收集了實際項目中的大量案例，每個案例側重點各不相同，是對前22章知識 點的綜合運用。不僅需要動手實踐項目管理中的硬技能，例如網絡圖、掙值分析以及成 本財務分析等，還需要能夠靈活運用項目管理中的軟技能，例如溝通協調、需求變更以 及項目管理中的一些常見原則等。

本章案例分析所要用到的信息化及系統集成專業知識主要涵蓋如下方面。

(l)信息化建設基本知識。

(2)軟件工程。

(3)面向對象設計。

(4)軟件以及硬件體系結構知識。

(5)計算機網絡知識。23.1項目管理硬技能案例 23.1.1

人力資源負荷的優化對很多項目來說是至關重要的一個問題，而利用網絡圖中非關 鍵路徑任務上的浮動時間是最常用的方法之一。

案例場景

為了更好地利用資源和對資源進行有效地管理，項目組重新對項目計劃進行了調 整。調整后的各項工作的工作持續時間、所需要的人力資源類型及其相應的工作量估計 如表23-1所示。

表23-1游戲軟件開發項目調整后的工作時間和工作量估計表

【問題2] 根據表23-2，進行人力資源平衡的優化，并繪制該項目的人力資源負荷圖。23.1.2現金流分析案例

在立項階段，經常需要對項目未來的現金流狀況進行分析，并作出相應的財務數據 分析。

案例場景

某軟件公司擬開發一套建筑施工項目管理軟件，該軟件應具有項目管理計劃的編制 及項目的動態管理功能。該軟件開發項目的基礎數據如下。

(1)該項目從2004年7月1日開始，周期為180天，項目總投資600萬元。

(2)該軟件從第二年開始銷售，預計當年銷售收入為500萬，各種成本為200萬； 第3年銷售收入為800萬，各種成本為300萬；第四年開始正常銷售，正常銷售期間預 計每年的銷售收入為1000萬元，各種成本為500萬元。

(3)根據上述數據，假設項目成本與收入均在年末核算，通過分析計算該公司從項 目開始當年到第6年的現金流量情況，包括每年的現金流出、現金流入、凈現金流量、累計凈現金流量、現值和累計現值，如表23-3所示。

【問題1】

請根據表23-3現金流量表中的數據，計算該項目自投資當年起的靜態投資回收期和 動態投資回收期（要求列算式），并說明兩者存在差異的原因。

【問題2]

如果該行業的標準動態投資收益率為20%，請問該項目的投資是否可行。23.1.3動態回收期及凈現值分析案例

對于很多項目來說，必須要考慮到資金的時間價值，因此經常要引入動態回收期和 凈現值的計算。

案例場景

某軟件公司擬開發一套建筑施工項目管理軟件，該軟件應具有項目管理計劃的編制 及項目的動態管理功能。該軟件開發項目的基礎數據如下：

(1)該項目從2004年7月1日開始，周期為180天，項目總投資600萬元。

(2)該軟件從第二年開始銷售，預計當年銷售收入為500萬，各種成本為200萬。第3年銷售收入為800萬，各種成本為300萬；第四年開始正常銷售，正常銷售期間預 計每年的銷售收入為1000萬元，各種成本為500萬元。

(3)根據上述數據，假設項目成本與收入均在年末核算，通過分析計算該公司從項 目開始當年到第6年的現金流量情況，包括每年的現金流出、現金流入、凈現金流量、累計凈現金流量、現值、累計現值，如表23-4所示。

【問題l】

請根據表234現金流量表中的數據，計算該項目自投資當年起的靜態投瓷回收期和 動態投資回收期（要求列算式），并說明兩者存在差異的原因。

【問題2】

如果該行業的標準動態投資收益率為20%，請問該項目的投資是否可行。23.1.4掙值分析案例

“掙值管理”是項目管理中非常有用的一種績效分析的方法。它通過對預算成本、實際完工工作量和實際發生成本三個基本指標的計算可以作出對項目成本和工期狀態的 準確評估。

案例場景

在認真分析新型柜式空調生產建設項目各項費用的基礎上，最終制定的各項工作的 成本預算修正結果如表23-4所示。假設該項目已進展到第21旬，你對項目前20旬的實 施情況進行了總結，有關執行情況匯總于表23-5中。

【問題1]

計算前20旬每項工作的掙值并填入表23-5中，請至少寫出一項工作掙值的計算公式。

【問題2]

計算該項目到第20旬末的掙值(EV)。

【問題31

計算該項目前20旬已完成工作量的實際成本(AC)。

【問題4]

根據以上結果分析項目的成本執行情況和進度執行情況。

【問題5]

假設該項目目前的執行情況不會影響到未來，未來將按計劃執行，請估計項目完成 時的總成本(EAC)；為了保證項目成本目標的實現，你將會采取哪些對策？ 23.1.5需求評竄案例

把握住清晰、完整和準確的需求是對項目進行有效控制和管理的前提，而需求評審 又是需求管理階段一個至關重要的工作。但是，需求評審往往是所有評審活動中最難，也常常是最容易被忽視的。

以下是在實際項目管理中幾種常見的、失敗的需求評審。

案例場景

案例一

某領域專家A先生就某企業的成本管理系統做用戶需求報告的評審工作，在評審會 開始時間不長，就被在場的某企業的一位副總B先生打斷，認為A先生提出的方案不適 合本企業，A先生提出的管理改進方案在企業中無法實施。該副總提完意見后，與會的 用戶方人員紛紛跟隨B先生的意見提出了他們的反對意見，致使評審會無法再進行下去，最終該報告被用戶否決。

案例二

某軟件公司內部舉行產品的需求評審會，主要是公司內部相關領域的專家參加。在 評審會開始后不久，某領域專家就對需求報告中的某個具體問題提出了自己的不同意見，于是，與會人員紛紛就該問題發表自己的意見，大家爭執不下，結果致使會議出現了混 亂狀況，主持人無法控制局面，會議大大超出了計劃評審時間。

案例三

某軟件公司為某公司A做業務流程管理系統的需求評審會，當項目組人員在會議上 宣讀多達上百頁的需求報告時，用戶明確提出昕不懂，致使會議不得不改日進行。

案例四

某軟件公司在用戶處開完物資管理系統的需求評審會后，與會人員在離開會議室時 紛紛搖頭，認為本次會議沒有多少實際效果，完全是在走過場。

【問題】

請提出一些建設性的意見，如何能夠召開成功的需求評審會議？ 23.1.6風險箐理案例

在項目中，風險是無處不在的，而風險叉往往是項目管理者最容易忽視的。因此，對很多項目來說，做好風險的識別、分析、監控和管理工作是保證項目成功、減少項目 損失的一個關鍵。

案例場景

C公司是國外一家知名的電信設備供應商，在國內擁用許多電信運營商客戶。C公 司主要通過分銷的方式發展其在中國的業務，由其在國內的合作伙伴與電信公司簽約并 提供系統集成服務。

2000。年，國內一家省級電信公司(H公司)打算上馬一個項目，并通過發布RFP（需 求建議書）以及談判和評估，揖終選定C公司為其提供相關電信設備。國內某集成公司（L公司）作為C公司在中國國內的代理商之一，成為了該項目的系統集成商。L公司是 第一次參與此類工程。電信公司（H公司）和L公司簽訂了總金額近1000萬元的合同。張先生是L公司負責該項目的項目經理。該項目的施工周期是三個月，由國外電信設備 供應商C公司負責提供主要設備，L公司負責全面的項目管理和系統集成工作，包括提 供主機、外設及相關附屬設備，并負責項目的整個運作和管理。C公司和其代理商L公 司之間簽署的是設備采購合同，一次性付款，這就意味著C公司不承擔任何項目風險，而L公司雖然有很大的利潤，但是也承擔了全部的風險。L公司和客戶H公司之間簽署 的是集成服務合同，合同類型為固定價分期付款合同，按照慣例，10%的尾款要等到系 統通過最終驗收一年后才能支付。

項目實施3個月后，整套系統安裝完成。但自系統試運行之日起，不斷有問題暴露 出來。H公司要求L公司負責解決，可其中很多問題涉及C公司的設備問題。因而，L 公司要求C公司予以配合，C公司也一直積極參與此項目的工作。

然而，隨著對項目的階段性測試工作的展開，H公司發現系統的實際技術指標遠遠 沒有達到當初L公司在最初的技術建議書上的承諾。對于H公司來說，他們認為，按照 RFP的要求，L公司實施的項目沒有達到合同的要求。因此，直至2002年，H公司還拖 欠L公司10%的驗收款和10%的尾款。L公司多次召開項目會議，要求C公司給予支持。但由于開發周期的原因，C公司的設備無法馬上達到新的技術指標并滿足相關的功能。于是，項目持續延期。為完成此項目，L公司只好不斷將C公司的最新升級系統（軟件 升級）提供給H公司，甚至派人常駐在H公司（外地）。

又經過了3個月的艱苦調試，H公司終于通過了最初驗收。在L公司同愨承擔系統 升級工作直到完全滿足RFP的基礎上，H公司支付了10%的驗收款。然而，2002年年 底，C公司由于內部原因暫時中斷了在中國的業務，其產品的支持力度大幅下降，結果 致使該項目的收尾工作至今無法完成。

作為項目經理，L公司張先生簡單估算了一下，在此項目上公司原本可以獲得250 萬元左右的毛利，可是考慮到增加的項目成本（差旅費、溝通費用、公關費用和貼現率）和尾款，實際毛利不到70萬元。如果再考慮機會成本，實際利潤可能是負值。

導致項目失敗，尤其是項目預期的經濟指標沒有完成，這是非常遺憾的事情。項目 失敗或沒有達到預期的經濟指標的因素有很多，其中風險管理是一個極為重要的因素。

【問題】

從L公司角度，討論一下該項目失敗的原因及其避免的方法。

分析提示：

(1)風險識別與分析的方法。

(2)適當的商務承諾。

(3)選擇適當的商務合同。

23.1.7公司組織結構對項目管理的影響

公司組織結構對項目管理的影響是顯而易見的，不同的組織結構都有其相應的優點 和缺陷。而對于矩陣型的組織結構來說，有效的溝通和協調能力對于項目經理往往是一 個非常大的挑戰。

案例場景

某軟件公司以產品開發和項目為其主要業務。公司目前發展勢頭良好，正在建謾中 的項目有5個左右，已經立項的有10個左右，還有若干項目正處在驗收和后期維護階段。

公司實行的是強矩陣式管理模式，專職的項目經理往往一個人帶多個項目，職能部 門內部也有擔任項目經理工作的人員。但是，瓷源的調配成了項目經理、職能部門經理 在項目實施過程中塌棘手的問題。項目經理每個人都身兼數職，對項目進度難以控制，而多數項目在進行耐，資源的調配是由各個職能部門經理安排的，職能部門經理對質量 進行監督，項目經理耍做進度控制，可是卻沒有分配資源的權力，從而引發出關于公司 內部管理流程和職責定位的問題。

【問題】

在強矩陣管理的模式下面，項目經理與職能部門經理對公司資源的調用如何協調？

分析提示：

(l)項目章程明確責任。

(2)項目經理和職能經理的協調。23.1.8項目變更管理案例

在項目執行中，變更往往在所難免。但是，無序和隨意的變更會對項目的成功造成 極大的危害。這就要求項目管理者在項目的前期做好需求的導出和定義工作，并在項目 執行中有切實可行的變更管理方法和流程。

案例場景

小張是國內某IT系統集成企業的項目經理，目前正在負責國內某省一個企業的信息 系統項目的建設工作。作為項目經理，小張根據合同中昀相關條款，在計劃階段簡單地 羅列出了項目中幾項必須應當完成的工作。甲方的項目經理由這個企業的信息中心領導 擔任，此系統集成項目涉及到甲方的許多業務部門。在項目實施中，甲方的銷售部門、財務部門和人力資源等多個部門都向小張提出了變更要求，而其有些要求甚至是相互矛 盾的。面對這些變更，小張嘗試向甲方的各個業務部門做說服和解釋工作，但甲方卻引 用合同中的相關條款作為依據要求小張實現這些新增加的變更要求。而這些合同條款要 么太粗、不夠明確，要么小張與他們有不同的理解，因此小張感到左右為難，既不能對 這些變更要求簡單地全盤接受，又不能生硬拒絕。但如果不能盡快改變這種現狀，完成 項目看起來是遙迢無期。

【問題】

該問題產生的原因是什么？如何解決？

分析提示：

(l)WBS詳細分解。

(2)CCB的成立。

(3)變更流程的建立。

(4)客戶對需求和項目工作說明書的確認。23.2軟技能案例

23.2.1范圍定義案例

?

項目的范圍管理影響到信息系統項目的成功。在實踐中，“需求蔓延”是信息系統失 敗最常見的原因之一，信息系統項目往往在項目啟動、計劃、執行，甚至收尾時不斷加 入新功能，無論是客戶的要求還是項目實現人員對新技術的試驗，都可能導致信息系統 項目范圍的失控，從而使得信息系統項目在時間、資源和質量上都受到嚴重影響。

閱讀以下關于信息系統項目管理過程中范圍管理方面問題的敘述，回答問題1～問 題3。

案例場景

Perfect公司原本是一家專注于企業信息化的公司，在電子政務如火如荼的時候，開 始進軍電子政務行業。在電子政務的市場中，接到的第一個項目是開發一套工商審批系 統。由于電子政務保密要求，該系統涉及到兩個互不聯通的子網：政務內網和政務外網。政務內網中儲存著全部信息，其中包括部分機密信息；政務外網可以對公眾開放，開放 的信息必須得到授權。

系統要求在這兩個子網中的合法用戶都可以訪問到被授權的信息，訪問的信息必須 一致可靠，政務內網的信息可以發布到政務外網，政務外網的信息在經過審批后可以進 入政務內網系統。

張工是該項目的項目經理，在捕獲到這個需求后認力電子政務建設與企業信息化有 很大的不同，有其自身的特殊性，若照搬企業信息化原有的經驗和方案必定會遭到慘敗。因此采用了嚴格瀑布模型，并專門招聘了熟悉網絡互通互聯的技術人員設計了解決方案，在經過嚴格評審后實施。在項目交付時，雖然系統完全滿足了保密性的要求，但用戶對 系統用戶界面提出了較大的異議，認為不符合政務信息系統的風格，操作也不夠便捷，要求徹底更換。由于最初設計的缺陷，系統表現層和邏輯層緊密耦合，導致70%的代碼 重寫，而第二版的用戶界面仍不能滿足最終用戶的要求，最終又重寫了部分代碼才通過 驗收。由于系統的反復變更，項目組成員產生了強烈的挫折感，士氣低落，項目工期也 超出原計劃的100%。

【問題1]

請對張工的行為進行點評？

【問題2]

請從項目范圍管理的角度找出該項目實施過程中的主要管理問題？

【問題3]

請結合你本人實際項目經驗，指出應如何避免類似問題？ 23.2.2工作要點的案例

閱讀以下關于信息系統項目管理過程中項耳范圍管理方面問題的敘述，回答問題

1、問題2。

案例場景

M集團是Perfect公司多年的客戶．Perfect公司已經為其開發了多個信息系統。是近，M又和Perfect公司簽訂了新的開發合同，以擴充整個企業的信息化應用范圍，張工 擔任該項目的項目經理。

張工組織相關人員對該項目的工作進行了分解，并參考了公司同M曾經合作的項 目，評估得到項目的總工作量為60人月，計劃工期6個月。

項目剛剛開始不久，張工的高層經理s找到張工。s表示，由于公司運作的問題，需要在4個月內完成項目，考慮到壓縮工期的現實，可以為該項目再增派兩名開發人員。

張工認為，整個項目的工作量是經過仔細分解后評估得到的，評估過程中也參考了 歷史上與M企業合作的項目度量數據，該工作量是客觀真實的。目前項目已經開始，增 派的人手還需要一定的時間熟悉項目情況，因此即使增派兩人也很難在4個月內完成。如果強行要求項目組成員通過加班等方式實現4個月完成的目標，肯定會降低項目的質 量，造成用戶不滿意。

因此，張工提出將整個項目分為兩部分實現，第一部分使用三個半月的時間，第二 部舒使用三個月的時間，分別制定出兩部分的驗收標準，這樣不增派開發人員也可以完 成。高層經理認為該方案可以滿足公司的運作要求，用戶也同意按照這種方案進行實施。

6個月以后，項目在沒有增加人員的前提下順利地完成，雖然比昂初計劃延長了半 個月的工期，但既達到了公司的要求，客戶對晟終交付的系統也非常滿意，項目組的成 員也沒有感受到很大的壓力。

【問題1]

請指出張工是如何保證項目成功的？

【問題2】

試結合案例指出項目范圍管理的工作要點？ 23.2.3范圍確認案例

閱讀以下關于信息系統項目管理過程中項目范圍管理方面問題的敘述，答問題卜— 問題3。

案例場景

Perfect公司剛剛和M簽訂了一份新的合同，合同的主要內容是處理公司以前為M 公司開發的信息系統的升級工作。升級后的系統可以滿足M公司新的業務流程和范圍。由于是一個現有系統的升級，項目經理張工特意請來了原系統的需求調研人員李工擔任

520

系統集成項目管理工程師教程

該項目的需求調研負責人。在李工的幫助下，很快地完成了需求開發的工作并進入設計 與編碼階段。由于M公司的業務非常繁忙，M公司的業務代表沒有足夠的時間投入到 項目中，確認需求的工作一拖再拖。張工認為，雙方已經建立了密切的合作關系，李工 也參加了原系統的需求開發，對業務的系統比較熟悉，因此定義的需求是清晰的。故張 工并沒有催促業務代表在需求說明書中簽字。

進入編碼階段后，李工因故移民加拿大，需要離開項目組。張工考慮到系統需求已 經定義，項目已經進入編碼期，李工的離職雖然會對項目造成一定的影響，但影響較小，因此很快辦理好了李工的離職手續。

在系統交付的時候，M公司的業務代表認為已經提出的需求很多沒有實現，實現的 需求也有很多不能滿足業務的要求，必須全部實現這些需求后才能驗收。此時李工已經 不在項目組，沒有人能夠清晰地解釋需求說明書。最終系統需求發生重大變更，項目延 期超過50%，M的業務代表也因為系統的延期表示強烈的不滿。

【問題1]

請對張工在項目管理工作中的行為進行點評。

【問題2]

請從項目范圍管理的角度找出該項目實施過程中的問題。

【問題3]

請結合你本人的項目經驗，談談應如何避免類做的問題。23.2.4客戶關系管理案例

溝通是指人際之間傳遞和溝通信息的過程，對于項目取得成功是必不可少的，而且 也是非常重要的。溝通的主旨在于互動雙方建立彼此相互了解的關系，相互回應，并期 待能經由溝通的行為與過程相互接納及達成共識。

在信息系統項目中，項目干系人之間的溝通貫穿項目整個生命周期。很多專家認為，信息系統項目失敗的重要原因就是溝通的失敗。

閱讀以下關于信息系統項目管理過程中客戶溝通管理和客戶關系管理問題的敘述，回答問題l～問題3。

案例場景

Perfect公司是一家中小規模的軟件公司，公司研發人員不到20人，主要從事紡織 機械行業企業管理信息系統的開發。經過一些開發項目的積累，逐步形成了適合該行業 企業的財務管理軟件和企業資源計劃系統ERP軟件兩大產品。由于Perfect公司銷售人 員的努力工作，目前Perfect公司業務較繁忙，逐步進入高速增長階段。

一個月前，Perfect公司銷售人員趙某參加了國內某大型紡織機械集團公司D公司的 信息化建設項目招標工作。趙某在多次向Perfect公司技術部門提出要求技術人員配合，參與項目建議書編寫工作，要求沒有得到人員落實的情況下，獨立完成了該招標的項目 建議書。由于報價合理，同時在向D公司提供的項目建議書中，提出了一套相當全面的 實施方案和較理想化的信息化建設思路，結果Perfect公司順利中標。

根據投標文件中做出的實施進度承諾，項目一周后正式立項。由于Perfect公司業務 繁忙，一時無法從其他項目組抽調研發人員到新成立的項目小組，人力資源部門臨時招 聘了張工和其他5名軟件工程師。由于張工具有較強的技術水平和豐富的項目管理經驗，被正式任命擔任詼項目的項身經理。

張工接手此項目后，認真閱讀了當初向D公司提供的項目建議書，很快發現了項目 中存在的技術難題，于是在簽訂技術開發合同過程中就該問題對D公司做了較詳細的說 明，D公司最終勉強接受了張工的建議并簽訂了合同，合同中未再包含項目建議書中無? 法實現的功能需求。

Perfect公司與客戶方簽署了技術開發合同后，張工立即組織了項目組中兩名軟件工 程師一起開始需求調研工作，但在需求調研工作中，D公司變得越來越不配合，總是強 調項目建議書中所描述的無法實現的功能需求，并提出當初之所以選擇Perfect公司，就 是因為Perfect公司的項目建議書中描繪的這些功能是其他公司不能提供的。

為了取得D盆司方面的支持，張工親自做了大量的技術嘗試去完成這些功能，但經 過多方技術論證，該部分功能在目前的條件下是很難成功的。對該部分功能的技術論證 已經持續了一個多月，沒有取得任何實質性的進展。作為項目經理，張工感到相當大的 壓力和責任。

【問題11

請對Perfect公司銷售人員趙某在執行此項目過程中的行為進行點評。

【問題2】

請結合你本人的實際項目經驗，談談項目客戶關系管理的重要性。

【問題3】

請對張工解決此問題提出建議。23.2.5變更控制案例

閱讀以下關于信息系統項目管理過程中項目變更控制和客戶溝通管理問題的敘述，回答問題1—問題3。

案例場景

PERFECT公司是某市一家大型股份制軟件企業，公司研發人員達到200人，主要 從事電子政務應用系統和金融信息系統等方向的研發。PERFECT公司具有較強的政府 背景，公司副總經理兼技術總監張工原為該市政府信息中心總工程師，3年前創立了 PERFECT公司。

目前，PERFECT公司正在進行該市某政府機關的辦公自動化系統研發，系統主要 由公文管理、檔案管理、公共信息、會議管理、領導辦公、電子郵件、個人辦公、業務 管理和事務預警系統管理等子系統組成。

由于PERFECT公司具有較好的技術和產品積累，經過5個月時間，整個系統于3 個月前按進度計劃開發完成，目前系統處于試運營階段，運行情況良好。但是，項目一 直沒有結項，項目中出現了幾個以下問題。

(1)頻繁的需求變更。由于客戶屬于機關單位，客戶不斷提出一些變更，項目組就 要處理變更需求。

(2)客戶的工作效率低、節奏慢，很小的內部分歧也需要開會討論。在項目實施過 程中，嚴重單方面拖延實施進度，使項目不能按計劃結項，造成項目延期。

(3)客戶同PERFECT公司關系特別密切，不能完全按照合同進展，對合同規定的

階段驗收不予回應，這些問題需要公司老總出面才能協調，項目經理控制協調明顯乏力。

項目經理李工原為該項目的系統分析師，主要負責系統技術架構和系統分析設計，開發后期由于原項目經理王工離職原因，被任命為新項目經理。

【問題1:1

請分析導致電子政務項目產生上述問題的原因，對于電子政務建設組織管理的關鍵 是什么？

【問題2]

請結合你本人的實際經驗，談談如何有效控制電子政務項目的需求變更以及用戶需 求變更的處理方法。

【問題3]

請對李工解決此問題提出建諛。23.3綜合運用案例

23.3.1電子政務項目案例

1．項目背景

隨著電子政務的普及，政府機關的信息化進程不斷加深，剛剛進入2001年，北方 的工業化重鎮濱海市市政府正式推出《濱海市市政府電子政務發展綱要>，其電子政務 二期工程在年初也正式立項并得到批準，這標志著該市的電子政務二期工程開始啟動。

市信息化辦公室負責整個工程的開發與實施，其首要任務包括在該市電子政務一期 工程已經完成的電子政務專網的基礎上，實現政府機關全部網絡化，并實現無紙化辦公。與此同時，還要建設相應的配套服務設施，政府網站等，總投資3000萬元。

此項目經過方案設計、公開招投標、專家評審，于2001年5月確定了承包商A公 司作為項目總包，全部工期預計5個月，整個項目年底前完成。此項目包括了以下子項 目：

(1)計算機機房建設；

(2)政府辦公大樓的綜合布線工程：

(3)政府辦公大樓全 樓的網絡系統、服務器設備的集成：(4)濱海市政府辦公自動化軟件平臺的開發。并在 符合安全規范的基礎上，實現內外網的隔離和信息交換，確保能夠順利并入電子政務 專網。

?

2。項目遇到了問題

簽約后承包商項目組進入該項目現場實施，項目分為軟件開發、硬件集成和綜合布 線三個實施部分。負責軟件部分的項目經理是賀工，A公司任命他牽頭負責整個項目的 實施，于是，他從A公司售前經理唐工和銷售經理胡工手中正式接過了整個項目。由于 他深知這次中標的主要原因還是報價較低和完全承諾了苛刻的工期要求，因此內心一直 忐忑不安。但由于A公司是該市的著名IT公司，其總經理李總已經下了決心，一定要 保質保量按時地完成濱海市的政府信息化項目，決不能有半點差錯。于是，A公司派出 了副總經理王總親自主管該項目，三個項目組也都是由A公司的精兵強將組成。雖然A 公司還在南方某市進行著另外兩項電子政務工程的實施工作，但A公司王總認為，家門 口的事情都辦不好，還有何面目見家鄉父老，況且濱海市的電子政務第二年還將上第三 期，將要建設呼叫中心、社保信息系統等大型項目，所以征得A公司李總同意后，各分 公司各個項目技術人員重新調配，采用矩陣式項曰管理模式，前提是以首先保證這個項 目為原則。

布線和硬件建設方面進展相對軟件開發比較順利。軟件開發在該項目中實際上是難 度最大的一塊內容。由于濱海市政府機關關系復雜，工作流程比較煩瑣，再加上工期非 常緊，因此甲方很重視，要求很高。A公司項目負責人及主要開發人員在開發計劃、進 度安排、需求調研上與甲方進行了一周時間的溝通，總體比較順利，項目很快完成了需 求調研階段。由于濱海市信息化辦公室主管領導正在出國考察，因此項目評審暫時擱置，于是項目直接進入到系統設計和編碼階段。計劃中的第一階段是完成功能開發，第二階 段是界面確認和性能優化。至此，由于A公司已經擁有了成型的商業化辦公軟件(BG-2系統)，王總認為下面的只是定制工作了，對年底完工充滿了信心。建設方對A公 司的進度也比較滿意，主管該項目的市信息辦領導向市委匯報：項目進展順利，年底前 一定請市長給該項目剪彩。

在一個月后，系統已經進入第二階段的界面確認和性能優化工作。但是在系統的第 一次階段性審查中，A公司的項目方案卻受到了專家組（由外聘專家和本地政府領導組 成）的批評，認為該系統的設計沒有充分體現濱海市政府辦公的實際需求，而是過多地 沿襲了A公司的商業化辦公軟仲的流程，一句話，針對性不夠，責成信息化辦公室立即 對項目進行補救。兩周后，方案在第二次評審會上又遭到了質疑，而且由于這次評審加 大了濱海市市政府各個主管領導和相關處室領導的比重，大家對方案評頭論足、與A公 司爭執不休，而且許多意見是與當初需求調研時不同或改進的，或者就是主管領導進行 調整導致意見完全不同的，最終會議幾乎沒有達成統一的意見，這使A公司王總十分難 堪，只得答應補充技術人員，再進行更進一步的需求調研。

可就在這個時候，南方的電子政務項目出現了問題，A公司李總不得不把項目組里 面的一部分原有人馬調去南方“救火”。又過了一周，在各方參加的項目協調會上，A 公司王總無奈地提出聘請專業的信息化咨詢顧問公司介入該項目，幫助A公司完成該 項目。

3．介入項目

于是，國內著名的信息化咨詢顧問公司B公司進入到項目中。本項目的咨詢總監由 謝經理擔任，對于眼前的僵局，他沒有急于拿出咨詢方案，而是首先對A公司的項目經 理賀工和韓工進行了溝通。

訪談之一

負責項目技術總體工作的賀工對項目目前的狀況發表了自己的意見：通過對目前項 目的狀態進行分析后，他認為A公司目前已經遇到的問題如下。

(1)用戶需求難以確定。市政府中很多用戶很明確政府信息化的作用，也找到了實 施方向，但對于自己在其中的需求很模糊，所以這次項目中他們要么就是各部門提出很 多雜亂的要求交給A軟件公司，要么就是請A公司自己通過調研整理出需求，然后請用 戶確認，但隨著項目的開展，往往需求的想法也隨之發生變化，變化是需要的，但是變 化太頻繁、變化的幅度大，直接影響了項目的實施進度和效果。

(2)工作量難以確定，導致項目總體進度無法把握。用戶需求不確走導致工作量不 確定是原因之一，更重要的原因是迄今為止仍然缺少有效的技術與方法來事先估算系統 分析與系統設計所需要的時間。盡管經驗很重要，但因為電子政務發展很快或系統本身 更新也很快，解決方案越來越細，越來越專業，很多大系統也是首次“開發”或使用，估算的計劃與實際往往有偏差。還有另外一個原因就是系統實施過程中出現的不確定因 素，例如政府人員變動、部門定位受到改革的巨大沖擊等。

(3)項目實施難以按期完成。項目不能按期完成現在已經是明擺著的了，這也是用 戶抱怨最多和最強烈的。可以說大多數子項目都不能如期完成，或者會留有“尾巴”，有 的甚至很可能會導致整體項目失敗。而目前不用說無人可調，即使人力增加，實際效果 也無法保證。

(4)用戶方沒有及時了解問題。在這類信息化項目過程中，往往壞消息向上傳遞的 速度較慢，報喜不報憂幾乎是所有組織存在的通病，實施過程中出現的問題往往被中層 過濾掉，不能及時反映到管理和決策的高層中去，有時候用戶也礙于情面私下解決，導 致出現的問題不斷積累，出現的錯誤不能及時糾正，直到評審會上才暴露出來。而這時 已經發展擴大積累到難以糾正，或者調整的代價太大，就像現在的狀況。

(5)項目組內部的工作方泫的不一致。由于項目組技術和管理人員被臨時抽調在一 起，甚至是來自不同分公司，以往工作方法不盡相同，所以在工作中難免會造成沖突，尤其在項目進展不順時，互相埋怨和推卸責任使項目也受到影響。本項目中，各個項目 經理對于目前的局面意見不一，幾乎沒法協調統一工作。

所以賀工認為，本項目已經很難進行下去了。

訪談之二

直接負責項目需求調研工作的韓工對此也發表了自己的意見：“我屜怕做政府的項 目”，他認為政府項目的“圍城”難以逾越。對此也許是看到賀工在場，他沒有直接說明 對本項目的看法，只是對謝經理談到了他兩年前的一段相似的經歷：

韓工原是內地某市一家軟件公司C公司的技術經理，大大小小的項目也做過了十幾 個，一年前來到A公司，對于政府項目他頗具發言權，他認為雖然近兩年電子政務很熱，好多公司都把政府行業作為發展的重點，但是有些項目并不好作，原因一言難盡。

首先是需求調研的結果難以控制。兩年前，C軟件公司承接了一個金額為幾十萬元 的政府OA項目。項目金額雖然不大，卻被該公司內部定為“力?！钡捻椖?，配備了公 司展強的項目經理、組建了一支十凡人的開發隊伍，公司并且指示該項目組可以隨意調 配所需資源。如此重視該項目的原因一方面因為源于對電子政務的重視，另外很重要的 一個原因是軟件公司正是在該政府部門管轄范圍以內，論起級別來，公司的老總也不過 是該部門的處級干部。然而，雙方地位的不對等使得項目實施過程憑空增加了幾分難度： 客戶稍有不滿，便會直接給老總打電話，而這是較件公司上上下下一致懼怕的。

其間政府錯綜復雜的關系令項目經理誠惶誠恐、如履薄冰，卻仍然不能避免麻煩的 發生。在項目展開始的需求階段，軟件公司就嘗到了苦頭。做軟件項目最怕的就是用戶 需求模糊，幾乎和現在的項目一樣，他們從客戶這里無法得到一個明確的需求是讓軟件 項目組最為頭疼的事情。當時，政府信息辦這邊共有3個人，3個人都略懂技術，雖然 所知有限，但是按理說，提出需求應該不是什么難事。但是因為客戶這邊沒有配備專門 的、專業的技術人員來負責確認，因此提出的項目需求朝令夕改，光是項目需求這個程 序就用了兩個月的時間，項目不得已只好延期。然后，客戶以項目不能如期交付為理由，投訴到公司（所以這次韓工直接到基層作需求調研，可結果依然不理想）。

隨著項目一步步地進展，接下來所發生的事情表明，需求階段出現的這段插曲并不 是偶然的，其間暴露出來的問題幾乎貫穿了楚個項目始終。為了保證客戶滿意，韓工領 導的項目組對客戶言聽計從，但是，客戶覺得自己懂技術，經常指手畫腳，可實際上他 們并非專業人員，很多技術程序并不十分明白，無法理解軟件公司的方案實質，與之溝 通也往往沒有結果。另一方面，叉對軟件公司有很強的防范心理，放在嘴邊上的一句話 足：“別以為我們不懂”，言外之意是“別蒙我們”，諸如此類，令項目經理們苦不堪言。最要命的是，這3人中沒有指定一個明確領導，又都想借此項目攢些“政治資本”，所以 對這個項目的掌控欲望都很強，而項目組是哪邊也不敢得罪，哪邊也得罪不起。公平地 講，需求總是變化，也不光是人的因素，在目前的情況下，很多政府職能在不斷調整變 化當中，這也給項目正常進行增掭了很大難度：項目進行當中，“客戶那邊可能就是調整 一個部門，但是我們這邊可能前邊的開發就都白做了，又得從頭干起，而客戶并不理解 這些，他覺得是應該的。做這個項目比做多少企業項目都累！這個項目打單的時候價格 就給壓得很低，再這么個折騰法兒，這回公司肯定是賠錢了！”韓工如此感慨（這與本項 目也幾乎一模一樣）。

“當然，上述問題當然也不僅僅是客戶方面的問題”。韓工認為項目經理也是關鍵，從軟件公司方面來講，項目經理對政府內部業務不熟悉，同時由于雙方地位的懸殊，因 此很難得到政府客戶的有效支持。很多政府機關在IT項目中，相關的責權不夠分明，同 時缺乏協調性。這無形中增加了項目的實施難度，同時也很容易埋下隱患。

另一方面，很多項目中，作為公司代表的項目經理、甚至是公司級領導在本公司所 能調配到的資源也很有限。事實上，在一般的公司中，項目經理甚至很難調配公司資源?，F在很多的軟件和系統集成公司運用的是矩陣式管理模式，為了凸顯對項目管理的重視，項目管理部往往被獨立出來。理論上來說，這樣做可以讓項目經理更自如地組織各方資 源實施項目，但實際上由于成本原因，公司的技術人員有限，使得項目經理無法組織有 效的工作。兩方夾擊之下，項目經理根本無法真正地執行項目管理職責。如果再加上公 司內部項目沖突（就像現在），就會更加加劇這種情況。

4．A公司的兩份項目管理文檔

與A公司的兩位項目經理溝通完，咨詢顧問公詞謝經理陷入了苦惱，整個項目目前 是一團亂麻，許多事情都需要從頭捋清，尤其在這個階段咨詢顧問公司才進入，當然也 是各方對其的信任，但他也明顯感到這個項目的沉重。作為顧問咨詢方的負責人，咨詢 顧問團隊正在等著他作出判斷，A公司也催促著要咨詢公司的具體實施方案，希望咨詢 公司能夠對這個項目起到提綱挈領的作用。

他沉思之后，覺得整個項目的最大問題應該還是項目管理問題，A公司的項目管理 到位了嗎？帶著疑問他馬上找到A公司的王總，向對方提出了自己了解到的情況，同時 也充分向其了解聽取了A公司對本項目整體管理的思路。兩個小時后回到自己的辦公室，謝經理整理著王總剛剛談到的《項目經理工作職責》和《項目管理操作手冊》，他覺得王 總的介紹應該表明項目中A公司應該進行了相關管理，也有相關文檔，但為什么結果不 好呢？他突然意識到，項目的進展不順利，恐怕還是落實問題，國內許多公司的標準化 文檔做得很好，質量控制條理也頭頭是道，但說的與實際操作卻不是一回事。他于是對 手中的兩份文檔仔細地分析起來，希望能從中找出一些癥結。

A公司項目經理工作職責（梗概）

1．項目啟動階段

在項目意向明晰后，項目銷售和售前經理的工作職責為：查閱資料，確定助手，刮 定下一步計劃。

(1)查閱資料主要分兩方面：-方面是OA的技術實現，一方面是政府的日常運作 流程。

(2)助手的主要工作內容是在技術和業務方面與項目經理有互補作用。

(3)制定下一步的計劃：和客戶面對面的溝通，了解客戶的期望以及對項目的認知

第23章案例分析

527 情況，了解客戶的業務；進一步了解相關技術；編寫設計方案，協助投標。

2．項目實施階段

(1)項目組織。

項目實施經理在經過分析之后，從各部門抽調人員組成項剛團隊，然后召開第一次 項目會議，根據公司現實情況做了鼓勵和動員，通報項目的目標和時間，分派相應的職 責給每一個人。

本項目具體的項目組織結構和角色如下。

項目總監：王總

項目經理：賀工

系統架構設計師：黃工

OA開發組經理：賀工

網站開發組經理：呂工

機房建設和網絡布線組經理：謝工

系統集成組經理：隋工

(2)項目實施。

①在項目組織結構和角色確定后，項目經理組織“系統架構設計師”成員共同工作，在基于先前提交的計劃基礎上，進一步細化WBS和項目的實施計劃。

②在計劃制定之后，項目的成功與否就要看計劃的執行，以及針對實際情況進行應 變的能力。

@相對于技術人員，項目經理的工作重點是調度資源、監督和控制進度、指導工作。

④項目經理和各方面人員的溝通是確保項目順利進行的有效手段。

⑤根據項目的情況，項目經理確定應用軟件的開發分兩階段：第一階段是完成功能 開發，第二階段是界面確認和性能優化。確保軟件開發更容易控制。

@依照甲方要求，進行必要的階段性評審。

⑦加強刪試工作，保證項目質量。

3。驗收階段

在項目的驗收階段，項目經理主要關注的工作內容如下。

(l)總結和移交存檔各種資源（如設備、文檔等），其目的是使得公司能夠不斷積累 有關的知識。

(2)對軟件產品的發展提出建議，供公司領導決策，其目的是為繼續拓展市場做 準備。

(3)總結分析本項目的成敗得失。

A公司項目管理操作手冊（梗概）

項目經理在項目進行的各階段，工作內容如下。

(1)工作職責和內容。

(2)所提交的交付物。

(3)所關注的項目里程碑。

(4)需要控制的關鍵要素。

(5)各種計劃外情況的處理和控制。

(6)需要整理和存檔的文檔。

1．項目啟動階段

(1)可行性研究、初步需求分析、編制項目立項書、項目章程。

(2)交付物如下。

①項目立項書，內容包含項目目標描述、確定項目經理、項目啟始和結束時間。

②項目章程。

⑨項目可行性方案。

④項目初步需求分析報告。

2．項目計劃階段

(l)編制各類項目計劃，目的是指導項目的實施，它具有現實性和有用性。

(2)將各項計劃交用戶確認。

(3)具體包括項目整體管理計劃編制、范圍計劃編制、范圍定義、歷時估算、進度 計劃編制、資源計劃編制、成本估算、成本預算、質量計劃編制、人力資源計劃編制、組織計劃編制、溝通計劃編制、風險識別、風險應對計劃編制和采購計劃編制等。

(4)在項目范圍計劃中最重要的是WBS分解結構。

(5)主要交付物有項目整體管理計劃、軟件客戶化計劃、工程實施計劃、項目集成 測試計劃、項目聯網測試計劃、軟件產品開發計劃、軟件產品質量管理計劃、需求分析 計劃、需求規格說明書、產品設計計劃、概要設計說明書、詳細設計讜明書、產品實現 計劃、測試計劃書、配置管理計劃、軟件分包申請、軟件分包開發計劃、培訓需求計劃 表和開發立項申請報告等。

．(6)項目里程碑。用戶確認各項計劃。

(7)關鍵控制點。范圍、進度、質量、成本計劃及項目整體管理計劃。

3．實施階段

(1)項目整體管理計劃的實施。針對項目進行中的變更提出《項目×X內容變更 申請》。

(2)采購管理的詢價。根據《項目軟、硬件購買清單》和《軟、硬件供應商清單》，通過廣告和招標等方法，確定合適的賣主，生成《項目軟、硬件購買建議書>。

(3)采購管理的資源選擇。根據《項目軟、硬件購買建議書>、客戶和公司的購買條 件，通過與賣方的談判和估算，生成《××軟件購買合同》或《××設備購買合同》。

(4)采購管理的合同管理。根據各種采購、購買合同和實際中的使用情況，以及賣 方提供的發票，通過本方對采購物品的使用情況反映和本方的支付系統，對本方支付系 統生成《××設備（軟件）付款申請》、對發生的合同變化生成<××設備（軟件）訂 購變動報告》、為項目驗收提供各種來往信件。

(5)質量管理的質量保證。根據質量管理人員對項目進行的質量測量的結果《項目 第×周運行情況報告》，對項目提出質量改進和調整。

(6)人力資源管理的團隊建設。根據《項目人員名單》、《項目階段計劃》、《項目人 員職責列表》和收到的各種對項目人員的反饋，通過項目組建時的獎懲機制，生成《項 目第×周××人的工作情況記錄》，并對其進行工作改進的要求。

(7)溝通管理的信息發送。根據項目進行中的工作結果（包括《項目第×周問題匯 總》、《項目第×周任務完成表》等）、《項目干系人清單》、《項目階段計劃》，分別向相 關人等發送或收到相關人等的《項目第×周周報》、《項目第×日日報》和《項目階段 報告》。

(8)范圍管理的范圍審核。根據《項目工作范圍說明》、《項目工作分解結構圖》等 內容，讓客戶確認，得到客戶認可的《項目工作內容確認書》。

4.收尾階段

(1)項目經理在收尾階段的主要工作有管理收尾和合同收尾。

(2)管埋收尾涉及為了使項目干系人對項目產品的驗收正式化而進行的項目成果驗 收和歸檔，具體包括收集項目記錄、確保產品滿足昂終規范、分析項目是成功或有效、保存項目信息以供將來使用。

(3)合同收尾是指確認一個合同的所有管理事務己全部完成，亦即此合同已經實實 在在地完成了，即供方已交付了所要求的貨物或完成了所要求的服務，合同各方已經檢 查并接受了貨物或服務。

(4)主要交付物有項目檔案、正式驗收的文件、吸取的經驗教訓的文檔、合同文件、正式收尾的文件。

(5)里程碑：正式收尾的文件(Contraot Completion Statement)。

①主要控制文檔的完整性，文件的正式性。

②防止沒有正式的項目結束文件。

謝經理打定主意，看來目前的問題不僅僅是項目的管理粗放，并且沒有落到實處，而且項目管理的大環境也不好，所以要想改變現狀，首先要作的就是兩件事：-是規范 項目，建立雙方的工作信任平臺；二是針對A公司的問題，提出有針對性的改進意見。之后，在此基礎上再制定出針對本項目特點的、針對項目中需要特別注意的、工作重點 明確的咨詢工作計劃。

【問題1]

針對本項目，你認為電子政務項目的難點在哪些方面？試對應設計本項目咨詢公司 的咨詢項目紐織機構。

【問題2]

你認為目前項目發生的停滯癥結在哪里？原因是什么？咨詢公司對應目前的局面 應該如何采取措施？

【問題3:1

賀工對項目目前狀況的分析都提出了哪些問題？是否正確和全面？應采取的解決 措施有哪些？

【問題4]

韓工以前經歷的項目與當今的項目相同的問題都有哪些？能認為這些都是這類項 目本身的特性所決定的嗎？你認為韓工的分析是否正確和全面？并從項目管理角度分析 是否可以避免？如何避免？

【問題5]

從其項目管理操作手冊分析A公司的項目管理是否存在問題？提出如何解決的咨 詢建議。

23.3.2南方電信項目案例

項目背景

中國新興集團公司地處華南，是這幾年新興的、專門服務國內電信營運商的集團公 司。經過艱苦卓絕而又十分經典的一輪銷售戰役，新興公司贏得了一個富有市場戰略意 義的合同：為南方移動21個業務區開發并實施其網管系統。公司領導非常高興，希望能 乘勝追擊，漂亮地執行好這個合同，然后順勢拿下受這個合同影響較大的華南其他4省 的網管系統。

項目目標、任務

本項目為南方移動直放站和室內覆蓋網管系統一期工程，目標是建立一個能夠同時 監控各個廠家GSM、CDMA直放站、室內覆蓋系統的網管系統平臺，在2003隼2月～ 2003年6月底的4個月的時間里，接入包括全省21個業務區所有在網運營的直放站及 室內覆蓋設備。整個工程以全省現有直放站及室內覆蓋統一網管系統和2004年工程目標 的業務量為基礎，并充分考慮將來的擴容需求。

網管項目實施過程中通過對網管中心功能的增強、對新設備網管功能的開通以及對 舊設備進行整改或升級，達到100%的接通率。

因為業務的需要，同時也是中國移動的要求，客戶方非常重視這個項目。事前客戶 方就按中國移動的規范再加上自己的技術要求拿出了一份本項目的技術規范，要求新興 公司按該技術規范進行項目實現（簡稱該規范為《技術》，該規范是合同的附件），同時 也要求新興公司對該項目配備足夠的資源，做好項目管理，務必按約定的時間使新系統 上線使用。客戶方指派處長郭軍負責協調這個項目。

新興公司（以下簡稱“公司”）委任了王東為項目經理，王東的部門經理張廷為項目

第23章案例分析 531 總監。張廷是公司工程部的經理，也是公司的元老之一。工程部是負責合同實施的部門。項目組的初始成員由工程部的5位工程師和研發部的3名工程師組成。公司項目管理部 派了一位QA負責質量方面的管理工作。按公司平常的工作規程，各部門跟本項目相關 的責任如下。

·工程部：總體負責合同執行、項目實施，包括軟件部分和接入部分。

·研發部：負責協助網管軟件的定制。公司在電信網管方面有較好的積累，研發部

是公司原網管解決方案的開發部門。

·項目管理部：負責指導和監督各項目的項目管理工作。

·銷售部：負責銷售及收款工作，在項目過程中篇要一定程度配合項目實施小組的 工作。

·商務部：負責設備和外購軟件的采購、發貨以及外包服務的選擇等商務運作。本

合同在本項目中需要從國內外采購一批網絡設備。

1．項目計劃部分

被委任為這個項目的項目經理后，王東心理有點復雜。一方面是因為接了一個比較 重要的項目、公司領導根重視所以比較*奮；另一個方面，他對項目感覺沒底，心里有 點兒空蕩蕩的。王東對網絡還算熟悉，但對軟件編程不是很熟，自己覺得只能算還行。進公司快兩年了，對公司的運作制度和項目管理制度也算比較熟悉，項目做過好幾個，也算是有～定經驗的項目經理了。

王東的回憶：

知道我負責這個項目后我比較關心的是項目的時問要求和人員問題。項目合同我大 致看過，時間已經定死了，4個月，6月底要上線。人員方面給我派了本部門的4人和研 發部的3人。我們需要完成什么工作呢？軟件開發扣2 1個業務區的接入，按《技術規范》 徽，4個月的時問連我在內8個人能完成嗎？說實話，這就是我一心里最沒底的 地方。

這個項目的工作范圍應該是明確的、固定的，《技術規范》我還沒看過呢！但這么多 工作4個月是否能完成可能誰也不清楚，這“4個月”是銷售部門跟甲方商定的，估計 甲方有要求有壓力，而銷售部想起來覺得也差不多就定下來了，事前工程部一點兒都不 了解；8個人夠還是不夠呢？誰都不清楚，沒有概念。我還是先做項再計劃吧。

公司里有一套項目管理的制度，按照項目計劃模板去填就可以了，我花了差不多一天多按以下順序填好了計劃模板中的各主要部分。

·項舄概迷和約束。

·項目組織和報告渠道，·項目過程和方法。

.WBS。

·項目規模、工作量估計．

·進度計劃。

(1)項目概述和約束

①關于項目目標沒有太多需要考慮的地方，這些目標之類我都是基本上照抄我上一 個項目的相同內容?？蛻簦脩舻膬热菀埠芎唵巍?/p>

⑦關于軟件總體功能描述在（（技術規范》里都有，我只寫了一句話概括了網管的 功能。

③關于主要約束，我主要寫了進度約束。

·需求分析：2003.2.17-2003.3.7

·總體設計：2003.3.10-2003.3.31

·詳細設計：2003.4.1-2003.4.30

·編碼：2003.5.7-2003.5.31

·測試：2003.6.1-2003.6.30

·初驗：2003.7.1

·終艟。：2003.9.20

本項目不存在成本和資源約束。

④本項目與公司其他項目和部門沒有依賴關系。

(2)項目組織和報告渠道

①我分了兩個組：軟件組和網絡組。軟件組由李鵬負責，網絡組由我負責。

⑦我把以下各角色的責任都描述出來了。

·項目總監（張廷）

·項目經理（我）

·軟件組長（李鵬）

·網絡組長（王東）

·項目支持（李克明，主要負責質量保證）

③報告渠道。

·項目組周例會，項目組內每周召開。

·給客戶的雙周報，向客戶即甲方匯報項目情況。

·項目報告，每雙周向公司江報項目情況。

(3)項目過程和方法

①在軟件方面，我們按常規的軟件瀑布型過程進行開發，其他沒有特殊的技術 方法。

②因為開發工作時間有限而且看起來不復雜，我裁剪了代碼走查、弱化了總體設計、詳細設計、單元測試和配置管理的工作。

(4)工作交付物及WBS

①項目的最終交付物是可正常運行的南方省級網管系統及相關文檔，包括如下

內容。

·網絡系統軟件的可執珩印灑。

·系統技術手冊。

·合同規定由我方提供的設備。

·達到氍技術規范》要求的網絡系統。

@按項目的時問順序，按照想象中的一件件工作我基本上分解出項目的工作分解結 構。每件工作我都標注上其輸出，走部分工作都在三五天以內，少數是10天左右．軟件 部分的工作基本土是接軟件開發生命周期進行分解的，接入部分的工作基本上按各地區 工作的時序進行分解。

(5)項目工作量估計

有了WBS估算項目艦麒和工作量就比較方便了。先為每一項子任務估算一個工期和 占用的資源，然后可以很容易地累加出總工作量。不過，既然總工期已經定死了是4個 月，那我定義的各任務的時間都是從速一最大的約束出發湊出來的。

(6)進度計劃

按第一項的進度約束我定叉了幾個里程碑。

(7)其他

因為還有風險日志，所以我不需要在項目計劃中針對風險作什幺計劃，等項目啟動 后，接風險日志的格式再處理也不遲．

有了計劃棋板，項目計劃確實好做多了，不過對這個項目而言有不少地方我還不太 有把握，例如WBS、任務工期及進度安排、資源安排、項目工作量等。但因為有橫叛的 格式，我還是按大致的估計填上了些內容，總不能空著。

王東把項目計劃提交給都門經理張廷和公司項目管理部。

張廷拿到這份計劃，他最關心的是能不能按公司領導的時間要求完成這個項目。從 進度安排方面看，蜃后的完工日期是符合合同要求的，這份計劃沒問題。另外，從組織、責任、溝通渠道、工作交付物和WBS等方面基本上都是常規的一些內容，每個項目大 體上都是寫這些內容，也都看不出有什么問題。他問了一下王東：“做好這個項目沒什么 問題吧？公司高層領導可是很重視的啊。”

王東也想不出有什么重要的問題，就說：“現在項目還沒開始，也沒什么問題。時間 方面現在心里沒底，我努力爭取吧。人員方面以后要是有什么需要還請老總您老人家多 支持l"

張廷說：“您千萬別}現在每個項目都很緊張，能給你抽出8個人已經很不容易了，你知足吧！”

公司項目管理部小林問了張廷對這個計劃有什么意見，張廷說沒有。小林看看項目 計劃的格式、內容基本符合要求，而且部門經理也沒意見，就批準了這份項目計劃。

按項目計劃，項目軟件部分的第一大項工作是進行需求分析。這方面工作王東讓軟 件組長李鵬全權負責。甲方這邊的負責人郭處讓他手底下的小凌負責跟李鵬來談軟件需 求。小凌和另外兩位甲方的人員針對未來的網管系統各個功能分別提出他們的想法，李 鵬他們就逐一跟他們談逐一作記錄。雖然談需求進行得不是很有規律，但是最后需求分 析還是按時完成了，得到了一份關于該項目網管系統的需求說明書。該說明書對系統的 各個功能、使用方法都提出了要求，有些要求非常具體。

李鵬告訴王東說這份需求文檔的內容雖然有些方面提得比較細，但有不少地方跟《技 術規范》不一致，想商量商量怎么處理。最后他們覺得這份需求有些地方是對《技術規 范》的發展，有些地方是細化，體現了甲方現在對網管系統的實現要求，與其到測試或 驗收時再處理，還不如現在就考慮。王東把需求文檔提交給了甲方請他們審閱。

設計、編碼工作基本是以需求文檔為基礎而進行的。

項目工作鋪開后，大家才發現項目的工作沒有原來計劃的那么簡單，有些工作在原 WBS中是沒有的，還有不少工作是計劃外的，這都占用了項目成員的很多精力。王東習慣性地感嘆：“意外太多了！怎么我們做的每一個項目都有這么多意外，原來做出來的計 劃就沒有辦法順利地執行下去，計劃沒有變化快啷】”這樣，項目計劃就沒辦法按原來的 進度要求走下去了，原來每個人的正常工作節奏全都被打亂了，每個人都很忙。

關于接入部分的工作，王東去了南方某省需要接入的好幾個地方才發現甲方各地準 備工作根本沒準備好，這將會嚴重地影響整個項目的進度，而這些準備工作原本是新興 公司希望甲方在接入工作開始前就做好的，甲方也曾說他們將負責把各地所有的接入準 備工作都做好。王東問各地的相關負責人這個項目的工作怎么安排，負責人的回答大同 小異，基本上都說省局為這個項目召集他們開過會，具體的工作也都考慮過或做過一些 工作，不過現在工作特別忙，有部分工作也沒顧上，有些人還說曾想好好完整地規劃好 要做的所有準備工作，但也不清楚準備工作具體都需要做哪些。王東又打電話問負責這 個合同的銷售代表老楊：“關于接入的準備工作當初跟甲方是怎么定的、怎么交待的？” 老楊說：“哎呀小李，你不找我我還想找你呢，簽完合同就不知道這個項目怎么樣了。你 說各地市的接入準備工作嗎？他們說是他們負責的呀，我就沒多管，你是不是該督促他 們一下??？”

接入工作的進展也影響到了軟件開發的工作，按原計劃到5月中旬應該可以進行軟 件調試的網絡環境沒按時就緒。

按王東的項目計劃研發部虛該在4月初額外派3個人來三、四天幫他們解決一個技 術問題。時間到了4月初研發部卻沒動靜，王東急了，打電話問人怎么還不過來，研發 部經理詫異地問：“你什么時候跟我說過這事？”王東說：“我都寫在計劃里了！計劃也 發給過你了！”研發部經理說：“每天文件這么多，我怎么可能把你的每一個字都細看 呢？”

還有一件更麻煩的事：公司為甲方所訂購的一批網絡設備到貨時間將會耽誤項目的 進度，國內供貨部分還好一點，國外供貨最晚的要到7月中旬左右才會到貨。王東又感 嘆：“天不助我啊！”

王東每兩周都會跟郭處溝通一次項目的情況，郭處知道了設備到貨時間的問題后問 王東：“你們公司沒有去考慮過這個問題嗎？”

5月22日，甲方高層領導來到開發現場聽項目組的匯報并觀看系統演示，為了表示 重視，公司領導和張廷也來了。當時系統并沒有完全開發完畢，大家只看到了主要的功 能模塊。

看完后，甲方領導表達了意見。

(1)對項目的進度極不滿意。

(2)系統演示出的功能與《技術規范》不一致，母后的驗收將以《技術規范》為 標準。

(3)從項目前階段的工作過程可以看出新興公司投入到項目中的資源不足，希望新 興公司領導充分重視該項目。

(4)為對項目的溝通和監督，從當天開始甲方將每8個工作日來現場聽取項目匯報 并觀看演示。

公司領導對甲方的意見非常意外，立即讓王東匯報項目情況。王東的匯報中提到了 資源不足。領導問項目組的8個人他是怎么使用的，王東說從項目開始到現在他們都很 忙。領導無話可說，又問王東要增加多少人，王東說估計4人左右。領導說雖然公司很 重視這個項目，但現在公司資源非常緊張，需要王東詳細規劃出這4個人怎么使用的一 個計劃然后再審批。王東覺得這樣很麻煩，本來項目工作就很多，還要把耐間浪費在這 種形式化的表面文章中，但俗話說胳膊不能跟大腿擰、好漢不要跟領導頂，還是簡單寫 了這4個人各分配哪個方向的工作作為計劃交了上去。

在隨后的幾次匯報中，甲方領導在觀看軟件演示時多次提出了修改意見。對于這些 意見李鵬提出這屬于項目范圍變更，要求按變更來處理。但郭處說這不是范圍變更，軟 件功能本來就該做成這樣子，是開發組理解錯了，不存在變更不變更的問題。為了能夠 說服郭處，李鵬和王東詳細查閱了《技術規范》，結糶悲觀地發現在很多地方《技術規范》 并沒有清楚描述要做成什么樣，所以報難判定甲方的意見是不是屬于變更。既然是這樣，就只有滿足甲方的要求了。

項目的麻煩開了頭就剎不住，估計項目的時間目標是不可能實現的了，不知道客戶 的高層領導和公司的高層領導要怎么著急呢，唉……

現在回過頭來看項目的計劃，王東覺得這項目計劃其實真的沒什么用，項目是活的 計劃是死的能有用嗎．}還不如不做！只不過公司有制度，不做不行罷了。

2．項目執行保障部分

客戶領導的意見讓公司領導對這項目異常重視，幾個人陸續派來了。

關于設備到贊的問題，公司領導責成公司商務營運部門抓緊催貨。沒到貨之前怎么 辦昵？張廷召集相關的人開會，大家出謀劃策，決定從公詞和客戶兩邊先湊或借部分可 用的設備，在佛山先建一個示范點，把示范點的做法制定為規范，等設備到貨后再COPY 到其余20個點，這樣能大大地節省后期接入工作的時間。經與甲方商量，甲方很贊成，之后示范點設備的籌集很順利，隨后的示范點接入和調試工作也都很順利。

王東又感嘆了：“還是客戶的力量是無窮的呀！以前關于這些問題我也給張廷寫過周 報，我寫過可能會有設備到貨時間的問題，會有資源不足的問題，會有需求變更的問題，但都是石沉大海，現在客戶領導一發話問題解決得真快！”

王東的回憶：

項目的氣氛緊張了很多，由于巨大的進度壓力，我規定全體人員每天都加班到晚上 9點半以后，周末也不休息。連續加班一段時期之后大家好像非常疲憊，全組人員一起 吃飯時話也不太多了，情緒變得不高了，積極性、工作效率等各方面都明顯下降了。

以前項目組開周例會大家還挺積極，七嘴八舌地提出不少建議，而現在大家無精打 采沒什么話，除了王耕田偶爾發發牢騷或講個段子。真是無可奈何：既然大家都這樣，干脆以后周例會也別開了，我每周大致問一下大家的工作情況就算了，反正大家都忙，頂多是我一個人多辛苦點，辛苦我不怕。

我發現如果以各項目成員為節點畫一張項目信息流劫的示意圖，有些人好像會成為 信息的“梗阻”，個別人居然趨向于成為“孤島”。不過，我覺得人的性格是很難說的，強求大家都像王耕田那樣特愛說話也不可能。

管人真是麻煩！這些問題讓我作為項目經理很難做工作，公司對項目的支持還是不 夠，公司應該把人管理好，這些人才能為項目服務好。

李鵬的回憶：

詳細設計、編碼和單元測試工作的結果讓我不滿意，客戶也不太滿意，項目進度也 被拖延不少。王東和我一分析原因，覺得其中很大一部分原因是項目組里有幾個成員不 太熟項目所用到的開發技術，無論是測試還是編碼問題都比較多，工作的反復比較多，表現也不專業，設計寫出來五花八門、各有各路，編碼更是天女散花，要多花有多花，急得我恨不能上去自己把所有工作全都做究。王東安慰我說公司派來的人也不可能所有 的都是高手，這也是正常的，我們自己不能急，習慣了就好了。

來自公司研發部的人讓王東覺得不好管理，他們中的部分人是身兼數職的，我們都 能看到，有時候他們會回公司忙他們別的工作，有時候他們人在項目現場但不停地為了 別的事情打電話。都是為了忙公司的事情，大家都能體諒。但有一次我覺得心里不舒服： 軟件的總體設計是請研發部的肖大躍做的，大躍是“大拿”，那段時間同祥是特別忙，匆 匆忙忙花兩天時間做出總體設計來，文檔中以前項目的“痕跡”都沒刪干凈。本來我覺 得在設計評審時QA和大家可能會找出不少問題來，但這個QA沒經驗，評審前沒讓大 家認真閱讀，我覺得參加評審的人員里閱讀了一小時的都算不錯的了。評審時因為有人 馬上要出差所以很快就過了一遍，兩小時都不到！除了改了改筆誤、刪掉原來的一些不 該出現的“痕跡”外沒談出什么大問題來。另外，大家有一個心態覺得這是大躍的東西 應該沒什么問題，大躍可是多大多復雜的系統都做過的“大拿”！但我懷疑這次大躍可能 連伐技術規范>都沒細看。后來事實還真證明我的懷疑是對的，客戶在測試的時候發現 我們的功能跟程技術規范》不一致，我們追根溯源一查，原來是大躍的設計照著舊系統 做的，沒考慮這個項目的要求．唉，耽旌我們一個多星期的時間啊。

說到這個QA，我還覺得有點不明白，設了QA他就應該把項目質量方面的事情全 都管理起來對吧？但他全都管得了嗎？他還是要我采負一些責任，還說我沒盡到責任！但我到現在也沒整明白在質量方面有哪些責任是該我負的，我也不清楚我具體負責的需 求，設計、編碼、測試這些過程里質量該怎么管。他說他的項目質量計劃里寫到了，我 怎么就覺得那玩意兒是個形式呢？沒有用！

甲方的小凌對小周所做的模塊不滿意，王東本來就對小周不滿意，于是詳細了解了 小周的工作情況，感覺小周雖然聰明但不踏實，有些工作該做但沒做得很好，有些工作 雖然不起眼但他該做沒做。王東直截了當地對小同提出批評了。小周報不服，說：“說我 該干沒干？可我頭到尾沒有清楚地得到過指示要我去做哪幾件事情，跟我交待過我要負 責這一塊，可是領導，這一?塊?到底多大誰知道啊?您認為我該做什么最好跟我明確 出來，要不然我根難猜。說我沒干好？?好?到什么程度能不能也一起告訴我？再說了，那些做得慢的您怎么不去考核一下？要是大家都考核，我應該還算好的呢！”

小周還提到了讓王東和李鵬不太好回應的一件事：正是因為他們倆決定把單元測試 和系統測試的部分工作簡化了才導致了后來出現的一些莫名其妙的問題。當時他們也是 想趕進度，沒想到現在省不了時間反而為了查找和排除這些問題費了幾倍的時間。什么 叫偷雞不著蝕把米？嘿嘿【王東從小周的眼神里看出了這個意思。

對小周的批評屜后也只能不了了之了。

讓王東覺得比較麻煩的還有客戶。客戶是上帝，上帝是給錢的人，上帝隨便咳嗽一 聲也絕對要注意聽著；客戶．還是合作者，沒有他們配合項目的工作不可能完成。不想不 知道，一想就發現項目里有很多事情需要客戶（或協調第三方廠家）去做而且他們能做 得好的，例如：

①提供各地的設備類型、數量、監控狀況和監控協議。

@對不符合統一協議的c網設備進行整改和升級。

@提供整改后的各地區需接入的站點信息。

④提供可聯調的實際站點。提供聯調配合計劃。

⑤對被接入的設備進行接入聯調，并提交聯調報告。

@外掛監控站點的接入實施工作。

讓王東頭疼的是客戶經帶不做好他們該完成的工作。下面這些是郭處、小凌或客戶 的其他人讓王東經常頭疼的話。

(1)“最近太忙，上周說的事還沒顧上。哎你們這邊差不多了吧，培我看看！”

(2)“下周一要三個人配合測試？你怎么不早說？今天都周四了，我們怎么來得及安 排人手出來啊？往后推一周吧？”

(3)“這種事也要我們做？你們這么熟，人又這么多，順手一弄就完了，啊，就這么 定了吧?！?/p>

(4)“這事我這種小兵管不了，我負不起這責任，你們還是找我們領導去吧！”

(5)“那是使用部門的事，跟我沒關系，你找他們吧……”

對這些話，王東都不知道怎么對付才好。

項目的壓力超乎尋常地大，客戶每8個工作日的檢查對項目組來說是個很大的負擔，而不是能解決問題的幫助，部門經理張廷和公司項目管理部經常追著問項目進度。

每天都有新的問題涌來、每天都有新的壓力，來自客戶的、來自公司的、來自項目 組成員的，進度方面的、資源方面的、技術方面的、亂七八糟方面的l面對這些鋪天蓋 地而來的信息、問題、壓力，王東覺得再下去就要崩潰了！

王東感嘆的是為什么每一個項目都不順、都這么麻煩，是自己運氣不好？公司的問 題？還是行業、客戶的問題？

3．項目控制部分

項目一開始公司領導和部門領導就一直希望這個項目能按目標完成，目標顯然不可 能達到時又寄希望于修訂后的目標能夠達到。項目經理被要求努力地去控制好項目以達 到各方面的目標。

王東的回憶：

一個事先沒有預料到的情況嚴重地干擾了項目的進展：甲方頷導每8個工作日的視 察有時滿意有時很不滿意，但不管怎么樣都會提出一堆意見和要求，這樣好那樣不好，要這樣下次別讓我看到那樣等等。項目有項目原來的進度計劃，每天干什么都有安排，而為了滿足這些要求原來的安排全都被打亂了。甲方提出的這些意見有的跟《技術規范》 一致、有時不一致，一開始我和李鵬還想部分頂住，但因為甲方領導層次較高，我覺得 他要是震怒可能公司領導又會很緊張，同時也不希望因為我不同意滿足甲方的要求讓甲 方向高層領導投訴，這樣會讓我很被動。

這種對修改要求的滿足一旦開始就很難停止，這樣項目就陷入了很被動的循環，剛 把上次的要求改好了，想回復正常的開發節奏，新的一輪又開始了。這讓我覺得就像轉 輪里的小白鼠，自己永遠不知道什么時候是盡頭，直到累死為止，而外人覺得你在干你 該干的事情。

變化永遠都在發生，這是極其討厭的事情，說實話，我現在很怕聽到這種壞消息，但這種消息從項目一開始到后來還是很多。

(1)網絡設備到貨比預期晚。

(2)甲方的接入準備工作沒做好。

(3)甲方的開發配合工作沒按計劃做好。(4)項目資源的可用性發生變化。(5)技術難題的難度超乎意料。

這些變化只要一出現就讓我們沒辦法按計置|j走下去。

公司要求我控制的兩個最重要的方面是項目進度和項目成本。

美于項目成本，我也想控制，但我實在不知道除了控制項目赧艄費用外還有什么措 施可用，反正項目費用預算的總額現在還沒超，除了這一點其他的情況都無法判斷，所 以也就沒辦法控制。

關于項目進度控制，我現在覺得是一個很虛無縹渺的事情，講得實在一點就是：如 果項目沒有意外，項目的進度你就能控制得住，有了意外你就控制不住，就這么回事！

另外，公司讓我們每個月都要進,f帶-值分析，累死人又沒有用，唉……

關于項目周例會：項目組一開始還開周倒會，例會內容有如下兩項。

(1)每人匯報上周的工作情況，有沒有完成任務。

(2)確定下周工作的任務安排。

后來周例會也不開了，基本上都由王東依次問大家的工作情況再安排一下下周的 工作。

張廷覺得這個項目各方面似乎都處于失控狀態，問王東他對項目都有哪些控制措 施，王東說了一堆，張廷覺得都沒到點子上。他問王東：“你覺得項目怎么樣才能控制得 ??？”

王東覺得不好回答，想了一想說：“第一要防止意外發生，第二要靠運氣!”

這個項目確實基本處于失控狀態。

在進度方面，原計劃是7月1日初驗，后來改成8月10日，然后再改成10月8日，然后……里程碑目標一拖再拖，眼看目標顯然不可能達到就又把進度目標修改一次，每 次都有客觀原因（公司項目管理部事后總結發現，要求進度目標延期或項目預算增加的 每一個項目都有絕對充分的理由、都有一大堆客觀原因）。

在項目費用方面，報銷的費用倒是不多，但整個公司里誰也沒概念：這個項目現在 已經花了多少錢，還允許項目可以再花多少錢。

在項目質量方面，一句話就可以概括：時間和資源換質量。各個環節都出了不少問 題，大部分問題是用人和時間去換的，小部分問題就算了，以后再說了，顧不上了。

最后，項目在12月5日終于通過初驗了。涉及到這個項目的所有人好像都舒了一 口氣，但沒有人有多少笑容。本來所有人對這個項目的期望值都挺高的，但現在落差太 大了。項目的成本遠遠超出了預算，無法不超，因為拖延了這么長時間、增加了這么多 人。王東知道的只停留在超出預算的數字上，但公司領導考慮的是：這個項目我們賺到 錢了嗎？我們賠了多少錢？以后這種項目還能做嗎？

各位項目成員也不開心，辛苦了這么長時間，項目沒有一個值得大家高興的結果，

第四篇：51CTO下載-系統集成項目管理工程師典型 13 案例分析

系統集成項目管理工程師典型 13 案例分析（下午試題保過版）1.實施項目中擅自變更，好心辦壞事 在一個正在實施的系統集成項目中出現下述情況，一個系統的用戶向系統他認識的一個開發人員抱怨系統軟件中的一項功能 問題，并且表示希望能夠修改，于是，該開發人員就直接對系統軟件進行了修改，解決了該想問題，針對這一問題請分析如 下問題： 問題

一、說明上述情況中存在哪些問題？ 問題

二、說明上述情況會導致什么樣的結果？ 問題

三、說明配置管理中完整的變更處理流程。問題解答： 問題

一、上述情況中存在的問題：

1、對用戶的要求未進行記錄；

2、對變更請求未進行足夠的分析，也沒有獲得批準；

3、在修改過程中沒有注意進行版本管理；

4、修改完成后未進行驗證；

5、修改的內容未與項目干系人進行溝通。問題

二、上述情況會導致的結果：

1、缺乏對變更請求的分析可能會導致對產品的變更工作出現欠缺，與其他工作不一致等問題，對項目的進度、成本、質量 方面也會產生一定的影響；

2、缺乏對變更請求的記錄可能會導致對產品的變更里是無法追溯，并會導致對工作的產物的整體變化失去把握；

3、在修改過程中不注意版本管理，一方面可能會導致當變更失敗時無法進行復原，造成成本損耗和進度拖延，另一方面，對于組織財富和經驗的積累也是不利的；

4、修改完成后不進行驗證則難以確認變更是否正確實施，為變更付出的工作量也無法得到承認；

5、未與項目干系人進行溝通可能導致項目干系人之間的工作出現不一致之處，進而影響項目的整體質量。問題

三、配置管理中完整的變更處理流程：

1、變更申請，應記錄變更的提出人、日期、申請變更的內容等事項，2、變更評估，對變更的影響范圍、嚴重程度、經濟和技術可行性方面進行評估。

3、變更決策，由具有相應權限的人員或機構決定是否實施變更

4、變更實施，由管理者指定的人員在受控狀態下實施變更，5、變更驗證，由配置管理人員或者受到變更影響的人對變更結果進行評價，確定變更結果和預期相符，相關內容進行了更 1/15 新，符合版本管理的要求，6、溝通存檔，將變更后的內容通知可能會受到影響的人員，并將變更記錄匯總歸檔，如提出的變更在決策時被否決，起初 時記錄也應予以保存。2.如何開好例會 老張是某個系統集成公司的項目經理,他身邊的員工始終在抱怨公司的氛圍不好,溝通不足.老張非常希望通過自己的努力來 改善這一狀況,因此他要求項目組成員無論如何每周都要參加例會并且發言,但對例會應如何進行,老張卻不知如何規定,很快 項目組成員就抱怨例會目的不明,效率太低,缺乏效果,等等.而且由于在例會上意見相左，很多組員開始爭吵，甚至影響到人際 關系的融洽，為此，老張非常苦惱。問題一：針對上述情況，分析問題產生的可能原因。問題二：針對上述情況，你認為應該怎樣提高項目例會的效果。問題三：針對上述情況，你認為除了項目例會外，老張還可以采取哪些措施來促進有效溝通。問題解答： 問題一：問題產生的可能原因：

1、缺乏對項目組成員的溝通需求和溝通風格的分析

2、缺乏完整的會議規程，會議目的，議程、職責不清，缺乏控制，導致會議效率低下，缺乏效果

3、會議沒有產生記錄

4、會議沒有引發相應的活動

5、溝通方式單一

6、沒有進行沖突管理 問題二：提高項目例會的效果的方法

1、事先制定一個例會制度，在項目溝通計劃里，確定例會的時間，參加人員范圍，一般議事議程等

2、放棄可開可不開的會議，在決定召開一個會議之前，首先應該明確會議是否必須舉行，還是通過其他方式進行溝通

3、明確會議的目的和期望的結果，明確要開的會議的目的，是集體討論一些想法，彼此互通信息還是解決面臨的一個問題，并確定會議的效果是以信息同步為結束還是要討論出一個確定的解決方案。

4、發布會議通知，在會議通知中明確：會議目的、時間、地點、參加人員、會議議程和議題。有一種被廣泛采用的決策方 法是：廣泛征求意見，少數人討論，核心人員決策。許多會議不需要全體人員參加，因此需要根據會議的目的，來確定參會 人員的范圍。實現應明確會議的議程和要討論的問題?？梢宰寘藛T提前做準備。

5、在會議之前把會議資料發放到參會人員手中。對于需要有背景資料支持的會

議，應是先將資料發給參會人員，以提前閱 讀，直接在會上討論?？梢杂行У毓澕s會議時間。2/15

6、可以借助視頻設備。對于有異地成員參加的會議，或者需要演示的場合，可以借助于一定的視頻設備，以提高會議效果。

7、明確會議規則。指定主持人，明確主持人的職責，主持人要對會議進行有效控制，并營造一個活躍的會議氣氛。主持人 要實現陳述會議的基本規則，例如明確每個人的發言時間，每次發言只有一個聲音，主持人根據會議的議程規定控制會議的 節奏。保證每一個問題都得到討論。

8、會議后要總結，提煉結論。主持人在會后總結問題的討論結果，重申有關決議，明確責任人和完成時間。

9、會議要有紀要，如果將工作的結果、完成時間、責任人都記錄在案，則有利于檢查工作的完成情況。

10、做好會議的后勤保障，很多會議兼有聯絡感情的的作用，因此需要選擇一個合適的地點，提供餐飲、娛樂和禮品，制定 一個有張有弛的會議議程。對于有客戶和合作伙伴參加的會憶尤其如此。問題三：除了項目例會外，老張還可以采取的有效溝通措施：

1、首先應該對項目組成員進行溝通需求和溝通風格的分析。

2、對于不同溝通需求和溝通風格的成員設置不同的溝通方式。

3、除了項目例會之外，可以通過電話、電子郵件、項目管理軟件、OA 軟件進行溝通。

4、正式溝通的結果應該形成記錄，對于其中的決定應該有人負責落實。

5、可以引入一些標準的溝通模板。

6、在項目組內培養團結的氛圍。

3.人力資源管理在實施項目中的應用 王先生是負責某行業一個系統集成項目的項目經理，因人手比較緊張，王先生從正在從事編程工作的高手中選擇小張作為負 責軟件子項目的項目經理，小張同時兼任模塊的編程工作，這樣導致了軟件子項目的失控。

一、請分析軟件子項目失控的原因。

二、王先生應該怎樣做才能讓小張成為項目經理，并避免項目失控

三、概述典型的項目集成團隊的角色構成，敘述在組建項目團隊，建設項目團隊和管理項目團隊所需的活動。問題解答：

一、軟件子項目失控的原因:

1、小張缺乏足夠的項目管理經驗和能力

2、小張身兼二職，精力和時間不夠用，顧此失彼

3、小張沒有進入管理角色，只關注于編程工作，疏于對項目的管理

4、高級項目經理王先生對小張的工作缺乏事先培訓和跟蹤監督

二、王先生應該這樣做才能讓小張成為項目經理，并避免項目失控

1、事先要制定崗位的要求，職責和選人的標準，并選擇合適的人選 3/15

2、高級項目經理應對小張的工作進行全面的估算，如果小張的工作確實負荷過重，需要找人代替小張正在從事的技術工作，解決負載平衡問題

3、要事前溝通，對小張明確要求，明確角色的輕重緩急，促使小張盡快轉換角色

4、上級應該平時注意對人員的培養和監控

三、項目集成團隊的角色構成 一）針對選定的項目，根據項目的特點，需要的角色如下

1、管理類崗位：項目經理

2、工程類崗位：架構師、分析師、網絡工程師、軟件工程師、測試工程師、和實施人員

3、行業專家

4、支援類：文檔管理員、秘書 二）、組建項目團隊、建設項目團隊、管理項目團隊所需的活動

1、組建項目團隊，明確責任，制定責任分配矩陣，制定組織結構圖和職位描述

2、建設項目團隊 提高項目團隊的個人績效 提高項目團隊個人之間的信任感和凝聚力，已通過更好的合作提高工作效率

3、管理項目團隊 跟蹤個人和團隊的執行情況、提供反饋 協調變更，以提高項目的績效，保證項目的進度 項目管理團隊還必須注意團隊的行為，管理沖突，解決問題評估團隊成員的績效 4.為什么甲方總是不驗收項目？ 假設某項目的主要工作已經基本完成,經核對項目的未完成項目任務清單后,終于可以提交客戶方代表老劉驗收了.在驗收過 程中老劉提出了一些小問題,項目經理張斌帶領團隊很快妥善的解決了這些問題,但是隨著時間的推移,客戶的問題似乎不斷.時間已超過了系統的試用期,但是客戶仍然提出一些小問題,而有些問題都是客戶方曾經提出過,并基本上已經解決了的問題.時間一天天的過去,張斌不知道什么時候項目才能驗收,才能得到最后一批款項.問題一：分析發生這件事情的可能原因。問題二：說明張斌應該怎么辦。問題三：說明應當吸取的經驗和教訓。

問題解答： 問題一：這件事情可能的原因如下： 4/15

1、合同缺乏以下內容：（1）項目目標中關于產品功能和交付物的清晰描述（2）項目驗收標準、驗收步驟和方法（或流程）（3）對客戶的售后服務承諾

2、項目實施過程控制中出現問題：（1）在項目實施過程中沒有及時傳遞績效報告給客戶，因此客戶對項目進展和質量狀況不了解（2）沒有讓客戶及時對階段交付成果簽字確認

3、由于沒有售后服務的承諾，客戶擔心沒有后續的保證。

4、合作氣氛不良，客戶存在某種程度的抵觸情緒，雙方缺乏信任感，客戶對項目質量信心不足，怕承擔責任，因此不愿簽 字。問題二：說明張斌應該采取補救措施，靠加強溝通來解決問題。

1、就項目驗收標準和客戶達成共識，確定哪些主要工作完成就可以驗收通過。

2、就驗收的步驟方法和客戶達成共識。

3、就項目已經完成的程度讓客戶確認，例如出具系統使用報告，讓客戶簽字確認。

4、向客戶提出明確的服務承諾。使客戶沒有后顧之憂。問題三：應當吸取的經驗和教訓。

1、項目合同中要規定項目成果的正式驗收標準，驗收步驟，驗收流程，和運營維護承諾等內容。

2、加強項目執行過程中的控制。加強變更控制。包括制定變更控制流程，按流程進行變更的進行變更的評估，審核、實施、記錄、確認等工作。加強項目溝通管理。包括及時向客戶提供績效報告，讓客戶了解項目進展，設置對階段性成果的驗收，并讓客戶對階段性交 付成果進行簽字確認，項目文檔要齊全，使項目進展有據可查。加強計劃執行的控制。制定詳盡的項目管理計劃（包括進度管理計劃，成本管理計劃的分項管理計劃），按計劃實施和檢查。

3、項目經理還應注重和客戶交往的技巧，努力促成雙方的良好合作氛圍。

5.如何完成獻禮項目 J 公司 2008 年 3 月中標某市公安局的人口管理系統開發項目，因該是要在 2008 年 11 月舉辦某大型國際會議，因此公安局 要求人口管理系統一定要在 2008 年 7 月 1 日前投入使用。強某是負責這個項目的項目經理，雖然他進公司不到三年，但他 已成功管理過 2 個類似的項目，被大家稱之為救火隊長，而強某也對自己信心十足，但這次和以往不同的是強某還同時管理 著另外兩個項目，而這個人口管理項目工期要求緊，他能調用的人手少。該人口管理項目屬于升級項目，原來的系統是

J 公司開發，是 C/S 結構，智能管理本地城區常住人口，新的人口管理系統是 B/S 結構，要既能管理城區人口又能管理郊區常住人口，市轄縣常住人口和流動人口，而公安局要求該新系統首先把流動人 5/15 口管理起來，該項目從技術角度可以分為網絡改造和軟件開發，而軟件又分為界面，業務流程和數據庫三個子系統，他們團 隊共有 6 人，其中有人做過類似的 C/S 結構的項目，而公司剛剛結束的網絡項目與本次承擔的網絡改造項目在技術上架構方 面幾近相同，只是規模不同，公安局要求新系統能夠支持移動接入，而項目團隊中沒有一人接觸過移動技術，強某憑直覺知 道以現有的人員在 2008 年 7 月 1 日前完成項目是不可能的。問題

一、請說明強某可以用什么方法和技術來估算項目的工期。問題

二、請說明強某可以采取哪些方法來壓縮工期，以使項目在 2008 年 7 月 1 日前完成。問題

三、請說明強某可以采用哪些方法來跟蹤項目的進度，以確保項目按時交付。問題解答： 問題

一、強某可以估算項目的工期的方法：

1、明確定義項目的工作分解結構（WBS）

2、由于是升級項目，所以部分工作的工期估算可以采用類比估算法

3、由于新增移動接入模塊，可以聯系業界專家，采用德爾菲法進行估算

4、對于 WBS 進行足夠細化后，可依據歷史數據采用參數估算或三點估算進行進一步歷時估算。問題

二、使項目在 2008 年 7 月 1 日前完成，強某可以采取的方法：

1、與客戶進行溝通，梳理業務需求中的關鍵需求，與客戶進行協商能否在期限前先完成關鍵需求，其他部分分期交付，2、制定出合理可靠的技術方案，對其中不熟悉的部分，采取外包的方式

3、清晰定義各功能模塊之間的接口，然后進行并行工作

4、明確目標，責任和獎懲機制，提高員工的工作績效

5、必要時，進行趕工 問題

三、強某跟蹤項目的進度的方法：

1、基于 WBS 和公式估算制定活動網絡圖，制定項目工作計劃

2、建立對項目的監督和測量機制

3、確定項目的里程碑，并建立有效地評審機制

4、對項目中發現的問題，及時采取糾正和預防措施，并進行有效地變更管理

5、使用有效的項目管理工具，提升項目管

理的工作效率

6.如何保證項目按期完工 某系統集成公司現有員工 50 多人，業務部門分為銷售部，軟件開發部系統網絡部等，經過近半年的醞釀后，在今年一月份，公司的銷售部直接與銀行簽訂了一個銀行前置機的軟件系統項目，合同中規定，6 月 28 日前系統必須投入試運行，在合同 簽訂后銷售部將此合同移交給了軟件部，進行項目的實施。6/15

項目經理小丁經歷了五年的系統分析和設計工作，但這是他第一次擔任項目經理，小丁兼任系統分析工作，此項目還有兩名 1 年工作經驗的程序員，1 名測試人員，2 名負責組網和布線的系統工程師，項目組的成員均參加項目工作。在承擔項目之后，小丁組織大家制訂了項目的 WBS，并依照以往的經歷制訂了本項目的計劃，簡單描述如下：

1、應用系統子系統（1）1 月 5 日-2 月 5 日，需求分析（2）2 月 6 日-3 月 26 日，系統設計和軟件設計（3）3 月 27 日-5 月 10 日編碼（4）5 月 11 日—5 月 30 日，系統內部測試

2、綜合布線 2 月 20 日—4 月 20 日，完成調研和布線 3，網絡子系統 4 月 21 日-5 月 21 日，設備安裝聯調 4，系統內部調試驗收（1）6 月 1 日—6 月 20 日，試運行（2）6 月 28 日，系統驗收 春節后，在 2 月 17 日，小丁發現系統設計剛剛開始，由此推測 3 月 26 日根本完不成系統設計 問題

一、分析問題的可能原因 問題

二、建議小丁應該如何做，以保證項目整體進度不拖延 問題

三、典型的信息系統集成項目的進度、時間管理的過程和方法以及資源配置對進度的制約。問題解答： 問題

一、問題的可能原因：

1、項目部沒有及時讓軟件部參與項目早期工作，需求分析耗時過長，2、項目經理經驗不足，進度估算不準確，3、項目資源分配不足，缺乏專門的系統分析和設計人員

4、工作安排沒有充分利用分配的項目資源，資源有閑置

5、在安排進度時，可能未考慮節假日的因素 問題

二、，保證項目整體進度不拖延，建議小丁應該：

1、向職能經理申請增加特定資源，特別是要增加系統分析設計人員

2、臨時加班、趕工，盡可能補救耽誤的時間，或提高資源的利用效率

3、將部分階段的工作改為并行進行 7/15

4、對后續工作的工期重新進行估算，并考慮節假日問題，修訂計劃盡量留有余地

5、加強溝通，爭取客戶能夠對項目范圍，以及需求、設計、驗收標準、進行確認，避免后續頻繁出現變更。

6、加強對階段工作的檢查和控制，避免后期出現返工 此外，如有可能還可以采取外包和采取縮減范圍等方法，不建議在本案中用。問題

三、典型的信息系統集成項目的進度、時間管理的過程和方法：

1、活動定義，2、活動排序

3、活動資源估算

4、活動歷時估算

5、制定進度計劃

6、進度控制 資源配置對進度的制約： 在一般情況下，項目活動的歷時與項目的規模成正比，與投入的資源數量成反比，即投入的資源數量越多，活動歷時越短，但是要注意，任何活動都有其壓縮點，當活動的歷時已達到自身的壓縮點后，增加再多的資源也無法壓縮活動歷時。在一個非關鍵活動的一個較大時間延誤也許只對項目產生較小的影響或不產生影響，而在關鍵活動的較小延誤也許就需要馬 上采取糾正措施，因此每當縮短項目工期時，應當首先考慮關鍵活動上增加資源，以加快進度，縮短項目工期。7.副總裁的項目就能優先嗎？ 某電子政務項目涉及到保密信息，項目建設的資源尤其是人力資源，必須從甲方內部獲得，如果把項目的部分任務交給分包 商，一方面要征得甲方同意，一方面，要求分包商具有相應的保密資質，而保密資質的審核需要很長的時間，這將嚴重危及 到項目的交付日期，當項目團隊內的工程師完成 90%的編程和測試任務時，項目承建單位的一位副總裁承攬了一個新的項 目，他把程序員，測試工程師，從該項目上調走去從事新的項目。問題

一、請簡要說明發生上述情況的可能原因。問題

二、簡要敘述如果項目經理希望繼續推進該項目，應如何進行？ 問題

三、請簡要敘述如何處理多個項目之間的資源沖突。問題解答： 問題

一、發生上述情況的原因：

1、可能是單位沒有對項目進行統一管理，誰的權大誰的項目就獲得優先支持。

2、副總裁承攬了新的更重要的項目。

3、項目經理忽略了單位內部可能的競爭性項目的出現所帶來的風險。8/15

4、可能是本項目的績效不好，已失去了單位有關方面的支持。

5、可能是重要干系人如客戶、公司高層管理者內定項目暫?；蛘呦埋R。問題

二、項目經理希望繼續推進該項目，應當：

1、如果經評估后，認為項目尚可，就應寫出反應該項目現狀與前景預測的報告，向主管領導匯報，說服和溝通，陳述該項 目的重要性和預期利潤，如果項目下馬會造成的損失等，已得到及時和滿足要求的資源支持。

2、因本項目要保密，所以要用本單位可靠和能干的人員，如果單位人手不夠，盡量讓本單位其他非涉密項目去社會招聘或 者外包。

3、如果只剩下不到 10%的工作，應說服原來的團隊成員加班趕工完成項目。問題

三、處理多個項目之間的資源沖突：

1、建議單位統一管理所有的項目和資源，制定資源在項目之間的分配，2、定期檢查項目的執行情況，根據項目進展情況和企業整體績效重新安排項目的優先順序，從資源上支持重要的和進展良 好的項目。

3、外包

4、必要時，增加資源

5、建立項目管理體系，設立項目管理辦公室，統一管理單位所有的項目。

8.如何讓甲方對項目質量放心和滿意 某信息技術有限公司中標了某大型餐飲連鎖企業集團的信息系統項目，該項目包含單點管理，物流系統，和集團 ERP 等若 干子項目，由該信息技術有限公司的高級項目經理張先生全面負責項目的實施，張先生認為此項目質量管理的關鍵在于系統 的進行測試。張工制訂了詳細的測試計劃用來管理項目的質量，在項目實施過程當中，他通過定期發給客戶測試報告來證明質量是有保證 的，可是客戶總覺得有什么不對勁，對項目的質量還是沒有信心。問題

一、客戶對項目沒有信心的原因可能是什么？ 問題二、一般地，項目的質量管理計劃包括哪些內容？ 問題

三、張工應該如何實施項目的質量保證，項目的質量控制與質量保證有哪些區別與聯系？ 問題解答： 問題

一、客戶對項目沒有信心的原因可能是：

1、張工沒有為項目制定一個可行的項目質量管理計劃并積極地實施

2、僅向用戶提交測試報告而沒有提交全面質量管理進展情況報告（或實施報告），溝通方式單一（或不全面），容易誤導客 戶，容易導致客戶不必要的擔心。9/15 問題二、一般地，項目的管理計劃包括的內容：

1、質量責任與人員分工（或職責）

2、組織結構

3、程序與過程（或項目的各個過程及其依據的標準）

4、質量控制地方法、工具、與重點（或質量評審、質量保證方法）

5、質量管理所需的資源

6、驗收標準 問題

三、張工應該如何實施項目的質量保證，1、張工應該首先執行項目的質量管理計劃

2、采用質量保證的工具和技術（如編制質量計劃時所采用的工具和技術、質量審計、質量控制、過程分析與基準分析）等

3、提出相應的質量整改措施，如建議的糾正措施，對項目計劃的可能的更新，對組織資產可能的更新，變更請求。項目的質量控制與質量保證的區別與聯系

1、質量計劃是質量控制和質量保證的共同依據。

2、達到質量要求是質量控制和質量保證的共同目的。

3、質量保證的輸出是下一階段質量控制的輸入

4、一定時間內質量控制的結果也是質量保證的質量審計對象，質量保證的成果又可以指導下一階段的質量工作，包括質量 控制和質量改進。

5、質量保證一般是每隔一定時間如階段末進行的，主要通過系統的質量審計來保證項目的質量（或質量保證是按質量管理 計劃正確的去做）

6、質量控制是實時監控項目的具體結果，以判斷他們是否符合項目的相關標準，制定有效方案，以消除產生質量問題的原 因（或質量控制檢查是否做的正確并進行糾正）

9.如何定量的管理項目的進度 一個預算 100 萬的項目，為期 12 周，現在工作進行到第八周，已知成本預算是 64 萬，實際支出是 68 萬，掙值為 54 萬。問題

一、請計算成本偏差 CV，進度偏差 SV，成本績效指數 CPI,進度績效指數 SPI.問題

二、根據給定數據畫出該項目的預算成本，實際成本和掙值圖 問題

三、對以下四張表，分別分析其所代表的效率，進度和成本情況，針對每副表所反映的問題，可采

取哪些措施？ 問題解答： 問題

一、計算成本偏差 CV，進度偏差 SV，成本績效指數 CPI,進度績效指數 SPI.CV=EV-AC=54-68=-14 萬元 10/15 SV=EV-PV=54-64=-10 萬元 CPI=EV/AC=54/68=0.794 SPI=EV/PV=54/64=0.843 問題

二、根據給定數據畫出該項目的預算成本，實際成本和掙值圖 問題

三、對以下四表，分別分析其所代表的效率，進度和成本情況，針對每副表所反映的問題，可采取哪些措施？三參數關系 分析 措施 圖 1 AC>PV>EV 效率低 進度拖延 投入超前 提高效率，例如，用工作效率高的人員換一批工作效率低的人員，趕工，工作并行以追趕進度，加強成本監控 圖 2 PV>AC>=EV 進度效率較低 進度拖延 成本支出與預算相差不大 增加高效人員投入，趕工，工作并行以追趕進度 圖 3 AC>=EV>PV 成本效率較低 進度超前 成本支出與預算相差不大 提高效率，減少人員成本，加強人員培訓和質量控制 圖 4 EV>PV>AC 效率高 進度提前 投入延后 密切監控，加強質量控制

11.與領導工作風格不一樣怎么辦？ 錢某新接手一個信息系統集成項目的管理工作，根據用戶的業務要求，該項目要采用一種新的技術架構，項目團隊沒有應用 這種架構的經驗，錢某的管理風格是 Y 型的，在該項目啟動之初，為了調動大家的積極性，宣布了多項激勵措施，如按期 用該技術架構搭建出系統原型有獎，并分別公布了具體的獎勵金額，在項目實施期間，為了激勵士氣，經常請大家聚餐，由 于單位領導屬于 X 型的管理風格，很多餐票都不予報銷，而在項目實施現場，因施工人員技術不過關，導致一臺電源燒毀，錢某也悄悄在項目中給與報銷，負責新技術架構的架構師經歷多次失敗后，總算憑自己的經驗和探索搭建出了系統原型。最 后，雖然項目的實際進度、成本和質量等目標大體達到了要求，錢某自我感覺尚可，項目好歹也通過了驗收，但他當初關于 獎勵的承諾并沒有兌現，有人甚至認為他和領導一唱一和，錢某有苦難言。問題

一、請概括出錢某在人力資源管里方面的問題。問題

二、錢某應該用那些措施進行團隊建設，如何應用自己的 Y 型風格有效地管理項目？ 問題

三、請敘述錢某的單位和錢某應該如何處理新技術開發和項目管理之間的關系。11/15 問題解答： 問題

一、錢某在人力資源管里方面的問題：

1、獎勵政策沒有得到領導的同意（或支持、溝通）

2、Y 型管理風格沒有與切實可行的規章制度（或措施、機制）相結合

3、錢某的管理風格沒有與直接領導的管理風格相協調

4、沒有對員工進行培訓

5、沒有配備有經驗的人員（或人力資源獲取方式單一）問題

二、錢某應該用那些措施進行團隊建設

1、一般管理技能（如溝通、交流）

2、培訓

3、團隊建設活動（如周例會、共同解決問題、拓展訓練）

4、共同的行為準則（或基本原則、規章制度）

5、盡量集中辦公（或同地辦公、封閉開發）

6、認可獎勵（或恰當的獎勵與表彰措施）如何應用自己的 Y 型風格有效地管理項目

1、Y 性的管理風格，要與切實可行的規章制度相結合，與領導風格相一致，或相適應

2、加強對團隊成員的培訓，或教育

3、加強激勵與約束并重 問題

三、請敘述錢某的單位和錢某應該如何處理新技術開發和項目管理之間的關系。

1、培訓

2、自制/外購分析

3、招聘掌握該技術的人員

4、風險分析與防范 12.中途接手的項目如何完成 某系統集成商 B 負責大學城 A 的 3 個校園網的建設，是某弱電總包商的分包商，田某是系統集成商 B 的高級項目經理，對 三個校園網的建設總負責。關某、夏某和宋某是系統集成商 B 的項目經理，各負責其中一個校園網的建設，項目建設方聘 請了監理公司對項目進行監理。系統集成商 B 承攬的大學城 A 的校園網的建設項目，計劃從 2002 年 5 月 8 日啟動，至 2004 年 8 月 1 日完工，期間因項目 建設方的資金問題，整個大學城的項目延后 5 個月，其校園網的開工日期也順延到 2005 年 1 月 1 日，期間田某因故離職，12/15

其工作由系統集成商 B 的另一位高級項目經理包某接替，包某第一次拜訪客戶時，客戶對項目狀況非常不滿，和包某一起 拜訪客戶的有系統集成商 B 的主管副總、銷售部總監、銷售經理和關某，夏某和宋某個項目經理，客戶的意見如下：

1、你們負責的校園網進度一再滯后，你們不停的保證又不停的延誤，2、你們在實施自己的項目過程中，不能與其他承包商配合，影響了他們的進度

3、你們在項目現場，不遵守現場的管理規定，造成現場的混亂

4、你們的技術人員技術太差，對我方的詢問，總不能及時答復

5、……….聽到客戶的意見，包某很生氣，而關某、夏某和宋某也向包某反映項目現場的確混亂，他們已完成的工作經常被其他承包商 攪亂，但責任不在他們，至于客戶的其他指控，關某夏某和宋某則顯得無辜，他們管理的項目不至于那么糟糕，他們的項目 進展和成績客戶一概不知，而問題卻被擴大和扭曲。問題

一、發生上述情況的原因有哪些？ 問題

二、承建方應如何與監理協同？ 問題

三、如何制定有多個承包商參與的項目溝通管理計劃？ 問題解答： 問題

一、發生上述情況的原因：

1、自己內部管理有問題，至少監管缺位或不得利

2、集成商 B 沒有或很少與客戶直接溝通

3、沒有建立現場管理制度，或者現場管理制度不嚴密或不明確，現場管理制度執行不力

4、總承包商和分包商責任不是十分清楚

5、客戶從總承包商和分包商獲得的信息失真，總承包商報告渲染了問題，推卸責任

6、客戶自己本身的原因，如資金、管理水平

7、可能本項目的監理工作沒有到位 問題

二、承建方與監理協同應該：

1、承建方應該認識到位，承建方和監理方不是對立關系，他們有共同的目標：把項目搞好

2、雙方都采用項目的管理方法承建方配合監理方對項目的四控三管一協調。

3、中間成果的評審

4、周期性的溝通

5、突發事件的協調 問題

三、多個承包商參與的項目溝通管理計劃的制定：

1、做好干系人分析，調研各集成商的溝通需求 13/15

2、發揮總承包商的牽頭作用和監理方的協調作用

3、對共用資源的可用性分析，引入資源日歷

4、解決沖突，包括項目干系人對項目期望之間的沖突，資源沖突等。

5、建立健全項目管理制度，并監管其執行

6、采用項目管理信息系統 13.如何簽訂和履行合同 小李是國內某知名 IT 公司的項目經理，負責西南某省的一個企業信息系統項目建設的管理。在該項目合同中，簡單列出了項目承建方應該完成的工作，據此小李自己制定了項目的范圍說明書，甲方的有關工作由其信 息中心組織和領導，信息中心主任兼任該項目的甲方經理。可是在項目實施過程中，有時是甲方的財務部直接向小李提出變 更需求，有時是甲方的銷售部直接向小李提出變更需求，而且又是這些需求又是矛盾的，面對這些變更需求，小李試圖用范 圍說明書來說服甲方，甲方卻動輒用合同的響應條款作為依據，而這些條款要么太粗，不夠明確，要么小李與他們理解不同，因此小李對這些變更需求不能簡單的接受或拒絕而左右為難，他感到很沮喪，如果不改變這種狀況，項目看來是遙遙無期。問題

一、針對上述情況，請分析問題產生的原因 問題

二、如果你是小李，你怎樣在合同談判、計劃和執行階段分別進行范圍管理 問題

三、說明合同的作用，詳細范圍說明書的作用，以及兩者之間的關系 問題解答： 問題

一、問題產生的原因：

1、合同沒有制定好，沒有對具體完成的工作行程明確清晰的條款

2、甲方沒有對各部門的需求及其變更進行統一的組織和管理

3、缺乏變更/拒絕的準則

4、由于乙方對項目的干系人及其關系分析不到位，缺乏足夠的信息來源，范圍定義不全面，不準確

5、甲乙雙方對項目認可和承諾

6、缺乏項目全生命周期的范圍控制

7、缺乏客戶/用戶參與 問題

二、在合同談判、計劃和執行階段應該： 合同談判階段

1、確定明確的工作說明書或更細化的合同條款

2、在合同中明確雙方的權利和義務，尤其是關于變更問題

3、采取措施，確保合同簽約雙方對合同的條款理解是一致的 14/15 計劃階段

1、編制項目范圍說明書

2、創建工作的分解結構

3、制定項目的范圍管理計劃 執行階段

1、在項目執行過程中加強對易分解的各項任務的跟蹤和記錄

2、建立與項目干系人進行溝通的統一渠道

3、建立整體變更控制的規程并執行

4、加強對項目階段性成果的審核確認 項目全生命周期變更管理

1、在項目管理體系中應該統一有一套嚴格、適用、高效、的變更程序

2、規定對用戶的范圍申請變更請求、應正式提出變更申請，并經雙方項目經理審核后，作出相應的處理 問題

三、合同的作用，詳細范圍說明書的作用，以及兩者之間的關系 合同法規定，合同是平等主體的自然人、法人、其他組織之間設立、變更、終止民事權利義務關系的協議。合同是買賣雙方 共同遵守的協議。賣方有義務提供和保證規定的產品和服務。而買方有義務支付合同規定地價款。項目范圍說明書詳細描述了項目的可交付物，和產生這些可交付物必須做的項目工作。項目范圍說明書在所有項目干系人之 間建立了一個對項目范圍的共識，描述了項目的主要目標能使團隊能進行更詳細的規劃，指導團隊在項目實施階段的工作，并為評估是否為客戶需求進行變更或附加工作是否在范圍之內提供基線。合同是制定范圍說明書的依據。15/15

第五篇：系統集成項目管理工程師下午考試答題技巧精選-案例分析

案例分析

根據考試大綱的規定，系統集成項目管理工程師考試案例分析（下午考試），即系統集成項目管理應用技術部分，試題范圍相對比較窄，局限在項目管理的范疇之內，具體的考查內容包括可行性研究、項目立項、合同管理、項目啟動、項目管理計劃、項目實施、項目監督與控制、項目收尾、信息系統的運營、信息（文檔）與配置管理、信息系統安全管理。1 試題解答方法

根據軟考命題的習慣，一般中級的考試下午案例分析會有5道大題，全部以問答題的形式出現，有時也會出現有選做題，滿分為75分。

下午試題I對于考生的基本要求將體現在：

（1）需要具有一定的信息系統項目管理實踐經驗，有較好的分析問題和解決問題的能力。

（2）對于有關項目管理方面，有廣博而堅實的知識或見解。

（3）對應用的背景、事實和因果關系等有較強的理解能力和歸納能力。

（4）對于一些可以簡單定量分析的問題已有類似經驗并能進行估算，對于只能定性分析的問題能用簡練的語言抓住要點加以表達。

（5）善于從一段書面敘述中提取出最必要的信息，有時還需要舍棄一些無用的敘述或似是而非的內容。

考生應當加強上述要求的訓練。

提示：考生解答試題時可按以下途徑來分析和解決問題。

（1）標出試題中要回答的問題要點，以此作為主要線索進行分析和思考。

（2）對照問題要點仔細閱讀正文。閱讀時，或者可以列出只有幾個字的最簡要的提綱，或者可在正文上作出針對要回答問題的記號。

（3）通過定性分析或者定量估算，構思答案的要點。

（4）以最簡練的語言寫出答案。注意不要超過規定字數，語言要盡量精簡，不要使用修飾性的空洞詞匯，也不要寫與問題無關的語句，以免浪費時間。2 試題解答實例

下面來看一些例題與詳細的分析，讀者可仔細閱讀這些案例，并加以體會運用，以快速提升解決問題的能力。2.1 例題1：子項目管理

M是負責某行業一個大型信息系統集成項目的高級項目經理，因人手比較緊張，M從正在從事編程工作的高手中選擇了小張作為負責軟件子項目的項目經理，小張同時兼任模塊的編程工作，這種安排導致了軟件子項目失控。

【問題1】請用150字以內的文字，分析導致軟件子項目失控的可能原因。

【問題2】請用200字以內的文字，說明你認為M事先應該怎么做才能讓小張作為子項目的項目經理，并避免軟件子項目失控？

【問題3】請用400字以內的文字，概述典型的系統集成項目團隊的角色構成？敘述在組建項目團隊、建設項目團隊和管理項目團隊方面所需的活動，結合實例說明。例題1分析

IT行業技術日新月異，要求從業人員具有高素質和高水平。而且，從我國的實際狀況來看，IT工程師緊缺，人員流動十分頻繁，合格人選很難找到和保留在某個項目中。因此，有效的管理人力資源，是項目經理們認為最困難的一件事情。

【問題1】

問題1要求考生分析導致軟件子項目失控的可能原因。因為試題描述很簡單，所以只能根據小張是新手這個線索，靠考生的常識來解答這個問題。

（1）項目經理的選擇

企業人手比較緊張，于是M就選擇了“編程工作的高手”小張作為項目經理。這種“饑不擇食”的現象在國內的軟件企業中比較普遍。軟件項目經理甚至高級項目經理通常直接來自編程高手，中間未經過任何的培訓。我們知道，在信息系統工程中，開發和管理是兩條不同的主線，開發人員所需要的技能與管理人員所需要的技能很不一樣。

當然，如果一個既是開發高手又是管理能手的人擔任項目經理，那是再好不過的了。系統分析師就是這樣的復合型人才，但是，我國的系統分析師太少了，遠遠不能滿足軟件企業的需求。因此，還必須考慮從開發高手中選擇項目經理，但這種選擇，必須是培養后的選擇。開發人員要勝任項目經理崗位，不僅需要技術背景、行業知識，還需要具備一定的管理知識和經驗。普通技術人員，未經培訓和考查就直接任命為項目經理，在實際工作中，很可能會出現問題。

（2）身兼數職的問題

根據試題的描述，小張在擔任了軟件子項目的項目經理后，仍然同時兼任模塊的編程工作。這也是國內軟件企業存在的一個實際性問題。在實際的項目中，通常存在“能者多勞”現象，一個人擔任多個角色、承擔過重的工作，在分配角色之前沒有仔細計算人員的工作負荷問題。特別是在小企業中，這種情況更為嚴重。

在本題中，作為技術出身的小張，由于仍然要編程，可能沒有多少時間去學習管理知識，去從事管理工作。小張一人承擔2個角色的工作，導致工作負荷過載，身心疲憊，其后果可能給全局帶來不利影響。

另外，小張初為項目經理，可能會存在思維轉換和角色轉換問題。一般而言，技術人員看待問題往往比較片面和深入，注重細節問題，而管理人員往往會關注問題的全面和大的問題。因此，雖然角色發生了部分變化（之所以說是“部分變化”，是因為小張仍然兼任程序員的工作），但小張的思維方式、看待問題和處理問題的方式都暫時還沒有轉變過來。而且，由于身兼開發職務，還會延緩這種轉變。

（3）間接管理問題

高級項目經理M選擇了小張作為軟件子項目的項目經理，并且未經過任何管理方面的培訓。在項目開展過程中，可能由于自己比較忙，也缺乏對小張工作的引導和幫帶，缺乏全程的跟蹤和監控。這種間接管理導致高級項目經理M不能及時發現項目中的問題，從而造成項目失控。

【問題2】

問題2要求考生回答，先應該怎么做才能讓小張作為子項目的項目經理，并避免軟件子項目失控。

根據問題1的分析，我們知道，要委任小張作為子項目的項目經理，應該至少要做好以下事情：

（1）根據項目經理崗位的任職條件和職責，選擇合適的人員擔任子項目的項目經理。由于企業人才緊缺，找不到合適的人選，要委任程序員小張擔任項目經理，則需要對小張進行崗前培訓。

（2）重新考慮和衡量小張的工作量問題，確保項目經理的工作都能完成。

（3）在項目管理方面，由于小張是新手，所以，在當前情況下，應盡量讓小張放棄編程工作，專心從事管理工作，學習管理知識。

（4）在項目進行過程中，高級項目經理M應加強對小張的培養和監控，以便及時發現問題，避免項目失控。同時，要敦促小張轉換思維方式，即實現從技術人員思維方式到管理者思維方式的轉變。

【問題3】

問題3要求考生回答，典型的系統集成項目團隊的角色構成，以及在組建項目團隊、建設項目團隊和管理項目團隊方面所需的活動。例題1解答要點

【問題1】

（1）小張缺乏足夠的項目管理能力和經驗。

（2）小張身兼二職，精力和時間不夠用，顧此失彼。

（3）小張沒有進入管理角色，只關注于編程工作，疏于對項目的管理。

（4）高級項目經理對小張的工作缺乏事先培訓和全程的跟蹤與監控。

【問題2】

（1）事先要制訂崗位的要求、職責和選人的標準，并選擇合適的人選。

（2）高級項目經理應對小張的工作進行全面估算，如果小張的負荷確實過重，需要找人代替小張當時正在從事的技術工作，解決負載平衡問題。

（3）要事前溝通、對小張明確要求、明確角色的輕重緩急，促使小張盡快轉換角色。

（4）上級應該注意平時對人員的培養和監控。

【問題3】

1．針對選定的項目，根據項目的特點，需要的角色：管理類（如，項目經理）；工程類（如，系統分析師、架構設計師、軟件設計師、程序員、測試工程師、美工、網絡工程師、主機人員、實施人員）；行業專家；輔助類（如，文檔管理員、秘書）。

2．結合實際項目，敘述進行如下活動的經驗：

（1）組建項目團隊，明確責任（制訂責任分配矩陣）。

（2）建設項目團隊。提高項目團隊成員的個人績效；提高項目團隊成員之間的信任感和凝聚力，以通過更好的團隊合作提高工作效率。

（3）管理項目團隊。跟蹤個人和團隊的執行情況、提供反饋；協調變更，以提高項目的績效、保證項目的進度；項目管理團隊還必須注意團隊的行為、管理沖突、解決問題；評估團隊成員的績效。

2.2 例題2：項目變更管理

在一個正在實施的系統集成項目中出現了下述情況：一個系統的用戶向他所認識的一個項目開發人員抱怨系統軟件中的一項功能問題，并且表示希望能夠進行修改。于是，該開發人員就直接對系統軟件進行了修改，解決了該項功能問題。針對這樣一種情況，請分析如下問題：

【問題1】請用150字以內的文字，說明上述情況中存在著哪些問題？

【問題2】請用300字以內的文字，說明上述情況可能會導致什么樣的后果？

【問題3】請用300字以內的文字，說明配置管理中完整的變更處置流程。

例題2分析

本題比較簡單，主要考查變更控制的基本流程及實施方法，基本屬于純理論問題。

變更來源有兩個方面，一是用戶，他們是信息系統項目需求的提出者。要求用戶一次性地把需求講清楚，并且不允許此后做任何變更，這是不現實的，開發方只能盡力減少變更，降低其影響。開發人員如何解決好自己的工作產品與變更的用戶需求之間的一致性，是CMM2級需求管理這個關鍵過程域的主要目標。

變更來源的另一個方面來自開發人員自身。他們在工作中可能發現前期工作中有些不妥當的地方，便要修改已經確定了的設計方案或是設計的細節。也許是項目管理人員提出要修訂已經確定了的項目方案。由此所導致的返工甚至部分工作產品的報廢也是在所難免的。

無論來自哪個方面的變更，都需要嚴格按照變更控制的流程進行，否則會給開發和后續維護帶來很多問題。

【問題1】

根據試題描述，這個開發人員在聽到用戶的口頭抱怨后，就直接對系統軟件進行了修改，解決用戶的問題。顯然，該開發人員沒有遵照變更控制的程序來解決問題。具體來說，存在以下問題：

（1）沒有對用戶口頭反映的問題進行文檔化，即沒有對用戶的要求進行記錄。任何變更申請都必須以書面的形式提出。

（2）沒有分析和評估用戶變更請求。事實上，開發人員在獲得用戶的變更請求后，應該提交給CCB，由CCB對變更請求進行分析和評估。在得到CCB的批準后，才能開始實施變更。

（3）在修改過程中沒有注意進行版本管理。開發人員直接對系統軟件進行修改，沒有進行任何配置管理工作，這也是不對的。這樣，會造成后續的維護工作出現差錯。

（4）修改完成后未進行驗證。開發人員直接修改了軟件，并“解決了該項功能問題”。但這種解決是局部性的，該功能的正常運行可能會引起其他功能的不正常，所以對軟件修改后，一定要進行驗證測試。

（5）修改的內容未和項目干系人進行溝通。由于變更請求是由“一個系統的用戶”提出的，這種請求不一定合理，不一定在項目范圍之內。一個配置項出現變更，可能會涉及到一些相關的部件和文檔進行變更，這將影響到項目開發工作中的許多人員，所以需要和項目干系人溝通。

【問題2】

問題2要求考生說明上述情況可能會導致什么樣的后果。變更管理簡單說就是控制修改，使之不出現改錯，改亂的現象。沒有按照變更控制流程來實施信息系統的變更，會出現很多問題。具體而言，我們針對問題1分析中的存在的5個問題，分別例舉其可能導致的問題：

（1）由于沒有記錄用戶的變更請求，可能會導致對系統軟件變更的歷史無法追溯，并會導致對工作產品的整體變化情況失去把握。

（2）由于沒有對變更進行分析和評估，可能會導致后期的變更工作出現工作缺失、與其他工作不一致等問題，對項目的進度、成本、質量方面也會產生一定影響。

（3）由于在修改過程中不注意版本管理，萬一變更失敗，則無法進行復原，造成成本損耗和進度拖延。而且，沒有版本管理，對于后續的開發和維護工作也會帶來困難，對于組織財富和經驗的積累也是不利的。

（4）由于修改完成后不進行驗證，難以確認變更是否正確實現，可能會影響系統其他功能的正常運行。同時，由于沒有進行驗證，為變更付出的工作量也無法得到承認。

（5）由于未與項目干系人進行溝通，可能會導致項目干系人的工作之間出現不一致之處，進而影響項目的整體質量。

【問題3】

變更管理的基本流程如下：

（1）變更申請。應記錄變更的提出人、日期、申請變更的內容等信息。

（2）變更評估。對變更的影響范圍、嚴重程度、經濟和技術可行性進行系統分析。

（3）變更決策。由具有相應權限的人員或機構決定是否實施變更。

（4）變更實施。由管理者指定的工作人員在受控狀態下實施變更。

（5）變更驗證。由配置管理人員或受到變更影響的人對變更結果進行評價，確定變更結果和預期是否相符、相關內容是否進行了更新、工作產物是否符合版本管理的要求。

（6）溝通存檔。將變更后的內容通知可能會受到影響的人員，并將變更記錄匯總歸檔。如提出的變更在決策時被否決，其初始記錄也應予以保存。例題2解答要點

【問題1】

存在的主要問題有：

（1）對用戶的要求未進行記錄；

（2）對變更請求未進行足夠的分析，也沒有獲得批準；

（3）在修改過程中沒有注意進行版本管理；

（4）修改完成后未進行驗證；

（5）修改的內容未和項目干系人進行溝通。

【問題2】

可能導致如下后果：

（1）缺乏對變更請求的記錄可能會導致對產品的變更歷史無法追溯，并會導致對工作產物的整體變化情況失去把握。

（2）缺乏對變更請求的分析可能會導致后期的變更工作出現工作缺失、與其他工作不一致等問題，對項目的進度、成本、質量方面也會產生一定影響。

（3）在修改過程中不注意版本管理，一方面可能會導致當變更失敗時無法進行復原，造成成本損耗和進度拖延；另一方面，對于組織財富和經驗的積累也是不利的。

（4）修改完成后不進行驗證則難以確認變更是否正確實現，為變更付出的工作量也無法得到承認。

（5）未與項目干系人進行溝通可能會導致項目干系人的工作之間出現不一致之處，進而影響項目的整體質量。

【問題3】

變更管理的基本流程如下：

（1）變更申請。應記錄變更的提出人、日期、申請變更的內容等信息。

（2）變更評估。對變更的影響范圍、嚴重程度、經濟和技術可行性進行系統分析。

（3）變更決策。由具有相應權限的人員或機構決定是否實施變更。

（4）變更實施。由管理者指定的工作人員在受控狀態下實施變更。

（5）變更驗證。由配置管理人員或受到變更影響的人對變更結果進行評價，確定變更結果和預期是否相符、相關內容是否進行了更新、工作產物是否符合版本管理的要求。

（6）溝通存檔。將變更后的內容通知可能會受到影響的人員，并將變更記錄匯總歸檔。如提出的變更在決策時被否決，其初始記錄也應予以保存。2.3 例題3：項目驗收

假設某項目的主要工作已經基本完成，經核對項目的“未完成任務清單”后，終于可以提交客戶方代表老劉驗收了。在驗收過程中，老劉提出了一些小問題。項目經理張斌帶領團隊很快妥善解決了這些問題。但是隨著時間的推移，客戶的問題似乎不斷。時間已經超過了系統試用期，但是客戶仍然提出一些小問題，而有些問題都是客戶方曾經提出過，并實際上已經解決了的問題。時間一天一天的過去，張斌不知道什么時候項目才能驗收，才能結項，才能得到最后一批款項。

【問題1】請用200字左右的文字，分析發生這件事情可能的原因？

【問題2】請用200字以內的文字，說明現在張斌應該怎么辦？

【問題3】請用200字以內的文字，說明應當吸取的經驗和教訓？ 例題3分析

本題綜合考查了合同管理、項目管理控制和項目溝通的實施方法。試題中描述的問題在現實生活中，也普遍存在，確實是令很多項目經理頭疼的事情。事實上，在項目開發過程中，如果甲乙雙方嚴格按照有關合同和規定進行項目活動的話，則這些問題都很好解決。但是，由于我們的文化背景和社會傳統的制約，人們往往以“情”的角度去考慮問題，而不是從“法”的角度去考慮，人情高于合同。

【問題1】

問題1要求考生分析發生這件事情可能的原因。

從試題描述來看，我們可以抓住幾個關鍵詞語：“主要工作已經基本完成”、“未完成任務清單”、“客戶的問題似乎不斷”，以及“有些問題都是客戶方曾經提出過，并實際上已經解決了的問題”。根據這些關鍵詞語，再進行分析和思考。

（1）從題中可知，在雙方簽合同時，很可能沒有規定驗收標準什么、什么時候驗收、驗收步驟和流程是什么，以及售后服務的范圍是什么等問題。這樣，就導致驗收時沒有依據。當然，也可能是合同里規定得很清楚，但如前所述，由于“人情高于合同”的緣故，雙方都沒有按合同來執行。

在項目開發合同中，應該要明確規定項目驗收標準（規定哪些工作必須完成、完成到什么程度、交付哪些產品（項目的交付物）等）和驗收流程（驗收時具體按何流程進行操作，包括何時提供驗收、驗收表格、驗收人員、驗收步驟、驗收有關問題的處理）。

（2）客戶方代表老劉問題似乎不斷，而且重復提出問題，這可能有三個方面的原因：

一是項目的變更管理可能做得不好，變更未以書面形式提出申請。這樣，原來提出并修改過的問題后來又忘記了，甚至出現一種惡性修改的情況，即某一天要求把“黑”改成“白”，沒過多久，又要求把“白”改成“黑”，拿開發方的時間和費用開玩笑。

二是雖然有好的變更控制流程，但老劉沒有在變更申請上簽字。在現實中，這種情況也是有的，例如筆者就曾經碰到過這樣的甲方“領導”。他對項目管理流程很清楚，也清楚變更是需要付出代價的，但就是始終不肯在變更申請上簽字。他這樣做的目的是，如果項目不出問題，事情就這樣過去了，反正我們會幫他們代簽字，執行我方的變更流程。如果項目出了問題，他的領導追究下來，他會很無辜地說“我不知道啊，怎么變成這樣子了！”。

三是老劉對項目質量如何心里沒底，在故意拖延時間。這樣，就能有更充裕的時間來進行測試和試用。而老劉心里沒底的原因，一是可能因為合同里沒有售后服務的承諾，老劉擔心簽字付款后，系統出問題就沒有人管；二是對于未完成問題，張斌沒有承諾完成時間；第三可能是張斌和老劉溝通不好，關系欠融洽，老劉對張斌沒有信心，所以不能放心簽字。

（3）從試題描述來看，除了上述2種可能外，還可能存在雙方的溝通問題。客戶代表老劉不斷提出相同的問題，這說明項目經理張斌對于老劉所需信息的傳遞不夠或者有誤，客戶獲得的信息不全或不及時。而且，如果老劉使用這種手段故意為難張斌，則更說明兩者的關系處理得太差。

【問題2】

問題2要求考生說明現在張斌應該怎么辦。

項目經理張斌的目的是促成客戶盡早驗收，針對問題1分析中給出的幾種原因，可采取相應的措施。

（1）如果合同中沒有規定驗收事宜或者規定得不清晰，則需要將驗收的事項規定清楚。通過簽訂補充合同跟客戶簽訂一個詳細的驗收計劃等方式，將驗收標準、流程規定清楚，雙方需要簽字確認。

（2）如果沒有完善的文檔，則需盡快完善文檔。將階段性驗收的結果、變更的結果、試運行的報告等作詳細記錄，逐一讓客戶簽字確認。

（3）如果合同中沒有售后服務的承諾，則需要對售后服務問題向客戶做出承諾，對于未完成的工作進行評估，需要完成的要承諾完成時間。

（4）進一步做好溝通工作。除了把項目文檔發送給有關項目干系人外，項目經理張斌需要跟客戶代表老劉多進行非正式的溝通，解除其中可能存在的疙瘩，讓老劉了解項目的進展，了解主要工作已經完成，并理解項目結項對張斌的重要性，達成理解和融洽的關系。

【問題3】

問題3要求考生說明應當吸取的經驗和教訓。這些問題的回答還是需要根據問題1分析中的可能原因來總結，存在什么樣的問題，就有什么樣的教訓，吸取了教訓，以后就有了經驗。根據試題的要求，下面，我們從合同管理、過程控制和項目溝通管理三個方面進行歸納和總結。

（1）合同管理方面。

·在合同或其附件中要詳細和清楚地規定有關的驗收事宜，包括驗收標準、驗收時間、驗收步驟和流程，以及售后服務的有關承諾。

·由于合同雙方現實環境和相關條件的變化，許多合同都有可能變更，而這些變更必須根據合同的相關條款適當處理。

（2）過程控制方面。

·在信息系統集成項目中，變更是很頻繁的，也是很正常的，關鍵的是要制訂和執行一個完善的變更控制流程。

·在項目活動過程中，文檔要齊全，使項目進展有據可查。

·加強項目配置管理，設置項目里程碑，進行階段性驗收，并要求客戶簽字確認。

（3）溝通方面。

·在項目計劃編制階段制訂一份詳盡的項目溝通計劃，并按其執行。

·定期出具績效報告，讓項目干系人了解項目的進展情況。如果發生變更，則要及時把信息提供給項目干系人。

·營造良好的客戶關系。項目經理要經常與客戶方進行非正式的溝通，需要營造良好的客戶關系，讓客戶成為自己真正的和長期的朋友。例題3解答要點

【問題1】

（1）合同中缺乏以下內容：

·項目目標中關于產品功能和交付物組成的清晰描述。

·項目驗收標準、驗收步驟和方法（或流程）。

·對客戶的售后服務承諾。

（2）項目實施過程控制中出現的問題：

·在項目實施過程中沒有及時將項目績效報告遞交給客戶，因此客戶對項目進展和質量狀況不了解。

·沒有讓客戶及時對階段成果簽字確認。

（3）由于沒有售貨服務的承諾，客戶擔心沒有后續報務保證。

（4）合作氛圍不良，客戶存在某種程度的抵觸情緒，雙方缺乏信任感，客戶對項目質量信心不足，怕承擔責任，因此不愿簽字。【問題2】

根據項目現狀，需要采取補救措施，加強溝通以解決問題。

（1）就項目驗收標準和客戶達成共識，確定哪些主要工作完成即可通過驗收。

（2）就項目驗收步驟和方法與客戶達成共識。

（3）就項目已經完成的程度讓用戶確認。例如出具系統試作報告，請客戶簽字確認。

（4）向客戶提出明確的服務承諾，使客戶沒有后顧之憂。【問題3】

（1）項目合同中要規定項目成果的正式驗收標準、驗收步驟、驗收流程和運營維護服務承諾等內容。

（2）加強項目執行過程中的控制。

·加強變更控制。包括制定變更控制流程，按流程進行變更的評估、審核、實施、記錄、確認等工作。

·加強項目溝通管理。包括及時向客戶提供項目績效報告，讓客戶了解項目進展；設置對階段性成果的驗收，并讓客戶對階段性成果進行簽字確認；項目文檔要齊全，使項目進展有據可查。

·加強計劃執行的控制。制訂詳盡的項目管理計劃（包括進度管理計劃、成本管理計劃等各分項計劃），按計劃實施和檢查。

（3）項目經理還應注重跟客戶相處的技巧，努力促成雙方的良好合作氛圍。2.4 例題4：項目管理體系

某公司是一家中小型系統集成公司，在2006年3月份正在準備對京發證券公司數據大集中項目進行投標，某公司副總裁張某授權銷售部的林某為本次投標的負責人，來組織和管理整個投標過程。

林某接到任務后，召集了由公司商務部、銷售部、客服部和質管部等相關部門參加的啟動說明會，并把各自的分工和進度計劃進行了部署。

隨后，在投標前3天進行投標文件評審時，發現技術方案中所配置的設備在以前的項目使用中是存在問題的，必須更換，隨后修改了技術方案。最后某公司中標并和客戶簽訂了合同。根據公司的項目管理流程，林某把項目移交到了實施部門，由他們具體負責項目的執行與驗收。

實施部門接手項目后，鮑某被任命為實施項目經理，負責項目的實施和驗收工作。鮑某發現由于項目前期自己沒有介入，許多項目前期的事情都不是很清楚，而導致后續跟進速度較慢，影響項目的進度。同時鮑某還發現設計方案中尚存在一些問題，主要有：方案遺漏一項基本需求，有多項無效需求，沒有書面的需求調研報告；在項目的工期、系統功能和售后服務等方面，存在過度承諾現象。于是項目組重新調研用戶需求，編制設計方案，這就增加了實施難度和成本?？墒呛髞碛职l現采購部仍是按照最初的方案采購設備，導致設備中的模塊配置功能不符合要求的情況。

而在希賽集成公司中，類似現象已多次發生。

【問題1】針對說明中所描述的現象，分析某公司在項目管理方面存在的問題（200字以內）。

【問題2】針對某公司在該項目管理方面存在的問題，提出補救措施（300字以內）。

【問題3】針對某公司的項目管理現狀，結合你的實際經驗，就某公司項目管理工作的持續改進提出意見和建議（300字以內）。例題4分析

本案例是一道綜合題，主要考查考生對項目組織結構、項目管理流程等方面存在的問題進行分析的能力，并針對問題提出相應改進的建議。

在回答問題之前，應仔細審題，以明了題目要求。

【問題1】要求分析某公司在項目管理方面存在的問題，這可以通過閱讀試題的說明而得到。如依次讀試題一的第1段、第2段和第3段內容，可知某公司整體上是職能型組織，分售前（投標）和售后（實施）。銷售部的林某作為投標的負責人沒有邀請后續的實施部門參與投標活動，僅僅在中標后作了簡單移交，在這一環節就容易出問題。另外以前的技術方案中出現的問題設備在本次投標文件中重復出現，說明某公司在項目管理的經驗教訓的傳承和傳播上是不重視的，缺乏組織方面和方法方面的有效保證。接著讀案例的第4段、第5段乃至全篇，就會不禁發問：一個有過度承諾的方案，是怎樣提交出去的呢？某公司有相應的評審和批準程序嗎？如果有，是否適當？如果適當，執行得如何?既然項目組重新編制了設計方案，這就意味著發生了重要變更，而采購部門的采購方案為什么沒有做相應變更呢？另外，類似錯誤在某公司屢有發生，也要分析：某公司對過去發生的類似經驗教訓是否有文檔記載？

如果有，那么，某公司關于對該類文檔的了解和使用的規定是怎樣的？執行得又如何？

在【問題1】找出問題之后，自然地在【問題2】中就可以有針對性地提出補救措施了。

由于企業的不同、所從事的行業的不同、項目規模和復雜程度的不同，要回答【問題3】，應主要針對某公司的項目管理現狀，再結合考生自己的實際經驗，就可以對某公司項目管理工作的持續改進全面地、系統地提出意見和建議。例題4解答要點

【問題1】

（1）投標前的項目內部啟動會上，沒有邀請技術或實施部門。

（2）沒有把以往的經驗教訓收集、歸納和積累。

（3）沒有建立完善的內部評審機制，或雖有評審機制但未有效執行。

（4）項目中沒有實行有效的變更管理。

（5）公司級的項目管理體系不健全，或執行得不好。

【問題2】

（1）改進項目的組織形式，明確項目團隊和職能部門之間的協作關系和工作程序。

（2）做好項目當前的經驗教訓收集、歸納工作。

（3）明確項目工作的交付物，建立和實施項目的質量評審機制。

（4）建立項目的變更管理機制，識別變更中的利益相關方并加強溝通。（5）加強對項目團隊成員和相關人員的項目管理培訓。

【問題3】

（1）建立企業級的項目管理體系和工作規范。

（2）加強對項目工作記錄的管理。

（3）加強項目質量管理和相應的評審制度。

（4）加強項目經驗教訓的收集、歸納、積累和分享工作。

（5）引入合適的項目管理工具平臺，提升項目管理工作效率。2.5 例題5：人力資源管理

某公司是一家系統集成商，章某是某公司的一名高級項目經理，現正在負責某市開發區的辦公網絡項目的管理工作，該項目劃分為綜合布線、網絡工程和軟件開發三個子項目，需要3個項目經理分別負責。章某很快找到了負責綜合布線、網絡工程的項目經理，而負責軟件開發的項目經理一直沒有合適的人選。原來由于某公司近年業務快速發展，承攬的項目逐年增多，現有的項目經理人手不夠。章某建議從在公司工作2年以上業務骨干中選拔項目經理。結果李某被章某選中負責該項目的軟件開發子項目。在項目初期，依照公司的管理規定，李某帶領幾名項目團隊成員刻苦工作，項目進展順利。

隨著項目的進一步展開，項目成員的逐步增加，李某在項目團隊管理方面遇到很多困難。他領導的團隊因經常返工而效率低下、團隊成員對發生的錯誤互相推諉、開會時人員從來沒有到齊過，甚至李某因忙于自己負責的模塊開會時都遲到過。大家向李某匯報項目的實際進度、成本時往往言過其實，直到李某對自己負責的模塊進行接口調試時才發現這些問題。

【問題1】請分析項目中出現這些情況的可能原因（200字以內）。

【問題2】你認為高級項目經理章某應該如何指導和幫助李某（300字以內）。

【問題3】請說明李某作為項目經理要承擔哪些角色？要成為一名合格的項目經理要具備哪些知識與技能？（300字以內）例題5分析

第一步：仔細閱讀題目要求，分析題目要點

本案例聚焦于人力資源管理，主要考查高級資格的考生如何選拔、培養項目經理，建設項目的管理團隊，對下屬授權并進行傳幫帶，從而使管理團隊成為自己管理能力的放大器，最終提升高級管理者自己的管理水平與領導水平。

在回答問題之前，應仔細審題，以明了題目要求。

先通讀試題的說明，可知【問題1】出現的問題。試題一的說明 中已說明“某公司近年業務快速發展，承攬的項目逐年增多，現有的項目經理人手不夠”，接著，“章某建議從在公司工作2年以上業務骨干中選拔項目經理。結果李某被章某選中”。“李某帶領幾名項目團隊成員刻苦工作，項目進展順利”，試題的說明的第2段則指出“隨著項目的進一步展開，項目成員的逐步增加，李某在項目團隊管理方面遇到很多困難”，說明李某在項目的早期，團隊只有幾個人時還是管得過來的。只是項目后期任務緊、人員增多時，李某的管理能力出了問題。這說明李某缺乏擔任項目經理所需的足夠的能力和經驗，不能說章某作為高級項目經理選人選錯，但他缺乏對李某傳、幫、帶。也有可能是D公司對項目經理的培養不重視、對項目經理的選拔任命不規范。

結合考生自己的實際經驗，在【問題2】中就可以提出對項目經理小李的傳幫帶措施了，如章某應明確李某的工作職責，幫助其實現向項目經理角色的轉變、參加小李組織的周例會等。

雖然項目實施的企業有所不同、所從事的行業有所不同、項目規模和復雜程度有所不同，但對項目經理的要求卻是高度一致的，如管理者和項目領導者的角色、同時具備管理能力和一定的專業技能。這些分析應構成【問題3】的基本內容。例題5解答要點

【問題1】

（1）李某缺乏擔任項目經理所需的足夠的能力和經驗。

（2）公司對項目經理的培養不重視、對項目經理的選拔任命不規范。

（3）章某對李某的傳、幫、帶做得不夠、或不到位。

（4）公司對項目經理的工作缺乏指導和監督。

（5）項目工作中的溝通沒有建立有效的機制和方式方法。

（6）缺乏有效的項目績效管理機制。

【問題2】

（1）章某應明確李某的工作職責，幫助其實現向項目經理角色的轉變。

（2）參加小李組織的周例會，以及時發現問題，并予以指導。

（3）對李某提供相關工作的指導或培訓，尤其是在項目管理方面。

（4）從整體項目層面對各子項目進行計劃和協調，對子項目提出具體的工作要求。

（5）加強對子項目的日常監管，要項目經理以身作則。

（6）針對子項目中出現的問題，及時提出糾正和預防措施。

【問題3】

（1）作為一名項目經理，要同時承擔項目管理者和項目領導者的角色，這些角色的工作包括了項目的計劃、組織、協調、領導和控制。

（2）項目經理應同時具備管理能力和一定的專業技能，包括：項目管理知識、IT知識、客戶行業知識，豐富的經歷與經驗，良好的協調能力，良好的職業道德，良好的溝通與表達能力，良好的領導能力。2.6 例題6：項目進度管理

某公司2008年3月中標某市公安局的人口管理系統開發項目，因該市要在2008年11月舉辦某大型國際會議，因此公安局要求人口管理系統一定要在2008年7月1日之前投入使用。強某是負責這個項目的項目經理，雖然他進公司才不到3年，但他已成功地管理過2個類似的項目，被大家稱之為“救火隊長”，而強某也對自己信心十足。但這次和以往不同的是強某還同時管理著另外兩個項目，而這個人口管理系統項目的工期要求緊、他能調用的人手

少。

該人口管理系統項目屬于升級項目。原來的系統為某公司開發，是C/S結構，只能管理本地城區常住人口。新的人口管理系統要求是B/S結構，要既能管理城區常住人口又能管理郊區常住人口、市轄縣常住人口和流動人口，而公安局要求該新系統首先把流動人口管理起來。該項目從技術角度可分為網絡改造和軟件開發，而軟件又分界面、業務流程和數據庫三個子系統。他們團隊有6人，其中有人做過類似的C/S結構的項目，而公司剛剛結束的一個網絡項目與本次承擔的網絡改造項目在技術架構方面幾近相同，只是規模不同。公安局要求新系統能夠支持移動接入，而項目團隊中沒有一人接觸過移動接入技術。強某憑直覺知道依現有的人員在2008年7月1日之前完成項目是不可能的。

【問題1】請說明強某可以用什么方法和技術來估算項目的工期（300字以內）？

【問題2】請說明強某可以采取哪些方法來壓縮工期，以使項目能夠在2008年7月1日之前交付（300字以內）？

【問題3】請說明強某可以采用哪些方法來跟蹤項目的進度，以確保項目能夠按期交付（300字以內）？ 例題6分析

本案例是一道關于項目時間管理的題，主要考查考生對制訂項目進度、壓縮項目工期、監控項目進度時所使用的技術與工具。

同樣，在回答問題之前，應先通讀試題的說明，以明了問題所在。

讀完試題的說明之后，可知某公司強某遇到了相當普遍存在的問題：出現的問題是相當普遍的。項目工期緊、項目經理包括團隊成員任務重，還涉及一些新技術。此時，要準確地估算工期，必須先明確任務，也就是明確定義項目的工作分解結構（WBS）。通過把WBS中的工作包進一步分解為活動，然后對活動進行定義、排序與資源估算，就可以確定整個項目的工期了。由于該項目是新舊交叉，所以對于新增的移動接入模塊，可以聯系業界專家，采用德爾菲法進行估算，對于舊模塊可依據歷史數據采用類比法估算。

結合傳統的工期壓縮技術，加上考生的經驗，就可以回答【問題2】了。

【問題3】不僅涉及到監控方法，還要使用項目管理的工具軟件。例題6解答要點

【問題1】

（1）明確定義項目的工作分解結構（WBS）。

（2）由于是升級項目，所以部分工作的工期估計方法可以采用類比估算法。

（3）對于新增的移動接入模塊，可以聯系業界專家，采用德爾菲法進行估算。

（4）對于WBS進行足夠細化后，可依據歷史數據采用參數估算或三點估算進行進一步歷時估算。

【問題2】

（1）與客戶進行溝通，梳理業務需求中的關鍵需求，與客戶進行協商能否在期限前先完成關鍵需求，其他部分分期交付。

（2）制定出合理可靠的技術方案，對其中不熟悉的部分，可以采用外包的方法。

（3）清晰定義各功能模塊之間的接口，然后可以加大并行工作的程度。

（4）明確目標、責任和獎懲機制，提高員工的工作績效。

（5）必要時，進行趕工。

【問題3】

（1）基于WBS和工時估算制定活動網絡圖，制定項目工作計劃。

（2）建立對項目工作的監督和測量機制。

（3）確定項目的里程碑，并建立有效的評審機制。

（4）對項目中發現的問題，及時采取糾正和預防措施，并進行有效變更管理。

（5）使用有效的項目管理工具，提升項目管理的工作效率。2.7 例題7：項目時間管理

小張是負責某項目的項目經理。經過工作分解后，此項目的范圍已經明確，但是為了更好地對項目的開發過程進行有效監控，保證項目按期、保質完成，小張需要采用網絡計劃技術對項目進度進行管理。經過分析，小張得到了一張表明工作先后關系及每項工作的初步時間估計的工作列表，如表22-1所示： 表22-1 工作列表

工作代號 緊前工作 歷時（天）

A-5 B A 2 C A 8 D B、C 10 E C 5 F D 10 G D、E 15 H F、G 10 【問題1】

請根據上表完成此項目的前導圖（單代號網絡圖），表明各活動之間的邏輯關系，并指出關鍵路徑和項目工期。節點用如圖22-1所示的樣圖標識。ES DU EF ID LS LF

圖22-1 節點樣圖 圖例：

ES：最早開始時間 EF：最早結束時間 LS：最遲開始時間 LF：最遲完成時間 DU：工作歷時

ID：工作代號 【問題2】

請分別計算工作B、C和E的自由浮動時間?！締栴}3】

為了加快進度，在進行工作G時加班趕工，因此將該項工作的時間壓縮了7天（歷時8天）。請指出此時的關鍵路徑，并計算工期。試題7分析

【問題1】

（1）按題目中給定活動的依賴關系和歷時，可得到如圖22-2項目活動網絡圖。圖22-2 項目活動網絡圖

（2）因為本題比較簡單，我們可以列出圖中所有路徑，并計算其時間跨度，如表22-2所示。

表22-2 時間跨度情況

圖中路徑

時間跨度

ABDFH 5+2+10+10+10=37 ABDGH 5+2+10+15+10=42 ACEGH 5+8+5+15+10=43

ACDGH 5+8+10+15+10=48 ACDFH 5+8+10+10+10=43 因此，關鍵路徑為ACDGH，工期為48天。

【問題2】

活動的自由浮動時間也就是自由時差，其計算公式為：

自由浮動時間 = 活動的最遲結束時間-活動的最早結束時間

= 活動的最遲開始時間-活動的最遲開始時間

因此，活動B的自由浮動時間為13-7=6；11-5=6?；顒覥的自由浮動時間為5-5=0；13-13=0；活動E的自由浮動時間為18-13=5；23-18=5。

【問題3】

活動G的歷時變為8天，則重新計算各路徑的時間跨度如表22-3所示。表22-3 重新計算后的時間跨度情況

圖中路徑

時間跨度

ABDFH 5+2+10+10+10=37 ABDGH 5+2+10+8+10=35

ACEGH 5+8+5+8+10=36

ACDGH 5+8+10+8+10=41

ACDFH 5+8+10+10+10=43 因此，關鍵路徑變為ACDFH，工期為43天。例題7解答要點

【問題1】

圖22-3 項目活動網絡圖

關鍵路徑為ACDGH，工期為48天。

【問題2】

活動B的自由浮動時間為6天，活動C的自由浮動時間為0天，活動E的自由浮動時間為5天。

【問題3】

關鍵路徑變為ACDFH，工期為43天。2.8 例題8：項目組織形式

某系統集成商B最近正在爭取某鋼鐵公司A的辦公網絡遷移到外地的項目。李某是系統集成商B負責捕捉項目機會的銷售經理，鮑某是系統集成商B負責實施的項目經理。由于以往項目銷售經理的過度承諾給后繼的實施工作帶來了很大困難，此次鮑某主動為該項目做售前支持。該辦公網絡遷移項目的工作包括鋼鐵公司A新辦公樓的綜合布線、局域網網絡系統升級、機房建設、遠程視頻會議系統、生產現場的閉路監控系統等5個子系統。鋼鐵公司A對該項目的招標工作在2006年8月4日開始。該項目要求在2006年12月29日完成，否則將嚴重影響鋼鐵公司A的業務。

時間已到2006年8月8日，鋼鐵公司A希望系統集成商B能在8月15日前能夠提交項目建議書。鋼鐵公司A對項目的進度非常關注，這是他們選擇集成商的重要指標之一。根據經驗、鋼鐵公司A的實際情況和現有的資源，鮑某組織制定了一個初步的項目計劃，通過對該計劃中項目進度的分析預測，鮑某認為按正常流程很難達到客戶對進度的要求。擬訂的合同中將規定對進度的延誤要處以罰款。但是銷售經理李某則急于贏得合同，希望能在項目建議書中對客戶做出明確的進度保證，首先贏得合同再說。鮑某和李某在對項目進度承諾的問題上產生了分歧，李某認為鮑某不幫助銷售拿合同，鮑某認為李某亂承諾對以后的項目實施不負責任。本著支持銷售的原則，鮑某采取了多種措施，組織制訂了一個切實可行的進度計

劃，雖然其報價比競爭對手略高，但評標委員會認為該方案有保證，是可行的，于是系統集成商B中標。系統集成商B中標后，由其實施部負責項目的實施。

【問題1】

在制訂進度計劃時，鮑某可能會采取哪些措施使制訂的進度計劃滿足客戶的要求？

【問題2】

實施項目的系統集成商B目前的組織類型是什么？如何改進其項目的組織方式？如何改進其項目管理的流程？如何降低管理外地項目的成本？

【問題3】

在項目實施過程中，負責售前工作的李某應繼續承擔哪些工作？ 試題8分析

【問題1】

案例的背景“鋼鐵公司A對項目的進度非常關注”和“按正常流程很難達到客戶對進度的要求”，現在試題問的是“在制訂進度計劃時，鮑某可能會采取哪些措施使制訂的進度計劃滿足客戶的要求”。也就是說，在現有資源受限的情況下，如果按照正常流程安排進度，是肯定不能滿足用戶的進度要求的，因此，必須采取一些壓縮項目工期的方法，包括增加工作的并行度（趕工）、縮短工作歷時、增加資源或提高資源資源率（加班）、外包等。

【問題2】

從試題介紹來看，“李某是系統集成商B負責捕捉項目機會的銷售經理，鮑某是系統集成商B負責實施的項目經理”，以及后面關于李某和鮑某的爭執，可以看出系統集成商B實施項目的組織方式是職能式的。職能式項目組織結構有很多不好的地方，例如，在各部門之間的協調就存在問題，正如本題案例所描述的情況，這是職能式項目組織的一個通病。因此，系統集成商B實施項目的組織方式應該改進為矩陣式結構。項目下一個階段的人員要提前介入到前一個階段，例如，實施階段的項目經理正式參與售前工作。也可以選擇做好各流程間交接工作，例如，實施與售后服務之間的技術交底。

本項目是一個外地項目，那么如何降低管理外地項目的成本呢？與本地實施項目相比，外地實施項目需要增加人員差旅費、通信費，以及管理成本。因此，為了降低成本，可以委托或分包給當地有相應資質的集成商，或在當地招人。如果材料或服務在當地獲得可降低成本，則盡量在當地采購。另外，要盡量壓縮人員差旅成本，使用QQ、MSN、E-mail等電子溝通手段，以降低通信成本。

【問題3】

由于在項目實施以前，一直都是負責售前工作的李某與客戶聯系，而且，也是由于李某“急于贏得合同，希望能在項目建議書中對客戶做出明確的進度保證”，導致整個項目進度難以安排。鮑某本著支持銷售的原則，采取了多種措施，組織制訂了一個切實可行的進度計劃，但該計劃的執行需要一些資源的支持，也需要客戶的支持。因此，需要李某繼續與客戶高層溝通，了解客戶對項目實施情況的反映，維護客戶關系。同時，也可能會發掘一些新的項目機會。

作為內部來說，為了便于與客戶溝通，李某應該參加周例會，或至少每周收一次周報以了解項目的進展和問題，要參與可能發生變更的前期評審工作。最后，在項目收尾時，李某要負責或者協助收款。例題8解答要點

【問題1】

（1）溝通。強調該項目對系統集成商B的意義，提高該項目優先級。例如開會這種方式，爭得相關部門建議、支持與承諾。

（2）從現有的資源和實際情況出發，優化網絡圖，例如重排活動之間順序，壓縮關鍵路

徑長度。

（3）增加資源，或者使用經驗豐富的員工。

（4）子任務并行、內部流程優化。

（5）盡可能地調配非關鍵路徑上的資源到關鍵路徑上的任務。

（6）優化外包、采購等環節并全程監控。

【問題2】

（1）目前系統集成商B實施項目的組織方式是職能式的。

（2）系統集成商B實施項目的組織方式應該改進為矩陣式。

（3）項目下階段人員提前介入到前一階段，如實施階段的項目經理正式參與售前工作。也可選擇做好各流程間交接工作，如實施與售后服務之間的技術交底。

（4）委托、分包給當地有相應資質的集成商，或在當地招人。如果材料或服務在當地獲得可降低成本，則盡量在當地采購。盡量壓縮人員差旅成本。使用虛擬遠程的溝通手段。

【問題3】

（1）與客戶高層繼續溝通，了解客戶對項目實施情況的反映，維護客戶關系，發掘新的項目機會。

（2）參加周例會，或至少每周收一次周報以了解項目的進展和問題。

（3）參與可能發生變更的前期評審工作。

（4）負責或者協助收款。2.9 例題9：項目溝通管理

閱讀以下關于溝通管理的敘述，回答問題1至問題3，將解答填入答題紙的對應欄內。【說明】

某系統集成商B負責某大學城A的3個校園網的建設，是某弱電總承包商的分包商。田某是系統集成商B的高級項目經理，對三個校園網的建設負總責。關某、夏某和宋某是系統集成商B的項目經理，各負責其中的一個校園網建設項目。項目建設方聘請了監理公司對項目進行監理。

系統集成商B承攬的大學城A校園網建設項目，計劃從2002年5月8日啟動，至2004年8月1日完工。期間因項目建設方的資金問題，整個大學城的建設延后5個月，其校園網項目的完工日期也順延到2005年1月1日，期間田某因故離職，其工作由系統集成商B的另一位高級項目經理鮑某接替。鮑某第一次拜訪客戶時，客戶對項目狀況非常不滿。和鮑某一起拜訪客戶的有系統集成商B的主管副總、銷售部總監、銷售經理和關某、夏某和宋某3個項目經理?？蛻舻囊庖娙缦拢?/p>

你們負責的校園網項目進度一再滯后，你們不停地保證，又不停地延誤。

你們在實施自己的項目過程中，不能與其他承包商配合，影響了他們的進度。

你們在項目現場，不遵守現場的管理規定，造成了現場的混亂。

你們的技術人員水平太差，對我方的詢問，總不能提供及時的答復。

??

聽到客戶的意見，鮑某很生氣，而關某、夏某和宋某也向鮑某反映項目現場的確很亂，他們已完成的工作經常被其他承包商攪亂，但責任不在他們。至于客戶的其他指控，關某、夏某和宋某則顯得無辜，他們管理的項目不至于那么糟糕，他們項目的進展和成績客戶一概不知，而問題卻被擴大甚至扭曲。

【問題1】

請簡要敘述發生上述情況的可能原因有哪些？

【問題2】

針對監理的作用，承建方如何與監理協同？

【問題3】

簡要指出如何制定有多個承包商參與的項目的溝通管理計劃？ 例題9分析

【問題1】

田某是系統集成商B的高級項目經理，但后來離職，由鮑某接替。而鮑某接任高級項目經理時，似乎對整個項目一無所知，這至少說明系統集成商B的內部管理有問題，對整個項目監管缺位或不得力，沒有及時把項目經驗累積為組織資產。

“期間因項目建設方的資金問題，整個大學城的建設延后5個月”，這說明客戶自己本身的原因，導致項目發生延遲以后的混亂狀況。

“至于客戶的其他指控，關某、夏某和宋某則顯得無辜，他們管理的項目不至于那么糟糕，他們項目的進展和成績客戶一概不知，而問題卻被擴大甚至扭曲”，這則說明．系統集成商B沒有或極少與客戶進行直接溝通，導致客戶對自己的工作不熟悉?？蛻魪目偝邪袒蚱渌邪棠抢铽@得的信息有失真。從試題描述來看，顯然，總承包商報告渲染了問題，推卸了責任。

“聽到客戶的意見，鮑某很生氣，而關某、夏某和宋某也向鮑某反映項目現場的確很亂，他們已完成的工作經常被其他承包商攪亂，但責任不在他們”，這說明系統集成商B沒建立現場管理制度，或者現場管理制度不嚴密不明確，或現場管理制度執行不力。而且，總承包商與分包商（系統集成商B）責任不是十分清楚。

最后，因為在這個項目中，還有第三方（監理方）的參與，監理方是代表建設方對整個項目進行監控的，但在監控之下，項目仍然發生混亂，這說明項目的監理工作沒有到位。

【問題2】

這是一個理論性問題，與試題的案例描述沒有關系。

監理作為獨立的第三方，需要公平、公正、公立地處理項目建設過程中所出現的問題，維護各方利益。監理方與承建方是沒有合同關系的，監理方與建設方簽訂監理合同，按照監理合同的要求來對承建方的建設工作進行監控，其監控的依據之一就是承建方和建設方所簽訂的建設合同，其目的就是要確保項目按期完成，并達到建設合同的要求。因此，承建方要正確認識監理方的作用，要認識到承建方和監理方不是對立關系，而是有著共同的目標，就是完成項目目標。

在項目管理方法上，采取的是“三方一法”，即建設方、承建方、監理方都采用項目管理方法來對項目進行管理，監理的主要內容是“四控三管一協調”，承建方也需要在這些方面進行配合，接受監理的監督和協調，有關中間成果需要通過監理的審核或評審。另外，承建方要積極主動地與監理方搞好關系，進行周期性的溝通，確保項目“溝通無障礙”。

【問題3】

這也是一個理論性試題，與試題描述的案例背景的關系不大，考查的內容是項目溝通管理計劃的制定。有關這方面的內容，在第12章中有詳細的介紹，在此不再重復。例題9解答要點

【問題1】

（1）系統集成商B內部管理有問題，至少監管缺位或不得力。

（2）系統集成商B沒有或極少與客戶進行直接溝通。

（3）沒建立現場管理制度，或者現場管理制度不嚴密不明確，或現場管理制度執行不力。

（4）總承包商與分包商責任不是十分清楚。

（5）客戶從總承包商或其他承包商那里獲得的信息有失真?？偝邪虉蟾驿秩玖藛栴}，推卸了責任。

（6）客戶自己本身的原因。

（7）監理工作做得不好。

【問題2】

（1）承建方要正確認識監理的作用，他們和監理方不是對立關系，而是有共同的目標，就是把項目做好。

（2）雙方都采用項目管理的方法，承建方協助和配合監理方對項目的“四控三管一協調”，接受監理方的協調和監督，中間成果需要通過監理方的評審。

（3）承建方和與監理方要進行周期性的溝通。

【問題3】

（1）調研各集成商的溝通需求，進行項目干系人分析。

（2）發揮總承包商牽頭作用和監理方的協調作用。

（3）對共用資源的可用性進行分析，引入資源日歷。

（4）解決沖突，包括干系人對項目期望之間的沖突、資源沖突等。

（5）建立健全項目管理制度并監管其執行。

（6）采用項目管理信息系統。2.10 例題10：資源沖突管理

某電子政務項目涉及到保密信息。項目建設的資源尤其是人力資源必須從甲方單位內部獲得，因為如果把項目的部分任務交給分包商，一方面要征得甲方的同意，一方面要求分包商具有相應的保密資質，而保密資質的審核需要很長時間，等待審核結果也需要一段時間，這將嚴重危及到項目的交付日期。當項目團隊內的工程師完成90%的編程和測試任務時，項目承建單位的一名副總裁承攬了一個新項目，他把程序員、測試工程師從該項目上調走，去執行他新承攬的項目。

【問題1】

請簡要說明發生上述情況的可能原因。

【問題2】

簡要敘述如果項目經理希望繼續推進該項目，應如何進行？

【問題3】

請簡要敘述如何處理多個項目之間的資源沖突。試題10分析

【問題1】

本題的案例描述比較簡短。因為項目涉及到保密信息，所以項目建設的資源尤其是人力資源比較緊張，而且在完成90%的編程和測試任務時，項目承建單位的一名副總裁承攬了一個新項目，他把程序員、測試工程師從該項目上調走，去執行他新承攬的項目。那么出現這種情況的原因是什么呢？在這種簡單背景下，我們只能憑自己的項目經驗，來“猜測”其中的原因。

首先，副總裁承攬了新的項目，就可以在原項目未完成的情況下就把人員調走，這說明可能是單位沒有對項目進行統一管理，誰的權力大誰的項目就獲得優先支持。當然，也可能說明副總裁承攬的新項目對整個單位來說更重要，更符合企業的戰略目標，因此，就可以把一些次要的項目的資源減少甚至下馬。

其次，我們認可副總裁承攬的新項目更重要，但一個單位可能同時實施著多個項目，為什么恰好就要從該項目中把程序員、測試工程師調走呢？這說明可能是本項目的績效不好，項目的完工不能給單位帶來利益，已經失去了單位有關方面的支持，甚至可能是公司高層領導已經內定該項目暫停或者下馬。

最后，在完成90%的編程和測試任務時，人員被調走，也說明了項目經理可能忽視了單位內可能的競爭性項目的出現所帶來的風險，在人員、時間的預算上做得不到位。

【問題2】

當前的狀況是完成90%的編程和測試任務，程序員、測試人員被調走了，那么，如果項目經理希望繼續推進該項目，應該怎么做呢？我們首先要搞清楚，項目經理的職責就是接受公司高層的委派，在已有資源約束條件下管理一個項目。根據問題1的分析，項目經理要組織有關專家評估該項目，評估之后，如果認為項目還是“有利可圖”的，則就應寫出充分準備反映項目現狀與前景預測的報告，向主管領導匯報、說服和溝通，陳述該項目的重要性和預期的利潤，如果項目下馬會造成的損失等，以得到及時的和滿足要求的資源支持。

如果領導批準了該項目繼續推進，則因為本項目的特殊性（要保密），所以要用本單位可靠又能干的人員。如果單位人手不夠，則盡量讓本單位的其他非涉密項目去社會招聘或外包。如果單位確實無法增加資源，因為項目只剩下不到10%的工作，此時，項目經理應該說服原來的團隊加班或趕工以按期完成項目。

【問題3】

在多項目管理中，資源沖突是難以避免的，關鍵的是如何解決好沖突。當發生資源沖突時，最簡單的辦法就是增加資源，或者把一些非核心的開發任務外包出去。然而，作為一個單位來說，資源總是有限的，因此，還必須采取其他措施。

在進行多項目管理時，要成立項目管理辦公室，由項目管理辦公室統一管理所有的項目和資源，制定資源在項目之間分配的原則。定期檢查項目的執行情況，根據項目進展情況和企業整體績效重新排定項目的優先順序（例如，使用DIPP方法），從資源上優先支持重要的和進展良好的項目。例題10解答要點

【問題1】

（1）可能是單位沒有對項目進行統一管理，誰的權大誰的項目就獲得優先支持。

（2）副總裁承攬了新的更重要的項目。

（3）項目經理忽視了單位內可能的競爭性項目的出現所帶來的風險。

（4）可能是本項目的績效不好，已失去了本單位有關方面的支持。

（5）可能是重要干系人如客戶、公司高層管理者內定項目暫?；蛘呦埋R。

【問題2】

（1）如果經評估后，認為項目可為，就應寫出充分準備反映項目現狀與前景預測的報告，向主管領導匯報、說服和溝通，陳述該項目的重要性和預期的利潤，如果項目下馬會造成的損失等，以得到及時的和滿足要求的資源支持。

（2）因本項目要保密，所以要用本單位可靠又能干的人員。如果單位人手不夠，盡量讓本單位的其他非涉密項目去社會招聘或外包。

（3）如果只剩下不到10%的工作，應說服原來的團隊加班趕工以期完成項目。

【問題3】

（1）建議單位統一管理所有的項目和資源，制定資源在項目之間分配的原則。

（2）定期檢查項目的執行情況，根據項目進展情況和企業整體績效重新排定項目的優先順序，從資源上優先支持重要的和進展良好的項目。

（3）外包。

（4）必要時，增加資源。

（5）建立項目管理體系，設立項目管理辦公室，統一管理單位所有項目。