給專案管理一把鑰匙[轉帖]

[轉帖]給專案管理一把鑰匙

給專案管理一把鑰匙 作者/專案管理大會

在諸多招聘廣告中，經常可以看見一些IT軟體企業或整合商對他們的技術部門經理或者專案經理是這樣要求的：

　　有XX行業X年軟體開發經驗、精通XXX程式語言、掌握XXX資料庫…
　　這裡面隱含著什麼意義？那就是對於大多數IT企業，他們眼中的技術部門經理或專案經理都是技術高手，部門員工碰到什麼搞不定的技術難題，這些經理一出手，一切搞定，贏來陣陣喝彩。這應該是這些經理們的第一職責嗎？顯然，有不少人都會說“No”。他們明白，對於這些經理們來說，管理好專案是更重要的職責。

　　正因為這樣，專案管理資質認證成為繼MBA之後的一大熱點，許多媒體紛紛刊登有關專案管理資質認證的各種利好資訊，大有專案管理資質認證是解決一切專案問題之靈丹妙藥。其實，專業的專案管理是保障專案成功實施的關鍵因素之一，但並不是唯一因素，就象股份制只是使企業的所有制趨於合理化，但股份制並不能保證企業的經營一定能獲得良好的經濟效益。

　　雖然國內眾多IT企業都開始重視專案管理，也積極的讓員工們參加各種專案管理的培訓，但是在實際的專案執行中，往往還是會出現許多不盡如人意的情況，或者可以說，在注意專案管理後，許多專案的執行效率並沒有得到實質性的提高。或許，我們需要一雙慧眼來仔細看看專案管理領域裡存在的諸多關鍵點。

　　一、專案管理的理論、方法和工具

　　首先需要認清的是專案管理的理論、方法和工具的區別以及相互關係。

　　有不少人接受了一些關於專案管理培訓，或者閱讀了一些關於專案管理的書籍，他們基本上就知道專案管理需要制定計劃，需要進行跟蹤和監控，也瞭解專案管理包含哪些內容，比如說質量管理、變化管理、風險管理、合同管理等等。但是，當他們真正在一個專案中去進行專案管理，卻仍然會感到無從下手，無法通過執行專案管理的活動讓專案沿著正確的方向前進。

　　之所以出現這樣的情況，是因為他們所掌握的往往還只是專案管理的理論，但卻還沒有掌握專案管理的方法。而理論的可操作性往往很弱，因此出現這樣的情況也是非常正常的。用一句話說，掌握理論只是知道了“What”，但還不知道“How”。

　　而方法會告訴你應該如何去做，它解決了“How”的問題，比如說，專案管理分成幾個階段？每個階段又包含哪些活動？這些活動的執行順序是什麼？這些活動之間的關係是什麼？這些活動產生哪些計劃？諸如此類等等。這樣就具有很強的可操作性。但遺憾的是許多培訓或者書本，都還是保持在理論的層次。

　　在日常工作中，經常會聽到這樣一句話“計劃不如變化快”。甚至有人會拿這句話做為擋箭牌，拒絕進行積極的專案管理。實際上，沒有一個專案可以在執行中完全遵守一開始制定的計劃，尤其是在計劃制定得非常詳細的情況下。專案的執行過程中肯定會隨時發生各種變化的，因此在進行專案管理時，是一定要對專案進行監督和控制的，並設定一些節點根據專案的進展對專案計劃進行必要的調整；另外，在制定專案計劃時，還應該注意根據專案的規模和時間，從粗到細制定詳細程度不同的計劃，以保證計劃的指導作用和有效性。象這樣的情況，都是要有方法才可以解決的。出現問題，並不是“進行專案管理”的理念不對，而是沒有找到合適的方法。

　　在日常工作中，還常聽到有人說：“以後我們要加強專案管理，使用××軟體進行專案管理。”他們不但用軟體做出了計劃，也產生了甘特圖和關鍵路徑圖等等，但是實際的工作往往和他們所做出的計劃有很大差異，專案管理成效依然甚微。在這種情況下，他們所犯的錯誤通常是以為有了工具，就可以解決一切問題，而其實他們並沒有專案管理方法。實際上，工具是基於方法的，需要和方法相結合。使用工具是為了更好的貫徹方法，如果沒有相適應的方法，使用工具甚至會產生負面的效果。

　　因此，在具體專案實施中，一定要有清楚的專案管理方法，才可能用好工具；同時也必須注意到所選擇的工具和採用的專案管理方法是相匹配的，因為並不是所有的專案管理軟體都會適用於所有的專案，應該基於專案管理的特定需要選擇某個專案管理軟體，就象ERP系統實際上體現著某種企業管理的理念，每個企業在選擇ERP時都需要密切關注隱藏在它背後的企業管理方法，而不只是它需要的技術支撐平臺是什麼？它的實施需要幾個人月？

