前言：想要寫出一篇令人眼前一亮的文章嗎？我們特意為您整理了5篇it項目管理范文，相信會為您的寫作帶來幫助，發現更多的寫作思路和靈感。

it項目管理范文第1篇

【關鍵詞】IT；項目管理；風險；探討

一、引言

雖然現實生活中，項目風險管理失誤而導致的IT項目失敗的現象較為普遍，但是在很長一段時間內一直未受到人們的重視。其主要原因在于IT行業平均利潤率遠遠高出傳統行業，即使IT行業內存在巨大問題，但是也能保證盈利，從而使很多企業迷惑，甚至忽視了風險管理的重要性。IT項目風險是指由于IT項目所處環境和條件的不確定性，導致項目的最終結果與我們的期望產生背離，并給相關人帶來損失的可能性。而所謂IT項目風險管理是對項目中潛在的風險進行預測并實行有效的控制，從而可靠地實現項目的總體目標的一種管理IT項目管理。

隨著科學技術的進步、經濟全球化進一步發展、IT行業的競爭日益激烈等等原因，使得企業不得不重視起IT項目的風險管理問題。

二、IT項目管理風險的來源分析

IT項目的風險越來越受到企業的重視，因此深入分析項目風險的來源，為采取有效措施控制項目風險奠定基礎顯得尤為重要。一般而言，IT項目風險主要來源于以下幾個方面：

（一）系統風險

IT 行業發展迅速，產品更新速度快。IT行業是未來的朝陽行業，根本原因在于這個行業出現的時間不長但它的發展卻非常迅速。所以IT項目必然會不斷遇到新標準和新的發展趨勢。并且同時，IT 行業內的競爭與合作也不斷改變著 IT 企業或企業聯盟的戰略和競爭優勢，從而影響 IT 項目的發展進程。

（二）技術風險

1、技術成熟度不夠

在一個項目里，使用的技術種類越少越好，因為這樣可以保證技術的穩定和成熟。無論如何，對我們來說，新的技術都是未知的，它們未必能像我們期望的那樣發揮作用。

2、開發與管理工具選擇不適合

開發和管理工具的選擇對于IT項目有著非常的意義。一方面，正確的選擇開發和管理工具有助于IT項目順利的推進，另一方面，選擇合適的開發和管理工具，可以減少再次開發同時縮短實施周期。

3、項目測試不縝密

在驗收性測試中，這卻是常常發生的事，因為一直到這個時刻，完整的方案才被集成在一起，實際的業務場景到了這個時候才第一次被放到方案里去執行。在測試里發現的堆積如山的問題中，其實很難把真正的缺陷找出來。當背負著這些包袱開始新的返工周期時，對抗的心態又會出現：方案供應商總是“帶罪羔羊”。然而，只有在詳盡的測試案例執行完成以后，功能修改的巨大任務負擔才會完整地呈現出來。

（三）成本風險

1、IT項目運營成本存在不可預知性

一個實施成功的IT項目就會有比較少的后期維護成本。但通常在IT項目實施過程中的干擾因素非常多，項目的變更也時常出現，使得項目的執行結果通常與預期有著較大的偏差，這樣就給后期的維護工作帶來很多麻煩.而且一些新型的項目在實際的使用過程中通常會出現預先沒有料到的問題，維護工作相當復雜，費用也就居高不下。

2、項目范圍的變更，導致成本上升

多數的 IT 項目通常只有開始具體實施時，才能夠通過詳細的調研發現客戶的真實需要，可能會出現與原先的設想出入很大的情況，因而項目就不得不進行變更。項目變更后，其成本范圍就超出了原先的項目計劃和預算，這樣很不利于項目的整體控制，因此而產生溝通、協調費用.甚至項目返工等風險，都給成本的控制增加了難度，從而大大增加了項目的總成本。

（四）進度風險

1、項目進度估計不精確

進度管理作為 IT 項目管理中及其重要的一環，但估計項目進度與估算項目成本同樣都是前瞻性的工作，所以出現估計項目進度不精確也是項目管理中經常碰到的難題。

2、資源短缺或變更導致項目進度拖延

資源，最主要的是人力資源。有時會出現某方面的人員不夠或者在多個項目的情況下某部門的人員中途被抽到其他項目或身兼多個項目的局面，而對進度造成影響；同時預算的變更會影響到某些資源的變更，也會對進度造成影響。

（五）運營風險

1、對項目認識和理解不充分

IT 項目開發者和項目業主之間溝通的一個要點就是要做出一份詳盡的計劃，從而避免在項目認識和觀點理解上的沖突，以較好地協調項目認識和沖突。

2、未合理授權

在 IT 項目開始之前，項目團隊的每一個角色都必須明確下來，并為每個角色找到最合適的人。要用既明確無誤又容易理解和接受的方式告訴每一個成員，他（她）擔當什么角色，這個角色的涵義是什么。非常重要角色同其他項目組成員之間的關系在團隊內部必須作出正式的說明。防止造成由于授權不合理造成管理模糊之處，而造成項目管理的混亂。

3、溝通不暢

IT 項目管理中，項目組內部需要以規范形式進行管理信息的溝通，因為這可使各個管理層能直接、有效地了解項目情況。在項目持續的過程里，規范的溝通確實非常重要。但是，我們還要明確，溝通并不是單向的，如果有新的信息出現，那么就應該讓全體成員及時了解，以免造成巨大的損失。

三、控制IT項目管理風險的對策

市場經濟環境下，各個行業都會遇到各種各樣的風險，對于IT項目而言也如此，如何在具體運營過程中，準確把握項目風險行動路徑，然后根據具體步驟，制定科學合理的方法減少和消除風險。此外我們還要考慮管理成本，防止避免風險產生的成本遠遠超過風險實際發生時的成本。我們可以通過以下途徑來控制應付各種IT項目風險，具體如下：

（一）選擇適合的項目經理

在 IT 行業里面，隨著具有項目經理頭銜的人日益增加，取得 PMP（Project Management Professional，項目管理師）證書的人也逐步增多，但使得項目管理達到最終目標的人才卻非常稀少。所以選擇什么樣的項目經理更加適合于企業的真正需求就越加重要，同時對于一個 IT 項目的風險管理也日益突出。一般來說，從四個方面來進行考慮與評判：知識、經驗、能力和性格。在這里需要特別強調對行業的了解，不僅是對 IT 行業的深入了解，而且還需要對其他行業的經營理念也有所相關認識。知識掌握得是否牢固，是否全面，是否應用自如，最終決定著項目經理的水平和水準。在項目開發中，項目經理要對風險管理負責人闡述潛在風險和管理風險并起著重要的參謀作用，并且也要讓所有涉及到項目開發的人員關心和關注風險問題，所以選擇適合的項目經理是成功的關鍵因素之一。

（二）建立風險管理計劃

