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

系統集成項目案例分析

本章收集了實際項目中的大量案例，每個案例側重點各不相同，是對前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項目中，相關的責權不夠分明，同 時缺乏協調性。這無形中增加了項目的實施難度，同時也很容易埋下隱患。

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

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)項目概述和約束

①關于項目目標沒有太多需要考慮的地方，這些目標之類我都是基本上照抄我上一 個項目的相同內容。客戶／用戶的內容也很簡單。

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

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

·需求分析：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)“這種事也要我們做？你們這么熟，人又這么多，順手一弄就完了，啊，就這么 定了吧。”

(4)“這事我這種小兵管不了，我負不起這責任，你們還是找我們領導去吧！”

(5)“那是使用部門的事，跟我沒關系，你找他們吧……”

對這些話，王東都不知道怎么對付才好。

項目的壓力超乎尋常地大，客戶每8個工作日的檢查對項目組來說是個很大的負擔，而不是能解決問題的幫助，部門經理張廷和公司項目管理部經常追著問項目進度。

每天都有新的問題涌來、每天都有新的壓力，來自客戶的、來自公司的、來自項目 組成員的，進度方面的、資源方面的、技術方面的、亂七八糟方面的l面對這些鋪天蓋 地而來的信息、問題、壓力，王東覺得再下去就要崩潰了！

王東感嘆的是為什么每一個項目都不順、都這么麻煩，是自己運氣不好？公司的問 題？還是行業、客戶的問題？

3．項目控制部分

項目一開始公司領導和部門領導就一直希望這個項目能按目標完成，目標顯然不可 能達到時又寄希望于修訂后的目標能夠達到。項目經理被要求努力地去控制好項目以達 到各方面的目標。

王東的回憶：

一個事先沒有預料到的情況嚴重地干擾了項目的進展：甲方頷導每8個工作日的視 察有時滿意有時很不滿意，但不管怎么樣都會提出一堆意見和要求，這樣好那樣不好，要這樣下次別讓我看到那樣等等。項目有項目原來的進度計劃，每天干什么都有安排，而為了滿足這些要求原來的安排全都被打亂了。甲方提出的這些意見有的跟《技術規范》 一致、有時不一致，一開始我和李鵬還想部分頂住，但因為甲方領導層次較高，我覺得 他要是震怒可能公司領導又會很緊張，同時也不希望因為我不同意滿足甲方的要求讓甲 方向高層領導投訴，這樣會讓我很被動。

這種對修改要求的滿足一旦開始就很難停止，這樣項目就陷入了很被動的循環，剛 把上次的要求改好了，想回復正常的開發節奏，新的一輪又開始了。這讓我覺得就像轉 輪里的小白鼠，自己永遠不知道什么時候是盡頭，直到累死為止，而外人覺得你在干你 該干的事情。

變化永遠都在發生，這是極其討厭的事情，說實話，我現在很怕聽到這種壞消息，但這種消息從項目一開始到后來還是很多。

(1)網絡設備到貨比預期晚。

(2)甲方的接入準備工作沒做好。

(3)甲方的開發配合工作沒按計劃做好。(4)項目資源的可用性發生變化。(5)技術難題的難度超乎意料。

這些變化只要一出現就讓我們沒辦法按計置|j走下去。

公司要求我控制的兩個最重要的方面是項目進度和項目成本。

美于項目成本，我也想控制，但我實在不知道除了控制項目赧艄費用外還有什么措 施可用，反正項目費用預算的總額現在還沒超，除了這一點其他的情況都無法判斷，所 以也就沒辦法控制。

關于項目進度控制，我現在覺得是一個很虛無縹渺的事情，講得實在一點就是：如 果項目沒有意外，項目的進度你就能控制得住，有了意外你就控制不住，就這么回事！

另外，公司讓我們每個月都要進,f帶-值分析，累死人又沒有用，唉……

關于項目周例會：項目組一開始還開周倒會，例會內容有如下兩項。

(1)每人匯報上周的工作情況，有沒有完成任務。

(2)確定下周工作的任務安排。

后來周例會也不開了，基本上都由王東依次問大家的工作情況再安排一下下周的 工作。

張廷覺得這個項目各方面似乎都處于失控狀態，問王東他對項目都有哪些控制措 施，王東說了一堆，張廷覺得都沒到點子上。他問王東：“你覺得項目怎么樣才能控制得 住？”

王東覺得不好回答，想了一想說：“第一要防止意外發生，第二要靠運氣!”

這個項目確實基本處于失控狀態。

在進度方面，原計劃是7月1日初驗，后來改成8月10日，然后再改成10月8日，然后……里程碑目標一拖再拖，眼看目標顯然不可能達到就又把進度目標修改一次，每 次都有客觀原因（公司項目管理部事后總結發現，要求進度目標延期或項目預算增加的 每一個項目都有絕對充分的理由、都有一大堆客觀原因）。

在項目費用方面，報銷的費用倒是不多，但整個公司里誰也沒概念：這個項目現在 已經花了多少錢，還允許項目可以再花多少錢。

在項目質量方面，一句話就可以概括：時間和資源換質量。各個環節都出了不少問 題，大部分問題是用人和時間去換的，小部分問題就算了，以后再說了，顧不上了。

最后，項目在12月5日終于通過初驗了。涉及到這個項目的所有人好像都舒了一 口氣，但沒有人有多少笑容。本來所有人對這個項目的期望值都挺高的，但現在落差太 大了。項目的成本遠遠超出了預算，無法不超，因為拖延了這么長時間、增加了這么多 人。王東知道的只停留在超出預算的數字上，但公司領導考慮的是：這個項目我們賺到 錢了嗎？我們賠了多少錢？以后這種項目還能做嗎？

各位項目成員也不開心，辛苦了這么長時間，項目沒有一個值得大家高興的結果，

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

六、歷年考點分析

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

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

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

七、案例分析要點

（1）可行性研究---------不是重點，建議不做過多的學習！１．主要內容

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

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

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

１）制定項目章程

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（３）創建工作分解結構：將項目的可交付成果和項目工作細分為更小的、更易于管理的單元。在項目范圍管理過程中，最常用工具就是工作分解結構（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糾偏糾錯

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

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

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

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

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

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

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

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

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、垂直與水平

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

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

③ 項目報告

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

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

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

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

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

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

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

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

１、做好干系人分析

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

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

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

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

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

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

８、開高效會議的做法

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

１、總承包合同

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

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

２、單價合同

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

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

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

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

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

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

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

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

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

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

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

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

2、可能會出現的問題

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

甲方無法進行跨部門協調

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

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

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

編制項目范圍說明書

創建項目的工作分解結構

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

幾個法律規定的日期

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

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

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

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

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

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

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

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

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

在項目啟動階段，項目經理首先要制定整個項目的開發計劃，它是整個項目研發工作的基礎。總體研發計劃完成后，配置管理的活動就可以展開了，如果不在項目開發之初制定項目配置管理計劃，那么配置管理的許多關鍵活動就無法及時有序的進行，而它的直接后果就是造成項目開發狀態的混亂，并注定使項目管理活動成為一種救火的行為。由此可見，在項目啟動階段制定項目配置計劃是項目成功的重要保證。配置管理計劃由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、修改的內容未與項目干系人進行溝通。

問題

二、上述情況會導致的結果：

1、缺乏對變更請求的分析可能會導致對產品的變更工作出現欠缺，與其他工作不一致等問題，對項目的進度、成本、質量方面也會產生一定的影響；

