e3 Harold Kerzner 項目管理 v12
10.1 項目發起人
PMBOK ® 指南,第6版
第13章 項目相關方管理
二十多年來,項目所涉及的高級管理者一直擔任項目發起人的職能。
項目發起人通常來自高級管理層,他們負責維護高層管理者與客戶的合同關係。發起人要保證來自承包商的信息正確傳輸給客戶,即信息從承包商到客戶沒有被遺漏,高層管理者要保證客戶的錢不會被亂用。項目發起人通常會將有關項目成本和可交付成果的信息傳遞給客戶,而進度信息和績效數據則來自項目經理。
除了高層管理者與客戶的合同關係,發起人還要在以下幾個方面提供指導:
• 目標的制定。 • 項目主計劃。
• 優先權的設定。 • 前期規劃。
• 項目組織結構。 • 關鍵人員配置。
• 項目方針和程序。 • 監測執行情況。
• 衝突的解決。
10.1.1 發起人與項目的界面
項目所處生命週期的不同,項目發起人的角色也會不同。在項目的規劃或啟動階段,發起人是一個主動的角色,主要進行下列活動:
• 幫助項目經理制定正確的項目目標。
• 在項目執行過程中為項目經理提供可能影響其進程的環境或政治信息。
• 制定項目的優先級(個人決策或者同其他高層管理者協商),將項目的優先級通知項目經理的同時並告知原因。
• 對需要提供治理的項目,指導建立方針和程序。
• 作為高層管理者與客戶合同的關鍵人物行使職責。
在項目啟動階段或開始階段,項目發起人必須主動地參與項目目標和優先級的設立。但是,高層管理者如果要求在業務部門和技術部門也建立優先級,就太過於強制了。
在項目的執行階段,項目發起人的角色由主動變為被動。如果項目經理需要的話,發起人將提供除了一些例行情況簡報以外的其他幫助。
在項目的執行階段,項目發起人必須有選擇性地參與解決問題。試圖干預每一個問題不僅不能幫助實現宏觀管理,還會降低項目經理解決問題的能力。
從某種角度而言,發起人就像仲裁人一樣。表10-1表明了在成熟組織和不成熟組織中項目經理和部門主管的工作關係。當在項目—直線界面存在衝突或問題並且在該層次無法解決時,發起人就應該介入並提供幫助。表10-2介紹了項目發起人介入項目的成熟做法和不成熟做法。
圖10-1 項目—直線界面

圖10-2 高層管理者界面

續表

10.1.2 發起人的職責
項目發起人要為項目中的每一個成員服務,包括部門主管和員工,這一點是應該理解的。項目發起人應該保持一種開放的方針,即使這種方針會有不利影響:首先,員工會因為大量的瑣事尋求項目發起人的幫助。其次,員工可能認為他們可以越過領導層而直接同項目發起人進行交談。這裡的行為準則是指鼓勵包括項目經理在內的員工要經常思考在什麼情況下他們的做法是合適的。
項目發起人除了正常的工作外,當項目需要時,必須能夠提供必要的幫助。發起人做的是一項很耗時的工作,尤其是出現問題的時候。因此,高層管理者要限制他負責發起的項目的數量。
高層管理者在一些問題上能立即履行發起人的職能,這些問題包括:
• 導致問題解決拖延的決策。
• 引起難以解決且影響決策的政策問題。
• 必要時不能決定項目的優先級。
當組織的項目管理能力走向成熟時,高層管理者開始相信中層或低層的管理者,並讓他們擔任項目發起人。這樣做主要有以下幾個原因:
• 高層管理者沒有足夠的時間擔任每一個項目的發起人。
• 並不是所有項目的發起人都要求由高層管理者擔任。
• 中層管理者與項目工作關係更密切。
• 中層管理者能更好地應對某些風險,並提出相關建議。
• 項目團隊成員更容易與中層管理者溝通。
在多元化的大公司中,高層管理者有時忙於戰略規劃,以致沒有足夠的時間擔任項目發起人。這種情況下,發起人就會由低級別的管理人員擔任。
圖10-1表明了項目發起人的主要職能。項目啟動時,發起人要開會決定該項目是否應獲得高優先級。如果項目是關鍵的或是戰略性的,委員會就指派一名高級經理擔任發起人,也許他就是委員會的一名成員。指導委員會的人擔當由指導委員會監察項目的發起人是常有的事。

