今天跟大家分享一下，我建立的IT項目管理體系，根據公司的實際環境建立，目前運行非常順暢。
從項目的申請，到項目的驗收付款，每一個環節都通過系統展現出來，我自己給這套體系叫做“數字化項目管理體系”。這套體系不依賴於我的能力，即使我休假或離職，也可以很好地運行，我是完全遊離在體系之外，觀察並優化其瓶頸，我也時常戲稱爲去中心化式的項目管理體系。
這套體系包括OA系統中的項目申請流程，Redmine項目管理系統，開發管理系統和IT項目展示系統（我們內部叫紅燈系統）四個模塊。通過以上四個模塊，將項目的各方（用戶，IT工程師，外部開發人員，領導或利益相關方等）都很好地連接起來，提高項目溝通效率的同時，項目進度管理和項目質量管理也就水到渠成。
開始之前，先聊聊之前的項目管理存在的問題，或許會有共鳴。
1、缺乏目標：項目沒有明確的、共同的目標。如用戶和IT工程師並不完全清楚項目最終將實現的效果，或很模糊；項目沒有明確的上線時間，做到什麼時候就什麼時候上線，如果忘了就不了了之。比如OA系統中還有兩年前的申請未結案，不管是用戶，還是IT工程師根本就忘了這事，直到有領導過來罵人。
2、缺乏用戶導向：項目沒有唯一的負責人。因爲我們IT團隊開發能力不足，80%的開發都是外包，如果有熟悉ABAP，JAVA，.net開發的朋友，也可以跟我聯繫，或許會有兼職外包開發的機會喲。如果一個需求涉及多個業務系統，用戶需要提交多個申請，對每一個申請分別拋外包開發PO。不同的申請由不同的IT工程師負責，相互之間沒在關聯和交流，經常會出現一個系統的開發完成了，用戶滿心歡喜地以爲可以上線試用了，被告知你去問問B工程師那邊做完了沒有，B工程師一眼蒙逼，你沒有給我提需求啊，我都不知道這個事兒。好吧，用戶還得乖乖地再提一個B系統的申請，就這樣，一個簡單的需求，由於沒有統一管理，時間跨度會很長。
3、對“完成”的理解有偏差：IT工程師報告的完成是指開發完成，而不是指項目上線給公司帶來真正的效益。比如剛開始時，工程師彙報說這一項已經完成了，就隨口問了一句，那現在用戶使用中是否有問題？得到的答案是隻是我們開發完了，還在測試系統測試，請問這是完成了嗎？這又回到第一點，我們IT部門的目標是使優化成果給公司帶來經濟效益，而不是簡單地做了這件事情。
4、缺乏交付標準：同一件事情，不同的工程師交付的結果是不一樣的。如OA流程界面可以說是百花齊放，函數的命名規則、字段的命名規則等。
以上只是簡單列舉幾條較嚴重的問題，針對這些困局，我提出了觀察、梳理、高效三步曲。
對IT工程師的要求是軟、硬技能兩手抓。硬技能包括學會繪製LOVEM流程圖，學會利用思維導圖收集用戶需求，學會製作原型圖和用戶確認，學會編制項目相關文檔。軟技能包括提高項目管理能力、時間管理能力，提升思維模式和解決問題的方法論。部分PPT及培訓文稿請出門左轉。
對人的要求如此，對系統的要求更是如此。
只有人和系統的完美結合，才能使IT項目管理高效的運行。對人的軟、硬技能培養部分有機會再講，今天先回到我們的正題 - 數字化IT項目管理體系。
公司的理念是能讓系統做的事就不要讓人來做，機器做更穩定，不易出錯且效率更高。所以，公司的信息化水平還算不錯，所有的信息系統都已打通，優化端到端的流程，消除了信息孤島。當然，我們IT部門也很苦逼，累成狗。但給公司帶來了很大的利益，系統效率提高了，操作人員減少了，節省了不少人力成本。獎金是沒有的，只能自己苦中作樂，尋求一些成就感！哈哈！
我們的IT項目管理按項目大小分爲兩類，較大的項目如：新系統開發或實施，舊系統在新公司實施等。本體系主要是適用於另一類，即IT優化類項目。較大的項目我們採用敏捷管理框架，IT優化類項目採用的瀑布管理模型，爲什麼這麼選，這可能就是最佳實踐 。
由於是內部優化項目，爲簡化管理，我們只重點管理項目範圍、項目進度、項目風險和質量等維度。
從項目實施的時間順序，劃分爲項目申請，項目評估，項目實施，項目測試，項目上線及驗收五個部分。並未嚴格按照PMP的五個過程組，十大知識域。
1、項目申請
項目申請主要通過OA系統中的項目申請流程，也可以稱之爲立項。
1.1、提出需求
所有的需求必須通過OA系統提交申請，以便於通過系統集中管理。這是項目的入口，必須嚴格要求，尤其是外地子公司。
IT項目將採用項目經理負責制，一個需求，無論涉及多少業務系統或多少位IT同事，用戶都只需提交一個申請，由項目經理對整個項目負責，協調內、外部資源。這一步通過重新設計優化OA流程來實現，對項目的進度管理起到至關重要的作用。
多囉嗦幾句，以前一個需求涉及多個系統，需要提交多個申請，是因爲OA系統向PO拋訂單的問題未解決。通過重新設計OA流程，一條OA流程可以同時拋多個PO，對應不同的外部開發顧問。
提交申請時需主要填寫以下信息：
1) 項目名稱或申請主題：用一句話描述項目的主要內容。
2）發起人：發起人是項目的實際發起人，也是項目最重要的干係人，可能與申請人不是同一個人。
3）項目適用範圍：選擇項目適用的公司名稱，可多選。在後面項目測試和項目上線時將作爲管控對象。
4) 業務現狀描述：對業務現狀的描述，即未開發或未優化前的業務情況。
5) 希望實現的目標：對業務優化、改善的詳細描述。
6) 主要風險控制點：業務實現過程中已知和未知風險，需要用戶和IT工程師共同識別。
7) 涉及或受影響的部門負責人：如果項目涉及到其它部門，需要納入進來管理其需求，相當於項目干係人管理。
1.2、認領項目或指定項目經理
根據用戶提交申請時選擇的系統類型，流程會自動推送給相關的IT工程師，根據工作分擔情況，IT工程師認領項目，併成爲該項目的項目經理。IT項目採用項目經理負責制，由項目經理負責整個項目的進度和質量，並協調內、外部資源。
2、項目評估
2.1、IT工程師評審需求，即需求分析
需求分析是整個項目管理的重點，是決定項目是否能夠近期交付的關鍵。
之前的舊模式是，用戶郵件或電話給IT工程師，或召開會議講一遍需求，然後IT工程師就開始着手開發。一方面需求未經過深入討論，可能用戶自己也沒想明白或講明白，或者是需求來源於某一領導口頭指示，提交申請的人自己也沒搞明白；另一方面IT工程師的理解和用戶的實際需求之間有很大偏差。結果就是測試時總是無法滿足用戶需求，反覆修改，最終上線的產品和用戶的原始需求相距甚遠，用戶，IT工程師和外包開發工程師都苦不堪言，項目無限期延期，領導也極不滿意。
在需求評估環節，需要完成以下工作：
1）和用戶及相關部門充分溝通需求，制定方案，對於複雜的項目，需要編制流程圖、繪製原型圖向用戶確認。
2）項目任務分解，類似於WBS，但和WBS還不完全一樣，按功能和用戶的操作步驟拆分，一步步描述，以便於用戶測試確認，越細越好。
3）識別項目的風險，填入OA表單中，以便於用戶測試時逐一確認。
4）項目經理確認實施人員，哪些是內部實施，哪些需要外包開發？填入實施人員，將自動彙總項目評估人天，自動計算項目的計劃上線日期，項目較多時，會根據評估的優先級排序，項目的實施成本，計入部門費用等。
外包開發通過開發管理系統管理，需要外包的項目，會傳到開發管理系統。
選擇發送給至少3個開發工程師，開發工程師將收到短信提醒，同時登錄平臺可以看到完整的項目信息。評估需求後給出報價人天，內部IT工程師可以看到各開發工程師的報價，選擇一個合理的報價即可。這個功能相當於一個簡單的招投標管理平臺。
2.2、項目方案確認及審批
項目經理提交方案和需求清單後，先由產品經理再次確認，確認無誤後經需求部門領導審批、涉及部門負責人審批、IT部領導審批後，項目進入實施階段。
各級領導審批通過是項目啓動階段完成的標誌。
3、項目實施
項目審批完成後，會通知IT工程師實施，如果有外包開發工程師，會通過短信通知。同時，OA系統會向SAP拋一個採購訂單憑證，處於鎖定狀態，驗收通過後，方可解鎖付款。
項目經理組織項目團隊開始實施項目，並在實施過程中控制項目的範圍、進度、成本、質量和風險，並積極地管理干係人的參與。實施過程中，項目經理應與產品經理保持密切溝通，關注項目的變更情況，產品經理也應積極主動地與項目團隊溝通，如有任何變更，應當第一時間通知項目經理，項目團隊評估變更對項目範圍、項目進度、質量和成本的影響，並將變更信息填入OA流程中。如果變更影響到外包開發成本，將返回需求部門事業部總經理重新確認。
3.1 Redmine項目管理系統
Redmine是開源的項目管理系統，功能非常強大，不再詳述，我們自定義了大量的字段，並且與OA打通。
項目管理體系建設初期，開發管理系統和IT項目展示平臺還未建立時，所有的項目都從OA自動傳送至Redmine，現在主要用於管理較大的項目。
有需要溝通Redmine的朋友可留言或私下溝通。
3.2 開發管理系統
開發管理系統是用戶、IT工程師和外部開發工程師交互的平臺，除了前面提到的得的詢價功能，還主要有以下功能：
1）開發工程師登錄後，可以看到自己有哪些項目正處於實施的任何一個階段？是否有延誤？哪些項目已經完成？哪些項目可以對賬×××等。
2）可以看到自己的平均按時完成率，在當前所有外包開發工程師中的排名，以利於我們評選優秀合作伙伴。
3）收到可以實施的短信通知後，開始實施，實施結束後需上傳相關的文檔，如函數名、字段名、SAP傳輸請求號等。
4）用戶在測試過程中發現的問題，直接在開發管理系統反饋，類似於BUG管理系統的功能，項目測試過程會提到。
3.3 IT項目展示平臺
IT項目展示平臺，不僅可以展示項目的整體指標，還能詳細地展示每個項目的進度狀態（我們內部叫紅燈管理），如下圖所示：
有了這些數據，做分析統計，就非常容易了
1）可以清楚地看到每一個項目每一階段的標準時間和實際耗時，因此可以初步預測項目是否可能延期？
1） 可以清楚地看到各個階段有多少優化項目，每一位項目經理分別是多少？
2）按月份統計，每個月有多少優化項目申請，每一位項目經理分別是多少？
3）每一位項目經理的平均響應時間，平均完成時間，平均按時完成率等。不過目前我們的整體水平還沒這麼高，而且考慮到內部用戶的工作忙碌程度及配合程度，項目按時完成率方面不是太高。但考慮到全球的項目平均按時完成率只有60%多，我們也很欣慰了。
通過設計這些指標，從項目數量，完成質量上都可以很好地考覈，並實時展現出來。
4、項目測試
內部優化項目不同於新業務系統上線等大項目，用戶領導的關注度較低，用戶也因爲日常工作較忙，可能會疏於測試。正式上線之後，經常會發現很多場景根本就走不通或存在BUG，一般情況還好，用戶找IT工程師修改即可，遇到較真或喜歡罵人的領導就麻煩了，任何一個小問題可能都少不了一頓臭罵。
1) 爲確保項目質量，在用戶測試前，項目經理必須組織項目團隊開展內部測試，達到交付標準後（即需求清單要求的功能都實現並已滿足用戶期望），方可交由用戶測試。事實證明，這一步的效果非常差，原因可能是多方面的，反正短期內不容易提高。
2) 項目團隊內部測試通過後，項目經理髮郵件通知所有的干係人開始用戶測試，郵件需註明測試時間段，正式上線日期，測試方法和注意事項等。由於第一步的效果非常差，這一步就是最後一根救命稻草，否則，出了問題，用戶和IT工程師都會捱罵。因此，我們選擇在這一環節由用戶和IT工程師共同測試。
3）用戶在測試過程中發現的問題，直接填寫在開發管理系統，也即集成了BUG管理系統的功能，類似於以前常用的Issue list Excel表格。外部開發顧問，IT工程師和用戶都可以跟蹤處理進度。
4) 需要對每一家公司在項目需求評估階段列出的功能點和風險點逐一測試確認。爲了確保測試效果，由系統自動生成一份項目測試清單，如下圖所示。逐一測試通過後，用戶及直屬領導簽字確認後上傳，方可認爲測試通過。這一步把用戶的直屬領導拉進來，出了問題就有人替我們IT背鍋了。
5、項目上線及驗收
用戶測試通過後，項目團隊再部署至正式環境，開始上線試運行。
新開發的功能部署至正式環境時，需要提交《IT變更管理流程》，按變更管理的要求執行。
5.1 項目上線試運行
上線試運行一般爲1個月，新業務系統上線後試運行一般爲3-6個月。
試運行期間，如發現Bug，由產品經理聯繫項目經理確認並修改，如需要對程序增減功能，此時不再允許變更，待業務運行一段時間後，再重新提交新的優化申請。
如果項目適用於多家子公司（根據申請時選擇的公司名稱），必須在申請單中逐一勾選並確認所有子公司都已上線，方可流轉至下一節點。
5.2 項目收尾驗收
項目收尾是指項目經理和產品經理確保所有的項目工作都已完成，項目目標都已經實現後，需求部門對項目進行驗收確認，以及項目團隊對項目經驗的總結。
項目收尾是公司內提高項目管理績效的簡單易行、立竿見影的有效方法，只有總結，才能持續改進、不斷提高，項目收尾也是最好的團建活動。
1) 項目經理應邀請所有合適的干係人蔘與本過程，參與人員包括項目團隊成員和關鍵用戶。
2) 總結項目經驗，分享在項目中的成功經驗和教訓。
3) 更新並歸檔項目文檔。包括但不限於：項目管理計劃、項目範圍、進度計劃、風險管理、變更管理文件等。
4) 如果項目包含了合同，在該階段也需要結束合同。如果項目失敗，仍然需要結束合同。
5) 會議結束後，項目經理需要郵件給所有干係人，包括外部兼職開發顧問，宣告項目結束。
項目通過驗收並收尾後，標誌着項目管理的工作結束，正式進入運營階段。
5.3 對賬及付款
因我們80%的開發都是外包，項目驗收後，需要和外部開發工程師對賬並付款。
外部開發工程師對賬和付款都在開發管理系統中完成，類似於SRM系統的功能，外部開發工程師可以隨時查詢付款歷史，待付款金額等信息。外部開發工程師開好發票後，IT工程師選擇需要付款的項目（可多選），輸入發票號，點擊付款按鈕，即可自動生成OA系統中的《供應商月結付款流程》，無需用戶及IT部門再次審批，即可由財務部門完成付款，費用根據申請用戶的部門，計入對應的成本中心。