做好專案管理通則(轉)

ger8發表於2007-08-10
說到專案管理很多人都不陌生,如果被問到您所想到的是西方式的還是中國式的專案管理,可能大部分人都會一笑了之。這一部分人,總不相信另一部分事情的存在。只有經歷了兩種管理方法,甚至曾經嘗試在舊式管理中引入西方模式的人,才會深切感受到其中的差別和各自的精髓。樂家林總工程師在電力鍋爐行業從業多年,他曾經領導過的世界銀行專案獲得過國外同行的讚譽。因此,我們請樂總在一個陽光明媚的下午,給我們講講那些專案管理中的故事。


說到專案管理,我認為西方在這方面領先我們很多。他們已經完成了專案管理的電子化,電子化的工作很重要,而之前對模式的歸納和總結,也很重要。

我曾經建議過國內軟體公司開發適合中國企業專案管理的軟體,當時,我發現中國的專案管理和西方差別很大,我以為我們不大可能直接照搬西方的模型。這是我當時的想法。

但現在回過頭看,我發現:我們更應該去模仿,而不是重新創造。畢竟我們應該承認我們在管理上,跟現代社會的需求並不接軌。打個比方,如果把管理實踐和建立管理方法視為走路和修路,如果一開始就一邊走一邊修,可想而知,代價會很大。而事實上,我們可以直接使用很多西方的理論和模式。所以我現在覺得,我們應該先模擬照搬。在這個過程中,想不修正都困難,其實也就逐漸地形成了我們自己的方式,並逐漸地找到我們自己管理文化的精髓。

我們在很多其他的方面也看到、聽到過幾乎同樣的歷程。僅就管理軟體這一方面看,從耗費大量人力、時間的自主開發演變為對商業軟體的基本贊同,本身就是對這個過程最外在的演繹。而樂先生對這一經驗的感悟來自於7年前,在實踐中感悟,在感受之後更卓越實踐,這也許是比之前的道理更重要的。

對西方模式的學習
97年的時候,我們接到一個世界銀行資助的專案,我所負責的那部分要求我們對利用引進技術所做的樣機設計進行安全性評估。

這類事情,在中國,至少在我們行業,是從來不做的。中國習慣的方式是一種安全監察。我們也開鑑定會,但通常的形式是:專家們坐在一起,看看圖紙資料,聽聽介紹,商量一下,然後表決透過。實際上,這樣的鑑定審查很少有不透過的。

但已開發國家對類似評估的要求是,審查人必須對產品涉及安全的各個方面進行全面的核查,對所有關注的"點"都要記錄,而不是隻記錄存在問題的地方。

因此,這個專案顯得非常難做。世行及其聘請的專家對我們的專案也有類似的要求,但我們又是在中國的環境下做這樣的工作,中國工程師不習慣這樣的做法。我不可能邀請美國的專家來做這個專案,那樣的開銷太大了,我也相信我們中國的工程師並不是沒有這樣的水平,他們只是沒有習慣西方的評估審查方式。因此,我要讓他們做好這個專案,一個可以套用的模式更加不可缺少。既然國內沒有現成的模式,創造一套模式從時間和能力上又幾乎不可能的,那麼不如先看看西方人怎麼做。抱著這樣的想法,我走了北京很多的圖書館和書店,去找這方面資料。很長時間都沒有找到能夠解決我問題的資料。最後,我在人民大學出版社的讀者服務部,看到了一個很小的小冊子,翻譯了一份美國空軍電子器件可靠性評估工作手冊。這個手冊的所有內容就是羅列出來的一個一個的問題。它先列出電子器件所需關注的大的方面,接下來列出很多小問題,而評估者在使用時,只需對這些問題作出是或者否的回答。

這個小冊子使我很受啟發,可以看到,西方人非常簡單,他們試圖把複雜問題簡單化。我決定借鑑他們的這個做法建立一個鍋爐設計安全評估的模型。模型中,我們根據三個方面來確定準則:一方面,是我們需要的那些技術性的標準;其次,必須遵守的國家標準;最後一部分是行業的技術慣例。我們據此把涉及安全的所有問題都開列出來,總共有超過1000個點。這些點不是由我來列,而是請了在某一方面擅長的專家來做的。我只是對他們說,"如果從您的專業出發,你會關注到哪些涉及安全性的焦點?您把它們列在紙上。"於是他們列出那些問題,我把所有專家的提出的要點進行了彙總整理,就得到了最終的一個完整的可操作的模型。

