第一篇：信息系統項目管理師論文寫作技巧

信息系統項目管理師論文寫作技巧

1.大綱中的要求

《信息系統項目管理師考試大綱》中，要求考生根據試卷上給出的四個有關項目管理的論文題目，選擇其中的一個，按規定的要求寫論文和摘要。論文可能涉及的內容極其廣泛，主要有信息系統項目管理，信息安全，信息系統項目監理，信息化戰略與實施，大型、復雜和多項目的管理，項目績效考核和績效管理6個主要模塊的論題方向，這6個方向又分為若干個子內容。

2005年上半年的考試雖然只出了一道論文題目——“論信息系統項目的需求管理和范圍管理”，似乎與考試大綱有所背離，但考試內容并沒有偏離大綱，屬于“信息系統項目管理”方向中的內容。所以作論文考試的準備時一定要緊緊圍繞考試大綱來進行。

歷屆高級資格考試論文寫作一般會有如下的要求：

簡述你所從事的項目及你在項目中擔任的角色；

在項目中關于論題方向碰到的問題和解決對策；

對項目實話的總結和展望。

2.為什么會覺得論文考試難

參加項目管理師的考生大致有兩種類型：在校學生和在職人員。

對于在校的學生來說，參加項目管理師這一高級別的考試無異于一種挑戰。這是因為：

缺乏項目實戰經驗；

沒有從事過項目管理；

學業繁重，沒有時間來準備考試；

考試范圍太廣，許多的知識沒有接觸過；

技術方面掌握不扎實，基礎不牢；

沒有寫過學術論文。

大學里的計算機專業或信息管理專業都會開設軟件工程課程，也有少數的院校開設項目管理課程，即便是有，考生自己也會感覺只有理論知識沒有實踐經驗，總覺得心里不踏實，寫出來的文章會不夠力度。大多數的研究生也只是跟隨導師做一些技術性的工作，項目管理方面的工作做得較少。其它專業的學生當然會覺得難度更大。

對于在職人員來說，可能存在以下困難：

有項目經驗但要寫成論文覺得寫作水平有限；

長期從事某一個方面的工作，很少從事項目管理這種綜合性的工作；

從事技術性工作或研究工作，熱衷于技術實現，管理工作做得較少；

工作任務過重，無暇復習及攥寫論文。

對于這兩類考生，又以在職人員居多。要想考試過關，一是要盡量從繁忙的學習和工作中抽出時間來應考；二是要熟悉考試論文的寫作格式及注意事項；三是掌握一定的論文寫作技巧；四是需要閱讀大量的資料來充電，五是在考試之前作適當的練習。當然如果您項目經驗十分豐富，可以把重點放在鍛煉寫作技巧上來。

3.論文的格式與寫作技巧

3.1格式要求

項目管理師考試的論文不同于要放在學術雜志上發表的學術論文，也不同于學生的畢業論文，她主要是對自己工作經驗的總結，更象一份述職報告，因此在格式上的要求也比較簡單。

論文的內容分為兩部分：摘要和正文。這兩部分的書寫要注意以下的格式：

達到字數要求。摘要一般要求200字以上，500字以下，正文要求2500字以上。在論文寫作的方格紙上會有字數提醒。

不要在論文中書畫圖形，盡量用文字表述。

盡量保持卷面清潔，如果實現需要劃掉文字，在字上劃一橫線即可。

不必寫關鍵詞。

3.2 寫作進度把握

論文的寫作時間只有兩個小時，要在短短的兩個小時里寫出一篇高質量的論文確屬不易，需要考生有較為豐富的理論和實踐知識的積累，當然也不必害怕，因為這還是有章可循的。這里建議的時間分配如下：

通讀論題，選定論題（5分鐘）；

構思論文，寫論文提綱（10分鐘）； 正文寫作（80分鐘）；

摘要寫作（15分鐘）；

復查論文（10分鐘）。

論文的摘要由于在論文的寫作過程中論文的論點及內容可能會有所變化，建議在寫作完正文后再寫摘要。下面按寫作步驟詳細解說。

3.3 論文選題

拿到試卷后，先把試題快速通覽，找到自己最容易發揮，最擅長的方向的論題。為了照顧大多數考生的情況，論文題目會比較寬泛。

需要注意的一點是，既然是考項目管理師，論文內容當然不會關心過多的技術細節問題，重在項目管理。

選題時要考慮應和什么項目相關聯。文章至少要與一個項目關聯起來。那么如何選定項目呢？

在校的學生由于沒有項目經驗，往往不知論文應與什么項目關聯為好。一是要看題目要求，如今年5月考試的論文題目中就明確指出要是參與管理過的大型信息系統項目，因此一般不要以如“學生成績管理信息系統”這種課程設計性質的項目來寫；二是盡量寫自己熟悉的，如一般的可寫高校人事MIS，高校教務MIS等，在職人員也可如此考慮。項目可以是虛構的，不需要指明開發單位，委托單位；三是如果有大型項目或可以構思出大型項目則更佳。

3.4 論文提綱

選定論題后不要急于動筆直接在答題紙（論文的答題紙為方格作文紙）上寫作。因為直接寫作很難有一個整體的思路，而且在寫作的過程中可能會涂改而使得卷面不整潔，影響評卷人的心理。不提倡在草稿紙上書寫論文再抄至論文答題紙上，因為考試的時間本就十分有限，抄寫論文的時間也需不少。不妨先花點時間理理寫作的思路，在草稿紙上寫作論文的提綱，所謂“磨刀不誤砍柴工”。

提綱中寫些什么內容呢？可有如下的內容；

擬聯系寫作的項目，思考如何聯系此項目來寫作；

擬寫論文的主要論點。

各段落的主要內容，如果直接以論點來分段就不必再寫此項了。

論文的閱卷者一般會把論文看兩遍，第一遍快速瀏覽全文的論點，以找出文章的“文眼”，第二遍再仔細閱讀。如果論點清晰，會給閱卷者以清晰明朗的感覺。

3.5 正文寫作

有了提綱了，寫正文就輕松多了。正文可采用“總——分——總”式，即文章開頭提出中心思想，再分述論點，最后在結尾處作出總結；也可用“提出問題——分析問題——解決問題”的逐步深入的方法。寫作時注意以下幾個方面：

理論聯系實際，一定要與項目關聯起來討論，切忌空談理論；

可以分條敘述的方式，但不要全文用此方式；

論點清晰，最好每段在開頭處或結尾處點明論點；

結尾處要對項目的實施情況，以及應用論點論據應用情況作出總結。

不必列舉過多的計算公式。

文章要帶有一定的學術性，更多的應是談項目經驗。

不要關注于技術，多就論題寫管理方面的問題及采取的措施。

第1樓 pmonly

2006-4-30 8:32:18 3.6 摘要寫作

摘要可按如下幾個方面來寫：

項目概述，包括自己主持或參與的項目及自己擔任的角色。

論文的主要論點。

為方便大家書寫摘要，這里給出兩個摘要的書寫模板。

模板一：（論點——項目概述）

本文以我主持（或參與）的××××××（項目名稱）為實例，探討了××××××（論文論題），認為××××××（論點）。在此項目中，我擔任了××××××（角色），參與了××××××（任務），實施后×××××（用論文中的方法實施后的效果）。

模板二：（項目概述——論點）

×××××（項目名稱）是×××××（項目說明），在此項目中，我擔任了×××××（角色），參與了×××××（任務）。對于項目的×××××（論題），本文認為×××××（論點）。該項目實施后×××××（用論文中的方法實施后的效果）。

下面給出模板一的一個實例，以供參考：（論信息系統項目的需求管理和范圍管理）

本文以我主持的某商業銀行網上銀行系統項目為實例，探討了作為開發方公司在信息系統項目的需求管理和范圍管理方面碰到的問題及解決的辦法，文章首先解釋了需求管理和范圍管理的基本概念，認為需求工作做得不扎實，項目范圍把控不好是導致項目難以成功的主要原因，提出應以CMM過程改進的思想指導項目的需求管理和范圍管理，項目在需求分析階段應確定需求可以決策的人，充分和客戶溝通以正確把握需求，對于需求和開發范圍的變更管理提出了解決的辦法。我在該項目中擔任了開發方的項目經理，自始至終參與了整個項目的建設，自2004年4月項目啟動至2004年12驗收歷時8個月，系統至今運行穩定，取得客戶的好評，很大程度上得益于項目成功的需求管理和范圍管理。

4.論文考題分析

我們來把考試大綱的內容與歷年的軟件資格與水平考試高級（包括系統分析師和項目管理師）相關的考試論文題目列舉出如下表所示，也許您會有所啟迪。

表1 歷年軟件資格和水平考試高級考試與考試大綱相關的論文題

模塊方向

子內容

歷年考題

考試年份

信息系統項目管理 項目選擇

可行性分析 論信息管理系統的可行性研究 1997年

項目生命周期流程管理

項目的整體、范圍、進度、成本、質量、人力資源、溝通、風險和采購管理 論軟件開發的質量管理 1989年

成本/效益分析 1990年

論軟件項目的質量保證 1993年

論項目管理工具的選用 1998年

論軟件質量保證 2002年

論軟件開發的風險控制 2003年

論軟件開發成本管理 2004年上半年

論應用軟件開發范圍和功能的確定 2004年下半年

論項目管理中的進度控制 2005年上半年

論信息系統項目的需求管理和范圍管理 2005年上半年項目管理師

項目評估

企業級信息系統項目管理體系的建立

項目中的質量管理與企業質量管理異同分析 論軟件開發的質量管理 1989年

論軟件項目的質量保證 1993年

論軟件質量保證 2002年

信息安全 信息安全體系 系統的安全與保密控制 1992年

信息安全體系的安全風險評估

企業信息安全策略 論企業信息系統的安全 2005年上半年

論企業內部網的安全策略 2004年下半年

信息系統工程監理 監理的方法與工作流程

監理的機構及監理工程師

監理中的質量、投資、進度和變更控制

監理中的合同管理、信息管理和安全管理

監理中的組織協調

信息化戰略與實施

企業建設信息化系統的過程

信息化系統建設過程中常見問題

新技術對信息化建設的影響

CIO在信息化建設過程中的作用

信息化規劃

不同類型信息化建設過程中的差異

電子政務建設 論電子政務信息共享整合 2005年上半年

企業自身管理成熟度對企業信息化建設的影響

大型、復雜信息系統項目和多項目的管理 計劃過程

跟蹤和控制過程

范圍管理 論應用軟件開發范圍和功能的確定 2004年下半年

論信息系統項目的需求管理和范圍管理 2005年上半年項目管理師

資源管理

協作管理

項目績效考核與績效管理 團隊績效與項目績效的關系

績效評估的方法

項目績效指標設計

績效改進

從上面的表格中可以看出，還沒有出過題目的內容極可能會成為下次考試出題的對象，“信息系統項目管理”模塊中的“項目的整體、范圍、進度、成本、質量、人力資源、溝通、風險和采購管理”是近四年的高級考試中必出論文考題的內容。據此，作者列出19個考題供大家參考和練習（每個模塊3~4個）：

信息系統項目管理

論項目團隊建設

論項目溝通管理

論企業信息系統項目管理體系的建立

論項目采購管理與合同管理

信息安全 論企業的信息系統安全體系

論企業信息系統的安全控制策略

論企業信息系統安全風險的評估

信息系統工程監理

論信息系統項目的工程監理

論信息系統工程監理中的質量控制

論信息系統工程監理中的進度控制

信息化戰略與實施

論企業信息化的規劃

論電子政務項目管理

論企業信息化的建設

論信息系統項目計劃的制訂

論信息系統項目資源管理

論信息系統的跟蹤與控制

項目績效考核與績效管理

論項目績效評估的方法與策略

論企業信息化中的績效評價機制

論信息系統項目績效指標的設計

5.如何準備論文

可以從以下幾個方面著手準備論文：

看別人寫的項目經驗文章，這是快速彌補經驗不足的辦法。以下的網站可以找到不少的資料：http://www.tmdps.cn（中國項目管理信息網）等。如果可以看到一些項目的實施方案書則提高實踐經驗更快。

介紹幾本好書。如果時間充足（先看《項目管理師輔導教程》），您可以參考以下幾本書籍：

《IT項目管理》（美）凱西.施瓦樂貝著 機械工業出版社；

《企業信息化行動綱領——中國企業信息化方法論》 吳文釗著 機械工業出版社；

《軟件開發項目管理》 韓萬江 姜立新著 機械工業出版社；

《企業信息化總體設計》 李清 陳禹六著 清華大學出版社；

《領跑企業信息化CIO工作手冊》 汪牧清 夏敬華 聞博著 電子工業出版社；

《信息化績效評價框架、實施與安例分析》 郝曉玲 孫強著 清華大學出版社。

一定要在考試前動手寫幾篇論文。可就前面提供的6個方面的論文題目去找幾個自己感興趣的，多準備幾篇，最好能有6篇，不必每個方向都寫，6個方向選其中的2——3個即可。寫完以后，最好能在身邊找一位專家幫你批改論文，寫作水平會迅速提高。

多與項目管理經驗豐富的人員聊天談項目實施的感受，談項目管理的點點滴滴，得到一些書本上不能得到的知識。

第2樓 pmonly

2006-4-30 8:33:25 以下內容是我自己在考試后總結而出的。

關于考試論文寫作的一些看法

第一，選題：對于咱們的考試來說，不是每個人都對每個方面很熟悉的，因此，選擇題目一定要選擇自己很熟悉的領域的題目。同時，選題目的時候也要注意自己對教材各大知識要點的掌握程度，選擇掌握的越熟練的越容易寫作。

第二，摘要，我看了2005年上半年的題目和下半年的題目，都有一個共同點，摘要可以引用論文題目下面的部分說明，同時，在摘要重要體現出論文所要寫的內容、研究的方法、以及論文所要表達的結論。通常用200字左右，不要超過300字為最佳。

第三，正文部分：

1、由于論文是要求要結合自己親歷的項目結合起來寫，因此正文部分首先需要對項目進行一定的描述，稱為項目概述；其次要在項目概述中點明選題立意的原因，這部分大概占用最少150字，最多不要超過300字。

2、對相關理論、概念進行界定定義，（既要有通用的定義，還要結合項目的特征進行。）對于所寫項目中的問題的定義和界定

3、對問題進行分析，導致問題的原因，現狀等

第四，總結綜述：也就是論文的結論，解決前面提出的問題的措施、技術方案等

需要注意的問題是：

1、在我們的考試中，論文的寫作一般采用的研究方法是實證法、比較法、案例法，這些方法不需要明著說出來，在摘要中體現出來即可。

2、論文的寫作必須每個部分要圍繞一定的主題展開

3、論文的寫作既要結合項目經歷，也要圍繞教材中的知識要點來展開。

4、千萬注意，不要弄錯邏輯順序

5、突出重點，重點突出某一個問題和比較新穎的解決方法，不需要對每個問題都進行深入展開，以期突出重點。

6、對于缺少項目經驗的朋友來說，其實也不算難事，只要在自己的某一具體工作中能夠與教材中所講述得知識進行對比融合，也是可以寫出來的。比如建設一個網站。未必一定非要自己參與過大項目才能寫。咱們的論文考試其實是為了檢查綜合運用的能力以及對知識的掌握層度。

7、選題后最好有一個大概的提綱。

8、論文寫作總共只有2小時，因此，從選題到提綱完成不要超過半小時，否則，就很難寫完整。

9、摘要可以放在最后寫，如果打算把摘要放在最后寫的朋友，一定要注意，摘要的完成最少需要20-30分鐘。不管你的正文部分最后寫的怎么樣，時間如果只剩了20-30分鐘的時候就要趕緊對論文收尾。才能來得及把摘要寫出來。

第二篇：信息系統項目管理師論文

項目管理師論文寫作指南

1.大綱中的要求

《信息系統項目管理師考試大綱》中，要求考生根據試卷上給出的四個有關項目管理的論文題目，選擇其中的一個，按規定的要求寫論文和摘要。論文可能涉及的內容極其廣泛，主要有信息系統項目管理，信息安全，信息系統項目監理，信息化戰略與實施，大型、復雜和多項目的管理，項目績效考核和績效管理6個主要模塊的論題方向，這6個方向又分為若干個子內容。

歷屆高級資格考試論文寫作一般會有如下的要求：

簡述你所從事的項目及你在項目中擔任的角色；

在項目中關于論題方向碰到的問題和解決對策；

對項目實話的總結和展望。

2.為什么會覺得論文考試難

對于在職人員來說，可能存在以下困難：

有項目經驗但要寫成論文覺得寫作水平有限；

長期從事某一個方面的工作，很少從事項目管理這種綜合性的工作；

從事技術性工作或研究工作，熱衷于技術實現，管理工作做得較少；

工作任務過重，無暇復習及攥寫論文。

要想考試過關，一是要盡量從繁忙的學習和工作中抽出時間來應考；二是要熟悉考試論文的寫作格式及注意事項；三是掌握一定的論文寫作技巧；四是需要閱讀大量的資料來充電，五是在考試之前作適當的練習。當然如果您項目經驗十分豐富，可以把重點放在鍛煉寫作技巧上來。

3.論文的格式與寫作技巧

3.1 格式要求

項目管理師考試的論文不同于要放在學術雜志上發表的學術論文，也不同于學生的畢業論文，她主要是對自己工作經驗的總結，更象一份述職報告，因此在格式上的要求也比較簡單。

論文的內容分為兩部分：摘要和正文。這兩部分的書寫要注意以下的格式：

達到字數要求。摘要一般要求200字以上，500字以下，正文要求2500字以上。在論文寫作的方格紙上會有字數提醒。

不要在論文中書畫圖形，盡量用文字表述。

盡量保持卷面清潔，如果實現需要劃掉文字，在字上劃一橫線即可。

不必寫關鍵詞。

3.2 寫作進度把握

論文的寫作時間只有兩個小時，要在短短的兩個小時里寫出一篇高質量的論文確屬不易，需要考生有較為豐富的理論和實踐知識的積累，當然也不必害怕，因為這還是有章可循的。這里建議的時間分配如下：

通讀論題，選定論題（5分鐘）；

構思論文，寫論文提綱（10分鐘）；

摘要寫作（15分鐘）；

正文寫作（80分鐘）

復查論文（10分鐘）。

論文的摘要由于在論文的寫作過程中論文的論點及內容可能會有所變化，建議在寫作完正文后再寫摘要。下面按寫作步驟詳細解說。

3.3 論文選題

拿到試卷后，先把試題快速通覽，找到自己最容易發揮，最擅長的方向的論題。為了照顧大多數考生的情況，論文題目會比較寬泛。

需要注意的一點是，既然是考項目管理師，論文內容當然不會關心過多的技術細節問題，重在項目管理。

選題時要考慮應和什么項目相關聯。文章至少要與一個項目關聯起來。那么如何選定項目呢？

在校的學生由于沒有項目經驗，往往不知論文應與什么項目關聯為好。一是要看題目要求，如今年5月考試的論文題目中就明確指出要是參與管理過的大型信息系統項目，因此一般不要以如“學生成績管理信息系統”這種課程設計性質的項目來寫；二是盡量寫自己熟悉的，如一般的可寫高校人事MIS，高校教務MIS等，在職人員也可如此考慮。項目可以是虛構的，不需要指明開發單位，委托單位；三是如果有大型項目或可以構思出大型項目則更佳。

3.4 論文提綱

選定論題后不要急于動筆直接在答題紙（論文的答題紙為方格作文紙）上寫作。因為直接寫作很難有一個整體的思路，而且在寫作的過程中可能會涂改而使得卷面不整潔，影響評卷人的心理。不提倡在草稿紙上書寫論文再抄至論文答題紙上，因為考試的時間本就十分有限，抄寫論文的時間也需不少。不妨先花點時間理理寫作的思路，在草稿紙上寫作論文的提綱，所謂“磨刀不誤砍柴工”。

提綱中寫些什么內容呢？可有如下的內容；

擬聯系寫作的項目，思考如何聯系此項目來寫作；

擬寫論文的主要論點。

各段落的主要內容，如果直接以論點來分段就不必再寫此項了。

論文的閱卷者一般會把論文看兩遍，第一遍快速瀏覽全文的論點，以找出文章的“文眼”，第二遍再仔細閱讀。如果論點清晰，會給閱卷者以清晰明朗的感覺。

3.5 正文寫作

有了提綱了，寫正文就輕松多了。正文可采用“總——分——總”式，即文章開頭提出中心思想，再分述論點，最后在結尾處作出總結；也可用“提出問題——分析問題——解決問題”的逐步深入的方法。寫作時注意以下幾個方面：

理論聯系實際，一定要與項目關聯起來討論，切忌空談理論；

論點要正確，合乎工程實踐的實際情況；

可以分條敘述的方式，但不要全文用此方式；

論點清晰，最好每段在開頭處或結尾處點明論點；

結尾處要對項目的實施情況，以及應用論點論據應用情況作出總結。

不必列舉過多的計算公式。

文章要帶有一定的學術性，更多的應是談項目經驗。

不要關注于技術，多就論題寫管理方面的問題及采取的措施。

3.6 摘要寫作

摘要可按如下幾個方面來寫：

項目概述，包括自己主持或參與的項目及自己擔任的角色。

論文的主要論點。

為方便大家書寫摘要，這里給出兩個摘要的書寫模板。

模板一：（論點——項目概述）

本文以我主持（或參與）的××××××（項目名稱）為實例，探討了××××××（論文論題），認為××××××（論點）。在此項目中，我擔任了××××××（角色），參與了××××××（任務），實施后×××××（用論文中的方法實施后的效果）。

模板二：（項目概述——論點）

×××××（項目名稱）是×××××（項目說明），在此項目中，我擔任了×××××（角色），參與了×××××（任務）。對于項目的×××××（論題），本文認為×××××（論點）。該項目實施后×××××（用論文中的方法實施后的效果）。

下面給出模板一的一個實例，以供參考：（論信息系統項目的需求管理和范圍管理）

本文以我主持的某商業銀行網上銀行系統項目為實例，探討了作為開發方公司在信息系統項目的需求管理和范圍管理方面碰到的問題及解決的辦法，文章首先解釋了需求管理和范圍管理的基本概念，認為需求工作做得不扎實，項目范圍把控不好是導致項目難以成功的主要原因，提出應以CMM過程改進的思想指導項目的需求管理和范圍管理，項目在需求分析階 段應確定需求可以決策的人，充分和客戶溝通以正確把握需求，對于需求和開發范圍的變更管理提出了解決的辦法。我在該項目中擔任了開發方的項目經理，自始至終參與了整個項目的建設，自2004年4月項目啟動至2004年12驗收歷時8個月，系統至今運行穩定，取得客戶的好評，很大程度上得益于項目成功的需求管理和范圍管理。

4.論文考題分析

我們來把考試大綱的內容與歷年的軟件資格與水平考試高級（包括系統分析師和項目管理師）相關的考試論文題目列舉出如下表所示，也許您會有所啟迪。

表1

歷年軟件資格和水平考試高級考試與考試大綱相關的論文題

模塊方向子內容歷年考題考試年份

信息系統項目管理項目選擇

可行性分析論信息管理系統的可行性研究1997年

項目生命周期流程管理

項目的整體、范圍、進度、成本、質量、人力資源、溝通、風險和采購管理論軟件開發的質量管理1989年

成本/效益分析1990年

論軟件項目的質量保證1993年 論項目管理工具的選用1998年 論軟件質量保證2002年

論軟件開發的風險控制2003年 論軟件開發成本管理2004年上半年

論應用軟件開發范圍和功能的確定2004年下半年 論項目管理中的進度控制2005年上半年

論信息系統項目的需求管理和范圍管理2005年上半年項目管理師 項目評估

企業級信息系統項目管理體系的建立

項目中的質量管理與企業質量管理異同分析論軟件開發的質量管理1989年 論軟件項目的質量保證1993年 論軟件質量保證2002年

信息安全信息安全體系系統的安全與保密控制1992年 信息安全體系的安全風險評估

企業信息安全策略論企業信息系統的安全2005年上半年 論企業內部網的安全策略2004年下半年 信息系統工程監理監理的方法與工作流程

監理的機構及監理工程師

監理中的質量、投資、進度和變更控制

監理中的合同管理、信息管理和安全管理

監理中的組織協調

信息化戰略與實施企業建設信息化系統的過程

信息化系統建設過程中常見問題

新技術對信息化建設的影響

CIO在信息化建設過程中的作用

信息化規劃

不同類型信息化建設過程中的差異

電子政務建設論電子政務信息共享整合2005年上半年 企業自身管理成熟度對企業信息化建設的影響

大型、復雜信息系統項目和多項目的管理計劃過程

跟蹤和控制過程

范圍管理論應用軟件開發范圍和功能的確定2004年下半年

論信息系統項目的需求管理和范圍管理2005年上半年項目管理師 資源管理

協作管理

項目績效考核與績效管理團隊績效與項目績效的關系

績效評估的方法

項目績效指標設計

績效改進

從上面的表格中可以看出，還沒有出過題目的內容極可能會成為下次考試出題的對象，“信息系統項目管理”模塊中的“項目的整體、范圍、進度、成本、質量、人力資源、溝通、風險和采購管理”是近四年的高級考試中必出論文考題的內容。據此，作者列出19個考題供大家參考和練習（每個模塊3~4個）：

l 信息系統項目管理

論項目團隊建設

論項目溝通管理

論企業信息系統項目管理體系的建立

論項目采購管理與合同管理信息安全

論企業的信息系統安全體系

論企業信息系統的安全控制策略

論企業信息系統安全風險的評估【此三項要工作聯系實際】信息系統工程監理

論信息系統項目的工程監理

論信息系統工程監理中的質量控制

論信息系統工程監理中的進度控制信息化戰略與實施

論企業信息化的規劃

論電子政務項目管理

論企業信息化的建設

大型、復雜信息系統項目和多項目的管理

論信息系統項目計劃的制訂

論信息系統項目資源管理

論信息系統的跟蹤與控制【此三項是指導工作實際】項目績效考核與績效管理

論項目績效評估的方法與策略

論企業信息化中的績效評價機制

論信息系統項目績效指標的設

5.如何準備論文

可以從以下幾個方面著手準備論文：

l.看別人寫的項目經驗文章，這是快速彌補經驗不足的辦法。以下的網站可以找到不少的資料：http://www.tmdps.cn（中國項目管理信息網）等。如果可以看到一些項目的實施方案書則提高實踐經驗更快。一定要在考試前動手寫幾篇論文?？删颓懊嫣峁┑?個方面的論文題目去找幾個自己感興趣的，多準備幾篇，最好能有6篇，不必每個方向都寫，6個方向選其中的2——3個即可。寫完以后，最好能在身邊找一位專家幫你批改論文，寫作水平會迅速提高。多與項目管理經驗豐富的人員聊天談項目實施的感受，談項目管理的點點滴滴，得到一些書本上不能得到的知識。

要想通過項目管理師考試，絕非一躇而就，論文寫作較為真實地集中體現了考生的水平和能力。但論文的寫作也是有章可循的，不僅要擠出時間來準備，還要注意論文的寫作格式與寫作技巧，勤于練習，虛心向經驗豐富的同仁請教。

論文實例

1.論文論題

這次一起分析和討論的論題是：“論信息系統項目的整體管理”。題目如下：

項目管理的9大知識領域包括項目的整體、范圍、時間、成本、質量、人力資源、溝通、風險和采購管理，其中項目整體管理包括在項目生命周期中協凋所有其他項目管理知識領域所涉及的過程，它確保項目所有的組成要素在正確的時間結合在一起，以成功地完成項目。

信息系統項目往往比較復雜，經常出現各項目目標之間或參與項目的人員之間的沖突，項目管理人員常常要處理各種沖突，協調為完成一個項目所需的人員、計劃以及工作。

請圍繞“論信息系統項目的整體管理”論題，分別從以下三個方面進行論述：

1、概要敘述你參與管理過的信息系統項目，以及該項目在項目整體管理方面的情況；

2、論述項目整體管理的主要內容及其重要性；

3、詳細論述你參與的信息系統項目整體管理的過程，方法及實際效果，討論在項目實施過程中出現的沖突情況及解決辦法。

2.范文一：論信息系統項目的整體管理

[摘要] 醫療保險管理信息系統涉及到醫保管理部門、各定點結算點（醫院、藥店）、開發商，加之政策多變、業務不成熟，需求變化頻繁，開發的難度和風險較大。在某市醫保管理信息系統開發過程中，我作為用戶方的項目負責人參與了項目的整體管理工作，我在項目整體管理中采取了針對性的措施，加強了參與各方的溝通，注重用戶需求和需求的變化，合理配置項目組成員，對風險進行了及時的評估并順利地控制了風險。通過這些辦法，平衡了各方的利益，控制了項目的范圍和進度，保證了項目的質量，順利完成了這個項目。

[正文] 幾年前，某市為實施城鎮職工基本醫療保險，開發了一套醫保管理信息系統，我作為用戶方項目負責人，參與了項目管理、系統分析和編程的部分工作。

這個系統的功能包含了基金征集和支付管理、參保單位（職工）管理、定點結算點管理、參保職工就診結算管理、IC卡管理等，目標管理人數為30萬、定點結算點200個，計劃投資400萬元；采用C/S結構，數據集中保存在市醫保中心，定點結算點與醫保中心之間數據實時交換。

通過公開招標，明確了項目的范圍、時間、成本和采購，因此，我把整體管理工作的重點放在了項目的質量、人力資源、溝通和風險管理方面，目的是保證實現計劃的功能并按時投入運行。在工作中，我根據實際情況，采用了靈活的工作方法，取得了較好的效果。

該系統在04年一次上線運行成功，目前運行情況良好。

一、加強了溝通管理。

該項目涉及到醫保中心、參保單位、定點結算點、系統開發（集成）商等多個單位，從需求分析到系統設計、測試都要各方參與、協調配合，由于各方的地理位置十分分散，難以經?；蜷L期集中，因此，各方及時有效的溝通是項目成功的必要條件。為解決好這個問題，我采取了三個辦法：

1、提高大家對溝通作用的認識，特別是各方主要領導人對溝通的必要性和重要性的認識，從而對溝通工作給予必需的人員、經費和時間支持，保證了溝通工作得以按計劃進行。

2、對項目組外部的溝通，堅持從實際出發，采用多種溝通的方式。一方面，把必要的、重要的溝通需要以聯席會議、工作計劃、總結報告的形式制度化。另一方面，在適用的前提下，采用靈活、經濟的溝通方式，比如：對一般的小問題或者是簡單問題進行電話交流，復雜一點的問題開碰頭會，需要后續解決的、比較重要的及涉及面較大的問題要形成書面的會議記要，有必要的情況下要由相關單位加蓋公章確認。

3、對項目組內部溝通，進行適當的控制，避免形式主義，在保證效果的前提下節省時間，提高工作效率。規定項目組成員在每天工作過程遇到問題，將其記錄下來，然后在以郵件方式發送給需要溝通或者詢問者。大家每天下 班之前收取郵件，對于可以直接回答的問題則直接以郵件方式回復，對于無法直接答復而只需與提出問題者討論的問題，在第二天上班前進行商議確定。而需要眾人一起討論的問題，則放到每周會議上討論，較緊急的問題召開臨時性會議。通過以上方法，基本上實現了有關各方及項目組內部的有效溝通，及時發現問題、解決問題，避免了因各方立場不一致造成嚴重對立而影響項目進度，避免了因交流不暢形成重大質量問題。

二、合理配置人員。

對項目組人員進行規劃配置，合理分工，明確責任，保證項目各階段、各方面的工作能夠按計劃完成。我們在項目組長配置了以下人員：技術組長一名，負責技術難題攻關，組間溝通協調；需求人員5名，負責將用戶需求轉換成項目內的功能需求和非功能需求，編制項目需求規格說明書，針對每個迭代集成版本與用戶交流獲取需求的細化；設計人員5名，負責對需求規格說明書，進行系統設計；開發人員8名，實現設計，完成用戶功能；集成人員1名，負責整套系統的編譯集成，督促小組系統功能提交，及時發現各模塊集成問題，起到各小組之間的溝通的紐帶；測試人員2名，對于集成人員集成的版本進行測試，盡可能的發現程序缺陷，以及未滿足需求的設計；文檔整理人員1名，負責對小組內產生文檔的整合，統一；維護人員1名，系統驗收后，維護人員，建議維護人員早期進入項目參與項目測試以便順利承擔起項目維護職責。

在人員的管理方面，一方面要求項目組成員相對穩定，以保證開發工作的連續性，另一方面，不搞終身制，不能夠勝任職工作的堅決調換，保證項目整體工作不受影響。通過平常和階段性的工作考核、評審，對不合格人員進行調換。有一名需求分析人員因為工作態度不好，與客戶單位業務人員關系惡化，調查落實后，我們立即把他調出項目組。

三、進行風險評估，在進度和質量之間進行權衡，爭取最佳平衡點。

由于項目資金已經確定，我就在進度和質量之間找平衡點，力爭把風險降到最低。由于醫療保險業務本身比較復雜，加之當時國家政策不穩定，業務流程不是很規范，系統需求也在不斷調整、完善，給項目的進度帶來一定影響。由于這個項目涉及到十余萬參保職工的醫療待遇，影響很大，通過與用戶方領導溝通，決定不搞“形象工程”，在質量和進度之間優先考慮質量。同時，考慮到這個項目的采用了增量開發模型和模塊化的設計方法，我把項目目標進行了分解，涉及到業務經辦的部分優先完成，保證系統在規定的時間上線運行，其它不影響業務經辦的、輔助性的功能適當延期，包括醫療監督、統計分析和部分報表。這樣雖然整體工期有所延長，但沒有影響系統及時上線。這種做法同時照顧到各方的利益，把整體風險降到了最低。

四、重視需求變化的客觀性，強化測試，保證軟件功能完整、正確、高效。

質量是軟件的生命，軟件功能完整、正確、高效是軟件質量的重要組成部分，也是用戶最關心的內容。

我們采用了軟件工程方法，使用漸增式的增量模型，注重滿足用戶需求和需求的變化。由于國家沒有統一的醫療保險業務經辦規范流程，另外，為保證醫保基金的收支平衡，各地都在根據醫?；鸬倪\行情況進行不斷的政策調整，造成醫保系統的需求變化頻繁。根據這個情況，為保證軟件滿足應用需要，我們規定：在整個項目的開發過程中，凡是用戶提出的、經調查情況屬實、經技術可行性論證可行的，全部予以響應。同時，采取措施避免需求的反復和無意義、不合理的變更。對較大的變更和比較關鍵的變更，要經各方聯席會議論證通過，參與人員簽字負責，并由提出變更的單位加蓋公章確認。由于不合理或技術上不可行而沒有通過的需求變更，要提出替代的解決辦法，并與用戶單位協商，達成一致意見后予以解決。

測試是保證軟件質量的重要手段，也是讓用戶直觀地了解軟件質量和熟悉軟件操作的有效途徑。我有計劃地強化測試環節，讓用戶由始至終地參與測試工作。我們主要采取黑盒法進行測試，把工作重點放在測試用例的準備上，嚴格定義測試索引、測試環境、測試輸入、預期結果、評價標準，盡可能的把各種業務的不同情況都表現出來。同時，我們準備了一家定點結算點進行實際運行測試，在該結算點手工記帳和計算機聯網記帳同時進行，并有計劃地穿插一些測試用例。通過這些辦法，及時發現了和解決了許多問題。

經過努力，該系統一次上線運行成功，并在6個月后通過了驗收。回顧項目的整體管理工作過程中，雖然沒有大的事故發生，但仍然存在許多問題，主要有以下3點：

1、軟件測試不系統，用例準備仍不夠充分，忽視了壓力測試。系統實際運行后隨著參保職工和定點結算的增加，運行速度下降很快，達不到設計要求。雖然通過升級硬件緩解了這個問題，但造成了資金的額外投入。

2、在需求分析過程中對各方目標的權衡不夠充分，導致定點結算點使用的結算子系統功能較弱，提供的系統接囗又不夠強大，給定點結算點內部管理帶來不便，一些必要的統計和查詢功能難以實現。

3、對開發人員與操作人員對系統的要求差異認識不足，兩者的直接溝通不夠，造成一些對操作員而言很重要的問題在開發人員那里得不到重視，產生了一些矛盾，給項目帶來不利影響，特別是影響到用戶方及領導部門對項目的整體印象。

綜上所述，良好的項目溝通管理；合理的人力資源配置；用風險評估在進度和質量之間進行權衡；重視需求變化的客觀性，強化測試，保證軟件功能完整、正確、高效是我在某市醫療保險管理信息系統項目中的整體管理中的 四個主要實踐，為項目的成功奠定了堅實的基礎。在以后的項目整體管理工作中，我要加強測試的系統性和科學性，注重各方利益的權衡，繼續深化各方的溝通，協調好開發工作各個部分及各個方面的關系，更好地完成項目。

[老師評語] 此文基本達到了考試要求。寫作比較規范，行文流暢。文章結構清晰，所述的一些情況確實是在項目開發過程中所經常碰到的而又需要解決的問題,給人的感覺問題真實,針對問題采用的措施亦較為有效。

3.范文二：論信息系統項目的整體管理

[摘要] 本文以筆者所主持的某卷煙廠物流控制及管理信息系統項目為實例，探討了信息系統項目整體管理在項目實施過程中的重要性，并分別論述了項目計劃編制、項目計劃實施，以及項目綜合變更控制等項目整體管理過程，在整個項目生命周期內所起的積極作用及其實施經驗。在該項目中，本人以開發方公司副總工程師身份擔任項目經理，負責了項目的整體規劃、組織實施和管理控制。我們科學地運用了信息系統項目整體管理的一般理論知識及其指導方法，有效地保障了項目的順利實施，很好地滿足了各利益相關者的需求和預期期望。

[正文] 信息系統項目的整體管理是項目取得全面成功的一個至關重要的前提和基礎。通過項目整體管理，可以確保項目所有的組成要素在適當的時間有機地結合在一起，以順利、成功地完成項目。這在本人所主持的某卷煙廠物流控制及管理信息系統項目實施過程中得到了充分驗證。

該項目是一個綜合性的系統工程項目。從技術實現角度講，它所涉及到的主要技術領域包括卷煙生產工藝、制造業物流技術、工業自控技術和計算機管理信息技術等等。從利益相關者角度講，它又涉及到作為需方的煙廠、物流設備供應商、工業自控設備供應商，以及作為信息系統集成商的我公司。因此，這是一個復雜程度高、涉及面較廣、實施周期長的綜合項目。

面對這樣一個項目，作為開發方公司的副總工程師，我受公司委托擔任該項目經理，我首先想到的是應該將主要精力放在項目的整體管理上，科學地運用相關理論知識及其指導方法，做好項目的全局性統領工作，協調完成項目所需的所有人員、計劃和工作，帶領整個項目團隊實現項目的順利成功。另外，我也考慮到，除了項目本身內部的各組成要素之外，項目的相關利益者也不容忽視。一方面是作為公司承擔的一個對外項目，我們實行項目經理負責制，具有一定意義上的獨立性，但同時也是公司整個組織日常持續運作中的一部分，離不開公司的整個組織環境，而且公司也已決定將該項目作為業務延伸拓展的一個新的窗口，將其提升到了一個相當重要的位置。另一方面，該項目是需方煙廠整體搬遷重大技改項目的一個部分，其實施的進度、質量和成本等，受到來自其主管上級部門和煙廠新經營目標的嚴格要求和控制。此外，還會涉及到物流設備供應商、工業自控設備供應商等中標單位。所以，項目的整體管理顯得是那么的重要、不可或缺。否則，稍有顧及步驟之處，都將會給項目的實施帶來很大的麻煩和影響。

下面分別從項目計劃編制、項目計劃實施，以及項目綜合變更控制等方面對項目的整體管理過程加以簡要論述。

1、關于項目計劃編制：

凡事預則立、不預則廢。信息系統項目尤其如此。只有站在統領全局、整體規劃的高度，對項目進行科學、合理、全面、周詳的計劃，預先制定一個用來協調所有其他計劃、以指導項目實施和控制的文件，才能使項目得以順利實施并最終取得成功。項目計劃記錄了計劃的假設條件和方案選擇，可以為各利益相關者之間的溝通提供了一個參照，并確定了關鍵管理審查的內容、范圍和時間，同時還為進度評測和項目控制提供了一個基線。

在該項目中，我們對項目計劃具體內容的確定，結合項目的各方面實際情況，主要參照IEEE1058.1中“軟件項目管理計劃”的基本內容，其中包括項目介紹、項目組織、管理過程、技術過程和進度預算等五個部分。在堅持科學、合理、全面、周詳的原則基礎上，還視部分具體的計劃條款，詳略得當。但所有的計劃內容都必須是正確的、明確的、易理解的和可執行的，切忌未經確認、含糊不清、容易誤解、難以執行的項目計劃描述。這就要求我們必須在制定計劃之前或在制定過程中，與需方煙廠、公司上層、其他設備供應商、項目團隊各技術和管理小組進行充分的溝通與協商，明確確定項目有關內容，如項目可交付成果、技術方法工具、組織結構、各工作包、資源要求、預算分配、進度計劃等。

另外，因為項目管理的最終目標是滿足或超越各利益相關者的需求和期望，在項目計劃過程中考慮利益相關者分析也是非常重要的，但不宜將其作為項目整體計劃的一個部分，最好把它作為公司內部使用的一個項目計劃附件。該項分析的內容可以包含各利益相關者的所屬組織、所處角色、項目利益、影響程度及管理這些利益相關者的合適建議等。對于項目經理來說，花點時間來關注和利用這些信息也是非常重要的。我在該項目管理過程中的感覺是，在項目的日常實施過程中，尤其是在項目陷入某些困難的時候，這些分析結果常常會幫助我起到對癥下藥、藥到病除的作用。

當然，項目計劃的制定和執行，也必須考慮和注意它的動態性和靈活性。尤其是對于綜合性的項目而言更加重要。由于項目復雜程度高、涉及面較廣、實施周期長，所以其中的變更是在所難免的。在該項目實施過程中，由于煙廠項目局部需求的修改，或由于各方交流的失誤等，曾經導致了部分項目內容的變更從而致使了項目計劃人員和進度的變化和調整等。而且這種計劃動態修訂的次數還不止一次。所以項目計劃制定以后并非一勞永逸，它與項目實施過程相互滲透，有一個動態的、靈活的修訂過程。

2、關于項目計劃實施：

項目計劃實施是指對項目計劃中所規定的工作進行管理和實施的過程。項目產品主要都在項目實施階段生產出來，所以項目的大部分時間和預算都花在這一階段。在該項目中，我們的軟件編程、與需方煙廠有關技術人員的具體溝通、與有關設備供應商的具體交流、階段性調試，直至全套系統軟件和技術文件的完成等，都發生在這一階段。為了能夠成功地完成項目產品，項目團隊進行了大量反復的具體編程、學習、溝通、修改、軟硬件安裝和調試工作。

如前所述，該項目涉及到的主要技術領域包括卷煙生產工藝、制造業物流技術、工業自控技術和計算機管理信息技術等，我們項目團隊不僅要從事熟知的信息技術工作，還要花大量時間和精力了解煙廠具體的細節性的需求，學習卷煙生產工藝、制造業物流理念和常識、物流設備的基本工作原理和管理知識、自控設備的基本工作原理和管理知識等等，以及反復地和煙廠、相關設備供應商、公司上層等進行必要的交流溝通。作為項目經理，在此階段主要的工作是要按照預先制定的項目計劃，利用項目團隊組織機構和工作程序，領導項目團隊開展各項工作，管理和協調各利益相關者的關系，成功地將項目計劃投入實施。

項目計劃和項目實施是相互滲透、不可分割的活動。在該項目的實施中，我們對于項目計劃編制和實施之間的協調改進工作主要采取誰實施誰計劃的原則。雖然項目經理負責整體項目計劃，但編制該計劃的大量基礎信息均來源與各技術組和技術人員。事實證明，按照這一原則，項目計劃的編制更加合理、可行，實施起來更加順利。

3、關于綜合變更控制

綜合變更控制是指在項目生命周期內對項目變更進行識別、評價和管理的工作，這也是項目經理及其項目團隊的一項重要工作。如前所述，該項目的復雜程度高、涉及面較廣、實施周期長，所以其中的變更是在所難免的。當有變更要求提出的時候，作為項目經理，我都會召集項目團隊相關人員，進行協商討論和工作安排。主要內容有：

A、對變更因素加以影響：通過在范圍、時間、成本和質量等關鍵項目尺度的權衡，對促使變更形成的因素進行分析和采取對策，確保變更對項目有利；

B、確定變更是否發生：在最終確定變更發生前，項目經理必須了解項目幾個關鍵方面的狀態。尤其是一些重大變更，項目經理必須與公司高管層，以及其他利益相關者進行必要的交流與溝通。

C、對變更加以管理：項目經理在項目管理過程中必須嚴格行事，盡量避免或減少變更的發生。但變更不可避免發生時，更重要的是對變更進行管理。

按照項目整體管理的指導方法，我們在變更發生時，要求必須輸入項目計劃、變更申請和績效報告等重要內容，輸出更新后的項目計劃、糾正行措施和經驗性教訓記錄等。通過這些做法，使我們的項目變更控制與管理工作規范有序。

該項目順利成功地實施完畢已經有一年多了?；仡櫰饋矶?，應該得益于我們在項目進行的最初期階段就引入了項目整體管理理念和方法，對項目進行了科學、規范的整體管理。通過項目整體管理，使項目所有的組成要素在適當的時間充分地、有機地結合在一起，極大地提高了項目的實施效率。

[老師評語] 本文基本達到了考試的要求。摘要和正文都寫得比較流暢，給人的感覺思路清晰，層次感強。項目所述情況基本與項目研發過程中的情況相同，給人以真實感和作者有豐富的項目實施經驗的感覺。

文中如果能把一些具體的問題和解決辦法展開一下則更佳。如：在變更控制上為了盡量減少變更的數量，采用的需求變更申請表的形式，讓煙廠方需求人員埴寫需求變更申請表，并簽名。一方面控制了需求變更的隨意性；另一方面對明確了各方的責任，也為開發人員提供了方便。

4.范文三：論信息系統項目的整體管理

[摘要] 本文以我主持某市地稅銀行代理繳稅系統項目為實例，探討了信息系統項目的整體管理，及個人的一些經驗教訓。在該項目中我受領導委派，擔任銀行方項目組長。通過實踐，對項目整體管理有了更深刻的認識：（1）前期工 作很重要，需要與各方進行充分溝通，明確接口，需要制定切實可行的計劃；（2）項目管理是一項系統的、動態的工作，不要僵硬化，應保障信息共享，及時根據情況變化進行計劃調整；（3）在項目管理中，特別是牽涉部門比較多時，應采用各種方式保證良好的溝通、協調，保證進度。

通過本人及項目組的努力，該項目按計劃完成，達到目標要求。[正文] 項目整體管理是項目管理中一項綜合性、全局性的管理工作。它決定在什么時間，在哪些預期的潛在問題上集中資源和基礎和工作，在問題變得嚴重前進行處理，協調項目干系人及各項工作使項目走向成功。整體管理的工作流程主要有制定項目章程、指定項目初步范圍說明、制定項目管理計劃、指導和管理項目執行、監督和控制項目工作、綜合變更控制、項目收尾。項目整體管理是一個項目能否高效、順利的進行的一項基礎性的工作。

2003年，根據某市地稅部門和我行的代理協議和該市我行的零售業務部門提出的需求，我受省行科技部門指派，擔任銀行方的項目經理，組織開發了某市地稅銀行代收項目，該項目2003年5月中旬啟動，2003年10月1日正式投產。項目涉及我行省行、市行，市地稅、市地稅方的信息系統外包開發公司四家單位。

在該項目的整體管理中，我在項目管理的五大過程中分別做了以下工作：

（1）在項目啟動過程中，我根據業務需求，提出項目開發立項報告，完成項目的啟動工作；進行項目的初步范圍制定，對項目的目標、范圍，項目組織、進度里程、項目費用估算進行分析；

（2）在項目的計劃過程中，用project制定項目初步管理計劃；

（3）在項目的執行過程中，配置人力資源，調配系統資源，執行項目計劃，協調、溝通項目組、市地稅方、市中行，確保項目正常、順利完成；

（4）在項目的監督、控制過程中，收集分析項目周報，舉行項目例會，將項目進度與項目計劃進行比較；對變更情況進行分析、流程改變、記錄分析，跟蹤項目風險點，并制定風險應對方案；

（5）在項目收尾過程中，要求業務部門提供項目驗收測試報告、項目投產申請；完成運行部門的項目投產單。該項目業務跨越銀行及稅務兩大行業，并各有自己的信息系統，如何實施雙方系統的互聯，進行需求的確定是一個比較困難的工作，需要解決稅務局和銀行，銀行業務部門與技術部門的各種沖突，即要滿足對方的需求，也要考慮本行的利益。

可以通過從對方角度考慮問題，進行良好的溝通，最后圓滿解決不合理的需求問題。如稅務局開始時提出，納稅人在銀行交費后，稅票信息需要在銀行保留。而銀行系統一般只保留交易的賬務信息，對保存稅票信息需要比較大的代價來實現，為解決該問題，我從稅務局的角度進行分析：首先會有其他銀行也加入地稅代收的工作，其次納稅人可能在就近的銀行或稅務局打印發票，所以，稅票信息需要集中保存，集中保存的最合適地方是稅務局。

在開發工作中，可以把行內業務需求人員加入到項目組中，或者建立緊密的溝通機制，調動業務人員積極性，讓其在項目開發的需求確定，業務測試中發揮積極作用，減少需求的反復，開發的重復勞動，減少投入，確保工程進度。

對避免不了的需求變更。需要需求方以文字的形式對該變動進行規范、明確的闡釋：如要求地稅局或業務部門要提供需求變更說明，填寫需求變更申請表等，減少需求提交的隨意性，大大減少需求變更的數量。

該項目還有一個特點，涉及的單位和人員比較多，協調工作比較復雜，對此我的解決辦法是：

（1）與地稅局及業務部門，要充分進行業務流程、交易接口、通訊接口的討論，確定雙方的交易功能，技術接口定義，明確各方的工作職責；

（2）在項目組中，根據明確的需求，及時進行工作分解，根據項目組成員的特點、專長分配各項子任務，做到職責明確，分工合理；

（3）在項目開發過程中，要及時進行信息交流，及時向各方發布項目進度情況，我通過建立文件共享服務器，發布技術協議，需求分析，概要設計，項目計劃，項目周報等文件，讓項目組成員及配合的業務人員對工作有全面了解，對工作重心及時掌握，盡量減少內部沖突；

（4）在功能開發基本完成后，及時組織雙方的系統聯合測試，在準生產環境中運行，及時發現問題，解決問題。（5）建立良好的進度管理機制：在項目啟動時就用Project制作計劃，統一分發，與其它單位協商計劃文檔；在項目進行中，及時完善、更新進度；計劃前提有變動時要及時調整；建立跨單位的周例會制度，項目周報填報制度等。

該項目歷時一個月，順利完成投產工作，并在生產中，達到要求，為銀行創造了效益，為地稅部門減輕了負擔，為納稅人提供了方便，實現了多贏的結果。同時也鍛煉了我的項目管理能力，對項目整體管理有了更深刻的認識：項目管理前期工作很重要，需要制定切實可行的計劃，需要充分溝通，明確接口；應對項目管理有是一項系統的、動態的工作的認識，不要僵硬化，應保障信息共享，及時根據情況變化進行調整；在項目管理中，特別是牽涉部門比較多時，應采用各種方式保證良好的溝通、協調。[老師評語] 論文基本上達到了考試論文的寫作要求，均是作者實踐經驗的總結，侃侃道來。美中不足的是：論文正文的字數稍少了點。在正文中的有些論點可適當再展開一下。如進度管理中是填制項目周報發現其它單位并不愿意填制周報，解決辦法：主動將自己項目組的周報發給其它單位并作溝通，在此基礎之上再表明希望這個單位也能回一個進度周報，即主動溝通。

5、范文四

信息系統項目的整體管理

[摘要]

本文以我參與的某大型結構分析軟件系統的消化、移植、開發項目為實例，探討了信息系統項目的整體管理，指出項目整體管理在信息系統項目實施中具有重要地位和關鍵作用，應根據項目的實際情況和特點，在做好項目整體管理各項工作內容的前提下，有針對性地強化某一方面整體管理的工作。具體論述了在本信息系統項目的實施中，系統動態地處理問題、明確接口定義并嚴格實施、換位思考以化解沖突三種方法對整體管理工作的積極意義。

[正文] 項目整體管理在項目實施中具有重要地位和作用，在本人參與的一項工程分析軟件系統的開發項目，充分體現了這一點。該項目開發的主要內容是：將引進某外國的運行于大、中型計算機（如，IMB4381、WAX3300等）的結構有限元分析系統進行消化、移植，形成有自主版權的可運行于工作站（如，HP715）和微機的結構分析系統，并在此基礎上開發出當時國內急需的結構優化功能、圖形化前后置顯示功能和復合材料結構單元等新功能。該項目工作量大，僅需消化、移植的某源程序就有四十多萬條；技術復雜，涉及有限元理論、離散數學、計算機技術、各型計算機體系結構和操作系統的兼容性、結構力學、材料力學等多學科；多單位協作，有多達四個單位參加；參加人員眾多且跨不同專業，有數學人員、力學人員和計算機開發應用人員。如此大型復雜的信息系統項目開發，綜合的整體管理至關重要，決定著項目的成敗。

為了保障項目的成功實施，在前期由我單位領導掛帥成立了項目領導小組，統一管理、協調根據項目的學科方向組建了相應項目研發小組，成立了項目管理組負責組間協調和項目的整體管理工作，我擔 任了項目管理組的組長，自始至終參與了項目的整體管理工作，切身地感到了研發活動的整體管理所起到的重要作用，并認識到了一些整體管理的具體理念和方法。

項目整體管理是貫穿項目生命期全過程的一項綜合性和全局性的管理工作，它以項目成功為目標，采取統一、協調、集約、澄清等措施，使項目實施全過程沿正確的軌道運行。通常項目整體管理工作包括：

（1）制定項目章程，確立項目的組織機構和運行機制，約定行動規則、制定實施標準等；（2）初步確定項目的工作內容和工作范圍，明確完成項目都要做哪些工作；

（3）在項目實施各分計劃的基礎上，制定、協調、集成項目管理計劃，并作為項目實施的準繩；（4）依據管理計劃，指導和管理項目實施過程中各項活動的執行；（5）監督、控制、協調項目的各項工作；

（6）進行變更控制管理，保持項目的完整性和一致性；（7）對項目進行收尾總結，工作有始有終，積累經驗。

信息系統項目往往比較復雜。如本人參與的這個項目，既有涉及不同技術和專業的，如建立力學模型，設計各種算法，使用高級語言和匯編語言等，也存在有不同組織和個人的不同期望，如有計算力學所，計算機所，對模塊性能有不同觀點期望。協調進度、成本、質量，進行有效溝通和資源配置，樹立全局觀念等，都是項目所必須的，但又往往存在大量主觀和客觀的問題，對以上的管理構成障礙和挑戰。在各項目目標之間和參與項目的單位和人員之間經常出現不協調或沖突，項目管理人員必須在這些不協調或沖突釀成危機前處理好各種矛盾和沖突，協調為完成項目所需的資源、計劃以及工作。可見沒有有效的整體管理工作，項目是難以成功的。

信息系統項目整體管理工作的內容繁多、涉及方方面面，存在著需要特別關注和做好的重要方面，換句話說，就是要特別關注在正確的時間、正確的場合，使用正確的方法，投放資源和實施工作。以我參與的這項工程分析軟件開發項目來說，項目最終按期完成，基本實現預期目標，與項目整體管理工作中著重做好了系統、動態地處理問題；明確接口并嚴格實施；換位思考以化解沖突、矛盾這三方面的工作密切相關。

系統、動態的處理問題，就是對項目實施中出現問題的處理應放到項目全局中進行考慮，全面地、聯系地進行分析，動態的而不是靜止的加以解決。在本項目開發實施中，由于系統的需求是來自工程領域利用計算機進行結構分析與優化，并實現大型分析系統的微機化，項目成功的技術重點和難點在于不同計算機系統的差異和兼容性，而項目負責技術總體設計的總工程師是工程力學方面的專家，對其它領域專業知識（特別是計算機專業）的局限，使動態內存管理模塊的設計方案幾易其稿，難以滿足系統總體要求，造成項目開發進度在系統移植階段停滯不前。為了解決這個問題，我向項目領導小組及時請示，取得了單位領導的支持，召集相關的主要負責人，通過認真分析，采取了數學組專家提出的方案，并由數學組的組來負責移植階段的總體技術工作，系統移植的技術難題才得以正確解決。由此可以看出，在項目實施的全過程中，系統地看待和處理問題，動態地、恰如其分地調配資源，有益于項目整體管理工作目標的達成。

明確接口并嚴格加以實施，是促使項目成功采取的一個重要措施。本結構分析系統是在已有原型基礎上的移植、開發，在模塊之間的接口調用上，存在不同的解決方案，具有不同的性能指標，如何整合集成，僅僅給出籠統的標準還不夠，在項目進行到一定的階段，必須由模塊開發的各方，在項目有關的負責人協調下，確立明確、具體的接口定義，并嚴格按照定義的接口檢測驗收，以保證軟件系統的完整性和一致性，形成階段可交付的子系統，推進項目的進度。在如此龐大的信息系統項目開發過程中，沒有明確的接口定義，項目在模塊聯調階段，將面臨大量協調、溝通、扯皮、更改工作，為項目推進帶來許多不必要的返工和重復，使本來不存在技術問題的項目實施舉步維艱。我們項目管理組根據以往的經驗，從項目一開始，就特別注重模塊接口定義的整體、全局管理工作，協調各研發小組共同討論接口的設計問題，使各研制組的工作在銜接處平穩對接，沒有因為接口定義的不到位而對項目造成拖延和資源上的浪費，取得了明顯的成效。

項目在開發過程中實施的各項活動交互重疊，不可避免地會發生沖突和矛盾，矛盾和沖突發生時，在雙方方案均具有合理性，又各持己見、相持不下時，換位思考以求折中、平衡，從而化解沖突和矛盾，不失為整體管理工作中的一項行之有效的方法。在本項目中，研發人員主要是兩類專業技術人員組成，工程結構方面的和數學、計算機方面的，兩類人員由于專業背景的關系和出發點的差異，在對問題的解決上，常常各持己見，互不相讓，而有時沖突的原因是對對方專業知識的缺乏。為了很好的解決這一問題，我們項目管理組經過計劃和組織，約定在每周五舉辦學術交流活動，請兩方面的專家講解、介紹各自專業領域的基本知識，使雙方都能對對方的技術觀點有了較客觀的理解，從而有利于在工作配合、協調時，能夠站在對的角度，尋求到雙方均滿意的平衡點。由于課題組積極的措施和倡導，換位思考成為項目參加人員的共同理念，為項目的成功實施創造了良好的文化氛圍。

該項目在歷時兩年后，較為成功的實現了當初制定的目標，并被評為當年部科技進步二等獎，能取得這樣的成績，很大程度上得益于良好的項目整體管理工作，特別是系統動態地處理問題、明確接口定義并嚴格實施、換位思考以化解沖突這三種解決項目沖突的方法。

[老師評語] 本文整體感覺比較流暢，觀點鮮明，論文中講述的情況，特別是對于多學科交叉的大型信息系統項目來說，作者的三點主要論點的體會，給人的感覺比較實在。

第一篇 項目管理（進度、風險）

IT項目管理

1）IT項目同傳統項目的區別

傳統的項目需要經歷的時間長，使用的是有形資源，項目成果是通過對資源的消耗與形態的轉化來逐步實現的。

IT項目的實質是“知識轉移”，項目是以無形的智力產品為項目目標。典型的IT項目是IT系統的建造(如系統集成)和軟件開發項目。

因此說，IT項目的實質是“知識轉移”，而建造項目的實質是“資源消耗”。當然，并非說IT項目中不存在“資源消耗”，也不是說傳統項目中沒有“知識轉移”。這一點應該得到辨證的理解。

2）項目管理的五個過程與IT項目生命周期

項目的管理過程分為五個過程組，每個過程組由多個過程組成。分為：

啟動過程組

計劃編制過程組

執行過程組

控制過程組

收尾過程組

過程組之間相互關聯，每個過程組的輸出是另外過程組的輸入。同時，各過程組之間不是獨立的事件，在同一階段會有多個過程組同時進行。

典型的IT項目的生命周期分為：

概念階段

需求分析階段

計劃階段

設計階段

執行階段 交付階段

結束階段

項目所處的階段越早，項目不確定性就越大，項目調整或變更的代價比較低。但隨著項目的進行，不確定性逐漸減小，而變更的代價、付出的人力、資源逐漸增加，就會增加決策的困難度。

在項目生命周期的每一個階段都要重復項目管理過程的五個過程組。

3）概念階段

概念階段的主要工作是：

評估商業需求和機會

開發項目以滿足商業需求和機會

財務收益分析

確認相關項目干系人

建立概念方案

啟動項目

啟動項目中最重要的是要建立項目章程，授權相應的項目經理開展項目。

4）需求分析階段

需求分析階段的主要工作是：

收集需求

分析需求并對需求排列優先級

記錄定義下來的需求

確認需要做的需求并細化需求

IT項目管理的三個條件、五個步驟

【本文精彩，可熟背】

項目是為完成某一獨特的產品或服務所做的一次性努力。根據這個定義，項目就具有了目標明確性、活動一次性及資源消耗性等特性。換句話說，具備前面三個主要特性的活動，都可以看作是項目。現實中的項目隨處可見，如設備消缺、會議組織、技術競 賽、結婚典禮以及家居裝修等等，都可以看作是項目。在這些項目的實施過程中，都存在項目管理問題，不過，實際生活與工作中，可能更多關注的事情本身，而對做好事情相關的組織、計劃、控制等過程相對缺少關注，或者沒有經驗與能力加以關注。

項目管理是在項目活動中運用知識、技能、工具和技術來實現項目要求。項目管理總體有五個過程：啟動過程、計劃過程、實施過程、執行過程、收尾過程等，包含了九大領域的知識：范圍管理、時間管理、成本管理、質量管理、風險管理、人力資源管理、溝通管理、采購管理及系統管理的方法與工具。作為項目經理要全面掌握這些九個核心領域的知識，并重點把握系統管理的觀念，避免進入某個細節，注意在五個不同階段的重點。

一、項目管理的三個約束條件

任何項目都會在范圍、時間及成本三個方面受到約束，這就是項目管理的三約束。項目管理，就是以科學的方法和工具，在范圍、時間、成本三者之間尋找到一個合適的平衡點，以便項目所有干系人都盡可能的滿意。項目是一次性的，旨在產生獨特的產品或服務，但不能孤立地看待和運行項目。這要求項目經理要用系統的觀念來對待項目，認清項目在更大的環境中所處的位置，這樣在考慮項目范圍、時間及成本時，就會有更為適當的協調原則。1.項目的范圍約束

項目的范圍就是規定項目的任務是什么？作為項目經理，首先必須搞清楚項目的商業利潤核心，明確把握項目發起人期望通過項目獲得什么樣的產品或服務。對于項目的范圍約束，容易忽視項目的商業目標，而偏向技術目標，導致項目最終結果與項目干系人期望值之間的差異。

因為項目的范圍可能會隨著項目的進展而發生變化，從而與時間和成本等約束條件之間產生沖突，因此面對項目的范圍約束，主要是根據項目的商業利潤核心做好項目范圍的變更管理。既要避免無原則的變更項目的范圍，也要根據時間與成本的約束，在取得項目干系人的一致意見的情況下，合理的按程序變更項目的范圍。2.項目的時間約束

項目的時間約束就是規定項目需要多長時間完成，項目的進度應該怎樣安排，項目的活動在時間上的要求，各活動在時間安排上的先后順序。當進度與計劃之間發生差異時，如何重新調整項目的活動歷時，以保證項目按期完成，或者通過調整項目的總體完成工期，以保證活動的時間與質量。

在考慮時間約束時，一方面要研究因為項目范圍的變化對項目時間的影響，另一方面要研究，因為項目歷時的變化，對項目成本產生的影響。并及時跟蹤項目的進展情況，通過對實際項目進展情況的分析，提供給項目干系人一個準確的報告。3.項目的成本約束

項目的成本約束就是規定完成項目需要花多少錢。對項目成本的計量，一般用花費多少資金來衡量，但也可以根據項目的特點，采用特定的計量單位來表示。關鍵是通過成本核算，能讓項目干系人，了解在當前成本約束之下，所能完成的項目范圍及時間要求。當項目的范圍與時間發生變化時，會產生多大的成本變化，以決定是否變更項目的范圍，改變項目的進度，或者擴大項目的投資。

在我們實際完成的許多項目中，多數只重視項目的進度，而不重視項目的成本管理。一般只是在項目結束時，才交給財務或計劃管理部門的預算人員進行項目結算。對內部消耗資源性的項目，往往不做項目的成本估算與分析，使得項目干系人根本認識不到項目所造成的資源浪費。因此，對內部開展的一些項目，也要進行成本管理。由于項目是獨特的，每個項目都具有很多不確定性的因素，項目資源使用之間存在競爭性，除了極小的項目，項目很難最終完全按照預期的范圍、時間和成本三大約束條件完成。因為項目干系人總是期望用最低的成本、最短的時間，來完成最大的項目范圍。這三個期望之間是互相矛盾、互相制約的。項目范圍的擴大，會導致項目工期的延長或需要增加加班資源，會進一步導致項目成本的增加；同樣，項目成本的減少，也會導致項目范圍的限制。作為項目經理，就是要運用項目管理的九大領域知識，在項目的五個過程組中，科學合理的分配各種資源，來盡可能的實現項目干系人的期望，使他們獲得最大的滿意度。

二、項目管理的五個主要過程組

一個項目的生命周期大概分成概念、開發、實施與收尾過程。在概念階段主要是對成本進行分析，對項目的可行性進行研究，其結果是要拿出一份報告，并獲得批準與支持。實際工作中，我們只是有了一個新的想法與概念，就立即轉入開發過程。在開發階段，要有項目計劃書、預算的成本以及工作分解計劃。

我們做事時，可能只是拿出一個簡單的工作分解與大致的項目計劃時間表，就結束了。在實施階段，要有底層的工作包與確定的成本估計，但我們沒有，到了這一步，我們基本上就開始失去了控制，沒有明確的里程碑，我們只是把一個階段當成了一個項目。在收尾階段，我們是經常討論每個項目的教訓，但對完成的工作的文檔工作基本上沒能及時跟上，同樣與用戶之間的交接也未能做好。

項目管理的五個過程組：啟動、計劃、執行、控制與收尾，貫穿于項目的整個生命周期，對于項目的啟動過程，特別要注意組織環境及項目干系人的分析；而在后面的過程中，項目經理要抓好項目的控制，控制的理想結果就是在要求的時間、成本及質量限度內完成雙方都滿意的項目范圍。1.項目的啟動過程

項目的啟動過程就是一個新的項目識別與開始的過程。一定要認識這樣一個概念，即在重要項目上的微小成功，比在不重要的項目上獲得巨大成功更具意義與價值。從這種意義上講，項目的啟動階段顯得尤其重要，這是決定是否投資，以及投資什么項目的關鍵階段，此時的決策失誤可能造成巨大的損失。重視項目啟動過程，是保證項目成功的首要步驟。

啟動涉及項目范圍的知識領域，其輸出結果有項目章程、任命項目經理、確定約束條件與假設條件等。啟動過程的最主要內容是進行項目的可行性研究與分析，這項活動要以商業目標為核心，而不是以技術為核心。無論是領導關注，還是項目宗旨，都應圍繞明確的商業目標，以實現商業預期利潤分析為重點，并要提供科學合理的評價方法，以便未來能對其進行評估。2.項目的計劃過程

項目的計劃過程是項目實施過程中非常重要的一個過程。通過對項目的范圍、任務分解、資源分析等制定一個科學的計劃，能使項目團隊的工作有序的開展。也因為有了計劃，我們在實施過程中，才能有一個參照，并通過對計劃的不斷修訂與完善，使后面的計劃更符合實際，更能準確的指導項目工作。

以前有一個錯誤的概念，認為計劃應該準確，所謂準確，就是實際進展必須按計劃來進行。實際并不是如此，計劃是管理的一種手段，僅是通過這種方式，使項目的資源配置、時間分配更為科學合理而已，而計劃在實際執行中是可以不斷修改的。

在項目的不同知識領域有不同的計劃，應根據實際項目情況，編制不同的計劃，其中項目計劃、范圍說明書、工作分解結構、活動清單、網絡圖、進度計劃、資源計劃、成本估計、質量計劃、風險計劃、溝通計劃、采購計劃等等，是項目計劃過程常見的輸出，應重點把握與運用。3.項目的實施過程

項目的實施，一般指項目的主體內容執行過程，但實施包括項目的前期工作，因此不光要在具體實施過程中注意范圍變更、記錄項目信息，鼓勵項目組成員努力完成項目，還要在開頭與收尾過程中，強調實施的重點內容，如正式驗收項目范圍等。

在項目實施中，重要的內容就是項目信息的溝通，即及時提交項目進展信息，以項目報告的方式定期通過項目進度，有利開展項目控制，對質量保證提供了手段。4.項目的控制過程

項目管理的過程控制，是保證項目朝目標方向前進的重要過程，就是要及時發現偏差并采取糾正措施，使項目進展朝向目標方向。

控制可以使實際進展符合計劃，也可以修改計劃使之更切合目前的現狀。修改計劃的前提是項目符合期望的目標?？刂频闹攸c有這么幾個方面：范圍變更、質量標準、狀態報告及風險應對?；旧咸幚砗靡陨纤膫€方面的控制，項目的控制任務大體上就能完成了。5.項目的收尾過程

一個項目通過一個正式而有效的收尾過程，不僅是對當前項目產生完整文檔，對項目干系人的交待，更是以后項目工作的重要財富。在經歷的很多項目中，更多重視項目的開始與過程，忽視了項目收尾工作，所以項目管理水平一直未能得到提高。另外要重視那一類未能實施成功的項目收尾工作，不成功項目的收尾工作比成功項目的收尾更難，也來得更重要，因為這樣的項目的主要價值就是項目失敗的教訓，因此要通過收尾將這些教訓提煉出來。

項目收尾包括對最終產品進行驗收，形成項目檔案，吸取的教訓等。另外，對項目干系人要做一個合理的安排，這也是容易忽視的地方，簡單的打發回去不是最好的處理辦法，更是對項目組成員的不負責任。

項目收尾的形式，可以根據項目的大小自由決定，可以通過召開發布會、表彰會、公布績效評估等手段來進行，形式是根據情況采用，但一定要明確，并能達到效果。如果能對項目進行收尾審計，則是再好不過的了，當然也有很多項目是無需審計的。

三、項目管理的九大知識領域

項目管理的九大知識領域是指作為項目經理必須具備與掌握的九大塊重要知識與能力。其中核心的四大知識領域是范圍、時間、成本與質量管理。在這些知識領域中還涉及很多的管理工具和技術，以用來幫助項目經理與項目組成員完成項目的管理。如：網絡圖示法、關鍵路徑法、頭腦風暴法、掙值法等，不同的工具能幫助我們完成不同的管理工作。另外，還有很多項目管理軟件，如：Microsoft Project、P3等，作為項目管理的工具，也可以很好的幫助我們解決在項目的各個過程中完成計劃、跟蹤、控制等管理過程。1.項目整體管理知識

項目的整體管理，或者說是綜合管理也不為錯，它是綜合運用其他八個領域的知識，合理集成與平衡各要素之間的關系，確保項目成功完成的關鍵。項目的整體管理包括三個主要過程：

項目計劃制定：即收集各種計劃編制的結果，并形成統一協調項目計劃文檔。項目計劃執行：通過執行項目計劃的活動，來實施計劃。整體變更控制：控制項目的變更。

項目經理負責協調完成一個項目所需的人員、計劃以及工作，統領全局，帶領團隊實現項目的目標；當項目目標之間或參與項目的人員之間出現沖突時，負責拍板定奪；并負責及時向高層管理人員匯報項目進展信息?？偠灾?，項目經理主要負責項目的整體管理，這也是項目成功的關鍵?；仡櫼郧柏撠煹捻椖?，覺得主要存在以下問題：

未找到項目發起人，或者項目發起人不明確，常把自己當成項目發起人； 項目交付成果定義不清，以致最后收尾時無法對照計劃進行驗收； 缺少組織結構描述；

對項目的控制未能規范化，尤其是項目范圍的變更控制；

風險管理未得到重視，只是在項目組內討論，并停留在項目負責人的頭腦中； 缺乏項目干系人分析；

沒有規范的進度報告，項目進展報告隨意性較大。

要有效的開展項目管理，引用項目管理的知識體系與方法工具，先依樣畫葫蘆，通過實踐，進一步領會這些內容是必須的。

2.項目范圍管理知識

項目范圍的不確定，會導致項目范圍的不斷擴大，作為項目經理，在項目開始時，就要對項目范圍拿出項目干系人都認可的、理解無歧意的范圍說明文檔——項目章程。然后為了保證項目的實施，明確項目組成員的工作責任，還必須分解項目范圍，使之成為更小的項目任務包——工作分解結構（WBS）。

最后還有就是要認識到項目本身不是孤立的，因此有時范圍的變更也是必須的，關鍵是當變更發生時，如何加以控制。

在以上討論之前，最重要的是當面臨項目時，或不知道具體做什么時，如何進行范圍管理。對潛在項目的識別，有四個步驟：

確定做一個什么樣的項目；

業務分析，找出重要的業務過程，分析其中最能從項目中得到好處的過程； 形成項目可能的優勢，確定范圍、好處及約束； 選擇方案，分配資源。

對于從多個項目中選擇項目，或從多個方案中選擇方案的情況，常見的四種方法：整體需要、分類、NPV及加權評分模型。

3.項目的時間管理知識

項目的時間管理，就是確保項目按期完成的過程。首先要制定項目的進度計劃，然后是跟蹤檢查進度計劃與實際完成情況之間的差異，及時調整資源、工作任務等，以保證項目的進度實現。在跟蹤過程中，要及時與項目干系人進行交流，以及時發現范圍的偏差，而產生時間與進度上的差異，或項目組成員有意或無意識的虛報了項目完成情況，導致進度的失控。具體包括以下內容：

活動定義：從WBS分解而來；

活動排序：明確活動之間的依賴關系；

活動歷時估算：估算每項活動的時間，可以PERT方法進行； 利用PROJECT 2002等工具軟件，協助項目的時間管理； 利用甘特圖幫助跟蹤項目進度；

利用網絡圖及關鍵路徑分析，協助確定完成日期上的重要性或調整工期對項目工期的影響，以及處理關注的焦點活動。

需要注意一點，以前學習項目的時間管理工具及方法以后，就以為可以實現對項目的跟蹤控制了，其實不然，這些工具都是通過人來發生作用，活動也是由人來完成的，因此項目經理不能把太多心思花在工具上，而是學會利用工具來協調人與資源的矛盾沖突。4.項目的成本管理知識

對于項目經理在成本管理方面，就是要努力減少和控制成本，滿足項目干系人的期望。其過程包括： 資源計劃：即制定資源需求清單； 成本估算：對所需資源進行成本估算；

成本預算：將整體成本估算配置到各個單項工作，建立成本基準計劃；

成本控制：控制項目預算的變化，修正成本的估算，更新預算，糾正項目組成員的行動，進行完工估算與成本控制的分析。

在成本管理中涉及很多財務管理的概念、術語、基礎理論及方法與工具的使用，作為項目經理，對這些內容要熟悉，特別是掙值分析的相關術語及簡稱，如：BCWS、BCWP、ACWP、CV、SV、CPI、SPI等等，不光要了解這些術語的涵意，還要掌握他們的計算公式。5.項目人力資源管理知識

項目的人力資源管理就是有效發揮每個參與項目的人員的作用的過程。項目的人力資源管理過程包括： 組織計劃編制：形成項目的組織結構圖； 獲取相關人員：其中重點是業務相關人員；

團隊建設：明確每個項目干系人的責任，訓練與提高其技能，實現團隊的合作與溝通。

因為與人發生關系，其中首先是要明確各自的責任，這一點計劃編制時就要明確，可以通過項目管理軟件幫助項目經理提高效率，并能及時發現任務分解的合理性，最后形成合理的任務分解表。

同時，要通過有效的激勵方法來幫助項目成員實施項目計劃，提高效率。項目是通過團隊共同努力實現的，注意充分發揮團隊的作用，使團隊成員各盡所能是項目經理的挑戰。在處理過程中，爭取做到對事不對人，通過有效的會議來幫助項目實現溝通、檢查以及目標實現。6.項目的質量管理知識

項目的質量，理解為項目滿足客戶明確或隱含的要求的一致性程度。注意這里包括明確的要求，也包括隱含的要求。這對IT項目來說，如何滿足用戶隱含的質量要求，可能是IT項目質量失敗的重要原因?？赡芩_發的系統符合需求說明中的要求，卻與用戶實際的要求（包含隱含的需求中），相差很大，導致不一致，結果導致IT項目的失敗。

現代質量管理經過了一個發展過程，目前已建立起相對完善的質量體系，國際組織也有相關的質量文件，以評審普通的生產質量，如ISO2000系列質量標準；對軟件的生產質量，也有一些評價模型，如SQFD模型、CMM軟件成熟度模型等等。其中CMM成熟度模型分成五個層次：自發的、簡單的、有組織的、被管理的及適應的，分別標識為不同的級別。

對于項目管理需要制訂質量計劃，并應用質量保證的工具確保質量計劃的實施。在質量控制的過程中，有許多現成的工具與方法，如帕累托分析、統計抽樣和標準差等。要提高項目的質量，必須在領導中形成質量意識，通過建立一個好的工作環境來提高質量，通過形成質量文化來改進質量，是全面提升項目質量管理的關鍵因素之一。在以往所經歷的項目中，項目的質量管理基本上沒有得到重視，公司每年都在開展QC活動，該活動的目的就是改進質量，但活動成了科技創新活動，而更多的項目實施過程中，如何開展質量管理，卻未能有所體現，這也是值得探討的問題。

7.項目的溝通管理知識

項目的溝通管理非常重要，對項目經理而言，就如同前線指揮需要情報管理一樣，這是使整個項目組掌握項目信息，實施其他管理手段的基礎，所有的控制都有基于溝通基礎之上的。

在項目的開始，需要編制溝通計劃，包括什么時間、將什么內容、以什么樣的格式、通過什么樣的方式、向誰傳遞。在項目的溝通中，可以采用書面報告、口頭報告或非正式的交流，各種方式有利也有弊，關鍵看是否有利于溝通的效果。

溝通的復雜程度隨著對象的增加而快速增加，因此要通過適當的工具和手段，使面對面的溝通控制在一定范圍之內，盡量減少因無效溝通而給項目管理帶來的負責影響。

在溝通中，會議是有效形式之一。很多業務員人員喜歡通過會議，以簡單的形式化的語言描述項目的進展與項目中碰到的問題，而不喜歡技術化的圖表與文檔。8.項目的風險管理知識

當因為未能做好風險管理，導致項目的風險發生時，項目干系人將難以一下子接受風險發生的事實以及風險所帶來的損失，需要用更多的時間來調整心理狀態，才能恢復對項目的實施。

項目的風險管理不僅是在項目進行過程中，有效避免風險的發生；而且能在風險發生時，幫助我們用正確的心態去面對，而不會手足無措。很多項目的失敗，是因為風險發生時，對項目干系心理上造成的傷害，導致失去主觀 15 判斷能力，而作出錯誤的決策。從這種意義上講，項目的風險計劃的制定主要是為提高項目干系人的風險意識，只要有了足夠的風險意識，風險識別全面與否，在有些項目中可能重要性反而不是太明顯。

風險識別可以采用頭腦風暴法、經驗法則等方法，在識別這些風險因子之后，可以對這些因子加上權重，最后可以計算出項目成功的概率，并能據此決策項目是否應該開展、繼續或停止。識別風險因子之后，緊接著就是制定風險應對措施。根據風險發生的概率，產生的風險成本與收益，決定相應的應對策略，如風險處理、風險接受、風險改善等等。

實際工作中，可能識別到存在的風險，但卻不能加以正確處理。風險就這樣被層層傳遞。如因用戶參與不夠，導致需求不正確，進一步產生工期估計的失誤，結果是計劃的偏差，最后整個項目的結果產生偏差。因此，要注意從風險的源頭抓起，防止風險的層層放大。9.項目的采購管理知識

采購就是從外界獲得產品或服務。對于IT項目而言，采購變得越來越重要。目前絕大多數的IT項目都離不開采購管理，而且很多項目的主要內容就是設備采購或咨詢采購，對于企業而言，能否做好采購管理是保證項目成功的重點內容。

有效采購管理包括以下過程：

編制合理有效的采購計劃：這是項目管理的一個重要過程，即確定項目的哪些需求可以通過采購得到更好的滿足。在采購計劃中，首先是決定是否需要采購、如何采購、采購什么、采購多少、何時采購等內容； 編制詢價計劃：即編制報價邀請書RFQ或招標書； 詢價：進行實際詢價；

開標：評估并選擇供應商； 管理：對采購合同進行管理； 收尾：對采購合同進行收尾。

在整個過程中，容易忽視的兩個過程，一是采購計劃，二是合同收尾。采購計劃的編制，是采購管理整體按需求進行的前提，如果這一步做不好，其他都是白費勁；而在采購的合同收尾過程中，最容易忘記或做不到的就是采購審計。至于供應商的選擇等過程，在IT項目中，往往會過分重視技術，而忽略管理與成本。其實，管理與成本決定合同能否按期保持履行的前提。在我公司的實際情況中，一般項目以設備為主要成本時，往往就不再考慮其他內容，而僅是作為一般的設備采購，交會器材部門實施。因為不光沒能做到項目管理，亦未做到采購管理，所以這類項目雖然也實施完成了，但項目的實施質量總令人不太滿意。[結束語]

PMP認證要求申請者必須具備的專業經歷至少具有3年以上4500小時的項目管理經歷。之所以有這樣的要求，是因為項目管理不只是光靠讀兩本書，掌握幾個工具的使用就能勝任的，很多知識與經驗，需要在實際的項目管理實踐中體會與積累。

IT項目管理的五大錯誤

范圍管理：項目成功一環

定義并計劃一個項目只是成功管理一個項目的第一步。在你制訂工作計劃后，你就要按照這個計劃工作。你必須保證工作要在規定的時間和預算范圍內完成。一旦項目開始進行，客戶就會不斷要求你完成超出原來范圍的工作，或者和原來范圍不同的工作。這就是你必須要使用范圍變化管理的時候。如果你不善用此一技巧，你就會因為要完成比原先同意的工作，還要多上好幾倍預算和工作量因而疲于奔命。換句話說，你將會遭到很大的麻煩。

導致項目失敗的主要原因

一般IT經理都經歷過不太成功的項目。以下將討論五個最為常見的項目管理錯誤。切記：“糟糕的計劃是項目管理第一大失誤”。

范圍管理從范圍定義開始

定義項目范圍是定義一個項目過程中最重要的部分。如果你不確定你在進行的是什么，以及你所進行的項目底線，你就根本不可能成功。管理項目范圍是項目管理里最重要的一部分。但是，如果你沒有好好定義項目范圍，管理項目范圍幾乎就是不可能的任務。

定義項目范圍的目的，是把項目的邏輯范圍清楚地描述出來并獲得認可。范圍陳述被用來定義哪些工作是包括在該項目內，而哪些工作又是在該項目范圍之外。你能夠把項目范圍定義得越清楚，你的項目目標就會越明確。下面的信息整理會有所幫助。

? ? 范圍內和范圍外的交付使用類型（商業需求、目前狀況評估）

? ? 范圍內和范圍外的生命周期流程（分析、設計、測試）? ? 范圍內和范圍外的數據類型（財務、銷售、雇員情況等）? ? 范圍內和范圍外的數據來源或數據庫（賬單、總帳、薪水明細等。）? ? 范圍內和范圍外的組織（人力資源、制造商、供貨商等）

? ? 范圍內和范圍外的主要功能（決策支持、數據輸入、管理報告）

可行的范圍變化流程

項目經理和項目小組必須意識到范圍變化本身并沒有什么不對，也就是說在項目進行過程中修改范圍并不是個壞主意。事實上，在很多時候里，這也是一件好事。首先，客戶通常都不能確定其所希望的解決方案具有何種需求和功能。其次，就算客戶十分清楚終極目標，商業動態亦隨著時間不斷變化，因此項目的需求也會發生變化。

如果你不能夠容納變化，最終的解決方案就達不到預定的成效，甚至有可能完全無用。因此，你必須在需要時擁有改變項目流程的能力。如果項目經理對于項目變化沒有準備，問題將陸續發生。每一個項目都應該有一個流程以進行有效管理變化。這個流程應該包括確定變化、評估變化的商業價值、評估對于項目的影響，然后把這些信息提報給項目發起人進行評估。

發起人可以決定是否同意該變化。如果同意，發起人還應該考慮變化對項目的影響程度，然后追加預算或延長項目時間。

IT項目管理：問題、體系、方法

摘要：無論是在國內還是國外，項目管理的學科、技術和應用的普及與發展已經進入了一個飛速發展的時代，信息技術（Information Technology，簡稱IT）的發展又將IT項目管理推向了全新的應用高度。本文分析了IT項目管理技術及其應用與發展的關鍵問題，提出了基于系統集成理念構建的IT項目管理的體系結構和技術框架，肯定了IT項目管理的總體指導思想和實施策略是“需求牽引、效益驅動、總體規劃、分步實施”。

關鍵詞：信息技術

項目管理

體系結構 引言

人類進入21世紀，信息化成為我國全面構建和諧社會、快速發展國民經濟的著眼點。黨的十五屆五中全會就明確指出：“大力推進國民經濟和社會信息化，是覆蓋現代化建設全局的戰略舉措。以信息化帶動工業化，發揮后發優勢，實現社會生產力的跨越式發展?！秉h的十六大再次明確：“信息化是我國加快實現工業化和現代化的必然選擇。堅持以信息化帶動工業化，以工業化促進信息化，走出一條科技含量高、經濟效益好、資源消耗低、環境污染少、人力資源優勢得到充分發揮的新型工業化路子?！蹦壳叭珖舷赂餍懈鳂I、各個領域、各個層面的信息化建設正在如火如荼地進行著。

信息化項目的開展是以信息技術為支撐，以業務活動為主體，以現代化管理為指導思想的一項全新的、復雜的系統化工程。全新在于信息技術這一新生事物的飛速變化與發展，復雜在于信息技術、業務工作、項目管理思想的一體化融合與集成化應用，這正是IT項目管理問世的緣由。信息化建設的成功經驗告訴我們，結合信息化應用特點，采用項目管理技術而開發的專用方法對IT項目在計劃落實、質量跟蹤、成本管理和風險控制等方面進行管理，是保證IT項目達到預期目標的有效手段。

本文在項目管理知識體系的基礎上，介紹了IT項目管理的特殊性，回顧了學術界和工業界在不同方向上為解決這些問題所做的努力、獲得的成果。在系統集成理念的指導下，探討IT項目管理的體系結構和模型驅動的集成技術與方法。IT項目管理的特殊性

信息技術發展快、滲透廣等特點，使得IT項目與一般工程項目存在著明顯的差別，這種差異性造成了基于工程項目管理理論與經驗基礎上發展起來的項目管理知識體系在處理IT項目時面臨諸多的難題。

第一，IT項目的需求來源廣泛，涉及國民經濟的各個領域，幾乎所有領域都能夠和信息技術相結合而構成信息化項目。信息技術可以支持多種業務需求的發展：

（1）市場要求，如商業銀行提供網上支付業務，以支持越來越頻繁的電子商務活動。

（2）環境需求，如企業為了應對各國越來越嚴格的環境標準中對產品回收再利用的要求，啟動一個構建產品全生命周期管理系統的項目。

（3）經營需要，如一個傳統的大型商業企業開展網上銷售業務，以擴大其銷售收入。（4）技術發展，如飛機制造企業為了提高設計水平而開展虛擬制造系統的項目。

（5）用戶要求，如快遞公司要構建一個物流管理系統，以滿足顧客對跟蹤其委托的快遞物件過程狀態的查詢需求。

（6）法律需求，如一個城市為了減少合同犯罪的數量，而啟動企業印鑒信息系統；為了杜絕假文憑的泛濫而建 立文憑查詢信息系統。

正是由于信息化項目涉及到了幾乎所有的經濟領域，因此很難形成有針對性的規范和標準，這無疑增加了項目管理的難度。

第二，與一般工程項目所涉及的領域經過了長時期的發展、技術相對成熟不同，IT領域是目前發展最快、最活躍的領域，新的技術層出不窮，技術更新也非常迅速，因此IT項目開展過程中會具有更多的風險因素。有統計表明，每18個月，CPU的速度就會翻一番，與之關聯的計算機體系結構、軟件架構等也發展非常迅速。例如早期的集成信息系統采用大型主機帶終端的結構，隨著網絡技術和分布式計算技術的發展，出現了Client/Server結構的信息系統，而目前流行的架構則是在互聯網上基于Browser/Server結構的信息系統，C、C++、Java等各種開發工具更是一代代迅速更迭，各類操作系統、協議、標準等都是IT項目必須面對的，這些都會增加項目過程中的風險。

為了處理好技術發展迅速所帶來的問題，IT項目團隊必須在先進性、實用性、經濟性、成熟性等諸多方面進行權衡，片面追求技術的先進性往往會事與愿違。在保證項目所采取的技術具有相當的前瞻性、先進性和可擴展性、可集成性的同時，從需求出發，注意技術的可靠性、成熟性和經濟性。

第三，信息技術的應用主體在管理領域，管理信息系統包含了特定的管理理念，將這些管理理念同企業的發展戰略與業務邏輯進行整合是信息系統實施的關鍵任務。IT項目的阻力75%以上是來自人和管理的因素，因此，IT項目特別強調技術、管理與人的集成。如何處理好信息系統所涉及的人的問題是成功管理IT項目的關鍵。

從更深層的角度而言，經典項目管理理論是構建在土建工程項目的研究和實踐基礎上的，基本的項目管理方法并不能解決IT項目的特殊問題，例如：

（1）如何衡量項目進度的問題，土建工程使用完成土石方的量來標識工程進度，但是完成軟件90%的代碼編寫工作并不意味著還有10%的時間就可以完成軟件開發項目了。業界普遍認為在工程項目中廣泛使用的掙值法在IT項目中缺乏適應性。

（2）在計劃的調整方法上，土建工程在計劃拖期時，可以通過增加資源的方式來加快進度，但是對于一個軟件開發項目，如果出現同樣的問題，寄希望于增加編程人員的數量來追趕工期，只能造成更大的麻煩。

另外，除了信息技術之外，IT項目還涉及信息系統應用單位的組織、管理的調整與經營過程/業務流程的重構，單靠信息技術是無能為力的。因此，要成功管理IT項目，要成為IT項目的合格從業人員，需要一套全面的IT項目的知識體系與方法的支撐，它的內容將覆蓋項目管理、信息技術、現代管理技術、系統集成技術、軟件工程技術等多學科領域，這正是IT項目管理技術研究和實踐的目標與方向。IT項目管理技術的發展脈絡

目前在信息化領域的不同方向，許多學者開發了針對不同方面的項目管理方法，其中比較有代表性的是軟件項目管理和廣義的IT項目管理。

軟件項目管理是軟件工程和項目管理的有效結合，將項目管理中重視過程、重視計劃控制的觀點引入軟件工程領域，目的是控制軟件開發項目的成本、進度、質量、風險等問題。近幾年IT領域進一步引進全面質量管理理念，認為軟件開發企業自身質量控制體系和控制能力的優劣，將會極大地影響軟件產品的質量，這就要求軟件企業從修煉內功入手，也就是確認質量是控制出來的而不是檢測出來的，從根本上保證軟件產品的質量，由此提出了軟件過程改進和軟件能力成熟度模型(CMM)的概念。CMM基于經典的產品質量原理，建立了定量控制軟件過程的項目管理和項目工程的基本原則，與此同時，CMM有關能力成熟度的操作方法也被引入經典項目管理領域，用以測評承擔項目的組織的項目管理能力。

廣義IT項目管理是目前業界討論比較多的，也出了不少這方面的專著，其基本思路是將IT項目當做一般工程項目，使用PMBOK的方法體系，結合一些信息技術項目的案例，研究如何在信息技術項目中應用項目管理方法。

廣義IT項目管理是將所有與IT有關的項目不加區分地通盤考慮，包括IT產品開發項目的管理和IT應用項目的管理。實際上廣義IT項目可以細分出多個類別，各個類別之間的差距是非常巨大的。計算機硬件開發項目與一般家用電器產品的開發設計具有非常高的相似度，而軟件設計開發則完全不同，信息技術應用項目與上述兩個分支領域更是存在巨大的差異，因此廣義的IT項目管理實際上是在經典項目管理知識體系的基礎上，嘗試解決IT項目的具體問題。目前來看這種處理方式比軟件項目管理體系的針對性差很多，對其進行細分研究具有非常重要的意義。為了提高IT項目管理的針對性，提高解決方案的系統性，學術界和企業界在企業信息化、數字化城市與電子政務、數字化軍工、供應鏈與物流、電子商務等不同領域分別開展了體系結構、實施指南、參考模型等的研究和實踐，取得了一定的成果。IT項目管理的體系結構與方法論

系統參考體系結構是“一組用以描述所研究系統的不同方面和不同開發階段的、結構化的、多層次多視圖的模型和方法的集合，體現了對系統的整體描述和認識，為對系統的理解、設計、開發和構建提供工具和方法論的指導”。

系統參考體系結構為IT項目的管理提供了體系參考和方法論，經過各國專家的努力，已經形成了一批相當有代 表性和廣泛影響力的體系結構及其建模方法，并進行了大量的工業實踐，如CIM開放系統體系結構(CIM-OSA)、GRAI集成方法論(GIM)、IMPACS、普度參考體系結構(PERA)、集成的信息系統體系結構(ARIS)、通用企業參考體系結構與方法論(GERAM)，以及在我國提出的階梯形CIM系統參考體系結構(SLA)等。

在信息化項目管理過程中，系統的認識和構建是階梯上升的，在概念定義階段需要明確企業的戰略目標，并據此形成集成系統的目標，然后圍繞系統目標，從組織、資源、信息、產品、功能和經營過程等角度描述企業的現狀，形成對企業基本框架和運行機制的完整描述。在這些描述的約束下，采用合適的模型分析手段進行分析，找出現有系統中的問題進行改進，然后構建目標系統，形成多視圖的目標系統的描述。在形成目標系統描述時，除了使用各個視圖的描述方法外，還可以應用其他建模方法，以便提供對系統更為完整的描述。完成基于模型的設計后，就是在構建工具集的幫助下，將設計轉化為實際系統構建的技術說明，并構建實際系統。系統描述對于系統的運行仍然能夠發揮作用，可以作為實際系統運行的參考，并據此進行系統的優化與調整。

一方面由于信息化項目的多專業性，為了解決溝通和分析設計的問題，需要借助建模的手段實現對被處理對象系統的描述；另一方面由于信息化處理對象的復雜性，依據“化繁為簡、分而治之”的原則，使用多層次多視圖的模型來描述目標系統。視圖的劃分包括反映結構信息的信息視圖、資源視圖、組織視圖、產品視圖，反映系統時間和邏輯特征的過程視圖，結合反映系統功能結構和功能關系的功能視圖，以及反映企業經濟性和目的性的經濟視圖。靜態結構反映了系統的存在，行為結構給出了系統的屬性和運行方式，而評價結構則將系統和它的目的性關聯在一起。透過多視圖，為IDEF、ARIS等其他建模方法和工具的集成，對于制造企業原模型和企業本體的開發提供了技術框架。利用模型技術解決IT項目的交流、設計、技術轉移、系統構建乃至運行維護的問題是目前學術界和業界的普遍看法，模型驅動的體系結構是目前的一個研究和實踐的熱點。結論

隨著信息技術的發展和應用范圍的不斷擴大，IT項目管理越來越具有普遍性。分析IT項目的內在特征和特有問題，在項目管理知識體系的架構下，有針對性地開發適應性的理念和方法，將是IT項目管理領域的發展方向。

需要強調的是，信息技術本身的發展并不是IT項目的目的，滿足應用對象的需求和戰略目標才是其出發點，因此需要切實做好項目的需求分析，一切從業務工作的實際需求出發，在集成理念的指導下，充分考慮整個系統的集成要求，并在此基礎上選擇相關的成熟技術、應用系統和產品，同時做好項目的技術經濟分析，才能保證信息化項目發揮實效。國家863計劃CIMS主題專家組在大量信息化工程實踐的基礎上提出的“需求牽引、效益驅動、總體規劃、分步實施”的策略是IT信息化項目管理的總體指導思想。

成功的軟件項目需要幾點要求

現在,隨著國內的軟件企業的逐漸的增多,而且,外資企業也不斷的深入到我國的軟件領域,來分享我們的一些或大或小的軟件項目.我們始終有一中壓力的感覺.說句不好聽的話,我們現在的軟件整體水平和歐美的差距越來越大,和日本的差距也很大,為什么這么大,難道我們真的沒有能力把項目做好.或者我們根本做不好這個領域的項目.不是,我們做不好,而是,我們缺少的東西太多了.我就根據自己在日企做過的一些項目,來談談自己的一些個人所得吧.第一:自責

在項目無論是開始還是進行中,還是即將結束的時候,對項目出現的問題,大家一定不要互相推托責任,而是明確項目不是一個人的項目,是大家共同的項目.是一個集體性的活動.無論項目是成功還是失敗,大家都有不可推卸的責任.同時也希望項目負責人或者公司的領導多說幾句這樣的話,讓大家都有壓力的存在.不要把所有的責任都推托到項目負責人身上,難道你身上沒有責任嗎?都有責任的.多一些自責,建立自己的威信.有利于以后的項目的開展.有利于大家的合作.第二:責任

責任,是一個比較復雜的東西.成功了,大家都希望,有自己的功勞.而失敗了,大家都想把責任推托到別人的身上,和自己沒有任何關系.其實事實也并不是這樣.我想這個問題大家都比較明白.咱們舉一個比較簡單的例子:小偷偷東西.如果大家看到有人在背后偷別人的東西,都去制止一下,小偷不會這么猖狂.如果大家都把自己的東西放在比較隱蔽的地方,小偷也不會偷東西.如果國家對小偷的打擊力度在大一點.小偷也不會那么大膽了.好多如果,好多假設.但是,大家都有責任.小偷不偷你的東西,而你開心.小偷偷了你的東西.你傷心.如果，在如果.小偷也不會偷你的東西了.對不對.和我們的項目一樣,如果大家都有責任心,都想如何把項目做好.遇到一些同事的不積極,而去主動溝通和交流.遇到同事的問題,一起解決.那么,項目還會失敗嗎? 第三:任務

現在,大家把任務,都作為自己的任務.而別人的任務,和自己沒有任何關系.是不是真的沒有關系呢?咱們在舉一個 例子:在軟件開發的過程中,一個程序員沒有按照需求去寫,而你發現,而沒有制止.那么在寫完后.你的程序和他的程序進行,調試.你如何都不能調試過去,這個時候,你會不會想到是它的原因,而不是自己的原因,是不是為這個原因而花費掉好多金錢和時間呢?如果你在做好自己的同時,也會去幫助一些他,那么整體的效率是不是就提高了.希望大家在以后的項目開發過程中,不要把自己的任務,作為任務,實際上其他人的任務,并不是項目負責人一個人的任務,而是大家的共同的任務.第四:務實

如果把這兩各自分開來理解:任務和實際.意思就是說我們不僅要做好自己的任務,而且要切合實際.保證質量.保證進度.這可能需要大家的一個共同的心態吧.如果大家都把自己的工作保持完美,那么整體的工作一定會很完美的.什么都不能和務實相比較.在項目啟動的時候,大家要多進行交流和溝通,因為我們的目的只有一個.把項目做好.只有項目做好了.我們才可以做大項目.只有做大項目了,我們自己的能力才可以得到發揮.那么屬于我們的東西就自然而然多了.真誠希望大家能在一起互相討論一下,如何把項目做得更好,更美.其實,我們個人和日本以及歐美是沒有差距的.而是我們對問題的看法不一致.相信,我們整理的力量也會比他們厲害的.加油吧.讓我們一起努力吧.對軟件項目管理的探討

一、引言

隨著信息技術的飛速發展，軟件產品的規模也越來越龐大，個人單打獨斗的作坊式開發方式已經越來越不適應發展的需要。各軟件企業都在積極將軟件項目管理引入開發活動中，對開發實行有效的管理。我公司是西安一家中型軟件企業，在公司中已經實行了項目管理制度，軟件項目管理是整個項目管理中的一個重要組成部分。

從概念上講，軟件項目管理是為了使軟件項目能夠按照預定的成本、進度、質量順利完成，而對成本、人員、進度、質量、風險等進行分析和管理的活動。實際上，軟件項目管理的意義不僅僅如此，進行軟件項目管理有利于將開發人員的個人開發能力轉化成企業的開發能力，企業的軟件開發能力越高，表明這個企業的軟件生產越趨向于成熟，企業越能夠穩定發展（即減小開發風險）。

軟件開發不同于其他產品的制造，軟件的整個過程都是設計過程（沒有制造過程）；另外，軟件開發不需要使用大量的物質資源，而主要是人力資源；并且，軟件開發的產品只是程序代碼和技術文件，并沒有其他的物質結果?；谏鲜鎏攸c，軟件項目管理與其他項目管理相比，有很大的獨特性。

二、軟件項目管理的組織模式

軟件項目可以是一個單獨的開發項目，也可以與產品項目組成一個完整的軟件產品項目。如果是訂單開發，則成立軟件項目組即可；如果是產品開發，需成立軟件項目組和產品項目（負責市場調研和銷售），組成軟件產品項目組。

公司實行項目管理時，首先要成立項目管理委員會，項目管理委員會下設項目管理小組、項目評審小組和軟件產品項目組。

1、項目管理委員會

項目管理委員會是公司項目管理的最高決策機構，一般由公司總經理、副總經理組成。主要職責如下：

（1）依照項目管理相關制度，管理項目；

（2）監督項目管理相關制度的執行；

（3）對項目立項、項目撤消進行決策；

（4）任命項目管理小組組長、項目評審委員會主任、項目組組長.2、項目管理小組

項目管理小組對項目管理委員會負責，一般由公司管理人員組成。主要職責如下：

（1）草擬項目管理的各項制度；

（2）組織項目階段評審；

（3）保存項目過程中的相關文件和數據；

（4）為優化項目管理提出建議。

3、項目評審小組

項目評審小組對項目管理委員會負責，可下設開發評審小組和產品評審小組，一般由公司技術專家和市場專家組成。主要職責如下：（1）對項目可行性報告進行評審；

（2）對市場計劃和階段報告進行評審；

（3）對開發計劃和階段報告進行評審；

（4）項目結束時，對項目總結報告進行評審。

4、軟件產品項目組

軟件產品項目組對項目管理委員會負責，可下設軟件項目組和產品項目組。軟件項目組和產品項目組分別設開發經理和產品經理。成員一般由公司技術人員和市場人員構成。主要職責是：根據項目管理委員會的安排具體負責項目的軟件開發和市場調研及銷售工作。

三、軟件項目管理的內容

從軟件工程的角度講，軟件開發主要分為六個階段：需求分析階段、概要設計階段、詳細設計階段、編碼階段、測試階段、安裝及維護階段。不論是作坊式開發，還是團隊協作開發，這六個階段都是不可缺少的。

根據公司實際情況，公司在進行軟件項目管理時，重點將軟件配置管理、軟件質量管理、軟件風險管理及開發人員管理四方面內容導入軟件開發的整個階段。

在八十年代初，著名軟件工程專家B.W.Boehm總結出了軟件開發時需遵循的七條基本原則，同樣，我們在進行軟件項目管理時，也應該遵循這七條原則。它們是：

（1）用分階段的生命周期計劃嚴格管理；

（2）堅持進行階段評審；

（3）實行嚴格的產品控制；

（4）采用現代程序設計技術；

（5）結果應能夠清楚地審查；

（6）開發小組地人員應該少而精；

（7）承認不斷改進軟件工程實踐地必要性。

四、編寫《軟件項目計劃書》

項目組成立的第一件事是編寫《軟件項目計劃書》，在計劃書中描述開發日程安排、資源需求、項目管理等各項情況的大體內容。計劃書主要向公司各相關人員發放，使他們大體了解該軟件項目的情況。對于計劃書的每個內容，都應有相應具體實施手冊，這些手冊是供項目組相關成員使用的。

《軟件項目計劃書》一般應該包括下述內容：

1.引言

1.1計劃的目的

1.2項目的范圍和目標

1.2.1范圍描述

1.2.2主要功能

1.2.3性能

1.2.4管理和技術約束

2.項目估算

2.1使用的歷史數據

2.2使用的評估技術

2.3工作量、成本、時間估算

3.風險管理戰略

3.1風險識別

3.2有關風險的討論

3.3風險管理計劃

3.3.1風險計劃

3.3.2風險監視

3.3.3風險管理

4.日程

4.1項目工作分解結構

4.2時限圖(甘特圖)

4.3資源表

5.項目資源

5.1人員

5.2硬件和軟件

5.3特別資源

6.人員組織

6.1組織結構

6.2管理報告

7.跟蹤和控制機制

7.1質量保證和控制

7.2變化管理和控制

8.附錄

五、軟件配置管理

是否進行配置管理與軟件的規模有關，軟件的規模越大，配置管理就顯得越重要。軟件配置管理簡稱SCM（Software Configuration Management的縮寫），是在團隊開發中，標識、控制和管理軟件變更的一種管理。配置管理的使用取決于項目規模和復雜性以及風險水平。

1、目前軟件開發中面臨的問題

。在有限的時間、資金內，要滿足不斷增長的軟件產品質量要求；

。開發的環境日益復雜，代碼共享日益困難，需跨越的平臺增多；

。程序的規模越來越大；

。軟件的重用性需要提高；

。軟件的維護越來越困難。

2、軟件配置管理應提供的功能

在ISO9000.3中，對配置管理系統的功能作了如下描述：

。唯一地標識每個軟件項的版本；

。標識共同構成一完整產品的特定版本的每一軟件項的版本；

?？刂朴蓛蓚€或多個獨立工作的人員同時對一給定軟件項的更新；

?？刂朴蓛蓚€或多個獨立工作的人員同時對一給定軟件項的更新；

。按要求在一個或多個位置對復雜產品的更新進行協調；

。標識并跟蹤所有的措施和更改；這些措施和更改是在從開始直到放行期間，由于更改請求或問題引起的。

3、版本管理

軟件配置管理分為版本管理、問題跟蹤和建立管理三個部分，其中版本管理是基礎。版本管理應完成以下主要任務：

。建立項目；

。重構任何修訂版的某一項或某一文件；

。利用加鎖技術防止覆蓋；

。當增加一個修訂版時要求輸入變更描述；

。提供比較任意兩個修訂版的使用工具；

。采用增量存儲方式；

。提供對修訂版歷史和鎖定狀態的報告功能；

。提供歸并功能；

。允許在任何時候重構任何版本；

。權限的設置；

。晉升模型的建立；

。提供各種報告。

4、配置管理軟件PVCS 6.0

PVCS6.0是一套非常優秀的配置管理軟件，它能夠實現配置管理中的各項要求，并且能和多種流行開發平臺集成，為配置管理提供了很大的方便。

六、軟件質量管理

隨著軟件開發的規模越來越大，軟件的質量問題顯得越來越突出。軟件質量的控制不單單是一個軟件測試問題，在軟件開發的所有階段都應該引入質量管理。我公司除加強了國家標準“信息技術軟件生存期過程”（GB/T8566--1995）的規范管理外，還積極為通過ISO 9000.3做準備。

1、軟件質量保證計劃

在進行軟件開發前，需要有一個《軟件質量保證計劃》。目前較常用的是ANSI/IEEE STOL 730--1984，983--1986標準，包括以下內容：

1.計劃目的2.參考文獻

3.管理

3.1.組織

3.2.任務

3.3.責任

4.文檔

4.1.目的

4.2.要求的軟件工程文檔

4.3.其他文檔

5.標準和約定

5.1.目的5.2.約定

6.評審和審計

6.1.目的6.2.評審要求

6.2.1.軟件需求的評審

6.2.2.設計評審

6.2.3.軟件驗證和確認評審

6.2.4.功能評審

6.2.5.物理評審

6.2.6.內部過程評審

6.2.7.管理評審

7.測試

8.問題報告和改正活動

9.工具、技術和方法

10.媒體控制

11.供應者控制

12.記錄、收集、維護和保密

13.培訓

14.風險管理

2、質量管理的基本原則

?？刂扑羞^程的質量；

。過程控制的出發點是預防不合格；

。質量管理的中心任務是建立并實施文件化的質量體系；

。持續的質量改進；

。有效的質量體系應滿足顧客和組織內部雙方的需要和利益；

。定期評價質量體系；

。搞好質量管理關鍵在于領導。

3、軟件質量因素

正確性：系統滿足規格說明和用戶目標的程度，即，在預定環境下能正確地完成預期功能的程度。

健壯性：在硬件發生故障、輸入的數據無效或操作錯誤等意外環

境下，系統能做出適當響應的程度。

效率：為了完成預定的功能，系統需要的計算資源的多少。

完整性（安全性）：對未經授權的人使用軟件或數據的企圖，系統能過控制（禁止）的程度。

可用性：系統在完成預定應該完成的功能時另人滿意的程度。

風險：按預定的成本和進度把系統開發出來，并且為用戶所滿意的概率。

可理解性：理解和使用該系統的容易程度。

可維修性：診斷和改正在運行現場發現的錯誤所需要的工作量的大小。

靈活性（適應性）：修改或改進正在運行的系統需要的工作量的多少。

可測試性：軟件容易測試的程度。

可移植性：把程序從一種硬件配置和（或）軟件系統環境轉移到另一種配置和環境時，需要的工作量多少。有一種定量度量的方法是：用原來程序設計和調試的成本除移植時需用的費用。

可再用性：再其他應用中該程序可以被再次使用的程度（或范圍）。

互運行性：把該系統和另一個系統結合起來需要的工作量的多少。

4、軟件評審

軟件評審并不是在軟件開發完畢后進行評審，而是在軟件開發的各個階段都要進行評審。因為在軟件開發的各個階段都可能產生錯誤，如果這些錯誤不及時發現并糾正，會不斷地擴大，最后可能導致開發的失敗。下面這組數據可以清楚的看出前期的錯誤對后期的影響。

軟件評審是相當重要的工作，也是目前國內開發最不重視的工作。

（1）評審目標

。發現任何形式表現的軟件功能、邏輯或實現方面的錯誤；

。通過評審驗證軟件的需求；

。保證軟件按預先定義的標準表示；

。已獲得的軟件是以統一的方式開發的；

。使項目更容易管理。

（2）評審過程

A、召開評審會議：一般應有3至5人參加，會前每個參加者做好準備，評審會每次一般不超過2小時。

B、會議結束使必須做出以下決策之一：接受該產品，不需做修改；由于錯誤嚴重，拒絕接受；暫時接受該產品。

C、評審報告與記錄；所提出的問題都要進行記錄，在評審會結束前產生一個評審問題表，另外必須完成評審簡要報告。

（3）評審準則

。評審產品，而不是評審設計者（不能使設計者有任何壓力）；

。會場要有良好的氣氛；

。建立議事日程并維持它（會議不能脫離主題）；

。限制爭論與反駁（評審會不是為了解決問題，而是為了發現問題；

。指明問題范圍，而不是解決提到的問題；

。展示記錄（最好有黑板，將問題隨時寫在黑板上）；

。限制會議人數和堅持會前準備工作；

。對每個被評審的產品要盡力評審清單（幫助評審人員思考）；

。對每個正式技術評審分配資源和時間進度表；

。對全部評審人員進行必要的培訓；

。及早地對自己地評審做評審（對評審準則的評審）。

5、ISO9000.3軟件質量認證體系

ISO9000.3是ISO9000質量體系認證中關于計算機軟件質量管理和質量保證標準部分。它從管理職責、質量體系、合同評審、設計控制、文件和資料控制、采購、顧客提供產品的控制、產品標識和可追溯性、過程控制、檢驗和試驗、檢驗/測量和試驗設備的控制、檢驗和試驗狀態、不合格品的控制、糾正和預防措施、搬運/貯存/包裝/防護和交付、質量記錄的控制、內部質量審核、培訓、服務、統計系統等二個方面對軟件質量進行了要求。

6、測試

軟件測試是軟件開發的一個重要環節，同時也是軟件質量保證的一個重要環節。所謂測試就是用已知的輸入在已知環境中動態地執行系統（或系統的部件）。測試一般包括單元測試、模塊測試、集成測試和系統測試。如果測試結果與預期結果不一致，則很可能是發現了系統中的錯誤，測試過程中將產生下述基本文檔：

（1）測試計劃：確定測試范圍、方法、和需要的資源等。

（2）測試過程：詳細描述和每個測試方案有關的測試步驟和數據（包括測試數據及預期的結果）。

（3）測試結果：把每次測試運行的結果歸入文檔，如果運行出錯，則應產生問題報告，并且必須經過調試解決所發現的問題。測試結果：把每次測試運行的結果歸入文檔，如果運行出錯，則應產生問題報告，并且必須經過調 試解決所發現的問題。

七、軟件風險管理

軟件項目管理存在著風險，如果我們提前重視風險，并且有所防范，就可以最大限度減少風險的發生。進行風險管理是有效的手段。

1、風險的分類

根據風險內容，我們可以將風險分為項目風險（成本提高，時間延長等）、技術風險（技術不成熟等）、商業風險（銷售問題等）、戰略風險（公司的經營戰略發生了變化）、管理風險（公司管理人員是否成熟等）、預算風險（預算是否準確等）等。

另外，我們還可以將風險分為已知風險（如員工離職等）、可預報風險（從以往經驗得出可能有風險的）和不可預知風險。

2、風險的識別

風險識別的有效方法是建立風險項目檢查表。主要涉及以下幾方面檢查：

。產品規模風險檢查

。業務影響風險檢查

。與客戶相關的風險檢查

。過程風險檢查

。技術風險檢查

。開發環境風險檢查

。與人員的模式和經驗有關的風險檢查

3、風險評估

風險評估主要從下面七個方面進行：

。發生的可能性

。發生的結果（影響）

。建立一個尺度表示風險可能性（如，極罕見、罕見、普通、可能、極可能）

。描述風險帶來的后果

。估計對產品和項目的影響

。確定風險評估的正確性

。根據影響排定有限隊列

另外，要對每個風險的表現、范圍、時間做出盡量準確的判斷。

4、風險的評價

對風險的評價主要依據三個因素：風險描述、風險概率和風險影響。從成本、進度及性能三個方面對風險進行評價。確定項目的中止點，在中止點出再一次進行風險評價。

5、風險的駕馭和監控

風險的駕馭與監控主要要靠管理者的經驗來實施。如，某開發人員的離職概率是0.7，離職后會對項目造成一定的影響，則該風險駕馭和監控的策略如下：

。與在職人員協商，確定流動原因。

。在項目開始前，把環節這些流動原因的工作列入風險駕馭計劃。

。項目開始時，作好人是會流動的準備，采取一些措施確保人員一旦離開時，項目仍能繼續。

。制定文檔標準，并建立一種機制，保證文檔及時產生。

。對所有工作進行細微詳審，使更多人能夠按計劃進度完成自己的工作。

。對每個關鍵性技術人員培養后備人員。

在考慮風險成本之后，決定是否采用上述策略。

八、人員管理

1、對項目經理的要求

。能夠使小組每個成員都能發揮能力

。有一定的組織能力

。能夠使小組美味成員有成就感

。有提出解決問題方案的能力

。對問題的理解有一定的深度

。要能讓成員知道軟件質量的重要性

2、人員的通訊方式

（1）正式非個人方式，如正式會議等；

（2）正式個人之間交流，如成員之間的正式討論等（一般不形成決議）；

（3）非正式個人之間交流，如個人之間的自由交流等；

（4）電子通訊，如E-MAIL（電子郵件）、BBS（電子公告板系統）等；

（5）成員網絡，如成員與小組之外或公司之外有經驗的相關人員進行交流；

在實踐中發現，（5）的通訊效率最高，其次是（1）。

人力資源管理中的風險管理

在進行人力資源管理時，我們往往重視招聘、培訓、考評、薪資等各個具體內容的操作，而忽視了其中的風險管理問題。其實，每個企業在人事管理中都可能遇到風險，如招聘失敗、新政策引起員工不滿、技術骨干突然離職等等，這些事件會影響公司的正常運轉，甚至會對公司造成致命的打擊。如何防范這些風險的發生，是我們應該研究的問題。特別是高新技術企業，由于對人的依賴更大，所以更需要重視人力資源管理中的風險管理

給項目管理一雙慧眼

在諸多招聘廣告中，經?？梢钥匆娨恍㊣T軟件企業或集成商對他們的技術部門經理或者項目經理是這樣要求的：

有XX行業X年軟件開發經驗

精通XXX編程

語言掌握XXX數據庫??

這里面隱含著什么意義？那就是對于大多數IT企業，他們眼中的技術部門經理或項目經理都是技術高手，部門員工碰到什么搞不定的技術難題，這些經理一出手，一切搞定，贏來陣陣喝彩。這應該是這些經理們的第一職責嗎？顯然，有不少人都會說“No”。他們明白，對于這些經理們來說，管理好項目是更重要的職責。

正因為這樣，項目管理資質認證成為繼MBA之后的一大熱點，許多媒體紛紛刊登有關項目管理資質認證的各種利好信息，大有項目管理資質認證是解決一切項目問題之靈丹妙藥。其實，專業的項目管理是保障項目成功實施的關鍵因素之一，但并不是唯一因素，就象股份制只是使企業的所有制趨于合理化，但股份制并不能保證企業的經營一定能獲得良好的經濟效益。

雖然國內眾多IT企業都開始重視項目管理，也積極的讓員工們參加各種項目管理的培訓，但是在實際的項目執行中，往往還是會出現許多不盡如人意的情況，或者可以說，在注意項目管理后，許多項目的執行效率并沒有得到實質性的提高?；蛟S，我們需要一雙慧眼來仔細看看項目管理領域里存在的諸多關鍵點。

一、項目管理的理論、方法和工具

首先需要認清的是項目管理的理論、方法和工具的區別以及相互關系。

有不少人接受了一些關于項目管理培訓，或者閱讀了一些關于項目管理的書籍，他們基本上就知道項目管理需要制定計劃，需要進行跟蹤和監控，也了解項目管理包含哪些內容，比如說質量管理、變化管理、風險管理、合同管理等等。但是，當他們真正在一個項目中去進行項目管理，卻仍然會感到無從下手，無法通過執行項目管理的活動讓項目沿著正確的方向前進。

之所以出現這樣的情況，是因為他們所掌握的往往還只是項目管理的理論，但卻還沒有掌握項目管理的方法。而理論的可操作性往往很弱，因此出現這樣的情況也是非常正常的。用一句話說，掌握理論只是知道了“What”，但還不知道“How”。

而方法會告訴你應該如何去做，它解決了“How”的問題，比如說，項目管理分成幾個階段？每個階段又包含哪些活動？這些活動的執行順序是什么？這些活動之間的關系是什么？這些活動產生哪些計劃？諸如此類等等。這樣就具有很強的可操作性。但遺憾的是許多培訓或者書本，都還是保持在理論的層次。

在日常工作中，經常會聽到這樣一句話“計劃不如變化快”。甚至有人會拿這句話做為擋箭牌，拒絕進行積極的項目管理。實際上，沒有一個項目可以在執行中完全遵守一開始制定的計劃，尤其是在計劃制定得非常詳細的情況下。項目的執行過程中肯定會隨時發生各種變化的，因此在進行項目管理時，是一定要對項目進行監督和控制的，并設定一些節點根據項目的進展對項目計劃進行必要的調整；另外，在制定項目計劃時，還應該注意根據項目的規模和時間，從粗到細制定詳細程度不同的計劃，以保證計劃的指導作用和有效性。象這樣的情況，都是要有方法才可以解決的。出現問題，并不是“進行項目管理”的理念不對，而是沒有找到合適的方法。

在日常工作中，還常聽到有人說：“以后我們要加強項目管理，使用××軟件進行項目管理。”他們不但用軟件做出了計劃，也產生了甘特圖和關鍵路徑圖等等，但是實際的工作往往和他們所做出的計劃有很大差異，項目管理成效依然甚微。在這種情況下，他們所犯的錯誤通常是以為有了工具，就可以解決一切問題，而其實他們并沒有項目管理方法。實際上，工具是基于方法的，需要和方法相結合。使用工具是為了更好的貫徹方法，如果沒有相適應的方法，使用工具甚至會產生負面的效果。

因此，在具體項目實施中，一定要有清楚的項目管理方法，才可能用好工具；同時也必須注意到所選擇的工具和采用的項目管理方法是相匹配的，因為并不是所有的項目管理軟件都會適用于所有的項目，應該基于項目管理的特定需要選擇某個項目管理軟件，就象ERP系統實際上體現著某種企業管理的理念，每個企業在選擇ERP時都需要密切關注隱藏在它背后的企業管理方法，而不只是它需要的技術支撐平臺是什么？它的實施需要幾個人月？

二、項目管理方法和項目實施方法

其次，也必須看到，在一個項目的執行過程中還同時需要兩種方法：項目管理方法和項目實施方法。

項目管理方法是關于如何進行項目管理的方法，是可在大部分項目中應用的方法。而項目實施方法指的是在項目實施中為完成確定的目標如某個應用軟件的開發而采用的技術方法。項目實施方法所能適用的項目范圍會更窄些，通常只能適用于某一類具有共同屬性的項目。而在有的企業里，常常把項目管理方法和項目實施方法結合在一起，因為他們做的項目基本是屬于同一種類型的。

實際上，只要愿意，做任何一件事情，我們都可以找到相應的方法，項目實施也是一樣。以IT行業的各種項目為例，常見的IT項目按照其屬性可以分成系統集成、應用軟件開發和應用軟件客戶化等，當然，也可以把系統集成和應用軟件開發再分解成一些具備不同特性的項目。系統集成和應用軟件開發的方法很顯然是不一樣的，比如說：系統集成的生命周期可能會分解為了解需求、確定系統組成、簽訂合同、購買設備、準備環境、安裝設備、調試設備、驗收等階段；而應用軟件的開發可能會因為采用的方法不同而分解成不同的階段，比如說采用傳統開發方法、原型法和增量法就有所區別，傳統的應用軟件開發的生命周期可能分解成：了解需求、分析需求、設計、編碼、測試、發布等階段。

至于項目管理，可以分成三個階段：起始階段，執行階段和結束階段。其中，起始階段是為整個項目準備資源和制定各種計劃，執行階段是監督和指導項目的實施、完善各種計劃并最終完成項目的目標，而結束階段是對項目進行總結及各種善后工作。

那么，項目管理方法和項目實施方法的關系是什么呢？簡單的說，項目管理方法是為項目實施方法得到有效執行提供保障的。如果站在生命周期的角度看，項目實施的生命周期則是在項目管理的起始階段和執行階段，至于項目實施生命周期中的階段分布是如何對應項目管理的這兩個階段，則視不同項目實施方法而不同。下圖是一個簡單說明。

項目管理方法和項目實施方法對項目的成功都是有重要意義的，兩者是相輔相成的，就如管理人員和業務技術人員對于企業經營的意義一樣。

從IT企業的角度看，任何一個IT企業如果要生產高質量的軟件產品或者提供高質量的服務，都應該對自身的項目業務流程進行必要的分析和總結，并逐步歸納出自己的項目管理方法及項目實施方法，其中項目實施方法尤其重要，因為大部分企業都有自己的核心業務范圍，其項目實施方法會比較單一，在這種情況下，項目管理方法可能會弱化，而項目實施方法會得到強化，兩者會較緊密的結合在一起。只有總結出并貫徹實施符合企業自身業務的方法，項目的成功才不會嚴重依賴于某個人。在某種程度上，項目管理方法和項目實施方法也是企業文化的一部分。

從客戶的角度看，如果希望得到有保障的產品或服務，那就既需要關注提供產品或服務的企業是否有恰當的項目管理方法和項目實施方法，也必須尊重該企業的方法。

三、項目管理和項目的目標

有了合適的方法，還要清楚項目的目標，才能有針對性的進行項目管理。項目的目標是指項目做完后能夠支持客戶如何運作業務，或者客戶可以獲得具備哪些功能的產品等。

在項目的實際執行過程中，客戶方和項目執行方往往很容易產生爭執，出現“先君子，后小人”的情況：開始時大家都是一團和氣，或項目執行方為了獲得項目合同，先是猛拍胸脯保證沒問題，只要是客戶方的要求就承諾一定實現。但隨著項目的進展，才發現雙方的期望有著不小的難以彌補的差距。

這種現象的原因就是項目雙方并沒有定義清晰的、可實現的項目目標，換句話說，雙方并沒有真正在項目目標上達成彼此認可的一致。這樣就很可能出現不了雙贏的局面，要么是最后產生的結果不是客戶需要的，要么是客戶不斷的修改需求，導致項目的進度和質量受影響。項目目標既是客戶期望的體現，也是項目執行方期望的體現，因此它們應該是清晰的和可實現的。

從另一方面講，項目目標的實現是要受到一定制約的，那就是它應該在確定時間和財務預算內實現。有一些目標并不是不能實現，而是實現的代價太高，或者不能滿足進度的要求。這也是在項目實施中需要注意的。

同時，清楚的目標也是界定項目是否成功的客觀標準，是對項目進行驗收和質量管理的重要依據。設定清楚的項目目標，在某種程度上也會讓執行項目的IT人員更清楚要做什么，因為在一些項目中，往往會出現片面追求技術的先進和完美，而忽視項目的結果是為誰服務的。因此，為了保證項目雙方能夠在項目執行過程中愉快有效合作，保證項目的成功執行，雙方都應該注意盡快在項目實施初期定義清楚的目標。

四、項目管理與體系結構

“體系結構”這個詞語來自英文單詞“Architecture”，在計算機行業中也有譯為“系統結構”，許多行業都用到這個單詞。對于一臺計算機而言，它所關注的是如何合理的利用合適的軟件、硬件和固件來構造計算機，使之能夠以最好的性能價格比完成用戶所需要的任務。之所以特別提出“體系結構”，主要有三方面的原因：一個是IT應用范圍的擴大；一個是IT系統的復雜性和產品多樣性；一個是軟件技術的發展。

隨著IT技術的發展，以及人們對IT技術的理解和掌握，IT在各行業的應用都日漸的發展和成熟，越來越多的行業和人員都在利用IT技術提高他們的業務運作效率，也就產生越來越多的應用型項目。尤其是IT 應用發展到現在，一個IT系統所覆蓋的范圍日益擴大（范圍包括最終用戶數量、部門數量、地理分布等），比較常見的大型IT項目是一些新用戶希望在一個高起點上構建一個覆蓋多個業務部門的完整的新IT系統，或者一些用戶希望在原有分散的IT系統基礎上進行整合，從而構建成一個完整的IT系統。

對于這樣的大型項目，它們所覆蓋的業務部門很多，彼此的業務功能差異比較大但又存在相當的聯系，也就是說應用軟件的功能會比較多，且相互之間存在著一定關聯；而與之相適應的是應用軟件技術也發生了變化，多層結構、對象技術和組件技術等得到日益廣泛的應用，這就意味著必須對應用軟件的體系結構進行全面的分析設計如層次如何劃分、組件如何劃分等，才有可能產生一個較完善的應用軟件系統以滿足最終用戶的復雜需求。

同時從IT系統的基礎設施來看，其使用的產品也是多種多樣的，從服務器級的系統平臺、網絡平臺到客戶端等，有功能的差異，也有性能的差異，甚至還有采用異構技術實現的。如何讓這些產品構成一個和諧完整的系統為客戶提供方便、快捷的服務，就需要站在整個IT系統的高度上進行完整的分析設計，定義整個IT系統的組成內容，每個組成部分的功能和性能，相互之間如何進行數據交換。

如果沒有清楚的體系結構觀念，在項目實施中往往會出現這樣的情況：客戶今天說需要這樣的功能，項目人員就按照客戶的要求實現了；客戶明天再提出新的功能，項目人員也實現了。這看起來很簡單，“簡單就是美”——客戶也會感到很滿意，可是隨著項目的進展，情況就不那么美了，客戶開始發現“這兩個部分怎么不能連接”，進而提出要修改想法，甚至要求重新來過。整個項目實施就可能會出現“邊施工，邊設計”的情況，在這種情況下，項目的進度和開銷就很難有效控制，項目的資源可能被極大的浪費，而質量能否得到保證則存在很大的風險。

在體系結構清楚的基礎上，項目管理人員就可以根據一定的優先次序關系組織資源去建設IT系統的各個組成部分，從而保證項目的順利實施，而不致于出現“停工待料”甚至是“推倒重來”的局面。因此，在一個合理的項目組織機構中，必須保證項目經理和體系結構設計師的有效配合。

五、ISO9000、CMM與項目管理

從90年代中后期開始，眾多的IT企業象其它傳統企業一樣，開始關注國際標準組織頒布的ISO9000標準系列，并有不少企業通過了ISO9000認證。2000年后，國內大部分從事軟件開發的IT企業開始和國際接軌，重視CMM認證，并有許多企業走上CMM認證之路。這是非常好的一個現象，說明我們的觀念和意識在提高，在一定程度上意味著未來更加光明。但是也出現有的企業為認證而認證，而對于它們的客戶來講，所得到的產品或者服務并沒有因為這些企業通過某項認證而得到更好的質量保證。

為什么會這樣呢？其中很重要的一點是大家并沒有完全認識清楚ISO9000、CMM和項目管理、項目實施的相互關系，或者是不愿意承認這種關系。ISO9000針對質量保證和管理，而項目管理要考核的指標包括了時間（或進度）、成本、資源和質量，它不僅有質量管理，還包含了變化管理、風險管理、合同管理等，當然這些專項管理內容和質量管理是相輔相成的，或者說這些專項管理都是在為質量服務的（有時質量的范疇會被盡可能的擴大）。項目管理必然包含質量管理，而ISO9000標準并無法完全代替項目管理。

ISO9000是面向絕大多數企業的質量標準體系，是具有通用性的質量保證和管理標準，也因此它對某些行業可能缺乏針對性。雖然它也提出和軟件開發有關的指南，但從總的來看制造業最容易按照ISO9000標準實施。對于制造業和IT企業（軟件、集成），它們都需要質量體系，但是它們的質量指標并不完全相同，甚至可以說絕大部分是不同的。當然，如果在未來的某一天軟件和系統集成的技術方法真的發展到很完善就象工廠中的流水線一樣，那么ISO9000類似的質量標準對軟件和系統集成的衡量就很有意義了。

IT企業通過ISO9000認證，這個體系一定要和項目實施方法密切結合。從ISO9000的發展歷程我們或許可以看出，質量管理方法的完善在時間上是落后于項目實施方法（對于制造業，應該是產品的研發和生產方法）的完善的，因為要進行質量管理，必須清楚要管理的質量指標項和相應的衡量標準，而這些都必須在積累一定的開發生產經驗后才能提出和完善。因此對于IT企業來講，要有很好的質量保證，必須有相對清楚合理的項目實施方法，才有可 能把ISO9000標準真正貫徹到項目中，沒有項目實施方法，全面貫徹ISO9000標準是不切實際的。當然，這并不是說在沒有清楚合理的項目實施方法之前不能接觸ISO9000標準，不能應用ISO9000標準。如果在起步階段就開始接觸ISO9000標準，應該說會更有可能以全面的眼光去看待項目的實施以及項目管理和落實項目質量保證，也更有可能逐步去完善項目管理方法和貫徹ISO9000標準。

至于CMM，則是側重于對企業的軟件過程和軟件能力的評估評價，它提供的是一個軟件過程改進的框架，這個框架與軟件開發的生命周期無關，更與項目管理的生命周期無關，因此它并不是企業可以直接采納的軟件開發方法和項目管理方法。CMM做為一個指南能夠幫助軟件企業選擇、采納和合理使用一些先進的軟件項目管理方法和軟件開發方法，并在實踐活動中不斷提高和完善，從而極大程度地提高企業按計劃的時間和成本提交有質量保證的軟件產品的能力。如果一個企業真正達到CMM第四級，那么它的軟件開發方法和軟件項目管理方法應該是相當成熟的。

因此，CMM只是為客戶選擇軟件開發商提供一個參考標準，它并不等同于軟件產品的質量，也不能代表企業對所有項目的管理能力。或許有一天，會推出項目的能力成熟度模型來評估評價企業的項目管理過程和項目能力，那樣提高項目管理能力可能就更容易了。

六、結合實情逐步落實

完整的項目管理還包括一系列專題管理，如：質量管理、變化管理、風險管理、財務（或成本）管理等。這些專題管理并不完全停留在項目范疇內，它們的實施要依賴企業內部諸多相關部門的配合，如果一開始就準備在項目實施中進行全面的項目管理（包括諸多專題管理），會存在相當大的難度，因為很多企業的內部運作還不足以支撐這樣的全面項目管理，而且大部分人員也不可能在一開始就能全部領會這么多的內容。“羅馬，不是一天建成的?！?/p>

在推廣項目管理的過程中，經常會出現這樣的情況，有的人會委婉的提出意見：“你提出的這種項目管理觀念非常好，我也覺得應該這樣去做，可是我又感覺好像太理想化了”，或者“太理論化了”等等。也就是說，對于他們，思想上接受了，但行動上卻很難真正執行，思想和行動總是存在一定的距離。

項目管理對于很多人來說是一個新事物，觀念上接受它就需要時間，更何況是在行動上完全采納。應該承認的是，引進項目管理，無論是對于企業，還是員工，都是一種變化。但是，這種變化對個體來說是必須的，而對整個行業來說則是必然的。

要讓項目管理真正進入實際業務運作中，應該結合實情逐步落實項目管理理論中的各項內容。比較合適的步驟是：第一階段，先進行一般意義上的項目管理，做到可以清楚的定義項目的目標、范圍及工作成果等，在這個階段應該確保對項目管理方法和項目實施方法及體系結構有清楚的認識和理解，并掌握適當的項目管理工具；第二階段，全面實施質量管理；第三階段，全面實施變化管理、風險管理以及財務管理。

接下來，制定一個計劃，把“實施和推廣項目管理方法”做為一個項目去執行和管理，一步一步去做，就會獲得成功的。開始吧！

工程項目管理的新挑戰—可持續發展

摘 要:工程建設會引起一系列的環境問題,本文從可持續發展的角度,詳細分析了可持續發展項目管理的必要性,同時對項目中的各個參與方在項目中所負的責任加以闡述,并且對可持續發展的項目管理從資源管理、環境管理、技術管理和項目參與人員的管理等方面提出了相應的措施。

關鍵詞:可持續發展;工程項目管理

引言

從20世紀80年代的“魯布格經驗”到今天,項目管理對建筑業的發展起到了無法替代的作用。但是由于建筑業一方面為人類建筑美好的居住空間,同時又對環境產生一定的破壞。例如:由于建筑工業大量使用合成的化工材料,使得一些含有二氧化硫、二氧化氮、鹵化物的材料暴露在大氣中或與在自然的氧化作用下,釋放出相應的氣態化合物;在施工過程中產生的噪音污染;由于機械化施工而產生的機械廢氣;施工過程中產生的大量的固態建筑垃圾等。

因此,在人們日益重視環境問題的今天,可持續發展越來越成為人們關注的熱點,然而可持續發展關注的熱點主要集中于土地、自然資源等不可再生資源的可持續利用上,集中于經濟發展的可持續研究上,忽視了對人們行為的主要對象—項目進行可持續性研究,造成了許多項目僅僅是某些領導政績的標志,由此造成了資源的巨大浪費和環境的嚴重破壞。如何從可持續發展的角度來推廣和發展項目管理的組織方法和實施方法,是當今項目管理領域的一個很有意義的話題。1 可持續發展的工程項目管理的特點及含義

1.1 管理對象的泛化傳統意義中的工程項目管理的管理對象是工程項目本身,是通過可行性研究報告、項目計劃書、設計圖紙、設計規范、實物模型等定義和說明的。而可持續發展的項目管理的對象不但包括項目本身,還包括項目所處的微觀環境和中觀環境,就是說作為可持續發展的管理者在進行管理的時候,要將與工程項目所有的外部關聯元素全部納入考慮和管理范圍。

1.2 管理目標的泛化作為一般意義上的項目管理目標,是要實現項目的質量目標、經濟目標、進度目標?？沙掷m發展的項目管理的目標則遠遠超出了這三個目標,它還要實現整個微觀區域和中觀區域的環境質量目標、經濟效益的長期最大化,實現人與自然、人與社會的和諧統一。

1.3 管理組織的泛化可持續發展的項目管理需要參與方的全體緊密合作,任意一個環節的失誤都會造成整個管理的失敗。

1.4 管理方法的多樣性隨著電子技術的發展以及Ｉｎｔｅｒｎｅｔ的使用,現代的管理更加傾向于開放性、及時性、準確性,可持續發展的項目管理作為一種工程管理方式同樣如此,尤其是ＥＲＰ、ＣＲＭ等系統的應用。因此,可持續發展的項目管理實際上是將工程項目放在一個微觀或中觀的區域內,應用現代的生產技術,實現項目的成本、質量、進度和社會、經濟的系統目標,從而解決項目的環境與發展問題,實現項目和社會的可持續發展。影響可持續發展的項目管理的因素項目生命周期的各個階段猶如串聯起來的一組電路,任何一個環節出現問題就會破壞項目管理的可持續發展。

影響可持續發展項目管理的關鍵因素有許多,涉及項目的各個方面。對項目可持續性的影響因素包括:項目的經濟效益、項目的資源利用情況、項目的可改造性、項目的環境狀況、項目的科技進步情況、項目的可維護性等幾方面。當然,項目的可持續性發展還要受到管理、組織的影響,另外項目所在國的政策、政治狀況等都會對項目的可持續性產生影響,其影響不僅涉及項目的可持續性甚至關系到項目的生死存亡。可持續發展的工程項目管理中各方面的責任和義務

在任何一個項目中,項目的參加者包括:政府部門、業主、勘察與設計單位、監理單位、承包商、材料供應商、用戶等。因此每一個參與者的行為都將對整個項目的可持續發展有著極大的影響。

3.1 政府部門作為項目的審批者和監督者,社會公共利益的代表者,如果政府部門在項目的立項審批、規劃審批、設計審批等方面提高對項目的可持續發展的要求,同時積極開展“社會評價”,使得項目的發展有利于自然資源合理利用與生態環境保護,有利于我國的經濟建設,合理利用有限的自然資源,節約有限資源,保護自然與生態環境,造福人類,實現以人為本的可持續發展。同時,政府可以對采用了可持續發展的項目管理的業主給予稅收或融資方面的優惠措施,鼓勵業主采用可持續發展的項目管理方式。2004年4月中央查處了“江蘇鐵本鋼鐵公司違規建設鋼鐵項目”事件。雖然有部分人認為“鐵本項目”的下馬給國家帶來了很大的經濟損失,但是如果把這個事件放在我們整個國家的大的經濟環境下考慮,我們可以清楚的發現,“鐵本項目”的死亡正是政府在考慮了整個社會成本的前提下采取的最優的管理方式,可以說更大程度上是為了保證可持續發展。同年4月29日江蘇省委書記李源潮、省長梁保華在向全省領導干部通報查處鐵本項目違規建設情況時指出,鐵本集團違規建設一案性質嚴重,教訓深刻。江蘇省委、省政府從鐵本事件中總結的三條經驗教訓的第一條就是堅持以人為本,全面、協調、可持續的發展觀。

3.2 業主業主是項目的投資人,一般情況下在保證質量和功能的前提下,自然會考慮項目的經濟可行性,但是如果采用可持續發展的項目管理方式,則意味著業主要將該項目放置在一個更高的層次,即社會和自然的角度來進行項目的可行性研究、項目的設計、篩選項目的承包商、采用新的環保材料、建造技術和環保技術,因此也需要業主預支費用,加大了成本,但是由于采用可持續發展的項目管理方式使得整個社會的收益提高,因此,業主完全有可能從政府獲得相關的優惠政策,從而補償自己的損失。在2008年的北京奧運會的場館建設中,北京奧林匹克運動會組織委員會在項目的招標書中明確規定了投標者的環境保護責任。在項目的標書中,把執行環境影響評價制度、防治污染的工程設施與主體工程同時設計、同時施工、同時建成投入使用的制度,和投標者應承擔的經濟責任寫入了標書,要求投標人認真貫徹執行。同時制定了《奧運工程綠色施工指南》,對工程施工提出了環境要求。要求在施工過程中,嚴格執行環境管理措施,防止揚塵、廢水、施工垃圾、施工噪聲對周圍環境造成的污染。

3.3 勘察與設計單位勘察與設計單位雖然在作為業主的被委托方,必須考慮委托方的經濟利益,但是在某種程度上勘察與設計單位可以利用自己的專業知識,向委托方提供有利于可持續發展的項目管理方式的設計方案、新的環保材料、建造技術和環保技術。

3.4 監理單位監理單位的主要作用在于協調業主和各個項目參與者的關系,保證項目的質量、進度等公共利益。監理的成功與否,對項目的成功與否有很大的影響。監理單位在保證業主利益的同時,如果站在可持續發展的高度開展工作,實際是在行使其社會職責,因此政府應該從開發企業上繳的稅收中,拿出一部分用于對監理單位的報酬。

3.5 施工單位施工單位是完成項目的核心,項目在施工的過程中要使用的機械設備,會產生大量的廢氣、粉塵、振動、噪音,對環境產生極大的破壞,影響項目的可持續發展。如果項目中標的施工單位在業主、監理單位和政府法 規的約束下,采用可持續發展的項目管理方式,采用綠色環保施工建造技術,將進一步完善現有的施工方法,提高企業自身的核心競爭力。北京城建集團有限責任公司是一個以建筑為主、多元化經營的綜合性上市公司,具有工程總承包的一級資質,是全球最大的國際承包商之一。該公司之所以能夠在如林的強手中中得奧運會的主場館項目,應該說同該公司在施工中堅持采用綠色環保施工建造技術有極大關系。

3.6 材料供應方工程項目的施工建造需要大量的材料,而這些材料的使用者由于缺乏相應的專業知識和不對稱的信息,難以對材料做出非常準確的評價,而材料的供應方卻相反,他們擁有專業的技術設備、強大的信息庫,可以為業主、設計方、施工方提供綠色環保、符合可持續發展要求的新型材料。作為整個可持續發展項目管理鏈上的一個組成,材料供應方應該從法律上保證所提供材料符合可持續發展要求,政府需在稅收上給予優惠。

3.7 項目的使用者工程項目建成以后,作為項目的使用者則更大程度體現了項目的可持續發展性。因為項目使用者在使用的過程中,要消耗大量的自然資源(水、光等),同時會產生一系列的廢棄物。因此如何在使用的過程中,少消耗資源,少產生廢棄物或廢棄物再次利用程度,則是該項目可持續發展能力的一個很重要的指標?？沙掷m發展的工程項目的實施管理

4.1 資源管理項目資源管理主要指項目運營所需原材料和項目廢棄物的處理和再利用的管理,以及項目報廢后資源的再利用情況。原材料的可再生性和對環境的影響直接關系到項目的可持續性。由于項目的廢棄物處理和利用關系到項目對環境的影響,關系到項目的存在與可持續發展能力,所以項目的可持續必須考慮項目的廢棄物利用和處理狀況,并對其作出評價,通過它進一步評價項目是否具有持續發展能力。只有這樣,才能全面保證項目的可持續發展。

4.2 環境管理對環境的管理包括自然環境、社會環境、生態環境等幾方面管理。

4.2.1對自然環境的管理對自然環境管理是指可持續發展的項目管理要能夠防止或減少項目造成的環境污染,如光污染、噪聲污染、廢氣、污水污染等,達到項目與周圍自然環境具有相容性、協調性。管理的措施包括:在項目的可行性研究階段就要確定可持續發展的主題;在項目的設計、施工階段,要采用綠色環保的施工技術和材料;在項目的使用階段,要對產生的廢棄物采用分類、無害處理。只有當項目達到污染治理的標準,并且與周圍自然環境相協調,項目才具有持續發展的可能。

4.2.2對社會環境影響的管理對社會環境的影響管理包括對周圍居民生活的影響管理、對社會文化的影響管理、對社會經濟環境的影響管理等。管理的措施包括:保證項目與社會文化相容;與人們的生活習慣相協調;與經濟發展相吻合,并具有一定的前瞻性。一個項目只有符合社會文化要求,不影響居民生活,與經濟發展協調,才有存在的可能和繼續發展的必要。以舉世聞名的三峽工程為例。有材料表明,該工程建成后,將保護長江中下游廣大平原湖區,使國土開發長治久安;能夠充分利用原有農業基礎設施,加強農田水利基本建設,大大提高長江流域糧棉生產水平,促進農業生產的發展;可利用水庫1084ｋｍ2水域面積和上百條大小支流庫汊,發展漁業、養殖業、林業及畜牧業等,為食品加工和輕工業提供原料基地;萬噸級船隊可大半年直通重慶,宜昌以上航道將大大改善,促進長江流域和西南地區的開發和對外交流,使長江成為名符其實的“黃金水道”。

4.2.3對生態環境影響的管理項目處在一定的環境中,都或多或少地對生態環境產生影響,對生態環境影響的管理需要各個參與方的共同努力,尤其是政府部門應該通過相應的法律、法規明確規定對生態環境的保護,同時對破壞者給予嚴厲的處罰,對于主動進行保護的給予獎勵。同時要培養全社會的環保意識,使環保的觀念深入人心,形成全社會愛護環境、保護環境的風氣。

4.3 技術管理技術管理主要考慮兩個方面:項目設計的先進性和技術本身的先進性。項目的設計要具有科學性、超前性,并有發展余地。設計時除了要考慮人們現在生活需要,還要考慮未來需要,使項目具有一定的前瞻性,能與以后的經濟、技術、文化發展相銜接。設計的先進性還表現在盡可能利用已有的新技術、新材料、新工藝,并具有一定的超前性,為以后發展留出接口。技術本身的先進性主要指項目實施技術和運營技術的先進性。項目的技術先進性表現在已09資源環境與工程有先進技術成果的應用上,表現在為以后技術發展留出的接口上,項目的技術先進性使項目能經得起時間考驗,同時具有可持續發展前景。

4.4 項目參與人員的管理作為整個項目建設的核心主體,項目參與人員在實施建設過程中的每一個動作都會對項目本身產生直接的作用,直接對項目的可持續發展產生影響。項目可持續發展的資源管理、環境管理和技術管理都直接依賴于項目參與人員的實施。因此,行業主管部門很有必要在項目參與人員上崗之前對其進行相關的政策法規培訓,對其進行技術指導,提高素質,并在項目的實施過程中不定期的進行檢查,使可持續發展觀深深植根于項目參與人員的頭腦中。結束語

可持續發展戰略的核心是經濟發展與保護資源、保護生態環境的協調一致,讓人類子孫后代能夠享有充分的資源和良好的自然環境。工程項目的可持續發展管理雖然只是可持續發展的一個非常細小的分支,但是如果我們能夠“勿以善小而不為”的態度去認真的從事工程項目的管理工作,可持續發展在不遠的將來一定會成功。

管理的三化與六法

企業管理的“三化”與“六法”，是現代企業管理理論與中國企業管理的實踐相結合的經驗總結，是現代管理理論的中國本土化。

“三化”

（一）決策層級民主化

決策層級民主化是指企業在進行各層級的決策時，要充分占有信息，要使用有效的手段科學地處理信息。廣義的民主化還應包括利用外腦。具體地說董事會會議，對公司重大事務進行決策。在民營企業中，董事局主席一般是企業的主要業主，由民主決策進而正確決策，實際上是業主個人財務安全和增值以及企業發展的保障。所以，對重大事務的決策民主化表現為在董事局會議上按持有股份的多少行使投票表決權。重大的決策比如公司的兼并、合并、注銷等必須有 2/3 以上（指持有股份的總額達到公司股份總額的 2/3，而不是投票人數的 2/3）的股東同意。其他的決策要由 1/2 以上的股東同意才可形成；子（分）公司層級的決策主要是經營決策，重大事務由子公司董事會決策，日常事務由子公司經理辦公會決策；職能部門事務決策，由部門經理辦公會進行。

（二）管理層級制度化

隨著技術的進步、科學的發展，管理的方式、手段不斷改進和提高。現代化的管理手段開始在企業使用，對員工提出了更高的要求，管理層級的制度化勢在必行，即企業職工的行為的準則，它規定著人們在共同區作中應當執行的工作內容、工作程序和工作方法。也是企業生產經營活動和一切管理工作所應遵循的法規。現代企業的生產經營過程極其復雜，分工協作極為嚴密，沒有嚴格的規章制度，企業的生存在就沒有保障。所以管理層級必須按照規章制度辦事，逐項落實。一視同仁地堅持有章可依，有章必依，執章必嚴，違章必究，即“依葫蘆畫瓢”。只有按章辦事，才能保證政令暢通。

（三）操作層級選擇化

操作層級選擇化指把企業管理的每一項工作都細化和量化，每一個崗位都有明確的崗位職責和工作流程，形成企業的各項目作分工合理、科學、明確，從而達到企業管理科學化，人人有事干，事事有人管，沒有重疊，沒有空白。任何一個員工，即使沒有某一崗位所需要的專業知識，只要他翻開職位說明書，就可以利用手機撥打電話一樣。為此，員工要先逐字逐名學懂弄通公司的操作程序，再在工作實踐中切實的執行。每一個具體的人在每一個具體的崗位上，按最有效的程序去完成相應的工作，成為一顆螺絲釘。反對和禁止形式主義、花架子，自以為是，另搞一套。

“六法”

（一）折箭法

“折箭”講的是古代的一位老人教育他的兒子們團結起來力量大的故事。一個人折一捆箭是折不斷的，可是把箭拆散，一根一根地折就很容易折斷。在日常的企業管理中，事務性的工作很多，其中只有 20% 是重要的，而這 20% 的事務要花費 80% 的精力去處理，這也是所謂的猶太人“黃金法則”。對所有的問題，先解決普遍問題，再解決特殊問題；先解決今天存在的問題，再解決歷史上遺留的問題，而且要一個一個地解決。每一個職能部門，每一個員工，每天解決一件，整個公司就解決了很多事情。解決問題最好的方法就是現場辦公，現場辦公是事事落實的最好形式。

（二）試點法

一項新的決策，為了降低風險應該在小范圍內試點。先試點再總結，先創新再推廣。

（三）源頭法

凡事要抓住重點、抓住源頭、提綱挈領。即做任何事情的方法是：要抓主要矛盾，把問題簡明地提出來，不要胡子眉毛一把抓。面對紛繁復雜的工作，要理順思路，突出重點，抓大放小，層層剝皮。大與小的關系是西瓜和芝麻的關系，抓大放小就是抓住西瓜。企業發展的源頭是市場，基層是其效益的來源地，也是培養和鍛煉管理干部的源頭，一切工作重心應圍繞基層市場，以有利于基層市場的深入發展和擴張。

（四）重心下移法

管理重心下移，實際上就是企業組織結構和管理體制的創新，形成管理層級少而精的扁平式組織結構和科研、市場營銷兩頭大，中間管理層級小的啞鈴式管理結構。公司的領導，特別是高級小的啞鈴式管理結構。公司的領導，特別是高層的領導者應經常深入基層和市場一線，調節器查研究，解剖麻雀，現場發現問題，解決問題。管理重心下移還表現在公司的干部要直接參與管理部門或本公司的某一具體工作管理直通車，即最高決策層可以和最基層直接溝通。這是因為基層是和企業的上帝——消費者直接接角的地方；是員工成長的舞臺，發展的條件，也是員工積累經驗的源頭，所以企業的領導者要重視基層，特別是深入基層，解決實際問題。要把深入基層當作一項經常性的

工作，同時也要根據不同的時間段落實下基層的高層領導人員。每一高層領導應具體負責某一領域的工作，既有利于管理，又有利于辦事效率的提高。

（五）組織放大法

作為公司的領導，要抓住關鍵總是不要事必躬親，所有的工作要通過組織來作。企業的組織是配置資源和發揮能力的結構形式，是企業整體能力的整合機制現代企業的整體能力依存于三種組織聯系形式：正式組織主要是通過“職能角色”發揮資源的優勢作用；非正式組織主要是通過“自然溝通”發掘深層的內在活力；外部協作組織主要是通過“利益共享”實現合作競爭力。涉及企業內部事務的，企業領導要善于利用正式組織途徑解決問題；在適當垢機會和場合，通過恰當的方式，調動非正式組織成員的積極性和主動性；現代企業要生存，必然面臨從多的競爭者；分工又使得企業不能離開其他的合作伙伴而存在，所以企業還必須會利用外部協作組織來發展自己。

（六）高位嫁接法

企業要根據其發展的階段，實行“拿來主義”，站在巨人肩上，高位起步。技術要不斷更新，管理要不斷改進，營銷手段落要隨市場變化而變化。因為在信息時代，企業之間的分工將主要取決于企業之間的技術優勢，而不是資源優勢和資金優勢。技術開發引導著市場需求，技術變遷決定著企業產供銷流程體系和企業產業的發展方向，技術創新成為企業界贏得市場份額的根本途徑。企業的發展離不開企業在技術上的優勢，企業技術優勢的發揮離不開企業在管理上的創新。管理創新是企業根據產供銷技術的變遷和市場的變化，調整企業組織、企業經營管理觀念和管理方的過程。管理創新能夠打破陳規陋習，提高企業的運轉效率，能夠激發員工的技術創新意識并增強企業的活力

管理項目失敗的教訓

事后諸葛亮——管理項目失敗的教訓

能力的提高往往不是從成功的經驗中來，而是從失敗的教訓中來。

在克萊斯勒汽車公司，一位項目經理把辭職信交給當時的CEO艾科卡·李，表示要對自己所領導項目的失敗負責。艾科卡拒絕了，他知道這位項目經理還

會在汽車行業繼續工作，于是說：“我不希望這100萬美元的學費替別的汽車公司交，把教訓記下來，這是我們的財富。”這只是艾科卡帶領克萊斯勒走出困境的一個小插曲，卻令人回味。

許多項目經理不注意經驗教訓積累，即使在項目運作中碰得頭破血流，也只是抱怨運氣、環境或者團隊配合不好，很少系統地分析總結，或者不知道怎樣總結，以至于同樣的問題不斷出現。

可有可無的項目終結

項目總監王深剛進公司不久就接到一項任務，要求他盡快把項目成本估算的準確度抓一下。由于市場競爭激烈，公司不得不在沒有足夠信息和數據的情況下，短時間內做出標書。這使過去幾個項目的進度大大延誤，成本失控，公司管理層對各項目經理的信任大打折扣。

王深查看了公司的項目文件檔案，按ISO9000管理來看還是比較規范的。他找來正處于項目收尾階段的項目經理李明，請他寫一個項目總結。要求項目組所有成員都參與總結，一周之后拿出一份完整的總結文件。李明的項目比預定工期晚了1個月，成本比預算多出10萬元，但與大部分項目相比，這算是做得不錯的了。

頗使王深意外的是，兩天后一份兩頁紙的項目總結擺在他的辦公桌上，除了項目背景的介紹，就是一些原則性的套話，“加強合作、及時跟蹤”等等，沒有觸及任何實質性問題。毫無疑問，公司的項目經理們覺得“總結”可有可無、無足輕重，但是許多寶貴的經驗就是這樣白白地丟掉了。也許，靜下心來好好總結一下，我們可以學到很多東西。

會議主題：抱怨

不得已，王深親自召集李明的項目組開總結會。趙雁發牢騷說：“總結會不是已經開過了嗎？我手上又接了一個電廠項目，馬上要做詳細設計了，這會能不能不開？”王深沒有回答，把李明寫的報告遞給趙雁，問道：“這些體會，你都清楚嗎？”趙雁掃了一眼，雖然有些不太明白，但還是不以為然地說：“這是項目經理的事，我們組員無所謂。況且，大部分項目根本就不寫總結報告。想寫也沒有時間！”

“這就是大家沒長進的原因！” 王深不客氣地說，“超支10萬元是怎樣造成的？是選擇分包商安裝監控設備但又無法控制領料造成的！本想賺取材料差價，卻沒考慮潛在的風險?！蓖跎罱又f：“我聽說以前公司發生過類似的事情，不幸在我們的項目上又發生了。要是總結就這樣草草了事，下次還會有！”

大家逐漸意識到總結的必要性，聯想起以往工作，紛紛發表意見。話匣子一打開，總結會變成了一個控訴會。

在項目總結會上，這是常有的事。項目組把所受的委屈，尤其是來自客戶方面的，統統發泄出來。但結論往往沒有什么建設性，大都是“不要相信分包商的承諾、對客戶的無禮要求應拒絕”等沒有指導意義的結論。

王深鼓勵大家暢所欲言，他說：“總結的意義在于判別結果和我們預想的是否一致，以便調整我們今后做計劃的方法，為以后的項目工作打基礎。大家最好比較一下項目計劃和實際執行的差距?！?/p>

李明不好意思地說：“我們的計劃只更新過一次，大家基本不太用?！?趙雁插話道：“這是因為計劃與實際太離譜，連我們自己都不相信它?！?/p>

王深并沒有責怪，他說：“對于新的項目，我們的報價、人員安排、進度控制大都基于假設，這很正常。現在我們可以回過頭來，逐一檢查當初的假設與現實情況的差距。下次同類項目，就可以大大提高計劃的準確率，尤其是在成本估算和報價策略上，也就能提高中標率了?！?在王深的提醒下，大家的思路逐漸清晰，原來帶有發泄意味的各種意見也變得有些系統化了。趙雁覺得大家的建議在新接的項目中就用得上。

王深特別強調了風險識別意識。他說：“這次在消防審批上的時間比預計的要長很多，影響了回款，這應該加在風險列表中。” 李明補充道：“應該盡早更換電纜供貨商，我們一直希望他們能補上進度，所以遲遲沒有啟動備選供貨商。雖然最后還是換了，但是耽誤了兩周的工期?！?/p>

一份非常不錯的總結報告出來了，超過了10頁，特別精彩的是對風險防范中啟動應急計劃的體會以及工程量的估算部分。

成長的煩惱

筆者曾在一家外企工作，看到其完備的計劃書、風險分析、文檔模板，由衷地感嘆總結工作的艱辛。許多項目經理不是意識不到總結的重要性，而是疑慮所付出的勞動太多，是不是值得？

一位著名作家在參加亞洲作家筆會之后曾有這樣的感想：我們代表團成員的論文動輒就是綜述、概述和趨勢分析，而少有像日本學者所做的編年史、作家生平考證之類的基礎數據積累。這或許是在中國文化某些領域我們的研究水平反而比海外落后很多的原因吧。

項目管理水平的提高，離不開項目總結這項基礎工作。這是任何教科書都無法替你做的。如果我們沒有諸葛孔明的前瞻智慧，那么項目總結上的亡羊補牢或許也能起到勤以補拙的效果。

我們往往只有在自己碰得頭破血流后才真切體會到別人的忠告是多么正確。在經歷了無數的成長的煩惱之后，我們才能體會“不聽老人言，吃虧在眼前”這句老話的味道。

對于管理項目，你還想重蹈覆轍嗎？

論項目管理中的量化管理

項目管理理論是一門綜合多門學科的新興研究領域，包括項目綜合管理、項目范圍管理、項目時間管理、項目費用管理、項目質量管理、項目人力資源管理、項目溝通管理、項目風險管理和項目采購管理等九大知識領域。傳統的項目管理論著都重點著眼于這九大知識領域來講解項目管理，卻忽視了一項基礎性工作：量化管理。缺乏量化管理，項目管理只能處于一種“混沌”狀態。以IT項目為例，據稱只有26％的IT項目成功地實現了范圍、時間和成本目標，剩余的74%都有不同程度的失敗。而如果采用了量化管理，項目管理的全過程就會變得“可視化”，發現問題也可以“讓數字說話”。

一．量化管理發展現狀

當前，在項目管理過程中實行量化管理方興未艾，較為典型的理論有六西格瑪管理和CMM/CMMI 體系。

六西格瑪是一項以數據為基礎，追求幾乎完美的質量管理方法。西格瑪是一個希臘字母σ的中文譯音，統計學用來表示標準偏差，即數據的分散程度。對連續可計量的質量特性：用“σ”度量質量特性總體上對目標值的偏離程度。幾個西格瑪是一種表示品質的統計尺度。它有別于其它的質量管理方法，是依據嚴格的數據采集和統計分析，找出誤差的根源，并尋求消除這些誤差的方法，根據顧客的要求來確定的管理活動。

實施六西格瑪包括五個階段：定義(D)，測量（M），分析（A），改進（I），控制（C），其數據流程如下圖所示：

以上這些過程并不是單一的，獨立的，而是相互關聯的統一體（如圖1）。由這些過程很容易看出，六西格瑪是一種基于數據的決策方法，強調用數據說話，而不是憑直覺、經驗辦事。其基礎是需求，作用及過程的量化，從

而可以客觀地反映我們的現狀，引起人們的關注。數據定義抽樣數據收集統計分析試驗設計控制數據定義測量分析改進控制。

CMM(Capability Maturity Model)是卡耐基梅隆大學軟件工程研究院（SEI，Software Engineering Institute）受美國國防部委托制定的軟件過程改良、評估模型，也稱為SEI SW-CMM，（Software Engineering Institute SoftWare-Capability Maturity Model)。該模型于1991年發布，目前修改至1.1版，并發展成為系列標準模型。全世界已經有1萬多家軟件企業經過CMM評估。CMM的核心是把軟件開發視為一個過程，并根據這一原則對軟件開發和維護進行過程監控和研究，以使其更加科學化，標準化。使企業能夠更好的實現商業目標。

CMMI(Capability Maturity Model integration)是為了解決現有不同CMM模型的重復性、復雜性，并減少由此引起的成本、改進過程，由美國國防部出資，委托美國卡耐基梅隆大學軟件工程研究院（SEI）開發的能力成熟度模型集成，它將軟件CMM2.0版草案C(SW-CMM)、EIA過渡標準731（系統工程CMM）及IPD-CMM集成為一體，同時，還與ISO15504相兼容。該模型廣泛適用于政府機構、軟件和硬件開發公司。

無論是CMM還是CMMI，都有個共同特點，就是關注量化管理，在CMM/CMMI模型中，企業過程能力等級越高，對量化管理的要求就逐步提高，當達到第4級“已管理級”（Managed級）時,要求針對組織過程的每一個階段都進行了監控、取樣和定量分析，形成了一個關于產品制作和維護流程的數據庫并不斷更新，以保證組織過程保持較高的質量。

他山之石，可以攻玉，可見，在項目管理中引入量化管理也是大勢所趨。

二．項目管理中需要量化管理的領域

項目管理知識體系中，涉及到需要量化管理的領域非常多，從事前管理和事后管理的角度來分，可以分為估算和度量兩大類。估算是以實際統計調查資料為基礎，根據事物的聯系及其發展規律，間接地估算和預計有關事物的數量關系和變化前景。而度量則是依據特定的標準，衡量當前的事物與標準之間的差異。項目管理范圍中，有如下階段需要應用估算技術：

1．項目范圍估算

對項目預期的范圍進行評估是項目的基礎，范圍估算失誤將給項目帶來不可挽回的損失。

2．項目成本估算

成本估算估計完成項目各活動所需每種資源成本的近似值，成本預算的過程是把估算的總成本分配到各個工作細目，建立基準成本以衡量項目執行情況?？梢姵杀竟浪愕臏蚀_性直接決定成本的預算情況。

3．項目進度估算

項目管理的關鍵要素之一就是時間管理，也即進度控制。準確地估算對制定項目計劃、監督項目執行都有重要的意義。

4．項目風險估算

對風險識別不到，或對風險可能造成的影響估計不足都可能導致項目失敗，因此對項目風險的量化估算更是至關重要。

定義項目、制定項目計劃的時候需要進行項目估算，而項目執行過程中的跟蹤監督過程則離不開度量。良好的項目管理主要針對項目要素進行跟蹤度量，通過分析度量數字就可以及時發現項目進展中存在的問題，從而有針對性地制定解決方案。通常需要度量的項目要素包括

1．項目進度度量

對項目進度進行定期的跟蹤度量，及時發現當前進度與計劃的偏差，可以及時采取措施，及時趕工或調整進度計劃。

2．缺陷度量

項目的成敗直接取決于客戶滿意度，客戶滿意度是個難以量化的指標，而項目成果——產品的缺陷密度直接影響著客戶的滿意程度。度量產品的缺陷密度，可以有效地了解項目完成的質量。

3．項目工作量度量

工作量是衡量項目成本、人員工作情況的基礎，準確地度量出項目真實的工作量，既可以掌握當前項目的情況，對于今后估算其它項目數據也有重要意義。

4．人員生產率度量

人力資源是項目中最為重要的資源，掌握人員的生產能力對于項目管理中人員管理、資源管理都有重要的參考價值。

三．量化管理的方法

量化管理涉及范圍廣、意義重大，應該如何進行量化管理呢？有很多科學的方法可以輔助項目管理人員進行估算和度量。

典型的估算方法有：

1.Delphi法

Delphi法是最流行的專家評估技術，在沒有歷史數據的情況下，這種方式可以減輕估算的偏差。Delphi法鼓勵參加者就問題相互討論。這個技術，要求有多種相關經驗人的參與，互相說服對方。

Delphi法的步驟是：

1、協調人向各專家提供基本情況介紹和估計表格；

2、協調人召集小組會各專家討論相關的因素；

3、各專家匿名填寫迭代表格；

4、協調人整理出一個估計總結，以迭代表的形式返回專家；

5、協調人召集小組會，討論較大的估計差異；

6、專家復查估計總結并在迭代表上提交另一個匿名估計；

7、重復4-6，直到達到一個最低和最高估計的一致。

2.類比法

類比法適合評估一些與歷史項目在應用領域、環境和復雜度的相似的項目，通過新項目與歷史項目的比較得到估計數據。類比法估計結果的精確度取決于歷史項目數據的完整性和準確度，因此，用好類比法的前提條件之一是組織建立起較好的項目后評價與分析機制，對歷史項目的數據分析是可信賴的。

以某軟件項目的規模估計為例，類比法的基本步驟是：

1、整理出項目功能列表和實現每個功能的代碼行；

2、標識出每個功能列表與歷史項目的相同點和不同點，特別要注意歷史項目做得不夠的地方；

3、通過步驟1和2得出各個功能的估計值；

4、產生規模估計。

針對項目工期估計，常采用PERT(計劃評審技術，Program Evaluation an Review Technique)技術進行估算。

針對項目成本估計，較好的方法有經驗估算法、因素估算法和WBS基礎上的全面詳細估算法等多種方法。

度量不一定需要特定的方法，度量的關鍵在于數據采集與分析。度量的數據是根據管理的需要采集的，通過對采集到的數據統計分析，就可以掌握項目的情況。

四．量化管理實例

以某系統集成項目為例，可以看一下怎樣在項目管理中應用量化管理。

項目名稱：某大樓綜合布線系統集成

項目啟動，首先估算項目范圍、進度、成本，以便制定項目計劃。由于該項目屬于典型的系統集成項目，采用“類比法”進行估算。估計該大樓項目范圍約需為2000個點布線，時間約需1個月，成本約為300萬。項目組根據估算結果編制項目計劃。

項目實施過程中，針對缺陷數量采集數據進行度量，從而管理項目質量，獲得采樣數據如下圖所示：

可見，缺陷數量始終控制在允許的上下限范圍內，該項目質量獲得了較好的控制。五．結束語

項目管理是個不斷完善的知識領域，引入量化管理，強化量化管理，可以使項目管理知識體系發揮更大的作用。

淺談如何實行有效的項目管理

目前隨著公司的快速穩定發展和在系統工程業界的影響不斷擴大，簽定的項目呈現出以下特征：

1.系統規模大

2.工期緊張

3.需要各方面的配合多。這就對我們的項目經理提出了更高的要求。

如何實行有效的的項目管理，從我個人的理解，一個項目實施的過程中，最重要的是對目標的實現。對于項目目標的明確劃分和界定就成為了如何能夠達到項目目標的關鍵的第一部，同時對于項目實施的每一步都是圍繞著項目目標進行的。其次是對進度的控制。對于實現項目目標的基礎上，是否按時完成了項目的目標就成為了檢驗項目是否成功的標準，按時完成目標關鍵是對項目進度的合理控制和把握。再次是對成本的控制。成本的控制包括對資源的申請、合理調配和合理利用；對項目資源之外的各方面成本控制。

另外，在項目實施中最關鍵的一點保證就是客戶，因此同客戶保持良好的客戶關系，時時體現為客戶著想，讓客戶滿意也是檢驗項目是否被客戶認可的一個關鍵因素。下面就圍繞著以上幾方面進行簡單的介紹。

1.目標管理。每一個項目的實施從與客戶接觸到合同談判到具體實施都有一個明確的總的系統目標。而在項目實施中，將總的系統目標分解為幾個階段目標進行，每個階段目標再分解為若干小的目標，最終分解為每個人在一定時間內能夠看到并達到的目標而加以實現。同時每一步的目標分解和確定都經過和客戶方的協調和確認，以保證總目標的實現得到客戶的認可。對于每一步目標的變更以及同客戶間任務的分配也經過同客戶多次的會議討論確

定。

2.時間控制。項目的時間控制是同目標管理密不可分的，每一步的進度控制都是基于一個特定的分解目標而確定的。目標的時間計劃制定要求切合實際，并且在開始階段要求嚴格實行按時完成，這樣到后面可控化的程度就高多了。對于項目的時間計劃也要求分解到每個人在一定時間內能夠完成一定的目標。同時對于進度的控制要求隨時檢查時間計劃是否按時完成以及同計劃間的差異，隨時采取措施調整相應計劃以保證總體計劃的可控性。

3.規范化的項目管理。項目按照規范化的項目管理方法進行管理能夠很好的對項目進行控制。首先從項目的綜合計劃和質量計劃，將項目的總體目標和分解目標以及時間計劃都紀錄下來，以保證項目的實施。其次對項目按周計劃、周總結以及每個人按照周計劃、周總結的管理方式進行管理控制，隨時記錄下文檔，以保證項目進程的可控性。同時隨時監控項目中可能出現的異常情況，比如硬件、軟件問題；人員資源問題等等，出現問題及時予以解決并記錄下來，及時予以調整項目控制保證項目進程的實施。

4.良好的客戶關系。在一個項目中保持良好的客戶關系可以說是本項目能否成敗的基礎，因為項目需要配合的方面很多，任何一方面的問題都可能導致項目的拖延。從項目一開始，根據我們的經驗積極為客戶著想，設計改進適合客戶的系統，客戶對我們的努力滿意，也就為能同客戶更好的合作奠定了基礎。

5.人員協調。隨著項目規模的擴大，項目組成員的數量也會越來越多，如何協調好每個人發揮每個人的充分作用就很大程度上決定了項目的成敗。因此項目組從管理上嚴格每個人的任務職責分工。從生活上關心每一個員工，讓每一個員工都成為朋友，幫助每一個員工前進，也使得項目組的情緒穩定，遇事不會影響到整個項目組，保證了項目組的活力。同時，要把項目組成員的定義范圍廣義化，即直接面對用戶的項目組成員和間接面對用戶的的項目組成員，如生產部門、采購部門、計劃部門、財務部門、質量部門等等，充分發揮它們的協助、指導和監督作用，對高效率、高質量完成項目目標起到至關重要的作用。在這里，我也希望我們這些間接面對用戶的部門能夠從思想上認識到它們自身也是項目組的一分子，多從項目組的角度考慮問題，為用戶提供出色的全面的服務。

從上面幾個方面闡述了我對如何實行有效的項目管理的看法，其實方法還有許多，但我認為最最關鍵的是我們對待用戶的看法和態度。應該這樣理解我們的用戶：他們不是我們工作的障礙，而是我們工作的目標；我們不是通過為他們服務而給他們恩惠，而是他們給我們為其服務的機會而給予我們恩惠。只有樹立這樣的觀念，“真誠的為每一位用戶設想”才不是一句空話，我們和利時公司才能在如此激烈的競爭市場找到長久的立足點。

淺談項目管理

一.商務談判

1.作人的姿態

作人似乎跟商務談判不太有關系，很多技術人員相信PM需要的是本事，是如何做好一個項目，而不是會搞好關系弄的四平八穩的人。隨著PM在中國的悄悄興起，越來越多的PM開始在老總的授意下參與商務談判，和銷售們一起打單子，這就比較實在的需要PM們去揣摩客戶的心理。揣摩客戶心理需要有多方面的知識，需要深度和廣度，然而，最重要的仍然是作人。如何放下架子，降低作人的姿態，對從技術人員轉型的PM們來說，是至關重要的。

降低作人的姿態需要從多個方面去實施，最主要應該記?。喝瞬豢擅蚕?，更不可以地位衡量。很多公司為了保持公司形象，會統一叫員工打扮的好看一點，看起來象個白領的樣子。然而，老板多半是沒有約束的。中國改革開放才二十年，很多有錢的老板實業家文化層次都不高，往往是當大學生們只會把屁股坐在板凳上肆意揮霍父母辛苦積攢的財富時，他們已經在各地奔波，積累豐富的商業經驗并對金錢，人生和社會的本質有了充分的認識，形成了自己穩定的思維框架。這些人，很多都是穿著舊舊的衣服，戴著破破的手表，說話的時候經常會帶上三字經，鉆進上海的人堆里，搞不好你會把他當成民工。因為到他們所處的社會地位，已經不需要任何華麗的外表來襯托自己的身份，他們有的是底氣。對PM來說，這是個非常危險的挑戰。雖然說項目在初期有意向時會對對方的人事和關鍵人物有一定的了解，然而大項目里能說的上話的人太多了。上海人最瞧不起的就是土氣，很多人談項目的時候看到民工或很俗氣的表現不免會皺皺眉頭，往往在皺眉頭的時候就失去了項目，也就是失去了市場和金錢。PM必須作到能與每一個層次的人交談，尤其是看起來比自己層次要低的群體，哪怕是公司里掃地的阿姨。只有作到謙虛謹慎，不擺架子，尊重別人，才會得到別人的尊重，才有機會贏得項目。鼻子比眼睛高的人只會把自己的鼻子撞扁。

2.豐富的知識面

光尊重別人還不足以贏得項目，準確的說是贏得對方關鍵人物的信賴。PM一般用不著陪客戶喝酒吃飯，那是銷售們的事情，但是PM和客戶討論問題可能是最多的。討論問題的時候就是機會，如何投其所好，是一大關鍵。金錢與美女依然是常規的敲門磚，然而這種傻瓜也知道的辦法人人都會去做。老板的關系也只是一個方面，如今的大

老板，哪個沒有關系？同等條件下PM憑什么去勝過別人一籌？

我一個朋友（PM）打一個單子時，發現對方對什么都不太感興趣，費了很大力氣也找不到突破口。對方這個人非常順利，金錢地位美女樣樣不缺。他花了好多天和對方交談，以自己的博學逐漸取得了對方的信任。后來他隱約發現對方對數學和天文學的發展史有所涉獵，如獲至寶，回家花一個通宵的時間在網絡上搜索相關資料。第二天他根本不談項目的事情，只跟對方大談特談哥白尼，布魯諾，伽利略這些人的生平，整整吹了一天。對方點頭如搗蒜泥，態度和熱情都來個一百八十度轉彎，隔天他就拿到了單子。這是個經典的戰例，誰能事先想到哥白尼會來幫助IT的人賺錢？這個PM靠的就是博學和由博學引申出的敏銳的感覺抓住了機會，讓客戶產生共鳴?？蛻舾杏X他層次也很高，而且和自己有共通之處，信任度大大增強，把項目交給他放心。如今這種例子在商務談判中已經屢見不鮮了。對PM來說，并不要求在各個方面都很精通，那是不可能的事情，只要PM對一些流行的話題和天文地理歷史各方面的知識有個大概的了解，在需要的時候能盡快的掌握，才有機會創造機遇和把握機遇。

3.強大的溝通能力

胸中有萬千墨水卻不知如何表達其實是比較少見的，但并非絕對沒有。每個人的人生軌跡都有所不同，思維受環境的影響也各有差異。包括象我們目前這個班級里的一些未來的MSE們，一定有比較內向或者不太愛表達自己觀點的人，這些人比較被動，往往很難承擔起談判的重任。從今天開始，這類人就必須重新學習如何說話，如何大聲的爭論。溝通，并不僅僅是大聲說話，而是在表達自己觀點的同時發現問題并綜合整理加以解決。除此之外，溝通的能力與社會經驗息息相關，與PM的見識聯系緊密。在日常生活中，PM就要多留心，多思考，當別人想到某個層次的時候要爭取比別人考慮的更深。當然，也有一些不夠踏實的朋友把溝通和吹牛當成了完全的一回事情，在和客戶交流的時候口若懸河的說一些不著邊際的話。這種人，碰到不懂，不太認真或者好奇心強的客戶是有一定市場的；而有水平，負責任的客戶往往會覺得這種人不可靠，一般不會把單子交給他。PM需要把握好這個度，吹是肯定要吹的，只是吹牛的時候一定要有基礎的去吹，對從來沒涉及過的領域或者根本不懂的東西輕易不要發表意見，挑選自己熟悉的方向合理的進行發揮，適當的留上一兩手，給對方高深莫測的感覺，效果最好。

4.優秀的售前團隊

這個團隊一般是由總經理發起并組建的，通常不指定PMP，對團隊的成員如SALES，PM，SA，ENGINEER們的團隊合作提出了比較高的要求。一般公司在接下一個單子進行到一定程度的時候，PM往往會尷尬的發現協議上銷售代表們對客戶的一些承諾是幾乎做不到或者根本做不到的事情。這種情況非常多，銷售的任務是拿下單子，我聽到的銷售們說的最多的就是“沒問題”或者“NO PROBLEM”，但是當我聽到客戶的要求和銷售的回答時我總是心驚肉跳，很不自然。銷售是非常辛苦的，為了建立客戶關系，尤其是空白的市場是很不容易的，往往為了一個單子會犧牲非常多。在這種情況下，和銷售進行協調自然而然的又落到了PM的頭上。在銷售和客戶做承諾之前，PM要主動的跟銷售交流，提供粗略的總體設計框架和技術難關以及能考慮出的工作量，而不是等出了問題再被動和銷售在老板面前互相推委責任。在組建團隊的時候，PM要根據團隊里每個人的素質和任務進行因人置宜的信息傳遞。優秀的售前團隊合作是接單的重要保障。

在商務談判的實際操作中，存在著各式各樣的問題，PM的職責和要求絕非以上幾點所能描述詳盡。根據環境，政策，人文，關系等各方面的不同情況，PM的不同成長經歷，每個PM最終都會建立自己對商務談判的看法和經驗。但是有一點可以肯定，這是PM成為PM的第一道關，也是最重要的一關。接不到單子，PM將失去存在的意義。與銷售有所不同，PM在該階段的任務除了接單，還要盡可能的搜集客戶關鍵人物的資料并與對方各個階層的負責人建立良好的客戶關系，以便在項目實施時充分調動資源。

二.啟動階段

1.項目的一些基本概念

項目三要素有多種版本，各不相同。實際操作中多分為范圍，成本與進度，其中最重要的莫過于范圍。我們把項目最終生成并提交給用戶的產品和文檔統稱為遞交件。談判的時候一定要確立遞交件的標準和要求，也就是范圍。盡管商戰的時候不可避免的客戶會不斷提高標準和要求，而承諾的款項卻不會有一分錢的增加。但是這個標準對每個公司來說都有一個底線，一旦超過了這個底線，那項目就肯定是虧的。除非是為了二期有利可圖或者是為了搞好關系，否則范圍超過底線的時候情愿不做，再厲害的PM在這種情況下也是無能為力。建立范圍需要的就是PM的多年的實戰經驗，在大大小小的項目中用血淚換來的一些體會。在這個時候，很能體現PM與技術人員的區別。成本就是客戶答應付的款項，與我們的投入成本并不是一回事情。進度就不用多描述了。

項目如何成功？也有一些關鍵的因素。個人的理解也不盡相同，通常包括以下幾個方面：界定工作目標及工作任務；老板或高層的支持；優秀的PM和開發團隊；充足的資源；良好的溝通；對客戶的積極反應以及適當的監控和反饋。這里要注意的就是資源和高層的支持。一個上規模的公司總是同時會有很多項目，可是再大規模的公司資源也不足以保證每個項目都能組建最合適的開發隊伍或擁有最好的環境。這時候各個團隊或者部門之間不可避免的會發生資源爭奪戰，摩擦再所難免。這時候對PM的作人再次提出挑戰。除了高層對PM項目的重視程度，如果PM

平時在公司與同事相處的好往往能使很多別人看起來很棘手的問題迎刃而解。相反，一個不會作人的PM由于人緣差，即使高層強壓別的部門或團隊配合，別人也會能拖就拖，延緩項目的進度和質量。有時候，這種內耗對項目和PM來說是毀滅性的。對客戶的積極反應也比較關鍵。一般來說PM已經被項目里大大小小的事情搞的筋疲力盡，要PM去主動要求客戶配合是很吃力的事情。然而，這個時候，越是困難，越是覺得累，越是要去主動?？蛻敉膊皇翘貏e的積極，主動與客戶聯系溝通和測試能及早發現問題。從風險控制的角度來說，問題發現的越早，風險越小，損失也就越小。積極的態度可以帶動客戶的積極性，在項目完工的時候，客戶對你的感激往往是難以用語言描述的，這對以后接單或者做二期三期會打下良好的基礎。因為在和別的新客戶談判的時候，新客戶自然會找你的老客戶了解情況，這時老客戶隨意的一句話頂的上你很費心的十句。

項目具有商業行為的幾個重要特征，有消費源，有參與者，有成功關鍵因素，有財務目標，有風險。

2.啟動階段的主要任務

根據PMI的解釋，接單之后項目自然轉入啟動階段。啟動階段PM的主要任務是率領總體架構設計師和系統分析員收集盡可能詳細的數據，確立盡可能詳細的需求，進一步確立詳細的項目范圍，預估資源，確立其他方案并獲得進入下一階段的批準。在這個階段，隨著需求分析的深入，PM也開始在公司內部進行人員挑選和資源爭奪，著手組建自己的項目團隊。項目即將進入計劃階段。

在收集完數據之后，PM要和客戶開始明確項目的大小，成本，規格，期限等重要特征并將其寫入合同文本，同時準備內部的包括預算，衡量標準等文檔，建立項目的評估標準。接下來就是需求分析。由于專業的原因，我們這里僅討論軟件工程項目的需求分析（以下簡稱需求分析）。

需求分析的主要參與人員有PM，總體架構設計師，系統分析員，熟悉業務流程的客戶。PM統領的團隊這時候還不是真正的開發團隊，我們叫做前期團隊。隨著需求分析的逐步深入，新的團隊成員不斷加入，啟動階段結束的時候正式的團隊將建立。對一個已經啟動的項目來說，需求分析直接決定了項目的成功與失敗。最初的需求體現在客戶的工作說明書或招標文件及附件上。這種需求一般比較含糊，無法體現客戶真正的需求。前期團隊要根據自己的經驗和客戶溝通并引導客戶進入正軌。有時候客戶會很不講道理或者思路僵化，就要求按照他的思維去定一些明顯錯誤的需求。這個時候團隊成員要耐心和客戶舉事實，談經驗，講道理，用圖形或模型等直觀的方式將需求描述出來，比如常見的數據流圖等。所以說，爭論再所難免，客戶有時候會吹胡子瞪眼睛拍桌子甚至會說“這個東西不要你們做了”之類的話。PM此時除了要親身參與需求分析綜合整理文檔之外，還要處理好團隊成員與客戶的關系，確保關系不會惡化到無法收拾的地步。只要PM盡力約束團隊中的成員，這個度還是很容易控制的。

對快速開發和疊代開發來說，需求和實現往往是同步進行，開發速度快是一大優勢。對有相同或類似模式的小項目來說采用快速開發或疊代開發是很合算的做法，時下流行的極限編程就是針對這方面建立的思維模式。然而，大中型項目中有太多不一樣的需求和模塊。如果不是因為項目有差異，那么市場上就只有產品而沒有項目了。所以，大中型項目的需求要認真仔細的去做。我們要討論一個問題，究竟應該在需求分析和總體設計上花費多少時間？我們熟悉的瀑布開發模式基本上分需求分析，總體設計，軟件開發，測試等幾個階段，然而究竟應該在前兩個階段上花多少時間卻沒有定論。實際項目操作的例子表明，分析設計的時間越長，需求設計做的越詳細，測試的時間就越短，返工率越低，風險也越小，成本越容易得到控制。而需求分析和總體設計沒有做好就急忙上馬進行開發的項目在項目初期進展順利的時候問題不大，到了項目后期和測試階段一些潛伏期比較長但是破壞作用比較大的問題就會凸顯出來，造成返工，延長測試時間。所以與其把問題堆積到緊張的項目后期，不如把時間多花點到需求分析和總體設計上。基礎夯實了，金字塔就容易造了。

在日本公司打工的程序員們可能都知道，小日本的軟件規范非常厲害，他們花在需求分析和總體設計上的時間通常在40%到50%左右，遠遠超過國內軟件項目的實施，效果也要強的多。他們總體設計的規范甚至詳盡到某個過程該如何判斷，確立什么樣的條件，換言之就是把什么時候該如何寫(if...else)語句都幫程序員定好了。在這樣的軟件規范下，程序員更象是裝配流水線上的工人，對一個模塊或技術熟悉到一定程序就變成了完全的重復性勞動。所以在日本和歐美經常會有程序員是低級工作一說，很多人不明就里，對國內程序員也照搬，對國內的程序員來說是很不公平的。在國內，只會照抄別人代碼，一點都不懂創新，凡事依靠別人，快下班就盯著表看的程序員是不少，這種人一般很難有什么前途。但是，優秀的不斷進取的程序員也很多。由于國內沒有象CMM這樣的軟件規范或者很少，所以這類優秀的程序員不少都是干著系統分析員甚至PM的活，拿著程序員的工資。這類程序員雖然在起步時會吃很多虧，而且是主動找虧吃，然而幾年之后與前一種程序員的社會地位會出現明顯的分化。當上進的程序員們作為PM進行商務談判的時候，前者還在各個公司里頻繁跳槽，跳來跳去都不滿意。有些扯開了，回到我們的話題。日本的軟件規范與CMM有驚人的相似，其中至少有35%以上都是幾乎一模一樣的。最近經濟不景氣，東京倒閉了160家軟件公司，這個數字是今年6月份的，還在不斷增加。這些公司紛紛搶灘上海，招收技術人員。如果去這樣的公司應聘就要考慮清楚了，進去可以學到他們的規范和質量控制，可是要想從程序員成為系統分析員或PM，比登天還難。往往一個程序員進去干了好幾年，對自己的那一塊熟的不得了，而對隔壁同事所做的東西一竅不通。

拒傳華為正在嘗試CMM4（華為印度研究所已經通過CMM4），對在華為工作的程序員們來說可謂福禍難料。當然，已經作到PM或QA或者熱愛CODING的朋友例外。

需求分析本身也存在著時間分配的問題。第一遍需求分析花的時間會最長，分析員們在客戶的各個部門之間幾乎把腿都跑斷，把口水說干，就是為了確立一個初期的需求模型。所有的文檔將會提交給PM進行復審并簽字，不合格的打回重做。反饋表隨之將提交給客戶，第二遍第三遍等等等等接踵而來，與客戶反復討論和磋商，反復提交文檔和表格，目的只有一個，明確需求。當PM最終合并了所有文檔并確立需求之后，最終生成的需求文檔將提交給客戶的各部門負責人簽字。這些文檔將作為合同的附件添加，以便在將來項目變更或者碰到重大問題時和客戶扯皮的重要依據。需要說明的是，客戶并非都是蠻不講理，但是說實話，頗有無奈，國內目前的項目大多數客戶為了不讓自己的錢白花，經常變著法子提需求。在啟動階段明確需求并簽字，無論最終情況如何，一份詳盡的書面文檔可以解決很多口頭承諾或概念模糊的文檔帶來的許多問題。

詳盡的需求分析有一個額外的好處就是對一些雙方都很陌生或者從來無人嘗試的領域將是一個決定是否進行項目的判斷標準。有時候，這種大項目在簽單時雙方都沒有絕對把握保證可以出成果，一旦在需求分析階段發現難以逾越的技術難關，就會放棄項目。典型的例子就是NMD洲際導彈防御系統。上世紀八十年代初美國搞星球大戰計劃，拖跨了蘇聯。大家對那段歷史有些含糊，很多人認為蘇聯人上了美國的當。其實并不完全如此，蘇聯人的情報機構無孔不入，并非那么容易上當受騙。實際上當時美國國防部已經開始著手NMD系統軟件的需求分析，前后耗資數億美圓，耗時兩年，僅僅是做需求分析，終于發現存在著在當時技術上無法達到的高度，隨后項目被放棄。

3.項目啟動

項目啟動要確定項目計劃，與客戶一起實施第一次項目審核，確認并對一些產品和服務向下包廠商下訂單。這個時候的PM會忽然發現有開不完的會，一天開三到四個會議是很正常的事情。這些會議有與客戶的會議，與下包廠商的，有團隊的，有公司高層的。團隊的會議主要是建立正式的團隊，提供團隊成員的角色和職責，提供績效管理方法，向成員提供項目范圍和目標。與客戶的一個主要會議將是項目啟動會議。在這個會議上PM會與客戶確立正式的交流渠道，項目綜合描述，讓項目參與人員相互了解，建立以PM為核心的管理制度。還有一些零零碎碎的東西甚至包括辦公場地的大小，電話多少部，所有人的聯系方式等等都要在會議上確立，并做會議記錄。這都是些非?，嵥榈氖虑?，聽起來婆婆***，卻是非常必要，缺一不可。大概就是所謂三軍未動，糧草先行吧。

這時候，作為公司高層，應該向全公司發表申明，正式給PM發布項目經理任命書和項目授權書。這個動作雖然在別人看來有些形式主義，但是對提高PM本人的士氣和責任感是有很大助力的。

三.計劃階段

1.定義結構分工結構圖（WBS）

啟動階段結束后，項目進入計劃階段，也就正式進入實施。這里概念可能有些不太對頭，其實是翻譯的緣故，反正大家明白意思就行，不用拘泥于字面。WBS是一組要提交的項目元素，用來組織定義項目的總體范圍，具體包括從工作內容，資源，成本角度考慮項目范圍；建立一套系統所需要的分層工作結構；把項目分解成易于管理的幾個細目，這概念有些模糊，其實跟資源管理器里分目錄是一回事情。可以說，WBS是計劃階段的核心。WBS會詳細的分到遞交件，包括給自己人用的項目使用的過程文件，給客戶用的模塊和說明文檔，完成每個細目的標準以及如何把這些細目的責任分配到具體的個人。WBS有縮進式和樹狀式，我這里也沒辦法畫圖，大家參考一些項目管理的書籍，里面有詳細介紹。我整個文章只挑我覺得需要注意的地方，如非必要，對技術細節或者工具使用不做詳細介紹。WBS的細目并不需要分解到同一水平，最下面的細目叫做工作包，分包的依據是個人的責任和可信度，也就是說到每個人頭上的任務是否能落實，是否有把握完成；還有就是準備對項目進行控制的程度，程度越深，WBS樹也就越深。由于WBS是實用性的東西，根據個人理解也不一樣，所以一個項目可能會有幾個正確的WBS，看PM的需要和最適合當前團隊狀態的進行選擇。

WBS的定義還是很麻煩的。PM要召開團隊進行討論，向成員提供與項目相關的所有詳細資料，并把WBS樹分解到二層三層。然后要花上一段時間讓成員進行頭腦風暴式（BRAINING STORM）思考，制訂工作產出和相應人員的職責，記錄每一個工作包的完成標準。在頭腦風暴式思考時，會有很激烈的爭論，PM要協調關系，調節氣氛，從自己能考慮到的各個角度旁推側敲，提示成員的思維角度和方向并加以總結。盡管很麻煩，制訂WBS仍然是非常值得的。如同需求分析一樣，WBS準備的越充分，編碼的進度越快。

2.風險管理

既然是商業行為，那么項目的風險必然存在，相信閱讀這個帖子的朋友不少人都經歷過或大或小的風險。有些風險很容易解決，有些風險則大大損害利益。不論什么樣的風險，能避免盡量避免，所以有必要對風險進行管理。由于風險的不可預知性，風險管理難度很大，概念也很難講清楚，只能從一些可行的角度去分析，進行管理。

首先要識別風險。這是個難度很高的活。PM要先召開風險識別會議，這個會議面向公司，高層，跨部門的有經驗的人都將參加。然后審核由項目小組生成的風險清單并與重要成員進行風險溝通，檢查一些重要的風險源如WBS，40 成本（時間）預估，人員計劃，采購管理等等。最后就要用到PM本身在以前類似項目中得到的經驗教訓。

識別之后要進行分析。我們可以進行粗略的量化分析（精確分析是不可能的事情）。有經驗的人可以一起參加討論，把提交出來的風險進行分類。首先按發生的可能性分，一般分成高，中，低三個級別，雖然很勉強，但是好歹也有個量化了；然后按耗去的成本分，也是高，中，低三級。我們可以把這兩種類別的三個級別進行組合，碰到可能性也高，成本也高的風險就定位為不能接受。碰到這種風險只好讓客戶修改需求或者增加風險預留成本，否則一旦虧起來不是虧一點點，有可能賠的很厲害。高和中，中和中的搭配都是屬于高風險，中和低，低和低搭配屬于低，高和低搭配屬于中。

針對出現的可能性，需要采取一些手段降低風險。到目前為止也沒有一個定論說有絕對好的方式，只能盡其所能的避免。有幾種方法可以考慮，第一種是將風險納入項目管理計劃并指定負責人，由外部人員定期檢查項目風險，一旦風險發生，執行風險管理計劃；第二種是保險，這種屬于風險轉嫁；第三種方式有點奸，不過最保險，就是把客戶拖下水，讓他們一起參與風險管理，呵呵，到時候就好說話了：）

風險管理作為項目計劃之后，PM需要更新WBS，修改日程計劃和更新風險管理計劃。

風險預留通常是成本的8%。

3.預估

預估是從量化的角度對項目進行評估，主要包括工作量，任務期限，人力，設備，材料，成本等，要注意預估不是財務策略或報價。

預估其實并不是一次性工作，在整個項目過程中，預估始終需要。預估似乎沒什么特別需要提的地方，每個PM接到項目的時候自然會有預估，在項目發生變更或進入下一階段時也會預估。預估的作用主要還是讓PM作到心中有個底，安排計劃時不至于毫無頭緒。

4.進度計劃

進度計劃就是一個模塊或功能要寫多長時間，PM安排個日期，設立里程碑，叫程序員們不能偷懶。進度計劃是從WBS提取過來的。對PM來說，合理的安排進度計劃對項目控制和激勵團隊士氣有著很大的作用。對程序員來說，進度計劃毫無疑問是噩夢。

顯示進度計劃一般有先后順序圖，甘特圖和里程碑圖表。上回邵衛老師講課，推薦的工具是m$的PROJECT，這個工具我還不會用，因為沒時間去摸索。我的頭倒是用的很溜了，近一個月來他就用這個PROJECT畫了一個又一個的里程碑圖，不停的折磨我和同事的神經。我們一般都是一邊開發一邊做UNIT TEST，效果上來看，因為有強大的時間壓力，效率上比之前確實要提高不少，可是我們也只能結結巴巴的趕完進度。由于TEAM里人少，我們都是一個人做幾個人的活。我每天早晨六點多出門，經過將近兩小時顛簸，八點多點已經坐在位子上，中午吃15分鐘的飯，干到晚上八點下班，到家吃完飯往往已經11點了。一個多月我從來沒吃過早飯，沒有睡過六個小時以上的懶覺。雖然強大的壓力使我們能在短時間內掌握盡可能多的技能，開發更多的模塊，但是對我們的情緒也是有很大的影響。所以說，項目里程碑是一把雙刃劍，合理安排才能既促進效率也不至于打擊士氣。團隊成員士氣的逐級衰落會給項目后期的開發帶來難以估計的影響，進度將會大大延緩。關于PM和團隊的問題我們后面會講到，這里我先祥林嫂一把，然后跳過。

里程碑圖表的特征是任務，成員和時間，任務和成員用文字標志，時間用數字描述并輔助以圖線跨度，象階梯一樣非常形象，一目了然。管理起來非常方便，完了的打個鉤就可以了。

網絡邏輯圖是表示任務和邏輯關系的示意圖，可以用先后次序表示，也可以用關鍵路徑表示。其實把各個活動劃分為1，2，3，4等階段，每個階段包括小活動1.1，1.2，2.1，2.2，2.3，2.4，3.1，3.2，3.3，4.1，4.2等，日程計劃也分四種，一般只提到從前向后和從后向前兩種。從前向后的概念就是某項活動必須相同或晚于直接指向這項活動的的所有活動的最早結束時間的最晚時間。有些繞口，我們打個比方：2階段指向3階段，那么2階段里的4個子階段也都指向3。假設2.1結束時間為1月12日，2.2結束時間為1月22日，2.3結束時間為1月15日，2.4結束時間為1月20日，那么，2階段中最晚的結束時間是2.2的1月22日，所以在3階段中的3個子階段3.1，3.2，3.3的最早開始時間都不能早于1月22日。至于從后向前的例子大家自己去推吧，我就不舉了，剛才幾個123打的我累死了：）

項目經常需要調整進度。在不改變項目范圍的情況下，調整進度有幾種方法：利用快速跟蹤手段來改變任務間的關系；將串行的任務改成并行；改變工作方法（可能改變WBS）；改變日期限制，使關鍵路徑上的任務開始或結束的更早。雖然方法多樣化，在我看來只有一條，就是拼命的壓榨程序員的勞動力。如何壓榨，還是個技巧。如前面所分析的，需求分析恨不得多分點時間給它，壓需求是不太可能；測試階段后期接近完工，羅里巴唆的事情一大堆，忙都忙不完，那時候PM一門心思提前/按時完工，好收錢，壓那段時間似乎也不太可能。說來殘酷，最能壓的還是CODING，編碼階段往往是壓縮重點，總之大家埋頭苦干就是了，大項目壓縮的時候程序員吃喝拉撒都在公司是很正常的事情，相信不少人都有很深的體會，這里傷心事情也就不提了。只是我總結一下，讓未來的PM們有壓

榨后來人的依據，呵呵。測試前期也可以適當的壓一壓，那時候人剛完工，都比較懶散。國內一般企業規模都不大，沒有專門的質量控制部門，所以質量保證和測試往往就是程序員或PM本身。其實質量保證和測試人員的人數和素質都應該要高于程序員。在日本和CMM實施的公司里，編碼壓縮是很容易實現的事情，因為那些程序員真的是技能熟練的裝配工人，壓起來方便的很。他們這樣培養人的目的或許就是為了壓縮吧？！

四.控制和執行階段

1.軟件開發

實在沒什么好說的，也是大家最不愿意談的，平時在公司里談的已經夠多的了，還要在這里受我嘮叨。需要提醒的依然是團隊合作精神和完善的文檔管理制度。SOURCESAFE這些工具有時候還是有必要使用的。經常看到有人說天才程序員不寫注釋什么的。我相信有這種天才程序員，因為我碰到過幾個。我愛人公司里也有一個，他們的一套產品核心代碼就是這個人寫的，4年過去了，周邊代碼換了好幾茬，核心算法始終沒換過，可惜這小子跟了李洪痔，如今已經不知所蹤了。但是他的代碼似乎也要有點注釋的，沒有注釋過段時間再天才的程序員也不能保證他是最有記憶力的。而且，對一個項目的編碼來說，靠一兩個人打天下如今是不可能了。別人的公司都是團隊，兩人智慧勝一人，這頭還在靠一個天才支撐門面，實際上市場可就別人搶了去，那時候再天才也沒用了。編碼的時候講究技術公開，程序員不要藏著掖著，對大家沒好處，PM要想辦法調動大家創新思維的積極性，營造良好的技術討論氛圍，碰到技術難關的時候就容易攻破了。

有個問題需要單獨對還沒有PM覺悟的程序員說，其實是在調研的時候就定了的，就是使用什么樣的開發工具。沒有經驗的程序員往往會拿著C++或者JAVA的資格證書或者擁有一兩個開發工具的一些經驗而得意洋洋。其實老板和PM根本不看重這個，他們關心的是使用什么樣的工具能盡快的達到目的。管你什么C++，DELPHI，PB還是JAVA，只要能做的出來，VFP都可以用。我舉這個例子并非說不看中工具，而是提醒想轉型為PM的程序員，第一要把工具當作工具，而不要被工具套進去，鉆研一些一輩子都用不上的技術；第二要掌握的并非是單獨的一個工具，而是流行的程序設計的思想，以及在最短時間內掌握一門陌生工具的能力。只有建立了這樣的思維，才有可能轉為PM，否則一輩子都是技術工人，最多就是個技術總監。

2.變更

對任何項目，變更無可避免，無從逃避，只能去積極應對，這個應對應該是從需求分析就開始了。對一個需求分析做的很好的項目來說，基準文件定義的范圍越詳細清晰，用戶跟PM扯皮的幌子就越少。而需求沒做好，基準文件里的范圍含糊不清，被客戶抓住空子搞你一下是非常頭疼的事情，往往要付出無謂的犧牲，有時候甚至非?；鸫?。

需求做的好，文檔清晰又有客戶簽字，那么后期客戶提出的變更就超出了合同的范圍，需要另外收費。這個時候千萬不能手軟，并非要刻意賺取客戶的錢財，而是不能養成客戶經常變更的習慣，否則后患無窮，維護的成本會讓PM吃不消。在客戶提出變更請求時，要建立變更申請登記表和變更申請表，并讓客戶簽字。當然，有時候一些不是非常關鍵的模塊PM也不至于一點不講情面，該賣面子的時候還是要賣，尤其是當著對方領導的面，千萬要賣面子，但是也別賣的太干脆，不要讓他們得到的太容易。

需求做的不好，客戶抓住漏洞或者非常不講道理，麻煩就大了。有時候爭論會很厲害，到非常白熱化的地步，PM與客戶代表幾乎溝通不了。PM在客戶關系和短期利益兩方面難以取舍，一般都是向客戶妥協，最終形成惡性循環。這種情況非常難辦。一般這種情況都是到了項目后期，做重大的更改幾乎是不可能的事情，如果白做就要虧錢。而這個時候如果PM跟對方高層的人關系搞的定，可以透過對方高層把事情壓住。然而由于已經到后期，客戶代表不會輕易更換，對方這次沒有改成，必然心懷不滿，下回在別的模塊依然會找麻煩或者在談二期的時候動動手腳，都是很讓PM傷腦筋的事情，這方面目前還沒有什么好的解決方法，所以盡可能的做好需求比什么都重要。相對需求來說，什么WBS，風險管理，計劃進度都是扯淡，需求做好了，一帆風順。還有一種辦法就是裝可憐，要裝的非常的象，在對方的領導面前裝，而且不能讓人看出是裝的樣子，要讓你自己都覺得你自己是真的可憐，那么就算這次客戶硬是要求改了，下回他也必然不好意思再叫你改。其實人心都是肉長的，如果可能的話，我還是不贊同使用一些手段的，但是有時候客戶非常難以在短時間打動而工期又將接近，這種情況下就要靠PM耍一些手段了。各人有各人的方式，八仙過海，各顯神通吧。

PM在變更管理中需要做的是分析變更請求，評估變更可能帶來的風險和修改基準文件。

3.質量控制

大公司有質量管理部門（QA），QA的成員基本上都是由非常有經驗的PM轉型過來的老狐貍，是老總接班人的有力爭奪者。一個QA會管理多個項目，有時候甚至會親身參與。PM和QA有些象貓和老鼠，不停的通過報表傳遞一些心照不宣的假數字。QA對PM的工作最終是有評定的：A級表示總體在控制下；B級表示當前在控制下；C級表示有顯著問題；D級表示有重大問題。如果PM得了個D，那可不太妙，不但世界級的QA會每個月要收報告，地區QA會一個星期找來面談一次，訓一頓。得到A的PM是很逍遙的，基本上不會有人來過問。在沒有QA的公

司，質量控制只能由經過授權的團隊成員進行，效果就要差的多了。

質量管理貫穿整個項目周期，詳細的可以參見CMM。

4.成本管理

PM經常通過控制進度和預估來控制成本。PM必須經常問自己，項目已經到了什么階段？完成了多少？花費了多少？完成時成本是多少？掙值法的術語不少，象BCWS，BCWP，ACWP，但是關系比較簡單，大家參閱一下相關資料，這里不再羸述?？傊?，PM要管理好成本，注意節約，但并非是拼命剝削程序員，該花的還是要花。

五.結束階段

1.項目結束

項目結束時，PM要將最終系統方案提交給用戶，完成項目所有的提交件，收集項目全部信息并結束項目，完成或終止合約，簽署項目結束的相關文件。

項目結束意味著可以收錢了。PM辛苦了那么多，終于可以高興一下了，收到最后一筆款項，意味著遞交件的移交和團隊的解散，項目也轉入維護階段。不過收錢未必代表著賺錢，要看項目是否按時完工。一般來說，提前完工的項目很少，但是能賺大錢；按時完工的賺小錢；延期的要賠錢。一個人首次承擔PM，如果沒有人帶，多半會失敗。失敗沒什么，所有的PM（注意是所有，不是幾乎所有）都失敗過，然而失敗會成為教訓和經驗，推動你繼續前行。在美國，每年至少有40%的項目無法實施被擱淺。只有在項目中和生活中不斷磨練，培養自身素質和作人的基本準則，才能成為賺大錢的PM。

2.項目完工會議

項目結束時，依然要開會，不過少多了。一般跟客戶要開一個，主要是確定所有的提交件都已經被接收，對突出的個體進行表揚，對外宣傳成功案例，標志并記錄項目的正式結束。這時候開會很輕松，目的也很明確，做完了大家好聚好散，或者以后有機會再合作。

團隊要解散，內部會議肯定是要開的。也沒什么好廢話的，該表揚就表揚，該發多少獎金就發多少獎金，畢竟大家都累死累活的干了那么長時間。項目結束請客戶出去泡溫泉時PM們千萬別忘記了辛苦為你工作的

程序員和工程師們，當然，如果他們不愿意看到你的臉那么你就折現發到他們的存折上去，正好讓他們回家好好休息休息。這樣下一個項目需要他們的時候他們才會為你賣命。說出來獎金發出去似乎你損失了，其實你賺大了。

3.客戶滿意度

形勢也好，歷史記錄也好，盡管項目結束的時候客戶滿意度PM心中已經有底了，但是還是有必要向客戶各個層次的項目代表發一張信息反饋表，收回的信息將反應客戶的滿意度。其實真正體現客戶滿意度的地方有很多。第一就是付錢付的快，如果客戶不滿意，一分錢藏在他牙縫里你也很難摳出來；第二就是二期，二期非常非常重要，因為這里已經是屬于一種無銷售成本的項目，又有一期的經驗，可以說二期的錢是最好賺的。這中間的感覺，只有經歷過的人才明白。

六.團隊管理

1.建立團隊

挑選人材依然是PM頭疼的一個大問題，有時候一個在別的項目里很優秀的人材，挖過來未必能適應。所以，PM還是要拓展知識面，培養自己的敏銳度，因人置宜，才能挑選對自己項目有幫助的人材，才能真正對項目起作用。

2.核心程序員

任何項目都有核心程序員。核心程序員背負著很重的責任，平時要和普通程序員一樣沒日沒夜的加班，碰到重大的技術難關更是整個人撲在電腦上，熬上幾個通宵是家常便飯。常有人抱怨程序員工資高，真想請這些人來嘗試一下程序員的工作，看看他們付出的精力是否配那份工資。前面說過的，中國的程序員不同于日本和歐美，他們很多人參與了系統分析和建模，對腳踏實地工作的程序員來說，這份工資實在是委屈了。看看行業里努力工作的程序員們，有幾個不是頭發花白，高度近視，未老先衰的？上星期五晚上我加班到10點，隔壁公司的一個技術總監特意留下來跟我說：“我們這種人，前半生拿命去換錢，后半生拿錢來買命！所以，工作的時候一定要注意勞逸結合！”道理我并非不懂，我也不想透支自己的身體，但是我有選擇么？

PM要特別注意愛護核心程序員，尤其是他們的生活困難和精神狀況，有時候，他們耍性子或者不合作PM要妥協，要從自己身上找原因。其實在國內，我還沒碰到過敢這么做的程序員。相對PM來說，程序員是絕對的弱勢群體，沒有任何發言權，幾乎可以說PM想怎么做，想怎么改，程序員就要付出一切代價去達到目標。

3.獎勵與懲罰

獎勵是不用說的了，相信所有閱讀我這篇文章的PM，未來的PM，程序員和未來的程序員們都知道如何去做，這里只說懲罰。懲罰似乎很不好辦，其實對PM來說再簡單不過。一個程序員把模塊做砸了，罵，扣工資，開除都不頂用，在項目沒完成之前不是追究責任的時候。一個優秀的PM應該給他一個機會，當作沒事一樣讓他去做別的

事情，把他做砸的事情交給別人去做，就是對他最大的懲罰。這樣既能激勵他上進又不會讓他尷尬，他會感激你一輩子，因為你給了他一次機會。而PM挑選這個人進團隊并給予他責任，他沒有完成，PM本身就有責任，應該自我檢討。

4.管理沖突

無論團隊里的成員相互之間很熟悉還是不熟悉，沖突再所難免。在發生沖突的時候PM要牢記以公開，公正的方式處理沖突，不能因為其中之一是自己的小姨子就干掉另一方；處理事情的時候必須對事不對人。有時候，成員與PM之間也會有沖突，一般情況下都可以幾乎肯定是PM的責任，因為很少有成員敢吃豹子膽來反抗自己的頂頭上司。這時候PM除了要及時的做自我檢討之外，要有寬廣的心胸。絕對不可以利用職權打擊與自己有矛盾的成員，否則團隊里所有成員都會心寒，項目的質量將會大打折扣。如果他確實不對，也要忍住，等項目完了慢慢收拾他不遲。PM的心胸還表現在不能嫉賢妒能上。當公司高層越級表揚團隊某成員時，你應該高興和光榮，而不是陰險的想著下次如何把這份光環戴到自己的頭上。實際上在國內的很多PM都是這么做的，邀功的時候全是他的，有了責任都在下面。這種PM永遠做不大，遲早會被淘汰。

5.承擔責任

項目是有風險的，肯定會有失敗的部分甚至整個項目失敗。雖然說每個人都在WBS里定下了責任，在項目里程碑里都有任務。但是當整個項目危機來臨的時候，PM要勇于站出來，承擔起全部的責任。這是做人的方式，也能讓你贏得團隊所有成員的尊敬和愛戴。往往在這個時候我們才能體會到什么叫團隊合作精神，就是大家齊心合力，共渡難關。

6.資源爭奪

前面提到過，資源有限，如何爭奪而不傷和氣是對PM的另一個挑戰。因為整個公司是一個大團隊，內耗的厲害對PM沒有好處。當然，擺平各路神仙是不可能的。但是一個健康的公司必然有健康的管理制度和優秀的成員。物以類聚，人以群分，PM應該在公司里主動結交志氣相投的朋友，在拿到項目時這些朋友會給你很大的幫助，當然，在這些朋友需要你幫助的時候你也應該懂得怎么做。如果你性子很怪，很難找到脾氣相近的朋友，沒關系，交幾個酒肉朋友也不錯。我們公司數據統計，一個人在公司的人緣和他在公司請客吃飯的次數成正比。PM一定要盡心盡力的為公司打算，這樣在需要高層支持的時候才會獲得鼎立相助，而總是為自己打小算盤的PM是不長久的，總會被別人看穿的。

后記：寫到這里實在寫不動了，控制階段的合約管理和項目跟蹤沒有寫進去，一方面我不熟悉，另一方面讓大家自己去做一些思索。其實前天我就在構思這篇文章了，本來還想把CMM也寫一篇的，如今看來太高估自己的能力了，時間實在是不允許。抬頭一看，東方已露魚肚白，外面隱約傳來麻雀的嬉叫聲。今天我還要去跟人談祖房子的事情，明天還要上課，星期一開始又要沒日沒夜的加班，多想睡個懶覺呀！

上回鄧老師的課，我再次跟大家說聲對不起，我的發言打擾了大家。作為非MSE成員，我的舉動實在是有些過火。但是有一點我還是要申明，我不是為了我自己，我也想為大家好。

我看到了在課程討論版面里關于我們課程太少，不如其他院校和課程安排不透明的討論。因為上次的教訓，我一直沒有表態，擔心會再惹麻煩。今天帖子寫完，實在是忍不住想說幾句了。我覺得課程安排不透明是復旦老師的責任。至于我們課程太少，不如其他院校的問題我覺得不是很有必要提。課程是死的，人是活的。再好的條件也有不成材的，再惡劣的條件也有脫穎而出的，更何況我們的條件并不比別人差很多。只要我們努力，我們不會輸給清華的人。我一直不覺得在光坐在課堂里聽課能學到什么真本事，MSE們如果不把學到的知識與自己的實際工作融合貫穿并領會其中的思想，那這個文憑拿到手也沒用?？幢究平逃椭懒耍蠹叶际沁^來人，如今也在工作，你們感覺當初在學校里學的知識在真正上了工作崗位之后有多少能派上用場？好象很多東西都要重新來過。這就是MSE相對普通研究生的優勢所在，因為你們一邊工作一邊學習，理論與實踐相結合，對知識的掌握會很快，而不是變成考試和拿文憑的工具。我今天看到亞聯招聘的信息，上面根本不提高學歷，而是換成了有本事。什么叫有本事我無法定義，但絕對不是一紙文憑能代替的了的。文憑只是個輔助和敲門磚，可以保證你進一個好公司三個月，三個月后你的命運如何還是取決于你能做多少事情。我就是高中畢業，大學退學了兩次，無論計算機還是英語連個象樣的證書都沒有。但是無論你是清華，北大，復旦還是交大的MSE，兩年后你畢業的時候你有把握在崗位競爭或商務談判中擊敗我嗎？

我們需要的是自覺，踏實，進取和拼搏。只有擁有不斷努力的恒心，我們才能最終提高自己的社會地位和人生價值，說的難聽點最起碼不要讓自己被淘汰。網絡上所有的資料都公開，都有的當，我們的老師又很有能力。其實根本用不著攀比老師的能力，學歷和目前的社會地位，只要他有可以傳授給我讓我學習的經驗，我管他是博士還是文盲，管他是IT總裁還是掃大街的！呵呵，這話說出來又要得罪人了！唉，話多就話多吧，總要有人說的！

這篇文章有我一個晚上的心血，也讓我復習了一下PM的知識。我把他獻給復旦02年所有的MSE們，也獻給我愛人。這些年風風雨雨，她跟著我，吃了很多苦，但是她從來不說什么。我要謝謝她！

希望能和大家共同度過愉快的兩年！

淺談項目管理機制

一.項目及項目管理 1.什么是項目

要討論項目管理，就必須首先理解項目這個概念。項目是為完成某一獨特的產品或服務所做的一次性努力。項目一般要涉及一些人員，由這些人員完成一些相互關聯的活動，項目發起人通常希望能夠在最有效地利用資源的基礎上，及時、高效地完成項目任務。

2.什么是項目管理

項目管理是指“在項目活動中運用專門的知識、技能、工具和方法，使項目能夠實現或超過項目干系人的需要和期望?！边@一定義不僅僅是強調使用專門的知識和技能，還強調項目管理中各參與人的重要性。項目經理不僅僅要努力實現項目的范圍、時間、成功和質量等目標，還必須協調整個項目過程，滿足項目參與者及其他利益相關者的需要和期望。

二.項目管理的歷史及發展 1.歷史事件

現代項目管理通常被認為開始于20世紀40年代，比較典型的案例是美國軍方研制原子彈的曼哈頓計劃。但直到80年代，項目管理主要還限于建筑、國防、航天等少數行業。我國和世界其他各國歷史上都有許多成功的項目管理范例。項目管理的實踐可以追溯到古代的一些主要基礎設施如埃及金字塔、運河、大橋、歐洲的古教堂、道路、城堡等的建設之中。對于項目管理的出現，有說服力的其他一些特別事件有：

■ 1917年，亨利甘特發明了著名的甘特圖，使項目經理按日歷制作任務圖表，用于日常工作安排.■ 1957年，杜邦公司將關鍵路徑法（CPM）應用與設備維修，使維修停工時間由125小時銳減為7小時。■ 1958年，在北極星導彈設計中，應用計劃評審技術（PERT），將項目任務之間的關系模型化，將設計完成時間縮短了2年。

60年代著名的阿波羅登月計劃，采用了網絡計劃技術使此耗資300億美圓、2萬家企業參加、40萬人參與、700萬個零部件的項目順利完成。

2.職業發展

進入20世紀70年代，各類項目日益復雜、建設規模日趨龐大，項目外部環境變化頻繁，項目管理的應用也從傳統的軍事、航天逐漸拓廣到建筑、石化、電力、水利等各個行業，項目管理成為政府和大企業日常管理的重要工具。同時，隨著信息技術的飛速發展，現代項目管理的知識體系和職業逐漸成型。

■ 項目管理是二次大戰以后發展起來的綜合性管理科學分支，■ 1965年第一個專業性國際項目管理組織IPMA（International Project Management Association）在瑞士洛桑成立。

■ 1969年，美國成立項目管理學會PMI（Project Management Institute）。

■ 1976年，PMI在蒙特利爾會議開始制定項目管理的標準，形成項目管理職業雛形。■ 1984年美國項目管理協會推出項目管理知識體系PMBOK（Project Management Body of Knowledge）和基于PMBOK的項目管理專業證書PMP（project management professional certification）兩項創新。

項目管理因此作為一門學科和專業化管理職業在全球得到迅速的推廣和普及。3.項目管理的應用

實際上任何創新和改革都是項目活動。由于這些任務具有一次性和獨特性的共同特征，人們日益認識到采用常規的管理是難以應付的，必須組成專門的項目班子，采用項目管理方法。因此，在企事業單位和政府管理機構中也同樣出現了對項目管理的強烈要求。

1）國外市場

世界銀行把每一筆貸款作為一個項目來管理；在美國，DEO（能源部）、DOT（交通部）等政府部門，在項目建設時不但自己使用項目管理軟件，并規定參與方也得用項目管理軟件對項目進行管理；摩托羅拉是世界著名的通信設備和服務供應商，在20世紀90年代就啟動了一個旨在改善其項目管理能力的計劃；總部設在瑞士的國際ABB工程公司，在90多個國家運營，要求公司的大部分工作實行良好的項目管理；英國、德國、加拿大、法國等國家的政府機構，其投資的項目都要求使用項目管理軟件進行管理。

■ 自1983年以來，美國政府投資的所有項目，不論軍用還是民用，都要求用項目管理軟件進行管理。其效果十分明顯，為國家節省了大量的財富及資源。在國外，項目管理軟件已擁有一個非常成熟的市場。

■ 業界排名第一的primavera公司業績： ■ 所應用管理的項目總值超過4萬億美元

■ 第25位PC軟件公司(2001軟件排行榜前100位)■ 全球85個國家均有授權經銷商 ■ 超過35萬用戶 ■ 典型用戶：

Boeing，Chevron，Exxon Mobil, Federal Express，Ford-Jaguar，General Motors，Honeywell IAC，Intel，Lucent Technologies，Motorola，Ontario Hydro，Raytheon，Glaxo SmithKline，Westin Hotels & Resorts。

■ 大客戶：香港機場，倫敦地鐵，舊金山機場，國內三峽工程。2）國內市場

隨著我國經濟日益融入全球經濟體系，國際競爭日趨激烈。我國涉外項目的比例也將越來越高，國內外形勢的發展要求項目管理采用國際通用方式，這就使得我們對項目管理的需求更為迫切。

我國在第一個五年計劃時期，就投資建設了156個重點建設項目，到2002年預計在各種項目上的投資將以萬億計，其中大型項目投資將達到2000個，幾乎涵蓋了經濟、文化、科教、國防等所有重要領域，諸如銀行貸款項目，能源、交通、水利等基礎設施項目，房地產項目，農業發展項目、工業企業技改項目、環保項目、扶貧項目、科研、教育項目、體制改革項目，以及體育、文化活動項目等。

■ 2002年政府撥3000億元?？钣糜诟黝愓咝皂椖?■ 省、市地方政府捐助至少1000億元的專款 ■ 每年都有2000個新的1億元以上的大項目 ■ 我國每年從世界銀行獲得約30億美元的貸款

■ 亞洲銀行貸款、國際經濟援助、出口信貸等，利用外資數額每年都在幾百億美元 ■ 此外還有許多項目要通過國際招標、采購、咨詢等方式來運作 伴隨著改革開放、申請并最終加入WTO，中國經濟在高速增長中日益深刻地融入全球市場，在國際化大背景下，國內大中型項目的數量、投資額度、資金來源和幣種的多元化以及管理上的復雜性都大大超過以往。

現代化、國際化的項目建設必須用科學的方法進行管理，現在我國已經開始實行政府采購制度、招投標制度、項目監理制度、政府審批制度等等都是國家加大監管力度、杜絕暗箱操作、確保項目建設質量的具體措施。現在，傳統大型企業（導入案例中的汽車制造企業）、高新技術企業（如IT企業）、政府機關、社會團體都開始把項目管理模式作為解決問題一個重要的工具和方法，項目管理的人才和應用熱潮已經撲面而至。

三.項目管理的知識領域

在PMBOK中，將項目管理劃分為9個知識領域，范圍管理、時間管理、成本管理、質量管理、人力資源管理、溝通管理、采購管理、風險管理和整體管理。其中范圍、時間、成本和質量是項目管理的四大核心領域。

四.項目管理的五大過程

1.啟動：批準一個項目或階段，并且有意向往下進行的過程。

2.計劃：制定并改進項目目標，從各種預備方案中選擇最好的方案，以實現所承擔項目的目標。3.執行：協調人員和其他資源并實施項目計劃。

4.控制：通過定期采集執行情況數據，確定實施情況與計劃的差異，便于隨時采取相應的糾正措施，保證項目目標的實現。

5.收尾：對項目的正式接收，達到項目有序的結束。五.項目管理的基本思想和技術 1.掙值法EVMS

掙值法實際上是一種分析目標實施與目標期望之間差異的方法，故又常被稱為偏差分析法。掙值法通過測量和已完成的工作的預算費用與已完成工作的實際費用和計劃工作的預算費用得到有關計劃實施的進度和費用偏差，而達到判斷項目預算和進度計劃執行情況的目的。其獨特之處在于以預算和費用來衡量工程的進度。

簡而言之，EVMS的思想可以概括為以下幾個方面：

■ 所有工作開始之前的預先計劃 ■ 基于技術目標上的性能衡量 ■ 時間表狀況分析

■ 按照完成的工作對資金支出的分析(非預定的工作)■ 隔離問題：

■在費用時間表參數內的技術質量問題 ■不打算替換或更換技術問題過程中的探測 ■ 預測完成日期和最終費用

■ 糾正行為

■ 維持性能測定基線的正常控制 2.蒙托卡羅模擬技術

蒙托卡羅模擬技術是項目風險管理——不確定性分析技術。由于項目中許多因素是變化的，不能用一個固定的值來描述，例如，在軟件開發項目中，開發某個子程序到底需要多長時間，一般來說，不能用一個定值（例如20天）描述，但是根據經驗，往往可以給出一個范圍，例如18-23天。問題是，如果在一個項目中有多個因素都是具有不確定性，如何計算結果呢。這就是蒙托卡羅模擬技術所要做的。本技術中的主要內容包括：

■ 描述不確定性風險因素的方法

■ 如何建立項目模型

■ 抽樣技術

■ 數據分析技術

■ 敏感性分析等

3.項目進展評價技術

由于項目中有許多任務組成，在項目進行到一定階段后就會發現，有些任務工期縮短了，有些加長了；有些任務超出了預算，有些低于預算。如何從整體上評價進展呢？這就是本技術中要討論的問題。本技術中的主要內容包括：

■ 流逝時間評價法

■ 工期評價法

■ 工時評價法

4.網絡計劃技術（PERT、CPM）

網絡計劃是以網絡圖為基礎的計劃模型，其最基本的優點就是能直觀地反映工作項目之間的相互關系，使一項計劃構成一個系統的整體，為實現計劃的定量分析奠定了基礎。同時，從數學的高度運用最優化原理，去揭示整個計劃的關鍵工作以及巧妙地安排計劃中的各項工作，從而可使計劃管理人員依照執行的情況信息，有科學根據地對未來做出預測，使得計劃自始自終在人們的監督和控制之中，達到以最短的工期、最少的資源、最好的流程、最低的成本來完成所控制的項目。

網絡計劃的基本形式是CPM（關鍵線路法）與PERT（概率網絡評審技術）。前者是美國杜邦公司和蘭德公司于1957年聯合研究提出，后者則是在1958年由美國海軍特種計劃局和洛克希德航空公司在規劃和研究在核潛艇上發射“北極星”導彈的計劃中首先提出的。兩者在初級發展階段的主要區別是：

■ CPM假設每項活動的作業時間是確定值，而PERT中作業時間是不確定的，是用概率方法進行估計的估算值。

■ CPM不僅考慮時間，還考慮費用，重點在于費用和成本的控制，而PERT用于含有大量不確定因素的大規模開發研究項目，重點在于時間控制。

■ 到后來兩者有發展一致的趨勢，常常被結合使用，以求得時間和費用的最佳控制。

關鍵路徑法是項目時間管理中的技術，簡稱CPM。它是把完成任務需要進行的工作進行分解，估計每個任務的工期，然后在任務間建立相關性，形成一個“網絡”，通過網絡計算，找到最長的路徑（主要矛盾），再進行優化。本技術的主要內容有：

■ 項目目標確定與時間、成本、資源的綜合權衡

■ 工作分解結構建立

■ 工期估算影響因素

■ 正向計算

■ 反向計算

■ 時差計算等

5.WBS，OBS，CBS，PBS分解技術

WBS是項目范圍管理中的技術，它是確定項目范圍的一種主要技術，也是進行成本、資源的估算的基礎。本技術的主要內容包括：

■ 分解原則

■ 工作分解結構

■ 組織分解結構

■ 成本分解結構

■ 產品分解結構

6.項目管理可視化技術

項目管理的不可見屬性，為項目團隊的溝通、控制帶來了很大的障礙。本技術將介紹，如何把項目的進度、成本、風險、質量可視化的方法。

淺析軟件項目管理中的10個誤區

隨著計算機硬件水平的不斷提高，計算機軟件的規模和復雜度也隨之增加。計算機軟件開發從“個人英雄”時代向團隊時代邁進，計算機軟件項目的管理也從“作坊式”管理向“軟件工廠式”管理邁進。這就要求軟件開發人員特別是軟件項目管理人員更深一步地理解和掌握現代軟件工程的理論方法，完成思想觀念上的轉變。筆者在此分析了10個在現代項目管理中思想觀念上容易陷入的誤區，希望能夠拋磚引玉，引發大家更多的思索和討論。

誤區1：在項目的需求分析階段，開發方與客戶方在各種的問題的基本輪廓上達成一致即可，具體細節可以在以后填充。因為無論開始時有多么細致，以后對需求的修改幾乎是必然的。分析：這是一種非常危險的思想。實際上許多軟件項目失敗的最主要的原因就是需求階段對問題的描述不夠細致，導致后來預算超出或者時間 進度達不到要求。正確的做法是：在項目需求分析階段，雙方必須全面地盡可能細致地討論項目的應用背景、功能要求、性能要求、操作界面 要求、與其他軟件的接口要求，以及對項目進行評估的各種評價標準。并且，在需求分析結束以后，雙方還要建立可以直接聯系的渠道，以盡 早地對需求變動問題進行溝通。

誤區2：軟件項目的需求可以持續不斷的改變，而且這些改變可很容易地被實現。分析：的確，在具體實際中由于種種原因客戶方很難在需求分析階段全面而準確地描述所有問題。隨著開發進度的推進，往往會有一些需求的 改變。而現代軟件工程理論也利用軟件的靈活性特點通過各種方式來適應這種情況。不過，這并不表明“軟件項目的需求可以持續不斷的改變，而且這些改變可很容易地被實現”。實踐表明：隨著開發進度的推進，實現軟件需求更改所需要的代價呈指數形式增長。假定在需求分析階 段實現需求更改需要花費1倍的代價；那么，在系統設計和編碼階段，需要花費1.5-6倍的代價；在系統測試階段需要花費10-20倍的代價；在軟 件版本發布以后，甚至可能要花費60-100倍的代價。由此可見，在項目開展過程中，軟件需求的改變應當盡量早地提出。這樣才可能花費少，容易被實現。

誤區3：軟件程序主要由代碼組成，因此編碼階段是整個軟件項目的最重要的階段，應該給與大量的時間，并且集中主要的資源。分析：與以前相比，由于軟件的規模和復雜度的增加，以及半自動化軟件代碼開發平臺的出現，現代軟件項目管理的中心發生了轉移--不是 著重編碼階段，而是著重系統總體/詳細設計階段。一般說來，在現代軟件項目管理中各種資源的合理分配比例是：項目論證、風險評估階段3%，項目需求分析階段8%，系統總體/詳細設計階段45%，編碼階段10%，系統測試階段34%。

誤區4：為了便于代碼的維護修改，在系統的詳細設計階段文檔工作應該做到寫出所有程序的偽碼。分析：通常偽碼的最大作用是對程序的算法流程進行描述，便于人們深入了解程序的功能和實現過程。可見，在一定程度上偽碼的確有利于對 程序代碼的維護和修改。但是，我們知道為了保證項目文檔和程序代碼的一一對應關系，維護程序代碼的時候同時需要對項目文檔進行維護。偽碼和程序代碼是非常接近的，對偽碼進行維護的話，相當于進行了2倍的程序代碼維護。工作量是很大的。所以切合實際的方式應該是對一般 的程序文檔做到程序流程圖即可，對于涉及了較復雜算法的才需要偽碼。

誤區5：既然在項目人員配置中設置了專門的測試人員，那么軟件所有的內部測試工作全部應該由測試人員完成。分析：軟件程序測試可以分為“白盒法”和“黑盒法”兩種方式。由于使用“白盒法”對測試人員各方面素質的種種要求，在進行程序測試時 測試人員總是最優先使用“黑盒法”。他們的工作方式往往是先對程序進行“黑盒法”測試；如果測試沒有通過，不得已這才考慮對程序代碼 進行“白盒法”測試。顯然，這種對“白盒法”有意無意的“逃避”，對軟件的可靠性和穩定性構成了威脅。如何解決這個問題？一方面需要 提高對測試人員的要求，另一方面也需要程序員完成部分的“白盒法”測試（實際上，程序員往往也是進行“白盒法”測試的最佳人選）。

誤區6：軟件項目管理只是相關技術部門的事情，與公司其他部門無關。分析：在競爭日益激烈的今天，軟件項目規模大、復雜度高而且時間要求緊迫。要想提高公司的軟件項目管理水平，這就需要提高公司的整體 參與意

識，需要公司各個部門協同作戰。例如需要會計部門協助進行項目預算，財務管理和費用控制；需要研究部門（技術委員會）指派專家 協助進行各種風險評估，提供技術指導；需要后勤部門提供各種保障。

誤區7：在開發進度滯后的情況下，可以聘請更多的程序員加入到開發團隊中，通過增加人力資源來趕上進度。分析：在注重團隊開發的時代，開發方應該根據目前的軟件項目管理水平慎重考慮這個做法。如果新加入的程序員對目前軟件項目的應用行業 有一定了解，并且可以很快適應了開發方的項目管理方式、軟件開發風格、團隊協作氛圍；那么“新人”的加入是有益的。否則，可能會“好 心好意做壞事”。因為盡管其個人能力很高，但是為了使其與大家一起協同工作，開發團隊不得不分出人手對其進行與項目有關的技術/業務培 訓，更重要的（也是難度最大的）是還要引導其融入團隊。這可能需要花費開發團隊許多時間和精力，很有可能使項目進度更慢。

誤區8：技術骨干應該成為項目的項目經理，項目經理一定是所有項目成員中薪水最高的。分析：在“軟件作坊”時代，這是一種普遍使用而且效果不錯的方法；而在“軟件工廠”時代，這種方法卻帶來各種問題，有時甚至直接導致 項目失敗。究其原因這主要是因為隨著現代軟件開發分工的細化，對項目經理的要求也發生了根本的改變--最注重的不是其對某項專業技術 的掌握程度，而是其組織、領導、協調開發團隊的能力（當然，可以兩者均突出最好）。至于項目經理的薪水問題，這和定薪制度有很大關系。通常，項目經理執行的是管理人員的薪酬體系，而其他人員執行的是技術人員的薪酬體系。項目經理的薪水在項目成員中是比較高的，但不 一定是最高的。有時候，為了激勵技術人員，項目中的技術骨干得到的酬勞比項目經理要高。

誤區9：只有項目經理以及部門主管才會關心項目整體進度，程序員只關心自己的開發進度。分析：這是一種“官僚”的想法。實際上程序員作為團隊中的一員，他不僅僅是在打一份工，更重要的是在參與一件“作品”的創作。在體味 工作的辛苦的同時，程序員更重要的是要享受創作的快感。項目經理不應該漠視程序員對“成就感”的追求，應該向每一個人詳細描述最終“ 作品”將會如何美妙和令人興奮，并且在到達最終目標的路上設立一系列的里程碑。每當項目整體推進到一個里程碑的時候，項目經理應該把 這個消息告訴每一位項目成員。實際上，這不僅僅可以讓所有的項目成員享受到階段勝利的喜悅，還可以激發大家更大的工作熱情，提高工作效率。

誤區10：為了保證項目繼續，為了留住核心程序員，加薪吧。分析：加薪可以說是很多企業在挽留程序員時所使用的常用方法。這一招可能暫時奏效，不過往往是人留下來了，但副作用也來了--加薪的 人未必見得多干活，沒有加薪的人卻開始消極怠工了。其實，項目的進行過多地依賴程序員的個人技術是“作坊”時代沿襲下來的“陋習”。既然IT行業人員的流動是無法控制的，現在項目的執行應該更加注重團體的力量，應該更多的考慮公司整體技術水平和核心技術能力。例如形 成公司自己的專家知識庫，類/函數庫，第三方控件庫，擁有自主版權的開發平臺等。另外，實際上程序員萌生去意的原因很大程度上不是薪水，而是缺少激勵和尊重。這需要項目經理使用“老土”一點的辦法，找適當的時機對程序員做一做思想工作，向其描述項目的美好未來，讓其 感受關心和尊重?？傊獜亩喾矫嬷直ＷC項目的順利開展，而不是簡單地加薪。

如何估算大型項目的工作量

我是一個九人開發團隊的領頭人。一般來說，我們所從事的是（項目）支持和強化的工作，但是有的時候，我們被要求完成一項大型工作，而這項工作大到肯定可以被作為一個項目來看待。我們所面臨的問題是：我們很難估算需要在這些大型項目上所花費的工作量和時間。通常我們對工作量的估算不足，所以搞得在最后幾個星期里才拼命加班完成所有的工作。我正在嘗試先預估工作量，然后在未來將其翻倍。有沒有什么簡單的方法能夠解決這個問題？——Kurt

回答：

Kurt：在先前的專欄里，我們看到了在估算大型工作的工作量問題上，很多支持人員都是出了名的估算不準者。我們知道，支持工作的很多特點會在支持人員試圖估算大型工作的工作量時合起來阻撓他們。好消息是，如果你知道這些陷阱并試著避免它們，而且學會一些基本的估算技巧，那么在估算工作量上你就會做得更好。

估算的技巧

項目的特點之一是，工作和可交付的內容是唯一的。這就意味著對項目的估算也會是唯一的。但是，基本的估算技巧能夠幫助你建立一個對項目需要多長時間的初步評估。有一些技巧要依賴于暴力（硬性估算），有一些會利用同其他項目之間的相似性，有一些要依賴數學計算，而有一些要靠其他人的意見。如果有可能的話，你應該使用兩種方法，并對比它們（的結果），看它們是否合理和一致。如果這兩種估算（的結果）很接近，那么你的估算就是相當準確的。如果它們相差較大，那么你就應該改進估算的方法，并找到不足之處了，或者使用第三種估算方法來嘗試獲得某種一致性。

對工作結構的分解

進行估算最精確的方法通常是建立一個將工作分解開的結構。這就需要在一個很高的層面描述工作，然后將該工作分解成更小的部分，直到每項活動都能夠被估算在80小時以內完成。（或者如果項目比較小的話，就是40個小時。）這通常也需要花費很多時間和精力。但是，如果你非常好地了解了這項工作，而且如果你能夠確定所需要的工作都已經包括進了你的工作分解結構里，那么你就常常取得獲得一個精確的估算。

以前的經驗

盡管所有的項目都是唯一的，但是有些項目同其他的項目非常相象。使用以前的經驗這一技巧，你可以找一找以前完成的類似項目，然后根據那個項目實際所需要的工作量來估算你當前的工作。這是一個估算工作量的好方法，因為它允許你使用以前的經驗。但是，它要求你以前有一個類似的項目，而且你必須具有對那個項目實際工作量的準確計算。例如，假設你正在將你的財務軟件升級為一個新的版本。如果這是你第一次完成一個新的版本，你就沒有以前的經驗。但是，如果你以前進行過軟件的升級工作，你就應該非常了解這次升級需要什么。即使這個項目是唯一的，它也和以前所做過的工作非常類似。

類比／比率

類比技巧和以前的經驗非常類似。但是，你不需要具有先前的項目作為比較對象，而是尋找具有類似特點的項目。例如，讓我們還是來看一下前面升級財務軟件的例子吧。如果你以前從來沒有對進行過升級，那么你就不知道這個項目會花多長時間。但是，你也許的確具有升級應收帳款（Accounts Receivable）軟件包的經驗。盡管這兩項工作不相同，但是它們很類似。知道了升級應收帳款軟件所花費的工作量和時間，會有助于你估算財務軟件升級所需要的工作量和時間。

根據比率來估算是類似的，不同的是，你要考慮當前項目同以前的項目相比而言的大小。一個很簡單的例子是，你以前可能在四個地區辦事處里安裝過一個新的財務軟件?，F在你被要求將同樣的軟件包安裝到另外兩個辦事處里。如果所有的條件都相同的話，在新項目（兩個辦事處）上所花費的工作量將是前一個項目（四個辦事處）所需工作量的一半，這樣考慮是理所當然的。

專家的意見

即使你以前沒有進行過這樣的項目，其他人可能經歷過。找一找內部或者外部的專家，看看他們是否能夠用其以往的經驗來指導你進行估算。例如，如果你必須部署一項新技術，你可以找一個研究分析師，請他來幫助你估算所需工作量的水平。

參數造型

要使用參數造型（parametric modeling）這一技巧，工作中就必須存在一個模式，這樣的話對一個或者多個基本部分的估算就能夠被用來推動整體的估算。例如，如果你必須在40個分支辦事處里部署一個財務軟件，那么你就可以（分別）估算大型、中型和小型辦事處所需要的典型時間和工作量。然后，將你的40個辦事處按照大型、中型和小型來分組。最后，通過計算來估算整個項目的時間和工作量。

事實上，你的提問就是這個技巧的另一個天然例子。你說你會將你團隊成員所估算的工作量翻倍。由于這里使用了某種算法，所以也可以被當作參數造型技巧。

概要

Kurt，你的問題是一個我碰到過很多次的問題。支持人員在估算大型項目時所碰到問題一部分與文化相關，一部分與技術相關。首先，他們通常的工作文化是迅速地辨別和解決問題。這就使他們養成了一種短期的思想，當他們需要在一個更長的尺度內對工作進行籌劃和估算的時候，這種思想并不總是能夠很好地轉變過來。

其次，這里可能有一個技術鴻溝。要跨越這一鴻溝，你需要將我在這里描述的估算技巧介紹給你的人員。這些技巧可能會促使你使用自己公司已有的技術和資源來估算大型工作的工作量，從而使估算工作更加容易一些。在得到你人員的估算并將其翻倍以前，看看這兩個方面。如果你能夠將他們培訓成為更好的評估者，你在未來會獲得更加準確的估算。

如何計算項目的投資收益率

jeanne說：

老師說：考試中經常會考計算項目的投資收益率，如何計算項目的投資收益率？

鐘鼓樓回答：

我也是現學現賣，不對的地方，請大家指教。

項目投資的主要決策指標有三個：凈現值（NPV）、內部收益率（IRR）和盈利指數（PI）。

▲ 凈現值是將項目在計算期內各年的凈現金流量（即現金流入減去現金流出），以行業投資的

第三篇：信息系統項目管理師-論文萬能

【摘要】2011年8月末，我作為項目經理參與**省**發電有限公司生產EAM項目，該項目投資700萬元，建設工期為18個月，通過該項目的建設實現了發電企業的信息化管理，該項目于2013年3月份，通過了業主方的驗收，贏得了用戶的好評，并作為重點標桿單位，向其他發電企業推廣實施。本文結合作者的實際經驗，以該項目為例，討論了信息系統下跪門建設過程中的**管理，主要從以下幾個方面進行了闡述:

【正文】2011年8月末，我作為項目經理參與**省**發電有限公司生產EAM項目，該項目投資700萬元，建設工期為18個月，通過該項目的建設實現了發電企業的信息化管理。該項目采用JAVA語言開發，數據庫使用Oracle 10g。中間件采用Weblogic9，系統采用B/S架構，數據庫服務器為Linux系統，應用服務器為Windows webservice 2003企業版。

由于本項目的順利上線及涉及到業務的考核，因此，在本項目中，xx管理尤為重要，在本項目管理中，我作為項目經理特別除了對其余管理領域進行克制恪守的管理外，特別對XX管理從如下幾個方面進行了管理。

【結尾】經過我們團隊的不懈努力，歷時6個月的時間，本項目最終在2013年3月，通過了業主方組織的驗收，本項目的順利驗收，解決了發電企業信息化從紙質手段到電子信息建設的過度。得到了業主方的好評，同時也作為發電集團向下級單位重點推廣項目奠定了基礎。本項目的成功得益于我的**管理。當然，在項目中還有一些不足之處，比如：在項目的實施過程中，由于現場機房空調自動調溫系統出現兩次故障，導致服務器溫度異常，致使應用服務器宕機問題，經過空調廠家工程人員的處理才得以解決。進度上受到了一些影響，不過，經過我后期的糾偏，并沒有對項目產生什么影響。在后續的學習和工作中，我將不斷的充電學習，同時進行業務交流，提升自己的業務和管理水平，力爭為我國信息化建設做出自己的努力。

第四篇：信息系統項目管理師論文

項目管理師論文寫作指南.............................................................................................................................6 1.大綱中的要求......................................................................................................................................6 2.為什么會覺得論文考試難................................................................................................................6 3.論文的格式與寫作技巧......................................................................................................................7 3.1 格式要求..........................................................................................................................7 3.2 寫作進度把握..................................................................................................................7 3.3 論文選題........................................................................................................................7 3.4 論文提綱........................................................................................................................7 3.5 正文寫作..........................................................................................................................7 3.6 摘要寫作..........................................................................................................................8 4.論文考題分析....................................................................................................................8 5.如何準備論文..................................................................................................................10 論文實例.......................................................................................................................................................10 1.論文論題..........................................................................................................................................10 2.范文一：論信息系統項目的整體管理..........................................................................................11 3.范文二：論信息系統項目的整體管理..............................................................................13 4.范文三：論信息系統項目的整體管理..............................................................................15 第一篇 項目管理（進度、風險）...........................................................................................................18 IT項目管理..........................................................................................................................................18 IT項目管理的三個條件、五個步驟..................................................................................................18 IT項目管理的五大錯誤......................................................................................................................23 IT項目管理：問題、體系、方法......................................................................................................24 成功的軟件項目需要幾點要求...........................................................................................................26 對軟件項目管理的探討.......................................................................................................................27 給項目管理一雙慧眼...........................................................................................................................33 工程項目管理的新挑戰—可持續發展...............................................................................................37 管理的三化與六法...............................................................................................................................40 管理項目失敗的教訓...........................................................................................................................41 論項目管理中的量化管理...................................................................................................................43 淺談如何實行有效的項目管理...........................................................................................................45 淺談項目管理.......................................................................................................................................46 淺談項目管理機制...............................................................................................................................54 淺析軟件項目管理中的10個誤區.....................................................................................................58 如何估算大型項目的工作量...............................................................................................................60 如何計算項目的投資收益率...............................................................................................................61 如何領導員工成為項目管理者？.......................................................................................................62 簡談項目的沖突的管理.......................................................................................................................65 IT外包項目管理..................................................................................................................................66 如何應對零星IT項目采購.................................................................................................................68 軟件公司項目管理的三大誤區...........................................................................................................69 軟件開發項目管理的簡單方法...........................................................................................................70 軟件企業如何面對項目管理...............................................................................................................71 軟件外包項目管理3點體會...............................................................................................................72 軟件項目成功的要素...........................................................................................................................72 軟件項目管理的成功原則...................................................................................................................75 軟件項目管理原則談...........................................................................................................................77 軟件項目管理中的一些誤區...............................................................................................................80 軟件項目失敗因素分析.......................................................................................................................80 什么是項目戰略計劃...........................................................................................................................81 實施項目問題管理的七步走...............................................................................................................82 述訴項目管理.......................................................................................................................................84 項目管理8要點...................................................................................................................................85 項目管理13禁忌.................................................................................................................................87 項目管理：經濟發展的驅動力...........................................................................................................87 項目管理成功的12個關鍵原則.........................................................................................................90 項目管理的20個關鍵問題.................................................................................................................91 項目管理的20條錦囊妙計.................................................................................................................92 項目管理的成功方程式.......................................................................................................................94 項目管理的概念...................................................................................................................................95 項目管理的概念及項目的過程管理...................................................................................................97 項目管理的三角鏈...............................................................................................................................99 項目管理的三角難題與解法.............................................................................................................101 項目管理的是與非.............................................................................................................................103 項目管理理論中關于軟件項目外包采購管理的探討.....................................................................107 項目管理三角形.................................................................................................................................111 項目管理體系：戰略好還要管理好.................................................................................................112 項目管理要突出解決好四個問題.....................................................................................................113 項目管理業績為上.............................................................................................................................115 項目管理應樹立的理念.....................................................................................................................117 項目管理中問題與對策探討.............................................................................................................118 應用P3E進行IT項目管理初探.......................................................................................................120 影響項目的因素及經驗總結.............................................................................................................129 用項目總結來減少問題的重復發生.................................................................................................130 有效控制質量、工期、成本三大目標.............................................................................................133 在項目管理中面對面交流最重要.....................................................................................................134 IT項目如何做好進度管理................................................................................................................135 對“項目時間管理”的認識和體會--“趕工和快速跟進”在工作中的運用...............................137 工程項目成本/進度綜合控制方法及應用........................................................................................138 軟件開發項目進度控制淺談.............................................................................................................141 項目的生命周期.................................................................................................................................145 項目管理過程之進度控制.................................................................................................................147 項目管理系列之進度和成本管理.....................................................................................................148 IT業項目管理與人才環境................................................................................................................151 論項目管理中人的管理.....................................................................................................................154 如何組織軟件開發團隊.....................................................................................................................156 如何組織一個高效的開發團隊.........................................................................................................158 軟件項目團隊建設的“三個中心”.....................................................................................................160 團隊管理101招.................................................................................................................................161 項目管理中“以人為本”的思想..........................................................................................................163 “樣板參照法”——項目管理團隊建設的有效工具.....................................................................165 IT應用的風險管理............................................................................................................................168 風險項目投資選擇與管理.................................................................................................................172 工程項目管理中的風險分析與防范.................................................................................................173 項目風險管理.....................................................................................................................................174 項目風險管理解決方案及應用.........................................................................................................178 項目風險管理研究.............................................................................................................................181 項目風險緩解、監控和管理.............................................................................................................184 項目管理中風險評價的必要性.........................................................................................................185 需求階段的風險分析.........................................................................................................................189 怎樣做好軟件項目風險計劃.............................................................................................................190 工程項目成本管理從降低采購成本入手.........................................................................................191 “模擬成本制”讓績效動起來.............................................................................................................192 項目成本管理.....................................................................................................................................193 項目執行中的成本控制.....................................................................................................................195 管理好基礎架構和開發團隊.............................................................................................................197 流程因誰而變——談流程管理的驅動因素.....................................................................................198 論項目合同管理.................................................................................................................................200 項目管理中的組織結構.....................................................................................................................204 淺談項目建議書、可行性研究、項目評估、項目后評價的作用及其區別.................................206 項目評估.............................................................................................................................................208 項目前期管理的一種科學方法——可行性研究工作.....................................................................209 軟件項目過程管理保證軟質量.........................................................................................................213 項目管理過程之質量管理.................................................................................................................214 項目經理如何避免降低軟件質量.....................................................................................................215 項目經理如何確保工程質量.............................................................................................................217 項目質量管理.....................................................................................................................................219 怎樣確保項目評估的精確.................................................................................................................220 項目采購管理.....................................................................................................................................221 項目采購和合同管理.........................................................................................................................222 項目策劃的方法.................................................................................................................................223 項目策劃的流程.................................................................................................................................225 項目策劃的原則.................................................................................................................................229 項目策劃特征.....................................................................................................................................232 項目策劃原理.....................................................................................................................................234 項目管理中的人力資源管理和溝通管理.........................................................................................237 第二篇 信息安全.....................................................................................................................................240 計算機安全的項目管理.....................................................................................................................240 第三篇 信息監理.....................................................................................................................................243 分公司對項目監理工作的管理.........................................................................................................243 信息化工程須引入項目監理.............................................................................................................244 信息系統工程監理特點.....................................................................................................................245 論信息系統工程——ERP項目監理.................................................................................................246 信息工程監理中的三大控制目標及關系.........................................................................................249 電子商務項目監理.............................................................................................................................250 第四篇 信息化（企業）.........................................................................................................................252 CIO如何制定高效IT項目提案？...................................................................................................252 ROI-項目經理的朋友還是敵人.........................................................................................................254 成為一個積極主動的項目經理.........................................................................................................255 從CIO看企業信息化需求................................................................................................................256 打造一個成功的項目經理.................................................................................................................257 你是不是一個優秀的項目經理人.....................................................................................................258 如何成為一個積極主動的項目經理.................................................................................................259 軟件項目經理所必需具備的素質.....................................................................................................259 微軟資深經理人的項目管理經驗.....................................................................................................262 我國信息化建設現狀及政策法律環境.............................................................................................265 我國政府信息資源開發的現狀、問題及措施.................................................................................268 “十一五”信息化規劃需要四個“新”.........................................................................................270 信息化需要四步走.............................................................................................................................271 信息化為什么需要項目管理?...........................................................................................................272 信息化項目監理 早做早安心...........................................................................................................273 信息化項目實施與應用的一個質量標準體系.................................................................................274 信息化項目“手術”如何做 成本管理是關鍵...............................................................................277 信息化項目與實施效益評估體系初探.............................................................................................279 信息技術應用項目的戰略風險分析.................................................................................................280 信息化與企業戰略管理.....................................................................................................................284 信息化與企業經營戰略.....................................................................................................................284 商業企業的信息化建設基本策略.....................................................................................................291 城市信息化建設的原則·框架·途徑.............................................................................................294 信息化建設的項目管理計劃、實施和控制兵法.............................................................................296 ERP是一個集成立方體 項目經理作用非凡...................................................................................300 正確認識ERP項目高風險性............................................................................................................305 電子商務項目成功的關鍵.................................................................................................................306 電子政務項目的風險管理.................................................................................................................308 如何規避電子政務項目的風險?.......................................................................................................310 如何實施電子政務項目.....................................................................................................................312 一個項目經理眼中的電子政務建設困境.........................................................................................313 以項目為中心的電子政務.................................................................................................................316 流程再造與企業項目化管理.............................................................................................................318 企業信息化規劃要軟硬兼施.............................................................................................................320 企業e化項目實施的典型問題及處理.............................................................................................321 如何規避企業信息化建設項目管理中的難題.................................................................................323 企業邊界與邊界之外—項目管理是什么.........................................................................................324 企業的項目化管理.............................................................................................................................326 企業管理的第三條道路.....................................................................................................................328 企業如何在信息化項目中進行項目范圍管理.................................................................................329 企業信息化項目規劃建設八策略.....................................................................................................346 企業信息系統項目管理的問題點和對策.........................................................................................348 淺談項目管理和企業管理的沖突和協調發展.................................................................................351 權力之爭使信息化項目內耗嚴重.....................................................................................................355 如何把握信息化項目管理.................................................................................................................356 如何化解信息化阻力.........................................................................................................................358 如何提高信息化建設項目進度控制.................................................................................................359 如何做好零售企業信息化項目規劃.................................................................................................360 通信企業信息化建設中的項目管理.................................................................................................363 以企業信息化項目管理為基礎的評價.............................................................................................364 第五篇 多項目管理與計劃、范圍、資源、協作管理.........................................................................368 IT項目成功——良好交流必不可少................................................................................................368 IT項目管理-計劃階段.......................................................................................................................369 IT項目管理中的團隊溝通................................................................................................................371 軟件項目規模小 項目經理溝通少...................................................................................................372 項目管理從改變團隊開始.................................................................................................................373 大型工程項目中的進度管理.............................................................................................................376 中國大型建設項目的質量管理和項目管理.....................................................................................380 中小型軟件開發項目管理.................................................................................................................382 防止軟件工程項目范圍蔓延的七個步驟.........................................................................................384 某企業IT項目范圍管理綜述...........................................................................................................386 如何做好范圍管理？.........................................................................................................................387 項目范圍管理.....................................................................................................................................388 項目范圍管理是項目成敗的關鍵.....................................................................................................389 項目范圍是項目成敗的關鍵.............................................................................................................392 糟糕的范圍管理導致項目失敗.........................................................................................................394 論信息系統的需求管理和范圍管理.................................................................................................395 項目中如何使用范圍變化管理.........................................................................................................398 基于過程的軟件項目實施方法.........................................................................................................399 淺談項目組合管理.............................................................................................................................400 如何管理多個IT項目.......................................................................................................................403 人力資源中的項目管理.....................................................................................................................405 項目管理計劃中的資源儲備.............................................................................................................406 項目計劃進度控制與資源管理.........................................................................................................406 項目規劃技巧.....................................................................................................................................409 項目計劃及質量管理.........................................................................................................................410 IT項目管理過程-控制.......................................................................................................................414 IT項目管理過程-跟蹤.......................................................................................................................415 計劃與跟蹤.........................................................................................................................................416 第六篇 績效管理.....................................................................................................................................420 績效管理更注重過程管理.................................................................................................................420 如何全面構建企業的績效管理體系.................................................................................................421 注重項目管理體系建設，提高項目績效.........................................................................................425 無所不在的績效管理.........................................................................................................................435 績效管理如何事半功倍.....................................................................................................................436 只有這樣才能讓績效考核不走樣.....................................................................................................437 淺談企業的績效溝通.........................................................................................................................441 典型績效問題怎樣給“貓”分“魚”.............................................................................................443 第七篇 其他.............................................................................................................................................444 從IT職位到IT角色.........................................................................................................................444 從技術到管理.....................................................................................................................................445 從優秀IT項目經理到千萬富翁的距離只有1m——如何當好項目經理.....................................446 當程序員變成軟件項目經理.............................................................................................................450 關于我們的思考-項目實例................................................................................................................453 當心最危險的十類IT經理...............................................................................................................456 管理大師的思想境界.........................................................................................................................458 軟件文檔的必備要素.........................................................................................................................463 軟件項目設計和開發評審指南.........................................................................................................463 項目與項目管理軟件.........................................................................................................................465 周伯生教授談軟件研發項目管理.....................................................................................................466 我的項目經驗總結.............................................................................................................................469 5

項目管理師論文寫作指南

05年上半年軟件專業技術資格與水平考試開考了信息系統項目管理師這一與系統分析師同級別的高級考試，考試的內容包括綜合基礎知識、案例分析和論文三個部分，其中論文讓許多的考生感到為難。為什么會覺得難呢？有沒有什么辦法解決？一起來逐步分析。

1.大綱中的要求

《信息系統項目管理師考試大綱》中，要求考生根據試卷上給出的四個有關項目管理的論文題目，選擇其中的一個，按規定的要求寫論文和摘要。論文可能涉及的內容極其廣泛，主要有信息系統項目管理，信息安全，信息系統項目監理，信息化戰略與實施，大型、復雜和多項目的管理，項目績效考核和績效管理6個主要模塊的論題方向，這6個方向又分為若干個子內容。

2005年上半年的考試雖然只出了一道論文題目——“論信息系統項目的需求管理和范圍管理”，似乎與考試大綱有所背離，但考試內容并沒有偏離大綱，屬于“信息系統項目管理”方向中的內容。所以作論文考試的準備時一定要緊緊圍繞考試大綱來進行。

歷屆高級資格考試論文寫作一般會有如下的要求：

簡述你所從事的項目及你在項目中擔任的角色；

在項目中關于論題方向碰到的問題和解決對策；

對項目實話的總結和展望。

2.為什么會覺得論文考試難

參加項目管理師的考生大致有兩種類型：在校學生和在職人員。

對于在校的學生來說，參加項目管理師這一高級別的考試無異于一種挑戰。這是因為：

缺乏項目實戰經驗；

沒有從事過項目管理；

學業繁重，沒有時間來準備考試；

考試范圍太廣，許多的知識沒有接觸過；

技術方面掌握不扎實，基礎不牢；

沒有寫過學術論文。

大學里的計算機專業或信息管理專業都會開設軟件工程課程，也有少數的院校開設項目管理課程，即便是有，考生自己也會感覺只有理論知識沒有實踐經驗，總覺得心里不踏實，寫出來的文章會不夠力度。大多數的研究生也只是跟隨導師做一些技術性的工作，項目管理方面的工作做得較少。其它專業的學生當然會覺得難度更大。

對于在職人員來說，可能存在以下困難：

有項目經驗但要寫成論文覺得寫作水平有限；

長期從事某一個方面的工作，很少從事項目管理這種綜合性的工作；

從事技術性工作或研究工作，熱衷于技術實現，管理工作做得較少；

工作任務過重，無暇復習及攥寫論文。

對于這兩類考生，又以在職人員居多。要想考試過關，一是要盡量從繁忙的學習和工作中抽出時間來應考；二是要熟悉考試論文的寫作格式及注意事項；三是掌握一定的論文寫作技巧；四是需要閱讀大量的資料來充電，五是在考試之前作適當的練習。當然如果您項目經驗十分豐富，可以把重點放在鍛煉寫作技巧上來。

3.論文的格式與寫作技巧

3.1 格式要求

項目管理師考試的論文不同于要放在學術雜志上發表的學術論文，也不同于學生的畢業論文，她主要是對自己工作經驗的總結，更象一份述職報告，因此在格式上的要求也比較簡單。

論文的內容分為兩部分：摘要和正文。這兩部分的書寫要注意以下的格式：

達到字數要求。摘要一般要求200字以上，500字以下，正文要求2500字以上。在論文寫作的方格紙上會有字數提醒。

不要在論文中書畫圖形，盡量用文字表述。

盡量保持卷面清潔，如果實現需要劃掉文字，在字上劃一橫線即可。

不必寫關鍵詞。

3.2 寫作進度把握

論文的寫作時間只有兩個小時，要在短短的兩個小時里寫出一篇高質量的論文確屬不易，需要考生有較為豐富的理論和實踐知識的積累，當然也不必害怕，因為這還是有章可循的。這里建議的時間分配如下：

通讀論題，選定論題（5分鐘）；

構思論文，寫論文提綱（10分鐘）；

正文寫作（80分鐘）；

摘要寫作（15分鐘）；

復查論文（10分鐘）。

論文的摘要由于在論文的寫作過程中論文的論點及內容可能會有所變化，建議在寫作完正文后再寫摘要。下面按寫作步驟詳細解說。

3.3 論文選題

拿到試卷后，先把試題快速通覽，找到自己最容易發揮，最擅長的方向的論題。為了照顧大多數考生的情況，論文題目會比較寬泛。

需要注意的一點是，既然是考項目管理師，論文內容當然不會關心過多的技術細節問題，重在項目管理。

選題時要考慮應和什么項目相關聯。文章至少要與一個項目關聯起來。那么如何選定項目呢？

在校的學生由于沒有項目經驗，往往不知論文應與什么項目關聯為好。一是要看題目要求，如今年5月考試的論文題目中就明確指出要是參與管理過的大型信息系統項目，因此一般不要以如“學生成績管理信息系統”這種課程設計性質的項目來寫；二是盡量寫自己熟悉的，如一般的可寫高校人事MIS，高校教務MIS等，在職人員也可如此考慮。項目可以是虛構的，不需要指明開發單位，委托單位；三是如果有大型項目或可以構思出大型項目則更佳。

3.4 論文提綱

選定論題后不要急于動筆直接在答題紙（論文的答題紙為方格作文紙）上寫作。因為直接寫作很難有一個整體的思路，而且在寫作的過程中可能會涂改而使得卷面不整潔，影響評卷人的心理。不提倡在草稿紙上書寫論文再抄至論文答題紙上，因為考試的時間本就十分有限，抄寫論文的時間也需不少。不妨先花點時間理理寫作的思路，在草稿紙上寫作論文的提綱，所謂“磨刀不誤砍柴工”。

提綱中寫些什么內容呢？可有如下的內容；

擬聯系寫作的項目，思考如何聯系此項目來寫作；

擬寫論文的主要論點。

各段落的主要內容，如果直接以論點來分段就不必再寫此項了。

論文的閱卷者一般會把論文看兩遍，第一遍快速瀏覽全文的論點，以找出文章的“文眼”，第二遍再仔細閱讀。如果論點清晰，會給閱卷者以清晰明朗的感覺。

3.5 正文寫作

有了提綱了，寫正文就輕松多了。正文可采用“總——分——總”式，即文章開頭提出中心思想，再分述論點，最后在結尾處作出總結；也可用“提出問題——分析問題——解決問題”的逐步深入的方法。寫作時注意以下幾個方面：

理論聯系實際，一定要與項目關聯起來討論，切忌空談理論；

論點要正確，合乎工程實踐的實際情況；

可以分條敘述的方式，但不要全文用此方式；

論點清晰，最好每段在開頭處或結尾處點明論點；

結尾處要對項目的實施情況，以及應用論點論據應用情況作出總結。

不必列舉過多的計算公式。

文章要帶有一定的學術性，更多的應是談項目經驗。

不要關注于技術，多就論題寫管理方面的問題及采取的措施。

3.6 摘要寫作

摘要可按如下幾個方面來寫：

項目概述，包括自己主持或參與的項目及自己擔任的角色。

論文的主要論點。

為方便大家書寫摘要，這里給出兩個摘要的書寫模板。

模板一：（論點——項目概述）

本文以我主持（或參與）的××××××（項目名稱）為實例，探討了××××××（論文論題），認為××××××（論點）。在此項目中，我擔任了××××××（角色），參與了××××××（任務），實施后×××××（用論文中的方法實施后的效果）。

模板二：（項目概述——論點）

×××××（項目名稱）是×××××（項目說明），在此項目中，我擔任了×××××（角色），參與了×××××（任務）。對于項目的×××××（論題），本文認為×××××（論點）。該項目實施后×××××（用論文中的方法實施后的效果）。

下面給出模板一的一個實例，以供參考：（論信息系統項目的需求管理和范圍管理）

本文以我主持的某商業銀行網上銀行系統項目為實例，探討了作為開發方公司在信息系統項目的需求管理和范圍管理方面碰到的問題及解決的辦法，文章首先解釋了需求管理和范圍管理的基本概念，認為需求工作做得不扎實，項目范圍把控不好是導致項目難以成功的主要原因，提出應以CMM過程改進的思想指導項目的需求管理和范圍管理，項目在需求分析階段應確定需求可以決策的人，充分和客戶溝通以正確把握需求，對于需求和開發范圍的變更管理提出了解決的辦法。我在該項目中擔任了開發方的項目經理，自始至終參與了整個項目的建設，自2004年4月項目啟動至2004年12驗收歷時8個月，系統至今運行穩定，取得客戶的好評，很大程度上得益于項目成功的需求管理和范圍管理。

4.論文考題分析

我們來把考試大綱的內容與歷年的軟件資格與水平考試高級（包括系統分析師和項目管理師）相關的考試論文題目列舉出如下表所示，也許您會有所啟迪。

表1

歷年軟件資格和水平考試高級考試與考試大綱相關的論文題

模塊方向子內容歷年考題考試年份

信息系統項目管理項目選擇

可行性分析論信息管理系統的可行性研究1997年

項目生命周期流程管理

項目的整體、范圍、進度、成本、質量、人力資源、溝通、風險和采購管理論軟件開發的質量管理1989年

成本/效益分析1990年

論軟件項目的質量保證1993年

論項目管理工具的選用1998年

論軟件質量保證2002年

論軟件開發的風險控制2003年

論軟件開發成本管理2004年上半年

論應用軟件開發范圍和功能的確定2004年下半年

論項目管理中的進度控制2005年上半年

論信息系統項目的需求管理和范圍管理2005年上半年項目管理師

項目評估

企業級信息系統項目管理體系的建立

項目中的質量管理與企業質量管理異同分析論軟件開發的質量管理1989年

論軟件項目的質量保證1993年

論軟件質量保證2002年

信息安全信息安全體系系統的安全與保密控制1992年

信息安全體系的安全風險評估

企業信息安全策略論企業信息系統的安全2005年上半年

論企業內部網的安全策略2004年下半年

信息系統工程監理監理的方法與工作流程

監理的機構及監理工程師

監理中的質量、投資、進度和變更控制

監理中的合同管理、信息管理和安全管理

監理中的組織協調

信息化戰略與實施企業建設信息化系統的過程

信息化系統建設過程中常見問題

新技術對信息化建設的影響

CIO在信息化建設過程中的作用

信息化規劃

不同類型信息化建設過程中的差異

電子政務建設論電子政務信息共享整合2005年上半年

企業自身管理成熟度對企業信息化建設的影響

大型、復雜信息系統項目和多項目的管理計劃過程

跟蹤和控制過程

范圍管理論應用軟件開發范圍和功能的確定2004年下半年

論信息系統項目的需求管理和范圍管理2005年上半年項目管理師

資源管理

協作管理

項目績效考核與績效管理團隊績效與項目績效的關系

績效評估的方法

項目績效指標設計

績效改進

從上面的表格中可以看出，還沒有出過題目的內容極可能會成為下次考試出題的對象，“信息系統項目管理”模塊中的“項目的整體、范圍、進度、成本、質量、人力資源、溝通、風險和采購管理”是近四年的高級考試中必出論文考題的內容。據此，作者列出19個考題供大家參考和練習（每個模塊3~4個）：

l 信息系統項目管理

論項目團隊建設

論項目溝通管理

論企業信息系統項目管理體系的建立

論項目采購管理與合同管理信息安全

論企業的信息系統安全體系

論企業信息系統的安全控制策略

論企業信息系統安全風險的評估信息系統工程監理

論信息系統項目的工程監理

論信息系統工程監理中的質量控制

論信息系統工程監理中的進度控制信息化戰略與實施

論企業信息化的規劃

論電子政務項目管理

論企業信息化的建設

大型、復雜信息系統項目和多項目的管理

論信息系統項目計劃的制訂

論信息系統項目資源管理

論信息系統的跟蹤與控制項目績效考核與績效管理

論項目績效評估的方法與策略

論企業信息化中的績效評價機制

論信息系統項目績效指標的設

5.如何準備論文

可以從以下幾個方面著手準備論文：

l.看別人寫的項目經驗文章，這是快速彌補經驗不足的辦法。以下的網站可以找到不少的資料：http://www.tmdps.cn（中國項目管理信息網）等。如果可以看到一些項目的實施方案書則提高實踐經驗更快。

2介紹幾本好書。如果時間充足（先看項目管理師教程），您可以參考以下幾本書籍：《IT項目管理》（美）凱西.施瓦樂貝著

機械工業出版社；《企業信息化行動綱領——中國企業信息化方法論》 吳文釗著 機械工業出版社；《軟件開發項目管理》 韓萬江 姜立新著

機械工業出版社；《企業信息化總體設計》 李清 陳禹六著 清華大學出版社；《領跑企業信息化CIO工作手冊》 汪牧清 夏敬華 聞博著

電子工業出版社；《信息化績效評價框架、實施與案例分析》 郝曉玲 孫強著 清華大學出版社。

一定要在考試前動手寫幾篇論文?？删颓懊嫣峁┑?個方面的論文題目去找幾個自己感興趣的，多準備幾篇，最好能有6篇，不必每個方向都寫，6個方向選其中的2——3個即可。寫完以后，最好能在身邊找一位專家幫你批改論文，寫作水平會迅速提高。多與項目管理經驗豐富的人員聊天談項目實施的感受，談項目管理的點點滴滴，得到一些書本上不能得到的知識。

要想通過項目管理師考試，絕非一躇而就，論文寫作較為真實地集中體現了考生的水平和能力。但論文的寫作也是有章可循的，不僅要擠出時間來準備，還要注意論文的寫作格式與寫作技巧，勤于練習，虛心向經驗豐富的同仁請教。

論文實例

1.論文論題

這次一起分析和討論的論題是：“論信息系統項目的整體管理”。題目如下：

項目管理的9大知識領域包括項目的整體、范圍、時間、成本、質量、人力資源、溝通、風險和采購管理，其中項目整體管理包括在項目生命周期中協凋所有其他項目管理知識領域所涉及的過程，它確保項目所有的組成要素在正確的時間結合在一起，以成功地完成項目。

信息系統項目往往比較復雜，經常出現各項目目標之間或參與項目的人員之間的沖突，項目管理人員常常要處理各種沖突，協調為完成一個項目所需的人員、計劃以及工作。

請圍繞“論信息系統項目的整體管理”論題，分別從以下三個方面進行論述：

1、概要敘述你參與管理過的信息系統項目，以及該項目在項目整體管理方面的情況；

2、論述項目整體管理的主要內容及其重要性；

3、詳細論述你參與的信息系統項目整體管理的過程，方法及實際效果，討論在項目實施過程中出現的沖突情況及解決辦法。

2.范文一：論信息系統項目的整體管理

[摘要] 醫療保險管理信息系統涉及到醫保管理部門、各定點結算點（醫院、藥店）、開發商，加之政策多變、業務不成熟，需求變化頻繁，開發的難度和風險較大。在某市醫保管理信息系統開發過程中，我作為用戶方的項目負責人參與了項目的整體管理工作，我在項目整體管理中采取了針對性的措施，加強了參與各方的溝通，注重用戶需求和需求的變化，合理配置項目組成員，對風險進行了及時的評估并順利地控制了風險。通過這些辦法，平衡了各方的利益，控制了項目的范圍和進度，保證了項目的質量，順利完成了這個項目。

[正文] 幾年前，某市為實施城鎮職工基本醫療保險，開發了一套醫保管理信息系統，我作為用戶方項目負責人，參與了項目管理、系統分析和編程的部分工作。

這個系統的功能包含了基金征集和支付管理、參保單位（職工）管理、定點結算點管理、參保職工就診結算管理、IC卡管理等，目標管理人數為30萬、定點結算點200個，計劃投資400萬元；采用C/S結構，數據集中保存在市醫保中心，定點結算點與醫保中心之間數據實時交換。

通過公開招標，明確了項目的范圍、時間、成本和采購，因此，我把整體管理工作的重點放在了項目的質量、人力資源、溝通和風險管理管理，目的是保證實現計劃的功能并按時投入運行。在工作中，我根據實際情況，采用了靈活的工作方法，取得了較好的效果。

該系統在04年一次上線運行成功，目前運行情況良好。

一、加強了溝通管理。

該項目涉及到醫保中心、參保單位、定點結算點、系統開發（集成）商等多個單位，從需求分析到系統設計、測試都要各方參與、協調配合，由于各方的地理位置十分分散，難以經常或長期集中，因此，各方及時有效的溝通是項目成功的必要條件。為解決好這個問題，我采取了三個辦法：

1、提高大家對溝通作用的認識，特別是各方主要領導人對溝通的必要性和重要性的認識，從而對溝通工作給予必需的人員、經費和時間支持，保證了溝通工作得以按計劃進行。

2、對項目組外部的溝通，堅持從實際出發，采用多種溝通的方式。一方面，把必要的、重要的溝通需要以聯席會議、工作計劃、總結報告的形式制度化。另一方面，在適用的前提下，采用靈活、經濟的溝通方式，比如：對一般的小問題或者是簡單問題進行電話交流，復雜一點的問題開碰頭會，需要后續解決的、比較重要的及涉及面較大的問題要形成書面的會議記要，有必要的情況下要由相關單位加蓋公章確認。

3、對項目組內部溝通，進行適當的控制，避免形式主義，在保證效果的前提下節省時間，提高工作效率。規定項目組成員在每天工作過程遇到問題，將其記錄下來，然后在以郵件方式發送給需要溝通或者詢問者。大家每天下班之前收取郵件，對于可以直接回答的問題則直接以郵件方式回復，對于無法直接答復而只需與提出問題者討論的問題，在第二天上班前進行商議確定。而需要眾人一起討論的問題，則放到每周會議上討論，較緊急的問題召開臨時性會議。通過以上方法，基本上實現了有關各方及項目組內部的有效溝通，及時發現問題、解決問題，避免了因各方立場不一致造成嚴重對立而影響項目進度，避免了因交流不暢形成重大質量問題。

二、合理配置人員。

對項目組人員進行規劃配置，合理分工，明確責任，保證項目各階段、各方面的工作能夠按計劃完成。我們在項目組長配置了以下人員：技術組長一名，負責技術難題攻關，組間溝通協調；需求人員5名，負責將用戶需求轉換成項目內的功能需求和非功能需求，編制項目需求規格說明書，針對每個迭代集成版本與用戶交流獲取需求的細化；設計人員5名，負責對需求規格說明書，進行系統設計；開發人員8名，實現設計，完成用戶功能；集成人員1名，負責整套系統的編譯集成，督促小組系統功能提交，及時發現各模塊集成問題，起到各小組之間的溝通的紐帶；測試人員2名，對于集成人員集成的版本進行測試，盡可能的發現程序缺陷，以及未滿足需求的設計；文檔整理人員1名，負責對小組內產生文檔的整合，統一；維護人員1名，系統驗收后，維護人員，建議維護 人員早期進入項目參與項目測試以便順利承擔起項目維護職責。

在人員的管理方面，一方面要求項目組成員相對穩定，以保證開發工作的連續性，另一方面，不搞終身制，不能夠勝任職工作的堅決調換，保證項目整體工作不受影響。通過平常和階段性的工作考核、評審，對不合格人員進行調換。有一名需求分析人員因為工作態度不好，與客戶單位業務人員關系惡化，調查落實后，我們立即把他調出項目組。

三、進行風險評估，在進度和質量之間進行權衡，爭取最佳平衡點。

由于項目資金已經確定，我就在進度和質量之間找平衡點，力爭把風險降到最低。由于醫療保險業務本身比較復雜，加之當時國家政策不穩定，業務流程不是很規范，系統需求也在不斷調整、完善，給項目的進度帶來一定影響。由于這個項目涉及到十余萬參保職工的醫療待遇，影響很大，通過與用戶方領導溝通，決定不搞“形象工程”，在質量和進度之間優先考慮質量。同時，考慮到這個項目的采用了增量開發模型和模塊化的設計方法，我把項目目標進行了分解，涉及到業務經辦的部分優先完成，保證系統在規定的時間上線運行，其它不影響業務經辦的、輔助性的功能適當延期，包括醫療監督、統計分析和部分報表。這樣雖然整體工期有所延長，但沒有影響系統及時上線。這種做法同時照顧到各方的利益，把整體風險降到了最低。

四、重視需求變化的客觀性，強化測試，保證軟件功能完整、正確、高效。

質量是軟件的生命，軟件功能完整、正確、高效是軟件質量的重要組成部分，也是用戶最關心的內容。

我們采用了軟件工程方法，使用漸增式的增量模型，注重滿足用戶需求和需求的變化。由于國家沒有統一的醫療保險業務經辦規范流程，另外，為保證醫?；鸬氖罩胶猓鞯囟荚诟鶕t?；鸬倪\行情況進行不斷的政策調整，造成醫保系統的需求變化頻繁。根據這個情況，為保證軟件滿足應用需要，我們規定：在整個項目的開發過程中，凡是用戶提出的、經調查情況屬實、經技術可行性論證可行的，全部予以響應。同時，采取措施避免需求的反復和無意義、不合理的變更。對較大的變更和比較關鍵的變更，要經各方聯席會議論證通過，參與人員簽字負責，并由提出變更的單位加蓋公章確認。由于不合理或技術上不可行而沒有通過的需求變更，要提出替代的解決辦法，并與用戶單位協商，達成一致意見后予以解決。

測試是保證軟件質量的重要手段，也是讓用戶直觀地了解軟件質量和熟悉軟件操作的有效途徑。我有計劃地強化測試環節，讓用戶由始至終地參與測試工作。我們主要采取黑盒法進行測試，把工作重點放在測試用例的準備上，嚴格定義測試索引、測試環境、測試輸入、預期結果、評價標準，盡可能的把各種業務的不同情況都表現出來。同時，我們準備了一家定點結算點進行實際運行測試，在該結算點手工記帳和計算機聯網記帳同時進行，并有計劃地穿插一些測試用例。通過這些辦法，及時發現了和解決了許多問題。

經過努力，該系統一次上線運行成功，并在6個月后通過了驗收?；仡欗椖康恼w管理工作過程中，雖然沒有大的事故發生，但仍然存在許多問題，主要有以下3點：

1、軟件測試不系統，用例準備仍不夠充分，忽視了壓力測試。系統實際運行后隨著參保職工和定點結算的增加，運行速度下降很快，達不到設計要求。雖然通過升級硬件緩解了這個問題，但造成了資金的額外投入。

2、在需求分析過程中對各方目標的權衡不夠充分，導致定點結算點使用的結算子系統功能較弱，提供的系統接囗又不夠強大，給定點結算點內部管理帶來不便，一些必要的統計和查詢功能難以實現。

3、對開發人員與操作人員對系統的要求差異認識不足，兩者的直接溝通不夠，造成一些對操作員而言很重要的問題在開發人員那里得不到重視，產生了一些矛盾，給項目帶來不利影響，特別是影響到用戶方及領導部門對項目的整體印象。

綜上所述，良好的項目溝通管理；合理的人力資源配置；用風險評估在進度和質量之間進行權衡；重視需求變化的客觀性，強化測試，保證軟件功能完整、正確、高效是我在某市醫療保險管理信息系統項目中的整體管理中的四個主要實踐，為項目的成功奠定了堅實的基礎。在以后的項目整體管理工作中，我要加強測試的系統性和科學性，注重各方利益的權衡，繼續深化各方的溝通，協調好開發工作各個部分及各個方面的關系，更好地完成項目。

[老師評語] 此文基本達到了考試要求。寫作比較規范，行文流暢。文章結構清晰，所述的一些情況確實是在項目開發過程中所經常碰到的而又需要解決的問題,給人的感覺問題真實,針對問題采用的措施亦 較為有效。

3.范文二：論信息系統項目的整體管理

[摘要] 本文以筆者所主持的某卷煙廠物流控制及管理信息系統項目為實例，探討了信息系統項目整體管理在項目實施過程中的重要性，并分別論述了項目計劃編制、項目計劃實施，以及項目綜合變更控制等項目整體管理過程，在整個項目生命周期內所起的積極作用及其實施經驗。在該項目中，本人以開發方公司副總工程師身份擔任項目經理，負責了項目的整體規劃、組織實施和管理控制。我們科學地運用了信息系統項目整體管理的一般理論知識及其指導方法，有效地保障了項目的順利實施，很好地滿足了各利益相關者的需求和預期期望。

[正文] 信息系統項目的整體管理是項目取得全面成功的一個至關重要的前提和基礎。通過項目整體管理，可以確保項目所有的組成要素在適當的時間有機地結合在一起，以順利、成功地完成項目。這在本人所主持的某卷煙廠物流控制及管理信息系統項目實施過程中得到了充分驗證。

該項目是一個綜合性的系統工程項目。從技術實現角度講，它所涉及到的主要技術領域包括卷煙生產工藝、制造業物流技術、工業自控技術和計算機管理信息技術等等。從利益相關者角度講，它又涉及到作為需方的煙廠、物流設備供應商、工業自控設備供應商，以及作為信息系統集成商的我公司。因此，這是一個復雜程度高、涉及面較廣、實施周期長的綜合項目。

面對這樣一個項目，作為開發方公司的副總工程師，我受公司委托擔任該項目經理，我首先想到的是應該將主要精力放在項目的整體管理上，科學地運用相關理論知識及其指導方法，做好項目的全局性統領工作，協調完成項目所需的所有人員、計劃和工作，帶領整個項目團隊實現項目的順利成功。另外，我也考慮到，除了項目本身內部的各組成要素之外，項目的相關利益者也不容忽視。一方面是作為公司承擔的一個對外項目，我們實行項目經理負責制，具有一定意義上的獨立性，但同時也是公司整個組織日常持續運作中的一部分，離不開公司的整個組織環境，而且公司也已決定將該項目作為業務延伸拓展的一個新的窗口，將其提升到了一個相當重要的位置。另一方面，該項目是需方煙廠整體搬遷重大技改項目的一個部分，其實施的進度、質量和成本等，受到來自其主管上級部門和煙廠新經營目標的嚴格要求和控制。此外，還會涉及到物流設備供應商、工業自控設備供應商等中標單位。所以，項目的整體管理顯得是那么的重要、不可或缺。否則，稍有顧及步驟之處，都將會給項目的實施帶來很大的麻煩和影響。

下面分別從項目計劃編制、項目計劃實施，以及項目綜合變更控制等方面對項目的整體管理過程加以簡要論述。

1、關于項目計劃編制：

凡事預則立、不預則廢。信息系統項目尤其如此。只有站在統領全局、整體規劃的高度，對項目進行科學、合理、全面、周詳的計劃，預先制定一個用來協調所有其他計劃、以指導項目實施和控制的文件，才能使項目得以順利實施并最終取得成功。項目計劃記錄了計劃的假設條件和方案選擇，可以為各利益相關者之間的溝通提供了一個參照，并確定了關鍵管理審查的內容、范圍和時間，同時還為進度評測和項目控制提供了一個基線。

在該項目中，我們對項目計劃具體內容的確定，結合項目的各方面實際情況，主要參照IEEE1058.1中“軟件項目管理計劃”的基本內容，其中包括項目介紹、項目組織、管理過程、技術過程和進度預算等五個部分。在堅持科學、合理、全面、周詳的原則基礎上，還視部分具體的計劃條款，詳略得當。但所有的計劃內容都必須是正確的、明確的、易理解的和可執行的，切忌未經確認、含糊不清、容易誤解、難以執行的項目計劃描述。這就要求我們必須在制定計劃之前或在制定過程中，與需方煙廠、公司上層、其他設備供應商、項目團隊各技術和管理小組進行充分的溝通與協商，明確確定項目有關內容，如項目可交付成果、技術方法工具、組織結構、各工作包、資源要求、預算分配、進度計劃等。

另外，因為項目管理的最終目標是滿足或超越各利益相關者的需求和期望，在項目計劃過程中考慮利益相關者分析也是非常重要的，但不宜將其作為項目整體計劃的一個部分，最好把它作為公司內部使用的一個項目計劃附件。該項分析的內容可以包含各利益相關者的所屬組織、所處角色、項目利益、影響程度及管理這些利益相關者的合適建議等。對于項目經理來說，花點時間來關注和利用這些信息也是非常重要的。我在該項目管理過程中的感覺是，在項目的日常實施過程中，尤其是在項目陷入某些困難的時候，這些分析結果常常會幫助我起到對癥下藥、藥到病除的作用。

當然，項目計劃的制定和執行，也必須考慮和注意它的動態性和靈活性。尤其是對于綜合性的項目而言更加重要。由于項目復雜程度高、涉及面較廣、實施周期長，所以其中的變更是在所難免的。在該項目實施過程中，由于煙廠項目局部需求的修改，或由于各方交流的失誤等，曾經導致了部分項目內容的變更從而致使了項目計劃人員和進度的變化和調整等。而且這種計劃動態修訂的次數還不止一次。所以項目計劃制定以后并非一勞永逸，它與項目實施過程相互滲透，有一個動態的、靈活的修訂過程。

2、關于項目計劃實施：

項目計劃實施是指對項目計劃中所規定的工作進行管理和實施的過程。項目產品主要都在項目實施階段生產出來，所以項目的大部分時間和預算都花在這一階段。在該項目中，我們的軟件編程、與需方煙廠有關技術人員的具體溝通、與有關設備供應商的具體交流、階段性調試，直至全套系統軟件和技術文件的完成等，都發生在這一階段。為了能夠成功地完成項目產品，項目團隊進行了大量反復的具體編程、學習、溝通、修改、軟硬件安裝和調試工作。

如前所述，該項目涉及到的主要技術領域包括卷煙生產工藝、制造業物流技術、工業自控技術和計算機管理信息技術等，我們項目團隊不僅要從事熟知的信息技術工作，還要花大量時間和精力了解煙廠具體的細節性的需求，學習卷煙生產工藝、制造業物流理念和常識、物流設備的基本工作原理和管理知識、自控設備的基本工作原理和管理知識等等，以及反復地和煙廠、相關設備供應商、公司上層等進行必要的交流溝通。作為項目經理，在此階段主要的工作是要按照預先制定的項目計劃，利用項目團隊組織機構和工作程序，領導項目團隊開展各項工作，管理和協調各利益相關者的關系，成功地將項目計劃投入實施。

項目計劃和項目實施是相互滲透、不可分割的活動。在該項目的實施中，我們對于項目計劃編制和實施之間的協調改進工作主要采取誰實施誰計劃的原則。雖然項目經理負責整體項目計劃，但編制該計劃的大量基礎信息均來源與各技術組和技術人員。事實證明，按照這一原則，項目計劃的編制更加合理、可行，實施起來更加順利。

3、關于綜合變更控制

綜合變更控制是指在項目生命周期內對項目變更進行識別、評價和管理的工作，這也是項目經理及其項目團隊的一項重要工作。如前所述，該項目的復雜程度高、涉及面較廣、實施周期長，所以其中的變更是在所難免的。當有變更要求提出的時候，作為項目經理，我都會召集項目團隊相關人員，進行協商討論和工作安排。主要內容有：

A、對變更因素加以影響：通過在范圍、時間、成本和質量等關鍵項目尺度的權衡，對促使變更形成的因素進行分析和采取對策，確保變更對項目有利；

B、確定變更是否發生：在最終確定變更發生前，項目經理必須了解項目幾個關鍵方面的狀態。尤其是一些重大變更，項目經理必須與公司高管層，以及其他利益相關者進行必要的交流與溝通。

C、對變更加以管理：項目經理在項目管理過程中必須嚴格行事，盡量避免或減少變更的發生。但變更不可避免發生時，更重要的是對變更進行管理。

按照項目整體管理的指導方法，我們在變更發生時，要求必須輸入項目計劃、變更申請和績效報告等重要內容，輸出更新后的項目計劃、糾正行措施和經驗性教訓記錄等。通過這些做法，使我們的項目變更控制與管理工作規范有序。

該項目順利成功地實施完畢已經有一年多了?；仡櫰饋矶裕瑧摰靡嬗谖覀冊陧椖窟M行的最初期階段就引入了項目整體管理理念和方法，對項目進行了科學、規范的整體管理。通過項目整體管理，使項目所有的組成要素在適當的時間充分地、有機地結合在一起，極大地提高了項目的實施效率。

[老師評語] 本文基本達到了考試的要求。摘要和正文都寫得比較流暢，給人的感覺思路清晰，層次感強。項目所述情況基本與項目研發過程中的情況相同，給人以真實感和作者有豐富的項目實施經驗的感覺。

文中如果能把一些具體的問題和解決辦法展開一下則更佳。如：在變更控制上為了盡量減少變更的數量，采用的需求變更申請表的形式，讓煙廠方需求人員埴寫需求變更申請表，并簽名。一方 面控制了需求變更的隨意性；另一方面對明確了各方的責任，也為開發人員提供了方便。

4.范文三：論信息系統項目的整體管理

[摘要] 本文以我主持某市地稅銀行代理繳稅系統項目為實例，探討了信息系統項目的整體管理，及個人的一些經驗教訓。在該項目中我受領導委派，擔任銀行方項目組長。通過實踐，對項目整體管理有了更深刻的認識：（1）前期工作很重要，需要與各方進行充分溝通，明確接口，需要制定切實可行的計劃；（2）項目管理是一項系統的、動態的工作，不要僵硬化，應保障信息共享，及時根據情況變化進行計劃調整；（3）在項目管理中，特別是牽涉部門比較多時，應采用各種方式保證良好的溝通、協調，保證進度。

通過本人及項目組的努力，該項目按計劃完成，達到目標要求。[正文] 項目整體管理是項目管理中一項綜合性、全局性的管理工作。它決定在什么時間，在哪些預期的潛在問題上集中資源和基礎和工作，在問題變得嚴重前進行處理，協調項目干系人及各項工作使項目走向成功。整體管理的工作流程主要有制定項目章程、指定項目初步范圍說明、制定項目管理計劃、指導和管理項目執行、監督和控制項目工作、綜合變更控制、項目收尾。項目整體管理是一個項目能否高效、順利的進行的一項基礎性的工作。

2003年，根據某市地稅部門和我行的代理協議和該市我行的零售業務部門提出的需求，我受省行科技部門指派，擔任銀行方的項目經理，組織開發了某市地稅銀行代收項目，該項目2003年5月中旬啟動，2003年10月1日正式投產。項目涉及我行省行、市行，市地稅、市地稅方的信息系統外包開發公司四家單位。

在該項目的整體管理中，我在項目管理的五大過程中分別做了以下工作：

（1）在項目啟動過程中，我根據業務需求，提出項目開發立項報告，完成項目的啟動工作；進行項目的初步范圍制定，對項目的目標、范圍，項目組織、進度里程、項目費用估算進行分析；

（2）在項目的計劃過程中，用project制定項目初步管理計劃；

（3）在項目的執行過程中，配置人力資源，調配系統資源，執行項目計劃，協調、溝通項目組、市地稅方、市中行，確保項目正常、順利完成；

（4）在項目的監督、控制過程中，收集分析項目周報，舉行項目例會，將項目進度與項目計劃進行比較；對變更情況進行分析、流程改變、記錄分析，跟蹤項目風險點，并制定風險應對方案；

（5）在項目收尾過程中，要求業務部門提供項目驗收測試報告、項目投產申請；完成運行部門的項目投產單。

該項目業務跨越銀行及稅務兩大行業，并各有自己的信息系統，如何實施雙方系統的互聯，進行需求的確定是一個比較困難的工作，需要解決稅務局和銀行，銀行業務部門與技術部門的各種沖突，即要滿足對方的需求，也要考慮本行的利益。

可以通過從對方角度考慮問題，進行良好的溝通，最后圓滿解決不合理的需求問題。如稅務局開始時提出，納稅人在銀行交費后，稅票信息需要在銀行保留。而銀行系統一般只保留交易的賬務信息，對保存稅票信息需要比較大的代價來實現，為解決該問題，我從稅務局的角度進行分析：首先會有其他銀行也加入地稅代收的工作，其次納稅人可能在就近的銀行或稅務局打印發票，所以，稅票信息需要集中保存，集中保存的最合適地方是稅務局。

在開發工作中，可以把行內業務需求人員加入到項目組中，或者建立緊密的溝通機制，調動業務人員積極性，讓其在項目開發的需求確定，業務測試中發揮積極作用，減少需求的反復，開發的重復勞動，減少投入，確保工程進度。

對避免不了的需求變更。需要需求方以文字的形式對該變動進行規范、明確的闡釋：如要求地稅局或業務部門要提供需求變更說明，填寫需求變更申請表等，減少需求提交的隨意性，大大減少需求變更的數量。

該項目還有一個特點，涉及的單位和人員比較多，協調工作比較復雜，對此我的解決辦法是：（1）與地稅局及業務部門，要充分進行業務流程、交易接口、通訊接口的討論，確定雙方的交易功能，技術接口定義，明確各方的工作職責；（2）在項目組中，根據明確的需求，及時進行工作分解，根據項目組成員的特點、專長分配各項子任務，做到職責明確，分工合理；

（3）在項目開發過程中，要及時進行信息交流，及時向各方發布項目進度情況，我通過建立文件共享服務器，發布技術協議，需求分析，概要設計，項目計劃，項目周報等文件，讓項目組成員及配合的業務人員對工作有全面了解，對工作重心及時掌握，盡量減少內部沖突；

（4）在功能開發基本完成后，及時組織雙方的系統聯合測試，在準生產環境中運行，及時發現問題，解決問題。

（5）建立良好的進度管理機制：在項目啟動時就用Project制作計劃，統一分發，與其它單位協商計劃文檔；在項目進行中，及時完善、更新進度；計劃前提有變動時要及時調整；建立跨單位的周例會制度，項目周報填報制度等。

該項目歷時一個月，順利完成投產工作，并在生產中，達到要求，為銀行創造了效益，為地稅部門減輕了負擔，為納稅人提供了方便，實現了多贏的結果。同時也鍛煉了我的項目管理能力，對項目整體管理有了更深刻的認識：項目管理前期工作很重要，需要制定切實可行的計劃，需要充分溝通，明確接口；應對項目管理有是一項系統的、動態的工作的認識，不要僵硬化，應保障信息共享，及時根據情況變化進行調整；在項目管理中，特別是牽涉部門比較多時，應采用各種方式保證良好的溝通、協調。

[老師評語] 論文基本上達到了考試論文的寫作要求，均是作者實踐經驗的總結，侃侃道來。美中不足的是：論文正文的字數稍少了點。在正文中的有些論點可適當再展開一下。如進度管理中是填制項目周報發現其它單位并不愿意填制周報，解決辦法：主動將自己項目組的周報發給其它單位并作溝通，在此基礎之上再表明希望這個單位也能回一個進度周報，即主動溝通。

5、范文四

信息系統項目的整體管理

[摘要]

本文以我參與的某大型結構分析軟件系統的消化、移植、開發項目為實例，探討了信息系統項目的整體管理，指出項目整體管理在信息系統項目實施中具有重要地位和關鍵作用，應根據項目的實際情況和特點，在做好項目整體管理各項工作內容的前提下，有針對性地強化某一方面整體管理的工作。具體論述了在本信息系統項目的實施中，系統動態地處理問題、明確接口定義并嚴格實施、換位思考以化解沖突三種方法對整體管理工作的積極意義。

[正文] 項目整體管理在項目實施中具有重要地位和作用，在本人參與的一項工程分析軟件系統的開發項目，充分體現了這一點。該項目開發的主要內容是：將引進某外國的運行于大、中型計算機（如，IMB4381、WAX3300等）的結構有限元分析系統進行消化、移植，形成有自主版權的可運行于工作站（如，HP715）和微機的結構分析系統，并在此基礎上開發出當時國內急需的結構優化功能、圖形化前后置顯示功能和復合材料結構單元等新功能。該項目工作量大，僅需消化、移植的某源程序就有四十多萬條；技術復雜，涉及有限元理論、離散數學、計算機技術、各型計算機體系結構和操作系統的兼容性、結構力學、材料力學等多學科；多單位協作，有多達四個單位參加；參加人員眾多且跨不同專業，有數學人員、力學人員和計算機開發應用人員。如此大型復雜的信息系統項目開發，綜合的整體管理至關重要，決定著項目的成敗。

為了保障項目的成功實施，在前期由我單位領導掛帥成立了項目領導小組，統一管理、協調根據項目的學科方向組建了相應項目研發小組，成立了項目管理組負責組間協調和項目的整體管理工作，我擔 任了項目管理組的組長，自始至終參與了項目的整體管理工作，切身地感到了研發活動的整體管理所起到的重要作用，并認識到了一些整體管理的具體理念和方法。

項目整體管理是貫穿項目生命期全過程的一項綜合性和全局性的管理工作，它以項目成功為目標，采取統一、協調、集約、澄清等措施，使項目實施全過程沿正確的軌道運行。通常項目整體管理工作包括：

（1）制定項目章程，確立項目的組織機構和運行機制，約定行動規則、制定實施標準等；（2）初步確定項目的工作內容和工作范圍，明確完成項目都要做哪些工作；

（3）在項目實施各分計劃的基礎上，制定、協調、集成項目管理計劃，并作為項目實施的準繩；（4）依據管理計劃，指導和管理項目實施過程中各項活動的執行；（5）監督、控制、協調項目的各項工作；

（6）進行變更控制管理，保持項目的完整性和一致性；（7）對項目進行收尾總結，工作有始有終，積累經驗。

信息系統項目往往比較復雜。如本人參與的這個項目，既有涉及不同技術和專業的，如建立力學模型，設計各種算法，使用高級語言和匯編語言等，也存在有不同組織和個人的不同期望，如有計算力學所，計算機所，對模塊性能有不同觀點期望。協調進度、成本、質量，進行有效溝通和資源配置，樹立全局觀念等，都是項目所必須的，但又往往存在大量主觀和客觀的問題，對以上的管理構成障礙和挑戰。在各項目目標之間和參與項目的單位和人員之間經常出現不協調或沖突，項目管理人員必須在這些不協調或沖突釀成危機前處理好各種矛盾和沖突，協調為完成項目所需的資源、計劃以及工作?？梢姏]有有效的整體管理工作，項目是難以成功的。

信息系統項目整體管理工作的內容繁多、涉及方方面面，存在著需要特別關注和做好的重要方面，換句話說，就是要特別關注在正確的時間、正確的場合，使用正確的方法，投放資源和實施工作。以我參與的這項工程分析軟件開發項目來說，項目最終按期完成，基本實現預期目標，與項目整體管理工作中著重做好了系統、動態地處理問題；明確接口并嚴格實施；換位思考以化解沖突、矛盾這三方面的工作密切相關。

系統、動態的處理問題，就是對項目實施中出現問題的處理應放到項目全局中進行考慮，全面地、聯系地進行分析，動態的而不是靜止的加以解決。在本項目開發實施中，由于系統的需求是來自工程領域利用計算機進行結構分析與優化，并實現大型分析系統的微機化，項目成功的技術重點和難點在于不同計算機系統的差異和兼容性，而項目負責技術總體設計的總工程師是工程力學方面的專家，對其它領域專業知識（特別是計算機專業）的局限，使動態內存管理模塊的設計方案幾易其稿，難以滿足系統總體要求，造成項目開發進度在系統移植階段停滯不前。為了解決這個問題，我向項目領導小組及時請示，取得了單位領導的支持，召集相關的主要負責人，通過認真分析，采取了數學組專家提出的方案，并由數學組的組來負責移植階段的總體技術工作，系統移植的技術難題才得以正確解決。由此可以看出，在項目實施的全過程中，系統地看待和處理問題，動態地、恰如其分地調配資源，有益于項目整體管理工作目標的達成。

明確接口并嚴格加以實施，是促使項目成功采取的一個重要措施。本結構分析系統是在已有原型基礎上的移植、開發，在模塊之間的接口調用上，存在不同的解決方案，具有不同的性能指標，如何整合集成，僅僅給出籠統的標準還不夠，在項目進行到一定的階段，必須由模塊開發的各方，在項目有關的負責人協調下，確立明確、具體的接口定義，并嚴格按照定義的接口檢測驗收，以保證軟件系統的完整性和一致性，形成階段可交付的子系統，推進項目的進度。在如此龐大的信息系統項目開發過程中，沒有明確的接口定義，項目在模塊聯調階段，將面臨大量協調、溝通、扯皮、更改工作，為項目推進帶來許多不必要的返工和重復，使本來不存在技術問題的項目實施舉步維艱。我們項目管理組根據以往的經驗，從項目一開始，就特別注重模塊接口定義的整體、全局管理工作，協調各研發小組共同討論接口的設計問題，使各研制組的工作在銜接處平穩對接，沒有因為接口定義的不到位而對項目造成拖延和資源上的浪費，取得了明顯的成效。

項目在開發過程中實施的各項活動交互重疊，不可避免地會發生沖突和矛盾，矛盾和沖突發生時，在雙方方案均具有合理性，又各持己見、相持不下時，換位思考以求折中、平衡，從而化解沖突和矛盾，不失為整體管理工作中的一項行之有效的方法。在本項目中，研發人員主要是兩類專業技術人員組成，工程結構方面的和數學、計算機方面的，兩類人員由于專業背景的關系和出發點的差異，在對問題的解決上，常常各持己見，互不相讓，而有時沖突的原因是對對方專業知識的缺乏。為了很好的解決這一問題，我們項目管理組經過計劃和組織，約定在每周五舉辦學術交流活動，請兩方面的專家講解、介紹各自專業領域的基本知識，使雙方都能對對方的技術觀點有了較客觀的理解，從而有利于在工作配合、協調時，能夠站在對的角度，尋求到雙方均滿意的平衡點。由于課題組積極的措施和倡導，換位思考成為項目參加人員的共同理念，為項目的成功實施創造了良好的文化氛圍。

該項目在歷時兩年后，較為成功的實現了當初制定的目標，并被評為當年部科技進步二等獎，能取得這樣的成績，很大程度上得益于良好的項目整體管理工作，特別是系統動態地處理問題、明確接口定義并嚴格實施、換位思考以化解沖突這三種解決項目沖突的方法。

[老師評語] 本文整體感覺比較流暢，觀點鮮明，論文中講述的情況，特別是對于多學科交叉的大型信息系 統項目來說，作者的三點主要論點的體會，給人的感覺比較實在。

第一篇 項目管理（進度、風險）

IT項目管理

1）IT項目同傳統項目的區別

傳統的項目需要經歷的時間長，使用的是有形資源，項目成果是通過對資源的消耗與形態的轉化來逐步實現的。

IT項目的實質是“知識轉移”，項目是以無形的智力產品為項目目標。典型的IT項目是IT系統的建造(如系統集成)和軟件開發項目。

因此說，IT項目的實質是“知識轉移”，而建造項目的實質是“資源消耗”。當然，并非說IT項目中不存在“資源消耗”，也不是說傳統項目中沒有“知識轉移”。這一點應該得到辨證的理解。

2）項目管理的五個過程與IT項目生命周期

項目的管理過程分為五個過程組，每個過程組由多個過程組成。分為：

啟動過程組

計劃編制過程組

執行過程組

控制過程組

收尾過程組

過程組之間相互關聯，每個過程組的輸出是另外過程組的輸入。同時，各過程組之間不是獨立的事件，在同一階段會有多個過程組同時進行。

典型的IT項目的生命周期分為：

概念階段

需求分析階段

計劃階段

設計階段

執行階段

交付階段

結束階段

項目所處的階段越早，項目不確定性就越大，項目調整或變更的代價比較低。但隨著項目的進行，不確定性逐漸減小，而變更的代價、付出的人力、資源逐漸增加，就會增加決策的困難度。

在項目生命周期的每一個階段都要重復項目管理過程的五個過程組。

3）概念階段

概念階段的主要工作是：

評估商業需求和機會

開發項目以滿足商業需求和機會

財務收益分析

確認相關項目干系人

建立概念方案

啟動項目

啟動項目中最重要的是要建立項目章程，授權相應的項目經理開展項目。

4）需求分析階段

需求分析階段的主要工作是：

收集需求

分析需求并對需求排列優先級

記錄定義下來的需求

確認需要做的需求并細化需求

IT項目管理的三個條件、五個步驟

項目是為完成某一獨特的產品或服務所做的一次性努力。根據這個定義，項目就具有了目標明確性、活動一次性及資源消耗性等特性。換句話說，具備前面三個主要特性的活動，都可以看作是項目?，F實中的項目隨處可見，如設備消缺、會議組織、技術競 賽、結婚典禮以及家居裝修等等，都可以看作是項目。在這些項目的實施過程中，都存在項目管理問題，不過，實際生活與工作中，可能更多關注的事情本身，而對做好事情相關的組織、計劃、控制等過程相對缺少關注，或者沒有經驗與能力加以關注。項目管理是在項目活動中運用知識、技能、工具和技術來實現項目要求。項目管理總體有五個過程：啟動過程、計劃過程、實施過程、執行過程、收尾過程等，包含了九大領域的知識：范圍管理、時間管理、成本管理、質量管理、風險管理、人力資源管理、溝通管理、采購管理及系統管理的方法與工具。作為項目經理要全面掌握這些九個核心領域的知識，并重點把握系統管理的觀念，避免進入某個細節，注意在五個不同階段的重點。

一、項目管理的三個約束條件

任何項目都會在范圍、時間及成本三個方面受到約束，這就是項目管理的三約束。項目管理，就是以科學的方法和工具，在范圍、時間、成本三者之間尋找到一個合適的平衡點，以便項目所有干系人都盡可能的滿意。項目是一次性的，旨在產生獨特的產品或服務，但不能孤立地看待和運行項目。這要求項目經理要用系統的觀念來對待項目，認清項目在更大的環境中所處的位置，這樣在考慮項目范圍、時間及成本時，就會有更為適當的協調原則。1.項目的范圍約束

項目的范圍就是規定項目的任務是什么？作為項目經理，首先必須搞清楚項目的商業利潤核心，明確把握項目發起人期望通過項目獲得什么樣的產品或服務。對于項目的范圍約束，容易忽視項目的商業目標，而偏向技術目標，導致項目最終結果與項目干系人期望值之間的差異。

因為項目的范圍可能會隨著項目的進展而發生變化，從而與時間和成本等約束條件之間產生沖突，因此面對項目的范圍約束，主要是根據項目的商業利潤核心做好項目范圍的變更管理。既要避免無原則的變更項目的范圍，也要根據時間與成本的約束，在取得項目干系人的一致意見的情況下，合理的按程序變更項目的范圍。2.項目的時間約束

項目的時間約束就是規定項目需要多長時間完成，項目的進度應該怎樣安排，項目的活動在時間上的要求，各活動在時間安排上的先后順序。當進度與計劃之間發生差異時，如何重新調整項目的活動歷時，以保證項目按期完成，或者通過調整項目的總體完成工期，以保證活動的時間與質量。在考慮時間約束時，一方面要研究因為項目范圍的變化對項目時間的影響，另一方面要研究，因為項目歷時的變化，對項目成本產生的影響。并及時跟蹤項目的進展情況，通過對實際項目進展情況的分析，提供給項目干系人一個準確的報告。3.項目的成本約束

項目的成本約束就是規定完成項目需要花多少錢。對項目成本的計量，一般用花費多少資金來衡量，但也可以根據項目的特點，采用特定的計量單位來表示。關鍵是通過成本核算，能讓項目干系人，了解在當前成本約束之下，所能完成的項目范圍及時間要求。當項目的范圍與時間發生變化時，會產生多大的成本變化，以決定是否變更項目的范圍，改變項目的進度，或者擴大項目的投資。在我們實際完成的許多項目中，多數只重視項目的進度，而不重視項目的成本管理。一般只是在項目結束時，才交給財務或計劃管理部門的預算人員進行項目結算。對內部消耗資源性的項目，往往不做項目的成本估算與分析，使得項目干系人根本認識不到項目所造成的資源浪費。因此，對內部開展的一些項目，也要進行成本管理。

由于項目是獨特的，每個項目都具有很多不確定性的因素，項目資源使用之間存在競爭性，除了極小的項目，項目很難最終完全按照預期的范圍、時間和成本三大約束條件完成。因為項目干系人總是期望用最低的成本、最短的時間，來完成最大的項目范圍。這三個期望之間是互相矛盾、互相制約的。項目范圍的擴大，會導致項目工期的延長或需要增加加班資源，會進一步導致項目成本的增加；同樣，項目成本的減少，也會導致項目范圍的限制。作為項目經理，就是要運用項目管理的九大領域知識，在項目的五個過程組中，科學合理的分配各種資源，來盡可能的實現項目干系人的期望，使他們獲得最大的滿意度。

二、項目管理的五個主要過程組 一個項目的生命周期大概分成概念、開發、實施與收尾過程。在概念階段主要是對成本進行分析，對項目的可行性進行研究，其結果是要拿出一份報告，并獲得批準與支持。實際工作中，我們只是有了一個新的想法與概念，就立即轉入開發過程。在開發階段，要有項目計劃書、預算的成本以及工作分解計劃。

我們做事時，可能只是拿出一個簡單的工作分解與大致的項目計劃時間表，就結束了。在實施階段，要有底層的工作包與確定的成本估計，但我們沒有，到了這一步，我們基本上就開始失去了控制，沒有明確的里程碑，我們只是把一個階段當成了一個項目。在收尾階段，我們是經常討論每個項目的教訓，但對完成的工作的文檔工作基本上沒能及時跟上，同樣與用戶之間的交接也未能做好。項目管理的五個過程組：啟動、計劃、執行、控制與收尾，貫穿于項目的整個生命周期，對于項目的啟動過程，特別要注意組織環境及項目干系人的分析；而在后面的過程中，項目經理要抓好項目的控制，控制的理想結果就是在要求的時間、成本及質量限度內完成雙方都滿意的項目范圍。1.項目的啟動過程

項目的啟動過程就是一個新的項目識別與開始的過程。一定要認識這樣一個概念，即在重要項目上的微小成功，比在不重要的項目上獲得巨大成功更具意義與價值。從這種意義上講，項目的啟動階段顯得尤其重要，這是決定是否投資，以及投資什么項目的關鍵階段，此時的決策失誤可能造成巨大的損失。重視項目啟動過程，是保證項目成功的首要步驟。

啟動涉及項目范圍的知識領域，其輸出結果有項目章程、任命項目經理、確定約束條件與假設條件等。啟動過程的最主要內容是進行項目的可行性研究與分析，這項活動要以商業目標為核心，而不是以技術為核心。無論是領導關注，還是項目宗旨，都應圍繞明確的商業目標，以實現商業預期利潤分析為重點，并要提供科學合理的評價方法，以便未來能對其進行評估。2.項目的計劃過程

項目的計劃過程是項目實施過程中非常重要的一個過程。通過對項目的范圍、任務分解、資源分析等制定一個科學的計劃，能使項目團隊的工作有序的開展。也因為有了計劃，我們在實施過程中，才能有一個參照，并通過對計劃的不斷修訂與完善，使后面的計劃更符合實際，更能準確的指導項目工作。

以前有一個錯誤的概念，認為計劃應該準確，所謂準確，就是實際進展必須按計劃來進行。實際并不是如此，計劃是管理的一種手段，僅是通過這種方式，使項目的資源配置、時間分配更為科學合理而已，而計劃在實際執行中是可以不斷修改的。

在項目的不同知識領域有不同的計劃，應根據實際項目情況，編制不同的計劃，其中項目計劃、范圍說明書、工作分解結構、活動清單、網絡圖、進度計劃、資源計劃、成本估計、質量計劃、風險計劃、溝通計劃、采購計劃等等，是項目計劃過程常見的輸出，應重點把握與運用。3.項目的實施過程

項目的實施，一般指項目的主體內容執行過程，但實施包括項目的前期工作，因此不光要在具體實施過程中注意范圍變更、記錄項目信息，鼓勵項目組成員努力完成項目，還要在開頭與收尾過程中，強調實施的重點內容，如正式驗收項目范圍等。

在項目實施中，重要的內容就是項目信息的溝通，即及時提交項目進展信息，以項目報告的方式定期通過項目進度，有利開展項目控制，對質量保證提供了手段。4.項目的控制過程

項目管理的過程控制，是保證項目朝目標方向前進的重要過程，就是要及時發現偏差并采取糾正措施，使項目進展朝向目標方向。

控制可以使實際進展符合計劃，也可以修改計劃使之更切合目前的現狀。修改計劃的前提是項目符合期望的目標?？刂频闹攸c有這么幾個方面：范圍變更、質量標準、狀態報告及風險應對?；旧咸幚砗靡陨纤膫€方面的控制，項目的控制任務大體上就能完成了。5.項目的收尾過程

一個項目通過一個正式而有效的收尾過程，不僅是對當前項目產生完整文檔，對項目干系人的交待，更是以后項目工作的重要財富。在經歷的很多項目中，更多重視項目的開始與過程，忽視了項目收尾工作，所以項目管理水平一直未能得到提高。

另外要重視那一類未能實施成功的項目收尾工作，不成功項目的收尾工作比成功項目的收尾更難，也來得更重要，因為這樣的項目的主要價值就是項目失敗的教訓，因此要通過收尾將這些教訓提煉出來。

項目收尾包括對最終產品進行驗收，形成項目檔案，吸取的教訓等。另外，對項目干系人要做一個合理的安排，這也是容易忽視的地方，簡單的打發回去不是最好的處理辦法，更是對項目組成員的不負責任。

項目收尾的形式，可以根據項目的大小自由決定，可以通過召開發布會、表彰會、公布績效評估等手段來進行，形式是根據情況采用，但一定要明確，并能達到效果。如果能對項目進行收尾審計，則是再好不過的了，當然也有很多項目是無需審計的。

三、項目管理的九大知識領域

項目管理的九大知識領域是指作為項目經理必須具備與掌握的九大塊重要知識與能力。其中核心的四大知識領域是范圍、時間、成本與質量管理。在這些知識領域中還涉及很多的管理工具和技術，以用來幫助項目經理與項目組成員完成項目的管理。如：網絡圖示法、關鍵路徑法、頭腦風暴法、掙值法等，不同的工具能幫助我們完成不同的管理工作。另外，還有很多項目管理軟件，如：Microsoft Project、P3等，作為項目管理的工具，也可以很好的幫助我們解決在項目的各個過程中完成計劃、跟蹤、控制等管理過程。1.項目整體管理知識

項目的整體管理，或者說是綜合管理也不為錯，它是綜合運用其他八個領域的知識，合理集成與平衡各要素之間的關系，確保項目成功完成的關鍵。項目的整體管理包括三個主要過程：

項目計劃制定：即收集各種計劃編制的結果，并形成統一協調項目計劃文檔。項目計劃執行：通過執行項目計劃的活動，來實施計劃。整體變更控制：控制項目的變更。

項目經理負責協調完成一個項目所需的人員、計劃以及工作，統領全局，帶領團隊實現項目的目標；當項目目標之間或參與項目的人員之間出現沖突時，負責拍板定奪；并負責及時向高層管理人員匯報項目進展信息?？偠灾?，項目經理主要負責項目的整體管理，這也是項目成功的關鍵?；仡櫼郧柏撠煹捻椖浚X得主要存在以下問題：

未找到項目發起人，或者項目發起人不明確，常把自己當成項目發起人； 項目交付成果定義不清，以致最后收尾時無法對照計劃進行驗收； 缺少組織結構描述；

對項目的控制未能規范化，尤其是項目范圍的變更控制；

風險管理未得到重視，只是在項目組內討論，并停留在項目負責人的頭腦中； 缺乏項目干系人分析；

沒有規范的進度報告，項目進展報告隨意性較大。

要有效的開展項目管理，引用項目管理的知識體系與方法工具，先依樣畫葫蘆，通過實踐，進一步領會這些內容是必須的。2.項目范圍管理知識

項目范圍的不確定，會導致項目范圍的不斷擴大，作為項目經理，在項目開始時，就要對項目范圍拿出項目干系人都認可的、理解無歧意的范圍說明文檔——項目章程。然后為了保證項目的實施，明確項目組成員的工作責任，還必須分解項目范圍，使之成為更小的項目任務包——工作分解結構（WBS）。

最后還有就是要認識到項目本身不是孤立的，因此有時范圍的變更也是必須的，關鍵是當變更發生時，如何加以控制。

在以上討論之前，最重要的是當面臨項目時，或不知道具體做什么時，如何進行范圍管理。對潛在項目的識別，有四個步驟： 確定做一個什么樣的項目；

業務分析，找出重要的業務過程，分析其中最能從項目中得到好處的過程； 形成項目可能的優勢，確定范圍、好處及約束； 選擇方案，分配資源。

對于從多個項目中選擇項目，或從多個方案中選擇方案的情況，常見的四種方法：整體需要、分類、NPV及加權評分模型。3.項目的時間管理知識

項目的時間管理，就是確保項目按期完成的過程。首先要制定項目的進度計劃，然后是跟蹤檢查進度計劃與實際完成情況之間的差異，及時調整資源、工作任務等，以保證項目的進度實現。在跟蹤過程中，要及時與項目干系人進行交流，以及時發現范圍的偏差，而產生時間與進度上的差異，或項目組成員有意或無意識的虛報了項目完成情況，導致進度的失控。具體包括以下內容：

活動定義：從WBS分解而來；

活動排序：明確活動之間的依賴關系；

活動歷時估算：估算每項活動的時間，可以PERT方法進行； 利用PROJECT 2002等工具軟件，協助項目的時間管理； 利用甘特圖幫助跟蹤項目進度；

利用網絡圖及關鍵路徑分析，協助確定完成日期上的重要性或調整工期對項目工期的影響，以及處理關注的焦點活動。需要注意一點，以前學習項目的時間管理工具及方法以后，就以為可以實現對項目的跟蹤控制了，其實不然，這些工具都是通過人來發生作用，活動也是由人來完成的，因此項目經理不能把太多心思花在工具上，而是學會利用工具來協調人與資源的矛盾沖突。4.項目的成本管理知識

對于項目經理在成本管理方面，就是要努力減少和控制成本，滿足項目干系人的期望。其過程包括：

資源計劃：即制定資源需求清單； 成本估算：對所需資源進行成本估算；

成本預算：將整體成本估算配置到各個單項工作，建立成本基準計劃；

成本控制：控制項目預算的變化，修正成本的估算，更新預算，糾正項目組成員的行動，進行完工估算與成本控制的分析。

在成本管理中涉及很多財務管理的概念、術語、基礎理論及方法與工具的使用，作為項目經理，對這些內容要熟悉，特別是掙值分析的相關術語及簡稱，如：BCWS、BCWP、ACWP、CV、SV、CPI、SPI等等，不光要了解這些術語的涵意，還要掌握他們的計算公式。5.項目人力資源管理知識

項目的人力資源管理就是有效發揮每個參與項目的人員的作用的過程。項目的人力資源管理過程包括：

組織計劃編制：形成項目的組織結構圖； 獲取相關人員：其中重點是業務相關人員；

團隊建設：明確每個項目干系人的責任，訓練與提高其技能，實現團隊的合作與溝通。

因為與人發生關系，其中首先是要明確各自的責任，這一點計劃編制時就要明確，可以通過項目管理軟件幫助項目經理提高效率，并能及時發現任務分解的合理性，最后形成合理的任務分解表。同時，要通過有效的激勵方法來幫助項目成員實施項目計劃，提高效率。項目是通過團隊共同努力實現的，注意充分發揮團隊的作用，使團隊成員各盡所能是項目經理的挑戰。在處理過程中，爭取做到對事不對人，通過有效的會議來幫助項目實現溝通、檢查以及目標實現。6.項目的質量管理知識

項目的質量，理解為項目滿足客戶明確或隱含的要求的一致性程度。注意這里包括明確的要求，也包括隱含的要求。這對IT項目來說，如何滿足用戶隱含的質量要求，可能是IT項目質量失敗的重要原因?？赡芩_發的系統符合需求說明中的要求，卻與用戶實際的要求（包含隱含的需求中），相差很大，導致不一致，結果導致IT項目的失敗。

現代質量管理經過了一個發展過程，目前已建立起相對完善的質量體系，國際組織也有相關的質量文件，以評審普通的生產質量，如ISO2000系列質量標準；對軟件的生產質量，也有一些評價模型，如SQFD模型、CMM軟件成熟度模型等等。其中CMM成熟度模型分成五個層次：自發的、簡單的、有組織的、被管理的及適應的，分別標識為不同的級別。

對于項目管理需要制訂質量計劃，并應用質量保證的工具確保質量計劃的實施。在質量控制的過程中，有許多現成的工具與方法，如帕累托分析、統計抽樣和標準差等。要提高項目的質量，必須在領導中形成質量意識，通過建立一個好的工作環境來提高質量，通過形成質量文化來改進質量，是全面提升項目質量管理的關鍵因素之一。

在以往所經歷的項目中，項目的質量管理基本上沒有得到重視，公司每年都在開展QC活動，該活動的目的就是改進質量，但活動成了科技創新活動，而更多的項目實施過程中，如何開展質量管理，卻未能有所體現，這也是值得探討的問題。7.項目的溝通管理知識

項目的溝通管理非常重要，對項目經理而言，就如同前線指揮需要情報管理一樣，這是使整個項目組掌握項目信息，實施其他管理手段的基礎，所有的控制都有基于溝通基礎之上的。

在項目的開始，需要編制溝通計劃，包括什么時間、將什么內容、以什么樣的格式、通過什么樣的方式、向誰傳遞。在項目的溝通中，可以采用書面報告、口頭報告或非正式的交流，各種方式有利也有弊，關鍵看是否有利于溝通的效果。

溝通的復雜程度隨著對象的增加而快速增加，因此要通過適當的工具和手段，使面對面的溝通控制在一定范圍之內，盡量減少因無效溝通而給項目管理帶來的負責影響。

在溝通中，會議是有效形式之一。很多業務員人員喜歡通過會議，以簡單的形式化的語言描述項目的進展與項目中碰到的問題，而不喜歡技術化的圖表與文檔。8.項目的風險管理知識

當因為未能做好風險管理，導致項目的風險發生時，項目干系人將難以一下子接受風險發生的事實以及風險所帶來的損失，需要用更多的時間來調整心理狀態，才能恢復對項目的實施。

項目的風險管理不僅是在項目進行過程中，有效避免風險的發生；而且能在風險發生時，幫助我們用正確的心態去面對，而不會手足無措。很多項目的失敗，是因為風險發生時，對項目干系心理上造成的傷害，導致失去主觀判斷能力，而作出錯誤的決策。從這種意義上講，項目的風險計劃的制定主要是為提高項目干系人的風險意識，只要有了足夠的風險意識，風險識別全面與否，在有些項目中可能重要性反而不是太明顯。

風險識別可以采用頭腦風暴法、經驗法則等方法，在識別這些風險因子之后，可以對這些因子加上權重，最后可以計算出項目成功的概率，并能據此決策項目是否應該開展、繼續或停止。識別風險因子之后，緊接著就是制定風險應對措施。根據風險發生的概率，產生的風險成本與收益，決定相應的應對策略，如風險處理、風險接受、風險改善等等。

實際工作中，可能識別到存在的風險，但卻不能加以正確處理。風險就這樣被層層傳遞。如因用戶參與不夠，導致需求不正確，進一步產生工期估計的失誤，結果是計劃的偏差，最后整個項目的結果產生偏差。因此，要注意從風險的源頭抓起，防止風險的層層放大。9.項目的采購管理知識

采購就是從外界獲得產品或服務。對于IT項目而言，采購變得越來越重要。目前絕大多數的IT項目都離不開采購管理，而且很多項目的主要內容就是設備采購或咨詢采購，對于企業而言，能否做好采購管理是保證項目成功的重點內容。有效采購管理包括以下過程： 編制合理有效的采購計劃：這是項目管理的一個重要過程，即確定項目的哪些需求可以通過采購得到更好的滿足。在采購計劃中，首先是決定是否需要采購、如何采購、采購什么、采購多少、何時采購等內容；

編制詢價計劃：即編制報價邀請書RFQ或招標書； 詢價：進行實際詢價； 開標：評估并選擇供應商； 管理：對采購合同進行管理； 收尾：對采購合同進行收尾。

在整個過程中，容易忽視的兩個過程，一是采購計劃，二是合同收尾。采購計劃的編制，是采購管理整體按需求進行的前提，如果這一步做不好，其他都是白費勁；而在采購的合同收尾過程中，最容易忘記或做不到的就是采購審計。至于供應商的選擇等過程，在IT項目中，往往會過分重視技術，而忽略管理與成本。其實，管理與成本決定合同能否按期保持履行的前提。在我公司的實際情況中，一般項目以設備為主要成本時，往往就不再考慮其他內容，而僅是作為一般的設備采購，交會器材部門實施。因為不光沒能做到項目管理，亦未做到采購管理，所以這類項目雖然也實施完成了，但項目的實施質量總令人不太滿意。[結束語]

PMP認證要求申請者必須具備的專業經歷至少具有3年以上4500小時的項目管理經歷。之所以有這樣的要求，是因為項目管理不只是光靠讀兩本書，掌握幾個工具的使用就能勝任的，很多知識與經驗，需要在實際的項目管理實踐中體會與積累。

文章只是簡單介紹了項目管理的幾個概念，如果需要深入學習，還需閱讀更多的資料，并在實際的項目管理中加以運用。這里，首先推薦學習美國項目管理協會編寫的《項目管理知識體系指南》（A Guide to the Project Management Body of Knowlwdge），簡稱PMPOK，這本書介紹了通用的項目管理的知識，不過因為是指南，類似于質量標準一樣的東西，閱讀起來有點枯燥無味，但為了明天更好的職業，這樣的付出還是值得的。期待明天會有一個新項目經理出世。

IT項目管理的五大錯誤

范圍管理：項目成功一環

定義并計劃一個項目只是成功管理一個項目的第一步。在你制訂工作計劃后，你就要按照這個計劃工作。你必須保證工作要在規定的時間和預算范圍內完成。一旦項目開始進行，客戶就會不斷要求你完成超出原來范圍的工作，或者和原來范圍不同的工作。這就是你必須要使用范圍變化管理的時候。如果你不善用此一技巧，你就會因為要完成比原先同意的工作，還要多上好幾倍預算和工作量因而疲于奔命。換句話說，你將會遭到很大的麻煩。

導致項目失敗的主要原因

一般IT經理都經歷過不太成功的項目。以下將討論五個最為常見的項目管理錯誤。切記：“糟糕的計劃是項目管理第一大失誤”。

范圍管理從范圍定義開始

定義項目范圍是定義一個項目過程中最重要的部分。如果你不確定你在進行的是什么，以及你所進行的項目底線，你就根本不可能成功。管理項目范圍是項目管理里最重要的一部分。但是，如果你沒有好好定義項目范圍，管理項目范圍幾乎就是不可能的任務。

定義項目范圍的目的，是把項目的邏輯范圍清楚地描述出來并獲得認可。范圍陳述被用來定義哪些工作是包括在該項目內，而哪些工作又是在該項目范圍之外。你能夠把項目范圍定義得越清楚，你的項目目標就會越明確。下面的信息整理會有所幫助。

? ? 范圍內和范圍外的交付使用類型（商業需求、目前狀況評估）

? ? 范圍內和范圍外的生命周期流程（分析、設計、測試）? ? 范圍內和范圍外的數據類型（財務、銷售、雇員情況等）

? ? 范圍內和范圍外的數據來源或數據庫（賬單、總帳、薪水明細等。）? ? 范圍內和范圍外的組織（人力資源、制造商、供貨商等）

? ? 范圍內和范圍外的主要功能（決策支持、數據輸入、管理報告）

可行的范圍變化流程

項目經理和項目小組必須意識到范圍變化本身并沒有什么不對，也就是說在項目進行過程中修改范圍并不是個壞主意。事實上，在很多時候里，這也是一件好事。首先，客戶通常都不能確定其 所希望的解決方案具有何種需求和功能。其次，就算客戶十分清楚終極目標，商業動態亦隨著時間不斷變化，因此項目的需求也會發生變化。

如果你不能夠容納變化，最終的解決方案就達不到預定的成效，甚至有可能完全無用。因此，你必須在需要時擁有改變項目流程的能力。如果項目經理對于項目變化沒有準備，問題將陸續發生。每一個項目都應該有一個流程以進行有效管理變化。這個流程應該包括確定變化、評估變化的商業價值、評估對于項目的影響，然后把這些信息提報給項目發起人進行評估。

發起人可以決定是否同意該變化。如果同意，發起人還應該考慮變化對項目的影響程度，然后追加預算或延長項目時間。

IT項目管理：問題、體系、方法

摘要：無論是在國內還是國外，項目管理的學科、技術和應用的普及與發展已經進入了一個飛速發展的時代，信息技術（Information Technology，簡稱IT）的發展又將IT項目管理推向了全新的應用高度。本文分析了IT項目管理技術及其應用與發展的關鍵問題，提出了基于系統集成理念構建的IT項目管理的體系結構和技術框架，肯定了IT項目管理的總體指導思想和實施策略是“需求牽引、效益驅動、總體規劃、分步實施”。

關鍵詞：信息技術

項目管理

體系結構 引言

人類進入21世紀，信息化成為我國全面構建和諧社會、快速發展國民經濟的著眼點。黨的十五屆五中全會就明確指出：“大力推進國民經濟和社會信息化，是覆蓋現代化建設全局的戰略舉措。以信息化帶動工業化，發揮后發優勢，實現社會生產力的跨越式發展?！秉h的十六大再次明確：“信息化是我國加快實現工業化和現代化的必然選擇。堅持以信息化帶動工業化，以工業化促進信息化，走出一條科技含量高、經濟效益好、資源消耗低、環境污染少、人力資源優勢得到充分發揮的新型工業化路子?！蹦壳叭珖舷赂餍懈鳂I、各個領域、各個層面的信息化建設正在如火如荼地進行著。

信息化項目的開展是以信息技術為支撐，以業務活動為主體，以現代化管理為指導思想的一項全新的、復雜的系統化工程。全新在于信息技術這一新生事物的飛速變化與發展，復雜在于信息技術、業務工作、項目管理思想的一體化融合與集成化應用，這正是IT項目管理問世的緣由。信息化建設的成功經驗告訴我們，結合信息化應用特點，采用項目管理技術而開發的專用方法對IT項目在計劃落實、質量跟蹤、成本管理和風險控制等方面進行管理，是保證IT項目達到預期目標的有效手段。

本文在項目管理知識體系的基礎上，介紹了IT項目管理的特殊性，回顧了學術界和工業界在不同方向上為解決這些問題所做的努力、獲得的成果。在系統集成理念的指導下，探討IT項目管理的體系結構和模型驅動的集成技術與方法。IT項目管理的特殊性

信息技術發展快、滲透廣等特點，使得IT項目與一般工程項目存在著明顯的差別，這種差異性造成了基于工程項目管理理論與經驗基礎上發展起來的項目管理知識體系在處理IT項目時面臨諸多的難題。

第一，IT項目的需求來源廣泛，涉及國民經濟的各個領域，幾乎所有領域都能夠和信息技術相結合而構成信息化項目。信息技術可以支持多種業務需求的發展：

（1）市場要求，如商業銀行提供網上支付業務，以支持越來越頻繁的電子商務活動。

（2）環境需求，如企業為了應對各國越來越嚴格的環境標準中對產品回收再利用的要求，啟動一個構建產品全生命周期管理系統的項目。

（3）經營需要，如一個傳統的大型商業企業開展網上銷售業務，以擴大其銷售收入。（4）技術發展，如飛機制造企業為了提高設計水平而開展虛擬制造系統的項目。

（5）用戶要求，如快遞公司要構建一個物流管理系統，以滿足顧客對跟蹤其委托的快遞物件過程狀態的查詢需求。

（6）法律需求，如一個城市為了減少合同犯罪的數量，而啟動企業印鑒信息系統；為了杜絕假文憑的泛濫而建立文憑查詢信息系統。

正是由于信息化項目涉及到了幾乎所有的經濟領域，因此很難形成有針對性的規范和標準，這 無疑增加了項目管理的難度。

第二，與一般工程項目所涉及的領域經過了長時期的發展、技術相對成熟不同，IT領域是目前發展最快、最活躍的領域，新的技術層出不窮，技術更新也非常迅速，因此IT項目開展過程中會具有更多的風險因素。有統計表明，每18個月，CPU的速度就會翻一番，與之關聯的計算機體系結構、軟件架構等也發展非常迅速。例如早期的集成信息系統采用大型主機帶終端的結構，隨著網絡技術和分布式計算技術的發展，出現了Client/Server結構的信息系統，而目前流行的架構則是在互聯網上基于Browser/Server結構的信息系統，C、C++、Java等各種開發工具更是一代代迅速更迭，各類操作系統、協議、標準等都是IT項目必須面對的，這些都會增加項目過程中的風險。

為了處理好技術發展迅速所帶來的問題，IT項目團隊必須在先進性、實用性、經濟性、成熟性等諸多方面進行權衡，片面追求技術的先進性往往會事與愿違。在保證項目所采取的技術具有相當的前瞻性、先進性和可擴展性、可集成性的同時，從需求出發，注意技術的可靠性、成熟性和經濟性。

第三，信息技術的應用主體在管理領域，管理信息系統包含了特定的管理理念，將這些管理理念同企業的發展戰略與業務邏輯進行整合是信息系統實施的關鍵任務。IT項目的阻力75%以上是來自人和管理的因素，因此，IT項目特別強調技術、管理與人的集成。如何處理好信息系統所涉及的人的問題是成功管理IT項目的關鍵。

從更深層的角度而言，經典項目管理理論是構建在土建工程項目的研究和實踐基礎上的，基本的項目管理方法并不能解決IT項目的特殊問題，例如：

（1）如何衡量項目進度的問題，土建工程使用完成土石方的量來標識工程進度，但是完成軟件90%的代碼編寫工作并不意味著還有10%的時間就可以完成軟件開發項目了。業界普遍認為在工程項目中廣泛使用的掙值法在IT項目中缺乏適應性。

（2）在計劃的調整方法上，土建工程在計劃拖期時，可以通過增加資源的方式來加快進度，但是對于一個軟件開發項目，如果出現同樣的問題，寄希望于增加編程人員的數量來追趕工期，只能造成更大的麻煩。

另外，除了信息技術之外，IT項目還涉及信息系統應用單位的組織、管理的調整與經營過程/業務流程的重構，單靠信息技術是無能為力的。因此，要成功管理IT項目，要成為IT項目的合格從業人員，需要一套全面的IT項目的知識體系與方法的支撐，它的內容將覆蓋項目管理、信息技術、現代管理技術、系統集成技術、軟件工程技術等多學科領域，這正是IT項目管理技術研究和實踐的目標與方向。IT項目管理技術的發展脈絡

目前在信息化領域的不同方向，許多學者開發了針對不同方面的項目管理方法，其中比較有代表性的是軟件項目管理和廣義的IT項目管理。

軟件項目管理是軟件工程和項目管理的有效結合，將項目管理中重視過程、重視計劃控制的觀點引入軟件工程領域，目的是控制軟件開發項目的成本、進度、質量、風險等問題。近幾年IT領域進一步引進全面質量管理理念，認為軟件開發企業自身質量控制體系和控制能力的優劣，將會極大地影響軟件產品的質量，這就要求軟件企業從修煉內功入手，也就是確認質量是控制出來的而不是檢測出來的，從根本上保證軟件產品的質量，由此提出了軟件過程改進和軟件能力成熟度模型(CMM)的概念。CMM基于經典的產品質量原理，建立了定量控制軟件過程的項目管理和項目工程的基本原則，與此同時，CMM有關能力成熟度的操作方法也被引入經典項目管理領域，用以測評承擔項目的組織的項目管理能力。

廣義IT項目管理是目前業界討論比較多的，也出了不少這方面的專著，其基本思路是將IT項目當做一般工程項目，使用PMBOK的方法體系，結合一些信息技術項目的案例，研究如何在信息技術項目中應用項目管理方法。

廣義IT項目管理是將所有與IT有關的項目不加區分地通盤考慮，包括IT產品開發項目的管理和IT應用項目的管理。實際上廣義IT項目可以細分出多個類別，各個類別之間的差距是非常巨大的。計算機硬件開發項目與一般家用電器產品的開發設計具有非常高的相似度，而軟件設計開發則完全不同，信息技術應用項目與上述兩個分支領域更是存在巨大的差異，因此廣義的IT項目管理實際上是在經典項目管理知識體系的基礎上，嘗試解決IT項目的具體問題。目前來看這種處理方式比軟件項目管理體系的針對性差很多，對其進行細分研究具有非常重要的意義。為了提高IT項目管理的針對性，提高解決方案的系統性，學術界和企業界在企業信息化、數字化城市與電子政務、數字 化軍工、供應鏈與物流、電子商務等不同領域分別開展了體系結構、實施指南、參考模型等的研究和實踐，取得了一定的成果。IT項目管理的體系結構與方法論

系統參考體系結構是“一組用以描述所研究系統的不同方面和不同開發階段的、結構化的、多層次多視圖的模型和方法的集合，體現了對系統的整體描述和認識，為對系統的理解、設計、開發和構建提供工具和方法論的指導”。

系統參考體系結構為IT項目的管理提供了體系參考和方法論，經過各國專家的努力，已經形成了一批相當有代表性和廣泛影響力的體系結構及其建模方法，并進行了大量的工業實踐，如CIM開放系統體系結構(CIM-OSA)、GRAI集成方法論(GIM)、IMPACS、普度參考體系結構(PERA)、集成的信息系統體系結構(ARIS)、通用企業參考體系結構與方法論(GERAM)，以及在我國提出的階梯形CIM系統參考體系結構(SLA)等。

在信息化項目管理過程中，系統的認識和構建是階梯上升的，在概念定義階段需要明確企業的戰略目標，并據此形成集成系統的目標，然后圍繞系統目標，從組織、資源、信息、產品、功能和經營過程等角度描述企業的現狀，形成對企業基本框架和運行機制的完整描述。在這些描述的約束下，采用合適的模型分析手段進行分析，找出現有系統中的問題進行改進，然后構建目標系統，形成多視圖的目標系統的描述。在形成目標系統描述時，除了使用各個視圖的描述方法外，還可以應用其他建模方法，以便提供對系統更為完整的描述。完成基于模型的設計后，就是在構建工具集的幫助下，將設計轉化為實際系統構建的技術說明，并構建實際系統。系統描述對于系統的運行仍然能夠發揮作用，可以作為實際系統運行的參考，并據此進行系統的優化與調整。

一方面由于信息化項目的多專業性，為了解決溝通和分析設計的問題，需要借助建模的手段實現對被處理對象系統的描述；另一方面由于信息化處理對象的復雜性，依據“化繁為簡、分而治之”的原則，使用多層次多視圖的模型來描述目標系統。視圖的劃分包括反映結構信息的信息視圖、資源視圖、組織視圖、產品視圖，反映系統時間和邏輯特征的過程視圖，結合反映系統功能結構和功能關系的功能視圖，以及反映企業經濟性和目的性的經濟視圖。靜態結構反映了系統的存在，行為結構給出了系統的屬性和運行方式，而評價結構則將系統和它的目的性關聯在一起。透過多視圖，為IDEF、ARIS等其他建模方法和工具的集成，對于制造企業原模型和企業本體的開發提供了技術框架。利用模型技術解決IT項目的交流、設計、技術轉移、系統構建乃至運行維護的問題是目前學術界和業界的普遍看法，模型驅動的體系結構是目前的一個研究和實踐的熱點。結論

隨著信息技術的發展和應用范圍的不斷擴大，IT項目管理越來越具有普遍性。分析IT項目的內在特征和特有問題，在項目管理知識體系的架構下，有針對性地開發適應性的理念和方法，將是IT項目管理領域的發展方向。

需要強調的是，信息技術本身的發展并不是IT項目的目的，滿足應用對象的需求和戰略目標才是其出發點，因此需要切實做好項目的需求分析，一切從業務工作的實際需求出發，在集成理念的指導下，充分考慮整個系統的集成要求，并在此基礎上選擇相關的成熟技術、應用系統和產品，同時做好項目的技術經濟分析，才能保證信息化項目發揮實效。國家863計劃CIMS主題專家組在大量信息化工程實踐的基礎上提出的“需求牽引、效益驅動、總體規劃、分步實施”的策略是IT信息化項目管理的總體指導思想。

成功的軟件項目需要幾點要求

現在,隨著國內的軟件企業的逐漸的增多,而且,外資企業也不斷的深入到我國的軟件領域,來分享我們的一些或大或小的軟件項目.我們始終有一中壓力的感覺.說句不好聽的話,我們現在的軟件整體水平和歐美的差距越來越大,和日本的差距也很大,為什么這么大,難道我們真的沒有能力把項目做好.或者我們根本做不好這個領域的項目.不是,我們做不好,而是,我們缺少的東西太多了.我就根據自己在日企做過的一些項目,來談談自己的一些個人所得吧.第一:自責

在項目無論是開始還是進行中,還是即將結束的時候,對項目出現的問題,大家一定不要互相推托責任,而是明確項目不是一個人的項目,是大家共同的項目.是一個集體性的活動.無論項目是成功還是 失敗,大家都有不可推卸的責任.同時也希望項目負責人或者公司的領導多說幾句這樣的話,讓大家都有壓力的存在.不要把所有的責任都推托到項目負責人身上,難道你身上沒有責任嗎?都有責任的.多一些自責,建立自己的威信.有利于以后的項目的開展.有利于大家的合作.第二:責任

責任,是一個比較復雜的東西.成功了,大家都希望,有自己的功勞.而失敗了,大家都想把責任推托到別人的身上,和自己沒有任何關系.其實事實也并不是這樣.我想這個問題大家都比較明白.咱們舉一個比較簡單的例子:小偷偷東西.如果大家看到有人在背后偷別人的東西,都去制止一下,小偷不會這么猖狂.如果大家都把自己的東西放在比較隱蔽的地方,小偷也不會偷東西.如果國家對小偷的打擊力度在大一點.小偷也不會那么大膽了.好多如果,好多假設.但是,大家都有責任.小偷不偷你的東西,而你開心.小偷偷了你的東西.你傷心.如果，在如果.小偷也不會偷你的東西了.對不對.和我們的項目一樣,如果大家都有責任心,都想如何把項目做好.遇到一些同事的不積極,而去主動溝通和交流.遇到同事的問題,一起解決.那么,項目還會失敗嗎? 第三:任務

現在,大家把任務,都作為自己的任務.而別人的任務,和自己沒有任何關系.是不是真的沒有關系呢?咱們在舉一個例子:在軟件開發的過程中,一個程序員沒有按照需求去寫,而你發現,而沒有制止.那么在寫完后.你的程序和他的程序進行,調試.你如何都不能調試過去,這個時候,你會不會想到是它的原因,而不是自己的原因,是不是為這個原因而花費掉好多金錢和時間呢?如果你在做好自己的同時,也會去幫助一些他,那么整體的效率是不是就提高了.希望大家在以后的項目開發過程中,不要把自己的任務,作為任務,實際上其他人的任務,并不是項目負責人一個人的任務,而是大家的共同的任務.第四:務實

如果把這兩各自分開來理解:任務和實際.意思就是說我們不僅要做好自己的任務,而且要切合實際.保證質量.保證進度.這可能需要大家的一個共同的心態吧.如果大家都把自己的工作保持完美,那么整體的工作一定會很完美的.什么都不能和務實相比較.在項目啟動的時候,大家要多進行交流和溝通,因為我們的目的只有一個.把項目做好.只有項目做好了.我們才可以做大項目.只有做大項目了,我們自己的能力才可以得到發揮.那么屬于我們的東西就自然而然多了.真誠希望大家能在一起互相討論一下,如何把項目做得更好,更美.其實,我們個人和日本以及歐美是沒有差距的.而是我們對問題的看法不一致.相信,我們整理的力量也會比他們厲害的.加油吧.讓我們一起努力吧.對軟件項目管理的探討

一、引言

隨著信息技術的飛速發展，軟件產品的規模也越來越龐大，個人單打獨斗的作坊式開發方式已經越來越不適應發展的需要。各軟件企業都在積極將軟件項目管理引入開發活動中，對開發實行有效的管理。我公司是西安一家中型軟件企業，在公司中已經實行了項目管理制度，軟件項目管理是整個項目管理中的一個重要組成部分。

從概念上講，軟件項目管理是為了使軟件項目能夠按照預定的成本、進度、質量順利完成，而對成本、人員、進度、質量、風險等進行分析和管理的活動。實際上，軟件項目管理的意義不僅僅如此，進行軟件項目管理有利于將開發人員的個人開發能力轉化成企業的開發能力，企業的軟件開發能力越高，表明這個企業的軟件生產越趨向于成熟，企業越能夠穩定發展（即減小開發風險）。

軟件開發不同于其他產品的制造，軟件的整個過程都是設計過程（沒有制造過程）；另外，軟件開發不需要使用大量的物質資源，而主要是人力資源；并且，軟件開發的產品只是程序代碼和技術文件，并沒有其他的物質結果。基于上述特點，軟件項目管理與其他項目管理相比，有很大的獨特性。

二、軟件項目管理的組織模式

軟件項目可以是一個單獨的開發項目，也可以與產品項目組成一個完整的軟件產品項目。如果是訂單開發，則成立軟件項目組即可；如果是產品開發，需成立軟件項目組和產品項目（負責市場 調研和銷售），組成軟件產品項目組。

公司實行項目管理時，首先要成立項目管理委員會，項目管理委員會下設項目管理小組、項目評審小組和軟件產品項目組。

1、項目管理委員會

項目管理委員會是公司項目管理的最高決策機構，一般由公司總經理、副總經理組成。主要職責如下：

（1）依照項目管理相關制度，管理項目；

（2）監督項目管理相關制度的執行；

（3）對項目立項、項目撤消進行決策；

（4）任命項目管理小組組長、項目評審委員會主任、項目組組長.2、項目管理小組

項目管理小組對項目管理委員會負責，一般由公司管理人員組成。主要職責如下：

（1）草擬項目管理的各項制度；

（2）組織項目階段評審；

（3）保存項目過程中的相關文件和數據；

（4）為優化項目管理提出建議。

3、項目評審小組

項目評審小組對項目管理委員會負責，可下設開發評審小組和產品評審小組，一般由公司技術專家和市場專家組成。主要職責如下：

（1）對項目可行性報告進行評審；

（2）對市場計劃和階段報告進行評審；

（3）對開發計劃和階段報告進行評審；

（4）項目結束時，對項目總結報告進行評審。

4、軟件產品項目組

軟件產品項目組對項目管理委員會負責，可下設軟件項目組和產品項目組。軟件項目組和產品項目組分別設開發經理和產品經理。成員一般由公司技術人員和市場人員構成。主要職責是：根據項目管理委員會的安排具體負責項目的軟件開發和市場調研及銷售工作。

三、軟件項目管理的內容

從軟件工程的角度講，軟件開發主要分為六個階段：需求分析階段、概要設計階段、詳細設計階段、編碼階段、測試階段、安裝及維護階段。不論是作坊式開發，還是團隊協作開發，這六個階段都是不可缺少的。

根據公司實際情況，公司在進行軟件項目管理時，重點將軟件配置管理、軟件質量管理、軟件風險管理及開發人員管理四方面內容導入軟件開發的整個階段。

在八十年代初，著名軟件工程專家B.W.Boehm總結出了軟件開發時需遵循的七條基本原則，同樣，我們在進行軟件項目管理時，也應該遵循這七條原則。它們是：

（1）用分階段的生命周期計劃嚴格管理；

（2）堅持進行階段評審；

（3）實行嚴格的產品控制；

（4）采用現代程序設計技術；

（5）結果應能夠清楚地審查；

（6）開發小組地人員應該少而精；

（7）承認不斷改進軟件工程實踐地必要性。

四、編寫《軟件項目計劃書》

項目組成立的第一件事是編寫《軟件項目計劃書》，在計劃書中描述開發日程安排、資源需求、項目管理等各項情況的大體內容。計劃書主要向公司各相關人員發放，使他們大體了解該軟件項目的情況。對于計劃書的每個內容，都應有相應具體實施手冊，這些手冊是供項目組相關成員使用的。

《軟件項目計劃書》一般應該包括下述內容：

1.引言

1.1計劃的目的

1.2項目的范圍和目標

1.2.1范圍描述

1.2.2主要功能

1.2.3性能

1.2.4管理和技術約束

2.項目估算

2.1使用的歷史數據

2.2使用的評估技術

2.3工作量、成本、時間估算

3.風險管理戰略

3.1風險識別

3.2有關風險的討論

3.3風險管理計劃

3.3.1風險計劃

3.3.2風險監視

3.3.3風險管理

4.日程

4.1項目工作分解結構

4.2時限圖(甘特圖)4.3資源表

5.項目資源

5.1人員

5.2硬件和軟件

5.3特別資源

6.人員組織

6.1組織結構

6.2管理報告

7.跟蹤和控制機制

7.1質量保證和控制

7.2變化管理和控制

8.附錄

五、軟件配置管理

是否進行配置管理與軟件的規模有關，軟件的規模越大，配置管理就顯得越重要。軟件配置管理簡稱SCM（Software Configuration Management的縮寫），是在團隊開發中，標識、控制和管理軟件變更的一種管理。配置管理的使用取決于項目規模和復雜性以及風險水平。

1、目前軟件開發中面臨的問題

。在有限的時間、資金內，要滿足不斷增長的軟件產品質量要求；

。開發的環境日益復雜，代碼共享日益困難，需跨越的平臺增多；

。程序的規模越來越大；

。軟件的重用性需要提高；

。軟件的維護越來越困難。

2、軟件配置管理應提供的功能

在ISO9000.3中，對配置管理系統的功能作了如下描述：

。唯一地標識每個軟件項的版本；

。標識共同構成一完整產品的特定版本的每一軟件項的版本；

?？刂朴蓛蓚€或多個獨立工作的人員同時對一給定軟件項的更新；

。控制由兩個或多個獨立工作的人員同時對一給定軟件項的更新；

。按要求在一個或多個位置對復雜產品的更新進行協調；

。標識并跟蹤所有的措施和更改；這些措施和更改是在從開始直到放行期間，由于更改請求或問題引起的。

3、版本管理

軟件配置管理分為版本管理、問題跟蹤和建立管理三個部分，其中版本管理是基礎。版本管理應完成以下主要任務：

。建立項目；

。重構任何修訂版的某一項或某一文件；

。利用加鎖技術防止覆蓋；

。當增加一個修訂版時要求輸入變更描述；

。提供比較任意兩個修訂版的使用工具；

。采用增量存儲方式；

。提供對修訂版歷史和鎖定狀態的報告功能；

。提供歸并功能；

。允許在任何時候重構任何版本；

。權限的設置；

。晉升模型的建立；

。提供各種報告。

4、配置管理軟件PVCS 6.0

PVCS6.0是一套非常優秀的配置管理軟件，它能夠實現配置管理中的各項要求，并且能和多種流行開發平臺集成，為配置管理提供了很大的方便。

六、軟件質量管理

隨著軟件開發的規模越來越大，軟件的質量問題顯得越來越突出。軟件質量的控制不單單是一個軟件測試問題，在軟件開發的所有階段都應該引入質量管理。我公司除加強了國家標準“信息技術軟件生存期過程”（GB/T8566--1995）的規范管理外，還積極為通過ISO 9000.3做準備。

1、軟件質量保證計劃

在進行軟件開發前，需要有一個《軟件質量保證計劃》。目前較常用的是ANSI/IEEE STOL 730--1984，983--1986標準，包括以下內容：

1.計劃目的2.參考文獻

3.管理

3.1.組織

3.2.任務

3.3.責任

4.文檔

4.1.目的

4.2.要求的軟件工程文檔

4.3.其他文檔

5.標準和約定

5.1.目的5.2.約定

6.評審和審計

6.1.目的6.2.評審要求

6.2.1.軟件需求的評審

6.2.2.設計評審

6.2.3.軟件驗證和確認評審

6.2.4.功能評審

6.2.5.物理評審

6.2.6.內部過程評審

6.2.7.管理評審

7.測試

8.問題報告和改正活動

9.工具、技術和方法

10.媒體控制

11.供應者控制

12.記錄、收集、維護和保密

13.培訓

14.風險管理

2、質量管理的基本原則

?？刂扑羞^程的質量；

。過程控制的出發點是預防不合格；

。質量管理的中心任務是建立并實施文件化的質量體系；

。持續的質量改進；

。有效的質量體系應滿足顧客和組織內部雙方的需要和利益；

。定期評價質量體系；

。搞好質量管理關鍵在于領導。

3、軟件質量因素

正確性：系統滿足規格說明和用戶目標的程度，即，在預定環境下能正確地完成預期功能的程度。

健壯性：在硬件發生故障、輸入的數據無效或操作錯誤等意外環

境下，系統能做出適當響應的程度。

效率：為了完成預定的功能，系統需要的計算資源的多少。

完整性（安全性）：對未經授權的人使用軟件或數據的企圖，系統能過控制（禁止）的程度。

可用性：系統在完成預定應該完成的功能時另人滿意的程度。

風險：按預定的成本和進度把系統開發出來，并且為用戶所滿意的概率。

可理解性：理解和使用該系統的容易程度。

可維修性：診斷和改正在運行現場發現的錯誤所需要的工作量的大小。

靈活性（適應性）：修改或改進正在運行的系統需要的工作量的多少。

可測試性：軟件容易測試的程度。

可移植性：把程序從一種硬件配置和（或）軟件系統環境轉移到另一種配置和環境時，需要的工作量多少。有一種定量度量的方法是：用原來程序設計和調試的成本除移植時需用的費用。

可再用性：再其他應用中該程序可以被再次使用的程度（或范圍）。

互運行性：把該系統和另一個系統結合起來需要的工作量的多少。

4、軟件評審

軟件評審并不是在軟件開發完畢后進行評審，而是在軟件開發的各個階段都要進行評審。因為在軟件開發的各個階段都可能產生錯誤，如果這些錯誤不及時發現并糾正，會不斷地擴大，最后可能導致開發的失敗。下面這組數據可以清楚的看出前期的錯誤對后期的影響。

軟件評審是相當重要的工作，也是目前國內開發最不重視的工作。

（1）評審目標

。發現任何形式表現的軟件功能、邏輯或實現方面的錯誤；

。通過評審驗證軟件的需求；

。保證軟件按預先定義的標準表示；

。已獲得的軟件是以統一的方式開發的；

。使項目更容易管理。

（2）評審過程

A、召開評審會議：一般應有3至5人參加，會前每個參加者做好準備，評審會每次一般不超過2小時。

B、會議結束使必須做出以下決策之一：接受該產品，不需做修改；由于錯誤嚴重，拒絕接受；暫時接受該產品。

C、評審報告與記錄；所提出的問題都要進行記錄，在評審會結束前產生一個評審問題表，另外必須完成評審簡要報告。

（3）評審準則

。評審產品，而不是評審設計者（不能使設計者有任何壓力）；

。會場要有良好的氣氛；

。建立議事日程并維持它（會議不能脫離主題）；

。限制爭論與反駁（評審會不是為了解決問題，而是為了發現問題；

。指明問題范圍，而不是解決提到的問題；

。展示記錄（最好有黑板，將問題隨時寫在黑板上）；

。限制會議人數和堅持會前準備工作；

。對每個被評審的產品要盡力評審清單（幫助評審人員思考）；

。對每個正式技術評審分配資源和時間進度表；

。對全部評審人員進行必要的培訓；

。及早地對自己地評審做評審（對評審準則的評審）。

5、ISO9000.3軟件質量認證體系

ISO9000.3是ISO9000質量體系認證中關于計算機軟件質量管理和質量保證標準部分。它從管理職責、質量體系、合同評審、設計控制、文件和資料控制、采購、顧客提供產品的控制、產品標識和可追溯性、過程控制、檢驗和試驗、檢驗/測量和試驗設備的控制、檢驗和試驗狀態、不合格品的控制、糾正和預防措施、搬運/貯存/包裝/防護和交付、質量記錄的控制、內部質量審核、培訓、服務、統計系統等二個方面對軟件質量進行了要求。

6、測試

軟件測試是軟件開發的一個重要環節，同時也是軟件質量保證的一個重要環節。所謂測試就是用已知的輸入在已知環境中動態地執行系統（或系統的部件）。測試一般包括單元測試、模塊測試、集成測試和系統測試。如果測試結果與預期結果不一致，則很可能是發現了系統中的錯誤，測試過程中將產生下述基本文檔：

（1）測試計劃：確定測試范圍、方法、和需要的資源等。

（2）測試過程：詳細描述和每個測試方案有關的測試步驟和數據（包括測試數據及預期的結果）。

（3）測試結果：把每次測試運行的結果歸入文檔，如果運行出錯，則應產生問題報告，并且必須經過調試解決所發現的問題。測試結果：把每次測試運行的結果歸入文檔，如果運行出錯，則應產生問題報告，并且必須經過調試解決所發現的問題。

七、軟件風險管理

軟件項目管理存在著風險，如果我們提前重視風險，并且有所防范，就可以最大限度減少風險的發生。進行風險管理是有效的手段。

1、風險的分類

根據風險內容，我們可以將風險分為項目風險（成本提高，時間延長等）、技術風險（技術不成熟等）、商業風險（銷售問題等）、戰略風險（公司的經營戰略發生了變化）、管理風險（公司管理人員是否成熟等）、預算風險（預算是否準確等）等。

另外，我們還可以將風險分為已知風險（如員工離職等）、可預報風險（從以往經驗得出可能有風險的）和不可預知風險。

2、風險的識別

風險識別的有效方法是建立風險項目檢查表。主要涉及以下幾方面檢查：

。產品規模風險檢查

。業務影響風險檢查

。與客戶相關的風險檢查

。過程風險檢查

。技術風險檢查

。開發環境風險檢查

。與人員的模式和經驗有關的風險檢查

3、風險評估

風險評估主要從下面七個方面進行：

。發生的可能性

。發生的結果（影響）

。建立一個尺度表示風險可能性（如，極罕見、罕見、普通、可能、極可能）

。描述風險帶來的后果

。估計對產品和項目的影響

。確定風險評估的正確性

。根據影響排定有限隊列

另外，要對每個風險的表現、范圍、時間做出盡量準確的判斷。

4、風險的評價

對風險的評價主要依據三個因素：風險描述、風險概率和風險影響。從成本、進度及性能三個方面對風險進行評價。確定項目的中止點，在中止點出再一次進行風險評價。

5、風險的駕馭和監控

風險的駕馭與監控主要要靠管理者的經驗來實施。如，某開發人員的離職概率是0.7，離職后會對項目造成一定的影響，則該風險駕馭和監控的策略如下：

。與在職人員協商，確定流動原因。

。在項目開始前，把環節這些流動原因的工作列入風險駕馭計劃。

。項目開始時，作好人是會流動的準備，采取一些措施確保人員一旦離開時，項目仍能繼續。

。制定文檔標準，并建立一種機制，保證文檔及時產生。

。對所有工作進行細微詳審，使更多人能夠按計劃進度完成自己的工作。

。對每個關鍵性技術人員培養后備人員。

在考慮風險成本之后，決定是否采用上述策略。

八、人員管理

1、對項目經理的要求

。能夠使小組每個成員都能發揮能力

。有一定的組織能力

。能夠使小組美味成員有成就感

。有提出解決問題方案的能力

。對問題的理解有一定的深度

。要能讓成員知道軟件質量的重要性

2、人員的通訊方式

（1）正式非個人方式，如正式會議等；

（2）正式個人之間交流，如成員之間的正式討論等（一般不形成決議）；

（3）非正式個人之間交流，如個人之間的自由交流等；

（4）電子通訊，如E-MAIL（電子郵件）、BBS（電子公告板系統）等；

（5）成員網絡，如成員與小組之外或公司之外有經驗的相關人員進行交流；

在實踐中發現，（5）的通訊效率最高，其次是（1）。

人力資源管理中的風險管理

在進行人力資源管理時，我們往往重視招聘、培訓、考評、薪資等各個具體內容的操作，而忽視了其中的風險管理問題。其實，每個企業在人事管理中都可能遇到風險，如招聘失敗、新政策引起員工不滿、技術骨干突然離職等等，這些事件會影響公司的正常運轉，甚至會對公司造成致命的打擊。如何防范這些風險的發生，是我們應該研究的問題。特別是高新技術企業，由于對人的依賴更大，所以更需要重視人力資源管理中的風險管理

給項目管理一雙慧眼

在諸多招聘廣告中，經?？梢钥匆娨恍㊣T軟件企業或集成商對他們的技術部門經理或者項目經理是這樣要求的：

有XX行業X年軟件開發經驗

精通XXX編程

語言掌握XXX數據庫??

這里面隱含著什么意義？那就是對于大多數IT企業，他們眼中的技術部門經理或項目經理都是技術高手，部門員工碰到什么搞不定的技術難題，這些經理一出手，一切搞定，贏來陣陣喝彩。這應該是這些經理們的第一職責嗎？顯然，有不少人都會說“No”。他們明白，對于這些經理們來說，33 管理好項目是更重要的職責。

正因為這樣，項目管理資質認證成為繼MBA之后的一大熱點，許多媒體紛紛刊登有關項目管理資質認證的各種利好信息，大有項目管理資質認證是解決一切項目問題之靈丹妙藥。其實，專業的項目管理是保障項目成功實施的關鍵因素之一，但并不是唯一因素，就象股份制只是使企業的所有制趨于合理化，但股份制并不能保證企業的經營一定能獲得良好的經濟效益。

雖然國內眾多IT企業都開始重視項目管理，也積極的讓員工們參加各種項目管理的培訓，但是在實際的項目執行中，往往還是會出現許多不盡如人意的情況，或者可以說，在注意項目管理后，許多項目的執行效率并沒有得到實質性的提高。或許，我們需要一雙慧眼來仔細看看項目管理領域里存在的諸多關鍵點。

一、項目管理的理論、方法和工具

首先需要認清的是項目管理的理論、方法和工具的區別以及相互關系。

有不少人接受了一些關于項目管理培訓，或者閱讀了一些關于項目管理的書籍，他們基本上就知道項目管理需要制定計劃，需要進行跟蹤和監控，也了解項目管理包含哪些內容，比如說質量管理、變化管理、風險管理、合同管理等等。但是，當他們真正在一個項目中去進行項目管理，卻仍然會感到無從下手，無法通過執行項目管理的活動讓項目沿著正確的方向前進。

之所以出現這樣的情況，是因為他們所掌握的往往還只是項目管理的理論，但卻還沒有掌握項目管理的方法。而理論的可操作性往往很弱，因此出現這樣的情況也是非常正常的。用一句話說，掌握理論只是知道了“What”，但還不知道“How”。

而方法會告訴你應該如何去做，它解決了“How”的問題，比如說，項目管理分成幾個階段？每個階段又包含哪些活動？這些活動的執行順序是什么？這些活動之間的關系是什么？這些活動產生哪些計劃？諸如此類等等。這樣就具有很強的可操作性。但遺憾的是許多培訓或者書本，都還是保持在理論的層次。

在日常工作中，經常會聽到這樣一句話“計劃不如變化快”。甚至有人會拿這句話做為擋箭牌，拒絕進行積極的項目管理。實際上，沒有一個項目可以在執行中完全遵守一開始制定的計劃，尤其是在計劃制定得非常詳細的情況下。項目的執行過程中肯定會隨時發生各種變化的，因此在進行項目管理時，是一定要對項目進行監督和控制的，并設定一些節點根據項目的進展對項目計劃進行必要的調整；另外，在制定項目計劃時，還應該注意根據項目的規模和時間，從粗到細制定詳細程度不同的計劃，以保證計劃的指導作用和有效性。象這樣的情況，都是要有方法才可以解決的。出現問題，并不是“進行項目管理”的理念不對，而是沒有找到合適的方法。

在日常工作中，還常聽到有人說：“以后我們要加強項目管理，使用××軟件進行項目管理。”他們不但用軟件做出了計劃，也產生了甘特圖和關鍵路徑圖等等，但是實際的工作往往和他們所做出的計劃有很大差異，項目管理成效依然甚微。在這種情況下，他們所犯的錯誤通常是以為有了工具，就可以解決一切問題，而其實他們并沒有項目管理方法。實際上，工具是基于方法的，需要和方法相結合。使用工具是為了更好的貫徹方法，如果沒有相適應的方法，使用工具甚至會產生負面的效果。

因此，在具體項目實施中，一定要有清楚的項目管理方法，才可能用好工具；同時也必須注意到所選擇的工具和采用的項目管理方法是相匹配的，因為并不是所有的項目管理軟件都會適用于所有的項目，應該基于項目管理的特定需要選擇某個項目管理軟件，就象ERP系統實際上體現著某種企業管理的理念，每個企業在選擇ERP時都需要密切關注隱藏在它背后的企業管理方法，而不只是它需要的技術支撐平臺是什么？它的實施需要幾個人月？

二、項目管理方法和項目實施方法

其次，也必須看到，在一個項目的執行過程中還同時需要兩種方法：項目管理方法和項目實施方法。

項目管理方法是關于如何進行項目管理的方法，是可在大部分項目中應用的方法。而項目實施方法指的是在項目實施中為完成確定的目標如某個應用軟件的開發而采用的技術方法。項目實施方法所能適用的項目范圍會更窄些，通常只能適用于某一類具有共同屬性的項目。而在有的企業里，常常把項目管理方法和項目實施方法結合在一起，因為他們做的項目基本是屬于同一種類型的。

實際上，只要愿意，做任何一件事情，我們都可以找到相應的方法，項目實施也是一樣。以IT行業的各種項目為例，常見的IT項目按照其屬性可以分成系統集成、應用軟件開發和應用軟件客戶

化等，當然，也可以把系統集成和應用軟件開發再分解成一些具備不同特性的項目。系統集成和應用軟件開發的方法很顯然是不一樣的，比如說：系統集成的生命周期可能會分解為了解需求、確定系統組成、簽訂合同、購買設備、準備環境、安裝設備、調試設備、驗收等階段；而應用軟件的開發可能會因為采用的方法不同而分解成不同的階段，比如說采用傳統開發方法、原型法和增量法就有所區別，傳統的應用軟件開發的生命周期可能分解成：了解需求、分析需求、設計、編碼、測試、發布等階段。

至于項目管理，可以分成三個階段：起始階段，執行階段和結束階段。其中，起始階段是為整個項目準備資源和制定各種計劃，執行階段是監督和指導項目的實施、完善各種計劃并最終完成項目的目標，而結束階段是對項目進行總結及各種善后工作。

那么，項目管理方法和項目實施方法的關系是什么呢？簡單的說，項目管理方法是為項目實施方法得到有效執行提供保障的。如果站在生命周期的角度看，項目實施的生命周期則是在項目管理的起始階段和執行階段，至于項目實施生命周期中的階段分布是如何對應項目管理的這兩個階段，則視不同項目實施方法而不同。下圖是一個簡單說明。

項目管理方法和項目實施方法對項目的成功都是有重要意義的，兩者是相輔相成的，就如管理人員和業務技術人員對于企業經營的意義一樣。

從IT企業的角度看，任何一個IT企業如果要生產高質量的軟件產品或者提供高質量的服務，都應該對自身的項目業務流程進行必要的分析和總結，并逐步歸納出自己的項目管理方法及項目實施方法，其中項目實施方法尤其重要，因為大部分企業都有自己的核心業務范圍，其項目實施方法會比較單一，在這種情況下，項目管理方法可能會弱化，而項目實施方法會得到強化，兩者會較緊密的結合在一起。只有總結出并貫徹實施符合企業自身業務的方法，項目的成功才不會嚴重依賴于某個人。在某種程度上，項目管理方法和項目實施方法也是企業文化的一部分。

從客戶的角度看，如果希望得到有保障的產品或服務，那就既需要關注提供產品或服務的企業是否有恰當的項目管理方法和項目實施方法，也必須尊重該企業的方法。

三、項目管理和項目的目標

有了合適的方法，還要清楚項目的目標，才能有針對性的進行項目管理。項目的目標是指項目做完后能夠支持客戶如何運作業務，或者客戶可以獲得具備哪些功能的產品等。

在項目的實際執行過程中，客戶方和項目執行方往往很容易產生爭執，出現“先君子，后小人”的情況：開始時大家都是一團和氣，或項目執行方為了獲得項目合同，先是猛拍胸脯保證沒問題，只要是客戶方的要求就承諾一定實現。但隨著項目的進展，才發現雙方的期望有著不小的難以彌補的差距。

這種現象的原因就是項目雙方并沒有定義清晰的、可實現的項目目標，換句話說，雙方并沒有真正在項目目標上達成彼此認可的一致。這樣就很可能出現不了雙贏的局面，要么是最后產生的結果不是客戶需要的，要么是客戶不斷的修改需求，導致項目的進度和質量受影響。項目目標既是客戶期望的體現，也是項目執行方期望的體現，因此它們應該是清晰的和可實現的。

從另一方面講，項目目標的實現是要受到一定制約的，那就是它應該在確定時間和財務預算內實現。有一些目標并不是不能實現，而是實現的代價太高，或者不能滿足進度的要求。這也是在項目實施中需要注意的。

同時，清楚的目標也是界定項目是否成功的客觀標準，是對項目進行驗收和質量管理的重要依據。設定清楚的項目目標，在某種程度上也會讓執行項目的IT人員更清楚要做什么，因為在一些項目中，往往會出現片面追求技術的先進和完美，而忽視項目的結果是為誰服務的。因此，為了保證項目雙方能夠在項目執行過程中愉快有效合作，保證項目的成功執行，雙方都應該注意盡快在項目實施初期定義清楚的目標。

四、項目管理與體系結構

“體系結構”這個詞語來自英文單詞“Architecture”，在計算機行業中也有譯為“系統結構”，許多行業都用到這個單詞。對于一臺計算機而言，它所關注的是如何合理的利用合適的軟件、硬件和固件來構造計算機，使之能夠以最好的性能價格比完成用戶所需要的任務。之所以特別提出“體系結構”，主要有三方面的原因：一個是IT應用范圍的擴大；一個是IT系統的復雜性和產品多樣性；一個是軟件技術的發展。

隨著IT技術的發展，以及人們對IT技術的理解和掌握，IT在各行業的應用都日漸的發展和成熟，越來越多的行業和人員都在利用IT技術提高他們的業務運作效率，也就產生越來越多的應用型

項目。尤其是IT 應用發展到現在，一個IT系統所覆蓋的范圍日益擴大（范圍包括最終用戶數量、部門數量、地理分布等），比較常見的大型IT項目是一些新用戶希望在一個高起點上構建一個覆蓋多個業務部門的完整的新IT系統，或者一些用戶希望在原有分散的IT系統基礎上進行整合，從而構建成一個完整的IT系統。

對于這樣的大型項目，它們所覆蓋的業務部門很多，彼此的業務功能差異比較大但又存在相當的聯系，也就是說應用軟件的功能會比較多，且相互之間存在著一定關聯；而與之相適應的是應用軟件技術也發生了變化，多層結構、對象技術和組件技術等得到日益廣泛的應用，這就意味著必須對應用軟件的體系結構進行全面的分析設計如層次如何劃分、組件如何劃分等，才有可能產生一個較完善的應用軟件系統以滿足最終用戶的復雜需求。

同時從IT系統的基礎設施來看，其使用的產品也是多種多樣的，從服務器級的系統平臺、網絡平臺到客戶端等，有功能的差異，也有性能的差異，甚至還有采用異構技術實現的。如何讓這些產品構成一個和諧完整的系統為客戶提供方便、快捷的服務，就需要站在整個IT系統的高度上進行完整的分析設計，定義整個IT系統的組成內容，每個組成部分的功能和性能，相互之間如何進行數據交換。

如果沒有清楚的體系結構觀念，在項目實施中往往會出現這樣的情況：客戶今天說需要這樣的功能，項目人員就按照客戶的要求實現了；客戶明天再提出新的功能，項目人員也實現了。這看起來很簡單，“簡單就是美”——客戶也會感到很滿意，可是隨著項目的進展，情況就不那么美了，客戶開始發現“這兩個部分怎么不能連接”，進而提出要修改想法，甚至要求重新來過。整個項目實施就可能會出現“邊施工，邊設計”的情況，在這種情況下，項目的進度和開銷就很難有效控制，項目的資源可能被極大的浪費，而質量能否得到保證則存在很大的風險。

在體系結構清楚的基礎上，項目管理人員就可以根據一定的優先次序關系組織資源去建設IT系統的各個組成部分，從而保證項目的順利實施，而不致于出現“停工待料”甚至是“推倒重來”的局面。因此，在一個合理的項目組織機構中，必須保證項目經理和體系結構設計師的有效配合。

五、ISO9000、CMM與項目管理

從90年代中后期開始，眾多的IT企業象其它傳統企業一樣，開始關注國際標準組織頒布的ISO9000標準系列，并有不少企業通過了ISO9000認證。2000年后，國內大部分從事軟件開發的IT企業開始和國際接軌，重視CMM認證，并有許多企業走上CMM認證之路。這是非常好的一個現象，說明我們的觀念和意識在提高，在一定程度上意味著未來更加光明。但是也出現有的企業為認證而認證，而對于它們的客戶來講，所得到的產品或者服務并沒有因為這些企業通過某項認證而得到更好的質量保證。

為什么會這樣呢？其中很重要的一點是大家并沒有完全認識清楚ISO9000、CMM和項目管理、項目實施的相互關系，或者是不愿意承認這種關系。ISO9000針對質量保證和管理，而項目管理要考核的指標包括了時間（或進度）、成本、資源和質量，它不僅有質量管理，還包含了變化管理、風險管理、合同管理等，當然這些專項管理內容和質量管理是相輔相成的，或者說這些專項管理都是在為質量服務的（有時質量的范疇會被盡可能的擴大）。項目管理必然包含質量管理，而ISO9000標準并無法完全代替項目管理。

ISO9000是面向絕大多數企業的質量標準體系，是具有通用性的質量保證和管理標準，也因此它對某些行業可能缺乏針對性。雖然它也提出和軟件開發有關的指南，但從總的來看制造業最容易按照ISO9000標準實施。對于制造業和IT企業（軟件、集成），它們都需要質量體系，但是它們的質量指標并不完全相同，甚至可以說絕大部分是不同的。當然，如果在未來的某一天軟件和系統集成的技術方法真的發展到很完善就象工廠中的流水線一樣，那么ISO9000類似的質量標準對軟件和系統集成的衡量就很有意義了。

IT企業通過ISO9000認證，這個體系一定要和項目實施方法密切結合。從ISO9000的發展歷程我們或許可以看出，質量管理方法的完善在時間上是落后于項目實施方法（對于制造業，應該是產品的研發和生產方法）的完善的，因為要進行質量管理，必須清楚要管理的質量指標項和相應的衡量標準，而這些都必須在積累一定的開發生產經驗后才能提出和完善。因此對于IT企業來講，要有很好的質量保證，必須有相對清楚合理的項目實施方法，才有可能把ISO9000標準真正貫徹到項目中，沒有項目實施方法，全面貫徹ISO9000標準是不切實際的。當然，這并不是說在沒有清楚合理的項目實施方法之前不能接觸ISO9000標準，不能應用ISO9000標準。如果在起步階段就開始接觸ISO9000標準，應該說會更有可能以全面的眼光去看待項目的實施以及項目管理和落實項目質量保

證，也更有可能逐步去完善項目管理方法和貫徹ISO9000標準。

至于CMM，則是側重于對企業的軟件過程和軟件能力的評估評價，它提供的是一個軟件過程改進的框架，這個框架與軟件開發的生命周期無關，更與項目管理的生命周期無關，因此它并不是企業可以直接采納的軟件開發方法和項目管理方法。CMM做為一個指南能夠幫助軟件企業選擇、采納和合理使用一些先進的軟件項目管理方法和軟件開發方法，并在實踐活動中不斷提高和完善，從而極大程度地提高企業按計劃的時間和成本提交有質量保證的軟件產品的能力。如果一個企業真正達到CMM第四級，那么它的軟件開發方法和軟件項目管理方法應該是相當成熟的。

因此，CMM只是為客戶選擇軟件開發商提供一個參考標準，它并不等同于軟件產品的質量，也不能代表企業對所有項目的管理能力。或許有一天，會推出項目的能力成熟度模型來評估評價企業的項目管理過程和項目能力，那樣提高項目管理能力可能就更容易了。

六、結合實情逐步落實

完整的項目管理還包括一系列專題管理，如：質量管理、變化管理、風險管理、財務（或成本）管理等。這些專題管理并不完全停留在項目范疇內，它們的實施要依賴企業內部諸多相關部門的配合，如果一開始就準備在項目實施中進行全面的項目管理（包括諸多專題管理），會存在相當大的難度，因為很多企業的內部運作還不足以支撐這樣的全面項目管理，而且大部分人員也不可能在一開始就能全部領會這么多的內容?！傲_馬，不是一天建成的。”

在推廣項目管理的過程中，經常會出現這樣的情況，有的人會委婉的提出意見：“你提出的這種項目管理觀念非常好，我也覺得應該這樣去做，可是我又感覺好像太理想化了”，或者“太理論化了”等等。也就是說，對于他們，思想上接受了，但行動上卻很難真正執行，思想和行動總是存在一定的距離。

項目管理對于很多人來說是一個新事物，觀念上接受它就需要時間，更何況是在行動上完全采納。應該承認的是，引進項目管理，無論是對于企業，還是員工，都是一種變化。但是，這種變化對個體來說是必須的，而對整個行業來說則是必然的。

要讓項目管理真正進入實際業務運作中，應該結合實情逐步落實項目管理理論中的各項內容。比較合適的步驟是：第一階段，先進行一般意義上的項目管理，做到可以清楚的定義項目的目標、范圍及工作成果等，在這個階段應該確保對項目管理方法和項目實施方法及體系結構有清楚的認識和理解，并掌握適當的項目管理工具；第二階段，全面實施質量管理；第三階段，全面實施變化管理、風險管理以及財務管理。

接下來，制定一個計劃，把“實施和推廣項目管理方法”做為一個項目去執行和管理，一步一步去做，就會獲得成功的。開始吧！

工程項目管理的新挑戰—可持續發展

摘 要:工程建設會引起一系列的環境問題,本文從可持續發展的角度,詳細分析了可持續發展項目管理的必要性,同時對項目中的各個參與方在項目中所負的責任加以闡述,并且對可持續發展的項目管理從資源管理、環境管理、技術管理和項目參與人員的管理等方面提出了相應的措施。

關鍵詞:可持續發展;工程項目管理

引言

從20世紀80年代的“魯布格經驗”到今天,項目管理對建筑業的發展起到了無法替代的作用。但是由于建筑業一方面為人類建筑美好的居住空間,同時又對環境產生一定的破壞。例如:由于建筑工業大量使用合成的化工材料,使得一些含有二氧化硫、二氧化氮、鹵化物的材料暴露在大氣中或與在自然的氧化作用下,釋放出相應的氣態化合物;在施工過程中產生的噪音污染;由于機械化施工而產生的機械廢氣;施工過程中產生的大量的固態建筑垃圾等。

因此,在人們日益重視環境問題的今天,可持續發展越來越成為人們關注的熱點,然而可持續發展關注的熱點主要集中于土地、自然資源等不可再生資源的可持續利用上,集中于經濟發展的可持續研究上,忽視了對人們行為的主要對象—項目進行可持續性研究,造成了許多項目僅僅是某些領導政績的標志,由此造成了資源的巨大浪費和環境的嚴重破壞。如何從可持續發展的角度來推廣和發展項目

管理的組織方法和實施方法,是當今項目管理領域的一個很有意義的話題?？沙掷m發展的工程項目管理的特點及含義

1.1 管理對象的泛化傳統意義中的工程項目管理的管理對象是工程項目本身,是通過可行性研究報告、項目計劃書、設計圖紙、設計規范、實物模型等定義和說明的。而可持續發展的項目管理的對象不但包括項目本身,還包括項目所處的微觀環境和中觀環境,就是說作為可持續發展的管理者在進行管理的時候,要將與工程項目所有的外部關聯元素全部納入考慮和管理范圍。

1.2 管理目標的泛化作為一般意義上的項目管理目標,是要實現項目的質量目標、經濟目標、進度目標?？沙掷m發展的項目管理的目標則遠遠超出了這三個目標,它還要實現整個微觀區域和中觀區域的環境質量目標、經濟效益的長期最大化,實現人與自然、人與社會的和諧統一。

1.3 管理組織的泛化可持續發展的項目管理需要參與方的全體緊密合作,任意一個環節的失誤都會造成整個管理的失敗。

1.4 管理方法的多樣性隨著電子技術的發展以及Ｉｎｔｅｒｎｅｔ的使用,現代的管理更加傾向于開放性、及時性、準確性,可持續發展的項目管理作為一種工程管理方式同樣如此,尤其是ＥＲＰ、ＣＲＭ等系統的應用。因此,可持續發展的項目管理實際上是將工程項目放在一個微觀或中觀的區域內,應用現代的生產技術,實現項目的成本、質量、進度和社會、經濟的系統目標,從而解決項目的環境與發展問題,實現項目和社會的可持續發展。影響可持續發展的項目管理的因素項目生命周期的各個階段猶如串聯起來的一組電路,任何一個環節出現問題就會破壞項目管理的可持續發展。

影響可持續發展項目管理的關鍵因素有許多,涉及項目的各個方面。對項目可持續性的影響因素包括:項目的經濟效益、項目的資源利用情況、項目的可改造性、項目的環境狀況、項目的科技進步情況、項目的可維護性等幾方面。當然,項目的可持續性發展還要受到管理、組織的影響,另外項目所在國的政策、政治狀況等都會對項目的可持續性產生影響,其影響不僅涉及項目的可持續性甚至關系到項目的生死存亡。可持續發展的工程項目管理中各方面的責任和義務

在任何一個項目中,項目的參加者包括:政府部門、業主、勘察與設計單位、監理單位、承包商、材料供應商、用戶等。因此每一個參與者的行為都將對整個項目的可持續發展有著極大的影響。

3.1 政府部門作為項目的審批者和監督者,社會公共利益的代表者,如果政府部門在項目的立項審批、規劃審批、設計審批等方面提高對項目的可持續發展的要求,同時積極開展“社會評價”,使得項目的發展有利于自然資源合理利用與生態環境保護,有利于我國的經濟建設,合理利用有限的自然資源,節約有限資源,保護自然與生態環境,造福人類,實現以人為本的可持續發展。同時,政府可以對采用了可持續發展的項目管理的業主給予稅收或融資方面的優惠措施,鼓勵業主采用可持續發展的項目管理方式。2004年4月中央查處了“江蘇鐵本鋼鐵公司違規建設鋼鐵項目”事件。雖然有部分人認為“鐵本項目”的下馬給國家帶來了很大的經濟損失,但是如果把這個事件放在我們整個國家的大的經濟環境下考慮,我們可以清楚的發現,“鐵本項目”的死亡正是政府在考慮了整個社會成本的前提下采取的最優的管理方式,可以說更大程度上是為了保證可持續發展。同年4月29日江蘇省委書記李源潮、省長梁保華在向全省領導干部通報查處鐵本項目違規建設情況時指出,鐵本集團違規建設一案性質嚴重,教訓深刻。江蘇省委、省政府從鐵本事件中總結的三條經驗教訓的第一條就是堅持以人為本,全面、協調、可持續的發展觀。

3.2 業主業主是項目的投資人,一般情況下在保證質量和功能的前提下,自然會考慮項目的經濟可行性,但是如果采用可持續發展的項目管理方式,則意味著業主要將該項目放置在一個更高的層次,即社會和自然的角度來進行項目的可行性研究、項目的設計、篩選項目的承包商、采用新的環保材料、建造技術和環保技術,因此也需要業主預支費用,加大了成本,但是由于采用可持續發展的項目管理方式使得整個社會的收益提高,因此,業主完全有可能從政府獲得相關的優惠政策,從而補償自己的損失。在2008年的北京奧運會的場館建設中,北京奧林匹克運動會組織委員會在項目的招標書中明確規定了投標者的環境保護責任。在項目的標書中,把執行環境影響評價制度、防治污染的工程設施與主體工程同時設計、同時施工、同時建成投入使用的制度,和投標者應承擔的經濟責任寫入了標書,要求投標人認真貫徹執行。同時制定了《奧運工程綠色施工指南》,對工程施工提出了環境要求。要求在施工過程中,嚴格執行環境管理措施,防止揚塵、廢水、施工垃圾、施工噪聲對周圍環境造成的污染。

3.3 勘察與設計單位勘察與設計單位雖然在作為業主的被委托方,必須考慮委托方的經濟利益，38 但是在某種程度上勘察與設計單位可以利用自己的專業知識,向委托方提供有利于可持續發展的項目管理方式的設計方案、新的環保材料、建造技術和環保技術。

3.4 監理單位監理單位的主要作用在于協調業主和各個項目參與者的關系,保證項目的質量、進度等公共利益。監理的成功與否,對項目的成功與否有很大的影響。監理單位在保證業主利益的同時,如果站在可持續發展的高度開展工作,實際是在行使其社會職責,因此政府應該從開發企業上繳的稅收中,拿出一部分用于對監理單位的報酬。

3.5 施工單位施工單位是完成項目的核心,項目在施工的過程中要使用的機械設備,會產生大量的廢氣、粉塵、振動、噪音,對環境產生極大的破壞,影響項目的可持續發展。如果項目中標的施工單位在業主、監理單位和政府法規的約束下,采用可持續發展的項目管理方式,采用綠色環保施工建造技術,將進一步完善現有的施工方法,提高企業自身的核心競爭力。北京城建集團有限責任公司是一個以建筑為主、多元化經營的綜合性上市公司,具有工程總承包的一級資質,是全球最大的國際承包商之一。該公司之所以能夠在如林的強手中中得奧運會的主場館項目,應該說同該公司在施工中堅持采用綠色環保施工建造技術有極大關系。

3.6 材料供應方工程項目的施工建造需要大量的材料,而這些材料的使用者由于缺乏相應的專業知識和不對稱的信息,難以對材料做出非常準確的評價,而材料的供應方卻相反,他們擁有專業的技術設備、強大的信息庫,可以為業主、設計方、施工方提供綠色環保、符合可持續發展要求的新型材料。作為整個可持續發展項目管理鏈上的一個組成,材料供應方應該從法律上保證所提供材料符合可持續發展要求,政府需在稅收上給予優惠。

3.7 項目的使用者工程項目建成以后,作為項目的使用者則更大程度體現了項目的可持續發展性。因為項目使用者在使用的過程中,要消耗大量的自然資源(水、光等),同時會產生一系列的廢棄物。因此如何在使用的過程中,少消耗資源,少產生廢棄物或廢棄物再次利用程度,則是該項目可持續發展能力的一個很重要的指標?？沙掷m發展的工程項目的實施管理

4.1 資源管理項目資源管理主要指項目運營所需原材料和項目廢棄物的處理和再利用的管理,以及項目報廢后資源的再利用情況。原材料的可再生性和對環境的影響直接關系到項目的可持續性。由于項目的廢棄物處理和利用關系到項目對環境的影響,關系到項目的存在與可持續發展能力,所以項目的可持續必須考慮項目的廢棄物利用和處理狀況,并對其作出評價,通過它進一步評價項目是否具有持續發展能力。只有這樣,才能全面保證項目的可持續發展。

4.2 環境管理對環境的管理包括自然環境、社會環境、生態環境等幾方面管理。

4.2.1對自然環境的管理對自然環境管理是指可持續發展的項目管理要能夠防止或減少項目造成的環境污染,如光污染、噪聲污染、廢氣、污水污染等,達到項目與周圍自然環境具有相容性、協調性。管理的措施包括:在項目的可行性研究階段就要確定可持續發展的主題;在項目的設計、施工階段,要采用綠色環保的施工技術和材料;在項目的使用階段,要對產生的廢棄物采用分類、無害處理。只有當項目達到污染治理的標準,并且與周圍自然環境相協調,項目才具有持續發展的可能。

4.2.2對社會環境影響的管理對社會環境的影響管理包括對周圍居民生活的影響管理、對社會文化的影響管理、對社會經濟環境的影響管理等。管理的措施包括:保證項目與社會文化相容;與人們的生活習慣相協調;與經濟發展相吻合,并具有一定的前瞻性。一個項目只有符合社會文化要求,不影響居民生活,與經濟發展協調,才有存在的可能和繼續發展的必要。以舉世聞名的三峽工程為例。有材料表明,該工程建成后,將保護長江中下游廣大平原湖區,使國土開發長治久安;能夠充分利用原有農業基礎設施,加強農田水利基本建設,大大提高長江流域糧棉生產水平,促進農業生產的發展;可利用水庫1084ｋｍ2水域面積和上百條大小支流庫汊,發展漁業、養殖業、林業及畜牧業等,為食品加工和輕工業提供原料基地;萬噸級船隊可大半年直通重慶,宜昌以上航道將大大改善,促進長江流域和西南地區的開發和對外交流,使長江成為名符其實的“黃金水道”。

4.2.3對生態環境影響的管理項目處在一定的環境中,都或多或少地對生態環境產生影響,對生態環境影響的管理需要各個參與方的共同努力,尤其是政府部門應該通過相應的法律、法規明確規定對生態環境的保護,同時對破壞者給予嚴厲的處罰,對于主動進行保護的給予獎勵。同時要培養全社會的環保意識,使環保的觀念深入人心,形成全社會愛護環境、保護環境的風氣。

4.3 技術管理技術管理主要考慮兩個方面:項目設計的先進性和技術本身的先進性。項目的設計要具有科學性、超前性,并有發展余地。設計時除了要考慮人們現在生活需要,還要考慮未來需要,使項目具有一定的前瞻性,能與以后的經濟、技術、文化發展相銜接。設計的先進性還表現在盡可能利

用已有的新技術、新材料、新工藝,并具有一定的超前性,為以后發展留出接口。技術本身的先進性主要指項目實施技術和運營技術的先進性。項目的技術先進性表現在已09資源環境與工程有先進技術成果的應用上,表現在為以后技術發展留出的接口上,項目的技術先進性使項目能經得起時間考驗,同時具有可持續發展前景。

4.4 項目參與人員的管理作為整個項目建設的核心主體,項目參與人員在實施建設過程中的每一個動作都會對項目本身產生直接的作用,直接對項目的可持續發展產生影響。項目可持續發展的資源管理、環境管理和技術管理都直接依賴于項目參與人員的實施。因此,行業主管部門很有必要在項目參與人員上崗之前對其進行相關的政策法規培訓,對其進行技術指導,提高素質,并在項目的實施過程中不定期的進行檢查,使可持續發展觀深深植根于項目參與人員的頭腦中。結束語

可持續發展戰略的核心是經濟發展與保護資源、保護生態環境的協調一致,讓人類子孫后代能夠享有充分的資源和良好的自然環境。工程項目的可持續發展管理雖然只是可持續發展的一個非常細小的分支,但是如果我們能夠“勿以善小而不為”的態度去認真的從事工程項目的管理工作,可持續發展在不遠的將來一定會成功。

管理的三化與六法

企業管理的“三化”與“六法”，是現代企業管理理論與中國企業管理的實踐相結合的經驗總結，是現代管理理論的中國本土化。

“三化”

（一）決策層級民主化

決策層級民主化是指企業在進行各層級的決策時，要充分占有信息，要使用有效的手段科學地處理信息。廣義的民主化還應包括利用外腦。具體地說董事會會議，對公司重大事務進行決策。在民營企業中，董事局主席一般是企業的主要業主，由民主決策進而正確決策，實際上是業主個人財務安全和增值以及企業發展的保障。所以，對重大事務的決策民主化表現為在董事局會議上按持有股份的多少行使投票表決權。重大的決策比如公司的兼并、合并、注銷等必須有 2/3 以上（指持有股份的總額達到公司股份總額的 2/3，而不是投票人數的 2/3）的股東同意。其他的決策要由 1/2 以上的股東同意才可形成；子（分）公司層級的決策主要是經營決策，重大事務由子公司董事會決策，日常事務由子公司經理辦公會決策；職能部門事務決策，由部門經理辦公會進行。

（二）管理層級制度化

隨著技術的進步、科學的發展，管理的方式、手段不斷改進和提高?，F代化的管理手段開始在企業使用，對員工提出了更高的要求，管理層級的制度化勢在必行，即企業職工的行為的準則，它規定著人們在共同區作中應當執行的工作內容、工作程序和工作方法。也是企業生產經營活動和一切管理工作所應遵循的法規?，F代企業的生產經營過程極其復雜，分工協作極為嚴密，沒有嚴格的規章制度，企業的生存在就沒有保障。所以管理層級必須按照規章制度辦事，逐項落實。一視同仁地堅持有章可依，有章必依，執章必嚴，違章必究，即“依葫蘆畫瓢”。只有按章辦事，才能保證政令暢通。

（三）操作層級選擇化

操作層級選擇化指把企業管理的每一項工作都細化和量化，每一個崗位都有明確的崗位職責和工作流程，形成企業的各項目作分工合理、科學、明確，從而達到企業管理科學化，人人有事干，事事有人管，沒有重疊，沒有空白。任何一個員工，即使沒有某一崗位所需要的專業知識，只要他翻開職位說明書，就可以利用手機撥打電話一樣。為此，員工要先逐字逐名學懂弄通公司的操作程序，再在工作實踐中切實的執行。每一個具體的人在每一個具體的崗位上，按最有效的程序去完成相應的工作，成為一顆螺絲釘。反對和禁止形式主義、花架子，自以為是，另搞一套。

“六法”

（一）折箭法

“折箭”講的是古代的一位老人教育他的兒子們團結起來力量大的故事。一個人折一捆箭是折不斷的，可是把箭拆散，一根一根地折就很容易折斷。在日常的企業管理中，事務性的工作很多，其中只有 20% 是重要的，而這 20% 的事務要花費 80% 的精力去處理，這也是所謂的猶太人“黃

金法則”。對所有的問題，先解決普遍問題，再解決特殊問題；先解決今天存在的問題，再解決歷史上遺留的問題，而且要一個一個地解決。每一個職能部門，每一個員工，每天解決一件，整個公司就解決了很多事情。解決問題最好的方法就是現場辦公，現場辦公是事事落實的最好形式。

（二）試點法

一項新的決策，為了降低風險應該在小范圍內試點。先試點再總結，先創新再推廣。

（三）源頭法

凡事要抓住重點、抓住源頭、提綱挈領。即做任何事情的方法是：要抓主要矛盾，把問題簡明地提出來，不要胡子眉毛一把抓。面對紛繁復雜的工作，要理順思路，突出重點，抓大放小，層層剝皮。大與小的關系是西瓜和芝麻的關系，抓大放小就是抓住西瓜。企業發展的源頭是市場，基層是其效益的來源地，也是培養和鍛煉管理干部的源頭，一切工作重心應圍繞基層市場，以有利于基層市場的深入發展和擴張。

（四）重心下移法

管理重心下移，實際上就是企業組織結構和管理體制的創新，形成管理層級少而精的扁平式組織結構和科研、市場營銷兩頭大，中間管理層級小的啞鈴式管理結構。公司的領導，特別是高級小的啞鈴式管理結構。公司的領導，特別是高層的領導者應經常深入基層和市場一線，調節器查研究，解剖麻雀，現場發現問題，解決問題。管理重心下移還表現在公司的干部要直接參與管理部門或本公司的某一具體工作管理直通車，即最高決策層可以和最基層直接溝通。這是因為基層是和企業的上帝——消費者直接接角的地方；是員工成長的舞臺，發展的條件，也是員工積累經驗的源頭，所以企業的領導者要重視基層，特別是深入基層，解決實際問題。要把深入基層當作一項經常性的工作，同時也要根據不同的時間段落實下基層的高層領導人員。每一高層領導應具體負責某一領域的工作，既有利于管理，又有利于辦事效率的提高。

（五）組織放大法

作為公司的領導，要抓住關鍵總是不要事必躬親，所有的工作要通過組織來作。企業的組織是配置資源和發揮能力的結構形式，是企業整體能力的整合機制現代企業的整體能力依存于三種組織聯系形式：正式組織主要是通過“職能角色”發揮資源的優勢作用；非正式組織主要是通過“自然溝通”發掘深層的內在活力；外部協作組織主要是通過“利益共享”實現合作競爭力。涉及企業內部事務的，企業領導要善于利用正式組織途徑解決問題；在適當垢機會和場合，通過恰當的方式，調動非正式組織成員的積極性和主動性；現代企業要生存，必然面臨從多的競爭者；分工又使得企業不能離開其他的合作伙伴而存在，所以企業還必須會利用外部協作組織來發展自己。

（六）高位嫁接法

企業要根據其發展的階段，實行“拿來主義”，站在巨人肩上，高位起步。技術要不斷更新，管理要不斷改進，營銷手段落要隨市場變化而變化。因為在信息時代，企業之間的分工將主要取決于企業之間的技術優勢，而不是資源優勢和資金優勢。技術開發引導著市場需求，技術變遷決定著企業產供銷流程體系和企業產業的發展方向，技術創新成為企業界贏得市場份額的根本途徑。企業的發展離不開企業在技術上的優勢，企業技術優勢的發揮離不開企業在管理上的創新。管理創新是企業根據產供銷技術的變遷和市場的變化，調整企業組織、企業經營管理觀念和管理方的過程。管理創新能夠打破陳規陋習，提高企業的運轉效率，能夠激發員工的技術創新意識并增強企業的活力

管理項目失敗的教訓

事后諸葛亮——管理項目失敗的教訓

能力的提高往往不是從成功的經驗中來，而是從失敗的教訓中來。

在克萊斯勒汽車公司，一位項目經理把辭職信交給當時的CEO艾科卡·李，表示要對自己所領導項目的失敗負責。艾科卡拒絕了，他知道這位項目經理還

會在汽車行業繼續工作，于是說：“我不希望這100萬美元的學費替別的汽車公司交，把教訓記下來，這是我們的財富。”這只是艾科卡帶領克萊斯勒走出困境的一個小插曲，卻令人回味。

許多項目經理不注意經驗教訓積累，即使在項目運作中碰得頭破血流，也只是抱怨運氣、環境或者團隊配合不好，很少系統地分析總結，或者不知道怎樣總結，以至于同樣的問題不斷出現。

可有可無的項目終結

項目總監王深剛進公司不久就接到一項任務，要求他盡快把項目成本估算的準確度抓一下。由于市場競爭激烈，公司不得不在沒有足夠信息和數據的情況下，短時間內做出標書。這使過去幾個項目的進度大大延誤，成本失控，公司管理層對各項目經理的信任大打折扣。

王深查看了公司的項目文件檔案，按ISO9000管理來看還是比較規范的。他找來正處于項目收尾階段的項目經理李明，請他寫一個項目總結。要求項目組所有成員都參與總結，一周之后拿出一份完整的總結文件。李明的項目比預定工期晚了1個月，成本比預算多出10萬元，但與大部分項目相比，這算是做得不錯的了。

頗使王深意外的是，兩天后一份兩頁紙的項目總結擺在他的辦公桌上，除了項目背景的介紹，就是一些原則性的套話，“加強合作、及時跟蹤”等等，沒有觸及任何實質性問題。毫無疑問，公司的項目經理們覺得“總結”可有可無、無足輕重，但是許多寶貴的經驗就是這樣白白地丟掉了。也許，靜下心來好好總結一下，我們可以學到很多東西。

會議主題：抱怨

不得已，王深親自召集李明的項目組開總結會。趙雁發牢騷說：“總結會不是已經開過了嗎？我手上又接了一個電廠項目，馬上要做詳細設計了，這會能不能不開？”王深沒有回答，把李明寫的報告遞給趙雁，問道：“這些體會，你都清楚嗎？”趙雁掃了一眼，雖然有些不太明白，但還是不以為然地說：“這是項目經理的事，我們組員無所謂。況且，大部分項目根本就不寫總結報告。想寫也沒有時間！”

“這就是大家沒長進的原因！” 王深不客氣地說，“超支10萬元是怎樣造成的？是選擇分包商安裝監控設備但又無法控制領料造成的！本想賺取材料差價，卻沒考慮潛在的風險?！蓖跎罱又f：“我聽說以前公司發生過類似的事情，不幸在我們的項目上又發生了。要是總結就這樣草草了事，下次還會有！”

大家逐漸意識到總結的必要性，聯想起以往工作，紛紛發表意見。話匣子一打開，總結會變成了一個控訴會。

在項目總結會上，這是常有的事。項目組把所受的委屈，尤其是來自客戶方面的，統統發泄出來。但結論往往沒有什么建設性，大都是“不要相信分包商的承諾、對客戶的無禮要求應拒絕”等沒有指導意義的結論。

王深鼓勵大家暢所欲言，他說：“總結的意義在于判別結果和我們預想的是否一致，以便調整我們今后做計劃的方法，為以后的項目工作打基礎。大家最好比較一下項目計劃和實際執行的差距。”

李明不好意思地說：“我們的計劃只更新過一次，大家基本不太用?！?趙雁插話道：“這是因為計劃與實際太離譜，連我們自己都不相信它?！?/p>

王深并沒有責怪，他說：“對于新的項目，我們的報價、人員安排、進度控制大都基于假設，這很正?！，F在我們可以回過頭來，逐一檢查當初的假設與現實情況的差距。下次同類項目，就可以大大提高計劃的準確率，尤其是在成本估算和報價策略上，也就能提高中標率了?！?在王深的提醒下，大家的思路逐漸清晰，原來帶有發泄意味的各種意見也變得有些系統化了。趙雁覺得大家的建議在新接的項目中就用得上。

王深特別強調了風險識別意識。他說：“這次在消防審批上的時間比預計的要長很多，影響了回款，這應該加在風險列表中。” 李明補充道：“應該盡早更換電纜供貨商，我們一直希望他們能補上進度，所以遲遲沒有啟動備選供貨商。雖然最后還是換了，但是耽誤了兩周的工期。”

一份非常不錯的總結報告出來了，超過了10頁，特別精彩的是對風險防范中啟動應急計劃的體會以及工程量的估算部分。

成長的煩惱

筆者曾在一家外企工作，看到其完備的計劃書、風險分析、文檔模板，由衷地感嘆總結工作的艱辛。許多項目經理不是意識不到總結的重要性，而是疑慮所付出的勞動太多，是不是值得？

一位著名作家在參加亞洲作家筆會之后曾有這樣的感想：我們代表團成員的論文動輒就是綜述、概述和趨勢分析，而少有像日本學者所做的編年史、作家生平考證之類的基礎數據積累。這或許是在中國文化某些領域我們的研究水平反而比海外落后很多的原因吧。

項目管理水平的提高，離不開項目總結這項基礎工作。這是任何教科書都無法替你做的。如果我們沒有諸葛孔明的前瞻智慧，那么項目總結上的亡羊補牢或許也能起到勤以補拙的效果。

我們往往只有在自己碰得頭破血流后才真切體會到別人的忠告是多么正確。在經歷了無數的成長的煩惱之后，我們才能體會“不聽老人言，吃虧在眼前”這句老話的味道。

對于管理項目，你還想重蹈覆轍嗎？

論項目管理中的量化管理

項目管理理論是一門綜合多門學科的新興研究領域，包括項目綜合管理、項目范圍管理、項目時間管理、項目費用管理、項目質量管理、項目人力資源管理、項目溝通管理、項目風險管理和項目采購管理等九大知識領域。傳統的項目管理論著都重點著眼于這九大知識領域來講解項目管理，卻忽視了一項基礎性工作：量化管理。缺乏量化管理，項目管理只能處于一種“混沌”狀態。以IT項目為例，據稱只有26％的IT項目成功地實現了范圍、時間和成本目標，剩余的74%都有不同程度的失敗。而如果采用了量化管理，項目管理的全過程就會變得“可視化”，發現問題也可以“讓數字說話”。

一．量化管理發展現狀

當前，在項目管理過程中實行量化管理方興未艾，較為典型的理論有六西格瑪管理和CMM/CMMI 體系。

六西格瑪是一項以數據為基礎，追求幾乎完美的質量管理方法。西格瑪是一個希臘字母σ的中文譯音，統計學用來表示標準偏差，即數據的分散程度。對連續可計量的質量特性：用“σ”度量質量特性總體上對目標值的偏離程度。幾個西格瑪是一種表示品質的統計尺度。它有別于其它的質量管理方法，是依據嚴格的數據采集和統計分析，找出誤差的根源，并尋求消除這些誤差的方法，根據顧客的要求來確定的管理活動。

實施六西格瑪包括五個階段：定義(D)，測量（M），分析（A），改進（I），控制（C），其數據流程如下圖所示：

以上這些過程并不是單一的，獨立的，而是相互關聯的統一體（如圖1）。由這些過程很容易看出，六西格瑪是一種基于數據的決策方法，強調用數據說話，而不是憑直覺、經驗辦事。其基礎是需求，作用及過程的量化，從而可以客觀地反映我們的現狀，引起人們的關注。數據定義抽樣數據收集統計分析試驗設計控制數據定義測量分析改進控制。

CMM(Capability Maturity Model)是卡耐基梅隆大學軟件工程研究院（SEI，Software Engineering Institute）受美國國防部委托制定的軟件過程改良、評估模型，也稱為SEI SW-CMM，（Software Engineering Institute SoftWare-Capability Maturity Model)。該模型于1991年發布，目前修改至1.1版，并發展成為系列標準模型。全世界已經有1萬多家軟件企業經過CMM評估。CMM的核心是把軟件開發視為一個過程，并根據這一原則對軟件開發和維護進行過程監控和研究，以使其更加科學化，標準化。使企業能夠更好的實現商業目標。

CMMI(Capability Maturity Model integration)是為了解決現有不同CMM模型的重復性、復雜性，并減少由此引起的成本、改進過程，由美國國防部出資，委托美國卡耐基梅隆大學軟件工程研究院（SEI）開發的能力成熟度模型集成，它將軟件CMM2.0版草案C(SW-CMM)、EIA過渡標準731（系統工程CMM）及IPD-CMM集成為一體，同時，還與ISO15504相兼容。該模型廣泛適用于政府機構、軟件和硬件開發公司。

無論是CMM還是CMMI，都有個共同特點，就是關注量化管理，在CMM/CMMI模型中，企業過程能力等級越高，對量化管理的要求就逐步提高，當達到第4級“已管理級”（Managed級）時,要求針對組織過程的每一個階段都進行了監控、取樣和定量分析，形成了一個關于產品制作和維護流程的數據庫并不斷更新，以保證組織過程保持較高的質量。

他山之石，可以攻玉，可見，在項目管理中引入量化管理也是大勢所趨。

二．項目管理中需要量化管理的領域

項目管理知識體系中，涉及到需要量化管理的領域非常多，從事前管理和事后管理的角度來分，可以分為估算和度量兩大類。估算是以實際統計調查資料為基礎，根據事物的聯系及其發展規律，間接地估算和預計有關事物的數量關系和變化前景。而度量則是依據特定的標準，衡量當前的事物與標準之間的差異。項目管理范圍中，有如下階段需要應用估算技術：

1．項目范圍估算

對項目預期的范圍進行評估是項目的基礎，范圍估算失誤將給項目帶來不可挽回的損失。

2．項目成本估算

成本估算估計完成項目各活動所需每種資源成本的近似值，成本預算的過程是把估算的總成本分配到各個工作細目，建立基準成本以衡量項目執行情況。可見成本估算的準確性直接決定成本的預算情況。

3．項目進度估算

項目管理的關鍵要素之一就是時間管理，也即進度控制。準確地估算對制定項目計劃、監督項目執行都有重要的意義。

4．項目風險估算

對風險識別不到，或對風險可能造成的影響估計不足都可能導致項目失敗，因此對項目風險的量化估算更是至關重要。

定義項目、制定項目計劃的時候需要進行項目估算，而項目執行過程中的跟蹤監督過程則離不開度量。良好的項目管理主要針對項目要素進行跟蹤度量，通過分析度量數字就可以及時發現項目進展中存在的問題，從而有針對性地制定解決方案。通常需要度量的項目要素包括

1．項目進度度量

對項目進度進行定期的跟蹤度量，及時發現當前進度與計劃的偏差，可以及時采取措施，及時趕工或調整進度計劃。

2．缺陷度量

項目的成敗直接取決于客戶滿意度，客戶滿意度是個難以量化的指標，而項目成果——產品的缺陷密度直接影響著客戶的滿意程度。度量產品的缺陷密度，可以有效地了解項目完成的質量。

3．項目工作量度量

工作量是衡量項目成本、人員工作情況的基礎，準確地度量出項目真實的工作量，既可以掌握當前項目的情況，對于今后估算其它項目數據也有重要意義。

4．人員生產率度量

人力資源是項目中最為重要的資源，掌握人員的生產能力對于項目管理中人員管理、資源管理都有重要的參考價值。

三．量化管理的方法

量化管理涉及范圍廣、意義重大，應該如何進行量化管理呢？有很多科學的方法可以輔助項目管理人員進行估算和度量。

典型的估算方法有：

1.Delphi法

Delphi法是最流行的專家評估技術，在沒有歷史數據的情況下，這種方式可以減輕估算的偏差。Delphi法鼓勵參加者就問題相互討論。這個技術，要求有多種相關經驗人的參與，互相說服對方。

Delphi法的步驟是：

1、協調人向各專家提供基本情況介紹和估計表格；

2、協調人召集小組會各專家討論相關的因素；

3、各專家匿名填寫迭代表格；

4、協調人整理出一個估計總結，以迭代表的形式返回專家；

5、協調人召集小組會，討論較大的估計差異；

6、專家復查估計總結并在迭代表上提交另一個匿名估計；

7、重復4-6，直到達到一個最低和最高估計的一致。

2.類比法

類比法適合評估一些與歷史項目在應用領域、環境和復雜度的相似的項目，通過新項目與歷史項目的比較得到估計數據。類比法估計結果的精確度取決于歷史項目數據的完整性和準確度，因此，用好類比法的前提條件之一是組織建立起較好的項目后評價與分析機制，對歷史項目的數據分析是可信賴的。

以某軟件項目的規模估計為例，類比法的基本步驟是：

1、整理出項目功能列表和實現每個功能的代碼行；

2、標識出每個功能列表與歷史項目的相同點和不同點，特別要注意歷史項目做得不夠的地方；

3、通過步驟1和2得出各個功能的估計值；

4、產生規模估計。

針對項目工期估計，常采用PERT(計劃評審技術，Program Evaluation an Review Technique)技術進行估算。

針對項目成本估計，較好的方法有經驗估算法、因素估算法和WBS基礎上的全面詳細估算法等多種方法。

度量不一定需要特定的方法，度量的關鍵在于數據采集與分析。度量的數據是根據管理的需要采集的，通過對采集到的數據統計分析，就可以掌握項目的情況。

四．量化管理實例

以某系統集成項目為例，可以看一下怎樣在項目管理中應用量化管理。

項目名稱：某大樓綜合布線系統集成

項目啟動，首先估算項目范圍、進度、成本，以便制定項目計劃。由于該項目屬于典型的系統集成項目，采用“類比法”進行估算。估計該大樓項目范圍約需為2000個點布線，時間約需1個月，成本約為300萬。項目組根據估算結果編制項目計劃。

項目實施過程中，針對缺陷數量采集數據進行度量，從而管理項目質量，獲得采樣數據如下圖所示：

可見，缺陷數量始終控制在允許的上下限范圍內，該項目質量獲得了較好的控制。五．結束語

項目管理是個不斷完善的知識領域，引入量化管理，強化量化管理，可以使項目管理知識體系發揮更大的作用。

淺談如何實行有效的項目管理

目前隨著公司的快速穩定發展和在系統工程業界的影響不斷擴大，簽定的項目呈現出以下特征：

1.系統規模大

2.工期緊張

3.需要各方面的配合多。這就對我們的項目經理提出了更高的要求。

如何實行有效的的項目管理，從我個人的理解，一個項目實施的過程中，最重要的是對目標的實現。對于項目目標的明確劃分和界定就成為了如何能夠達到項目目標的關鍵的第一部，同時對于項目實施的每一步都是圍繞著項目目標進行的。其次是對進度的控制。對于實現項目目標的基礎上，是否按時完成了項目的目標就成為了檢驗項目是否成功的標準，按時完成目標關鍵是對項目進度的合理控制和把握。再次是對成本的控制。成本的控制包括對資源的申請、合理調配和合理利用；對項目資源之外的各方面成本控制。

另外，在項目實施中最關鍵的一點保證就是客戶，因此同客戶保持良好的客戶關系，時時體現為客戶著想，讓客戶滿意也是檢驗項目是否被客戶認可的一個關鍵因素。下面就圍繞著以上幾方面進行簡單的介紹。

1.目標管理。每一個項目的實施從與客戶接觸到合同談判到具體實施都有一個明確的總的系統目標。而在項目實施中，將總的系統目標分解為幾個階段目標進行，每個階段目標再分解為若干小的目標，最終分解為每個人在一定時間內能夠看到并達到的目標而加以實現。同時每一步的目標分解和確定都經過和客戶方的協調和確認，以保證總目標的實現得到客戶的認可。對于每一步目標的變更以及同客戶間任務的分配也經過同客戶多次的會議討論確定。

2.時間控制。項目的時間控制是同目標管理密不可分的，每一步的進度控制都是基于一個特定的分解目標而確定的。目標的時間計劃制定要求切合實際，并且在開始階段要求嚴格實行按時完成，這樣到后面可控化的程度就高多了。對于項目的時間計劃也要求分解到每個人在一定時間內能夠完成一定的目標。同時對于進度的控制要求隨時檢查時間計劃是否按時完成以及同計劃間的差異，隨時采取措施調整相應計劃以保證總體計劃的可控性。

3.規范化的項目管理。項目按照規范化的項目管理方法進行管理能夠很好的對項目進行控制。首先從項目的綜合計劃和質量計劃，將項目的總體目標和分解目標以及時間計劃都紀錄下來，以保證項目的實施。其次對項目按周計劃、周總結以及每個人按照周計劃、周總結的管理方式進行管理控制，隨時記錄下文檔，以保證項目進程的可控性。同時隨時監控項目中可能出現的異常情況，比如硬件、軟件問題；人員資源問題等等，出現問題及時予以解決并記錄下來，及時予以調整項目控制保證項目進程的實施。

4.良好的客戶關系。在一個項目中保持良好的客戶關系可以說是本項目能否成敗的基礎，因為

項目需要配合的方面很多，任何一方面的問題都可能導致項目的拖延。從項目一開始，根據我們的經驗積極為客戶著想，設計改進適合客戶的系統，客戶對我們的努力滿意，也就為能同客戶更好的合作奠定了基礎。

5.人員協調。隨著項目規模的擴大，項目組成員的數量也會越來越多，如何協調好每個人發揮每個人的充分作用就很大程度上決定了項目的成敗。因此項目組從管理上嚴格每個人的任務職責分工。從生活上關心每一個員工，讓每一個員工都成為朋友，幫助每一個員工前進，也使得項目組的情緒穩定，遇事不會影響到整個項目組，保證了項目組的活力。同時，要把項目組成員的定義范圍廣義化，即直接面對用戶的項目組成員和間接面對用戶的的項目組成員，如生產部門、采購部門、計劃部門、財務部門、質量部門等等，充分發揮它們的協助、指導和監督作用，對高效率、高質量完成項目目標起到至關重要的作用。在這里，我也希望我們這些間接面對用戶的部門能夠從思想上認識到它們自身也是項目組的一分子，多從項目組的角度考慮問題，為用戶提供出色的全面的服務。

從上面幾個方面闡述了我對如何實行有效的項目管理的看法，其實方法還有許多，但我認為最最關鍵的是我們對待用戶的看法和態度。應該這樣理解我們的用戶：他們不是我們工作的障礙，而是我們工作的目標；我們不是通過為他們服務而給他們恩惠，而是他們給我們為其服務的機會而給予我們恩惠。只有樹立這樣的觀念，“真誠的為每一位用戶設想”才不是一句空話，我們和利時公司才能在如此激烈的競爭市場找到長久的立足點。

淺談項目管理

一.商務談判

1.作人的姿態

作人似乎跟商務談判不太有關系，很多技術人員相信PM需要的是本事，是如何做好一個項目，而不是會搞好關系弄的四平八穩的人。隨著PM在中國的悄悄興起，越來越多的PM開始在老總的授意下參與商務談判，和銷售們一起打單子，這就比較實在的需要PM們去揣摩客戶的心理。揣摩客戶心理需要有多方面的知識，需要深度和廣度，然而，最重要的仍然是作人。如何放下架子，降低作人的姿態，對從技術人員轉型的PM們來說，是至關重要的。

降低作人的姿態需要從多個方面去實施，最主要應該記住：人不可貌相，更不可以地位衡量。很多公司為了保持公司形象，會統一叫員工打扮的好看一點，看起來象個白領的樣子。然而，老板多半是沒有約束的。中國改革開放才二十年，很多有錢的老板實業家文化層次都不高，往往是當大學生們只會把屁股坐在板凳上肆意揮霍父母辛苦積攢的財富時，他們已經在各地奔波，積累豐富的商業經驗并對金錢，人生和社會的本質有了充分的認識，形成了自己穩定的思維框架。這些人，很多都是穿著舊舊的衣服，戴著破破的手表，說話的時候經常會帶上三字經，鉆進上海的人堆里，搞不好你會把他當成民工。因為到他們所處的社會地位，已經不需要任何華麗的外表來襯托自己的身份，他們有的是底氣。對PM來說，這是個非常危險的挑戰。雖然說項目在初期有意向時會對對方的人事和關鍵人物有一定的了解，然而大項目里能說的上話的人太多了。上海人最瞧不起的就是土氣，很多人談項目的時候看到民工或很俗氣的表現不免會皺皺眉頭，往往在皺眉頭的時候就失去了項目，也就是失去了市場和金錢。PM必須作到能與每一個層次的人交談，尤其是看起來比自己層次要低的群體，哪怕是公司里掃地的阿姨。只有作到謙虛謹慎，不擺架子，尊重別人，才會得到別人的尊重，才有機會贏得項目。鼻子比眼睛高的人只會把自己的鼻子撞扁。

2.豐富的知識面

光尊重別人還不足以贏得項目，準確的說是贏得對方關鍵人物的信賴。PM一般用不著陪客戶喝酒吃飯，那是銷售們的事情，但是PM和客戶討論問題可能是最多的。討論問題的時候就是機會，如何投其所好，是一大關鍵。金錢與美女依然是常規的敲門磚，然而這種傻瓜也知道的辦法人人都會去做。老板的關系也只是一個方面，如今的大老板，哪個沒有關系？同等條件下PM憑什么去勝過別人一籌？

我一個朋友（PM）打一個單子時，發現對方對什么都不太感興趣，費了很大力氣也找不到突破口。對方這個人非常順利，金錢地位美女樣樣不缺。他花了好多天和對方交談，以自己的博學逐漸取得了對方的信任。后來他隱約發現對方對數學和天文學的發展史有所涉獵，如獲至寶，回家花一個通宵的時間在網絡上搜索相關資料。第二天他根本不談項目的事情，只跟對方大談特談哥白尼，46 布魯諾，伽利略這些人的生平，整整吹了一天。對方點頭如搗蒜泥，態度和熱情都來個一百八十度轉彎，隔天他就拿到了單子。這是個經典的戰例，誰能事先想到哥白尼會來幫助IT的人賺錢？這個PM靠的就是博學和由博學引申出的敏銳的感覺抓住了機會，讓客戶產生共鳴?？蛻舾杏X他層次也很高，而且和自己有共通之處，信任度大大增強，把項目交給他放心。如今這種例子在商務談判中已經屢見不鮮了。對PM來說，并不要求在各個方面都很精通，那是不可能的事情，只要PM對一些流行的話題和天文地理歷史各方面的知識有個大概的了解，在需要的時候能盡快的掌握，才有機會創造機遇和把握機遇。

3.強大的溝通能力

胸中有萬千墨水卻不知如何表達其實是比較少見的，但并非絕對沒有。每個人的人生軌跡都有所不同，思維受環境的影響也各有差異。包括象我們目前這個班級里的一些未來的MSE們，一定有比較內向或者不太愛表達自己觀點的人，這些人比較被動，往往很難承擔起談判的重任。從今天開始，這類人就必須重新學習如何說話，如何大聲的爭論。溝通，并不僅僅是大聲說話，而是在表達自己觀點的同時發現問題并綜合整理加以解決。除此之外，溝通的能力與社會經驗息息相關，與PM的見識聯系緊密。在日常生活中，PM就要多留心，多思考，當別人想到某個層次的時候要爭取比別人考慮的更深。當然，也有一些不夠踏實的朋友把溝通和吹牛當成了完全的一回事情，在和客戶交流的時候口若懸河的說一些不著邊際的話。這種人，碰到不懂，不太認真或者好奇心強的客戶是有一定市場的；而有水平，負責任的客戶往往會覺得這種人不可靠，一般不會把單子交給他。PM需要把握好這個度，吹是肯定要吹的，只是吹牛的時候一定要有基礎的去吹，對從來沒涉及過的領域或者根本不懂的東西輕易不要發表意見，挑選自己熟悉的方向合理的進行發揮，適當的留上一兩手，給對方高深莫測的感覺，效果最好。

4.優秀的售前團隊

這個團隊一般是由總經理發起并組建的，通常不指定PMP，對團隊的成員如SALES，PM，SA，ENGINEER們的團隊合作提出了比較高的要求。一般公司在接下一個單子進行到一定程度的時候，PM往往會尷尬的發現協議上銷售代表們對客戶的一些承諾是幾乎做不到或者根本做不到的事情。這種情況非常多，銷售的任務是拿下單子，我聽到的銷售們說的最多的就是“沒問題”或者“NO PROBLEM”，但是當我聽到客戶的要求和銷售的回答時我總是心驚肉跳，很不自然。銷售是非常辛苦的，為了建立客戶關系，尤其是空白的市場是很不容易的，往往為了一個單子會犧牲非常多。在這種情況下，和銷售進行協調自然而然的又落到了PM的頭上。在銷售和客戶做承諾之前，PM要主動的跟銷售交流，提供粗略的總體設計框架和技術難關以及能考慮出的工作量，而不是等出了問題再被動和銷售在老板面前互相推委責任。在組建團隊的時候，PM要根據團隊里每個人的素質和任務進行因人置宜的信息傳遞。優秀的售前團隊合作是接單的重要保障。

在商務談判的實際操作中，存在著各式各樣的問題，PM的職責和要求絕非以上幾點所能描述詳盡。根據環境，政策，人文，關系等各方面的不同情況，PM的不同成長經歷，每個PM最終都會建立自己對商務談判的看法和經驗。但是有一點可以肯定，這是PM成為PM的第一道關，也是最重要的一關。接不到單子，PM將失去存在的意義。與銷售有所不同，PM在該階段的任務除了接單，還要盡可能的搜集客戶關鍵人物的資料并與對方各個階層的負責人建立良好的客戶關系，以便在項目實施時充分調動資源。

二.啟動階段

1.項目的一些基本概念

項目三要素有多種版本，各不相同。實際操作中多分為范圍，成本與進度，其中最重要的莫過于范圍。我們把項目最終生成并提交給用戶的產品和文檔統稱為遞交件。談判的時候一定要確立遞交件的標準和要求，也就是范圍。盡管商戰的時候不可避免的客戶會不斷提高標準和要求，而承諾的款項卻不會有一分錢的增加。但是這個標準對每個公司來說都有一個底線，一旦超過了這個底線，那項目就肯定是虧的。除非是為了二期有利可圖或者是為了搞好關系，否則范圍超過底線的時候情愿不做，再厲害的PM在這種情況下也是無能為力。建立范圍需要的就是PM的多年的實戰經驗，在大大小小的項目中用血淚換來的一些體會。在這個時候，很能體現PM與技術人員的區別。成本就是客戶答應付的款項，與我們的投入成本并不是一回事情。進度就不用多描述了。

項目如何成功？也有一些關鍵的因素。個人的理解也不盡相同，通常包括以下幾個方面：界定工作目標及工作任務；老板或高層的支持；優秀的PM和開發團隊；充足的資源；良好的溝通；對客戶的積極反應以及適當的監控和反饋。這里要注意的就是資源和高層的支持。一個上規模的公司

總是同時會有很多項目，可是再大規模的公司資源也不足以保證每個項目都能組建最合適的開發隊伍或擁有最好的環境。這時候各個團隊或者部門之間不可避免的會發生資源爭奪戰，摩擦再所難免。這時候對PM的作人再次提出挑戰。除了高層對PM項目的重視程度，如果PM平時在公司與同事相處的好往往能使很多別人看起來很棘手的問題迎刃而解。相反，一個不會作人的PM由于人緣差，即使高層強壓別的部門或團隊配合，別人也會能拖就拖，延緩項目的進度和質量。有時候，這種內耗對項目和PM來說是毀滅性的。對客戶的積極反應也比較關鍵。一般來說PM已經被項目里大大小小的事情搞的筋疲力盡，要PM去主動要求客戶配合是很吃力的事情。然而，這個時候，越是困難，越是覺得累，越是要去主動?？蛻敉膊皇翘貏e的積極，主動與客戶聯系溝通和測試能及早發現問題。從風險控制的角度來說，問題發現的越早，風險越小，損失也就越小。積極的態度可以帶動客戶的積極性，在項目完工的時候，客戶對你的感激往往是難以用語言描述的，這對以后接單或者做二期三期會打下良好的基礎。因為在和別的新客戶談判的時候，新客戶自然會找你的老客戶了解情況，這時老客戶隨意的一句話頂的上你很費心的十句。

項目具有商業行為的幾個重要特征，有消費源，有參與者，有成功關鍵因素，有財務目標，有風險。

2.啟動階段的主要任務

根據PMI的解釋，接單之后項目自然轉入啟動階段。啟動階段PM的主要任務是率領總體架構設計師和系統分析員收集盡可能詳細的數據，確立盡可能詳細的需求，進一步確立詳細的項目范圍，預估資源，確立其他方案并獲得進入下一階段的批準。在這個階段，隨著需求分析的深入，PM也開始在公司內部進行人員挑選和資源爭奪，著手組建自己的項目團隊。項目即將進入計劃階段。

在收集完數據之后，PM要和客戶開始明確項目的大小，成本，規格，期限等重要特征并將其寫入合同文本，同時準備內部的包括預算，衡量標準等文檔，建立項目的評估標準。接下來就是需求分析。由于專業的原因，我們這里僅討論軟件工程項目的需求分析（以下簡稱需求分析）。

需求分析的主要參與人員有PM，總體架構設計師，系統分析員，熟悉業務流程的客戶。PM統領的團隊這時候還不是真正的開發團隊，我們叫做前期團隊。隨著需求分析的逐步深入，新的團隊成員不斷加入，啟動階段結束的時候正式的團隊將建立。對一個已經啟動的項目來說，需求分析直接決定了項目的成功與失敗。最初的需求體現在客戶的工作說明書或招標文件及附件上。這種需求一般比較含糊，無法體現客戶真正的需求。前期團隊要根據自己的經驗和客戶溝通并引導客戶進入正軌。有時候客戶會很不講道理或者思路僵化，就要求按照他的思維去定一些明顯錯誤的需求。這個時候團隊成員要耐心和客戶舉事實，談經驗，講道理，用圖形或模型等直觀的方式將需求描述出來，比如常見的數據流圖等。所以說，爭論再所難免，客戶有時候會吹胡子瞪眼睛拍桌子甚至會說“這個東西不要你們做了”之類的話。PM此時除了要親身參與需求分析綜合整理文檔之外，還要處理好團隊成員與客戶的關系，確保關系不會惡化到無法收拾的地步。只要PM盡力約束團隊中的成員，這個度還是很容易控制的。

對快速開發和疊代開發來說，需求和實現往往是同步進行，開發速度快是一大優勢。對有相同或類似模式的小項目來說采用快速開發或疊代開發是很合算的做法，時下流行的極限編程就是針對這方面建立的思維模式。然而，大中型項目中有太多不一樣的需求和模塊。如果不是因為項目有差異，那么市場上就只有產品而沒有項目了。所以，大中型項目的需求要認真仔細的去做。我們要討論一個問題，究竟應該在需求分析和總體設計上花費多少時間？我們熟悉的瀑布開發模式基本上分需求分析，總體設計，軟件開發，測試等幾個階段，然而究竟應該在前兩個階段上花多少時間卻沒有定論。實際項目操作的例子表明，分析設計的時間越長，需求設計做的越詳細，測試的時間就越短，返工率越低，風險也越小，成本越容易得到控制。而需求分析和總體設計沒有做好就急忙上馬進行開發的項目在項目初期進展順利的時候問題不大，到了項目后期和測試階段一些潛伏期比較長但是破壞作用比較大的問題就會凸顯出來，造成返工，延長測試時間。所以與其把問題堆積到緊張的項目后期，不如把時間多花點到需求分析和總體設計上。基礎夯實了，金字塔就容易造了。

在日本公司打工的程序員們可能都知道，小日本的軟件規范非常厲害，他們花在需求分析和總體設計上的時間通常在40%到50%左右，遠遠超過國內軟件項目的實施，效果也要強的多。他們總體設計的規范甚至詳盡到某個過程該如何判斷，確立什么樣的條件，換言之就是把什么時候該如何寫(if...else)語句都幫程序員定好了。在這樣的軟件規范下，程序員更象是裝配流水線上的工人，對一個模塊或技術熟悉到一定程序就變成了完全的重復性勞動。所以在日本和歐美經常會有程序員是低級工作一說，很多人不明就里，對國內程序員也照搬，對國內的程序員來說是很不公平的。在國內，48 只會照抄別人代碼，一點都不懂創新，凡事依靠別人，快下班就盯著表看的程序員是不少，這種人一般很難有什么前途。但是，優秀的不斷進取的程序員也很多。由于國內沒有象CMM這樣的軟件規范或者很少，所以這類優秀的程序員不少都是干著系統分析員甚至PM的活，拿著程序員的工資。這類程序員雖然在起步時會吃很多虧，而且是主動找虧吃，然而幾年之后與前一種程序員的社會地位會出現明顯的分化。當上進的程序員們作為PM進行商務談判的時候，前者還在各個公司里頻繁跳槽，跳來跳去都不滿意。有些扯開了，回到我們的話題。日本的軟件規范與CMM有驚人的相似，其中至少有35%以上都是幾乎一模一樣的。最近經濟不景氣，東京倒閉了160家軟件公司，這個數字是今年6月份的，還在不斷增加。這些公司紛紛搶灘上海，招收技術人員。如果去這樣的公司應聘就要考慮清楚了，進去可以學到他們的規范和質量控制，可是要想從程序員成為系統分析員或PM，比登天還難。往往一個程序員進去干了好幾年，對自己的那一塊熟的不得了，而對隔壁同事所做的東西一竅不通。拒傳華為正在嘗試CMM4（華為印度研究所已經通過CMM4），對在華為工作的程序員們來說可謂福禍難料。當然，已經作到PM或QA或者熱愛CODING的朋友例外。

需求分析本身也存在著時間分配的問題。第一遍需求分析花的時間會最長，分析員們在客戶的各個部門之間幾乎把腿都跑斷，把口水說干，就是為了確立一個初期的需求模型。所有的文檔將會提交給PM進行復審并簽字，不合格的打回重做。反饋表隨之將提交給客戶，第二遍第三遍等等等等接踵而來，與客戶反復討論和磋商，反復提交文檔和表格，目的只有一個，明確需求。當PM最終合并了所有文檔并確立需求之后，最終生成的需求文檔將提交給客戶的各部門負責人簽字。這些文檔將作為合同的附件添加，以便在將來項目變更或者碰到重大問題時和客戶扯皮的重要依據。需要說明的是，客戶并非都是蠻不講理，但是說實話，頗有無奈，國內目前的項目大多數客戶為了不讓自己的錢白花，經常變著法子提需求。在啟動階段明確需求并簽字，無論最終情況如何，一份詳盡的書面文檔可以解決很多口頭承諾或概念模糊的文檔帶來的許多問題。

詳盡的需求分析有一個額外的好處就是對一些雙方都很陌生或者從來無人嘗試的領域將是一個決定是否進行項目的判斷標準。有時候，這種大項目在簽單時雙方都沒有絕對把握保證可以出成果，一旦在需求分析階段發現難以逾越的技術難關，就會放棄項目。典型的例子就是NMD洲際導彈防御系統。上世紀八十年代初美國搞星球大戰計劃，拖跨了蘇聯。大家對那段歷史有些含糊，很多人認為蘇聯人上了美國的當。其實并不完全如此，蘇聯人的情報機構無孔不入，并非那么容易上當受騙。實際上當時美國國防部已經開始著手NMD系統軟件的需求分析，前后耗資數億美圓，耗時兩年，僅僅是做需求分析，終于發現存在著在當時技術上無法達到的高度，隨后項目被放棄。

3.項目啟動

項目啟動要確定項目計劃，與客戶一起實施第一次項目審核，確認并對一些產品和服務向下包廠商下訂單。這個時候的PM會忽然發現有開不完的會，一天開三到四個會議是很正常的事情。這些會議有與客戶的會議，與下包廠商的，有團隊的，有公司高層的。團隊的會議主要是建立正式的團隊，提供團隊成員的角色和職責，提供績效管理方法，向成員提供項目范圍和目標。與客戶的一個主要會議將是項目啟動會議。在這個會議上PM會與客戶確立正式的交流渠道，項目綜合描述，讓項目參與人員相互了解，建立以PM為核心的管理制度。還有一些零零碎碎的東西甚至包括辦公場地的大小，電話多少部，所有人的聯系方式等等都要在會議上確立，并做會議記錄。這都是些非常瑣碎的事情，聽起來婆婆***，卻是非常必要，缺一不可。大概就是所謂三軍未動，糧草先行吧。

這時候，作為公司高層，應該向全公司發表申明，正式給PM發布項目經理任命書和項目授權書。這個動作雖然在別人看來有些形式主義，但是對提高PM本人的士氣和責任感是有很大助力的。

三.計劃階段

1.定義結構分工結構圖（WBS）

啟動階段結束后，項目進入計劃階段，也就正式進入實施。這里概念可能有些不太對頭，其實是翻譯的緣故，反正大家明白意思就行，不用拘泥于字面。WBS是一組要提交的項目元素，用來組織定義項目的總體范圍，具體包括從工作內容，資源，成本角度考慮項目范圍；建立一套系統所需要的分層工作結構；把項目分解成易于管理的幾個細目，這概念有些模糊，其實跟資源管理器里分目錄是一回事情?？梢哉f，WBS是計劃階段的核心。WBS會詳細的分到遞交件，包括給自己人用的項目使用的過程文件，給客戶用的模塊和說明文檔，完成每個細目的標準以及如何把這些細目的責任分配到具體的個人。WBS有縮進式和樹狀式，我這里也沒辦法畫圖，大家參考一些項目管理的書籍，里面有詳細介紹。我整個文章只挑我覺得需要注意的地方，如非必要，對技術細節或者工具使用不做詳細介紹。WBS的細目并不需要分解到同一水平，最下面的細目叫做工作包，分包的依據

是個人的責任和可信度，也就是說到每個人頭上的任務是否能落實，是否有把握完成；還有就是準備對項目進行控制的程度，程度越深，WBS樹也就越深。由于WBS是實用性的東西，根據個人理解也不一樣，所以一個項目可能會有幾個正確的WBS，看PM的需要和最適合當前團隊狀態的進行選擇。

WBS的定義還是很麻煩的。PM要召開團隊進行討論，向成員提供與項目相關的所有詳細資料，并把WBS樹分解到二層三層。然后要花上一段時間讓成員進行頭腦風暴式（BRAINING STORM）思考，制訂工作產出和相應人員的職責，記錄每一個工作包的完成標準。在頭腦風暴式思考時，會有很激烈的爭論，PM要協調關系，調節氣氛，從自己能考慮到的各個角度旁推側敲，提示成員的思維角度和方向并加以總結。盡管很麻煩，制訂WBS仍然是非常值得的。如同需求分析一樣，WBS準備的越充分，編碼的進度越快。

2.風險管理

既然是商業行為，那么項目的風險必然存在，相信閱讀這個帖子的朋友不少人都經歷過或大或小的風險。有些風險很容易解決，有些風險則大大損害利益。不論什么樣的風險，能避免盡量避免，所以有必要對風險進行管理。由于風險的不可預知性，風險管理難度很大，概念也很難講清楚，只能從一些可行的角度去分析，進行管理。

首先要識別風險。這是個難度很高的活。PM要先召開風險識別會議，這個會議面向公司，高層，跨部門的有經驗的人都將參加。然后審核由項目小組生成的風險清單并與重要成員進行風險溝通，檢查一些重要的風險源如WBS，成本（時間）預估，人員計劃，采購管理等等。最后就要用到PM本身在以前類似項目中得到的經驗教訓。

識別之后要進行分析。我們可以進行粗略的量化分析（精確分析是不可能的事情）。有經驗的人可以一起參加討論，把提交出來的風險進行分類。首先按發生的可能性分，一般分成高，中，低三個級別，雖然很勉強，但是好歹也有個量化了；然后按耗去的成本分，也是高，中，低三級。我們可以把這兩種類別的三個級別進行組合，碰到可能性也高，成本也高的風險就定位為不能接受。碰到這種風險只好讓客戶修改需求或者增加風險預留成本，否則一旦虧起來不是虧一點點，有可能賠的很厲害。高和中，中和中的搭配都是屬于高風險，中和低，低和低搭配屬于低，高和低搭配屬于中。

針對出現的可能性，需要采取一些手段降低風險。到目前為止也沒有一個定論說有絕對好的方式，只能盡其所能的避免。有幾種方法可以考慮，第一種是將風險納入項目管理計劃并指定負責人，由外部人員定期檢查項目風險，一旦風險發生，執行風險管理計劃；第二種是保險，這種屬于風險轉嫁；第三種方式有點奸，不過最保險，就是把客戶拖下水，讓他們一起參與風險管理，呵呵，到時候就好說話了：）

風險管理作為項目計劃之后，PM需要更新WBS，修改日程計劃和更新風險管理計劃。

風險預留通常是成本的8%。

3.預估

預估是從量化的角度對項目進行評估，主要包括工作量，任務期限，人力，設備，材料，成本等，要注意預估不是財務策略或報價。

預估其實并不是一次性工作，在整個項目過程中，預估始終需要。預估似乎沒什么特別需要提的地方，每個PM接到項目的時候自然會有預估，在項目發生變更或進入下一階段時也會預估。預估的作用主要還是讓PM作到心中有個底，安排計劃時不至于毫無頭緒。

4.進度計劃

進度計劃就是一個模塊或功能要寫多長時間，PM安排個日期，設立里程碑，叫程序員們不能偷懶。進度計劃是從WBS提取過來的。對PM來說，合理的安排進度計劃對項目控制和激勵團隊士氣有著很大的作用。對程序員來說，進度計劃毫無疑問是噩夢。

顯示進度計劃一般有先后順序圖，甘特圖和里程碑圖表。上回邵衛老師講課，推薦的工具是m$的PROJECT，這個工具我還不會用，因為沒時間去摸索。我的頭倒是用的很溜了，近一個月來他就用這個PROJECT畫了一個又一個的里程碑圖，不停的折磨我和同事的神經。我們一般都是一邊開發一邊做UNIT TEST，效果上來看，因為有強大的時間壓力，效率上比之前確實要提高不少，可是我們也只能結結巴巴的趕完進度。由于TEAM里人少，我們都是一個人做幾個人的活。我每天早晨六點多出門，經過將近兩小時顛簸，八點多點已經坐在位子上，中午吃15分鐘的飯，干到晚上八點下班，到家吃完飯往往已經11點了。一個多月我從來沒吃過早飯，沒有睡過六個小時以上的懶覺。雖

第五篇：信息系統項目管理師論文

項目的XX管理

[摘要]：

XX年X月，我作為項目經理開始參與XX系統項目的開發，主要負責系統的組織規劃實施開發與項目管理，該系統具有嚴格的安全，穩定，時實高效和可靠性能要求，該系統由XX子系統和YY子系統兩部分組成，XX子系統主要實現XXXX業務，YY子系統是整個系統的核心，采用了struts+hibernate+spring主流WEB應用框架，實現了WEB應用服務器websphere與協作應用服務器lotus domino 的高度集成.隨著軟件系統的日益復雜化和用戶需求，軟件更新的頻繁化，XX管理在軟件項目中顯得越來越重要了。本文以該項目為例，結合作者實踐，（此處提出論點，后面正文會用到，建議3個論點即可，論點來源于各個知識領域的過程和方法）主要通過在項目前期，做好需求調研，總體設計和詳細設計并制定完整的配置管理計劃。在該項目全過程中規范化配置管理，注意員工培訓并加強溝通與協調，來實施項目的XX管理。目前，該系統已開發完畢，正式投入運行，狀況良好，受到客戶一致好評。

[正文]：

（本段在摘要的第一段的基礎上擴充即可）XX年XX月，我作為項目經理開始參與XX系統項目的開發，主要負責系統的組織規劃實施開發與項目管理，當然還做一些編碼工作，主要是公用基礎代碼和核心代碼的編寫與維護。XX系統是將XX子系統和YY子系統有效的結合起來，采用先進的XX技術和YY技術，充分利用【電話，短信，傳真，因特網】等信息化手段，解決XX問題，規范了業務流程，強化了內部管理，與XX技術的完美結合，使應用系統功能更加完善，提高了整個XX業務的工作效率。其中，XX子系統包括：[客戶管理，機票管理，票證管理，銷售管理，財務結算，調度管理，遠程營業部（代理商／分銷商）管理，系統管理]八大功能模塊，并統一于服務器端軟件模塊。YY子系統由【電話呼叫系統，短信分發系統，傳真呼叫】系統三部分組成。YY子系統是整個系統的核心，采用了struts+hibernate+spring主流WEB應用框架，實現了WEB應用服務器websphere與協作應用服務器lotus domino 的高度集成,在本次開發中，我把它視為整個項目的重點

由于考慮到寒假和春運期間將會是旅客的高峰期，客戶要求系統必須在12月底前交付，項目開發周期為XX個月，為此我做了如下安排：前XX個月主要集中精力用于XX子系統，后XX個月主要完成XX子系統和YY子系統的集成以及項目收尾工作

（摘要的第二段的基礎上擴充）隨著軟件系統的日益復雜化和用戶要求，軟件更新的頻繁化，XX管理逐漸成為軟件生命周期中的主要控制過程。在軟件開發過程中，扮演越來越重要的角色。一個好的XX管理過程能覆蓋軟件開發和維護的各個方面，同時對軟件開發過程的客觀管理，即項目管理也有重要的支持作用。在該系統項目中，我主要使用（XX管理的過程和方法），并通過在項目前期作好需求調研，總體設計和詳細設計并制定完整的配置管理計劃。在項目全過程規范化配置管理，注意員工培訓并加強溝通與協調等方法和策略來實施XX管理。

（采用總-分-總的格式）

1． 項目前期做好要求調研，總體設計和詳細設計，并制定完整的配置管理計劃。（總）

（分，描述各個知識領域的工具和方法，不用面面俱到，要有側重點，要結合實際，不要純擺理論）項目計劃階段，我對需求分析，總體設計和詳細設計這三項活動工期安排如下：需求分析12天，總體設計和詳細設計總共20天，時間盡量充足。在做需求調研的時候，我要求一定要和客戶充分溝通，深入挖掘客戶的隱性需求。不僅要實現客戶需求的功能，在界面上也要讓客戶滿意，為此我們作出了航空系統的虛擬界面，讓客戶對系統 有一個感官上的整體了解，在需求分析完成工作之后，我們還通過小組會議的形式進行了確認和評審。并邀請客戶方代表參與。最終的《需求規格說明》我們也要求客戶方代表一定要簽字確認。在總體設計和詳細設計過程中，我們盡量使用適合本項目團隊特點的工具和技術，并充分考慮其先進性和成熟性。在設計完成之后，我們仍舊對其進行了評審，總結和討論，對爭議比較大的地方交公司資深專家審核評定。

（總）配置管理計劃的制定也使配置管理中不可少的一步，它能有效的指導后期配置管理工作。在本項目中，配置管理計劃由配置管理員完成，我只做一些審核工作，軟件資源配置管理計劃，配置項目計劃，交付計劃，備份計劃，CCB

審批計劃等．．．．總之，我認為（結論或觀點）項目前期做好以上鋪墊工作可以減少變更，對后面一些工作可以說是水到渠成。同時，一個比較完整的計劃，也可以避免不必要的項目反工，而且項目管理員的工作也會比較好做一些。

2．項目全過程規范化配置管理。（第二個論點）

開發過程中，對文檔修改非常麻煩，在配置管理中，對任何一配置項的修改都可能導致版本的變化。因此，對配置管理規范化勢在必行，在本項目中，我要求配置標識一定要規范，必須獨立命名配置項，配置對象的標識要充分考慮命名對象間存才聯系。在配置管理中，項目組成員要各司其職，不得越權操作，同時還要根據自己的權限操作配置項。我的工作在配置管理中主要是：定制開發子系統，定制訪問控制，制定常用策略，制定集成里程碑，進行系統集成．．．．．而配置管理員的職責主要是：創建配置序，為項目成員分配權限，對存儲庫進行日常備份恢復等．．．軟件開發人員主要根據項目的開發配管理策略，創建，修改和測試工件等。軟件生存期內全部軟件配置是軟件產品的真正代表，必須保持精確，軟件工程中某一階段的變更都會引起軟件配置的變更，對這種變更也必須做到嚴格規范的控制和管理。為此，我做了如下規定：處于工作狀態的產品開發人員可對其修改，而作為基線進入配置庫的產品，則不允許開發人員對其進行修改。在本項目中，我們還成立了臨時CCB,由項目經理，用戶代表，軟件質量控制人員，配置管理員5人組成。我們要求對于用戶提出的變更請求要嚴格按照變更控制流程處理。在用戶提交更多請求后，開發人員對其進行評價，并產生變更報告。在由變更控制委員會〈CCB〉作出決定是否進行變更。通過批準，就重新檢出變更的配置項，建立測試基準程序，并執行質量保證和測試活動，必須通過CCB的鑒定審批后，方可實施變更。

3．注意員工培訓并加強協調與溝通。（第三個論點）

項目組成員大多來自不同部門，對項目環境還不熟悉，為了能實施配置管理系統，我建議公司對項目組成員進行相關培訓。針對配置管理員，我們要求他學習配置管理工具管理相關的內容。針對開發人員，主要學習配置管理工具與開發相關的常用操作。針對全體人員，要讓他們了解配置管理策略和流程，以及如何與開發管理，項目管理相結合。同時，我要求項目組成員要加強協調和溝通。可以使用PVCS，通過ressionmanger文檔共享和連鎖機制。Tracker與電子郵件的集成，加強項目成員之間的溝通，做到有問題及時發現，及時修改，及時通知，但又不額外增加很多的工作量，這樣有助于營造一個和諧，公平，競爭的氣氛和環境。

XX系統在XX年XX月正式上線，提前完成了項目，目前系統運行正常，受到客戶和有關部門的一致好評，對項目的滿意度較高。（回顧和反思）重新回顧該項目也存在一些問題不足，比如：項目初期，大多數成員對版本管理一點都不重視，總是敷衍了事。代碼編寫人員編寫得代碼也混亂不堪，給測試人員和維護人員帶來了很大不便，一些沒多大用的垃圾資料也被放置到配置服務器上，給配置管理人員帶了很多麻煩。因此我建議（展望未來）在項目一開始，就要讓項目成員認識到版本管理的好處。對源碼的管理，要保證書寫代碼的規范性，強化注釋力度，還應作好build和relase工作.