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

我曾經在五月發(fā)表了一篇文章，內容主要說明我國軟件工程人員對需求的誤解，導致軟件行業(yè)未能有效把握客戶的“需求”，使我國的軟件缺乏創(chuàng)新。不期然，聯想到目前IT項目管理的應用，也因為一些錯誤的觀點，讓項目管理在IT企業(yè)中走上另一段冤枉路。

過去數年，項目管理在科技企業(yè)中漸漸被重視，企業(yè)希望利用項目管理的理念來強化項目的交付質量，起碼也希望能夠讓項目可以如期完成交付，降低企業(yè)的交付成本，提升利潤。所以，很多從業(yè)人員誤以為只要考取了一個專業(yè)資格，便可以成為一個項目經理，有效執(zhí)行項目管理的工作。

知識與體系的分別

要知道美國PMI項目管理的考試內容環(huán)繞著項目管理知識（PMBoK）的范圍，PMBoK不是一套體系（Methodology），它提供的是項目管理知識，但我們把Body of Knowledge 翻譯成為“知識體系”，讓我們誤會只要完成有關知識的學習，便可以有系統地直接實施。但往往在實際應用這些知識的時候，才發(fā)現無從入手。

“知識”讓我們知道“該做什么”（What），而“體系”告訴我們“如何去做”（How）。缺乏一個體系，所有的知識只是理論，這也是為什么國內的新進項目經理感嘆“不知如何把學習到的理論在實踐中應用”的主要原因。

為什么一些基建項目，如蓋房子、修路、建水壩等項目，能夠有效利用項目管理的知識？那是因為這些項目的管理機制和實施流程比較成熟。項目在設計階段已經把建設的方法（Construction Processes）有效地融合到項目交付的流程和機制（體系）中。

科技項目所需的時間往往比較短，范圍變動也比較大，加上沒有一個實施的流程和管理機制，所以科技項目往往未能有效地把項目管理知識應用到實際的過程中。

國內企業(yè)缺乏自建管理體系

一些比較成熟的管理體系，包括歐洲單位及企業(yè)所選擇的Prince2 （Project in Control Environment 第二版），美國MacDonnell Douglas 公司的STRADIS (Structured Analysis and Design of Information Systems)， Ernst & Young 咨詢集團的Navigator，或者是Agile的Method123等，都是一些常用的體系。

有了一套管理體系，才能夠發(fā)揮知識的應用。歐美的企業(yè)大部分有本身的體系，按企業(yè)本身的項目特色及業(yè)務方向建立的管理流程和機制，讓企業(yè)的項目能夠按照這個體系實施。

要能有效地應用項目管理的知識，企業(yè)必須建立本身的管理體系。這是我們國內企業(yè)所缺乏的。

其他項目管理誤區(qū)

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

贊助人與發(fā)起人

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

這里談到的是兩個人， 一個A君是項目“發(fā)起人”，而B君是項目“贊助人”，A君的計劃能夠成為項目，完全是B君的投資才能夠立項。但如何在項目管理的翻譯中把B君翻譯成為A君呢？的解釋便是這個負責翻譯的“外人”在翻譯的時候，由于對項目管理缺乏認識，錯把“馮京”作“馬涼”了。

項目贊助人

回想我1997年被調派負責當時“郵電部”的“綠卡工程”（即現郵政儲蓄系統）建設的時候，當時有三家供應商負責提供各省的系統安裝，這個項目的資金安排是“郵電部”負責支付各項目的大部分資金，各“省”及“市”單位負責支付當地系統的小部分資金。

當時很多地區(qū)的項目在建設完成后，都需要進行變動及返工，經過很長的試運行期才能夠完成驗收過程。我們一家是當時快得到驗收文檔的供應商，因為我們在各地執(zhí)行項目的時候，嚴格執(zhí)行“部”的要求，對“地方”單位所提出的功能變動采取嚴格的范圍變動管理方法，任何變動必須得到“部”的同意下才進行變動，所以我們的交付比較順利。

當然，在過程中，我們不像其他供應商一樣按照“地方”的需求增加或修改系統架構，常會與“地方”的官員發(fā)生爭議，但多能夠透過協調解決。我們能夠比其他供應商更順利完成驗收過程，是因為我們能夠明確理解到“部”是負責大部分資金的單位，他們的意見才是重要的，“部”是整個項目的主要“贊助人”，而其他供應商均未能有效把握“Sponsor”的定義，讓項目延誤了多月才能夠完成。

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

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

項目干系人

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

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

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

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

項目管理本身的意義是MBA課程的Management By Objectives (MBO)與Management by Exception (MBE)的混合體。MBO在項目管理中是范圍管理、成本管理、質量管理、溝通管理、采購管理和時間管理。MBE在項目管理中是進度管理、范圍變動管理，爭議管理和風險管理。

如何適當應用這些知識，那便需要企業(yè)本身提供一套體系，或者需要項目經理本身為企業(yè)建立一套體系，同時改正翻譯的錯誤。只有這樣才能夠推動我國的項目管理應用。