IT 項目的風險管理作為項目管理的一部分，需要形成一個完善的和全面的風險管理計劃。應包含四個階段：風險識別、建立風險物化結果、理解風險形成的驅動因素、以盡量減少風險，達成共識。按照上述的風險分類方式，運用聚焦的方法，提出相應的風險問題，進一步形成項目的風險評估問卷，這有利于幫助風險管理負責人考慮主要風險或目前存在的相關風險。然后進行檢查風險物化后的結果或問題，它為規避風險提供指導，其次要進行全面檢查風險的驅動因素。如果能理解好這些因素，那么在風險管理方面，風險管理負責人就可以能夠在預防和避免風險方面發揮出重要的作用，最后根據上述步驟建立和實施適當的行動方法和方案。在這個過程中，應注意避免風險而造成的成本不能超過解決風險物化后造成的結果成本。

（三）對項目參與人員進行業務培訓

由于參與者對相關業務不熟悉或不完全理解而構成業務風險中很大一部分，尤其是項目經理。因此，有必要在 IT 項目實施之前對他們進行必要的業務培訓，使參與者能夠對業務流程有充分的理解，并有必要安排考核的方式和方法，進而組成精干的開發團隊。

（四）建立定期風險審查的審計計劃

IT 項目的風險管理過程中會面對各種不同的風險管理環境。所以，除檢查風險管理計劃以外，定期檢查或審計風險水平也是非常重要的。在國外 IT 項目開發中普遍使用風險評估和審查技術來做此項工作，這樣便可以在進行項目風險分析時為項目管理人員提供一整套有效的方法和措施。

參考文獻：

[1] 禹莉.基于實物期權的BOT項目風險分析及管理研究[D].西南交通大學 2010

[2]呂斌.海洋工程項目的風險管理研究[J].中小企業管理與科技（上旬刊）.2010（01）

[3]甘華鳴主編.項目管理[M].中國國際廣播出版社，2002

it項目管理范文第2篇

[關鍵詞] 項目管理 客戶管理 客戶角色

一、前言

作為以軟件開發和實施為主的IT企業，其項目管理的主要工作就是能夠合理的利用企業研發、服務、銷售和客戶等各方資源，在總體成本和工期的控制范圍內，能夠按期或者提前完成項目建設，滿足甚至超越客戶需求，完成項目驗收和回款。項目需求來源和最終結果好壞的裁判就是客戶。所以客戶作為項目最重要的干系人，對軟件項目的影響至關重要。項目管理中的客戶管理包括客戶甄別、客戶需求管理、客戶溝通、客戶投訴管理等各個方面的內容。

二、軟件項目客戶

為了提高客戶滿意度，現代的軟件項目管理方法都向以客戶為中心、客戶驅動、客戶參與的項目管理方式轉移。所以我們必須認識到客戶是軟件項目成敗的核心因素。正確的識別和定義軟件項目的客戶，這是IT企業客戶管理成功的基礎。

比如，某IT企業的軟件開發類項目，其項目目標是針對電信運營商的網絡管理中心和運行維護部門的實際生產和管理需求，需要解決他們的實際工作問題:自動化網絡維護工作，規范化工作流程管理等。因此，該企業開發出來的產品，能否解決客戶的實際工作問題和困難，最終用戶是否滿意，項目直屬領導是否滿意，能否解決實際的網絡維護和保障問題，給運營商創造了多少直接和間接的價值，是否能落實客戶領導的管理思路，是判斷該產品或項目是否成功的標尺。由于企業的產品需求來源是客戶，最終評判也是客戶，所以要做好軟件項目的管理，就要在需求調研、需求評審、驗收軟件項目流程的幾個關鍵環節上明確具體客戶和客戶責任，包括哪些是最終客戶，哪些客戶負責提需求，哪些是決策客戶，哪些是驗收客戶（驗收客戶最好與提需求的客戶是同一個團隊或個人）。同時客戶也要明確相應的職責，明確他們在項目中的地位和角色，才能提高企業產品的針對性、準確性，促進項目順利進展，促進項目驗收和回款，甚至衍生出新的或者下一期的項目。

所以，在軟件項目中，需要明確以下四種客戶角色：

1.要明確最終使用部門和用戶，要去了解他們現有的工作方式，要讓他們知道項目的目標框架，知道項目要解決他們的哪些困難，但絕對不是全部困難，這樣可以較好的控制項目范圍。

2.要明確需求的提出者，他或者他們要能夠代表最終客戶群體。提出產品需求的這類客戶要具有一定的技術、業務能力和權威，能夠真正代表最終客戶團隊的意愿和想法，最好有IT基礎，能夠用IT語言描述問題和需求，以利于雙方的溝通、協作，避免產生歧義。

3.要明確做需求確認的中層領導,他要把握方向。軟件開發項目是解決實際生產或者管理問題，同時也是領導系統建設的具體實現,做需求確認的客戶領導,既要了解高層領導的系統建設要點和方向,又要諳熟具體業務和生產管理實際。如果是這樣的客戶領導來把握和決策，對企業軟件開發項目的順利進展作用非凡。

4.要明確誰來對成品提意見，誰來驗收。項目驗收環節，是項目的收尾環節,如果驗收的人對項目初期的需求目標不了解，會從態度和產品實際使用效果上對驗收產生負面的影響，對提品的企業關閉項目非常不利。根據實踐總結,由需求提出人和確認人來做項目的驗收工作,能夠促進項目的順利完成,避免延期。

三、軟件項目各階段的客戶管理

IT企業軟件項目的實施較之于其他項目，有其特點。也決定了該類企業的客戶管理工作的獨有特性。在通常情況下，軟件項目分為四個階段，分別是:需求識別階段、制定方案階段、實施階段和結束階段。

由于軟件項目的各階段具有不同的特點，所以始終貫穿于項目各階段的項目客戶管理在不同的階段實施的內容也有差異。

1.需求識別階段。需求對于軟件項目來說是一把雙刃劍，它既可能讓一個項目成功，也可能讓該項目失敗。對于項目組織而言，該階段非常重要，需精確識別客戶的真實需求。因此，在該階段，項目經理應充分與客戶溝通，組織內其他與項目相關的成員也必須頻繁活動，通過一切渠道充分獲取關于客戶的所有信息。隨后，項目團隊應對收集到的信息加以匯總并進行深層次、多角度的分析，隨時將不明確之處反饋于客戶，以期客戶解答，并要求客戶審核需求分析書，達到與客戶的真實期望高度一致。同時，項目方還要做好需求和需求的變更管理，切實捕捉客戶的真正需求，避免開發資源的重復勞動，縮短開發周期。因此，我們需要在以下幾方面做好管理工作：

(1)需求溝通和描述的規范化。要用標準化的工作方式和工具與客戶溝通并描述需求。一些規范的需求調研與溝通手段，諸如隨工、問卷、原型展示等，都可以針對實際情況來使用，其主要目的是更準確的把握客戶需求。需求描述文檔要針對不同的需求部分，比如界面應用、處理邏輯等，通過標準化的文檔模板來描述和表現，并和用戶確認落實，填平需求和功能之間的鴻溝，同時給后端研發提供可管理的開發點介入。

在理解和認同客戶需求方面，我們需要把握以下幾點：