2、缺乏對變更請求的記錄可能會導致對產品的變更里是無法追溯，并會導致對工作的產物的整體變化失去把握；

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

4、修改完成后不進行驗證則難以確認變更是否正確實施，為變更付出的工作量也無法得到承認；

5、未與項目干系人進行溝通可能導致項目干系人之間的工作出現不一致之處，進而影響項目的整體質量。問題

三、配置管理中完整的變更處理流程：

1、變更申請，應記錄變更的提出人、日期、申請變更的內容等事項；

2、變更評估，對變更的影響范圍、嚴重程度、經濟和技術可行性方面進行評估；

3、變更決策，由具有相應權限的人員或機構決定是否實施變更；

4、變更實施，由管理者指定的人員在受控狀態下實施變更；

5、變更驗證，由配置管理人員或者受到變更影響的人對變更結果進行評價，確定變更結果和預期相符，相關內容進行了更新，符合版本管理的要求；

6、溝通存檔，將變更后的內容通知可能會受到影響的人員，并將變更記錄匯總歸檔，如提出的變更在決策時被否決，起初時記錄也應予以保存。

㈡如何開好例會

老張是某個系統集成公司的項目經理,他身邊的員工始終在抱怨公司的氛圍不好,溝通不足.老張非常希望通過自己的努力來改善這一狀況,因此他要求項目組成員無論如何每周都要參加例會并且發言,但對例會應如何進行,老張卻不知如何規定,很快項目組成員就抱怨例會目的不明,效率太低,缺乏效果,等等.而且由于在例會上意見相左，很多組員開始爭吵，甚至影響到人際關系的融洽。

問題一：問題產生的可能原因：

1、缺乏對項目組成員的溝通需求和溝通風格的分析；

2、缺乏完整的會議規程，會議目的，議程、職責不清，缺乏控制，導致會議效率低下，缺乏效果；

3、會議沒有產生記錄；

4、會議沒有引發相應的活動；

5、溝通方式單一；

6、沒有進行沖突管理；

問題二：提高項目例會的效果的方法：

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

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

3、明確會議的目的和期望的結果，明確要開的會議的目的，是集體討論一些想法，彼此互通信息還是解決面臨的一個問題，并確定會議的效果是以信息同步為結束還是要討論出一個確定的解決方案；

4、發布會議通知，在會議通知中明確：會議目的、時間、地點、參加人員、會議議程和議題。有一種被廣泛采用的決策方法是：廣泛征求意見，少數人討論，核心人員決策。許多會議不需要全體人員參加，因此需要根據會議的目的，來確定參會人員的范圍。實現應明確會議的議程和要討論的問題。可以讓參會人員提前做準備；

5、在會議之前把會議資料發放到參會人員手中。對于需要有背景資料支持的會議，應是先將資料發給參會人員，以提前閱讀，直接在會上討論。可以有效地節約會議時間；

6、可以借助視頻設備。對于有異地成員參加的會議，或者需要演示的場合，可以借助于一定的視頻設備，以提高會議效果；

7、明確會議規則。指定主持人，明確主持人的職責，主持人要對會議進行有效控制，并營造一個活躍的會議氣氛。主持人要實現陳述會議的基本規則，例如明確每個人的發言時間，每次發言只有一個聲音，主持人根據會議的議程規定控制會議的節奏。保證每一個問題都得到討論；

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

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

10、做好會議的后勤保障，很多會議兼有聯絡感情的的作用，因此需要選擇一個合適的地點，提供餐飲、娛樂和禮品，制定一個有張有弛的會議議程。對有客戶和合作伙伴參加的會憶尤其如此。問題三：除了項目例會外，老張還可以采取的有效溝通措施：

1、首先應該對項目組成員進行溝通需求和溝通風格的分析；

2、對于不同溝通需求和溝通風格的成員設置不同的溝通方式；

3、除了項目例會之外，可以通過電話、電子郵件、項目管理軟件、OA軟件進行溝通；

4、正式溝通的結果應該形成記錄，對于其中的決定應該有人負責落實；

5、可以引入一些標準的溝通模板；

6、在項目組內培養團結的氛圍。

㈢人力資源管理在實施項目中的應用 王先生是負責某行業一個系統集成項目的項目經理，因人手比較緊張，王先生從正在從事編程工作的高手中選擇小張作為負責軟件子項目的項目經理，小張同時兼任模塊的編程工作，這樣導致了軟件子項目的失控。

一、軟件子項目失控的原因：

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

2、小張身兼二職，精力和時間不夠用，顧此失彼；

3、小張沒有進入管理角色，只關注于編程工作，疏于對項目的管理；

4、高級項目經理王先生對小張的工作缺乏事先培訓和跟蹤監督。

二、王先生應該這樣做才能讓小張成為項目經理，并避免項目失控：

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

2、高級項目經理應對小張的工作進行全面的估算，如果小張的工作確實負荷過重，需要找人代替小張正在從事的技術工作，解決負載平衡問題；

3、要事前溝通，對小張明確要求，明確角色的輕重緩急，促使小張盡快轉換角色；

4、上級應該平時注意對人員的培養和監控。

三、項目集成團隊的角色構成1、針對選定的項目，根據項目的特點，需要的角色如下：

⑴管理類崗位：項目經理；⑵工程類崗位：架構師、分析師、網絡工程師、軟件工程師、測試工程師、和實施人員；⑶行業專家；⑷支援類：文檔管理員、秘書。

2、組建項目團隊、建設項目團隊、管理項目團隊所需的活動

⑴組建項目團隊，明確責任，制定責任分配矩陣，制定組織結構圖和職位描述；⑵建設項目團隊，提高項目團隊的個人績效，提高項目團隊個人之間的信任感和凝聚力，已通過更好的合作提高工作效率；⑶管理項目團隊，跟蹤個人和團隊的執行情況，提供反饋、協調變更，以提高項目的績效，保證項目的進度，項目管理團隊還必須注意團隊的行為，管理沖突，解決問題評估團隊成員的績效。

㈣甲方總是不驗收項目？

某項目主要工作已基本完成,經核對項目未完成項目任務清單后,終于可以提交客戶方代表老劉驗收了。驗收過程中老劉提出了些小問題,項目經理張斌帶領團隊很快妥善的解決了這些問題,但是隨著時間的推移,客戶的問題似乎不斷.時間已超過了系統的試用期,但是客戶仍然提出一些小問題,而有些問題都是客戶方曾經提出過,并基本上已經解決了的問題.時間一天天的過去,張斌不知道什么時候項目才能驗收,才能得到最后一批款項。

問題一：發生這件事情可能的原因：

1、合同缺乏以下內容：

⑴項目目標中關于產品功能和交付物的清晰描述；⑵項目驗收標準、驗收步驟和方法(流程)⑶對客戶的售后服務承諾；

2、項目實施過程控制中出現問題：⑴在項目實施過程中沒有及時傳遞績效報告給客戶，因此客戶對項目進展和質量狀況不了解；⑵沒有讓客戶及時對階段交付成果簽字確認；

3、由于沒有售后服務的承諾，客戶擔心沒有后續的保證；

4、合作氣氛不良，客戶存在某種程度的抵觸情緒，雙方缺乏信任感，客戶對項目質量信心不足，怕承擔責任，因此不愿簽字。

問題二：張斌應該怎么辦：

1、就項目驗收標準和客戶達成共識，確定哪些主要工作完成就可以驗收通過；

