如何做好專案經理

專案經理是幹出來的，不是學出來的；是帶出來的，不是教出來的。一個人要成長為一名合格的專案經理主要不是靠學，而是靠幹，當然學也很重要。靠幹，完全不學，可以出專案經理。但靠學不靠幹，是絕對出不來專案經理的。光幹不學，有可能會出現的情況是，你的能力本來可以做一個大專案經理，但現在可能只能做一箇中的或者小的專案經理，因為你沒有理論指導，有些問題可能處理得不夠好。

我一直贊同這個觀點：“專案經理是幹出來的，不是學出來的；是帶出來的，不是教出來的。一個人要成長為一名合格的專案經理主要不是靠學，而是靠幹，當然學也很重要。靠幹，完全不學，可以出專案經理。但靠學不靠幹，是絕對出不來專案經理的。光幹不學，有可能會出現的情況是，你的能力本來可以做一個大專案經理，但現在可能只能做一箇中的或者小的專案經理，因為你沒有理論指導，有些問題可能處理得不夠好。”在實施中型鋼鐵集團ERP專案的過程中，作為實施團對整個總結了很多的實踐經驗，當然這些經驗不能作為專案經理的實施準則，或許也存在個人的誤解，但是提供出來，以供大家參考。

　　一、真正理解專案經理的角色

　　對專案經理角色的理解一定要避免兩個極端，一種過分強調專案經理的技術能力，認為專案經理應該是團隊中技術最強的人，專案實施中的任何疑難問題最終歸集到專案經理，專案經理必須說“Yes”或“No”，否則就無以服眾。另一種則過分強調專案經理的領導能力，認為專案經理首要任務是給他的組員端咖啡，協調大家之間的關係等。我認為專案經理首先應是有過類似本專案的專案實施經驗，對ERP專案有一個清醒地認識，同時對該行業的相關知識有紮實的基礎；對該ERP專案能夠做出一個科學的、切合實際情況的實施方案，在必要的時候能夠幫助自己的組員解決問題，但並不是說專案經理必須是任何技術問題都非常精通，比如對於專案的網路構架，專案經理可以諮詢相關專業人員。但無論如何，專案經理都應該熟悉和了解專案中的每一項技術，只有這樣才能全面掌握專案。其次專案經理應具有協調、組織的能力，能夠調節整個專案團隊的氣氛，在遇到挫折時“升溫”，在過分樂觀時“降溫”；同時應具有同專案單位進行溝通、協調的能力，為自己組員的專案實施做好環境的準備；在遇到關鍵或疑難問題時，能夠通過各種途徑找到問題的答案。

　　專案經理跟一般的職業經理人不同，它具有較強的專業性，一個不懂技術的人是絕對不能做專案經理的，專案經理應該是技術和管理的結合。

　　二、重視對專案組的管理，獎罰分明。

　　在ERP專案的實施中，必須建立一套切實可行的專案管理制度，特別是多方組成的專案團隊，更是如此。只有這樣，才能保證整個專案實施的有序進行。規範化而且切實可行的專案管理制度，必須因企業、因專案而異。一般而言，應是專案管理原理、企業/行業特點和專案規模/性質、企業開發文化/素質等各種因素綜合的產物。同時要嚴格執行制度，做到獎罰及時、分明。在制度建設上一定要避免兩種情況：一是無專案管理制度，僅憑個人經驗實施專案管理；二是書生制度，照搬教條，紙上談兵，束之高閣。

　　專案管理的核心是‘三角平衡’，即規格、成本、進度三個方面保持平衡。在大部分專案實施中，往往無法確立和實現專案成本的指標、考核和控制，資金的支配權往往不歸專案經理，而由公司決定，這樣導致公司與專案經理之間的責任不清，對於某些制度也無法貫徹執行，不能很好地實現專案經理負責制。

　　為了組建一個和諧的團隊，專案經理必須充當隊員的激勵者、教練、活躍氣氛者、維和人員和衝突裁決人。

　　另外，專案經理還必須注重不同崗位的後備人員的開發。在專案的實施過程中一旦出現隊員辭職的現象，專案經理能夠合理安排人員調動和接替；同時，便於隊員在工作過程中形成競爭，以及合理安排期間性休假。

　　三、計劃、計劃、計劃

　　幾乎所有的人都知道專案的實施需要制定計劃。但是在具體操作過程中還是存在以下幾種現象：一是專案計劃的制定不夠嚴謹，隨意性大，可操作性差，因而實施中無法遵循（如專案計劃過於粗略，落實不足），沒有做到任務、進度、資源三落實。二是缺乏貫穿專案全程的詳細專案計劃，甚至採取每週制定下週工作計劃的逐周專案計劃方式，其實質是“專案失控合法化”。三是專案進度的檢查（與進度計劃比對）和控制不足，不能維護專案計劃的嚴肅性。

