很多項目經理在這個階段，由於經驗不足及整個項目管理體系涉及的環節和內容比較龐雜，往往無法有效思考，無從下手。
筆者有幸在最近幾年的工作實踐中，實際搭建并迭代了2-3次項目管理體系流程框架，期間也經歷過很多迷茫，也踩過一些坑，當然更多的是收穫和經驗，有了一些個人的實踐方法和感悟。
本著輸出和總結個人的經驗沉澱，以及受PMO前沿夢想老師分享精神的影響，筆者將在後續的章節，通過一個完整的軟體交付項目，跟大家分享自己在構建項目管理體系過程中，一步步思考、一步步分析的步驟和思路，從而搭建出符合公司特點、能夠落地的項目管理的體系。
在分享具體的交付型軟體項目管理體系流程之前，先介紹一下常用的一些思考方法和模型，這樣大家可以有一個比較整體的概念。
01行業標杆和經典理論
人類社會經過幾千年的發展，特別是進入現代商業社會後，各行各業都形成了很多經典、實用的理論和模型。我們大多數人都是普通人，需要站在巨人的肩膀上，借鑑已有的經典理論和模型，並根據我們的實際需要來快速提高我們的能力。
譬如項目管理流程體系的搭建，就可以參照PMP、Prince2、CMMI這些經典的項目管理體系和方法，或者參考軟體行業先進企業的管理流程。
02分層、分步驟拆分思路
當我們遇到一個比較大的、複雜的工作或事物時，是非常難於理解和把握的。一般的解決方式是把大的問題按照各種維度拆解成小的問題和結構，從而降低複雜度和理解難度。
筆者常用的模型是金字塔模型。其理論認為所有的事務都可以按照三種維度進行分解：時間順序、結構順序和重要性順序。譬如：
Ø我們常說的軟體項目管理流程分為：項目啟動-需求分析及設計-概要/詳細設計-代碼實現-測試-項目上線-項目收尾就是按照時間順序去分解。
Ø需求分析和設計工作中，常用的業務de架構-應用架構-數據架構-技術架構 就是按照結構順序進行分類。
Ø我們常用的WBS工作分解結構其實也是以上運用幾種邏輯順序進行分解。
03目標-現狀-問題差距-解決方案
這個模型大家應該也不陌生，也是筆者常用的模型和思考方法。
Ø我們做任何事情，只有有了目標才能更加聚焦和有明確性，防止走偏。
Ø只有了解了現狀，才能發現差距和具體的問題所在，問題差距=目標-現狀。
Ø而分析出問題和差距，我們才能夠有針對性地制定相應的解決方案。
通過這個方法與經典理論相結合，才有可能能找到符合本企業、本團隊可落地的各種方案。
04二維矩陣模型
二維矩陣在這裡就不多介紹，其在很多領域都被廣泛使用，譬如項目管理5大過程組+10大知識領域、項目決策矩陣模型、在軟體項目開發過程中項目經理、技術組長、需求分析人員、開發人員、測試人員等各個階段的崗位職責等。
05二維矩陣模型
四象限模型也是大家耳熟能詳的模型，很多模型其實都是四象限模型的具體應用。
譬如常見的干係人權力影響模型、時間管理模型、波士頓矩陣。
05表單化模板和問題檢查清單
公司各種管理流程的建立，有兩個大的目的：
Ø一是為了統一標準，提升效率
Ø另外一個目的就是降低對人員能力的要求，從而使工作門檻降低
表單是承載公司戰略意圖與管理意圖的工具，同時也是讓制度、流程、標準、編碼等落地可執行的重要工具。現在企業運行，無論是傳統的線下運轉，還是全線上無紙化辦公，其本質都是通過一個個表單在各個環節進行流轉，從而完成相關的業務。
問題檢查清單在企業實踐中，可以通過組織過程資產沉澱或者有經驗的人員總結出來後，讓能力水平經驗相對弱的人員也能有完成相應的工作，相對輕鬆上手，並起到培養團隊成員的目的。
譬如項目啟動大會工作內容清單，項目風險識別清單等等。
現在隨著騰訊文檔、飛書等在線協作文檔和表格出現，已經越來越方便搭建公司線上管理表格和清單，從而有效提高工作和業務協同。
項目管理體系流程整體框架及目標
我們開展任何相對複雜的活動，都需要制定明確的目標，從而為後續的工作提供指引。
這裡我們用到的是看現狀-查問題-定目標-提供解決方案的常用方法和思路。
1、看現狀
搭建能夠落地的項目管理體系流程和純理論研究的最大不同，筆者認為一定要貼合企業的發展現狀和實際業務運營的特點來開展，因此分析企業的現狀就是第一步要開展的工作。接下來我們從公司所處階段、公司的組織架構、公司開展的業務等幾個方面去分析。
1.1. 公司所處階段
公司目前處於1-10的階段。
目前從正式開始業務運營以來，已經進入第三個年，已經從最初的10多人，通過自主團隊建設和引入外部團隊，已經突破100人左右，正處於業務快速發展期。
1.2. 公司的組織架構
公司的組織架構在期間也進.行過調整，根據業務開展特的實際運行和參照行業先進標杆，由原來的產品部、技術部、測試部、項目部的職能矩陣式調整為目前的事業部下的項目經理責任制。具體結構如下：
公司採取扁平化管理，最高層級為總經理並直接管理商務部，和支撐保障部門。
目前設立了三個軟體交付事業部，每個事業部根據各自部門的發展情況，擁有3-5個軟體開發項目組。並由三位事業部部長+外部業務、技術專家顧問組成虛擬的決策委員會，開展日常的管理及決策工作。其中軟體開發項目組為最小單位組織，以項目經理牽頭，並與產品經理和技術組長形成團隊核心骨幹。
可能有眼尖的小夥伴會發現，咦你們公司怎麼沒有CTO、產品總監等崗位。這其實就是每個公司根據自己發展的階段和業務特點的獨特性。
首先：是根據公司開展業務的特點決定的，在後面的公司業務會分析到
其次：是根據公司現有團隊人員特點來決定的。公司的三個軟體事業部部長或在業務領域，或在技術開發領域都有自己各自的特長，獨當一面，各自互相補充支持。通過決策委員會及外部聘請的業務和技術顧問這種機制已經可以滿足目前階段的實際業務開展。
說到這裡，我們要向中國人民解放軍學習，窮則老三樣：56衝鋒鎗、RPG火箭筒和107毫米火箭炮，富則殲20、東風飛彈、航母戰鬥群。總之要貼近實戰和現有條件，只要能把美帝干翻的，那都是好方法好手段。
對我們項目經理來說，有條件要上，沒有條件創造條件也要上。
通過組織架構的分析，對我們最終搭建的項目管理流程的工作步驟及各個管控點提供了依據和指導，使我們的管理流程更能順利的、高效的開展，更加落地。
1.3.公司開展的業務
公司定位於保險、銀行等大型金融行業數位化建設軟體供應商，目前主要開展的的業務有數位化轉型諮詢、軟體項目實施、人力資源外包服務及軟體產品開發四個大的領域。目前以軟體項目實施占公司營業比重最多，本次項目管理體系流程的搭建就是針對這個業務模塊展開的。
目前大型保險、銀行企業通常都會進行數位化轉型業務戰略規劃，然後根據規劃的內容進行相應的信息化建設，其中部分核心IT建設內容為保險、銀行企業自己創建的金融科技公司進行實施，其餘部分均為保險、銀行軟體開發供應商以項目制度的形式進行開發實施。
目前大部分保險、銀行企業對定製化的外包項目絕大部分仍舊採用瀑布式軟體開發方式和流程，極少部分項目開始試點敏捷開發。
而目前公司服務的3-5家保險、銀行甲方均採用瀑布式軟體開發流程。
這基本上就為我們的將要構建的的交付型軟體項目管理體系流程定下了基調：
即採用跟甲方相匹配的瀑布式軟體項目管理開發流程。當然我們在實際過程的細節和節點，也引入了敏捷項目管理中一些比較實用的工具，譬如每日站會、看板、需求優先級評估、分階段快速疊代上線等。這一點現在看來和PMBOK第七版不謀而合。
在這裡再嘮叨一句，瀑布式和敏捷式真的有必要分的那麼清楚嗎，筆者個人認為在真正的項目實踐中，瀑布+敏捷的混合式將越來越多的成為主流模式。還是那句話，只要是符合公司現階段實際的、有利於軟體項目開發效率和管控的，都可以大膽拿過來使用。
到了這裡，現狀和基本背景都分析完畢了，這樣我們就了解了企業內部和企業外部的各種情況，為我們最終制定可以落地的項目管理體系流程提供了有力的保障。
思考題：
你們公司目前處於什麼階段呢？
你們公司的組織架構你能畫出來嗎，每個部門大概的職責你了解嗎？
你們公司的開展的主要的業務是哪些，行業特點是什麼，是定製化項目為主，還
是產品自研為主？
2、查問題
只有發現目前項目管理體系流程中具體存在的問題，把問題收集並匯總歸納具象化後，我們才能有針對性的調整、疊代我們新的項目管理體系流程。
那麼如何全面的、深入的去探查問題呢，我們這邊採用分別針對公司高層（總經理）、中層（各事業部部長及支撐部門經理）以及一線項目組成員三個層次，採用先發散後收斂歸納的方式進行調研和分析。這樣從高到低，從整體到局部基本上可以做到不遺漏，各個方面都能照顧和了解到。
2.1 公司高層（總經理）
總經理並沒有指出特別具體的問題，只是重申了一些公司後續發展的規劃和本年度的重要事項。
- 公司預計會成功開拓新的2-3家中等規模的保險、銀行客戶，其中一家公司的IT信息研發中心在另外的一線城市。業務量會逐步增加，需要更多的有戰鬥力，可以大概率保證項目順利交付的軟體項目交付團隊。
- 公司當年準備進行CMMI3及質量管理體系認證，從而增加公司相關資質，更有利於公司招投標和相關高科技企業認證。
雖然沒有特別明確的問題，但是已經為我們搭建項目管理體系提供了比較宏觀的背景和要求。
2.2 公司中層（事業部部長和支撐部門經理）
筆者與另外2位軟體事業部部長工作經驗、能力特長各自不同，特別是其中一個事業部及其下屬團隊為公司整體引入，與公司現有各種制度流程處於磨合狀態。筆者與他們進行了深入的溝通和暢談，各自分享了自己的經驗和教訓，以及目前項目實施過程中經常遇到的困難，並總結歸納了普遍的問題，和迫切需要解決的方向。
這其中既有管理層面遇到的問題，也有具體執行層面項目經理常見的問題。大家在實際分析中要通過頭腦風暴等發散收集後，至少要按照這兩種維度去歸納整理，方便後面有針對性的制定對策，而這些問題就是我們項目管理體系架構中的各個環節的管控要點。
並與商務部和支撐部門經理進行了溝通和訪談，聽取了他們遇到的問題，以及意見和想法，主要可以歸納2個維度：
1.其他部門希望我們能為他們做什麼
2.我們可以為其他部門做什麼，及遇到的哪些問題。
不知大家有沒有注意到，在做調研問題中，是以我們三位交付事業部部長的思考和討論為主，其他部門為輔。
這其實是與公司組織架構和經營模式有關，在公司軟體交付事業部是戰鬥和收入主體，其他部門均為輔助保障部門。如果是矩陣式組織架構，在流程制定上要均衡所有部門的意見。所以大家一定要找到最關鍵的部門和要素，要根據自身公司的實際情況進行調研和分析。
2.3 一線項目組成員
筆者同時也調研了自己負責以及外部引入事業部團隊的項目經理和技術、業務骨幹，獲取了他們目前遇到的問題，以及希望從公司得到的幫助。
當然有些問題不是完全項目管理制度和流程可以解決的，需要排除干擾。
思考題
你們公司項目管理目前遇到哪些問題呢？
3、定目標
通過現狀分析和問題分析，最終歸納匯總及優先級排序，最終定下來了整體的原則和要著重解決的幾個問題和目標：
- 目前各個項目團隊項目管理流程不完全一致的問題
- 降低一線項目經理及業務骨幹使用難度並能夠給與必要指南（解決方案：在每項具體工作節點形成模板表格，有定量指標和形成檢查清單）
- 明確支撐部門工作界面和介入重要節點指標
- 滿足CMMI３認證要求
在定目標和方案的過程中，一定要找到目前最重要的２－３點問題來制定目標和重點解決，不能太多。因為資源和人們的精力是有限的，如果問題太多需要分階段一步一步來解決。
到了項目總監或者部長這個企業中層及以上的級別，一定要有取捨的思維和能力，不能既要、還要、全都要。
思考題：
如果是你的話制定的公司項目管理體系搭建的目標和原則是什麼呢？
4、確定方案
根據前面幾個步驟的分析和目標，最終確定要搭建的項目管理體系流程整體框架仍舊採用瀑布式軟體開發流程和內容，在具體每個環節上根據公司具體內容進行調整和建設落地。
各位讀者看到這裡，意不意外。這不是滿大街都差不多的流程嗎？
筆者想說的是，軟體行業已經發展幾十年的時間，大的框架和流派已經基本成熟和固定下來，目前以瀑布式和敏捷式開發２個大的流派為主。
筆者包括其他大多數人都沒有能力進行特別大的創新和變革，我們都是站在前人的肩膀上，逐步改進和發展。重要的是思考和分析的過程，此外整套框架體系也引入了大量的敏捷工具和思想，具體的落地和裁剪內容在後面的每個具體工作節點裡面進行介紹和體現。
思考題
如果是你，最終確定的項目管理流程節點是哪些呢？
在整個分析過程中，你會運用哪些分析工具和思考方法呢？
作者：PMO前沿特約分享嘉賓寶芝林