項目干系人目標不一致是導致絕大多數項目失敗的主要原因。

　——經驗總結

4.1?? 項目失敗最大風險：目標模糊

目標管理是項目管理的核心思想之一，明確并統一項目目標是項目管理的首要任務。目標是前進的方向，是團結的旗幟，項目的一切活動都圍繞項目目標展開。任何項目的目標都是由項目的一個或幾個干系人因為某些原因提出來的，由于每個人的知識范圍、語言、文化、性格等存在差異，導致每個人對項目目標的理解和期望迥異，所有項目的目標既有顯性目標，又有隱性目標，往往隱性目標卻又是真正的目標。高效挖掘隱性目標并把項目干系人統一到同一目標上是優秀項目經理必備的能力之一。

項目的大目標多數都是模糊的，準確識別真正的項目目標是項目成功的基礎。只有對該目標進行分解并逐一細化，并不斷調研分析，“漸進明細”，才能確定真正的目標。一個真正的項目目標必須符合“SMART”標準，即：

S—Specific（明確的）

M—Measurable（可測量的）

A—Action-oriented（行動導向的）

R—Realistic（務實的）

T—Time-related（有時間期限的）

例如建筑項目：為某企業蓋一棟樓是一個項目的大目標，但大樓究竟要做什么用（寫字樓、教室、住宅還是縮微景觀），建在什么地方，什么材質，長寬高的要求，什么外形，防震等級要求，準備什么時候投入使用等等，必須用建筑學的知識進行詳細分析，與相關干系人多次交流調研，才能確定“蓋一棟大樓”的真正目標。

再例如軟件項目，新編一套財務報銷系統。該系統都能報銷哪些科目，是只報銷市內、國內的差旅費用，還是包含出國的差旅費用？如果要實現出國差旅費用報銷，就還有匯率結算的問題，并且我們知道匯率是隨時間不斷變化的，差旅標準是否因之改變呢？還有在填單據的時候，是否允許代替別人報銷？是否分多個頁面分步填寫？圍繞著實現“財務報銷系統”這個大目標，有諸多更詳細的小目標，這些小目標不是一下就能明確的，需要“漸進明細”。

但如果老板給你下達一個任務：“明天你到火星上打一瓶礦泉水來”，盡管目標具體，有時限，可測量，并且行動導向，但顯然不務實，這不是一個真正的目標。

由于有些項目的目標過于龐大而復雜，各種原因（技術、規模）限制項目目標難以短時間內完全明確，為了縮短工期，往往在部分目標明確后就開始實施，在實施過程中進一步對目標“漸進明細”，這類項目的風險就極高。例如航天項目（探月工程、登陸火星等）、全新產品的研發（新藥、新軟件、新車等等）等，規模越大，周期越長，風險越大。

4.2?? 需求調研：搜集與分析

項目提出者的不同項目干系人的需求構成了項目的目標，全面深入挖掘干系人的需求需要調研：調查并研究，即需求搜集與分析。需求搜集與需求分析一定要同步進行，因為二者相輔相成：“挖出蘿卜帶出泥”，收集需求時需要不斷分析才能根據需求的相互關系搜集更多需求，使得需求充分而完整；“管中窺豹，只能見一斑”，“盲人摸象，必然不全面”，由于人手和工具方法的局限性，收集的需求總是有限的，有限的需求往往只能分析出有限的結果，收集的需求越多才能保證需求分析得更徹底更全面，這是最終交付的項目成果設計合理性的基礎。

全面收集干系人需求的前提是對干系人的準確識別，關于如何識別干系人，將在《干系人管理》章節中再述。常用的收集需求的方法有訪談、焦點小組會議、引導式研討會、群體創新、群體決策、問卷調查、觀察、原型法、集中討論、專家代表、調研搜集與干系人基本目標相一致的各類資料、調研搜集以往同類項目資料等等方法。

1．訪談 訪談是一種通過與干系人直接交談，來獲得信息的正式或非正式方法。訪談的典型做法是向被訪者提出預設和即興的問題，并記錄他們的回答。通常采取“一對一”的形式，但也可以有多個被訪者和/或多個訪問者共同參與。訪談有經驗的項目參與者、干系人和主題專家，有助于識別和定義項目可交付成果的特征和功能。