2、就驗收的步驟方法和客戶達成共識；

3、就項目已經完成的程度讓客戶確認，例如出具系統使用報告，讓客戶簽字確認；

4、向客戶提出明確的服務承諾。使客戶沒有后顧之憂。

問題三：應當吸取的經驗和教訓：

1、項目合同中要規定項目成果的正式驗收標準，驗收步驟，驗收流程，和運營維護承諾等內容；

2、⑴加強項目執行過程中的控制包括：制定變更控制流程，按流程進行變更的進行變更的評估，審核、實施、記錄、確認等工作；⑵加強項目溝通管理包括：及時向客戶提供績效報告，讓客戶了解項目進展，設置對階段性成果的驗收，并讓客戶對階段性交付成果進行簽字確認，項目文檔要齊全，使項目進展有據可查。⑶加強計劃執行的控制：制定詳盡的項目管理計劃(包括進度管理計劃，成本管理計劃的分項管理計劃)，按計劃實施和檢查；

3、項目經理還應注重和客戶交往的技巧，努力促成雙方的良好合作氛圍。㈤如何完成獻禮項目

J公司2008年3月中標某市公安局的人口管理系統開發項目，因該是要在2008年11月舉辦某大型國際會議，因此公安局要求人口管理系統一定要在2008年7月1日前投入使用。強某是負責這個項目的項目經理，雖然他進公司不到三年，但他已成功管理過2個類似的項目，被大家稱之為救火隊長，而強某也對自己信心十足，但這次和以往不同的是強某還同時管理著另外兩個項目，而這個人口管理項目工期要求緊，他能調用的人手少。

該人口管理項目屬于升級項目，原來的系統是J公司開發，是C/S結構，智能管理本地城區常住人口，新的人口管理系統是B/S結構，要既能管理城區人口又能管理郊區常住人口，市轄縣常住人口和流動人口，而公安局要求該新系統首先把流動人口管理起來，該項目從技術角度可以分為網絡改造和軟件開發，而軟件又分為界面，業務流程和數據庫三個子系統，他們團隊共有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、使用有效的項目管理工㈥副總裁的項目就能優先嗎？

某電子政務項目涉及到保密信息，項目建設的資源尤其是人力資源，必須從甲方內部獲得，如果把項目的部分任務交給分包商，一方面要征得甲方同意，一方面，要求分包商具有相應的保密資質，而保密資質的審核需要很長的時間，這將嚴重危及到項目的交付日期，當項目團隊內的工程師完成90%的編程和測試任務時，項目承建單位的一位副總裁承攬了一個新的項目，他把程序員，測試工程師，從該項目上調走去從事新的項目。

問題

一、請簡要說明發生上述情況的可能原因。

問題

二、簡要敘述如果項目經理希望繼續推進該項目，應如何進行？

問題

三、請簡要敘述如何處理多個項目之間的資源沖突。

問題解答：

問題

一、發生上述情況的原因：

1、可能是單位沒有對項目進行統一管理，誰的權大誰的項目就獲得優先支持。

2、副總裁承攬了新的更重要的項目。

3、項目經理忽略了單位內部可能的競爭性項目的出現所帶來的風險。

4、可能是本項目的績效不好，已失去了單位有關方面的支持。

5、可能是重要干系人如客戶、公司高層管理者內定項目暫停或者下馬。

問題

二、項目經理希望繼續推進該項目，應當：

1、如果經評估后，認為項目尚可，就應寫出反應該項目現狀與前景預測的報告，向主管領導匯報，說服和溝通，陳述該項目的重要性和預期利潤，如果項目下馬會造成的損失等，已得到及時和滿足要求的資源支持。

2、因本項目要保密，所以要用本單位可靠和能干的人員，如果單位人手不夠，盡量讓本單位其他非涉密項目去社會招聘或者外包。

3、如果只剩下不到10%的工作，應說服原來的團隊成員加班趕工完成項目。

問題

三、處理多個項目之間的資源沖突：

1、建議單位統一管理所有的項目和資源，制定資源在項目之間的分配，2、定期檢查項目的執行情況，根據項目進展情況和企業整體績效重新安排項目的優先順序，從資源上支持重要的和進展良好的項目。

3、外包

4、必要時，增加資源

5、建立項目管理體系，設立項目管理辦公室，統一管理單位所有的項目。

㈦如何保證項目按期完工

某系統集成公司現有員工50多人，業務部門分為銷售部，軟件開發部系統網絡部等，經過近半年的醞釀后，一月，公司的銷售部與銀行簽訂了一個銀行前置機的軟件系統項目，合同中規定，6月28日前系統必須投入試運行，在合同簽訂后銷售部將此合同移交給了軟件部，進行項目的實施。項目經理小丁經歷了五年的系統分析和設計工作，但這是他第一次擔任項目經理，小丁兼任系統分析工作，此項目還有兩名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、將部分階段的工作改為并行進行；

4、對后續工作的工期重新進行估算，并考慮節假日問題，修訂計劃盡量留有余地；

5、加強溝通，爭取客戶能夠對項目范圍，以及需求、設計、驗收標準、進行確認，避免后續頻繁出現變更；

6、加強對階段工作的檢查和控制，避免后期出現返工。此外，如有可能還可以采取外包和采取縮減范圍等方法，不建議在本案中用。

問題

三、典型的信息系統集成項目的進度、時間管理的過程和方法：

1、活動定義；

2、活動排序；

3、活動資源估算；

4、活動歷時估算；

5、制定進度計劃；

6、進度控制

資源配置對進度的制約：在一般情況下，項目活動的歷時與項目的規模成正比，與投入的資源數量成反比，即投入的資源數量越多，活動歷時越短，但要注意，任何活動都有其壓縮點，當活動的歷時已達到自身的壓縮點后，增加再多的資源也無法壓縮活動歷時。在一非關鍵活動的一個較大時間延誤也許只對項目產生較小的影響㈧如何定量的管理項目的進度

一個預算100萬的項目，為期12周，現在工作進行到第八周，已知成本預算是64萬，實際支出是68萬，掙值為54萬。

問題

一、計算成本偏差CV，進度偏差SV，成本績效指數CPI,進度績效指數SPI.CV=EV-AC=54-68=-14萬元 SV=EV-PV=54-64=-10萬元 CPI=EV/AC=54/68=0.794 SPI=EV/PV=54/64=0.843

問題

二、根據給定數據畫出該項目的預算成本，實際成本和掙值圖

問題

三、對以下四表，分別分析其所代表的效率，進度和成本情況，針對每副表所反映的問題，可采取哪些措施？㈨如何讓甲方對項目質量放心和滿意 某信息技術有限公司中標了某大型餐飲連鎖企業集團的信息系統項目，該項目包含單點管理，物流系統，和集團ERP等若干子項目，由該信息技術有限公司的高級項目經理張先生全面負責項目的實施，張先生認為此項目質量管理的關鍵在于系統的進行測試。

張工制訂了詳細的測試計劃用來管理項目的質量，在項目實施過程當中，他通過定期發給客戶測試報告來證明質量是有保證的，可是客戶總覺得有什么不對勁，對項目的質量還是沒有信心。

問題

一、客戶對項目沒有信心的原因可能是：

1、張工沒有為項目制定一個可行的項目質量管理計劃并積極地實施；

2、僅向用戶提交測試報告而沒有提交全面質量管理進展情況報告（或實施報告），溝通方式單一（或不全面），容易誤導客戶，容易導致客戶不必要的擔心。