①能夠站在客戶的角度，知道什么需求是對的，什么需求的應用是更適合的;②客戶了解業務語言，開發人員了解IT語言，應用需求和開發之間的鴻溝，有時需要產品經理去填平;③提倡以草圖或者可視信息化的方式和用戶溝通，確認界面、業務需求;④要學會換位思考，針對不同層面的客戶提供最適合的操作界面，用戶覺得好用的才是真正好的軟件產品;⑤要抓住重點需求，尤其是客戶方領導關注的創新類和實用類需求。

(2)需求變更的規范化管理。需求變更在軟件開發類項目中是正常的也是可以理解的，對需求變更需要做規范化的管理。一方面避免出現需求反復無止境的風險，另一方面可以一步一個腳印的落實資源調配和項目實施。需求變更需要經過統一的接口人提出，并且要用戶需求的審核領導認可，需求變更要定期而不是隨時的提出，我們要做好詳細的記錄，讓客戶能夠了解需求變更的實際情況，了解客戶自身和我們為之付出的成本代價。

2.制定方案階段。該階段項目團隊的主要任務就是與客戶一起制定一個以前期明確的需求、雙方的資源、項目開始實施的時間約定、項目費用限制等為基礎的具有可操作性的項目計劃，從本階段開始爭取客戶全面參與項目的管理，需要雙方共同考慮項目實施的具體計劃落實和風險規避。

3.實施項目階段。在該階段，軟件項目團隊應該與客戶共同領導項目的實施。同時，項目團隊應實時評估客戶滿意度，并通過持續改進提高客戶滿意度，還應要求客戶參加必要的培訓，以及在必要時檢查項目產品。在出現客戶的需求變更前，應主動與客戶溝通交流，使客戶充分了解項目的每個環節，以及變更帶來的影響，減少需求變更。如果出現客戶需求變更，應與客戶一起共同解決由變更引起的成本、進度、質量變化；如果與客戶發生沖突，應與客戶坦誠相待，以項目的最終目標和實現雙方的利益最大化來權衡，化解矛盾。在項目執行過程中，促進雙方人員的認識和了解，記錄客戶的個性要求和特點，建立合作伙伴關系。

想在項目實施和管理過程中，獲得客戶的持續滿意，并最終達到雙方的共同目標，軟件項目組織的相關崗位人員應從以下幾方面加以關注和改進：

(1)在獲取項目過程中，相關銷售人員不要過分承諾。如果過分承諾，會給后續的項目實施帶來困難；一旦承諾沒有兌現，也會降低客戶滿意度，影響今后合作。如果有附加承諾，一定要讓實施項目經理知曉并傳達給項目組成員。

(2)項目組要充分理解售前投標書或建議書的內容，并在項目正式開始后就項目需求范圍以文檔化的形式與客戶確認。

(3)項目經理要切實履行自己的職責，做好項目規劃和人員管理，并時刻銘記項目目標。

(4)項目經理要定期與客戶方相關負責人召開項目會議，介紹項目進展情況以及項目過程中遇到的問題。

(5)項目實施過程一定要規范，質量控制要到位，項目資料編寫規范和齊全。

(6)項目組成員要努力工作，利用過硬的技術本領和規范化的實施，贏得客戶的信賴。

(7)項目階段成果要讓客戶參與評審并聽取客戶的意見和建議，并在里程碑點交付客戶。

(8)銷售人員要保持與客戶的聯系，了解項目進展和問題，在項目組和客戶有意見分歧時起到緩沖的作用，不要等到項目收款時才露面。

4.結束項目階段。在項目結束階段，軟件項目團隊應組織項目經驗或教訓總結會，邀請客戶參加。評估客戶滿意度，并加以全面分析，請客戶評估項目組織各個環節的工作，提出建議和批評。在項目結束后，仍需和客戶保持聯系，建立長期合作關系。

四、客戶溝通

客戶溝通是軟件項目客戶管理中的“劑”。在明確了項目中的各種角色和目標客戶之后，接下來需要在項目的各階段，做好貫穿項目始終的客戶溝通工作。結合軟件項目需求調研、方案評審、項目開發和結束驗收等不同的階段，客戶溝通會涉及到以下內容：

1.和需求提出者（或者最終用戶）的溝通。要盡量深入他們的實際工作，了解項目需要解決的實際問題的關鍵點。要使用不同的溝通手段和溝通工具來和用戶溝通，比如手繪界面或者圖片界面、原型法來和客戶溝通應用需求；比如用例圖、流程圖等方式來和客戶溝通業務邏輯和流程需求等，爭取把IT語言和客戶語言能夠很好的在表述上達到一致，切忌自以為是，答非所問。

2.和決策者或者客戶領導的溝通。項目產品基本定型和相對完整的產品需求，需要經過客戶領導的認可，以確認項目建設思路和方向沒有偏離，利于投入更多的資源來細化和付諸開發實現。和客戶領導要定期匯報溝通項目進展，及時修正項目目標偏離，爭取客戶更大力度的協調配合，裁定項目范圍需求邊界。和客戶領導的溝通要主動和及時，要堅持到項目結束，貫穿始終。每周的項目進展周報也是很好的溝通方式，主動及時的匯報項目狀態，促進項目進展。

3.和負責驗收的客戶的溝通。驗收客戶最好就是需求提出者和最終客戶。由于軟件開發項目的產出是面向生產和管理實際的系統，驗收要考慮到功能、界面、性能、數據和用戶容量等多個方面。為了實現分階段建設，成熟一步運用一步，對于暫時有問題的部分，需要和客戶做詳細的書面或面對面的溝通，達成后期階段實現的共識，避免建設“大而全”且工期漫長的系統。

五、客戶抱怨處理

客戶對企業的抱怨，主要來自于對我們軟件產品方面和服務方面的期望落差，要預防和處理好客戶的抱怨，需要從以下兩個方面重點做工作：

1.產品方面。在產品功能方面，我們要盡量使得我們的產品能夠符合客戶的業務實際、工作實際和管理實際，能夠符合用戶的部門職責分工和工作流程，能夠給他們的實際工作帶來創新性的改善和提升。用戶在產品功能方面的抱怨，很可能是我們提升產品價值的寶貴信息和財富。在產品可用性方面，由于軟件所運行的主機、存儲，既有數據量和用戶使用量的不同，又有軟件產品的設計階段和實際運行階段的不同，所以我們如果想做好的產品，從設計、開發到現場部署只是完成了一半，我們還需要密切跟蹤現場的運行環境，不斷改進和優化我們的軟件產品，在容錯性、運行效率等各個方面付出努力和代價，才能使得我們的產品在用戶的工作中扎根，真正和客戶形成長期的戰略合作。

2.服務方面。服務方面的抱怨主要由專業技術和工作態度引起。客戶針對這兩個方面的抱怨或投訴，需要我們能夠具體甄別,對癥下藥。我們可以通過建立“學習型組織”、通過實行“導師負責制”等具體方式提升團隊的整體技術水平和實力。同時,還要統一服務形象、標準化服務流程、加強員工工作禮儀培訓等,全面提升員工的自身修養和素質,從而提升企業在客戶現場的服務形象和公司形象。

在IT企業中,無論是集團群組項目還是本省本地開發項目，在項目管理的諸多環節中都需要以客戶為指向，切實做好客戶管理，為項目的成功運作打下堅實的基礎。作為企業的各相關人員，尤其是項目經理,能夠做好客戶管理,意味著項目已經成功了一半。

