案例一

趙曉東是海正公司的員工，最近感到很煩惱。公司簽下了一份價值超過100萬的合同，由于雙方老板關系密切，都希望項目能夠盡快啟動，所以在簽訂合同時沒有舉行正式的簽字儀式。合同簽署后，公司老總立即指定趙曉東和其他8名員工組成項目組，趙曉東擔任項目經理。老總把趙曉東介紹給了客戶老總，并在業務部為他們安排了辦公室。

項目一開始進展順利，趙曉東及時與客戶老總溝通任何事情。但客戶老總經常很忙，經常不在公司。趙曉東想找其他部門的負責人，但他們要么推說自己無法決定，要么表示這與他們無關，甚至有人根本不知道這件事。問題得不到及時解決，很多手續也沒人簽字。

項目組內部也存在問題，一些程序員多次繞過趙曉東直接向老板請示問題；幾個程序員編寫的軟件界面不統一；每筆項目支出都需要財務部要求趙曉東找老板簽字。趙曉東頻繁給老板打電話，其他人心里想，趙曉東為什么總是拿老板來壓人。因此，趙曉東與項目組其他成員和財務部產生了不少摩擦，老板也開始懷疑趙曉東的能力。

趙曉東的遭遇相信很多項目經理都有過類似經歷，特別是剛開始服務行業客戶的公司。通常情況下，公司的老板和客戶單位的某個主管關系良好，或者業務人員關系處理得很到位，因此公司老板希望項目能夠盡快完成，常常會跳過項目啟動階段，直接指示項目經理進入實施階段。結果導致項目一開始就出現了各種麻煩。

趙曉東遇到了什么問題？

內部問題：

1、項目內部成員繞過項目經理直接向老總請示；

2、項目內部人員對建設標準出現不一致情況；

3、財務部要求趙經理找公司老總簽字以支出項目經費。

結果：

1、項目組成員、財務部人員與趙經理產生了摩擦；

2、公司老總懷疑項目經理的能力。

外部問題：

1、與客戶老總溝通的事情都受阻，因為老總很忙；

2、客戶部門負責人推托，沒有人簽署相關手續。

結果：

客戶端的工作無法正常開展。

做項目啟動的目的是什么？

建立項目管理制度、整理啟動會資料等。

1. 項目啟動會的任務有哪些？

闡述項目背景、價值、目標；介紹項目交付物；介紹項目組織機構及主要成員職責；讓雙方人員相互了解，清楚各個層次的接口；展示項目初步計劃與風險分析；介紹項目管理制度；說明項目將要使用的工作方式。

2. 在項目啟動時應該注重哪些問題？

3. 為什么說“好的開始是成功的一半”？

做項目啟動是為了形成一個良好的溝通體系，讓所有與項目相關的人都理解項目的重要性，同時形成一個由雙方老總、項目負責人和項目組成員構成的三級溝通體系，確保項目管理的暢通。

4. 在項目啟動時為什么要給項目經理授權？

案例二

A公司是國內領先的IT設備制造廠商，經過多年的企業信息化實踐，網絡基礎建設和辦公自動化建設已經具備相當的規模，并取得了良好的應用效果。同時，以ERP/SCM/CRM為主體的信息化應用架構也初步建成，此外作為提高產品創新能力的產品數據管理系統（PDM）也在建設當中。隨著公司研發業務管理的不斷深化，對產品研發的項目管理提出了更高的要求。雖然公司整體的研發項目管理體系尚未形成，但研發管理部門仍然希望將部分研發項目的核算用信息化手段來實現，以提高核算準確度。緊迫的需求提到了公司信息化項目部門的面前。

過去的幾年，公司在信息化建設方面的投入巨大，難免有一些急于上馬的項目投入與產出并不十分理想。而且由于市場環境的迅速變化，相應的業務模式也在不斷的改變，從而給信息化系統的適應性提出了相當高的要求。過去的有些項目啟動時期沒有很好地考慮到這些問題，造成一些項目盲目啟動、盲目建設，建成后才發現已經不適應業務的變化。因此，公司對于項目上馬的決策已經趨于理性，嚴格要求做好項目啟動前的論證工作。在滿足當前緊迫的業務需求和長遠的戰略需求之間作好平衡。確保項目建設的成功。