《專案管理知識指南》中,將專案管理定義為:專案管理就是指把各種系統、方法和人員結合在一起,在規定的時間、預算和質量目標範圍內完成專案的各項工作,有效的專案管理是指在規定用來實現具體目標和指標的時間內,對組織機構資源進行計劃、引導和控制工作。專案管理的四個關鍵要素:時間、人、物質資源、質量,在這裡如果把資源看作廣義的詞,則時間、人、必要的物質條件都是資源的一部分,則專案管理無非也是依靠有限的資源得到一定質量的結果。要達到這一點,必要的計劃不可缺少。對結果的計劃就是我們在這一節中看到的"模式設計",而模式不僅僅包括一個簡單的成果格式,也包括如何得到這個成果的關鍵步驟。模型搭建完畢,就應該關注資源的管理。

對資源的管理,在樂總的管理方法中,具體體現為一定的專案通則。

做好"通則"
模型雖然可以構建,但在具體操作過程中仍然會發生問題。過去,一個產品的設計交給工程師去看,他們多半隻會指出哪些地方存在問題。但現在,因為是我負責這樣一個專案,最終完成的評估報告還必須清晰地說明一共評估了哪些地方,哪些是沒問題的,哪些是有問題,還要作出必要的解釋,說明依據什麼來作出的判斷。因此,我當時對專家的要求就是,必須說得出並記錄下來:在這些要點中,哪些沒有問題,哪些有問題,根據是什麼。在審查要點時,專家們基本上是按照各自擅長的專業分工來審閱的,一般情況下只需要將審查記錄合併在一起就可以了。但一旦碰到專家們對相同要點出現評價分歧,以誰的判斷意見為準,就會成為爭論的焦點。而一旦發生這種問題,又如何仲裁,也是個問題。從時間上看,我一共要做9個產品的設計評估,每個設計評估如果不透過,都必須在設計修改後重新審查。在這種不穩定的條件下,整個專案,我仍然必須在一定的週期內完成。還有,我必須考慮到,評估過程中必然會碰到與設計者之間意見相左的情況。為了解決或者控制這些問題,我做了一個"專案工作通則"。在這個通則裡,我將評估的工作程式、原則、技術性爭議的仲裁以及評估的原則是怎麼得出的,清晰地告訴所有參與相關工作的人。我用了3個月的時間建立評估標準和細則,總共花了4個月建立完體系,但實施第一個評估就出了問題。專家習慣於坐在一起說說,談清楚自己的觀點,給出個結論,也就算完成了評估,沒想到我這裡還要一個一個簽字,逐條打勾,立即就有牴觸情緒。

我當時告訴他們,我們現在做事情的方式,可能是我們沒有經歷過的,我們可能感到不習慣,但不習慣的未必是不好的。當然我的這些方式也未必全都是好的,我個人擬的條例可能會有很多問題,這些問題都是可以修改和完善的。但另一方面,儘管你們都是專案組的專家,但從整個專案操作來說,我是負責人,因此我希望你們嚴格按照我的思路走。其實,我當時提出這樣的要求也覺得很不好意思,這些專家中有些是我的大學老師,是老前輩,但為了能夠按時保證質量地完成專案,我必須這樣要求。

打個比方來說,我開發了這個體系,好比是開了個模具,這個模具有問題,大家可以修,但不能一開始生產,就說要把模具扔掉。後來專家們還是讓了步並堅持了下來,當然這個條例也有所修改,最初的設計中還是有些過於理想化的東西,需要把它改得更適合操作。

最後,整個專案得以連續做了下來,我們請的專家集中在六位,而整個過程中,我的原則也沒有太多太頻繁地變化過。同樣型別的評估,一共做了11次,其中兩個設計分別做了兩次,整個專案進展越往後越順,單項評估的直接成本和邊際成本都非常低,但評估的質量卻很高。