圖10-1 項目發起人
對於那些常規的、維護性的、不關鍵的項目可以委派一箇中層管理者擔任發起人。讓中層管理者擔任發起人,能提升中層人員的認同感。
並非所有的項目都需要發起人。只有在項目需要大量資源,或需要較多職能部門參與,或存在潛在的破壞性衝突,或需要與客戶保持良好的溝通時才需要發起人。例如,客戶通常希望確保承包商的項目經理能謹慎使用資金。所以,客戶會希望高層管理者擔任項目的發起人,監督項目經理的資金使用情況。
經常參與招投標的公司不僅會在它們的投標書中介紹項目經理的經歷,還會強調發起人的閱歷。在其他條件相同時,這會使投標者更具競爭優勢。因為,客戶認為他們現在有一個與高層管理者溝通的直接渠道。承包商認為高層管理者擔任項目發起人需要履行的職能:
• 主要參與銷售和合同的協商。
• 建立和維護與重要客戶的關係。
• 幫助項目經理順利地開展項目(規劃、程序、人員配置等)。
• 瞭解項目主要活動的進展信息(接收項目信息報告、參加項目評審會議、定期審查項目等)。
• 處理重大合同問題。
• 為項目經理解釋公司方針。
• 幫助項目經理識別和解決主要問題。
• 傳達總經理和公司管理層對主要問題提出的建議。
10.1.3 現今的項目發起人
一直以來,發起人只需要與項目經理溝通,中小型項目尤其如此。現在,我們做的項目越來越複雜,需要發起人和整個項目團隊溝通。因此,項目發起人的角色被賦予了以下新的責任:
• 在項目過程中與整個項目團隊保持緊密聯繫。
• 準備並簽署項目章程。
• 確保項目經理在整個項目過程中都有做出決策的相應權力。
• 確保項目的優先級合適。
• 向項目團隊解釋項目優先級確定的原因。
• 制定項目的商業目標和技術目標。
• 確保所有的截止日期都是可達到的。
• 重申截止日期的重要性。
• 解釋能夠對項目產生影響的企業環境因素和政治因素。
• 在設計項目組織結構時提供幫助。
• 為項目制訂應急資源計劃。
• 為項目具體的方針和程序的制定提供指導。
• 為其他高級管理層提供關鍵的項目狀態信息。
• 陳述他們對項目經理和團隊的期望。
• 作為終身學習的一部分,說明他們希望項目經理擁有或提升的技能。
• 解釋如何處理專利。
• 制定項目範圍變更流程。
• 為缺乏經驗的項目經理提供幫助。
• 提出建設性反饋而不是針對某個人提出批評。
• 各參與方的溝通橋樑。
• 不論是好的信息還是壞的信息,都鼓勵報告,但不過分渲染壞消息。
• 及時發現項目團隊是否承受過大的壓力。
• 瞭解文檔工作的成本。
• 採取走動式管理(Walk-the-Halls Management)。
• 安撫憤怒的客戶。
• 建立認同或獎勵制度,即使不是金錢獎勵制度。
• 堅持對整個項目團隊而不是項目經理實行開放政策。
10.1.4 多項目發起人
可以考慮將項目分解成兩個生命週期階段:規劃階段和實施階段。對於短期項目(通常2年或更短)而言,建議這類項目只派遣一個項目發起人。但對長期項目(如5年甚至更長)而言,則建議在不同的項目生命週期階段派遣不同的項目發起人,但這些發起人最好來自同一個管理層。項目發起人不一定來自與項目工作有關的直線組織,有的公司甚至會要求發起人來自與項目無直接利益的直線組織。
項目發起人實際上就像項目經理的“大哥”或指導老師。在任何情況下,項目發起人都不應該行使項目經理的職能。項目發起人應該協助項目經理解決那些項目經理自己不能解決的問題。
10.1.5 看不見的項目發起人
在有些行業,如建設業,項目建議書中就明確了項目發起人,因此項目發起人是可見的。遺憾的是,有些情況下項目發起人是“隱藏”的,項目經理不知道誰是項目發起人,或者不清楚客戶是否知道誰是項目發起人。看不見的發起人常見於高級管理層,也被稱為缺席的發起人。
看不見的項目發起人經常發生於以下幾種情形中。第一種是被任命為項目發起人的經理拒絕擔任發起人,因為他們害怕自己的決策失誤或項目的失敗會對他的事業造成負面影響。第二種是被任命的項目發起人既不瞭解發起人該承擔的職責,也不瞭解項目管理的理論,認為項目發起人僅需要提供簡單的服務。第三種是被任命的發起人工作量過多,沒有足夠的時間履行項目發起人的義務。第四種是項目經理排斥項目發起人,拒絕向項目發起人彙報有關的項目進展信息,導致項目發起人認為項目進展順利,不需要他的參與。
有的人認為較好的應對方式:項目經理先做決策,然後遞交給發起人相關的備忘錄,備忘錄上可以這樣寫“這是我做出的決策,除非我在 48小時內聽到你的答覆,否則我會認為你同意了我的決策”。
事實上,還有的項目發起人喜歡進行微觀管理。有的人認為應對這種情況的較好方式是讓項目發起人處於極其忙碌的狀態,以期項目發起人能自行離開。
遺憾的是,這樣做的結果可能使得項目發起人更加堅信自己的做法是正確的。我認為對於喜歡微觀管理的項目發起人,可以要求角色界定。項目經理應該盡力與項目發起人一起界定項目經理和項目發起人各自的職責。
相比看不見的項目發起人和專橫的項目發起人而言,更糟糕的是“不會說不”的項目發起人。當項目發起人不斷地對客戶說“是”時,執行組織中的每個人最終都會受到傷害。
有時候項目發起人的存在會弊大於利,尤其當項目發起人圍繞一個錯誤的目標做決策時更是如此。
有一個理解項目管理而不是簡單幫助決策的項目發起人是有必要的。項目發起人的目標不僅要與整個項目的目標一致,而且這些目標還要是現實的。如果發起人來自高級管理層,發起人必須是可見的,且隨時瞭解項目的進展狀況。
10.1.6 跨國的項目發起人與相關方
全球項目的跨國溝通,明顯會存在許多不可預測因素,這些不可預測因素能對項目造成直接的影響。更糟糕的是,全球項目的實施環境相當複雜,受到社會政治因素的高度影響。與全球項目相關方溝通的要點包括:
• 並不是所有的項目相關方都可以識別出來。
• 顯然,全球項目的相關方數量比非全球項目的相關方數量多。
• 全球項目的相關方在項目持續期內變化得更快。
• 相比可預見的全球項目相關方而言,未識別出的相關方的級別可能更高。
• 並非所有與全球項目相關方有關的問題都可以識別出來。
• 全球項目的某些問題可能需要比全球相關方更高級別的人員參與解決。
• 與相關方有關的問題,非全球項目的解決方案並非適合全球項目使用。
• 與非全球項目相關方相比,全球項目的相關方日程安排更復雜。
• 與非全球項目相關方相比,全球項目的相關方需要採用不同的衝突解決模式。
Aaltonen 和Sivonen在文章[1] 中討論了全球項目相關方的各種衝突解決模式,如下:
• 接受 接受相關方的原則、方針和程序。
• 妥協 協商與對話。
• 迴避 放棄與相關方之間的合同。
• 駁回 不理會相關方的需求。
• 影響 積極地改變相關方的需求。
新興市場國家的項目相關方管理與其他市場是不一樣的。在全球項目中,熟悉項目相關方的文化背景這一點至關重要。
10.1.7 委員會發起人
多年來,很多公司一直採用委派一個人承擔某個項目的發起人。這樣做的風險在於:發起人因對直線組織表示偏愛而做出次優的決策。現在,有的公司開始考慮由委員會來擔任項目發起人。
在負責協同設計與縮短產品開發時間的組織中,委員會發起人非常常見。委員會的成員由中層管理者組成,來自市場營銷、研發和運營等部門。這種做法的好處是委員會的決策比個人決策對公司更有利。
委員會發起人也有其侷限性。在高級管理層,幾乎很難找到所有高層經理們可以同時碰面的時間。委員會發起人不太適合項目眾多的公司。
當項目出現危機,項目經理可能需要及時與發起人聯繫。如果發起人是委員會,項目經理如何以最少的時間召集委員會成員?當然,個人擔任項目發起人比委員會的反應更迅速一些。如果委員會中的某一個成員擔任某個項目的主要發起人時,委員會就能很好地發揮作用。
10.1.8 什麼時候尋求幫助
項目經理可以用亮紅燈、黃燈或綠燈的方式介紹項目的狀態。這就是所謂的“交通燈”報告系統。對狀態報告的每一個元素,項目經理可以根據下面的準則啟動三盞燈中的一盞:
• 綠燈——工作按計劃進行,發起人不必參與。
• 黃燈——存在潛在問題,發起人要知情,但不必採取行動。
• 紅燈——存在可能影響時間、成本、範圍或質量的問題。發起人需要進行干涉。
黃燈是警告,應該由中層及下層管理者來解決。
如果項目經理亮的是紅燈,發起人應該積極地參與進來。紅燈就意味著項目的時間、成本或者績效會受到影響,必須儘快做出決策。發起人的主要職能是幫助及時制定最好的決策。
項目經理和發起人不主張員工出了問題來找他們,除非員工能同時提供備選方案或建議。通常,一旦員工們制定了備選方案或建議,他們自己就能解決大部分問題。
好的企業文化鼓勵員工儘快提出問題,尋求解決方案。越快發現問題,越快解決問題。
有的公司採用不止3種顏色來表示項目的狀態。有一家公司除了用上面定義的紅燈、黃燈和綠燈外,還有一個橘黃燈。橘黃燈代表項目工作在目標里程碑日期之後仍在執行。
10.1.9 高層管理者的新角色
當項目管理成熟時,高層管理者會授權給中層及下層管理者。高層管理者擔任的新的角色:
• 為優秀的項目管理人員建立中心機構。
• 建立項目管理辦公室或項目管理職能中心。
• 建立項目管理職業發展路徑。
• 為新任命的項目經理建立指導程序。
• 成立一個專門管理最優方法的部門,為組織內的其他部門服務。
• 為風險管理提供戰略信息。
由於進度緊張給項目經理帶來的壓力,使得風險管理技能成為項目經理必備的管理技能。高層管理者會發現有必要為項目管理提供戰略型商業人才,幫助識別風險、評估風險及選擇風險處理的優先次序。
10.1.10 主動參與與被動參與
在委派項目發起人時,高級管理層面對的一個問題是項目發起人應該是項目的既得利益者還是獨立的第三方。表10-3說明了這個問題的正反兩方面。在項目中沒有既得利益的發起人似乎更像一個離場擁護者,而不是項目發起人。
圖10-3 有沒有既得利益