2．焦點小組會議 焦點小組會議是把預先選定的干系人和主題專家集中在一起，了解他們對所提議產品、服務或成果的期望和態度。由一位受過訓練的主持人引導大家進行互動式討論。焦點小組會議往往比“一對一”的訪談更熱烈。

3．引導式研討會 通過邀請主要的跨職能干系人一起參加會議，引導式研討會對產品需求進行集中討論與定義。研討會是快速定義跨職能需求和協調干系人差異的重要技術。由于群體互動的特點，被有效引導的研討會有助于建立信任、促進關系、改善溝通，從而有利于參加者達成一致意見。該技術的另一好處是，能夠比單項會議更快地發現和解決問題。例如，在軟件開發行業，就有一種被稱為“聯合應用開發（或設計）（Joint Application Development，JAD）”的引導式研討會。這種研討會注重把用戶和開發團隊集中在一起，來改進軟件開發過程。在制造行業，則使用“質量功能展開（Quality Function Deployment，QFD）”這種引導式研討會，來幫助確定新產品的關鍵特征。QFD從收集客戶需求（又稱“顧客聲音”）開始，然后客觀地對這些需求進行分類和排序，并為實現這些需求而設置目標。

4．群體創新技術 可以組織一些群體活動來識別項目和產品需求。下面是一些常用的群體創新技術：?

頭腦風暴法。用來產生和收集對項目需求與產品需求的多種創意的一種技術。?

名義小組技術。通過投票來排列最有用的創意，以便進行進一步的頭腦風暴或優先排序。名義小組技術是頭腦風暴法的深化應用。?

德爾菲技術。由一組選定的專家回答問卷，并對每一輪需求收集的結果再給出反饋。專家的答復只能交給主持人，以保持匿名狀態。?

概念/思維導圖。把從頭腦風暴中獲得的創意，用一張簡單的圖聯系起來，以反映這些創意之間的共性與差異，從而引導出新的創意。?

親和圖。這種技術可以將大量創意分類，以便審查和分析。

5．群體決策技術 群體決策就是為達成某種期望結果而對多個未來行動方案進行評估。群體決策技術可用來開發產品需求，以及對產品需求進行歸類和優先排序。達成群體決策的方法很多，例如：?

一致同意。每個人都同意某個行動方案。?

大多數原則。獲得群體中50%以上的人的支持。?

相對多數原則。根據群體中相對多數者的意見做出決定，即便未能獲得一部分人的支持。?

獨裁。某一個人為群體做出決策。

在需求收集過程中，幾乎可采用上述任何一種決策方法進行群體決策。

6．問卷調查 問卷調查是指通過設計書面問題，向為數眾多的受訪者快速收集信息。如果受眾眾多、需要快速完成調查，并想要使用統計分析法，就適宜采用問卷和/或調查方法。

7．觀察 觀察是指直接觀察個人在各自的環境中如何開展工作和實施流程。當產品使用者難以或不愿說明他們的需求時，就特別需要通過觀察來了解細節。觀察，也稱為“工作跟蹤”，通常由觀察者從外部來觀察使用者的工作。觀察也可以由“參與觀察者（Participant observer）”進行。“參與觀察者”需要實際執行一個流程或程序，體驗該流程或程序是如何實施的，以便挖掘出隱藏的要求。

8．原型法 原型法是指在實際制造產品之前，先造出該產品的實用模型，并據此征求對需求的反饋意見。原型是有形的實物，它使干系人有機會體驗最終產品的模型，而不是只討論抽象的需求陳述。原型法符合漸進明細的理念，因為原型需要重復經過制作、試用、反饋、修改等過程。在經過足夠的重復之后，就可以從原型中獲得足夠完整的需求，并進而進入設計或制造階段。

不同行業需求分析的方法不同，這是一個偏重行業技術的工作，像軟件行業常用的分析方法有大綱分類分析、業務流程分析、活動場景分析、時序圖分析、優先級分析、可行性分析、需求關聯關系分析等等，在此不再詳述。

