時間、質量、成本——專案管理的矛與盾

myattitude發表於2009-01-12

出處:專案管理者聯盟
作者:李琨 汪蔚 郝崢嶸 郭瑩
 

工期緊,活兒只能湊合了;超支,趕緊砍內容,別弄那麼多;資源有限,人手奇缺,往後拖吧。

  這就是我們身邊專案運作時常發生的狀況。

  所有的專案經理都會做預算,都會設定檢查點,都知道又要無休止的協調。但真正執行起來,千變萬化的現實讓他們經常無所適從。

  時間、質量、成本 難平衡!

  在紙上畫一個等邊三角形。在各個邊上標上時間、質量、成本。我們會看 到,任何一方的移動必定帶動其他的變形。這個三角形中間又是什麼呢?是範圍管理,也就是專案範圍。這個三角也就是我們常說的“專案管理三角形”。時間、成 本、質量就是專案管理的三要素。有一種比喻更能說明三要素之間的關係。

  小高為了取悅新認識的女朋友,精心設計了歐洲8日遊,旅遊花光了他多年的積蓄,旅遊結束後,他再也沒有財力去繼續下一步的發展了。用專案管理的話說,這就是不計成本的惡果。

  過了一段時間後,他又攢了一些錢,這次他不和新女朋友旅遊了,他請這個姑娘看了場電影—《第一滴血》。看完後,女朋友覺得小高有暴力傾向,又分手了。這一次,小高敗在不講質量。

  第三次,小高知道女孩子一般喜歡看歌舞劇,他準備請第三個女朋友去看半年後才上演的《天鵝湖》,戰線一直拉著,女朋友愛上了別人——時間拖得太久了。

  這個比喻形象地說明了專案管理中的難題:如何平衡三要素之間的關係?

  一般來說,管理者都希望專案完成的時間要快,完成的成本要低,完成後 的質量要好。可是這三個要素是彼此互斥的。能夠完美做到以上三個要素的專案,少之又少。上世紀60年代初,肯尼迪總統下令要十年內把人送上月球,並安全帶 回來。這個龐大的計劃,要快,必須趕在前蘇聯之前完成;要好,絕不能出現任何差錯;並且在預算上有限制。

  結果,在各方為這個專案大開綠燈之後,美國果真搶先把人類送上月球,並平安帶了回來。當然,我們平常的專案不可能集所有人力、物力、財力等所有資源,並且得到至高無上的尚方寶劍。

  因此,在一般的專案上,這三個要素,彼此之間是魚與熊掌的關係。要兼顧的難度,會按照幾何級數上升。這樣一個三角難題,我們怎麼去解呢?可以試著從兩方面著手。

  第一,先弄清楚什麼是“好”,什麼是“快”,什麼是“便宜”。

  什麼是好專案?一般來說,專案的結果使企業的收入增加、支出減少、服務加強,就是好專案。

  那麼,什麼是“快”?在專案管理上,時間是絕對的。專案經理最容易犯的錯誤,就是在完工日期的預測上,為了討好上司而儘量樂觀。同時,他們總用歷史資料或別人的經驗影響自己的預測,也使得專案工期的變化比較大。

  要達到預期完工的要求,專案經理要把一個規模大、時間長的專案,分成不同的階段完成。在每個階段,又要根據每階段不同的重點分別來做完工預測。工程分得越細,預測的準確性就越高。這道理很普通,但需要很周詳的計劃和分析。

  至於什麼是“省”?當然,省錢不是專案管理中最重要的目的。一個專案 該花多少錢,是早就算出來的。一般來說,如果實際的花費和預估的花費差別在30%以內,是能接受的範圍;超過30%,預算有問題。專案經理在預算方面遭受 的壓力,比什麼都大,因此,在做預算的時候,必須面對現實,而且一定要掌握一個原則—專案的“漲價”必不可少,做預算時打出點富餘是正經。