小王作為信息化項目部任命的項目啟動管理的負責人，著手處理該項目啟動前的可行性論證工作。小王發現，這個需求在年初規劃時并沒有提出項目意向，屬于規劃外的項目。在與業務部門的溝通中，他發現業務部門對于整體項目管理的模式并不十分清晰，目前需要解決的項目核算問題僅僅是項目管理中非常具體的一個需求，至于項目其它方面的管理，以及如何與產品開發過程結合起來，如何利用產品數據管理系統等，都沒有考慮。項目建設的系統只是一個項目管理的臨時解決方案。對方案的風險也沒有進行詳細的分析。而業務部門認為需求已經十分清晰，項目的價值也是毋庸置疑的，至于以后怎樣與研發平臺的產品數據管理系統結合起來，那要等立項后，做出了詳細的方案才會有答案。此外，業務部門還推薦了幾個產品供應商，希望能盡快選定產品，開展實施。

如果在立項環節出現延誤，影響了業務的開展，信息化項目部要承擔責任。小王認為業務的要求十分無理，需求、方案、投入產出、風險，以及業界的產品情況等很多問題都還沒有清楚，根本談不上選型。溝通過程中，業務人員對小王的工作極為不滿，向信息化項目部經理進行了投訴。

參考討論題：

1．在“部分研發項目的核算用信息化手段來實現”的問題上，雙方存在哪些分歧？

在這個案例中，反映了目前企業信息化項目啟動管理中的普遍問題。業務一旦產生信息化需求，總是非常急迫地希望能立刻上馬。而從信息化項目管理的角度，如果盲目、倉促地上馬信息化項目，往往導致項目的投入產出分析不清，項目重復建設，組織混亂，給后期的項目實施，項目維護，項目使用帶來極大的風險，甚至導致系統建成后被用戶棄用。最終使業務遭受損失。

本案例中，作為企業的信息化部門，在項目啟動管理的重要性方面已經有了較為理性的認識，但是在應用中不被業務部門理解，從而導致矛盾的激化。這是雙方對項目啟動管理的過程沒有達成統一的認識

2．在項目啟動階段形成統一的認知，對于實施信息化項目的企業有什么重要意義。

相對產品供應商而言，企業在項目建設中處于合同意義上的甲方，其項目的啟動過程與乙方的項目管理有很大的不同，是一個較為復雜的過程。它往往需要考慮一系 列的問題，如：需求是否合理？是否有必要啟動項目？項目可能帶來的影響是什么？可能的投入有多大？取得的效益有多大？當前的管理模式是否能支撐？如果不 能，可能要在哪些方面做好變革的準備？業界相關的產品有哪些？哪些是真正適合需求的？

因此，對項目啟動管理形成統一的認知，對于實施信息化項目的企業有著非常重要的意義。

3．在項目立項前應該做哪些方面的論證？

可行性方案的論證是項目啟動階段的關鍵活動，它的質量直接影響項目的實施效果。技術 成本 環境

4可行性分析的作用和目的是什么？

可行性研究的目的（1）技術的先進性和適用性（2）經濟上的盈利性和合理性（3）運行環境上的可能性和可行性

可行性研究的作用（1）為決策提供依據（2）可行性研究是項目設計的依據（3）項目評估的依據（4）為商務談判、簽訂有關合同協議提供依據

案例三

瑪吉、保羅和史蒂夫是一家咨詢企業的合伙人，他們專門為醫生設計和安裝計算機信息系統。這些系統通常包括對病人記錄、處方、帳單和醫療保險過程的處理。有時醫生有自己的人工系統并希望將其計算機化，有時他們需要升級和改進現有的計算機系統。

咨詢公司通常會購買必要的硬件和一些軟件包，然后根據醫生的具體要求定制軟件，并負責安裝整個系統。他們也會為醫生和辦公室員工提供培訓。這些項目的成本通常在10000~40000美元之間，具體取決于所需硬件的數量。大多數醫生愿意投資這筆錢，而不是再雇傭額外的辦公室員工來處理不斷增長的文書工作。