4.3?? 分解并定義目標

創建工作分解結構（Work Breakdown Structure ，簡稱WBS）是項目管理用于分解并定義目標的方法。創建WBS是把項目可交付成果和項目工作分解成較小的、更易于管理的組成部分的過程。WBS是以可交付成果為導向的工作層級分解，其分解的對象是項目團隊為實現項目目標、提交所需可交付成果而實施的工作。WBS每下降一個層次就意味著對項目工作更詳盡的定義。WBS組織并定義項目的總范圍，代表著現行項目范圍說明書所規定的工作（見圖5-6和圖5-7）。計劃要完成的工作包含在WBS底層的組成部分中，這些組成部分被稱為“工作包”。可以針對工作包安排進度、估算成本和實施監控。在“工作分解結構”這個詞中，“工作”是指經過努力所取得的成果，如工作產品或可交付成果，而非“努力”本身。圖5-6顯示了創建工作分解結構過程的輸入、工具與技術和輸出，圖5-7概述了本過程的基本數據流向。

分解就是把項目可交付成果劃分為更小的、更便于管理的組成部分，直到工作和可交付成果被定義到工作包的層次。工作包是工作分解結構的底層，是能夠可靠地估算和管理工作成本和活動持續時間的位置。工作包的詳細程度因項目大小與復雜程度而異。要把整個項目工作分解成工作包，一般需開展下列活動：

u? 識別和分析可交付成果及相關工作；

u? 確定工作分解結構的結構與編排方法；

u? 自上而下逐層細化分解；

u? 為工作分解結構組成部分制定和分配標志編碼；

u? 核實工作分解的程度是必要且充分的。

圖5-8顯示了某工作分解結構的一部分，其中若干分支已經向下分解到工作包層次。工作分解結構可以采用多種形式，例如：把項目生命周期的各階段作為分解的第一層，把產品和項目可交付成果放在第二層，如圖5-9所示；把主要可交付成果作為分解的第一層，如圖5-10所示；按子項目進行第一層分解。子項目（如外包工作）可能由項目團隊之外的組織實施。然后，作為外包工作的一部分，賣方需編制相應的合同工作分解結構。

對工作分解結構上層的組成部分進行分解，就是要把每個可交付成果或子項目都分解為基本的組成部分，即可核實的產品、服務或成果。工作分解結構可以采用列表式、組織結構圖式、魚骨圖式或其他方式。通過確認工作分解結構下層的組成部分是完成上層相應可交付成果的必要且充分的工作，來核實分解的正確性。不同的可交付成果可以分解到不同的層次。某些可交付成果只需分解一層，即可到達工作包的層次，而另一些則需分解更多層。工作分解得越細致，對工作的規劃、管理和控制就越有力。但是，過細的分解會造成管理努力的無效耗費、資源使用效率低下以及工作實施效率降低。對于建筑行業，多數采用40小時法則，即把工作包細化到其活動持續時間約40小時即可；而軟件項目則多采用8小時（或1人天）法則，把工作包細化到其活動持續時間約8小時，1人天的工作量；而某些明確而又緊迫的工作任務，可能會細化到1小時或者幾分鐘，例如銀行的核心業務系統新版本更新的上線項目。這些都是在實踐中的一些經驗，推薦參考，而不是絕對的標準。工作包肯定要符合“SMART”準則，但不一定是以“SMART”為準則細化的最小單元。工作包細化的程度達到“能夠可靠地估算和管理工作成本和活動持續時間，使項目可控”即可。

要在未來遠期才完成的可交付成果或子項目，當前可能無法分解。項目管理團隊通常要等到這些可交付成果或子項目的信息足夠明確后，才能制定出工作分解結構中的相應細節。這種技術有時稱做滾動式規劃。工作分解結構包含了全部的產品和項目工作，包括項目管理工作。通過把工作分解結構底層的所有工作逐層向上匯總，來確保沒有遺漏工作，也沒有增加多余的工作。這有時被稱為100%規則。

4.4?? 統一干系人的目標