it項目管理范文第3篇

關鍵詞:大型IT項目；管理方法；研究

在美國協同管理的計劃書中對“項目”一詞進行了相關性定義。它主要是一種針對新型產品的臨時性任務。而項目管理的最實際領域則是IT大型項目。由于IT行業的信息化、技術化水平突出,所以它與項目管理的結合方式也是非常先進的,其項目管理的知識性與科技性也遠遠超過其他行業。

1大型項目管理的定義以及特點

1.1大型項目管理的定義

在美國的管理策略中說明,大型項目管理就是運用多種綜合性解決方式,在人員最優組合的基礎上,從多個學科、多個領域的范圍進行的一種管理活動。一般來講,大型項目的管理時間應該超過一年,并且操作人員能夠從中看出其巨大的風險性。一個大型項目可能不僅僅是由一個單位進行操作,它通常是應用于創新性的項目當中,并且由無數個子項目構成。另外,大型項目的階段性體現得較為明顯,研發者需要對各類產品以編號的形式呈現出來,并且以產品說明為基礎,在實驗環境下對產品進行測量。通常來講,企業需要建立一個自身條件非常突出的團隊去進行,并且要花費上一到兩年的時間來完成。如果新產品的集成性非常高,并且各階段的連貫性較強,其中會涉及到許多實際應用的環節,那么項目的制定與管理的時間可能會更長。

1.2大型項目管理的特點

相比中小型項目管理來講,大型項目管理的特點是非常顯著的。第一,它有著明確的任務性。管理者會在項目啟動之初就進行時間設定,并且規定負責人在相應時間內完成的任務數量與順序,對項目開發任務進行有效的編制。各項目的階段管理者應該按照實際要求進行有效實施。第二,管理工具的先進性。提到IT項目管理,大家首先想到的就是高科技性與計算機的應用。從業人員不僅要有編訂任務的能力,還要能夠將任務管理過程與計算機相結合,能夠對計算機進行靈活使用。第三,信息溝通的及時性。在大型項目管理當中,各項目負責人的信息一定是連貫的、統一的。現代通信技術扮演著二者的紐帶與傳遞角色,它能夠時時進行信息交互與分享,使溝通方式做到相對完善。第四,資源提供的必要性。資源是保證軟件開發與信息交流的前提,IT行業中的信息資源相對完整,并且能夠以很高的效率加以利用。文件服務器可以與第三方軟件系統相連接,并且在數據庫與語言編程系統的協作下完成高質量的工作[1]。

2大型IT項目管理方法研究

2.1溝通管理

在大型IT項目的管理之中,良好的溝通性是非常重要的。在項目管理中有這樣的一句名言“客戶只會針對你的問題進行回答,而不會將他們心中所想對你進行傾訴”。這句話也正說明了溝通管理的重要性與前提。從IT行業布局的至高點來講,溝通交流甚至能夠決定一個企業的項目管理成敗,并且在一定程度上影響企業的發展[2]。第一,與客戶進行溝通并且及時解決問題。IT項目中,客戶會參與到企業的發展全過程,并且與管理者進行及時的交流。不管是在方案制定、實施還是評價方面,客戶都希望能夠完成得相對全面。所以,操作者要明確以上幾點要求。在與客戶交流時,要以他們的實際需求為導向,并且將每一點都以文本的形式制作出來。同時將制作后的文檔發送給客戶,讓他們對以上總結的幾個方面進行查看,以避免二次改進的情況。這是項目設計與成功轉變的關鍵,也是能夠將項目規劃理論迅速傳遞給用戶的主要手段。另外,信息交流中還包括一些非語言式的要求,這需要制定者進行詳細的分析。項目制定中的一些問題客戶可能不會考慮到,而其中的隱患是顯而易見的。在這種情況下,設計者要將此部分內容列入到規劃過程中,并且拿給客戶查看,以保障方案的相對完整性與健全性。第二,溝通計劃的制定非常重要。首先,各部門經理要對預案進行編制。預案編制的過程中要以建設項目框架為主,定期制定項目例會,根據項目的總體流程設定可視化測評報告與問題協調商議組織。從需求性出發,編制每天的任務表格,建立整體化的溝通協作體系。其次,在實際實施的過程中,要建立客戶與方案制定者之間的關系,在每個子項目下進行分組,每個組員負責不同的項目內部評價系統的反饋,將執行情況在第一時間進行疏通。第三,項目經理對整體任務進行分管。他的主要工作是對各部門的交流情況進行匯總,了解各子項目的進度與資源需求,并將他們的成績予以報送。項目經理根據執行因素與指令,進行及時的補救與完善[3]。

2.2風險管理

大型IT項目本身就存在著很大的風險性。管理者實施措施之前,要對風險進行預測,并且做到管理水平的完善性。從IT項目的特點中也可以看出,高風險、高收益是其主要形式之一。項目的規劃與建設過程中往往會存在著一些不確定性與無保障性。管理者要能夠正確地識別風險的性質。一般來講,IT行業的風險會分為直接與間接兩種。雖然管理者不能夠將風險完全剔除,但可以適當地預防,并制定最及時的控制手段。IT項目風險根據種類的不同可進行劃分。其中分別是需求風險、編制計劃風險、組織結構設置風險、環境規劃風險、客戶評估風險、設計產品風險以及管理運維風險。IT項目的風險管理要經歷一定的過程,它并不是一蹴而就的。首先,管理者要將可能出現的風險一一列舉出來。根據相關資源進行整合,在風險數據庫評價的基礎上進行過程運維。其次,制定風險檢查表。衡量風險所能夠出現的最大臨界值與最小范圍,對風險狀態進行整合與規劃。最后,根據風險的實際情況對各部門的相關工作進行改進,在監督考評的基礎上加大實施力度。IT項目管理的具體風險管理方式如下:第一,對項目文件的制定規則進行審核。其中包括文件的形成、項目的設計流程、人員的職位設定、項目成本測評、風險中的假設條件等等。從IT項目的實際規劃情況入手,才能夠將風險進行全面性預防,并且在文件中識別這些相關風險。第二,專家調查法。根據項目的實際情況與建設過程尋找相似性,找出比較貼近的項目進行探訪與查詢,與相關的技術規劃專家進行協商,詢問此項目中容易出現問題的關鍵點所在。第三,管理者可以將各部門的人員進行集合,將他們所認為的一些風險預估結果進行歸結,進而形成風險預估的系統性管理方式。第四,類推比較法。企業管理者可以建立風險測評軟件,將項目的具體說明與注意內容都輸入到計算機中,將相似項目的評估結果也予以錄入,在建立數據統計庫的基礎上完善評估方式。系統可以根據相似性數據進行對比、核算與分析,進而將這些數據轉化成圖形的形式呈現在管理者的面前,管理者可以更加清晰地看出其中的缺陷與問題所在[4]。

2.3創新管理方式,建立虛擬的管理途徑

