接觸項目管理成熟度模型後讓我改變項目管理思想

於多年前之前，我一直帶著一個希望能改善項目運作想法。即能使公司的項目能夠以有系統的方式來管理，使項目不會再因為需求不斷增加、用戶期望永不滿足等因素而不斷往後延長，導致公司的項目只能以虧損收場，並且客戶也對於項目的延期而抱怨不斷。在接觸項目管理成熟度模型後，我終於知道公司於項目管理上缺失的到底是什麼東西了。

項目管理成熟度模型目的什麼

第一個廣泛認可的項目管理成熟度模型是 SEI 的能力成熟度模型 (Capability Maturity Model, CMM)，最初由美國卡內基梅隆大學的軟件工程研究所 (Software Engineering Institute, SEI) 在 1980 年代末開發。它的誕生背景與美國國防部對軟件開發品質的擔憂密切相關。在 1980 年代，美國國防部是軟件開發的主要客戶之一，但他們發現許多軟件開發項目都存在嚴重的問題，例如：

• 成本超支： 項目預算經常被突破。

• 延期交付： 項目無法按時完成。

• 品質低劣： 軟件存在大量缺陷，難以滿足需求。

為了應對這些問題，美國國防部委託 SEI 開發一種方法，用於評估和改進軟件開發組織的能力。SEI 的研究表明，軟件開發組織的能力水平與軟件開發項目的成功率之間存在顯著的相關性。因此，他們開發了 CMM，旨在幫助組織了解自身的軟件開發能力，並制定改進計劃。

因此，它的主要目標是：

• 提供一個框架： 用於評估軟件開發組織的能力水平。

• 指導改進： 幫助組織制定改進計劃，提升軟件開發能力。

• 降低風險： 降低軟件開發項目的風險，提高成功率。

簡而言之就是通過一系列有系統的方式來讓軟件開發項目的品質不斷提升，從而解決軟件行業流程混亂、質量不可控的問題。

首次接觸項目管理成熟度模型

在接觸項目管理成熟度模型之前，我雖已擔任多年項目經理並考取多項專業認證（如PMP、PRINCE2等），但實際管理項目時仍常陷於需求變更頻繁、交付進度滯後的困境。當時並不知曉存在系統性評估組織管理能力的方法，直至公司啟動項目管理成熟度等級認證（CMMI認證），才深刻理解到成熟度模型如何透過分級系統（如從無序到持續優化）推動管理規範化。

在評估前的學習階段，老師提出了許多問題，其中最令我印象深刻的是關於建立項目基準（Baseline）。老師甚至質疑我管理的項目是如何建立基準的，當時我只能含糊其辭地回答。現在回想起來，我當年的管理方式從未考慮與客戶建立基準，也不知道何謂建立基準。這也難怪我當時的項目會深陷泥沼了。

除了上述情況外，在評估過程中我也了解到，有系統地進行決策是有效提升項目績效的關鍵。正因為這些原因，我開始對項目管理成熟度模型產生濃厚的好奇心，想知道在公司內部，我是否能將其應用於實務，並提高項目成功的機率。

學習模型後對我的幫助

最近幾年，我一直致力於學習和了解項目管理成熟度模型，其中深入地研習了CMMI-DEV的模型內容和由PM Solutions 推出的項目管理成熟度模型。雖然這兩個模型對項目成熟度的理解並非完全相同，但是它們都能為我現在的管理方式帶來一定的啟發，包括：

• 了解管理上的缺失：通過系統化對比模型上的建議，我發現團隊在需求開發、確認上缺少規範化的流程，具體表現為需求沒有得到客戶確認的情況下即開始後續的開發工作。由於這一方面缺乏規範，因此往往導致需求的不斷延伸。特別當用戶在測試方案的時候，通過會有很多意想不到的想法（如界面交互細節的調節、功能的自動化等）。正因為這些想法和期望沒有好好管理，項目才會進入求無止境的變更之路。

• 有了改進方向：在我對現有的管理流程和模型作差距分析的時候，發現各不同領域的流程中存在明顯的缺失。例如於配置管理領域，我們已經有明確的規範；但在需求管理上，則缺少變更管理規範。通過和模型的對比，

  能幫助我決定優先補足對項目成功影響較大的方面，對於項目影響較輕微或需要團隊大幅度地更改工作習慣，則考慮於未來才作出改善。

• 知道應該有那些改進：當決定改進的領域後，需把模型框架的內容轉化為具體的流程。以需求開發為例，原來我的需求開發流程上缺乏設計評審及製作系統概要設計這兩項關鍵活動，因此我和其他項目經理討論在合適的步驟上把欠缺的步驟加上。如果欠缺模型的對比，要對現有流程作出優化就會如大海撈針一樣困難。

後記

現在的我仍在持續不斷地研究項目管理上可改善之處以及應如何改善。現階段，我的工作重點在於流程最佳化與團隊行為模式重塑這兩方面。需要特別強調的是，任何管理改進都需遵循PDCA循環（計劃-執行-檢查-改進），且必須建立配套的監督機制，驅動團隊成員逐步形成標準化作業習慣。

另外，必須注意的是，模型並非金科玉律，它並不會直接告訴讀者應該如何做才是良好的管理。因為每一家公司都是獨一無二的，別家公司行之有效的做法套用在這家公司可能會產生水土不服的情況，因此在改善的過程中必須根據公司自身的文化設計出合理的做法。要記住，結果才是管理層希望看到的，只要做法不違反基本原則，就不存在絕對的好壞之分。