目標不一致是多數項目失敗的主要原因，統一項目目標是項目經理的核心工作之一。由于項目對每個干系人的利益影響有差異，每個干系人的知識范圍、語言、文化、性格及智商等有差異，使得同一項目中每個干系人的目標都不一致：既有對交付成果具體屬性標準的期望差異，也有對實現交付成果方式方法的期望差異。

例如在建筑工程項目中，建造任何一棟大廈，設計者都須綜合考慮該大廈的建設發起方、未來用戶以及其他干系人的不同期望目標，如用途要求、風格要求、抗震要求、通風要求等等，設計圖紙并建立模型，交付發起方進行討論、專家論證，最終確定該大廈的交付標準。這就是一個明確目標、統一目標的過程。像奧運主體場館——鳥巢，當初的設計方案就是向全球征集，經過多輪專家論證后才確定下來——因為這是公共項目，不僅僅是幾個項目干系人的目標統一，而是幾乎全民性的，因此需要很多業界各類專家共同論證。

而軟件項目，尤其是應用軟件項目，涉及的項目干系人多且對目標的要求繁雜不一，項目因目標不統一而造成失敗的風險極大。相比而言，建筑的方法論已經基本成熟，如果沒有設計圖，沒有明確的模型標準，建筑項目不會開工，而軟件項目，尤其受“敏捷”思想影響較大的當代軟件開發人員，用“成果”來摸索“目標”，邊開發邊與用戶研討確認，不符合用戶期望則改代碼重新來過，“前面修路，后面挖溝”，必然讓各個不同的目標引導得東倒西歪，暈頭轉向。這是很多軟件項目失敗的根本原因，尤其一些較為大型的軟件項目，就是因為尚未統一最終目標就開始了行動。借鑒建筑工程設計模型的思路，采用“原型設計”方法實施軟件開發項目被證明是一條最佳實踐。上一節講到需求搜集時已經對“原型法”有描述，盡管軟件是軟體，無法像生產制造那樣能造出棱角分明的原型，但一樣可以造出原型：在正式編碼前，將軟件最終展示給用戶的界面逐一設計好，并按照軟件功能邏輯順序將其組織起來，按照操作的先后次序逐一展示，并將每個界面對應的功能及約束要求用文字詳細描述，展示給最終驗收軟件產品的用戶，由其逐一確認，直到所有人對此達成共識，不再有異議，就形成了軟件的“原型”。

“設計模型”實際就是把各個干系人的目標由心中的期望轉化成了符合“SMART”標準的現實目標，項目干系人對此達成共識，并一一允諾（如果是有重大利害關系的項目，一定要有書面簽字承諾），這其實就是“明確目標，統一目標”的過程。切記：只有得到“確認”的目標才是項目要實現的目標，切不可自以為是的猜測目標就付諸實施，這樣的結果多數就是“出力不討好”——難以通過驗收。

項目經理對“統一目標”的意義一定要有深刻認識，在目標尚未統一的情況下，一定不能帶團隊盲目付諸項目的實施行動，此時唯一要做的行動就是與團隊成員一起盡快“統一項目目標”。

“統一項目目標”只是統一目標的第一步，紅軍二萬五千里長征的途中，遵義會議達成了這個目標，但直到紅軍到達陜北革命根據地之前，“前有堵截，后有追兵，內部還有破壞者”，如何將目標統一到每個項目執行者的心目中，統一人心，凝聚團隊力量，并識別敵友，爭取最多的支持者，一同達成項目目標是項目經理在從始至終的整個項目過程中都需要不斷努力的工作。

多數商務項目都有這樣的情況：項目提出者希望項目能如期保質保量地按照自己的期望實現；而他的“政敵”卻希望這個項目搞砸了乘此機會能扳倒他；項目的承包商更關心花費最低的成本完成該項目以獲得最高的利潤；監理方要確保項目按照質量、安全等標準如期正常進行；工程師關心的是多干活能不能多拿獎金，或者反正薪水都是固定的，干多干少一個樣，怎么才能少干點活；驗收人員之前跟承包商有過節，想盡辦法增加驗收標準的難度……，如此林林總總，導致項目實施過程中總是“一波未平一波又起”。項目規模越大，干系人越多，不同的行動目標就越多，作為項目經理，“統一項目目標”只是做到了“統一共識”，明確了方向，但還需要“統一力量”——使用各種方法手段使更多的人心歸屬到支持達成項目目標上，凝聚越多的支持力量，成功的把握性才越大。關于如何做到這一點將在《干系人管理》章節中進行詳述。