問題二、一般地，項目的管理計劃包括的內容：

1、質量責任與人員分工（或職責）；

2、組織結構；

3、程序與過程（或項目的各個過程及其依據的標準）；

4、質量控制地方法、工具、與重點（或質量評審、質量保證方法）；

5、質量管理所需的資源；

6、驗收標準。

問題

三、張工應該如何實施項目的質量保證：

1、張工應該首先執行項目的質量管理計劃；

2、采用質量保證的工具和技術（如編制質量計劃時所采用的工具和技術、質量審計、質量控制、過程分析與基準分析）等；

3、提出相應的質量整改措施，如建議的糾正措施，對項目計劃的可能的更新，對組織資產可能的更新，變更請求。項目的質量控制與質量保證的區別與聯系：

1、質量計劃是質量控制和質量保證的共同依據；

2、達到質量要求是質量控制和質量保證的共同目的；

3、質量保證的輸出是下一階段質量控制的輸入；

4、一定時間內質量控制的結果也是質量保證的質量審計對象，質量保證的成果又可以指導下一階段的質量工作，包括質量控制和質量改進；

5、質量保證一般是每隔一定時間如階段末進行的，主要通過系統的質量審計來保證項目的質量（或質量保證是按質量管理計劃正確的去做）；

6、質量控制是實時監控項目的具體結果，以判斷他們是否符合項目的相關標準，制定有效方案，以消除產生質量問題的原因（或質量控制檢查是否做的正確并進行糾正）。

(十一)與領導工作風格不一樣怎么辦？

錢某新接手一個信息系統集成項目的管理工作，根據用戶的業務要求，該項目要采用一種新的技術架構，項目團隊沒有應用這種架構的經驗，錢某的管理風格是 Y型的，在該項目啟動之初，為了調動大家的積極性，宣布了多項激勵措施，如按期用該技術架構搭建出系統原型有獎，并分別公布了具體的獎勵金額，在項目實施期間，為了激勵士氣，經常請大家聚餐，由于單位領導屬于X型的管理風格，很多餐票都不予報銷，而在項目實施現場，因施工人員技術不過關，導致一臺電源燒毀，錢某也悄悄在項目中給與報銷，負責新技術架構的架構師經歷多次失敗后，總算憑自己的經驗和探索搭建出了系統原型。最后，雖然項目的實際進度、成本和質量等目標大體達到了要求，錢某自我感覺尚可，項目好歹也通過了驗收，但他當初關于獎勵的承諾并沒有兌現，有人甚至認為他和領導一唱一和，錢某有苦難言。

問題

一、請概括出錢某在人力資源管里方面的問題。

問題

二、錢某應該用那些措施進行團隊建設，如何應用自己的Y型風格有效地管理項目？

問題

三、請敘述錢某的單位和錢某應該如何處理新技術開發和項目管理之間的關系。

問題解答：

問題

一、錢某在人力資源管里方面的問題：

1、獎勵政策沒有得到領導的同意（或支持、溝通）

2、Y型管理風格沒有與切實可行的規章制度（或措施、機制）相結合3、錢某的管理風格沒有與直接領導的管理風格相協調

4、沒有對員工進行培訓

5、沒有配備有經驗的人員（或人力資源獲取方式單一）

問題

二、錢某應該用那些措施進行團隊建設

1、一般管理技能（如溝通、交流）

2、培訓

3、團隊建設活動（如周例會、共同解決問題、拓展訓練）

4、共同的行為準則（或基本原則、規章制度）

5、盡量集中辦公（或同地辦公、封閉開發）

6、認可獎勵（或恰當的獎勵與表彰措施）如何應用自己的Y型風格有效地管理項目

1、Y性的管理風格，要與切實可行的規章制度相結合，與領導風格相一致，或相適應

2、加強對團隊成員的培訓，或教育

3、加強激勵與約束并重

問題

三、請敘述錢某的單位和錢某應該如何處理新技術開發和項目管理之間的關系。

1、培訓

(十二)中途接手的項目如何完成某系統集成商B負責大學城A的3個校園網的建設，是某弱電總包商的分包商，田某是系統集成商B的高級項目經理，對三個校園網的建設總負責。關某、夏某和宋某是系統集成商B的項目經理，各負責其中一個校園網的建設，項目建設方聘請了監理公司對項目進行監理。

系統集成商B承攬的大學城A的校園網的建設項目，計劃從2002年5月8日啟動，至2004年8月1日完工，期間因項目建設方的資金問題，整個大學城的項目延后5個月，其校園網的開工日期也順延到2005年1月1日，期間田某因故離職，其工作由系統集成商B的另一位高級項目經理包某接替，包某第一次拜訪客戶時，客戶對項目狀況非常不滿，和包某一起拜訪客戶的有系統集成商B的主管副總、銷售部總監、銷售經理和關某，夏某和宋某3個項目經理，客戶的意見如下：

1、你們負責的校園網進度一再滯后，你們不停的保證又不停的延誤，2、你們在實施自己的項目過程中，不能與其他承包商配合，影響了他們的進度

3、你們在項目現場，不遵守現場的管理規定，造成現場的混亂

4、你們的技術人員技術太差，對我方的詢問，總不能及時答復

5、……….聽到客戶的意見，包某很生氣，而關某、夏某和宋某也向包某反映項目現場的確混亂，他們已完成的工作經常被其他承包商攪亂，但責任不在他們，至于客戶的其他指控，關某夏某和宋某則顯得無辜，他們管理的項目不至于那么糟糕，他們的項目進展和成績客戶一概不知，而問題卻被擴大和扭曲。

問題

一、發生上述情況的原因有哪些？ 問題

二、承建方應如何與監理協同？ 問題

三、如何制定有多個承包商參與的項目溝通管理計劃？

問題解答：

問題

一、發生上述情況的原因：

1、自己內部管理有問題，至少監管缺位或不得利

2、集成商B沒有或很少與客戶直接溝通

3、沒有建立現場管理制度，或者現場管理制度不嚴密或不明確，現場管理制度執行不力

4、總承包商和分包商責任不是十分清楚

5、客戶從總承包商和分包商獲得的信息失真，總承包商報告渲染了問題，推卸責任

6、客戶自己本身的原因，如資金、管理水平

7、可能本項目的監理工作沒有到位 問題

二、承建方與監理協同應該：

1、承建方應該認識到位，承建方和監理方不是對立關系，他們有共同的目標：把項目搞好

2、雙方都采用項目的管理方法承建方配合問題

三、多個承包商參與的項目溝通管理計劃的制定：

1、做好干系人分析，調研各集成商的溝通需求

2、發揮總承包商的牽頭作用和監理方的協調作用

3、對共用資源的可用性分析，引入資源日歷

4、解決沖突，包括項目干系人對項目期望之間的沖突，資源沖突等。

5、建立健全項目管理制度，并監管其執行

6、采用項目管理信息系統

㈩三參數關系 分析 措施圖1 AC>PV>EV 效率低 進度拖延

投入超前 提高效率，例如，用工作效率高的人員換一批工作效率低的人員，趕工，工作并行以追趕進度，加強成本監控圖2 PV>AC>=EV 進度效率較低 進度拖延

成本支出與預算相差不大 增加高效人員投入，趕工，工作并行以追趕進度圖3 AC>=EV>PV 成本效率較低 進度超前

成本支出與預算相差不大 提高效率，減少人員成本，加強人員培訓和質量控制圖4 EV>PV>AC 效率高 進度提前

