給專案“發起人”和“干係人”正名（轉）
任何專案經理在學習專案管理知識的過程中，都明白“Project Sponsor”（翻譯為“專案發起人”）及“Stakeholder”（翻譯為“專案干係人”）的重要性。但從我過去二十多年的專案管理經驗中，對這兩者的認識和在專案過程中需要建立的焦點，讓我感覺到一個專案管理應用的重大誤區。
我曾經在五月發表了一篇文章，內容主要說明我國軟體工程人員對需求的誤解，導致軟體行業未能有效把握客戶的“需求”，使我國的軟體缺乏創新。不期然，聯想到目前IT專案管理的應用，也因為一些錯誤的觀點，讓專案管理在IT企業中走上另一段冤枉路。
過去數年，專案管理在科技企業中漸漸被重視，企業希望利用專案管理的理念來強化專案的交付質量，最起碼也希望能夠讓專案可以如期完成交付，降低企業的交付成本，提升利潤。所以，很多從業人員誤以為只要考取了一個專業資格，便可以成為一個專案經理，有效執行專案管理的工作。
知識與體系的分別
要知道美國PMI專案管理的考試內容環繞著專案管理知識（PMBoK）的範圍，PMBoK不是一套體系（Methodology），它提供的是專案管理知識，但我們把Body of Knowledge 翻譯成為“知識體系”，讓我們誤會只要完成有關知識的學習，便可以有系統地直接實施。但往往在實際應用這些知識的時候，才發現無從入手。
“知識”讓我們知道“該做什麼”（What），而“體系”告訴我們“如何去做”（How）。缺乏一個體系，所有的知識只是理論，這也是為什麼國內的新進專案經理感嘆“不知如何把學習到的理論在實踐中應用”的主要原因。
為什麼一些基建專案，如蓋房子、修路、建水壩等專案，能夠有效利用專案管理的知識？那是因為這些專案的管理機制和實施流程比較成熟。專案在設計階段已經把建設的方法（Construction Processes）有效地融合到專案交付的流程和機制（體系）中。
科技專案所需的時間往往比較短，範圍變動也比較大，加上沒有一個實施的流程和管理機制，所以科技專案往往未能有效地把專案管理知識應用到實際的過程中。
國內企業缺乏自建管理體系
一些比較成熟的管理體系，包括歐洲國家單位及企業所選擇的Prince2 （Project in Control Environment 第二版），美國MacDonnell Douglas 公司的STRADIS (Structured Analysis and Design of Information Systems), Ernst & Young 諮詢集團的Navigator，或者是Agile的Method123等，都是一些常用的體系。
有了一套管理體系，才能夠發揮知識的應用。歐美國家的企業大部分有本身的體系，按企業本身的專案特色及業務方向建立的管理流程和機制，讓企業的專案能夠按照這個體系實施。
要能有效地應用專案管理的知識，企業必須建立本身的管理體系。這是我們國內企業所最缺乏的。
其他專案管理誤區
任何專案經理在學習專案管理知識的過程中，都明白“Project Sponsor”（翻譯為“專案發起人”）及“Stakeholder”（翻譯為“專案干係人”）的重要性。但從我過去二十多年的專案管理經驗中，對這兩者的認識和在專案過程中需要建立的焦點，讓我感覺到一個專案管理應用的重大誤區。
贊助人與發起人
所謂“Sponsor”，直接翻譯應該是“贊助人”，但如何會變成“發起人”（Initiator）呢？假設A君有一個商業計劃，可以讓A君賺大錢，但因為缺乏資金，所以到處找尋投資者，最後B君對這計劃感覺興趣，願意投資A君的商業計劃，讓A君這個“發起人”可以進行有關的計劃，把計劃成為事實。
這裡談到的是兩個人， 一個A君是專案“發起人”，而B君是專案“贊助人”，A君的計劃能夠成為專案，完全是B君的投資才能夠立項。但如何在專案管理的翻譯中把B君翻譯成為A君呢？唯一的解釋便是這個負責翻譯的“外人”在翻譯的時候，由於對專案管理缺乏認識，錯把“馮京”作“馬涼”了。
專案贊助人
回想我1997年被調派負責當時“郵電部”的“綠卡工程”（即現郵政儲蓄系統）建設的時候，當時有三家供應商負責提供全國各省的系統安裝，這個專案的資金安排是“郵電部”負責支付各專案的大部分資金，各“省”及“市”單位負責支付當地系統的小部分資金。
當時很多地區的專案在建設完成後，都需要進行變動及返工，經過很長的試執行期才能夠完成驗收過程。我們一家是當時最快得到驗收文件的供應商，因為我們在各地執行專案的時候，嚴格執行“部”的要求，對“地方”單位所提出的功能變動採取嚴格的範圍變動管理方法，任何變動必須得到“部”的同意下才進行變動，所以我們的交付比較順利。
當然，在過程中，我們不像其他供應商一樣按照“地方”的需求增加或修改系統架構，常會與“地方”的官員發生爭議，但多能夠透過協調解決。我們能夠比其他供應商更順利完成驗收過程，是因為我們能夠明確理解到“部”是負責大部分資金的單位，他們的意見才是最重要的，“部”是整個專案的主要“贊助人”，而其他供應商均未能有效把握“Sponsor”的定義，讓專案延誤了多月才能夠完成。
當專案發起人建議專案的概念時，往往在經過“可行性研究”後對專案的範圍及功能會有很多不一樣的地方，不管實際應用需求或資金問題。發起人的概念可能在專案立項時只保留了一部份的概念，只有負責專案費用的人才知道他投資這個專案的最終目標。如果按照專案發起人的要求執行專案，不一定能夠得到投資者的認同，讓專案走上冤枉路。
由此可以看到，當一個專案在實施過程中，往往專案發起人並不是專案贊助人，當然也有可能兩者是同一個人，但明確體會“贊助人”及“發起人”的差異，讓我們能夠把握專案的焦點，降低專案延誤的風險，減少交付時進行修改及返工的機會，降低專案的成本。專案經理對“Sponsor”（贊助人）及“Initiator”（發起人）的理解對專案能否如期完成起了重大的影響。
專案干係人
“Stake”的直接翻譯是“籌碼”或“賭注”，所以“Stakeholder”可以直接翻譯成為“拿著籌碼的人”。但中文翻譯為“專案干係人”，這更讓人感覺莫名其妙。
什麼才算是“拿著籌碼的人”呢？那就是在賭局完的時候（既系統開始執行的時候），最終是“輸”還是“贏”,是看這個人在過程中投注的決定。在系統建設的過程中，是那個“初步”決定哪些功能需要增加，哪些功能可以減少，明確理解系統在執行時，能否提升部門的能力和效率，這個人便是系統應用部門的主管。這個主管及他的屬下是系統使用者（Users），是專案干係人，但只有這個部門的主管才是Stakeholder。
我說那個“‘初步’決定哪些功能需要增加，哪些功能可以減少”的人，是因為最終決定不是這個Stakeholder， 是專案的Sponsor。Stakeholder有可能是專案發起人，但也可能不是。他需要說服贊助人對專案進行投資，讓系統提供他所需要的功能來完成他部門的工作。所以在專案過程中，我們需要Stakeholder對專案的認同。一些中小型專案可能有數十個使用者，但可能只有一個Stakeholder，一些大型的專案可能有數萬名使用者，但可能只有二三十個Stakeholders。我們的焦點錯了，專案便會失敗。
當我們在2003年負責實施澳門政府一個資訊平臺的建設專案時，我們面對的是數萬政府公務員，這數萬名公務員都會因為這個資訊平臺的建設使他們的應用受到影響。如果我們需要這數萬名“專案干係人”認同我們的設計，那麼這個專案便沒有辦法如期完成。所以這個專案的Stakeholders只是部門的主管級人員（視乎系統本身的應用範圍，一些大型系統供應數個部門使用的Stakeholders是部長，一些小型系統只提供一個“署”或“處”應用的Stakeholders是署長或處長），整個專案的Stakeholders只有二十來人。我們只需要說服這些主管，讓他們認同整個資訊平臺的設計便可以實施，而不是要說服數萬個專案干係人的公務員，去認同我們的設計方案。
專案管理本身的意義是MBA課程的Management By Objectives (MBO)與Management by Exception (MBE)的混合體。MBO在專案管理中是範圍管理、成本管理、質量管理、溝通管理、採購管理和時間管理。MBE在專案管理中是進度管理、範圍變動管理，爭議管理和風險管理。
如何適當應用這些知識，那便需要企業本身提供一套體系，或者需要專案經理本身為企業建立一套體系，同時改正翻譯的錯誤。只有這樣才能夠推動我國的專案管理應用。
作者簡介
黃紹良（Hubert Vaughan）MBA, MACS, PMP, MPD, CPM, MCEPIS
黃紹良畢業於澳洲墨爾本大學計算機系學士，於1972年開始從事軟體開發的工作。後在加拿大約克大學獲得工商管理碩士，任職多家資訊科技公司，包括澳大利亞的國衛保險公司，美國友邦資料亞太中心、亞太區和歐洲的迪吉多、澳大利亞天騰計算機、澳大利亞紐西蘭銀行集團、美國/澳大利亞惠普、加拿大貝爾電話公司等跨國企業。 [@more@]
我曾經在五月發表了一篇文章，內容主要說明我國軟體工程人員對需求的誤解，導致軟體行業未能有效把握客戶的“需求”，使我國的軟體缺乏創新。不期然，聯想到目前IT專案管理的應用，也因為一些錯誤的觀點，讓專案管理在IT企業中走上另一段冤枉路。
過去數年，專案管理在科技企業中漸漸被重視，企業希望利用專案管理的理念來強化專案的交付質量，最起碼也希望能夠讓專案可以如期完成交付，降低企業的交付成本，提升利潤。所以，很多從業人員誤以為只要考取了一個專業資格，便可以成為一個專案經理，有效執行專案管理的工作。
知識與體系的分別
要知道美國PMI專案管理的考試內容環繞著專案管理知識（PMBoK）的範圍，PMBoK不是一套體系（Methodology），它提供的是專案管理知識，但我們把Body of Knowledge 翻譯成為“知識體系”，讓我們誤會只要完成有關知識的學習，便可以有系統地直接實施。但往往在實際應用這些知識的時候，才發現無從入手。
“知識”讓我們知道“該做什麼”（What），而“體系”告訴我們“如何去做”（How）。缺乏一個體系，所有的知識只是理論，這也是為什麼國內的新進專案經理感嘆“不知如何把學習到的理論在實踐中應用”的主要原因。
為什麼一些基建專案，如蓋房子、修路、建水壩等專案，能夠有效利用專案管理的知識？那是因為這些專案的管理機制和實施流程比較成熟。專案在設計階段已經把建設的方法（Construction Processes）有效地融合到專案交付的流程和機制（體系）中。
科技專案所需的時間往往比較短，範圍變動也比較大，加上沒有一個實施的流程和管理機制，所以科技專案往往未能有效地把專案管理知識應用到實際的過程中。
國內企業缺乏自建管理體系
一些比較成熟的管理體系，包括歐洲國家單位及企業所選擇的Prince2 （Project in Control Environment 第二版），美國MacDonnell Douglas 公司的STRADIS (Structured Analysis and Design of Information Systems), Ernst & Young 諮詢集團的Navigator，或者是Agile的Method123等，都是一些常用的體系。
有了一套管理體系，才能夠發揮知識的應用。歐美國家的企業大部分有本身的體系，按企業本身的專案特色及業務方向建立的管理流程和機制，讓企業的專案能夠按照這個體系實施。
要能有效地應用專案管理的知識，企業必須建立本身的管理體系。這是我們國內企業所最缺乏的。
其他專案管理誤區
任何專案經理在學習專案管理知識的過程中，都明白“Project Sponsor”（翻譯為“專案發起人”）及“Stakeholder”（翻譯為“專案干係人”）的重要性。但從我過去二十多年的專案管理經驗中，對這兩者的認識和在專案過程中需要建立的焦點，讓我感覺到一個專案管理應用的重大誤區。
贊助人與發起人
所謂“Sponsor”，直接翻譯應該是“贊助人”，但如何會變成“發起人”（Initiator）呢？假設A君有一個商業計劃，可以讓A君賺大錢，但因為缺乏資金，所以到處找尋投資者，最後B君對這計劃感覺興趣，願意投資A君的商業計劃，讓A君這個“發起人”可以進行有關的計劃，把計劃成為事實。
這裡談到的是兩個人， 一個A君是專案“發起人”，而B君是專案“贊助人”，A君的計劃能夠成為專案，完全是B君的投資才能夠立項。但如何在專案管理的翻譯中把B君翻譯成為A君呢？唯一的解釋便是這個負責翻譯的“外人”在翻譯的時候，由於對專案管理缺乏認識，錯把“馮京”作“馬涼”了。
專案贊助人
回想我1997年被調派負責當時“郵電部”的“綠卡工程”（即現郵政儲蓄系統）建設的時候，當時有三家供應商負責提供全國各省的系統安裝，這個專案的資金安排是“郵電部”負責支付各專案的大部分資金，各“省”及“市”單位負責支付當地系統的小部分資金。
當時很多地區的專案在建設完成後，都需要進行變動及返工，經過很長的試執行期才能夠完成驗收過程。我們一家是當時最快得到驗收文件的供應商，因為我們在各地執行專案的時候，嚴格執行“部”的要求，對“地方”單位所提出的功能變動採取嚴格的範圍變動管理方法，任何變動必須得到“部”的同意下才進行變動，所以我們的交付比較順利。
當然，在過程中，我們不像其他供應商一樣按照“地方”的需求增加或修改系統架構，常會與“地方”的官員發生爭議，但多能夠透過協調解決。我們能夠比其他供應商更順利完成驗收過程，是因為我們能夠明確理解到“部”是負責大部分資金的單位，他們的意見才是最重要的，“部”是整個專案的主要“贊助人”，而其他供應商均未能有效把握“Sponsor”的定義，讓專案延誤了多月才能夠完成。
當專案發起人建議專案的概念時，往往在經過“可行性研究”後對專案的範圍及功能會有很多不一樣的地方，不管實際應用需求或資金問題。發起人的概念可能在專案立項時只保留了一部份的概念，只有負責專案費用的人才知道他投資這個專案的最終目標。如果按照專案發起人的要求執行專案，不一定能夠得到投資者的認同，讓專案走上冤枉路。
由此可以看到，當一個專案在實施過程中，往往專案發起人並不是專案贊助人，當然也有可能兩者是同一個人，但明確體會“贊助人”及“發起人”的差異，讓我們能夠把握專案的焦點，降低專案延誤的風險，減少交付時進行修改及返工的機會，降低專案的成本。專案經理對“Sponsor”（贊助人）及“Initiator”（發起人）的理解對專案能否如期完成起了重大的影響。
專案干係人
“Stake”的直接翻譯是“籌碼”或“賭注”，所以“Stakeholder”可以直接翻譯成為“拿著籌碼的人”。但中文翻譯為“專案干係人”，這更讓人感覺莫名其妙。
什麼才算是“拿著籌碼的人”呢？那就是在賭局完的時候（既系統開始執行的時候），最終是“輸”還是“贏”,是看這個人在過程中投注的決定。在系統建設的過程中，是那個“初步”決定哪些功能需要增加，哪些功能可以減少，明確理解系統在執行時，能否提升部門的能力和效率，這個人便是系統應用部門的主管。這個主管及他的屬下是系統使用者（Users），是專案干係人，但只有這個部門的主管才是Stakeholder。
我說那個“‘初步’決定哪些功能需要增加，哪些功能可以減少”的人，是因為最終決定不是這個Stakeholder， 是專案的Sponsor。Stakeholder有可能是專案發起人，但也可能不是。他需要說服贊助人對專案進行投資，讓系統提供他所需要的功能來完成他部門的工作。所以在專案過程中，我們需要Stakeholder對專案的認同。一些中小型專案可能有數十個使用者，但可能只有一個Stakeholder，一些大型的專案可能有數萬名使用者，但可能只有二三十個Stakeholders。我們的焦點錯了，專案便會失敗。
當我們在2003年負責實施澳門政府一個資訊平臺的建設專案時，我們面對的是數萬政府公務員，這數萬名公務員都會因為這個資訊平臺的建設使他們的應用受到影響。如果我們需要這數萬名“專案干係人”認同我們的設計，那麼這個專案便沒有辦法如期完成。所以這個專案的Stakeholders只是部門的主管級人員（視乎系統本身的應用範圍，一些大型系統供應數個部門使用的Stakeholders是部長，一些小型系統只提供一個“署”或“處”應用的Stakeholders是署長或處長），整個專案的Stakeholders只有二十來人。我們只需要說服這些主管，讓他們認同整個資訊平臺的設計便可以實施，而不是要說服數萬個專案干係人的公務員，去認同我們的設計方案。
專案管理本身的意義是MBA課程的Management By Objectives (MBO)與Management by Exception (MBE)的混合體。MBO在專案管理中是範圍管理、成本管理、質量管理、溝通管理、採購管理和時間管理。MBE在專案管理中是進度管理、範圍變動管理，爭議管理和風險管理。
如何適當應用這些知識，那便需要企業本身提供一套體系，或者需要專案經理本身為企業建立一套體系，同時改正翻譯的錯誤。只有這樣才能夠推動我國的專案管理應用。
作者簡介
黃紹良（Hubert Vaughan）MBA, MACS, PMP, MPD, CPM, MCEPIS
黃紹良畢業於澳洲墨爾本大學計算機系學士，於1972年開始從事軟體開發的工作。後在加拿大約克大學獲得工商管理碩士，任職多家資訊科技公司，包括澳大利亞的國衛保險公司，美國友邦資料亞太中心、亞太區和歐洲的迪吉多、澳大利亞天騰計算機、澳大利亞紐西蘭銀行集團、美國/澳大利亞惠普、加拿大貝爾電話公司等跨國企業。 [@more@]
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7839396/viewspace-955548/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 專案干係人是什麼？如何有效管理專案干係人？
- 專案干係人管理
- 如何管理專案干係人
- 如何管理專案干係人？
- 專案管理中，專案干係人的角色和責任專案管理
- 需求調研分析中的專案干係人概念（轉）
- 如何做好專案干係人（相關方）管理？
- 閒談管理：專案干係人的有效溝通
- 專案干係人管理各過程的輸入輸出關係
- 因為忽略干係人管理，專案臨交付時一地雞毛
- [原創]專案管理知識體系指南之 13專案干係人管理思維導圖專案管理
- 後端開發學習敏捷需求-->干係人分析與識別後端敏捷
- 如何給開源專案發起提案
- 工程專案管理造就人（轉）專案管理
- 專案成功在於人 （轉）
- 專案人的情、物、理（轉）
- 獻給機器人發燒友：十大開源機器人專案哪個更適合你？機器人
- 專案經理必備的11種人際關係技能
- 專案回顧：一個開發人員的觀察與思考（轉）
- 單人專案管理的心得和教訓專案管理
- 老專案和人有一個能跑就行
- 給TouchPad開發人員的忠告：轉移平臺
- 專案成功在於人--BUCEC資質模型（轉）模型
- 專案管理中 “以人為本” 的思想(轉)專案管理
- 技術人員的發展之路（轉） — 抓緊，起飛啦
- 專案設計和客戶的關係 (轉)
- IT專案中的ROI：專案經理的朋友還是敵人（轉）
- Open Source專案SuperWaba徵求IME開發人員
- 人際關係三維理論(轉載)
- 中國式管理－人際關係學1 （轉）
- 中國式管理－人際關係學2 （轉）
- 中國式管理－人際關係學3（轉）
- 中國式管理－人際關係學5（轉）
- 中國式管理－人際關係學6（轉）
- 專案管理:起、承、轉、合(轉)專案管理
- 【專題】測試人員 VS 開發人員
- 請轉發給你們老闆--為什麼人們恨工作？
- 專案成功與否的關鍵在於人（轉）