這就是規則的用處。

對,這就是規則的用處。事實上,專案開始以後,從第三個評估開始,無論請誰來評估,結果都會是一樣的,因為模型已經穩定下來了。我覺得自己最大的貢獻就是構思和建模。如果規則和目標不明確,協同去完成一件事情就會很沒有效率,大家都會感到很苦惱。是的。您做了兩件事情:找到最終的目標,定下專案方向,這是其一。然後,您為整個專案定了一個規則,讓專家可以在框架中行動。這其實正是專案管理中非常重要的兩點。

當時這個做法在我這個行業裡,似乎還沒有人這麼做過的。

這個專案的過程中,世行請了一位美國專家來監督我們這件事情。那位美國專家對我們提交的東西非常滿意,他說沒有想到中國的企業也用這種方式來做評估。而且他看了我們的通則,也覺得非常好。當時,我們這個專案屬於世界銀行一個大專案中的一小部分。如果把那個專案所有子專案做個分類,我們的屬於軟性專案,因為我們的做法他們很滿意,他們要求所有軟性的專案都學習這樣一種運作方式,做同樣的通則。

但在專案管理的三個層次中,管好專案只是第二個層次的工作,而管理並行的專案,有效控制輸出,則是專案管理更宏觀的部分。

當專案變得複雜
我負責的另外一個專案是行業性的。我先解釋一下這個專案的內容。每個行業搞設計都會牽涉到計算問題,而一些計算方式是行業內通用的。我們的這個專案,就涉及3個標準計算方法的修訂,和2個方法的新建。這個專案牽涉的人非常多,專案中,有時參與到專案的人數超過150個,專家就有60到70人,而且都是行業中的知名專家,我稱之為專家團。

專家團中的專家都是在所屬領域說一不二的人物,這樣的選擇其實基於我對專案最終效果控制的考慮。:雖然這是一個世行援助專案,但它形成的結果要在中國的行業內使用。在中國,除非你是強制性的,一個標準方法是不是被接受,關鍵要看是誰寫出來的。我個人不是名人,也沒什麼權威,我只是拿到資金,希望給行業內做些有益的事情。但我也不願意做出的東西沒人看沒人用,我必須保證專案成果被人們從心理上接受,所以我要求請來的專家是絕對權威的。

另一個原因是,透過這些最專業的專家,我才能夠控制住整個局面。因為權威的力量是巨大的,他替你說話,可以把一批人震懾住。參加整個專案的人,牽涉了5個不同的單位,有搞研究的,搞IT的,搞軟體的,搞貿易的,都歸屬不同的口,怎麼協調困難非常大。於是,我仍然決定先把它簡單化,先做一個通則。

這裡的通則就更難做了。

確實更難。所以當時,我先定了一個非常重要的原則,讓所有參與專案的單位一把手簽字認可:"專案所有成員,歸專案經理領導。涉及專案工作由專案經理安排。"

這樣,我成立了一個有效的可以正常運作的專案班子。因為一個專案過程中,對每個個人,都會涉及到日常的考核指標和任務協調,而這些都不是我能力內可以去照顧到的,需要他的領導為他保證。

當時做那個專案做得很累。最後完成5個計算方法及相對應的軟體的半商業化,花了兩年半時間,結果是基本滿意的。這同樣可以歸功於在專案運作的前期,我們制定了一個有效的通則和專家力量的有效使用。

在此之前,談論的,都是專案管理的內生因素,或者是內生因素來主導的外部因素。然而很多專案的成敗會取決於,或者被認為取決於外部環境的影響。那麼我們來看看專案管理者的努力能在多大程度上轉變外部的不利影響,或者說,透過另一個視角,不利因素如何成為最有力的推動因素。

在最不可能的時候做成了
我在原先的單位負責過一次鍋爐設計的專案,對那次設計過程中發生的一件事情也是感受頗深。

當時,那家公司的設計手段還比較落後,仍舊以趴圖板為主。按實力,接下那個專案是很勉強的。但既然拿下,我們就要完成它,而我是那個專案的負責人。其實當時我已經很長時間沒有碰設計了。事實上,即使是我在接觸設計的時候,也不是這方面的專家,我只做過半年的設計,還是實習性質的學生。但對於設計專案的安排,總有一套程式,我是清楚的。一開始,我就按照常規來安排所有的工作。