投入延后 密切監控，加強質量控制

(十三)如何簽訂和履行合同

小李是國內公司的項目經理，負責西南某省的一個企業信息系統項目建設的管理。在該項目合同中，簡單列出了項目承建方應該完成的工作，據此小李自己制定了項目的范圍說明書，甲方的有關工作由其信息中心組織和領導，信息中心主任兼任該項目的甲方經理。可是在項目實施過程中，有時是甲方的財務部直接向小李提出變更需求，有時是甲方的銷售部直接向小李提出變更需求，而且又是這些需求又是矛盾的，面對這些變更需求，小李試圖用范圍說明書來說服甲方，甲方卻動輒用合同的響應條款作為依據，而這些條款要么太粗，不夠明確，要么小李與他們理解不同，因此小李對這些變更需求不能簡單的接受或拒絕而左右為難，他感到很沮喪，如果不改變這種狀況，項目看來是遙遙無期。問題

一、問題產生的原因：

1、合同沒有制定好，沒有對具體完成的工作行程明確清晰的條款；

2、甲方沒有對各部門的需求及其變更進行統一的組織和管理；

3、缺乏變更/拒絕的準則；

4、由于乙方對項目的干系人及其關系分析不到位，缺乏足夠的信息來源，范圍定義不全面，不準確；

5、甲乙雙方對項目認可和承諾；

6、缺乏項目全生命周期的范圍控制；

7、缺乏客戶/用戶參與。

問題

二、在合同談判、計劃和執行階段應該：

合同談判階段：

1、確定明確的工作說明書或更細化的合同條款；

2、在合同中明確雙方的權利和義務，尤其是關于變更問題；

3、采取措施，確保合同簽約雙方對合同的條款理解是一致的。

計劃階段：

1、編制項目范圍說明書；

2、創建工作的分解結構；

3、制定項目的范圍管理計劃。

執行階段：

1、在項目執行過程中加強對易分解的各項任務的跟蹤和記錄；

2、建立與項目干系人進行溝通的統一渠道；

3、建立整體變更控制的規程并執行；

4、加強對項目階段性成果的審核確認

項目全生命周期變更管理：

1、在項目管理體系中應該統一有一套嚴格、適用、高效、的變更程序；

2、規定對用戶的范圍申請變更請求、應正式提出變更申請，并經雙方項目經理審核后，作出相應的處理。問題

三、合同的作用，詳細范圍說明書的作用，以及兩者之間的關系

合同法規定，合同是平等主體的自然人、法人、其他組織之間設立、變更、終止民事權利義務關系的協議。合同是買賣雙方共同遵守的協議。賣方有義務提供和保證規定的產品和服務。而買方有義務支付合同規定地價款。

項目范圍說明書詳細描述了項目的可交付物，和產生這些可交付物必須做的項目工作。項目范圍說明書在所有項目干系人之間建立了一個對項目范圍的共識，描述了項目的主要目標能使團隊能進行更詳細的

第四篇：系統集成項目管理案例分析教程 案例二團隊協作

案例二團隊協作

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

5.2.1案例場景

重慶市某行業關鍵應用IT系統(A系統)的建設工程由希賽信息技術有限公司(CSAI)中標，CSAI是國內一家大型IT系統集成商，企業通過了ISO9000質量體系認證和CMM3級認證，對信息系統工程建設有著比較成熟豐富的經驗。

CSAI總部設在長沙，有軟件研發中心。CSAI為A系統建設所組建的項目小組由兩個部分組成：一是總部長沙負責進行軟件開發工作；二是重慶現場負責進行信息系統的本地化實施，本地化實施的內容包括網絡系統建設、主機系統安裝調試、應用軟件的運行環境建設、現場測試、客戶需求跟蹤、客戶關系協調等。其中，應用軟件開發的管理工作由長沙軟件中心負責，A系統的配置

管理工作由現場負責。

CSAI對A系統應用軟件開發的控制非常嚴格，可是，由于A系統在實施的過程中，用戶不斷地提出新的需求，催促要CSAI滿足，而且，A單位的領導對進度非常關心，經常突襲檢查，要求CSAI演示所建設的應用系統的功能。CSAI現場項目經理李工也試圖通過與用戶進行溝通，以求解決需求的頻繁變更問題，解決用戶對進度的要求等。

CSAI對現場項目經理有關于維護良好客戶關系的績效考核指標，因此，李工不敢怠慢客戶所提出的要求，但為了達到A用戶所提出的需求變更、進度變更，李工想法讓長沙研究所滿足客戶的需求變更，這樣，長沙研究所的軟件開發工作量就大大增加，而且，常常趕不上客戶對項目進度的要求。

在寄托于總部無望的情況下，李工為了在工程進度方面滿足用戶的愿望，于是決定將部分應用軟件系統代碼在現場進行開發。現場開發的目的主要是加快了軟件開發的進度，李工的決定也確實很奏效，大大加快了應用軟件開發的進度。但是，當應用軟件系統投入運行后，系統故障的發生頻率卻非常高，經過對故障的分析，李工發現，這些故障當中，由現場所開發的軟件與長沙總部所開發的軟件在協同工作中所暴露的問題尤為普遍，比如，現場所修改的軟件代碼，在長沙總部下發統一版本軟件的時候常常被替換而丟失功能，A應用系統的本地化功能太多太偏而很難與統一版本融合。

另外，由于現場抽調人員參與應用軟件開發，現場本應做的配置管理工作也被耽擱了，如網絡系統的配置(設備訪問權限、路由、IP規劃等)、主機訪問權限規劃、應用系統訪問權限規劃、應用環境參數規劃等，這些現場運行環境參數，按照B公司的管理制度，是應當編制文件存檔的，但李工卻沒有安排人員來做這些工作。

由于網絡系統龐大，中心機房設備繁多，參與工程建設的人員按照各自的習慣進行系統的配置，這樣，在工程投入運行后，由于各部分配置的不規范，常常引起局部配置的變更給系統運行帶來嚴重事故。曾經在一次配置變更過程中，由于應用系統密碼的修改，導致系統停止業務半天，給用戶造成了嚴重的損失和不良影響。

【問題1】(8分)

請以300字內回答，李工對所遇到的問題的處理方法是否恰當。李工所做出的決定的主要缺陷是什么？造成問題的原因主要是什么？

【問題2】(8分)

請以300字內回答，團隊協同工作時，在軟件版本方面會造成哪些問題，應當采取什么措施以避免問題的出現？

【問題3】(9分)

請以300字內回答，在IT應用軟件開發工程中，怎樣進行項目現場與總部軟件開發團隊的有效配合？

5.2.2案例分析

CSAI雖然通過了CMM3級認證、ISO9000認證，但CSAI的管理工作未必就能按照規范來開展，有不少公司只是將這些認證作為投標競爭時的砝碼而已。因此，我們在建設工程項目的時候，不但要看IT系統集成商具不具備這些認證，還應采取有效的手段考核IT系統集成商的質量保證計劃。對IT系統集成商進行考核，簡便可行的方法就是讓集成商在項目開工前提交質量保證計劃，并對質量保證計劃進行評審，通過后要求集成商嚴格執行。通常，過程能力成熟度高(指實際)的IT企業，在實際工程與質量保證計劃之間的一致性會完成得較好，而過程能力成熟度低的企業(指實際)，實際工程與質量保證計劃之間的一致性會完成得相對較差。

【問題1】