10.1.11 管理範圍蔓延
PMBOK ® 指南,第6版
5.6 控制範圍
以技術為導向的團隊成員不僅希望達成產品的規格要求,還希望提供更高規格要求的產品。但是,更高的規格意味著更高的成本代價。項目經理必須控制變更,制定出相應的計劃控制範圍變更。如果範圍蔓延是由項目經理引發的,該怎麼處理?項目發起人必須同項目經理定期保持密切聯繫,檢查項目範圍基準是否變化,檢查項目是否存在未經授權的變更,檢查是否存在由範圍變更引起的成本增加。
10.1.12 高層管理的擁護者
變更的實施需要高層管理者的擁護。例如,在公司中推行項目管理。高層管理的擁護者能促使項目管理從上到下徹底實施,讓成員迅速接受項目管理這種方法體系,因為高層的參與意味著高層的支持和興趣。
10.1.13 失敗的項目治理
僅僅因為項目治理委員會的成員來自高級管理層,就認為他做的所有決策都是正確的,這是一種錯誤的想法。與其他人一樣,高層管理者也會犯錯誤。即使由於治理的失敗導致項目的失敗很少見,但是治理失敗造成的損失遠遠大於項目經理決策錯誤造成的損失。
由治理導致項目失敗的原因包括:
• 未總結項目的經驗教訓,或者治理委員會不清楚之前的治理委員會的做法。
• 拒絕聆聽項目經理的建議。
• 基於政治而非項目做出決策。
• 決策的制定不考慮對其他項目造成的影響。
• 在項目中期更換相關方。
• 拒絕中止可能失敗的項目。
• 治理方式過於細緻。
• 未經過商業論證。
隨著治理委員會需求的增加,我們也要識別出新的風險。治理委員會的成員可能並不完全瞭解項目管理的實質。這樣做的後果是委員會做出的決策看上去有利於項目,實際上對項目管理是不利的。例如,影響大的範圍變更導致現有資源的重新安排以及人員的重新配置。