對于IT項目的管理手段而言,創新才是當前企業的出路,也是彰顯企業獨特管理手段的方法之一。第一,計算機系統上建立完善的人員評價與考核機制。在數據庫中輸入各部門人員的數量與相關職責,系統會對組合方式進行模擬,進而制定出一個最佳的組合策略。有效團隊的形成是科學化項目管理形成的前提。在系統內部,各部門管理者要將每天的組員工作量進行編輯。數據庫會進行自動計算,并且將月工作總量統計出來。但這只是人員評估的一個方面,評估總成績是將任務的完成數量與質量相結合。所以其中還包括客戶對每階段任務的滿意程度,系統會將這兩個方面進行綜合,最后形成合理化的考評結果。在每一小區域任務完成后,管理者可以根據總成績進行評價,給予成績優秀員工以物質獎勵,調動人員的工作積極性,創新管理方式[5]。第二,建立大型IT項目管理的信息化平臺。首先,將多個子項目的相關信息進行統計,并在一個平臺上進行核算與管理。多項目信息管理系統可以在單獨模塊評價的基礎上進行綜合評估,建立相關子項目之間的聯系。這樣的統一化平臺更方便項目的整體化管理與工作的協調發展。其次,多信息項目管理平臺能夠根據IT項目的設計方式,對每一階段的過程進行跟蹤,將項目時間、項目流程與項目的質量進行優化,及時采集現有的項目執行數據,在信息的整體把控上做到綜合性監督與管理。最后,多項目信息網絡平臺還可以將各部門的數據傳到企業的主頁面當中,通過數據庫的建立與實時報告的形成規則進行資源的傳遞與共享[6]。

3結語

綜上所述,該文以大型項目管理的定義和特點作為切入點,從溝通方式、風險系統評估與多項目信息平臺建立的3個方面來研究大型IT項目管理內容。從而得出:在大型IT項目中,管理手段的科學性與先進性能夠調動員工的內部協作性,實現信息之間的整合與共享,有效地對風險進行抑制,為企業的經濟效益提升奠定良好基礎。

參考文獻

[1]張生.大型交通建設項目關鍵要素集成管理方法研究[D].長沙理工大學,2005.

[2]班宏寶.汽車企業實施ERP項目可行性分析與風險評價研究[D].南京航空航天大學,2004.

[3]陳海艷.大型工程項目管理組織結構評價指標體系及其度量方法研究[D].國防科學技術大學,2009.

[4]陳瓊.大型集群項目管理的流程知識表示方法及其應用研究[D].華南理工大學,2011.

[5]楊婧.大型工程項目網絡化建模及關鍵節點分析方法研究[D].國防科學技術大學,2012.

it項目管理范文第4篇

項目的選擇是項目生命周期第一步，它是對單個或多個項目進行評估，并選擇其中一些進行執行從而保證項目承擔方完成任務的過程。簡而言之，項目選擇是評估所承擔項目的優點和缺點的過程 。項目的選擇是對未來做出承諾，選擇投入一個正確的項目，對于項目實施方的長期生存而言，是一個至關重要的決定。

William（2009）認為，項目管理領導應該參與項目的選擇過程，對于IT項目來說也是一樣。面臨著更大的需求，較少的預算和迫切需要證明的業務狀況，組織必須優先考慮他們的IT項目，并對目前的最佳實踐進行再創造（Boyer，2003）。

識別好項目并確定它們的優先順序，組織需要遵循一些標準。根據Gray（2010）等人的研究，項目選擇標準通常分為財務類和非財務類：對大多數經理人，財務標準是評估項目的首選方法，在對未來現金流有較強信心的情況下，它是非常合適的選擇。當然財務收益盡管重要，但并不總是反映戰略重要性。因此，當組織為恢復企業形象或提高品牌認知度而支持項目時，可能使用非財務、多準則選擇模型，即檢查表模型、多加權計分模型等等。Grey還指出，無論在不同類型的項目中存在怎樣的標準差異，最重要的選擇標準始終是項目應當適合組織的策略，并對提高業務具有戰略影響。

1.研究方法

通過查看文獻報告和公司白皮書，實地考察等多種方法對不同類型的IT企業進行了信息收集。將調查中收集到有價值的數據和信息進行對比分析，我們列出了影響項目選擇過程的重要因素。基于對在不同的IT企業中主要影響因素的識別和實際觀察，確定項目選擇的基本流程框架。

系統動力學（System dynamics，簡稱SD）是一種描述、建模和模擬復雜系統的動態行為的方法，由麻省理工學院教授Forrester于1958年提出。系統動力學是基于系統行為與內在機制間的相互緊密的依賴關系，并且透過數學模型的建立與操作的過程而獲得的，逐步發掘出產生變化形態的因果關系。

“影響圖”是單決策人基于不確定信息表示和求解復雜決策問題的圖模型，它記錄系統運行的方式，是用來建立SD模型系統的基本工具。動態行為的原因不在于一個系統中個別組件的細節，而在系統中組件之間的相互作用。影響圖列出有關變量的名稱，并用箭頭連接它們，箭頭的方向表示因果關系的方向。箭頭處的標志，顯示影響的效果。

在確定影響系統的所有因素后，我們能夠繪制出SD影響圖，它是由這些影響因素這中的不同因果關系以及這些因果關系形成的因果。通過該圖，可以將諸多因素選擇過程的影響直觀地表示出來，便于理解。

2.項目選擇的影響因素

Meredith和 Mantel（2003）指出，選擇項目中不同影響因素，包括生產、財務、營銷、人事、行政和多方面因素。生產因素包括設施和生產設備的要求、原材料的可獲得情況等；市場因素包括消費者接受程度、產量的市場份額、產出的預計周期、對當前生產線的影響等；金融因素包括盈利能力、現金需求，對現金流的影響，投資需要的規模等等；人事因素包括培訓需求、勞動技能需求、所需勞動技能的可獲得性、當前勞動力的抗拒程度，對工作環境的影響，外部和內部團體的溝通需求等等；行政及其它因素包括對信息系統的影響，對客戶、供應商、競爭對手形象的影響，專利與商業秘密保護，對新工藝的管控能力。

從調查結果中發現，對于一個中型公共IT機構（以下代稱為A機構），當用戶請求A機構的服務，以獲得IT解決方案，A機構的技術人員會去用戶有關部門研究現有系統的問題，然后提出建議來提高工作流的性能。在進行完包括團隊成員和用戶在內的若干次會議后，關于預計成本、持續時間等細節的項目文檔，和針對用戶方所需的資金和財務狀況的建議一起，應當完成并提交給用戶方。當用戶接受這個提議后， A機構評估自己的內部功能設施，包括勞動力的可用性、技能和技術等，從而選擇利用自身的資源或項目分包的方式來完成項目。

對于中小型私有IT機構（以下代稱B機構）而言，調查顯示，項目人員會接觸客戶以了解他們的問題和需求，研究后提出建議。為此，開發人員會事先分析他們是否有足夠的資金儲備，和其它所需的資源投入，以確保如果獲得該項目。如果需要額外的人力和非人力資源，由于是小型私有機構，他們可以相對容易和迅速地雇傭額外的資源。但在A機構或政府組織等，很多程序和政策必須遵循，這種為獲取資源而采取的行為不可能像在私有機構中那么簡單。