豪澤是保羅曾經為之做過項目的醫生之一，她放棄了自己的業務，加入了一個大型地區性診所。這個組織有6個辦事處和2家藥店，雇傭了總共200名員工。豪澤聯系保羅，詢問他的咨詢公司是否對升級該組織整個地區診所的信息系統感興趣，并是否愿意提交申請書。項目包括將6個辦事處和兩家藥店整合成一個系統，并且該組織最終將雇傭信息系統人員來監管系統的運行。目前每個辦事處都有自己的系統。

豪澤告訴保羅，其他醫生也有曾為大型咨詢公司工作的患者，他們也對這項工作感興趣。她說，來自6個辦事處和兩家藥店的代表們已經開始準備需求建議書，并且申請書必須在兩周內完成。她表示抱歉無法提供更多信息，因為她沒有機會像其他醫生一樣參加選擇大咨詢公司的討論。

保羅得到了需求建議書，并給瑪吉和史蒂夫做了幾份備份。他非常熱心于這次機會，并表示：“如果我們承接這個項目，我們將邁入全新的商業舞臺！這是我們一直期待的超越機會。”

1. 為什么這個小組沒有同時收到大型咨詢公司的需求建議書？

a. 采購經理并不了解保羅的咨詢公司，這就是他沒有接到RFP備份的原因；

b. 在該行業缺乏這個業務的成功案例和知名度。

2. 為什么這個小組會被考慮作為提交申請書的候選人？

豪澤醫生是保羅過去曾為之做過項目的醫生之一，可能認可保羅的能力和之前做得項目，并且豪澤醫生說，如果保羅感興趣，并能在兩周內提交申請書的話，她會讓采購經理給保羅一份RFP。結果保羅得到了RFP。

3. 在投標決策過程中，需要評價的因素有哪些？

競爭對手分析、風險分析、目標分析、聲譽與經驗分析、客戶資金分析、項目所需資源分析、客戶本身的資信問題。

4. 瑪吉、保羅、史蒂夫應當怎么做？解釋一下你的回答，表述一下3個小組成員每個人的想法。

這個小組成員應該就保羅獲得的這個項目的機會，使用SWOT 工具進行分析，對這個項目做評審，是否能夠獲取一定的利潤或者說即時沒有利潤，完全只是將這個項目作為企業業務能力的一次經驗積累和提升。

瑪吉的想法：想做，但沒有時間（不愿放棄目前現有客戶的項目）—缺少人力資源；

史蒂夫的想法：對公司是否有能力做好表示懷疑，底氣不足—缺乏成功案例的經驗；

保羅的想法：想做并且要做成功，把公司作強，這是未來生存的唯一出路，并且現在有資源，有能力—我們可以雇用幾個人。我有幾個朋友想做兼職。

如果我是這個組的成員，我會力挺保羅，并配合他完成這個項目。

案例四

王欣是一個政府部門實驗室的項目經理，負責高技術項目的研發工作。10個月前，他為項目起草了需求建議書，詳細說明了工作要求，并要求在項目結束時提交最終報告。項目計劃大約需要9個月完成，預計價值為145000元。

該項目有多家組織參與競標，其中大部分是高校。根據法律規定，合同必須授予符合資格且成本最低的投標者。最終，王欣將合同授予了一所大學，其投標價為131500元。根據他們的建議書，最終報告的編寫預計需要140頁，成本為13000元。

現在是項目的第8個月底，大學負責人通知王欣稱他們已經耗盡了項目資金，因此無法完成最終報告。然而，王欣是否應該再次撥付10000元給他們以完成最終報告呢？

王欣的合同條款中提到這種情況是非常頻繁發生的。政府可以采取法律行動，但這將導致額外的費用超過10000元。而且，如果政府在法庭上獲勝，該大學只需提交一個簡化的20-25頁報告作為最終報告。王欣詢問合同管理員是否可以在未來的競標中排除該大學，但被告知這樣做會限制競爭。

