贏過半衰期 (t 1/2)：管理您的 PPM 解決方案 (後期實作)

  • 發行項

本文是「從馬西斯」集合的一部分。 其中說明如何設定架構，以設定 Project Portfolio Management (PPM) 解決方案的治理模型。 它也包含範例治理計畫，可用來作為設定您自己治理策略的起點。

To download the Word version of this article, see Beat the Half-life (t ½): Governing Your PPM Solution, Post-Implementation: white paper.

若要查看更多文章，請參閱 白皮書。

比對半生命 (t 1/2) ：控管您的 PPM 解決方案、實作後

簡介

在體物理中，半生命週期 (t1/2) 是數量落在其值的一半所需時間量，如時間週期開始時所測量。 (參考： https://en.wikipedia.org/wiki/Half-life) 。

那麼，這如何套用至您最近實作的全新 Project Portfolio Management (PPM) 解決方案？ 套用的原因是因為成功實作的 PPM 解決方案隨附到期日。 如果您不花時間規劃、設計及執行有關管理 PPM 解決方案的治理程式，您可以放心地確保解決方案會填入過時的資料、不正確的設計變更、與實際組織程式不同步的程式，且清單會繼續進行。 就像從未收到維護的車輛一樣，您的解決方案將會停止產生預期的 ROI。 您的使用者會變成被動，並停止使用解決方案，或以體面方式提倡不同的解決方案。

本檔的目標是討論一個架構，以設定 PPM 解決方案的治理模型。 此外也會提供範例治理計畫，作為設定您自己治理策略的起點。

What 和 Why

雖然治理一詞對不同的人可能代表不同的事物，但治理計畫的核心是一組自我載入的原則和程式，以確保應用程式在所有領域都狀況良好，並為在工具上所做的投資帶來最佳價值報酬。

為什麼需要有這些限制，您會詢問？ 這類似于您所居住房屋的維護。 想像一下，每當您需要修正或新增至住家時，就會出現不同的承包商，並以不同于先前的承包商的方式執行工作。 很快地，您一定會得到不相符的視窗、多重設計門 KNOB 等等。 這就是為什麼建置器在建置某些專案時，讓所有這些程式碼和指導方針都遵循、需要維護的元件標準等等，都是合理的。

同樣地，一旦您的 PPM 解決方案上線，將會出現數個變更、增強功能和移除功能。 除非您設定「如何」執行這些變更的標準，否則您可以放心地確保解決方案已完全混亂。

治理區域

當您開始考慮為 PPM 解決方案設定治理計畫時，您必須考慮您實際想要治理的區域。 有許多理論和模型可用來建立企業解決方案的治理計畫，而且您可以自由選擇最適合貴組織的方案。 在本文中，我們將討論符合大部分 PPM 實作的其中一個模型。

找出所需治理區域的最簡單方式是考慮可能發生變更的區域，然後設定管理這些變更的治理計畫。

注意事項

即使專案本身不是「變更」，而是標準維護 (例如：新增使用者、更新時程表期間等，) ，請務必記錄一組標準程式。

一般而言，您的 PPM 解決方案有四個主要區域可能發生變更。

PPM 解決方案的四個主要變更領域：資訊、設計、基礎結構和進程。

資訊控管

實作 PPM 解決方案時，合理假設您從解決方案中良好的「主要」資料開始。 例如，這些資料包括企業資源詳細資料、企業行事曆、相關的自訂欄位等等 ， 基本上是所有可讓您有效地使用 PPM 解決方案的「主要」資料。 不過，當您繼續使用解決方案時，人員會變更部門、某些人員離開組織、行事曆必須以新的假日更新、必須建立時間報告期間、可能需要變更會計週期，且清單會繼續進行。 很明顯地，如果此資料未持續更新，則您的所有報告都將不正確，安全性設定也是如此。

資訊控管會負責讓此資料保持更新和完成，讓解決方案的其餘部分可以利用此核心資料。

設計控管

第二個需要成為治理計畫一部分的區域是維護 PPM 部署的「設計」。 當您繼續使用解決方案時，將會要求調整解決方案設計。 這些可能來自想要變更其使用工具方式，或想要利用新功能的特定群組。 傳統範例是切換時間報告的完成方式。 您可能已選擇使用 %Work Complete 方法，而在新增部門之後，您可能需要將它切換為「每個期間的工作時間」方法，以便與其他財務解決方案整合。 因此，問題在於誰將評估此變更在整個解決方案中的影響，以及如何推出變更。

設計控管是管理影響您整體 PPM 解決方案設計之變更的計畫。

程式控管

您可以輕鬆地將此治理領域視為設計治理的一部分，因為大部分的時間、程式和設計會手動進行。 不過，整體來說，此領域不只涵蓋設計。 其會解決在 PPM 解決方案內部和外部控管推動其效率的程式。

例如，假設您的 PMO 應該在每週三上午提交報告給資深管理層。 您可能已設定一個程式，以確保每個星期五在特定時間提交時程表，而且所有專案經理都會在星期一上午之前更新併發布其專案計劃，再進行報告。 現在，假設資深管理層要求在星期一上午而不是每週三上午傳送報告。 這會在程式中觸發 PPM 解決方案的使用方式變更，而不是變更 PPM 解決方案本身的設計。

這類變更必須由定義為程式治理一部分的標準規則集來控管。

基礎結構治理

這是另一個看似容易定址的區域，但可能會與上述其他三個區域重迭。 簡單地說，支援 PPM 解決方案的基礎結構應該透過安裝來維護。 一些應該屬於這種治理模型的重要專案範例如下：

  • Service Pack 安裝或累積更新。

  • 安裝新的附加元件或應用程式。

  • 升級基礎結構 (新增應用程式伺服器、網頁伺服器等，) 解決效能考慮。

  • 由於組織中其他應用程式的變更而對基礎結構所做的變更 (例如，所有伺服器的虛擬化) 。

在方程式的一端，安裝某些專案的決定純粹是根據 (例如，它是否會對任何目前的生產解決方案造成負面影響) 。 任何基礎結構方程式的另一面是查看安裝所造成的「程式」或「設計」變更。 在某些情況下，基礎結構變更可能是其他區域中任何變更的結果。 如先前所述，雖然我們嘗試將每個變更分類為其中一個區域的一部分，但某些變更可能會完全與這四個區域重迭。

重要問題

無論您嘗試設定哪一個治理領域，都需要回答三個主要問題，以構成治理計畫的核心。

  • PPM 小組如何知道需要進行變更 (例如，這些變更的觸發程式是什麼？) 。 有時候，這些變更本身並不會「觸發」，而是一般照護和饋送您 PPM 實作的一部分 (例如，新增 Project Center 的新檢視)

  • 誰核准這些變更，不只是從企業投資報酬率 (ROI) 的觀點，而是從治理的觀點來看？

  • 誰實際進行這些變更？ 針對上述許多變更，牽涉到多個小組。 在某些組織中，某些變更功能會根據商務需求轉移給一部分的使用者。 在這類案例中，定義誰會實際進行哪些變更會變得更重要。

治理小組

任何治理策略的重要元件是實際執行治理計畫的小組。 雖然有數種方式可以對此治理小組的外觀進行配量和骰子，但所有學派都同意的其中一個建議是保持簡單。

以下是設定小組結構的其中一種方式：

治理區域擁有者 這些是本文先前所述每個治理區域的擁有者。 一般而言，任何會影響這些治理擁有者所指定區域的變更要求，都會成為這些擁有者的責任。 其角色是評估、提供建議、設定新功能的治理等等。

CGC (中央治理委員會) 這是決策者小組，他們可以核准或拒絕治理擁有者所提出的建議。 擁有中央治理委員會不僅有助於減少執著度，也有助於將所有想法帶入通用平臺，並以彼此的認知來評估。

如上所述，根據實作的大小，以及存在於組織中其他應用程式的目前程式，這些角色的定義和結構可能會較小或更大。 重點是至少要備妥最小結構。

其他主要元件

成功治理策略的一些其他重要元件包括但不限於：

  • 工作要求解決方案，可讓使用者要求變更、功能和功能。 這可以像 SharePoint 清單或目前使用的內部工作要求解決方案一樣簡單。

  • 處理變更的程式，包括 IT、治理、CGC 及其他相關商務功能的檢閱。

  • 實際實作變更的程式。 這可能是從開發到測試到生產解決方案的簡單變更，或是根據組織標準的完整Release Management。

進程

讓我們將上述討論的所有元件作為建立治理策略的一部分，並建置其相關程式。 在這裡，其外觀 (可能會根據組織需求) 而有所不同。

治理策略圖顯示使用者如何提交要求，並透過治理委員會進行檢閱和核准。

總結

雖然很難預測和規劃 PPM 解決方案可能發生的每一項變更，但請務必採用可彈性且可調整至任何案例的步調策略。

請考慮下列基本的共通方法來建置治理策略，

  • 治理計畫不需要是包含許多模糊術語的 Tome，也不需要是沒有人能在每日生命週期中使用的語言。 它就像 Excel 工作表一樣簡單，可快速解答 (在重要問題) 中解決的重要問題。

  • 請記住，治理計畫不是您設定的檔。 這是一個「計畫」，可在設定) 必要時保護、維護及變更 (。

  • 治理計畫必須容易實作，而且應該妥善整合到組織的現有程式中。 您不需要重新建立滾輪。

  • 瞭解 PPM 解決方案的治理是不斷演進的程式。 請務必不要因為分析的偏差而停止回應。 從小型開始，傳遞值，然後相應增加。

關於作者

Prasanna Adavi (PMP、MCTS、MCITP、MCT) 是資深企業專案管理 (EPM) 顧問和訓練人員，專門負責 Microsoft Project、Microsoft Project Server 和 Microsoft SharePoint 平臺。 他的主要重點是建置並啟用商務解決方案，以協助組織達到投資的最佳報酬率。

在各式各樣的領域和垂直領域中，他也有豐富的端對端前置專案經驗，包括 IT、ERP (SAP) 、製造、應用程式開發、汽車和創意服務。 他經常在國家/地區參加各種 Project Server、EPM 和 SharePoint 活動，也是 SharePoint 和 EPM 社群的一般參與者。

Prasanna 是) (常用的播客 https://www.prasannaadavi.com ，也會執行每週兩次的播客 (https://www.msprojectpodcast.com) ，主要著重于 Microsoft Project 和 Project Server 解決方案。 Prasanna 是 EPMA () https://www.epmainc.com 的資深顧問。