三個要素互相制約,找準一個平衡點,才能讓三者平衡。很多時候,由於外在和內在的壓力,取捨是免不了的。要做好取捨分析,專案經理要懂得六件事:

  第一,要很清楚地瞭解專案衝突的基本原因;第二,重新確認專案的目的;第三,瞭解專案現處的環境及目前狀況;第四,尋求可行的其它方法;第五,選擇最佳的其他方法;第六,重新策劃專案計劃。

  工作分解咋控制?

  “計劃趕不上變化!”一個專案經理感嘆道。

  的確,專案中有相當多的不確定因素,專案經理辛辛苦苦做的WBS(工 作分解結構),可能因為客戶的改變,甚至領導的一句話,就分崩離析了。一些公司高層沒有經過仔細考慮,也沒有充分徵求各個方面的意見,在制定總體計劃時比 較隨意,修改起來更是“信手拈來”。專案經理也常常藉口工作忙等理由,拖延制定詳細的WBS,甚至有專案經理認為,不應該制定詳細的WBS。

  而沒有詳細WBS的危害也是明顯的:造成計劃與控制管理脫節,無法進行有效的進度控制管理,最終導致專案延期或成本上升。可以說,沒有WBS或者是隨意的不負責任的WBS的專案是一種無法控制的專案。面對各種潛在的變化,專案經理應該怎樣制定WBS呢?

  首先專案經理應該對WBS有正確的認識,制定WBS就是一個對專案逐 漸瞭解掌握的過程,通過這個過程,專案經理可以知道哪些要素是明確的,哪些是要逐漸明確的,通過漸近明細不斷完善。漸近明細也是專案的一個特點,因此 WBS的制定需要在一定條件的限制和假設之下采用漸近明細的方式進行不斷完善。

  再者,制定WBS需要有一個現實的方法。一個大型的軟體開發專案,通常是採用二次WBS方法。即根據總體WBS,在需求調研階段結束、概要設計完成後,再專門針對詳細設計或編碼階段制定二次WBS 。

  一個方面,需求的顆粒度在一開始往往是比較粗的,因此根據功能點對於 整體專案規模的估計誤差範圍也是比較大的,只能據此制定總體的WBS。另一個方面,需求和編碼工作分解不是一一對應的,一個需求的功能點可能對應多個程式碼 模組,而多個需求的功能點也可能只對應一個或少數程式碼模組。只有在概要設計完成以後才能準確地得到詳細設計或編碼階段的二次WBS。

  例如,某系統整合公司與銀行簽訂了一個銀行前置機的軟體系統的專案。合同規定,6月28日之前系統必須投入試執行。專案經理小丁組織大家制定了專案的WBS,並制訂了本專案的進度計劃,簡單描述如下:

  1.應用子系統:1月5日~2月5日需求分析,2月6日~3月26日系統設計和軟體設計,3月27日~5月10日編碼,5月11日~5月30日系統內部測試;

  2.綜合佈線:2月20日~4月20日完成調研和佈線;

  3.網路子系統:4月21日~5月21日裝置安裝、聯調;

  4.系統內部除錯、驗收:6月1日~6月20日試執行,6月28日系統驗收。

  2月17日,小丁發現系統設計剛剛開始,由此推測3月26日很可能完不成系統設計。小丁應該如何做,以保證專案整體進度不拖延呢?

  小丁編制的這個WBS比較粗糙,不適合作為編織專案計劃的基石。只有 一個專案的大概框架和子系統各部分的期望完成時間。從該WBS上面可以看出最底層任務的工期至少也在半個月左右。如果任何一個任務出現了問題,就必然會出 現小丁現在遇到的問題,即延期和延期發生了較長時間才知道。

  在這種情況下,小丁最好是制定二次WBS。最終分解任務的工期最好不要長於一週,否則可能出現失去控制的情況。而且,在不同階段應該有具體直接的責任人。作為專案經理,小丁需要保持與某階段的直接責任人溝通,瞭解進度、發現問題。

