一、研究專案管理的意義
專案管理是一個範圍比較大的課題。由於快速的市場變化，大量的創新工作，當前企業中越來越多的工作都可歸為專案管理的範疇。這樣，一方面企業如果能夠認識和掌握專案管理的一般規律和技能，無疑會極大提升企業應對市場競爭和變化的能力；另一方面，由於專案管理幾乎無所不包，因此泛泛談專案管理，其價值不大，企業應當對其關鍵價值鏈上的專案活動的組織、流程、技術予以深入研究，形成成功模式。

二、專案的特點
1) 時效性。企業之所以發動專案，是希望在短時間內集中資源快速完成任務。
2) 創新性。專案工作往往涉及到新的技術，新的方法，新的環境，無前例可循。
3) 協調性。專案工作往往涉及多個方面，專案人員往往來自多個層面，多個部門。可謂以"烏合之眾"應對"八路神仙"，協調難度很大。
4) 結果性。專案都會有既定的目標。但是對達成目標程度的評價卻仁者見仁，智者見智。專案經理往往費力不討好，不可能取悅於所有的人。

三、專案失敗的主要原因
以上4點決定了專案管理的難度、不確定性和高風險。專案失敗的案例比比皆是，失敗的原因主要有：
1) 戰略失誤，立項就搞錯了。對市場和技術前景判斷失誤，專案作了一半，發現環境已發生變化，該專案已沒有價值，或有了更好的替代方案。
2) 專案組織結構不合理，責權不明確。
3) 需求分析不準確。
4) 重大技術障礙。重大的技術創新是困難，應單獨立項；常規性的專案應當儘可能採用成熟技術。
5) 資源衝突。同時進行多個專案，顧此失彼。
6) 盲目樂觀，計劃與控制不力，工期拖延。對工期估計過於樂觀，缺乏緩衝。
本文重點針對前4個問題予以深入討論。

四、專案立項與規劃
研究專案管理，首先要思考的問題是：專案從哪裡來，或者說，專案的來源有哪些？一般來說，專案的主要來源有：市場或客戶的需求；技術攻關、跟蹤或創新的需求；產品完善或配套的需求；領導或員工的 "靈機一動"等。這些原始的需求僅僅是一些粗糙的、混亂的專案構想，如果在這混亂的時候，就倉促啟動專案，那麼這樣的專案十有八九會失敗。這些混亂的專案構想必須透過一個嚴格的立項過程來進行梳理和評估，明確專案的目標和範圍，識別專案之間的依賴關係，分清輕重緩急，形成結構化的專案清單，在些基礎上進行的專案才有可能成功。
因此，立項過程非常重要，它直接決定了一個企業專案管理水平的高低、有的企業的專案立項是事後反應式，只能被動地應付企業內外部需求，對出現的問題採取救火式的解決辦法。而有些企業的專案立項是前瞻式的，能夠主動地預測需求，並抓住需求和引導需求，對可能出現的問題和風險能夠提前預防。這種前瞻性的思考能使企業避免隨意的、臨時的、盲目的上一些沒有業務價值的專案，而忽視了那些真正能夠提升企業核心競爭力的專案。
專案立項應當仔細考慮如下問題：
• 專案的總體目標是什麼？
• 使用者需求是什麼?
• 可以利用哪些現有的東西?
• 費用的極限是多少?
• 專案持續時間是多少，什麼時候開始獲利?
• 存在的風險是什麼?
五、專案運作的組織結構和職位角色
支撐專案良性運作的組織結構的基本原則："三權分立，各司其職，相互制衡"。
1) 人大：立法及法律解釋，定期修改；
2) 國務院：按法律要求，具體做事情；
3) 檢察院：保證依法辦事，糾偏糾錯。
以軟體開發專案為例，按CMM的要求，正規的軟體開發組織應包括以下角色：
1. 軟體工程過程組，相當於"人大"。其主要作用是建立質量管理體系，如：流程、模板、檢查表、標準、指導書等；這些東西建立起來後，軟體工程過程組主要負責質量管理體系的完善與改進工作，定期召集會議，討論制度流程的改進。老子說："治大國若烹小鮮"，煎小魚兒，必須經常翻，不翻就煎糊了；但也不能翻得太勤，翻得太勤就會破環小魚兒的形狀。制度流程也是一樣，不應該變動太頻繁，讓員工不知所措；但也不能永遠"以不變應萬變"。
2. 軟體開發專案組，包括：專案經理、專案成員、質量控制專員、專案秘書等，負責具體的軟體開發。
3. 質量保證人員，相當於"檢察院"。其工作主要保證制度流程的順利執行，一個質量保證人員監控幾個專案組了。質量保證人員不僅是事後檢查，還必須強化事前和事中控制。質量保證人員要主動協助專案經理以及專案組成員理解這些流程、模板、規範，譬如寫程式碼前，質量保證人員可以給專案組介紹程式設計規範，寫文件前，介紹文件的標準、模板等。質量保證人員保證公司的質量體系在專案組內得以實施，每個階段結束後，都要對該階段的進行質量以及流程執行情況的總結，監控專案按照質量計劃（質量計劃是專案經理制定的）執行。質量保證人員還要透過專案組成員蒐集資料，分析資料,給出分析報告，等等。