我們都知道，信息應用系統的變更尤其頻繁，而頻繁的變更必然影響到信息工程項目的三大目標。通常與客戶接觸最多的是現場項目經理，引導客戶需求對項目經理就非常關鍵，項目經理引導得好，項目的開發就會非常順利，反之，就會使項目組疲于奔命。優秀的項目經理是既能夠讓項目組成員“睡大覺”，又能保持良好的客戶滿意度。

CSAI項目經理李工與用戶的溝通存在問題。善于溝通的人，一言明百理；不善于溝通的人，百言不明一理。項目經理與客戶的溝通，不是指項目經理善于說話，善于高談闊論就能夠解決問題，更為關鍵的是項目經理要具備足夠的引導項目建設的能力。作為現場項目經理，不是只做一個傳話筒，客戶說什么就是什么，而是應當與客戶進行深入交流，深入分析客戶所提出的問題，合理引導客戶的需求，要有主見。

李工在CSAI進行客戶滿意度考核，客戶又有大量需求的前提下，顯得無所適從，手忙腳亂，而做出了不合適的決定。

一是客戶的需求，只要我們能夠合理引導客戶，客戶的需求變更不可能有那么頻繁，有很多需求變更是可以讓用戶暫時放棄的，或有的需求變更可以讓用戶在另外的工程項目中去實現，比如建議用戶建設=期工程。我曾經見到一位項目經理在一個工程項目中，客戶提出了一個需求，項目經理安排組員加班三天三夜完成了，告訴客戶方主任，客戶主任大吃一驚，說：“我并沒有要求你們實現這個需求啊，我只不過向你們咨詢一下而已”。

客戶與我們的項目經理交談，并不是都談需求，有很多時候，客戶可能是談到自己的想法、心得體會、建議等。客戶方面也往往有很多員工，一位員工有一種思想，十位員工就有十種思想，要統一這十種思想，項目經理就得付出更多的努力，要與用戶方面的主管人員達成一致，而且，很多時候是必須要用戶的主管人員去統一他們的意見。否則，應用系統的開發就存在很大制約因素。很多項目經理面對公司客戶滿意度的考核，面對客戶無休止的需求，常常不能采取正確的應對方法，該說的不敢說了，該講的不敢講了。應用軟件工程在建設階段，優秀的項目經理應當是能夠引導用戶思路的項目經理，而不是讓用戶領導項目經理的項目建設思路。項目經理應當知道，任何一個客戶都更注重項目建設的結果，在項目建設的過程中，項目小組與建設單位之間可能存在著很多次交流，甚至爭論，但只要我們能確保項目建設的結果讓用戶滿意，用戶是終會給予好評的。

【問題2】

二是對CSAI資源的利用不當，李工把本不屬于現場的工作內容，讓現場工程師來完成是嚴重的失誤，現場工程師倉促上陣，沒有納入CSAI統一的軟件開發質量管理體系。雖然能夠臨時快速解決問題，但也會埋下故障隱患，而故障隱患的爆發卻是在工程建設的后期。這種做法只能讓員工疲于奔命。在項目管理中，如果項目組成員總是處于應急、救火的狀態，是不可能高質量地完成工作任務的。作為項目經理，不但要關心項目的進展，還應當關心自己的成員，要讓項目小組成員在高效率、高質量的狀態下工作。

三是忽略了現場應該做的重要工作，應用系統的配置管理工作對現場來說是很重要的。混亂的配置管理，也會導致系統運行中發生嚴重的質量問題。

即使李工非要在現場進行開發不可，那也應當自覺地將現場所開發的軟件，與公司總部所開發的應用軟件進行統一的管理。特別是要注意，現場開發的缺點是對需求的把握太隨意，由于開發人員與用戶直接接觸，用戶的想法可能有很多偏激的成分，也容易被現場開發人員設計到應用軟件系統中，從而導致現場版本與統一版本難以融合，特別是對有些需求的滿足，可能涉及到軟件系統體系架構的變更，這樣就更難處理了。而現場臨時決定的軟件開發，管理工作怎樣和總部的管理工作融合到一起，項目經理是應當考慮的，要么是由總部來控制，要么是現場自覺與總部配合。

【問題3】

我們在工程現場實施的時候，對于所遇到的系統問題，有的是能夠迅速解決的，也有暫時無法解決的。對于暫時無法解決的問題，我們常常采取迂回的方式繞過去，以保證工程項目的進度。但是對于應用軟件系統的開發來說，現場不能只是繞過去而已，還應當及時向總部報告，應當建立一個系統故障管理平臺，記錄所有發現的軟件故障，逐一報告研發中心進行解決，并跟蹤解決情況。

為有效解決現場與總部的配合問題，可以建設一個基于Internet的開發管理平臺，現場所遇到的問題，及時匯報到管理平臺，由總部管理人員分配解決。現場也可通過管理平臺主動與總部溝通軟件開發問題，協調一致，避免總部統一版本更新時丟失現場所開發的功能。配置管理也是涉及到工程質量的。我們做企業級的應用系統，都應當考慮到系統割接的平滑性，配置變更的平滑性，在進行配置規劃的時候就應當考慮配置的變更怎樣才能實現平滑過渡，否則，就很可能使運行的系統在進行配置變更的時候進入癱瘓狀態。而良好的配置管理，又是實現配置變更平滑過渡的有力支持。

5.2.3參考答案

【問題1】(8分)

現場用戶的需求是不可能有盡頭的，但作為項目經理要能夠把握住用戶的需求，特別是要合理引導用戶需求，切不可讓用戶怎么說就怎么做。

積極響應客戶需求要從多個方面著手考慮，不要只從技術上考慮問題，技術引導、合同變更、人力資源等各個方面都應當考慮。

臨時的現場開發工作，大多數都不可能與公司總部的軟件開發融為一體，而且管理工作常常是自上而下的，李工忽略了這點，顧此失彼，導致項目問題的發生。

造成項目問題的原因有以下幾點：李工對需求把握隨意；控制不嚴；李工與客戶溝通不到位；李工沒有向客戶提交合理的進度計劃，或沒有按時提交進度報告；項目實施無計劃，或計劃不能得到客戶認可，客戶不滿意。

【問題2】(8分)

團隊協同開發軟件時，很容易出現軟件版本管理不善帶來的軟件系統故障。同一軟件系統代碼不能同時由多人進行修改。

項目現場為應急而擅自更改軟件代碼，而常常沒有將更改納入統一的版本管理，很容易造成總部發行新版本軟件時，替換軟件而丟失了現場所進行更新的代碼，從而造成系統故障反復出現。

李工如果一定要進行現場開發，應當委托現場合適的人員，或親自督促現場所進行的開發工作與總部所進行的開發工作在軟件版本方面保持一致，處理本地過于偏激的需求要與總部協商一致的情況采取合理措施控制統一版本。

【問題3】(9分)

項目現場應明確自己的工作職責范圍，要自覺與總部門形成密切的配合。

現場所做的開發，應與總部所做的開發納入同一個軟件版本管理。

當現場發現軟件故障時，應當及時向總部報告。建立故障管理表，記錄并跟蹤軟件系統故障解決情況。

建設一個軟件開發交流平臺，如基于Internet的管理平臺，管理工程現場所提出的問題，調度、跟蹤解決工程現場問題。

現場工程人員與總部人員應多交流，通過各種方式，如及時通信軟件、電話、電子郵件等，必要時，可組織研發部給現場工程人員進行培訓。