案例問題：

1．為什么會發生這種情況？

2．最初的合同是故意做得比較低嗎？

3．如果運用法律手段處理，誰將在法庭上獲勝？

4．如果他們在需求建議書中詳細地列舉了在最終報告中應該包括的條款，這樣會對政府有所幫助嗎？

5．你認為這種問題應該如何解決？

6．政府可以避免類似事件不再發生嗎？如果可以，怎么辦？

7．需求建議書中應該有一部分內容對政府以前的投標績效進行評價嗎？這合法嗎？

答：1.發生這種情況的根本原因在于合同中出現了關于資金問題的漏洞，投資方沒有在合同中明確規定資金使用的條件和標準，給對方可乘之機。

2.甲方最初只是為了廣泛招商，采取了降低成本等策略來減少投資預算，過于看重市場占有率和范圍，而忽略了合同本身對資金明確規定的重要性。作為項目管理的關鍵部分，合同應當縝密無懈可擊。

3.我認為不宜進行官司，問題出在自身合同漏洞上，應盡快加強管理，改善運營機制。打官司所需費用將超出10000元，并不劃算。事故發生后應以最小的代價解決問題。

案例五

風華電子CIMS需求開發歷程

（1）項目背景

風華電子與天劍公司簽訂了軟件集成開發合同，旨在上馬CIMS。根據合同要求，系統必須將MRPII/ERP思想引入，內容涵蓋企業的人力資源、財務、物流、供應鏈、質量、工藝等所有方面，并實現與條形碼的集成。技術上采用C/S架構，網絡操作系統采用Windows NT，數據庫系統采用SQL Server7。

（2）兩項基本工作

項目一開始，項目組面臨兩個主要問題：首先，企業信息化基礎薄弱。當時，一個年銷售額超過1億的500多人規模企業，只有兩部IBM微機，一部用于電子郵件收發，一部用于財務自編系統的運行。這種情況影響了已制定的項目實施計劃，原先計劃的主要步驟包括：調研、分析、設計、分批編碼、試運行、分批系統切換、總體集成、驗收。由于企業基礎較差，調研工作進展不理想，直接影響到其他工作。

項目組經過研究決定從培訓、考察、宣傳入手，在企業組織各類培訓，例如CIMS普及培訓、計算機基本操作培訓、漢字輸入培訓、先進管理思想培訓、企業流程培訓等；然后，組織風華電子的相關人員到其他企業學習、考察，親身感受信息化應用的效果。

此外，當時企業處于快速發展階段，組織機構和管理流程不斷變化，這可能導致軟件開發速度跟不上企業發展變化。有經驗的人員都知道，系統將陷入一種沒完沒了的修改之中。為應對這種情況，項目組從管理入手，通過對企業進行調研，將企業流程進行分類：第一類，可以確定下來的流程；第二類，可以變通的流程；第三類，有可能變化的流程，但變化的情況可以列舉；第四類，肯定會變，但不知道怎么變的流程。不同的流程在軟件設計中采用不同的解決辦法：第一、二類按正常的方法設計；第三類，采用參數控制法；第四類，細分業務單元，采用用戶流程自定義。

（3）建立需求管理工作機制

在進行需求分析時，天劍公司的開發人員抓住決策者最迫切和最關心的問題，引起重視。例如，整個CIMS系統開發初期，庫存管理是企業管理的重要組成部分，庫存的主要功能是在供給和需求之間建立緩沖，減緩供需矛盾。庫存作為生產、采購、物料需求計劃、銷售、成本的依據，保證庫存數據的準確性、完整性與及時性，是保證生產、財務、成本、銷售、采購等其他系統順利上線的關鍵，也是整個系統成功與否的關鍵。開發人員在開發過程中利用一切機會了解解決策者關心的問題，同時也讓他們了解項目的情況。在諸如專題匯報、協調會議、領導視察、階段性成果演示等過程中用簡短明確的語言或文字抓住領導最關心的問題，引導他們了解和重視項目的開發，當決策者認識到項目的重要性時，需求分析工作在人力、物力、時間上就有了保障。

