Project Sponsor &Stakeholder
Stakeholder：包括這樣的個人和組織,他們或者積極參與專案,或者其利益在專案執行中或者成功受到積極或消極影響。Stake”的直接翻譯是“籌碼”或“賭注”，所以“Stakeholder”可以直接翻譯成為“拿著籌碼的人”。但中文翻譯為“專案干係人。

任何專案經理在學習專案管理知識的過程中都明白“Project Sponsor ”(翻譯為“專案發起人”)及“Stakeholder”(翻譯為“專案干係人”)的重要性。但從我過去二十多年的專案管理經驗中對這兩者的認識和在專案過程中需要建立的焦點，讓我感覺到一個專案管理應用的重大誤區。

　　1.專案贊助人與發起人

　　所謂“Sponsor”，直接翻譯應該是“贊助人”，但如何會變成“發起人”(Initiator)呢?假設A君有一個商業計劃，可以讓A君賺大錢，但因為缺乏資金，所以到處找尋投資者，最後B君對這計劃感覺有興趣，願意投資A君的商業計劃，讓A君這個“發起人”可以進行有關的計劃，把計劃變成事實。

　　這裡談到的是兩個人，A君是專案“發起人”，而B君是專案“贊助人”，A君的計劃能夠成為專案，完全是靠B君的投資才能夠立項。但如何在專案管理的翻譯中把B君翻譯成為A君呢?惟一的解釋便是這個負責翻譯的“外人”在翻譯的時候，由於對專案管理缺乏認識，錯把“馮京”做“馬涼”了。

　　回想1997年被調派回國負責當時原郵電部的“綠卡工程”(即現郵政儲蓄系統)建設的時候，當時有三家供應商負責提供全國各省的系統安裝，這個專案的資金安排是原郵電部負責支付各專案的大部分資金，各省及市單位負責支付當地系統的小部分資金。當時很多地區的專案在建設完成後都需要進行變動及返工，經過很長的試執行期才能夠完成驗收過程。只有我們一家是當時最快得到驗收文件的供應商，因為我們在各地執行專案的時候，嚴格執行部的要求，對地方單位所提出的功能變動採取嚴格的範圍變動管理方法，任何變動必須得到部的同意才進行變動，所以我們的交付比較順利。當然，在過程中我們不像其他供應商一樣按照地方的需求增加或修改系統架構，雖然常會與地方的官員發生爭議，但多能夠通過協調解決。我們能夠比其他供應商更順利地完成驗收過程是因為我們能夠明確理解部是負責大部分資金的單位，他們的意見才是最重要的，部是整個專案的主要“贊助人”，而其他供應商均未能有效把握“Sponsor”的定義，讓專案延誤了多月才能夠完成。

　　當專案發起人建議專案的概念時，往往在經過可行性研究後對專案的範圍及功能會有很多不一樣的地方，不管是實際應用需求或資金問題，發起人的概念可能在專案立項時只保留下一部分的概念，只有負責專案費用的人才知道他投資這個專案的最終目標。如果按照專案發起人的要求執行專案，不一定能夠得到投資者的認同，讓專案走上冤枉路。

　　由此可以看到，當一個專案在實施過程中，往往專案發起人並不是專案贊助人，當然也有可能兩者是同一個人，但明確體會“贊助人”及“發起人”的差異，讓我們能夠把握專案的焦點，降低專案延誤的風險，減少交付時進行修改及返工的機會，降低專案的成本。專案經理對“Sponsor”(贊助人)及“Initiator”(發起人)的理解對專案能否如期完成有著重大的影響。

　　2.賭注

　　“Stake”的直接翻譯是“籌碼”或“賭注”，所以“Stakeholder”可以直接翻譯成為“拿著籌碼的人”。但中文翻譯為“專案干係人”，這更讓人感覺莫名其妙。

　　什麼才的直接翻譯是“籌碼”或“賭注”，所以“Stakeholder”可以直接翻譯成為“拿著籌碼的人”。但中文翻譯為“專案干係人”，這更讓人感覺莫名其妙。 http://bbs.mypm.net

　　什麼才算是“拿著籌碼的人”呢?那就是在賭局完的時候(即系統開始執行的時候)，最終是“輸”還是“贏”是看這個人在過程中投注的決定。在系統建設的過程中，是那個人“初步”決定哪些功能需要增加，哪些功能可以減少，明確理解系統在執行時能否提升部門的能力和效率，這個人便是系統應用部門的主管。這個主管及他的屬下是系統使用者(User)，是專案干係人，但只有這個部門的主管才是Stakeholder。

　　我說那個“‘初步’決定哪些功能需要增加，哪些功能可以減少”的人，是因為做最終決定的不是這個Stakeholder，而是專案的Sponsor。Stakeholder有可能是專案發起人，但也可能不是。他需要說服贊助人對專案進行投資，讓系統提供他所需要的功能來完成他的部門的工作。所以在專案過程中我們需要Stakeholder對專案的認同。一些中小型專案可能有數十個使用者，但可能只有一個Stakeholder，一些大型的專案可能有數萬名使用者，但可能只有二三十個Stakeholders。我們的焦點錯了，專案便會失敗。

　　當我們在2003年負責實施澳門政府一個資訊平臺的建設專案時，我們面對的是數萬名政府公務員，這數萬名公務員都會因為這個資訊平臺的建設使他們的應用受到影響。如果我們需要這數萬名“專案干係人”認同我們的設計，那麼這個專案便沒有辦法如期完成。所以這個專案的Stakeholders只是部門的主管級人員(視系統本身的應用範圍，一些供應數個部門使用的大型系統的Stakeholders是部長，一些只提供一個署或處應用的小型系統的Stakeholders是署長或處長)，整個專案的Stakeholders只有二十來人。我們只需要說服這些主管，讓他們認同整個資訊平臺的設計便可以實施，而不是要說服數萬個專案干係人的公務員去認同我們的設計方案。