從上面的討論中，已確定6個顯著變量構成并影響“項目選擇”子系統，包括：

（1） 項目的需求和價值

（2）用戶主動性

（3）組織主動性

（4）項目財務分析報告

（5）財務能力

（6）項目預計成本

3.項目選擇活動的流程

任何組織機構，在尋求一個特定項目實施之前，需要從解決組織問題的實用性角度，評估項目的需求和價值。一旦組織相信該項目具有較強的實用性，就開始考慮這個項目的費用。對于IT項目，不同的評估技術，如COCOMO（構造性成本模型）、功能點分析等，都會被使用。在尋求IT解決方案時，企業會先組織一部分擅長估算的IT人員，基于以往項目的詳細評估資料，對當前項目做出一個大概的估計。

在粗略估計IT解決方案的成本后，組織需要計算從項目中獲得的經濟效益。在此之上，當組織認可其收益，它會檢查資金儲備以便開始實施該解決方案。如果它可以確保有足夠的資金來滿足開發費用，組織會把實施IT解決方案的任務作為一個成熟項目。否則，組織會出于經濟問題的考慮，放棄這個開發項目的計劃。

上述項目選擇的過程可以用一個流程圖表示，如下圖所示

圖1 項目過程的框架

4.項目選擇過程的系統動力學模型

根據上文中列出的影響項目選擇活動的顯著變量，這些變量之間不同的因果關系也可以被確定，從而建立了SD因果循環模型。

當某一產品或服務有良好的市場需求或實用價值，用戶和開發單位有足夠的資金來源，并且對項目有興趣時，就會進行產品或服務的開發。鑒于此，從“項目的需求/價值”和“財力”這兩個變量關系分別連接到變量“組織主動”和“用戶主動性”的因果關系，可以被視為積極的因果關系。而用戶和開發組織積極性越高，選擇這個項目的機會就越大。因此，連接“組織主動”和“用戶主動”這兩個變量的對于“項目選擇”的因果關系也是積極的。“項目的需求/價值”和“用戶主動”兩個變量間積極相互的因果關系，則形成一個積極的因果反饋循環。

如果初步的項目估計成本更高，項目開發組織和用戶可能會對這個項目失去信心。因此，的“項目預計成本”與“組織主動性”和“用戶主動性”之間的因果關系是消極的。項目財務分析報告確認收益、利潤，以及計劃項目中除去開發成本的其他預期效益。如果預計成本更高，則會對項目的項目財務分析報告有負面影響，選擇項目的可能性就會降低。因此，“項目預計成本”與“項目財務分析報告”的因果關系是負面的。如果有更詳細和樂觀的項目財務分析報告，將會吸引開發組織的關注和提升選擇該項目的機會。因此，“項目財務分析報告”與“組織主動性”和“選擇項目”兩個變量是積極的因果關系。

項目選擇的SD模型已經建立了上述各種因果關系以及因果反饋回路，模型的整體結構顯示在圖2。

5.結論

項目管理的成功始于對一個項目的正確選擇，因此項目選擇是項目管理中一個重要的基本步驟。本文通過對有助于選擇正確項目的重大問題收集信息，共識別六個主要因素——項目的需求和價值，用戶主動性，組織主動性，項目財務分析報告，財務有力和項目預計成本。并運用SD方法來描述這些問題中兩兩相互影響的類型，繪制出SD影響圖。影響圖的框架清楚展示了循序漸進的項目選擇過程，以及因素之間的相互作用。

未來的研究方向是面向某一特定的IT組織的實際項目選擇過程開發SD存量-流量模型，并在一定時間范圍內進行模型的驗證。

參考文獻：

[1]Boyer C （2003）， “Make Profit Your Priority”， PM Network， Vol. 15， No. 10，pp. 37-42

[2]Gray C F， Larson E W and Desai G V （2010）， Project Management： The Managerial Process， 4th Edition， Tata McGraw Hill， New Delhi

[3]Meredith J R and Mantel S J Jr. （2003）， Project Management： A Managerial Approach， 5th Edition， John Wiley & Sons， USA

[4]張波、虞朝暉等.系統動力學簡介及其相關軟件綜述[J]環境與可持續發展 ， 2010，（02）

[5]寧曉倩. 基于系統動力學的軟件開發項目管理[D].復旦大學 2004

[6]王宇靜. 系統動力學在項目管理中的應用研究綜述與展望[J].科技與管理，2013，（01）

作者簡介：

汪俊華（1986-），男，湖北省孝感市，碩士。研究方向：信息管理與信息系統，工程數字化。

高尚建（1984-），男，山東省菏澤市，學士。研究方向：工程數字化信息系統管理。

it項目管理范文第5篇

[關鍵詞] 掙值法；IT項目管理；人工時

doi ： 10 . 3969 / j . issn . 1673 - 0194 . 2015 . 17. 022

[中圖分類號] F272.7 [文獻標識碼] A [文章編號] 1673 - 0194（2015）17- 0045- 06

1 概 述

隨著第三次工業革命的到來，信息技術時代，特別是計算機網絡的發展，信息技術已經越來越多地進入了我們日常的工作和生活。基于計算機網絡技術，企業數據的共享和流程管理已逐漸成為可能。而因此，信息化技術（IT，Information Technology）的應用正越來越為企業所關注，并逐漸成為企業提高工作效率、促進管理水平的有效手段。

從簡單的辦公自動化（OA，Office Automatic）系統，到復雜的企業資源計劃（ERP，Enterprise Resource Planning），供應鏈管理（SCM，Supply Chain Management），客戶關系管理（CRM，Customer Relationship Management），產品生命周期管理（PLM，Product Lifecycle Management），制造執行系統（MES，Manufacture Execution System），各類不同的企業都在尋找適合自己的IT解決方案，或為了消除業務過程中的瓶頸，或為了將業務流程再造（BPR，Business Process Reengineering）的結果通過系統固化，抑或只是為了追趕潮流而不至于落后。

幾年前，當ERP方興未艾的時候，業內有一種說法流傳甚廣：“不上ERP是等死，上了ERP是找死”。這雖然只是句玩笑，但也折射出一個現象：IT項目實施難度大，成功率不高。對于一些復雜IT系統的實施，大家普遍比較認同的一種觀點是：三分軟件，七分實施。如何將一個成熟的軟件系統，根據客戶的需求和業務現狀，以客戶可以接受的方法和程度進行實施，并發揮效用，是每個IT項目經理面臨的難題。這里面也包含很多方面和方法，PMBOK將項目管理的知識領域和過程組分析得非常清晰，項目經理也常常將溝通交流、范圍控制、成本管理、變更控制放在案頭與心中，但考慮得多了又往往千頭萬緒，不知從何下手。