建立組織保障，明確的責任分工。天劍公司成立了相應的項目組或工程組，包括：產品管理組、質量與測試組、程序開發組、用戶代表組和后勤保障組。產品管理組負責確定和設置項目目標，根據需求的優先級確定功能規范，向相關人員通報項目進展。程序管理組負責系統分析，根據軟件開發標準協調日常開發工作確保及時交付開發任務，控制項目進度。程序開發組負責按照功能規范要求交付軟件系統。質量與測試組負責保證系統符合功能規范的要求，測試工作與開發工作是獨立并行的。用戶代表組負責代表用戶方提出需求，負責軟件的用戶方測試。后勤保障組負責確保項目順利進行的后勤保障工作。

建立良好的溝通環境和氛圍。分析人員與用戶溝通的程度關系到需求分析的質量，因此建立一個良好的溝通氛圍、處理好分析人員與用戶之間的關系顯得尤其重要，針對用戶作為投資方會有一些心理優勢，希望他們的意見得到足夠的重視的特點，風劍公司的分析人員充分的認識到這一點，做好心了理準備，盡量避免與他們發生爭執。因為他們的目的是幫助用戶說出他們的最終需要。在溝通時分析人員注意做到：1）在態度上尊重對方，但不謙恭。2）努力適應不同用戶的語言表達方式。適應用戶的語言風格，理解他們的意思。3）善于表達自己，善于提問。4）利用工作外的交流來增進理解，加強溝通。

在需求調研和流程梳理順利完成后，天劍的開發團隊按計劃完成了需求分析任務，進入了軟件設計階段。

案例問題：

1. 本案例對需求開發工作有哪些成功的經驗？

2. 對于不確定和變化的需求，天劍的開發人員是如何處理的？

3. 對于用戶關心的問題，天劍的開發人員是如何處理的？

4. 對需求管理是如何建立組織保障的？

5. 為什么在進行溝通時要“在態度上尊重對方，但不謙恭”，請說明原因。

案例六

工期拖了怎么辦？

某公司計劃開發一個新軟件產品。在項目啟動的第一個月，項目團隊提出了一個初步的進度計劃，預計產品開發周期為12~18個月。一個月后，產品需求已經完成并得到批準，項目經理制定了一個為期12個月的詳細進度表。由于這個項目與以前的一個項目相似，項目經理在制定計劃時沒有讓技術人員參與，而是自行編寫了進度表并提交審核，以便技術人員專注于“真正的”工作（如設計、開發等）。每個人都很樂觀，都知道這是公司非常重要的一個項目。然而，沒有人真正重視這個進度表。公司要求盡早交付產品給客戶有兩個理由：1）為下一個財年創造收入；2）有利于確保主要客戶選擇這個產品而不是競爭對手的產品。團隊中沒有人對盡快交付產品產生懷疑。

在項目開發階段，許多技術人員認為計劃安排得太緊，沒有考慮節假日和新員工需要熟悉和學習的時間，而且計劃是按照最高水平的人員的進度安排的。除此之外，項目成員也提出了其他一些問題，但基本上都沒有得到相應的重視。

為了緩解技術人員的抱怨，計劃者將進度表中的計劃工期延長了兩周。雖然這不能完全滿足技術人員的需求，但這是必要的，可以在一定程度上減輕技術人員的工作壓力。技術主管經常說：產品總是在必須做的時候才做，所以才會有現在這么多事情要做。

計劃編制者抱怨說：項目中出現的問題都是由于技術主管沒有更多的商業頭腦造成的，他們沒有意識到為了擴大業務，需要承擔比較大的風險，技術人員不懂得做生意，我們不得不促使整個組織去完成這個進度。

項目實施過程中存在諸多爭議，商業目標與技術目標難以達成一致。為了趕進度，項目規格說明書匆忙完成，但提交評審時意見很多，只能勉強接受。由于前期分析階段拖延，進度大大緩慢，導致后續的編碼、測試計劃和交付物不斷修改，造成大量返工。