　　再完美的計劃也會時常遭遇不測，但並不表明我們不需要制定計劃了。如果沒有計劃我們就失去了參照物。專案經理應該能夠預測變化並且能夠適應變化。經常做一些“如果??那麼”的假設，避免安於專案現狀，在專案發生變化時能夠及時作出調整。計劃總在變化，計劃沒有變化快，關鍵是計劃能夠跟上變化。

　　在專案的實施過程中，經常會將整個專案分成若干個小的專案，專案經理應有效的利用好時間，做到各個專案之間的有效、合理銜接，保持整體計劃的合理性和連貫性。

　　專案計劃粗細程度，是一個需要小心把握平衡的問題。越細則控制力度越大，但專案管理的成本越高；反之亦然。以國內目前的狀況，個人看法，3個月以下的專案應細到人天，至少2～3人天；半年以上的專案，至少應到人周。

　　四、真正理解“一把手工程”

　　ERP專案的實施是一把手工程，這是公認的準則。很多專案在實施前期都強調“一把手工程”，並且運用的特別好，比如：由總經理召開會議、成立專案小組等等，但是往往在實施開始之後就不能很好地發揮“一把手”的作用，使得一把手工程變成了撒手工程。專案經理應該自始至終地發揮“一把手”的作用，應該定期地（一般為一個月）或在某項小的專案結束時將階段總結呈遞給“一把手”，並且進行簡短的交流，聽取“一把手”對於專案的看法，在必要時提議“一把手”召開會議。同時，對於專案經理所在公司的“一把手”也要定期進行彙報和交流，以獲取支援、理解和資源的調配。

　　五、不要吝惜在培訓上花的時間，進行二次、三次培訓都不為過。

　　培訓是專案實施的一個重要環節，目前國內單位（特別是大型國營單位）的人員素質比較低，對於資訊化的理解幾乎等於零。所以我們在進行培訓時，應該分層次、分階段的進行培訓，不能期望一次培訓就能使單位的人員理解和掌握軟體的操作。培訓應貫穿於專案的始終，並且應做好適合使用者水平的操作手冊，必要時在單位內部網頁上做“常見問題問答”的欄目。一定要避免“客戶理解太慢、太笨了，我幫他做了吧”等想法和行為的出現。ERP專案是自己單位的專案，任何人都代替不了。

　　六、進行原型測試，做好一個理論和實踐都可行的實施方案。

　　不管是培訓還是計劃都必須建立在一個可行的實施方案的基礎上，否則即使你的方法再好，也不可能達到良好的效果。所以在實施之前，應該進行充分的系統分析和調研，充分聽取各個層次人員的意見，多方蒐集資料，並且進行多角度的原型測試，在專案小組（包括ERP單位方）同意的基礎上，才進行實施和培訓等計劃的制定和執行。儘量避免在實施過程中進行方案改變等情況的發生。

　　七、合理的降低客戶的需求

　　任何軟體都不是萬能的，都不可能百分之百地解決客戶地所有問題。在專案的實施過程中，應該實事求是地、明確地告訴使用者那些是軟體做不到的。一些軟體公司和實施人員不願意和害怕把真象告訴使用者，只想把企業原本正確的業務流程轉變成本公司軟體所規定的業務流程，結果造成雙方僵持。特別是一些軟體程式上的毛病，更是不願接受使用者的指責。其實，這完全沒有必要。在不可能解決的問題上跟使用者兜圈子，其結果只能是使使用者對你造成誤解，和對公司的不信任。

　　由於各種各樣的原因，在企業的經營管理中總會有一些具有自己特色的東西，但是，企業難於在短時間改變現有的做法，這就需要軟體的靈活性和實施的變通。當然，應該儘可能地使企業的行為合符有關的法規和慣例，這是最好的結果。

　　對待客戶需求方面也應該講求80/20原則，不能一味的降低客戶需求，試想一個軟體連客戶百分之八十的需求都滿足不了，還怎樣要求客戶放棄自己的需求。我們所講的合理的降低客戶需求，應該是在解決了百分之八十以上的基礎上，或解決了企業主要需求的基礎上，對於客戶的一些特殊需求不預滿足或解決。在專案的實施過程中，我們不能承諾能夠解決客戶的所有需求，如果一個軟體能夠解決客戶的所有需求，那我們的實施也就不費力了，也就不需要講求那麼多的實施方法了，企業實施ERP也就不需要諮詢了。

　　上述只是從不同的方面描述自己對專案經理的理解，當然在專案的實施過程中最重要的是實施成功，而不管你採取什麼方法。專案經理應該根據專案的自身情況確定適合該專案的方案和實施策略。

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