4.5?? 項目范圍控制

項目發起方的干系人根據自己的期望需求會分別提出不同的項目目標，所有這些目標綜合確定了項目的范圍。模糊的項目目標很容易導致項目范圍的擴散，如果想做好項目范圍的控制，就必須做到如下兩點：

一、全面搜集干系人的期望需求，并對所有需求進行綜合分析，根據SMART原則對每一個需求核實細化為真正的項目目標。

二、建立項目范圍變化控制管理機制，包括：范圍變化審核負責人，工作流程，必要的溝通工具。

隨著干系人的變化目標極可能隨之變化，由于項目目標的變化會涉及到不同干系人的利益，究竟是按照誰提的目標來執行，一般不是項目經理能獨斷的，需要納入各干系人共同認可的項目范圍變化控制流程進行統一管理。有經驗的組織一般在項目立項時就要由關鍵干系人（一般是合同雙方/多方具有財物、技術等確定權的領導人）成立項目管理委員會（Project Management Office，簡稱PMO，關于PMO的構成將在《項目組織結構》章節中詳述），遇到目標變化的情況項目經理可提交材料由PMO確定是否變更。對于內部項目，即使沒有明確的PMO，項目經理也要根據項目干系人的關系，按照“有限授權，逐級申請”的原則，確定虛擬的PMO，出現目標變化時由各個干系人共同商討確定。

相當多經驗欠缺的項目經理在遇到目標變化時會犯獨斷專行的錯誤：要么堅決的一口回絕客戶提出的新的要求，導致客戶不滿；要么軟弱的完全答應客戶提出的幾乎任何要求，致使項目無限期后延，導致老板不滿。前者是貿然擴大了自己的權力，后者是完全放棄了自己的權力，都屬于極端表現。在組織項目管理制度不完善的情況下，作為執行代理人，項目經理一定要跟上級請示清楚自己能決策的范圍，在實在難以說清楚的情況下，就以新增的工作內容是否會導致項目延期，是否超預算成本為標準：只要判斷不超，就可自行決斷，否則就請示上級領導來決策。

常用的項目范圍控制流程如下圖所示：

（圖需更新）

在項目啟動后，需要盡快調研項目需求，明確目標，并由各方共同書面確認（統一目標），定為項目范圍基線。對于此后在設計、實施等階段由各干系人提出的需求，均納入PMO確定的統一變更流程進行審批控制，對于確認通過的新需求，與原需求進行歸并，并形成新的項目范圍基線，同時據此更新項目計劃，依據新的計劃繼續實施項目。這將確保整個項目在受控范圍內實施。

無論什么項目，越早明確目標，確定項目范圍，項目就越容易控制，項目成功的機率就越高。強調三點：一、目標必須經關鍵干系人（不一定是目標提出者，但最好是項目驗收者）確認；二、目標務必符合SMART標準，否則即使有確認，但理解差異大，在交付驗收時必然是各執一詞；三、盡早確定范圍基線，避免沒有基線帶來的混亂變化影響項目的正常進展，把項目做成“無底洞”。項目目標是允許變化的，但變化必須受控——必須按照既定的流程規則由關鍵干系人共同管控。

4.6?? 小結

目標管理是項目管理的核心，直接決定了項目管理的成敗。“明確標準（SMART）—〉明確目標—〉統一目標—〉控制目標”是目標管理的4個關鍵步驟，任何一個環節出問題，都將導致項目工作要么“方向錯誤”，要么“徒勞無功”，要么“永無止境”，無論如何，都將導致有干系人不滿，使項目失敗。

總結

以上是生活随笔為你收集整理的目标管理是项目管理的核心思想之的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。