稀缺資源怎麼搶?

  小閻剛被任命為公司某橋樑設計專案的專案經理時,內心喜悅之情難以言表。可是才過了不到半個月,面對“溝通複雜化”、“資源爭奪戰”,他已愁容滿面,這是怎麼回事?

  原來,公司為這個專案組建專案組時,人力上,核心組員一共才5人,其 中還有兩位由於來自公司其他部門,時常被其所在部門領導臨時派活;經費上,公司沒有下放任何許可權,所有專案開支仍然要經過公司研發主管、財務部門、公司總 裁一系列的審批程式;物質上,專案開發過程中,需要的實驗場所、器材等還需要不停地和其他部門與專案組協調使用。這一系列問題讓原本是公司技術尖刀的小 閻,在具體實施專案建設時,可利用的資源常常捉襟見肘。

  是小閻自己能力有限,還是公司管理混亂?小閻曾一度十分懷疑自己的管理能力,為了給自己充電,專門報了一期專案管理培訓班。培訓結束後,小閻發覺不是自己能力出了問題,而是公司在專案管理機制上出現了問題。

  小閻的公司將各項資源調配的權力,牢牢地把握在公司各個部門手中,公 司所有專案在實施過程中,專案經理的實際權力相當有限,有時連自己專案組內成員的工作分配都常常遭遇困難。來自其他部門的臨時組員,由於各項管轄關係仍然 隸屬於其部門主管,常常對小閻分配的工作不以為然。而在資金與物質調配上,面對公司的後勤、行政、財務等諸多主管部門,小閻更是無可奈何。

  其實,小閻的遭遇與國內許多公司的專案經理遭遇非常相似。在國內的許多國有、民營企業內,專案經理在企業中的地位往往比較弱勢,企業中的各項資源仍主要控制在職能部門手中,專案經理雖然直接對專案的成敗負責,但卻缺乏相應的權力。

  許多企業的管理層對專案管理的價值相當模糊。傳統模式中,資源大都為 職能部門所控制,面對資源調配時,專案經理的權力處處受限。傳統的管理模式導致了許多專案上馬後,或是長期無法完成,或是成為“半吊子”工程,乃至最後以 失敗告終。企業要想其各個專案快速併成功實施,就必須對企業各項業務實施專案化管理,儘可能將企業的資源實現最優化分配。

  要實現資源優化,企業就要面對多專案協調、部門協調等問題。如果實行各專案的獨立管理模式,往往會出現各專案之間無法很好協調,極容易造成相互推拖和扯皮。而缺乏職能部門間的協調,往往會導致管理錯位、資源配置滯後,嚴重阻礙專案實施和管理。

  面對多專案管理,企業要通過建立專案管理知識庫,通過優先順序評價體系等方式,按專案組合管理的理論,使專案的組合和資源劃分更加反映企業的整體戰略目標。對於相互間有關聯的專案,還應當注重協調與溝通機制的建立,以使巨集觀的規劃與協調更加合理與優化。

  而對於部門間的溝通,企業須逐步建立起有效的溝通機制,使得專案團隊與職能部門之間、部門與部門之間、專案與管理層之間的溝通與協調製度化和流程化。這是整個專案管理機制的一個重要組成部分。資源的協調、風險的監控以及團隊的建設都要依靠這一機制得以實現。

  中國空間技術研究院在專案管理上經驗獨到。2001年,研究院開始在 全院推行專案化管理。隨著研發任務的增多,大量的協調工作也隨之而來。各專案都希望佔用儘可能多的資源,這也給研究院的調配工作帶來很大麻煩。為此,研究 院專門設立了專案管理辦公室(PMO)負責專案的管理、協調工作。

  但是,不久研究院又發現專案辦與其總體部在某些功能上產生重疊,於是研究院又將專案管理辦公室併入總體部,並將總體部提升到院本部的層次,負責所有專案的管理協調工作和總體設計,從而真正實現了技術與管理的合一,提高了執行效率,同時組織結構得到簡化和明晰。

  自總體部履行起PMO的職責後,研究院的工作效率大大提升:原來全院1萬多人只承擔三四個研製任務還力不從心,而現在,即使在人員精簡後,承擔30多個任務時,仍然遊刃有餘。

  有責任沒權力 日子怎麼過?

  專案經理是幾品官銜啊?從責任上說,他負責一個專案,甚至是關係到企業前途的重點專案;從權力上說,他上不如公司老總,下不如普通部門主管,甚至一些普通員工資歷也比他高。你說這專案該怎麼管?

  我國航天集團為了保證神州專案的順利進行,專門設立了總指揮一職,負責整個專案的管理工作。總指揮的級別基本上屬於該專案的“一把手”。這種體制設定,是神五、神六能順利昇天的重要保證。

  專案管理中的矛與盾如何解決?解決的首要方法是設定明確的責任和權力制度,只有給專案經理足夠的權力,他才能充分行使職責,在資源調配、進度控制等方面遊刃有餘。

  其次是專案經理的技能提升。給你權力了,你就能管好這個專案?隨著時 間的推進、專案的變更以及資源的緊缺,沒點金剛鑽,這瓷器活還真攬不下來。現在社會上專案經理的培訓這麼多,就是因為專案管理已經非常重要,甚至對於很多 企業來說,專案就是從始至終貫穿企業生產經營的全部。

  當然,專案經理也得打不少小九九,比如借用IT的方法科學分配任務,合理排期;平常與專案組經常交流專案管理方法,讓每個人都有專案管理觀念,保證專案的實施。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/14780914/viewspace-536467/,如需轉載,請註明出處,否則將追究法律責任。

相關文章