近幾年，掙值分析法正逐漸進入國內各個項目管理公司和IT項目經理的視線，為行業發展指出了方向。掙值法作為一種綜合的偏差管理方法，可以綜合地考慮項目的范圍、時間、成本和質量的整體狀況，量化地分析計劃各指標與實際指標之間的差異，以便項目經理來確認是否可控可接受。掙值法起源于大型的國防、能源、建設項目，所以根據項目的規模和類型，其適用性也不盡相同。由于IT項目普遍規模和周期較小，往往并不具備獨立的項目管理辦公室來進行大量數據的收集和分析，主要的分析工作都集中在項目經理個人手中進行，因此使用和評價都各有千秋。在本文中，我們將就實際的項目為例，使用掙值法進行相關的嘗試性分析。通常，IT項目有諸多種類，例如純軟件開發項目、系統實施項目、純咨詢項目等。在文中，我們所涉及的項目將主要針對于系統實施項目展開。

2 掙值法在IT項目管理中的應用

掙值分析法是一種能全面衡量項目進度狀態、成本趨勢的科學方法，其基本要素是用貨幣量代替實物量來測量項目的進度，它不以項目投入資金的多少來反映項目的進展，而是以投入資金已經轉化為項目成果的量來衡量，是一種完整和有效的項目監控方法。掙值分析通過將時間與成本綜合考慮的方法來確定項目執行的健康程度，將多維度的考核標準統一到一個維度，從而進行綜合的評價。這種方法可以幫助我們直觀地了解項目的狀態，并預計其未來的走勢。

然而，對于一般的系統實施項目經理，由于項目規模相對較小，并行開展項目較多，包括工資、差旅、設備折舊等成本并不會特別計入項目成本，而是作為日常成本攤入多個項目。而對于成本的直接考核往往借助于人天數。人天數是一個成本指數，當給一個人天數賦予單價，就可以方便地核算出人員投入方面的成本，而如果這個成本占項目成本比例非常高的話，這種核算方法就非常合理了。值得一提的是，人天數也是成本直接相關的一項指標，其直接關系到工資、差旅等成本，因此此考核方式是比較科學的。

系統實施項目就是這個情況，項目下達時通常會給項目經理一個人天數的指標，并規定項目的進行需要在人天數的指標之內完成；通常，項目超出10%的指標需要部門經理批準，超出20%就需要公司高管批準，而超出30%則即可視為項目責任事故。因此，項目經理往往對于人天數給予了高度的重視。

在一些情況下，由于項目開始階段客戶的準備不到位，部分項目組成員不需要到現場工作，從項目人天數的統計會發現人天數小于計劃的情況，但往往在這種情況下，由于項目此時的進度嚴重延后，項目的健康度很低。通常，由于部分成員從其他項目中能夠空閑出來，而大量投入本項目的實施，人天數統計有時會超出計劃，而在這種情況下，由于團隊集中工作，提高了溝通效率，反而可以事半功倍，將項目的進度提前。在這兩種情況下，普通的時間進度計劃和人天數統計表體現的數據可能無法直觀地體現項目的健康度，項目經理必須具備全面的經驗才能發現其中的奧妙，而掙值分析法則可以很好地彌補這兩個參數的不足，更直觀且準確地分析項目的執行情況和健康度。同時，通過人天數這一指標來反映成本，也簡化了分類統計成本的復雜度，對項目經理來說也非常易于統計和操作。

2.1 掙值法基本知識

掙值（EV，Earned Value）是為項目管理而發明的一個中間指標，表示實際完成的工作所對應的預算成本，從而在計劃和實際之間建立了一個衡量的橋梁。通過用成本指標來表示每個項目任務的價值，綜合反映時間、資源、成本等多方面因素的影響。

掙值管理中用到的主要指標包括：

?BCWS（Budget Cost for Work Scheduled）表示計劃的任務對應的預算成本，也叫PV（Plan Value）。

?ACWP（Actual Cost for Work Performed）表示實際完成的任務對應的實際成本，也叫AC（Actuel Cost）。

?BCWP（Bugedt Cost for Work Performed）表示實際完成的任務對應的預算成本，就是掙值，EV（Earned Value）。

?成本偏差：CV=BCWP-ACWP，就是實際完成的任務，比較預算成本和實際成本之差。

?進度偏差：SV=BCWP-BCWS，就是預算成本，比較實際完成的任務和計劃中應完成的任務。

?成本績效指數：CPI=BCWP/ACWP，就是已完成工作預算成本/已完成工作實際成本。

?進度績效指數：SPI=BCWP/BCWS，就是已完工程預算成本/計劃完成工作預算成本。

關于兩個偏差（CV，SV）和兩個指數（CPI，SPI）的值所代表的含義，可以簡單地用表1說明。

2.2 項目背景

某電子研究所是國家一類研究所。隨著業務的快速發展，原有的管理機制無法滿足所管理層對企業的管理要求，在項目研發階段管理、電子資料管理、研發過程規范化管理等方面都提出了更高的要求。因此，研究所在2006年，引進Teamcenter Enterprise 2.0 構建產品數據管理信息環境，并引進Teamcenter Project 3.2構建項目管理平臺，為產品研發過程的管控提供3個方面的解決方案：

（1）為產品電子數據提供管控和利用手段，改變沿用人工紙質化管理電子化產品數據的不對稱現狀。

（2）為產品設計過程搭建可視化協同和管理平臺，消除專業系統所形成的信息孤島，為產品實現過程的數據流提供透明的集成環境。

（3）為質量管理體系運行提供基于流程控制的支持環境，實現技術狀態演變過程的實時簿記和可追溯性。

PDM一期的實施讓企業看到了PDM強大的功能，及其在企業研發過程中的重要作用，管理層認為推進PDM實施是企業實現研發過程電子化管理的可行道路，也期望看到更多的成果和更好的推廣。因此研究所產生了PDM進一步實施的要求，要求在深度和廣度上都有所提高。

在系統實施深度方面，希望通過進一步完善功能，利用先進的IT技術，解決易用性的問題，無論從界面和操作上都能夠簡化，提高用戶對系統的接受程度；同時，通過引入新的模塊，實現更高層次的電子化管理。在實施廣度方面，研究所希望將PDM系統從原來的試點項目推廣到全所級的運用，將所有的研發過程均納入系統管理，真正意義上實現電子化管理。

2.3 項目計劃

根據項目前期調研了解的用戶期望，和對現狀的把握，明確了二期項目的實施范圍。基于工作內容和工作范圍制定了項目的時間進度和人力資源投入計劃。

本計劃依據實施方法學的原則，詳細規定了在實施過程中應當完成的每一項任務及其分解，并規定了這些任務所對應的交付內容。在項目計劃中還規定了用于控制PDM系統實施品質的質量檢驗點，項目實施中的決策人員將在每個里程碑檢驗質量檢驗點的關鍵交付內容，以決定項目是繼續進行還是應當延期以等待條件的成熟與完善。

2.4 掙值法進度分析

在項目的實際執行過程中，項目組通過周計劃、周報告的方式詳細記錄了每周項目的執行情況，包括任務執行進度、人力資源投入、項目問題及處理以及項目風險記錄。通過這些原始信息的積累，我們可以對項目的進度情況進行掙值分析。其中，以人天數為項目成本統計量。

2.4.1 項目第二個質量檢驗點：系統設計結束

根據項目計劃，系統設計完成日期為2010年4月14日，計劃的人天數是90。

根據項目組記錄，系統設計完成日期是在2010年4月28日，統計的項目人天數是132。