但當圖紙開始出來的時候,問題也顯現了。我們發現圖紙的質量太差了。我們在設計過程中雖然也有管理環節,但不嚴格。結果體現在最終設計上,就是出來的東西互相對不上,更不要說圖面質量了。

當時看到這樣的情況,我就下決心採取強硬手段了。我也將之看作一種機會,一個我們能夠達到計算機輔助設計層次的機會。我先同公司領導溝通了情況,然後去說服總工程師。我把圖攤在他面前,問他:你認為這些圖可以過關嗎?他看了也搖頭。我說,"好。那現在聽我的。我們下決心做一件事情:全部用計算機畫。"

說起來容易,但這意味著公司立即要購置一批機器、軟體,還要邊學邊幹。

當時實際情況是,我手上僅有一個學數學的人會CAD,她並不是設計人員,只做過一些小部件的設計,給設計人員打打下手。我自己剛剛開始接觸CAD,也只會畫個圈兒或一條直線。我讓自己冒了個很大的風險,在基本條件不具備的條件下,強行去推這件事情。我考慮到了違約的可能性。但另一方面,如果我不抓住這個機會,可能設計部門永遠會保持這個狀態,我可能永遠再沒有機會了。權衡兩方面的得失,我決定冒這個險。

所以我說服老闆,新買來4臺計算機,然後跟總工程師說,前面的圖紙全部作廢,重新畫。我當時甚至說,我不要進度了。我不能容忍生產垃圾。冒著違約的風險,我還是義無返顧地選擇了重新開始。設計之初,我曾提出過全部圖紙的20%用CAD完成的目標,然後,我把它提高到了90%,這剩下的10%是因為還有一些人會沒有機器用,必須用手來畫。我又將一部分設計量和圖紙工作量很大的部件分包了出去,但也要求必須用計算機來完成。

當時,我們設計部的經理跟我爭執,他說他不會,幹不了,我告訴他幹不了也得幹。他說"那你來畫呀。"我說,"是的,我跟你一起畫。" 連續半個多月,我們就沒日沒夜地投在專案裡。由於以前的一點基礎,我大概用了一個星期,學會了CAD,其他人差不多用了10天也就學會了基本的操作,後面那一週,就是沒日沒夜地趕圖紙。

到了最後交圖期限,6點的火車,我5點還沒有離開繪圖儀旁邊。最後一張圖還在繪圖儀上沒出完,連藍圖也來不及曬了。我安排將已經打出來的底圖拿去曬藍圖。我和另一位技術部經理趕去火車站。曬圖的人拿到曬好的藍圖直接送到火車站,交給我們,搭火車趕去唐山交圖。這其實已經到了最後的交圖期限了。所謂最後期限,就是已經過了第一時間了,我之所以跟著去,是想表示一種誠意和歉意。

這一次趕專案,我們整整幾天沒有閤眼,那樣做很累。但是經過這一次,我們徹底把圖板甩掉了,從此,設計質量猛地上了一個很高的臺階。實際上,即使是計算機畫圖,錯誤依然有,但比起手工製圖來說,那質量不知道好了多少倍,在當時手工製圖還相當普遍的情況下,那樣的圖紙水平已經是非常高的了,員工們獲得了成就感的滿足,士氣得到了極大的鼓舞,也為進一步提高水平奠定了基礎並贏得了時間和空間。

我有時候這樣想:我們做事情,常常強調客觀強調環境強調困難的時候比較多,那其實是在為自己的畏縮和退卻尋找理由。如果狠下心去,不講這麼多理由,可能完全可以做成。

在最後一個故事中,告訴我們的已經不僅僅是簡單的管理一個專案的方法,而是作為一個管理者應有的開拓精神和以我為主的創造力。如何藉助看上去最不有利的時機,透過發現機遇,把握方向,以及強有力的自我管理和推動,把計劃中的專案順利完成。我想,這正是對大部分專案經理最有價值的地方,要借勢,而不是逆勢,也不是待勢。[@more@]

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

相關文章