讓 EPM 部署藍圖就像用 GPS 繪製地圖
本文是「從馬西斯」集合的一部分。 其中說明當您打算實作 EPM 時，如何將企業專案管理部署設為「藍圖」。 它會唯一描述當您規劃部署路徑時要考慮的因素。
若要查看更多文章，請參閱 白皮書。
規劃 EPM 部署的 G.P.S. 協助
在最後一欄中，我提到如何使用階段式方法，讓您規劃部署 Microsoft 企業專案管理 (EPM) 方案。 今天，我們將在專案計劃中處理 EPM 部署藍圖。
如果您已前往 Microsoft Live Maps，您知道指示需要兩件事：目的地和起點。 當我們將此比喻套用至 EPM 部署時，我們必須以類似的術語思考：
在技術、程式和人員詞彙中定義的起點
以商務詞彙和優先順序定義的目的地
我們可能也想要定義一些「月臺」或過渡停駐點，您可以在其中重新群組、拍照、享受一段時間的景景，並補充您的供應專案，以進行下一段程的旅行。
進行藍圖或路線規劃時，通常會有兩個縮放比例。 我們會將行程的下一個行程保持在詳細資料中，向下到逐回合路線。 不過，我們可能也會更詳細地保留整個車程的更高層級地圖，以將我們目前的時間保持在整個行程的內容中。 在專案管理詞彙中，我們稱之為「滾動波規劃」。
「Directions」
在進行 EPM 部署藍圖時，我們一律會從公司在 EPM 工作方面所前往位置的願景或意圖開始。 這會提供我們所需的目的地，像 Microsoft Live Maps 一樣進行指示。
如果我們只是詢問「您想要什麼？」，答案幾乎總是會以解決方案來提供。 人員可能會說「我需要類似這樣的報表」或「我們的公司需要產品群組分析」。
對於我們這些在解決方案業務中的人，我們知道這些類型的設計注意事項會面臨風險。 我們會訓練顧問接聽將問題描述為解決方案的用戶端。 「這是問題的解決方案」，我們會說：「不是問題。 讓我們定義問題。」
因此，我們通常不會詢問「您想要什麼？」相反地，在構想期間可能很有用的問題可能包括：
「您現在無法做出哪些商務決策，或是只能在非常困難時進行，因為此 EPM 部署會使哪些決策變得更容易？」
或者：
「您認為組織有哪些層面可以透過增加輸送量或透過此 EPM 部署減少工作來提高效率？」
現在，我們應該詢問這些問題的物件為何？ 當然，為什麼是做出這些決策的人員！ 如果您曾經有一個滿是小孩的迷你貨車，然後向他們詢問您應該前往何處作為目的地，您就知道您會得到 50 個解答。
透過相同的權杖，我們必須確定組織的決策者是此程式的關鍵區段，或我們承擔挑選「驅動程式」未準備好前往之方向的風險。 目前，將資深管理帶入 EPM 藍圖程式還有額外的好處。 除了是選擇 EPM 部署應該方向的重要參與者之外，他們也能夠瞭解專案的規模。 成功部署 EPM 的最常見和困難挑戰之一是長期管理支援。 某些資深主管並未考慮這會變更現有做法和程式的程度，甚至是暫時性的干擾性。 他們也可能不知道 EPM 之類的文化變更專案可能投入多少心力。
在我們與資深管理以及專案管理，甚至是線人合作期間，我們嘗試將商務決策或商務效率與程式和技術連線。 是否有必須建立才能滿足此需求的程式？ 需要完成什麼作業？ 是否有存在或必須建立的系統函式來為該商務決策提供服務？ 需要提供什麼？
基本系統分析是此階段的關鍵。 我們從商務決策「輸出」開始，並回到做出這些決策所需的資料元素。 在某些情況下，我們發現基本資料並不存在，而這會導致藍圖的該元素標示為「高風險」。畢竟，我們現在必須包含以新格式或結構收集資料，以擷取這些新的資料元素，我們甚至可以考慮提供更好的商務程式，而在某些情況下，這可能是高順序。
在關閉目的地程式之前，還有一件事需要做，而這會優先處理最終視覺的不同元素。 在規劃程式的開頭，通常會認為優先順序會單向，但請發現，當您實際記錄它們時，它們會以非常不同的方式進行。 有趣的是，當每個人都對目的地中包含哪些目標達成一致時，對於最優先順序應該是什麼有顯著的共識。
接下來我們需要指示的來源點，我們會透過組織目前與我們所選擇目標相關之位置的清查來管理。
我們將探討現有的人員。 他們是否已針對其特定角色在專案管理中進行訓練？ 我們是否有足夠的人員具備足夠的經驗來完成已設定的目標？ 請記住，我們必須在這裡查看多個量值，因為不同的人員在最終的企業專案管理程式中會有不同的角色。 將每位員工定型為專案排程器並沒有任何意義，因為事實上他們永遠不會負責建立排程。 根據預設，我們會考慮四個角色：系統管理員、專案經理、個別資源和主管。 如果涉及時程表，我們也會將監督員視為第五個角色。 當然，根據我們在原始構想程式中定義的目的地，角色可能會有很大的差異。 這會徹底改變技能清查程式，這就是為什麼我們一律先定義目的地，再思考起點。
我們也會探討現有的程式。 是否有指定或記載的專案管理程式？ 如何維護？ 誰負責？ 如果已建立 Project Management Office，則此處會著重許多心力。 畢竟，如果有已經有效的現有程式和程式，建立新程式就沒有任何意義。 根據 EPM 環境的最終目標，我們可能會清查目前專案管理程式內部和外部的現有進程。
例如，我們可能已決定合約管理將是新 EPM 環境的重要元素，而且這從未成為此組織內專案管理程式的一部分。 不過，如果我們看起來更遠一點，我們可能會發現組織有一組強大的控制項，可用來管理檔，而現有的工作流程已經在移動檔，或許在 SharePoint 中。 這是我們採用的理想程式，如果需要的話，請進行調整，以確保它能夠讓新的企業專案管理環境具備這個層面。 這麼做有三個優點。 首先，我們不需要花太多心力來建立新的程式。 其次，我們知道人員已經具備以這種方式使用程式的技能和習慣，這表示沒有訓練工作或努力讓人員遵守。 最後，我們並沒有嘗試建立個別程式的困難情況，該程式可能與管理檔的現有程式不一致，例如合約。
我們知道其中一個最大的挑戰就是合規性。 不是建置系統，而是讓每個人都能使用它，並以一致的方式使用它。 我們越能採用內嵌在組織中的現有習慣、做法和程式，合規性就越容易。
最後，您需要技術平臺的清查。 由於 Microsoft EPM 解決方案是以技術平臺為基礎建置，因此可能會發現其中一些技術已就緒，但組織可能也必須升級其某些平臺，才能讓您要設計的解決方案運作。 SharePoint 和 SQL Server 是部署 Microsoft Office Project Server 的明顯元素，但您可能也需要檢查瀏覽器相容性 (是否每個人都使用最新版的 Internet Explorer？) ，系統會向外 (安全性狀態？) ，部署的SQL Server版本 (是 OLAP 服務或SQL Server Reporting Services已在使用中？) 。 您可能也需要考慮需要介面或整合的其他系統。 如何在生產環境中存取這些系統？
規劃的系統大小也可能需要查看硬體、網路和其他基礎結構元素，以確保系統在抵達時會有所需的結構。
如同任何企業系統，您會想要規劃生產區域和預備區域，以便在實驗室中建立更新和增強功能，而不是在即時系統上建立一段時間。 您可能也必須規劃試驗或概念證明階段;我將在下一個資料行中深入討論。
「重新計算路由」
當我汽車中的 G.P.S.單位發現我錯過一個回合時，一個非常美的因為我們的聲音會顯示「重新計算路線」。 稍後，透過地圖的線條會變更，而我有新的方向。 在 EPM 部署中，我們必須準備好進行繞道或封鎖修復的回合。 也許我們遺漏了該道結束。 如何處理重新規劃？ 離開課程時，有兩件事需要詢問：首先，您還是要前往相同的位置嗎？ 第二，如何從這裡到達該處？ 我最愛此主題的其中一個專案管理引號來自 Napoleon Bonaparte，他曾說「一個敵人計畫會持續進行，直到與敵人連絡為止」。
在 EPM 部署中，如何套用此相同原則？ 首先，您需要量值來判斷您是否不再進行課程。 如果一位小組成員明天有緊急醫生的約會，而辦公室有四個小時沒有約會，那麼我們應該讓該差異變更所有下游工作，將每個人從明天中午重新排程到專案結束時，然後傳送電子郵件給每個人新的指派時間嗎？
當然沒有。
在涉及數十個人的專案六個月存留期內，一個資源的四小時差異不足以保證變更我們的路徑。 在啟動任何類型的企業專案時，我們需要做的是設定可接受進度的臨界值。 太空人和防禦世界最近會為此「Tripwires」尋找新的詞彙，這非常具描述性。 我們可以建立哪些準則會向我們指出需要重新計算路由。 有幾個一般計量或量值需要考慮。 首先，如果預計完成成本與原始預算相較于 X% 以上，則可能構成專案計劃檢閱。 您可能會以人力時數或金錢來測量成本。 兩者都有效。 如果預測的完成日期與原先規劃的完成日期相差超過 X 天，則可能構成專案計劃檢閱。
您也可以決定遺漏特定重要里程碑超過一定天數是一個 tripwire，或者您可能會將某些風險識別為 tripwire，或者您可能會判斷某些重要專案小組成員的變更，例如執行贊助者是一個 tripwire。 設定一些準則，比完全正確取得準則更重要。 此外，請記住，您需要在整個專案的存留期中根據這些準則進行測量，因此，如果您選擇 50 或 100 個不同的計量，最後可能會花費比執行專案更多的時間來測量專案！
一旦您確定您已不在課程中，重新上線的最佳方式就是進行專案計劃檢閱。 我們建議同時包含來自一開始協助建立目的地的資深管理原始群組，以及來自專案管理小組內協助執行原始清查之群組的標記法。 專案計劃檢閱可能會因為指派專案偏離追蹤的原因，以及為何觸發特定的 tripwire 而深陷其中。 這類工作可能會使結果相反。 建議您將焦點放在下列問題：
該怎麼辦？
我們在哪裡結束？ 我們目前的起點為何？
我們是否仍致力於原始目的地，或有充分的理由來檢閱該程式，或甚至重做構想程式？
我們需要重設任何中繼里程碑或階段嗎？
我們需要變更任何專案小組嗎？
我們需要重設任何 tripwire 計量嗎？
我們發現生產力較低的問題包括：
我們在這裡的錯為何？ 誰負責？ 誰該受到責備？
如何在追蹤上「返回」;回到舊方案？
專案計劃檢閱的最常見原因是組織的優先順序會轉移。 例如，階段 2 中會要求設計為階段 3 的專案。 這通常是組織內狀況良好的動態，以及人們開始仔細思考 EPM 系統部署影響的結果。
天氣不好
在您在長磁片磁碟機上進行設定之前，您可能會檢查天氣通道 (或 weather.msn.com) ，以確保沒有任何天氣狀況會影響您的旅行。 風險是生命的一部分。 請記住，如果沒有風險，就不需要專案經理！ 規劃最明顯的風險並非複雜的程式。 從構想程式的開頭開始，當您查看您要設計之目的地的每個元素時，詢問群組到達這個目的地時可以想到的障礙。 在某些情況下，風險會很大。 組織不常想要特定結果，只是發現傳遞該結果所需的原始資料從未收集過，而且收集該資料可能會有相當大的抗拒。
在其中一個範例中，我們發現組織想要規劃資源容量。 這需要完整會計出所有專案人員的所有資源可用性，並完整計算所有可能套用至這些人員的工作負載。 當我們詢問這兩者是否都可用時，我們得知它們確實可用，但僅適用于組織的五分之二。 當我們接著發現組織中五分之三的資料無法使用，甚至未在構想會議中表示時，我們說：「讓我們猜測一下。 您在規劃資源容量時遇到的問題位於這三個部門中。」當然，我們必須將這些部門的部門主管註冊為專案的個別階段，且風險極高。
當您繼續在清查程式中與專案管理和一行人員合作時，請在面試期間詢問這些人員可能能夠識別的任何風險。
一旦識別出風險，請務必加以組織。 如果您之前尚未這樣做，最基本的資訊將是最有價值的資訊。 包括：
風險的簡短描述
專案可能影響的區域或階段
如果準則已實現，風險的嚴重性
最後，您可以執行的其中一個最重要動作是新增風險降低的一些詳細資料。 只考慮風險是一項龐大的緩和因素，但是當 EPM 部署處於起始狀態時，在專案期間輸入一些您可能如何處理特定風險的注意事項可能相當重要。 當風險實現時，通常會在情緒內容中以雜湊方式進行決策。 有一些在酷炫的頭部占上風時所想出的筆記可能很有用。
讓我們開啟我們要建置的車輛
以下是製作藍圖的秘訣，可能會付出極大的代價：使用 Project Server 和 Microsoft EPM 解決方案來協助制定及管理您的藍圖計畫。 這看起來可能很明顯，但很少能讓組織這麼做，我們在這裡提到它。
我曾經有位資深經理告訴我，他的專案人員曾詢問過他，是否認為使用 Microsoft EPM 解決方案來部署 Microsoft EPM 解決方案不是過度學習。 他們表示：「如果我們以生存方式建置飛機平面，我們就不會將飛機飛至工作。 「您要來吧？」他回復了。 「如果我可以飛出飛機來工作，我每天都會這麼做！」
事實上，使用適用于 EPM 部署小組的 Microsoft EPM 解決方案是不錯的主意。
安裝 Project Server 和 Microsoft EPM 解決方案的其他元素並不是一項重大的技術挑戰，只要設定絕對少，您就可以在幾天內以使用者身分啟動並執行小型部署小組。 對於將成為部署風雲人物的使用者來說，這是一個絕佳的方式，可在系統到達大量員工的桌面之前，熟悉系統的使用和優點。
此部署不應該是您的生產環境。 您幾乎一定會進行設定，並加以自訂，以實現原始目的地的願景。 您幾乎當然不會在 Project Server 的 EPM 部署反復專案中處理多專案排程、資源容量規劃或組合優化等工作，但您將能夠提供可提供絕佳優點的系統。 建議您：
以已發佈的專案執行滾動波排程。
滾動波排程會將目前階段的詳細資料和未來階段醒目提示為摘要。 這可讓小組成員知道他們現在需要處理什麼，並且仍然讓他們在較大的內容中查看專案。
管理專案工作區中的視覺檔。
專案工作區是系結至專案的 SharePoint 網站，預設包含問題、風險和檔的區域。 為何不要將 EPM 部署專案的所有專案檔案放在此處，並建立 SharePoint 的版本控制，讓您一律可以回到原始版本？
將您的里程碑登出和「閘道」放在 Project Workspace 交付專案中。
這是您可以連結到 Project Server 中工作的簡單工作清單。 它會提供非常高階的專案檢視，而且是一種簡單的工具，可用來進行臨界值管理，以判斷您何時要「離開課程」。
將變更管理放入專案工作區作為問題。
變更管理是技術專案的其中一個絕佳挑戰。 當專案變更的新建議出現時，請將它們放入 [問題] 區域，作為要管理的潛在變更。 藉由將幾個欄位新增至此區域，您可以隨時取得高優先順序專案清單，以及負責這些專案的人員。
將專案風險放入 [專案工作區]。
除了檔和問題之外，工作區的風險區域是新增風險和風險降低計畫的理想位置。 事實上，預設畫面有所有欄位可供您使用。
我們到了嗎？
「快了。 我們很快就會出現。」
EPM 部署可將組織帶至許多不同的地方，因此無法直接為每個人發佈預設排程。 但搜尋網際網路幾分鐘後，您可能會針對專案的不同部分提供許多可能的範例。 如果我摘要說明上述藍圖練習，您最後可能會有一個具有一些明顯階段的專案：
藍圖練習
想像 (選擇目的地)
清查現有的進程 (識別來源點)
清查現有人員 (識別來源點)
技術清單 (識別起點)
部署 EPM 小組的 EPM 解決方案
階段 1
Design
設定、自訂、檔
試驗
訓練
推出
檢閱階段 1 並視需要調整階段 2
階段 2
階段 3
階段 4
專案總結
將藍圖練習套用至您的 EPM 部署，可以非常快速地將體驗從輕鬆變更為可管理。 只要記得先挑選您的目的地，接下來找出您的起點，然後繪製它們之間的路徑。
旅行快樂！
關於作者
Chris Vandersluis 是 Microsoft 認證合作夥伴、加拿大 HMS Software 的副總裁和建立者。 他擁有 McGill University 的經濟效益學位，以及超過 30 年的專案控制系統自動化經驗。 他長期隸屬于 Project Management Institute (PMI) ，並協助您找到 Microsoft Project Users Group (MPUG) 的多倫多、多倫多和魁北克章節。 Chris 所撰寫的發行集包括《星號》、《重度建構新聞》、《計算加拿大》雜誌和 PMI 的 PMNetwork，而他也是 Project Times 的一般常客。 他教授 McGill University 的進階專案管理，並經常在北美洲全球各地的專案管理關聯函式上進行討論。 HMS Software 是 TimeControl 專案導向的計時系統發行者，自 1995 年起一直都是 Microsoft Project Solution Partner。
您可以透過電子郵件連絡 Chris Vandersluis：： chris.vandersluis@hms.ca
如果您想要閱讀 Chris Vandersluis 的更多 EPM 相關文章，請參閱 HMS 的 EPM 指引網站 (https://www.epmguidance.com/?page_id=39) 。