　　二、專案管理方法和專案實施方法

　　其次，也必須看到，在一個專案的執行過程中還同時需要兩種方法：專案管理方法和專案實施方法。

　　專案管理方法是關於如何進行專案管理的方法，是可在大部分專案中應用的方法。而專案實施方法指的是在專案實施中為完成確定的目標如某個應用軟體的開發而採用的技術方法。專案實施方法所能適用的專案範圍會更窄些，通常只能適用於某一類具有共同屬性的專案。而在有的企業裡，常常把專案管理方法和專案實施方法結合在一起，因為他們做的專案基本是屬於同一種型別的。

　　實際上，只要願意，做任何一件事情，我們都可以找到相應的方法，專案實施也是一樣。以IT行業的各種專案為例，常見的IT專案按照其屬性可以分成系統整合、應用軟體開發和應用軟體客戶化等，當然，也可以把系統整合和應用軟體開發再分解成一些具備不同特性的專案。系統整合和應用軟體開發的方法很顯然是不一樣的，比如說：系統整合的生命週期可能會分解為了解需求、確定系統組成、簽訂合同、購買裝置、準備環境、安裝裝置、除錯裝置、驗收等階段；而應用軟體的開發可能會因為採用的方法不同而分解成不同的階段，比如說採用傳統開發方法、原型法和增量法就有所區別，傳統的應用軟體開發的生命週期可能分解成：瞭解需求、分析需求、設計、編碼、測試、釋出等階段。

　　至於專案管理，可以分成三個階段：起始階段，執行階段和結束階段。其中，起始階段是為整個專案準備資源和制定各種計劃，執行階段是監督和指導專案的實施、完善各種計劃並最終完成專案的目標，而結束階段是對專案進行總結及各種善後工作。

　　那麼，專案管理方法和專案實施方法的關係是什麼呢？簡單的說，專案管理方法是為專案實施方法得到有效執行提供保障的。如果站在生命週期的角度看，專案實施的生命週期則是在專案管理的起始階段和執行階段，至於專案實施生命週期中的階段分佈是如何對應專案管理的這兩個階段，則視不同專案實施方法而不同。下圖是一個簡單說明。

　　專案管理方法和專案實施方法對專案的成功都是有重要意義的，兩者是相輔相成的，就如管理人員和業務技術人員對於企業經營的意義一樣。從IT企業的角度看，任何一個IT企業如果要生產高質量的軟體產品或者提供高質
量的服務，都應該對自身的專案業務流程進行必要的分析和總結，並逐步歸納出自己的專案管理方法及專案實施方法，其中專案實施方法尤其重要，因為大部分企業都有自己的核心業務範圍，其專案實施方法會比較單一，在這種情況下，專案管理方法可能會弱化，而專案實施方法會得到強化，兩者會較緊密的結合在一起。只有總結出並貫徹實施符合企業自身業務的方法，專案的成功才不會嚴重依賴於某個人。在某種程度上，專案管理方法和專案實施方法也是企業文化的一部分。

從客戶的角度看，如果希望得到有保障的產品或服務，那就既需要關注提供產品或服務的企業是否有恰當的專案管理方法和專案實施方法，也必須尊重該企業的方法。

　　三、 專案管理和專案的目標

　　有了合適的方法，還要清楚專案的目標，才能有針對性的進行專案管理。專案的目標是指專案做完後能夠支援客戶如何運作業務，或者客戶可以獲得具備哪些功能的產品等。

　　在專案的實際執行過程中，客戶方和專案執行方往往很容易產生爭執，出現“先君子，後小人”的情況：開始時大家都是一團和氣，或專案執行方為了獲得專案合同，先是猛拍胸脯保證沒問題，只要是客戶方的要求就承諾一定實現。但隨著專案的進展，才發現雙方的期望有著不小的難以彌補的差距。

　　這種現象的原因就是專案雙方並沒有定義清晰的、可實現的專案目標，換句話說，雙方並沒有真正在專案目標上達成彼此認可的一致。這樣就很可能出現不了雙贏的局面，要麼是最後產生的結果不是客戶需要的，要麼是客戶不斷的修改需求，導致專案的進度和質量受影響。專案目標既是客戶期望的體現，也是專案執行方期望的體現，因此它們應該是清晰的和可實現的。

　　從另一方面講，專案目標的實現是要受到一定製約的，那就是它應該在確定時間和財務預算內實現。有一些目標並不是不能實現，而是實現的代價太高，或者不能滿足進度的要求。這也是在專案實施中需要注意的。