六、需求分析
需求分析貫穿專案始終，在專案過程中會不斷產生新的需求，也會不停地發生需求變更。需求分析是專案管理的重點和關鍵，需求分析常見的問題有：
1. 需求膨脹。希望一次解決所有的問題，專案範圍不斷擴大，"把海水煮沸"，最終導致專案失控，偏離原來的專案目標。
2. 需求曲解
a) 需求鍍金。對使用者需求進行了包裝和拔高，"使用者需要的是一輛腳踏車，而不是寶馬"。
b) 選擇性地過濾使用者的需求，"對一個拿著榔頭的4歲小孩來說，滿世界都是釘子"，需求分析人員可能因為自己的價值觀而片面分析問題。
3. 需求分析人員過早給出解決方案，失去了尋找更好解決方案的機會。
需求分析的"5C"和"5T"原則
1. Correct（正確）：表述的內容一和包含的資訊應該是準確無誤的。
2. Clear（清晰）：言簡意賅，意思明確，無需別人絞盡腦汁這個需求到底是要表達什麼意思，措辭不可含糊不清，模稜兩可，更不能讓人感覺話裡有話，引起岐義。
a) 易引起岐義的需求表述句式通常是否定式，而不是肯定式。
b) 不要隱含假設 -- 所有假設都應表述清晰。
c) 對所有需求要進行優先順序排序。一些需求會比另一些重要，如果需求分析人員已有了這樣的判斷，就應該也傳遞給別人。
3. Complete （完備）：每條需求都應完整無缺，避免漏缺或不必要的重複。
4. Consistent （前後一致）：需求應能與上下文保持一致。需求應包含關鍵字或識別符號，如"應"代表必要的需求，"將"代表導向性需求，而且全文保持這一種優先順序定義原則。
5. Changeable（可變更）：對單個需求的更改不會對其他項造成過多影響。
6. Traceable（可追溯）：所有需求的來源都要明確，應可追溯到其他相關文件。
7. Tenable（合理）：所表述的需求必須是可實現的和可操作的。能否在專案預算範圍內，利用有限的資源，按時實施這些需求？一條需求是否與其他需求有衝突？是不是正當需求？需求實際上都應是必要的。也許需求用"將"來描述更好一些，也就是指，導向性或非基本功能。某個需求是否只是一般描述，與系統功能沒有什麼關係？某個需求是否超出系統控制範圍，或根本不是需求？對每個需求，是不是都能找到用途或使用者？有沒有存在的理由？
8. Testable （可測試）：確定每一條需求都可以透過某種方法去測試其是否能實現。是否已量化？容錯性和誤差範圍是否說明？能不能想到一個合理的方法去測試它？這個需求的結果是否可見？
9. Tool （工具性）：需求管理的工具化。
10. Terminology（專案術語表）：建立並維護專案或公司的詞彙表。只要一個行話，或一個單詞、或一個縮略語在專案中表示他們通常意義之外的意思，就應該把他們納入詞彙表。詞彙表應列為需求文件的一項或作為需求文件的參考專案。

七、專案人員
1) 專案經理。專案經理是稀缺資源，不是所有的人都能成為專案經理。挑選有成功經歷的人做專案經理，有的人總能把專案引向成功的彼岸，大部分人卻總是在中途觸礁。
2) 專案成員。應當能夠獨當一面，專案組如果大部分都是"學習者"，往往很難成功。"挑選那些最忙的人，而不是閒著沒事的人。"

八、專案管理的一些經驗
• 有明確定義的目標，有清晰定義的階段、承諾及基線目標
• 採用一個有正式的開發評審點的流程 (管理決策及減少風險)
• 在專案剛開始時就有跨部門團隊制定計劃
a) 確定清晰的團隊目標
b) 在專案整個週期中在一起工作
c) 團隊被授權做決策
• 在專案的整個生命週期中根據使用者需求來制定、執行和調整專案計劃
• 透過預算控制來管理專案
• 在產品/技術目標、計劃及成本方面保持均衡
• 團隊成員的角色及職責是明確定義的
• 有一個唯一的對專案的最終結果負責的專案負責人
• 質量, 獲利能力, 使用者滿意度/市場接受程度
• 將專案管理視為一種正式的職業及層次較高的工作
• 將技術開發與產品開發分離
• 採用一個整合的系統來處理所有專案的資訊 [@more@]

專案管理泛泛談（轉）

相關文章