第五篇：系統集成項目管理案例分析教程 案例二溝通渠道

案例二溝通渠道

閱讀以下關于信息系統項目管理過程中團隊建設和項目溝通管理問題的敘述，回答問題1至問題3。

7.2.1案例場景

希賽信息技術有限公司(CSAI)是由某集團投資建立的致力子為教育行業提供針對信息技術咨詢、開發、集成的專業應用解決方案提供商，在“數字化校園”領域具有多年的研發經驗和相當數量的客戶成功案例。經過長時間的使用和改進，系統已經日趨成熟，獲得了廣大用戶的信賴。目前通過和有關銀行的合作，綜合考慮了學校的需求，為“數字化校園”推出了軟、硬件結合的“銀校通”完整解決方案。

半個月前，CSAI和U大學合作建設的“銀校通”項目正式立項。由于CSAI已有比較成熟的產品積累，項目研發工作量不是特別大。張工被任命擔任該項目的項目經理，主要負責項目管理和用戶溝通等工作。張工兩個月前剛從工作了五年時間的B公司辭職來到CSAI，由于B公司主要從事電子政務信息系統的集成，故張工在“數字化校園”的業務方面不是特別熟悉。

項目組成員還包括李工、小王、2名程序員和1名測試人員，李工主要負責項目中的技術實現，小趙和小高2名程序員主要負責程序編碼工作，小王負責項目文檔的收集和整理。在CSAI，李工屬于元老級的人物，技術水平高也是大家公認的，但李工在過去作為項目經理的一些項目中，工作上常由于沒有處理好客戶關系為公司帶來了一些問題。

小王的工作雖然簡單但是格外繁重，因而多次向張工提出需要增派人員，張工也認為小王的工作量過大，需要增派人手，因此就事多次與CSAI項目管理部門領導溝通。但每當CSAI項目管理部門就此事向李工核實情況時，李工總是說小王的工作不算很多，而且張工的工作比較輕松，讓張工幫助下小王就可以了，不需要增派人員。因而CSAI項目管理部門不同意張工關于增加項目組成人員的建議。

張工得到CSAI項目管理部門意見反饋后，與李工進行了溝通，李工的理由是張工的工作確實不多，總是幫別人提意見，自己做得不多。所以李工認為張工有足夠時間來幫助小王完成文檔工作。張工試圖從崗位責任、項目分工等方面對李工的這個誤解進行解釋，又試圖利用換位思維的方法向李工說明真實情況，但李工依舊堅持自己的看法，認為張工給自己的工作太少。

【問題1】(8分)

什么是項目溝通管理中的溝通渠道，溝通渠道與溝通復雜性的關系怎樣，試根據溝通渠道的計算公式計算該項目小組內部溝通渠道的數量。請用300字以內文字回答。

【問題2】(9分)

請用500字以內文字分析該項目中存在的主要項目管理問題，并針對問題提出建議。

【問題3】(8分)

請用200字以內文字結合你本人的實際經驗，就軟件項目中如何改進項目溝通提出實質性的建議。

7.2.2案例分析

【問題1】

溝通渠道(Communication Channels)是項目中溝通的排列組合數量，看起來像聯系所有參與者的電話線的數目。

CC = N(N-1)÷2其中CC表示溝通渠道 N表示項目中成員數

比如當項目團隊有3個人時，溝通渠道數為3×(3-1)÷2=3;而當項目團隊有9名成員時，溝通渠道數為9 ×(9-1)÷2=36。由于溝通是需要花費項目成本的，所以應盡量控制團隊規模，避免大規模團隊中常常出現的溝通不暢的問題。

溝通的復雜性會隨著項目中人員的增加而增加，項目溝通渠道急劇增加，溝通偏好差異化矛盾上升。地理位置和文化背景也會影響到項目溝通的復雜性。如果利益相關者來自不同的國家，那么通常在正常的工作時間安排雙向的溝通會非常困難甚至不可能。語言障礙也可能給溝通帶來一些問題。接收者對信息的解釋很少與發送者想的一模一樣。因此，提供多種溝通方法和一個能促進坦誠對話的環境是很重要的。

根據項目案例的場景描述，項目組成員包括張工、李工、小王、2名程序員和1名測試人員。項目組成員總數為6人，根據溝通渠道數計算公式，該項目小組內部溝通渠道的數量為6 ×(6-1)÷2=15。

【問題2】

根據案例的場景，項目經理張工兩個月前剛來到C公司，在C公司從事的“數字化校園”的業務方面不是特別熟悉，在C公司張工的資質相對較淺。李工是C公司的元老級人物，一個資質比較老的技術人員。根據項目經驗，項目經理沒有威信，一般工作很難開展。為了項目目標的實現必須依靠技術人員的積極配合，作為項目經理張工應該加強團隊建設，逐步樹立自己的威信，消除項目組成員溝通中的一切障礙，保證團隊溝通順暢。根據項目案例的場景描述，項目中出現的主要問題集中體現在三個方面：

(1)項目經理角色定位問題

作為項目經理，張工應該能較好地把握全局。對于軟件開發項目，工作量估算、人力資源管理和溝通管理等方面顯得特別重要，張工在這些方面存在較大的欠缺，盡快熟悉公司業務是張工成為合格的項目經理必須解決的首要問題。

特別地，針對小王的問題。張工必須充分地了解小王文檔編寫工作的實際情況，以客觀地判斷小王是否真的因為文檔太多而忙不過來，還是因為小王的工作方法不當、工作效率低導致“忙不過來”。根據自己了解到的實際工作狀況決定是向C公司項目管理部門還是幫助小王改進工作方法、提高效率解決小王忙不過來的問題，以避免不必要的人員和成本增加。

(2)團隊建設與協作方面的問題

C公司項目管理部門對張工擔當項目經理沒有做充分的授權，對張工缺乏必要的信任和支持。李工自恃是C公司的元老級人物，技術水平高而對張工的項目管理工作沒有認可。事實上，軟件企業中常存在這樣的角色，很多時候也為項目管理帶來了許多問題。項目組成員總體缺乏協調和配合，表現出對立與矛盾的僵化局面。

對于李工，他的問題可能是技術人員可能都有的通病，認為溝通不是什么真正的工作，技術工作才是項目成功的關鍵問題，而且確實不知道張工每天在做些什么。

(3)溝通不暢

該項目組溝通上存在很大問題，張工或許應該先自我檢討一下，與領導之間的溝通是否存在什么問題。其次，在李工的方面，其實對待技術人員用“尊重”一般都比較有效，建立良好的個人關系，從各個方面去關心你的項目組成員，尤其是關鍵人物。“元老級人物”是麻煩的制造者，但如果項目經理關系處理得當，有時可以把負面影響轉變為正面。

項目組所有成員，特別是張工、李工、小王應該相互理解和支持，保持充分的溝通，畢竟作為一個項目團隊，理解和溝通是很重要的，沒有暢通的溝通這個基礎，項目進展也是不可能很順利的。張工應該加強與李工的交流，甚至應該加強一下私人關系，否則總有類似的成員向領導說反話的話張工的工作會受到很大干擾。如果李工的不合作精神依舊，可以考慮讓李工離開自己的團隊，另行委派別的技術人員。

【問題3】

根據軟件企業項目管理實際情況，改進項目溝通的建議包括：

(1)使用項目管理信息系統(PMIS)輔助溝通

項目管理的復雜性要求有合適的工具輔助項目管理人員進行項目管理工作。項目管理信