　　同時，清楚的目標也是界定專案是否成功的客觀標準，是對專案進行驗收和質量管理的重要依據。設定清楚的專案目標，在某種程度上也會讓執行專案的IT人員更清楚要做什麼，因為在一些專案中，往往會出現片面追求技術的先進和完美，而忽視專案的結果是為誰服務的。因此，為了保證專案雙方能夠在專案執行過程中愉快有效合作，保證專案的成功執行，雙方都應該注意儘快在專案實施初期定義清楚的目標。

　　四、 專案管理與體系結構

　　“體系結構”這個詞語來自英文單詞“Architecture”，在計算機行業中也有譯為“系統結構”，許多行業都用到這個單詞。對於一臺計算機而言，它所關注的是如何合理的利用合適的軟體、硬體和韌體來構造計算機，使之能夠以最好的效能價格比完成使用者所需要的任務。之所以特別提出“體系結構”，主要有三方面的原因：一個是IT應用範圍的擴大；一個是IT系統的複雜性和產品多樣性；一個是軟體技術的發展。

　　隨著IT技術的發展，以及人們對IT技術的理解和掌握，IT在各行業的應用都日漸的發展和成熟，越來越多的行業和人員都在利用IT技術提高他們的業務運作效率，也就產生越來越多的應用型專案。尤其是IT 應用發展到現在，一個IT系統所覆蓋的範圍日益擴大（範圍包括終端使用者數量、部門數量、地理分佈等），比較常見的大型IT專案是一些新使用者希望在一個高起點上構建一個覆蓋多個業務部門的完整的新IT系統，或者一些使用者希望在原有分散的IT系統基礎上進行整合，從而構建成一個完整的IT系統。

　　對於這樣的大型專案，它們所覆蓋的業務部門很多，彼此的業務功能差異比較大但又存在相當的聯絡，也就是說應用軟體的功能會比較多，且相互之間存在著一定關聯；而與之相適應的是應用軟體技術也發生了變化，多層結構、物件技術和元件技術等得到日益廣泛的應用，這就意味著必須對應用軟體的體系結構進行全面的分析設計如層次如何劃分、元件如何劃分等，才有可能產生一個較完善的應用軟體系統以滿足終端使用者的複雜需求。

　　同時從IT系統的基礎設施來看，其使用的產品也是多種多樣的，從伺服器級的系統平臺、網路平臺到客戶端等，有功能的差異，也有效能的差異，甚至還有采用異構技術實現的。如何讓這些產品構成一個和諧完整的系統為客戶提供方便、快捷的服務，就需要站在整個IT系統的高度上進行完整的分析設計，定義整個IT系統的組成內容，每個組成部分的功能和效能，相互之間如何進行資料交換。

　　如果沒有清楚的體系結構觀念，在專案實施中往往會出現這樣的情況：客戶今天說需要這樣的功能，專案人員就按照客戶的要求實現了；客戶明天再提出新的功能，專案人員也實現了。這看起來很簡單，“簡單就是美”——客戶也會感到很滿意，可是隨著專案的進展，情況就不那麼美了，客戶開始發現“這兩個部分怎麼不能連線”，進而提出要修改想法，甚至要求重新來過。整個專案實施就可能會出現“邊施工，邊設計”的情況，在這種情況下，專案的進度和開銷就很難有效控制，專案的資源可能被極大的浪費，而質量能否得到保證則存在很大的風險。

　　在體系結構清楚的基礎上，專案管理人員就可以根據一定的優先次序關係組織資源去建設IT系統的各個組成部分，從而保證專案的順利實施，而不致於出現“停工待料”甚至是“推倒重來”的局面。因此，在一個合理的專案組織機構中，必須保證專案經理和體系結構設計師的有效配合。

　　五、 ISO9000、CMM與專案管理

　　從90年代中後期開始，眾多的IT企業象其它傳統企業一樣，開始關注國際標準組織頒佈的ISO9000標準系列，並有不少企業通過了ISO9000認證。2000年後，國內大部分從事軟體開發的IT企業開始和國際接軌，重視CMM認證，並有許多企業走上CMM認證之路。這是非常好的一個現象，說明我們的觀念和意識在提高，在一定程度上意味著未來更加光明。但是也出現有的企業為認證而認證，而對於它們的客戶來講，所得到的產品或者服務並沒有因為這些企業通過某項認證而得到更好的質量保證。

　　為什麼會這樣呢？其中很重要的一點是大家並沒有完全認識清楚ISO9000、CMM和專案管理、專案實施的相互關係，或者是不願意承認這種關係。ISO9000針對質量保證和管理，而專案管理要考核的指標包括了時間（或進度）、成本、資源和質量，它不僅有質量管理，還包含了變化管理、風險管理、合同管理等，當然這些專項管理內容和質量管理是相輔相成的，或者說這些專項管理都是在為質量服務的（有時質量的範疇會被儘可能的擴大）。專案管理必然包含質量管理，而ISO9000標準並無法完全代替專案管理。