因此，在2010年4月28日當天，

計劃工作的預算費用：BCWS=PV= 100人天

已完成工作實際成本：ACWP=AC= 132人天

已完成工作的預算成本：BCWP=EV= 90人天

可以導出：

費用偏差：CV=EV-AC= 90-132= -42人天

CV

進度偏差：SV=EV-PV= 90-100= -10人天

SV

費用績效指數：CPI=EV/AC=90/132=0.68

CPI

進度績效指數：SPI=EV/PV=90/100=0.9

SPI

進一步分析：

假定完工預算：BAC=281人天

剩余成本：ETC=（BAC-EV）/CPI=（281-90）/0.68=280人天

總成本：EAC=ETC+AC=280+132=412人天

成本偏差：VAC=EAC-BAC=412-281=131人天

結果分析：

該項目進行到這一里程碑時，進度略有滯后，而投入人天超支較嚴重，如果繼續執行下去，人天數將超額131/281=47%>30%，將會成為嚴重項目責任事故，因此項目組必須予以高度關注。

而分析原因，由于項目執行初期在需求確認過程中，用戶部分之間發生分歧，導致評審周期變長，項目組整體待工。而由于多次評審會的需要，項目組調動了各個相關領域的資深顧問參與，導致項目人天投入也嚴重超支。

后續計劃將加緊開發過程的進度，爭取在計劃上能有所超前。同時，由于需求確認較充分，因此期望后期在用戶接受測試和用戶評審階段可以加快周期。

2.4.2 項目第三個質量檢驗點：開發結束

根據項目計劃，開發結束完成日期為2010年6月16日，計劃的人天數是225。

根據項目組記錄，開發結束完成日期是在2010年6月23日，統計的項目人天是268人天。

因此，在2010年6月23日當天，

計劃工作的預算費用：BCWS=PV= 230人天

已完成工作實際成本：ACWP=AC= 268人天

已完成工作的預算成本：BCWP=EV= 225人天

可以導出：

費用偏差：CV=EV-AC=225-268= -43人天

CV

進度偏差：SV=EV-PV= 225-230= -5人天

SV

費用績效指數：CPI=EV/AC=225/268=0.84

CPI

進度績效指數：SPI=EV/PV=225/230=0.98

SPI

進一步分析：

假定完工預算：BAC=281人天

剩余成本：ETC=（BAC-EV）/CPI=（281-225）/0.84=67人天

總成本：EAC=ETC+AC=67+268=335人天

成本偏差：VAC=EAC-BAC=335-281=54人天

結果分析：

該項目進行到第三個里程碑時，進度略有滯后只有5個工作日，而投入人天超支情況有所改善。如果照此趨勢，人天數將超額54/281=19%>10%，仍然需要上報公司高管批準，因此項目組仍然需要關注項目執行情況。

而分析原因，由于開發過程基本由乙方完成，在需求和規格定義明確的情況下，執行基本受控，同時考慮到前期的滯后，還有所趕工，因此時間進度得以部分趕前。

后續計劃仍將盡快趕上進度，特別是在人天投入方面，將考慮多利用用戶方項目組團隊成員參與最終用戶培訓，以減少乙方人員的投入。

2.4.3 項目第四個質量檢驗點：用戶認可

根據項目計劃，用戶認可完成日期為2010年6月30日，計劃的人天數是255。

根據項目組記錄，用戶認可完成日期是在2010年7月7日，統計的項目人天是288人天。

因此，在2010年7月7日當天，

計劃工作的預算費用：BCWS=PV= 275人天

已完成工作實際成本：ACWP=AC= 288人天

已完成工作的預算成本：BCWP=EV= 255人天

可以導出：

費用偏差：CV=EV-AC=255-288= -33人天

CV

進度偏差：SV=EV-PV= 255-275= -20人天

SV

費用績效指數：CPI=EV/AC=255/288=0.86

CPI

進度績效指數：SPI=EV/PV=255/275=0.93

SPI

進一步分析：

假定完工預算：BAC=281人天

剩余成本：ETC=（BAC-EV）/CPI=（281-255）/0.86=30人天

總成本：EAC=ETC+AC=30+288=318人天

成本偏差：VAC=EAC-BAC=318-281=37人天

結果分析：

該項目進行到第四個里程碑時，進度略有滯后只有20個人天，投入人天超支情況又有所改善。照此趨勢，人天數將超額37/281=13%

而分析原因，在文檔編寫和最終用戶培訓中，盡量調用了甲方項目團隊的工作能力，因此節省了部分的人天，使項目健康度又有所改善。后續計劃則將考慮系統配置工作能做好充分準備，盡量減少現場問題和現場人天。同時將數據遷移工作同步進行，并調動甲方團隊的積極性，以期能趕上項目計劃人天和資源投入。

2.4.4 趨勢分析

整理以上的數據可以得到關于PV、AC、EV的數據表，見表3。

繪制曲線如圖1所示。

從圖中我們可以直觀地看到成本偏差與進度偏差，也能看到偏差變化的趨勢，特別是AC將接近于PV的趨勢。如果我們能在項目執行過程中增加一些監控點的話，該趨勢的表現將更加細致和直觀，對項目進度和成本（人天）的監控也是非常有益的。

3 結 語

本文嘗試以掙值分析法監控和分析IT項目實施過程中的項目執行情況和健康度，并以某項目實施案例為例予以分析說明。文中將項目成本中的費用替換成了人天數，對于部分以人天投入為主的項目實施，此類嘗試已被證明是具有實用價值的。在文中，我們指出了掙值分析法在IT項目管理中分析項目進展情況并預計今后發展趨勢的有效性，該方法可以指導項目經理人在項目過程中采取相應的策略、預見風險、以及減少項目的超期和超支。

最后，我們將掙值分析法在IT項目管理中的作用總結如下：

（1）幫助項目經理及早地發現項目可能出現的風險和問題，以采取應對措施規避風險。

（2）通過簡單的數據積累和分析，提供量化的項目實時診斷信息，使診斷更準確。

（3）便于向管理層和項目監督小組做匯報，通過數據和圖表的方式，更具說服力。

掙值分析法目前在國內IT項目管理中的應用尚不普遍。然而，我們相信經過一些改良，該方法可以在占用項目經理相對較小的工作量的前提下，利用項目組原先積累的數據就能夠對項目進程作出相對準確和可靠的分析，其應用前景是非常值得肯定與期待的。

主要參考文獻

[1][美]項目管理協會.項目管理知識體系指南[M].第4版.王勇，張斌，譯.北京：電子工業出版社，2009.

[2]毛婧穎.掙值法研究現狀及展望[J] .項目管理技術，2010，8（2）：19-23.

[3]蔣國瑞，等.IT項目管理[M].北京：電子工業出版社，2006.

[4]Fleming Quentin.Joel Koppelman. Earned Value Project Management[M].Third Edition. USA：Project Management Institute，2005.

[5]Barry W Boehm.軟件工程經濟學[M].李師賢，譯.北京：機械工業出版社，2004.

[6]Capers Jones.Determining Software Schedules[J].Computer， 1995，28（2）：73-75.