息系統(PMIS)是用于收集、綜合和分析項目管理過程輸出的工具和技術。通常用來支持項目從啟動到收尾的各個方面，可分為人工系統和自動系統。這里主要指能夠幫助項目進行范圍管理、時間管理、成本管理、采購管理、風險分析等綜合功能的管理信息系統。PMIS一般包含兩塊核心的功能—計劃和控制。計劃系統主要圍繞質量、時間、成本三大目標，輔助完成項目計劃工作，如工作結構分解(WB S)、進度計劃(網絡圖、甘特圖)繪制、CPM、成本計劃等。控制系統重要提供一些控制手段，以領導和協調項目組織的各種要素，包括人力資源、工程設計、原材料和財務等部門。

(2)建立溝通基礎結構

溝通基礎結構(Communications Infrastructure)是一套工具、技術和原則，為項目信息傳送提供一個基礎。工具包括電話機、傳真機、電子郵件、項目管理信息系統、視頻會議系統、文件管理系統及文字處理程序等；技術包括報告指導方針、文檔模板、會議基本規則和程序、決策過程、解決問題的方法、沖突解決和協商技術及與此相似的技術；原則包括提供開放式對話的環境，使用“率直交談”和遵照公認的工作道德規范。

(3)使用項目溝通模板

為使項目中日常溝通更容易，組織項目管理部門需要為一般的項目溝通建立一些范例和模板，如項目章程、績效報告和口頭狀態報告等。以往項目的好文檔是范例的豐富的來源。書面的和口頭的范例和模板對于從來沒有寫過項目文件和做過項目陳述的人來說，特別有幫助。文檔模板需要進行維護和升級，以適應項目實際工作要求的需要。建立和維護項目管理文檔模板文件庫是組織項目管理部門重要工作職責之一。

(4)把握項目溝通基本原則

在信息系統項目中，為了提高溝通的效率和效果，需要把握：溝通內外有別；非正式的溝通有助于關系的融洽；采用對方能接受的溝通風格；溝通的升級原則；掃除溝通的障礙等基本原則。

(5)發展更好的溝通技能

有些人似乎天生就有很好溝通能。有些人則有學習技術技能的訣竅，但很少發現有人天生就擁有上述兩種技能。然而，溝通技能和技術技能都能學習提高。多數IT專業人員因其技術技能而得以進入這個領域。然而，多數人發現溝通技能是提升職位的關鍵，特別是如果他們想成為優秀的項目經理。

溝通技能培訓通常包括角色扮演活動，通過這些活動讓參與者建立協同的觀念。培訓課還為參與者提供機會去發展在小組中溝通的特殊技能。著重于表達能力的培訓課通常把參與者的表現記錄在錄像帶上。多數人對他們在錄像帶中看到的言語上的特殊習慣感到驚訝。喜歡這種提高他們技能的挑戰。在溝通和表達培訓方面很小的投資就能為個人、項目和組織帶來巨大的回報。這些技能比他們在技術培訓課上學到的許多技能有更長的生命力。

(6)認識和把握人際溝通風格

認識和把握人際溝通風格，針對不同溝通風格的人，“個性化定制”，采用對方喜歡的方式去溝通，就會取得好的溝通效果。

要解決由于文化背景、工作背景、技術背景等因素造成的人們溝通過程中編碼和解碼過程中的偏差，需要了解影響溝通的重要因素之一人際溝通風格。不同的人表達同樣的事會用不同的方式，原因是人們擁有不同的人際溝通風格。人際溝通風格可以簡化為四種類型，即理想型、實踐型(操縱型)、表現型(親和型)、理性型(分析型)，四種風格有各自的表現特征。

(7)進行良好的沖突管理

沖突管理是利用溝通技能創造性地處理項目沖突的藝術。沖突管理的作用是引導這些沖突的結果向積極的、協作的而非破壞性的方向發展。許多信息系統項目都具有很高風險，這些項目要求項目組成員付出巨大努力，花費高昂，占用重要的資源，對組織內的工作方式有

廣泛的影響。當風險高時，沖突就不可避免；當潛在的沖突高時，良好的溝通就是必要的。在這個過程中，項目經理則是解決沖突的關鍵人物。

解決沖突的五種基本策略包括：問題解決(Problem Solving)；妥協(Compromise)；圓滑(Smoothing)；強迫(Forcing)和撤退(Withdrawal)等。

(8)召開高效的會議

會議是項目溝通的一種重要形式。一個成功的會議能成為鼓勵項目團隊建立和加強對項目的期望、任務、關系和責任的工具。失敗的會議會對一個項目產生負面的影響。例如：一個糟糕的啟動會議(kickoff meeting)—在項目或項目階段開始時舉行的會議。所有重要的利益相關者在會上討論項目目標、計劃等等—可能會使一些重要的利益相關者決定不再支持該項目，許多人抱怨他們的時間浪費在一些不必要的或者缺乏計劃的、糟糕的會議上。

7.2.3參考答案

【問題1】(8分)

溝通渠道(Communication Channels)是項目中溝通的排列組合數量，看起來像聯系所有參與者的電話線的數目。

溝通的復雜性會隨著項目中人員的增加而增加，項目溝通渠道急劇增加，溝通偏好差異化矛盾上升。地理位置和文化背景也會影響到項目溝通的復雜性。如果利益相關者來自不同的國家，那么通常在正常的工作時間安排雙向的溝通會非常困難甚至不可能。語言障礙也可能給溝通帶來一些問題。接收者對信息的解釋很少與發送者想的一模一樣。

根據案例的場景描述，項目組成員包括張工、李工、小王、2名程序員和1名測試人員。項目組成員總數為6人，根據溝通渠道數計算公式，該項目小組內部溝通渠道的數量為6 ×(6-1)÷2=15。

【問題2】(9分)

根據案例的場景，項目中出現的主要問題集中體現在三個方面：

(1)項目經理角色定位問題

作為項目經理，張工應該能較好地把握全局。對于軟件開發項目，工作量估算、人力資源管理和溝通管理等方面顯得特別重要，張工在這些方面存在較大的欠缺，盡快熟悉公司業務是張工成為合格的項目經理必須解決的首要問題。

(2)團隊建設與協作方面的問題

C公司項目管理部門對張工擔當項目經理沒有做充分的授權，對張工缺乏必要的信任和支持。李工自持是C公司的元老級人物，技術水平高對張工的項目管理工作沒有認可。事實上，軟件企業中常存在這樣的角色，很多時候也為項目管理帶來了許多問題。項目組成員總體缺乏協調和配合，表現出對立與矛盾的僵化局面。

(3)溝通不暢

該項目組溝通上存在很大問題，張工或許應該先自我檢討一下，與領導之間的溝通是否有什么問題。其次，在李工這一方面，其實對待做技術的人用“尊重”一般都比較有效，建立良好的個人關系，從各個方面去關心你的組員，尤其是關鍵人物。“元老級人物”是麻煩的制造者，但如果項目經理關系處理得當，有時可以把負面影響轉變為正面。

【問題3】(8分)

根據軟件企業項目管理實際情況，改進項目溝通的建議包括：

(1)使用項目管理信息系統(PMIS)輔助溝通。

(2)建立溝通基礎結構(Communications Infrastructure)。

(3)使用項目溝通模板。

(4)把握項目溝通基本原則。

(5)發展更好的溝通技能。

(6)認識和把握人際溝通風格。

(7)進行良好的沖突管理。

(8)召開高效的會議。