　　ISO9000是面向絕大多數企業的質量標準體系，是具有通用性的質量保證和管理標準，也因此它對某些行業可能缺乏針對性。雖然它也提出和軟體開發有關的指南，但從總的來看製造業最容易按照ISO9000標準實施。對於製造業和IT企業（軟體、整合），它們都需要質量體系，但是它們的質量指標並不完全相同，甚至可以說絕大部分是不同的。當然，如果在未來的某一天軟體和系統整合的技術方法真的發展到很完善就象工廠中的流水線一樣，那麼ISO9000類似的質量標準對軟體和系統整合的衡量就很有意義了。

　　IT企業通過ISO9000認證，這個體系一定要和專案實施方法密切結合。從ISO9000的發展歷程我們或許可以看出，質量管理方法的完善在時間上是落後於專案實施方法（對於製造業，應該是產品的研發和生產方法）的完善的，因為要進行質量管理，必須清楚要管理的質量指標項和相應的衡量標準，而這些都必須在積累一定的開發生產經驗後才能提出和完善。因此對於IT企業來講，要有很好的質量保證，必須有相對清楚合理的專案實施方法，才有可能把ISO9000標準真正貫徹到專案中，沒有專案實施方法，全面貫徹ISO9000標準是不切實際的。當然，這並不是說在沒有清楚合理的專案實施方法之前不能接觸ISO9000標準，不能應用ISO9000標準。如果在起步階段就開始接觸ISO9000標準，應該說會更有可能以全面的眼光去看待專案的實施以及專案管理和落實專案質量保證，也更有可能逐步去完善專案管理方法和貫徹ISO9000標準。

至於CMM，則是側重於對企業的軟體過程和軟體能力的評估評價，它提供的是一個軟體過程改進的框架，這個框架與軟體開發的生命週期無關，更與專案管理的生命週期無關，因此它並不是企業可以直接採納的軟體開發方法和專案管理方法。CMM做為一個指南能夠幫助軟體企業選擇、採納和合理使用一些先進的軟體專案管理方法和軟體開發方法，並在實踐活動中不斷提高和完善，從而極大程度地提高企業按計劃的時間和成本提交有質量保證的軟體產品的能力。如果一個企業真正達到CMM第四級，那麼它的軟體開發方法和軟體專案管理方法應該是相當成熟的。
因此，CMM只是為客戶選擇軟體開發商提供一個參考標準，它並不等同於軟體產品的質量，也不能代表企業對所有專案的管理能力。或許有一天，會推出專案的能力成熟度模型來評估評價企業的專案管理過程和專案能力，那樣提高專案管理能力可能就更容易了。

　　六、結合實情逐步落實

　　完整的專案管理還包括一系列專題管理，如：質量管理、變化管理、風險管理、財務（或成本）管理等。這些專題管理並不完全停留在專案範疇內，它們的實施要依賴企業內部諸多相關部門的配合，如果一開始就準備在專案實施中進行全面的專案管理（包括諸多專題管理），會存在相當大的難度，因為很多企業的內部運作還不足以支撐這樣的全面專案管理，而且大部分人員也不可能在一開始就能全部領會這麼多的內容。“羅馬，不是一天建成的。”

　　在推廣專案管理的過程中，經常會出現這樣的情況，有的人會委婉的提出意見：你提出的這種專案管理觀念非常好，我也覺得應該這樣去做，可是我又感覺好像太理想化了”，或者“太理論化了”等等。也就是說，對於他們，思想上接受了，但行動上卻很難真正執行，思想和行動總是存在一定的距離。

　　專案管理對於很多人來說是一個新事物，觀念上接受它就需要時間，更何況是在行動上完全採納。應該承認的是，引進專案管理，無論是對於企業，還是員工，都是一種變化。但是，這種變化對個體來說是必須的，而對整個行業來說則是必然的。

　　要讓專案管理真正進入實際業務運作中，應該結合實情逐步落實專案管理理論中的各項內容。比較合適的步驟是：第一階段，先進行一般意義上的專案管理，做到可以清楚的定義專案的目標、範圍及工作成果等，在這個階段應該確保對專案管理方法和專案實施方法及體系結構有清楚的認識和理解，並掌握適當的專案管理工具；第二階段，全面實施質量管理；第三階段，全面實施變化管理、風險管理以及財務管理。

　　接下來，制定一個計劃，把“實施和推廣專案管理方法”做為一個專案去執行和管理，一步一步去做，就會獲得成功的。開始吧！

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