測試工作實際進度比計劃落后6周，為了趕進度，單元測試與集成測試被迫同步進行。然而，由于開發小組和測試小組同時進行測試，發現了大量錯誤，但對測試人員發現的問題響應遲緩。項目經理雖然強調了測試的重要性，并命令開發人員優先解決測試組提出的問題，但最終的代碼仍存在諸多問題。

如今項目進度已經拖后10周，開發人員加班過度，導致大家疲憊不堪，工作還未結束。如果按照目前的方式繼續下去，整個項目將比原計劃延遲4個月。

案例問題：

1．我們能從本案例中學到什么教訓？

2．邀請項目組成員參與編制計劃有哪些好處？

3．學習曲線對軟件項目有哪些影響？

學習項目管理包需要一定時間，因個人情況和經歷不同，所需時間也不同。對于不熟悉計算機和商業軟件的人來說，學習曲線會非常明顯。然而，由于軟件越來越易于使用，學習培訓時間大大縮短了。

4．編制進度計劃時需要考慮哪些重要因素？

項目網絡圖，項目活動工期的估算文件，項目的資源要求和共享說明，項目作業的各種約束條件，項目活動的提前和滯后要求。

5．一個成功的項目管理其基礎是什么？

案例七

小丁該怎么辦？

某系統集成公司目前有50多名員工，業務部門包括銷售部、軟件開發部、系統網絡部等。在經過近半年的籌備后，公司的銷售部在今年一月份與某銀行簽訂了一個銀行前置機軟件系統的項目。根據合同規定，系統必須在6月28日之前投入試運行。銷售部在簽訂合同后將項目移交給了軟件開發部進行實施。項目經理小丁在系統分析和設計方面有5年的工作經驗，但這是他第一次擔任項目經理。小丁兼任系統分析工作，項目組還有2名有1年工作經驗的程序員，1名測試人員，以及2名負責組網和布線的系統工程師。所有成員都全程參與項目。在接手項目后，小丁組織團隊制定了項目的WBS，并根據以往經驗制定了本項目的進度計劃，簡要描述如下：

1、應用子系統

1）1月5日～2月5日需求分析

2）2月6日～3月26日系統設計和軟件設計

3）3月27日～5月10日編碼

4）5月11日～5月30日系統內部測試

2、綜合布線：2月20日～4月20日完成調研和布線

3、網絡子系統：4月21日～5月21日設備安裝、聯調

4、系統內部調試、驗收

1）6月1日～6月20日試運行

2）6月28日系統驗收

在春節后的2月17日，小丁發現系統設計剛剛開始，由此推測3月26日很可能無法按時完成系統設計。請問問題發生的可能原因，小丁應該如何保證項目整體進度不拖延？

案例問題：

1． 請分析導致項目進度拖延的原因有哪些？

2． 作為技術人員轉為管理人員，擔任項目經理的小丁應該關注哪些問題？

3． 小丁在控制進度計劃方面應該采取什么措施？

4． 小丁應該采取哪些管理措施來確保項目整體進度不被拖延？

【問題1】

（1）銷售部未及時讓軟件開發部參與項目早期工作，導致需求分析耗時過長；

（2）項目經理首次擔任，經驗不足，進度估算不準確；

（3）項目資源配置不足，項目經理兼任系統分析，缺乏專門的系統分析和設計人員；

（4）工作安排未充分利用分配的項目資源，導致資源閑置；

（5）在安排進度時可能未考慮法定節假日的因素。

【問題 4】

（1）向職能經理申請增加特定資源，特別是增加系統分析設計人員；

（2）將部分階段的工作改為并行進行，以節約時間；

（3）臨時加班/趕工，盡可能補救耽誤的時間；

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

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

（6）加強對階段性工作的檢查和控制，避免后期出現返工。

此外，如有可能還可采取外包和縮減范圍等辦法，不過不建議在本案例中采用。

需要推薦靠譜PMP/軟考/NPDP/CSPM機構的同學可以關注我后臺回復【推薦機構】

備考資料分享如下：