部署企業專案管理的階段式方法

本文說明規劃在您的環境中部署企業專案管理解決方案時,可能會面臨的各種挑戰。 也描述可供使用的多種不同部署案例,以及需要考量的重要先決條件。

若要下載本文的 Word 版本,請參閱 部署企業專案管理的階段式方法:白皮書

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

部署企業專案管理的階段式方法

本文供應商務決策者、網路系統管理員和 Project Server 系統管理員指引,說明您在規劃在環境中部署企業專案管理解決方案時,可能會面臨的各種挑戰。 也描述可供使用的多種不同部署案例,以及需要考量的重要先決條件。

簡介

我擁有一家執行 Microsoft 企業專案管理 (EPM) 方案部署的公司。 公平地說,HMS Software 的執行比這還多。 我們也是 ISV,但我花相當多的時間與中型到大型組織合作,以瞭解它們如何部署 EPM。 有些挑戰是 Microsoft 技術特有的,但許多挑戰與我在 1983 年開始使用專案管理軟體業務以來,公司所面對的挑戰很類似。 我們將在這裡探討如何規劃自己的 EPM 部署。

當我們開始 EPM 部署時,我們面臨的最大挑戰之一,就是建立產生預期結果的可靠藍圖。 雖然我們已在此部署企業專案管理系統超過 24 年,但有一件事沒有變更,那就是資深管理人員希望能在昨天取得所有結果。

挑戰會因幾個幾乎永遠存在的因素而複合:

  1. 銷售小組已向用戶端顯示最終結果,但未說明在生產環境中重現效果所需的工作,或甚至是建立銷售示範中所涉及的虛擬映射和資料投入了多少心力, (通常數個人月) 。

  2. Microsoft 具有易於部署的舊版。 人員已習慣將 DVD 放入其電腦中,等到它快顯,然後立即取得他們購買的軟體權益。 不過,可能有一些選擇性訓練的概念,但很少會預期所進行的是組織變更練習。

什麼是企業專案管理?

這已經足夠挑戰,但用戶端通常會在購買期間忽略其他層面,從「EPM 到底是什麼?」開始 這是一個簡短的問題,可能有很長的答案。 在 EPM 部署的早期階段,我們會使用用戶端的資深管理來進行構想研討會。 我一律使用的投影片如下所示:

列出 EMP 解決方案不同層面的圖表。

「從您的觀點來看,什麼是 EPM?」我會問。 回應通常位於投影片的其中一個圓圈中。 回應可能是:

  • 基本專案管理。 「對於我們而言,企業專案管理表示每個人都會以相同方式進行專案管理,並使用相同的工具。」

  • 企業專案管理。 有人可能會說:「那對我們而言不夠。 「對於我們而言,企業專案管理表示我們的專案管理資料會整合。 我們可以取得在整合式摘要報表中顯示排程的報表,而且能夠管理從某個專案到另一個專案的影響。」

  • (PPM) 專案組合管理 。 「這是關於我們的專案組合管理」,有人可能會說。 「對於我們而言,企業專案管理意謂著在專案層級管理更高層級。 我們需要將專案分組為組合或專案群組,並一起分析和報告它們。 我們必須能夠在此摘要層級追蹤進度,以及實作階段控制。」

  • 資源管理。 「對於我們而言,企業專案管理表示資源容量規劃。 我們不僅需要知道是否可以處理新的專案,以及對現有承諾的影響為何,也必須知道根據專案進度和資源可用性來管理我們已認可的工作狀態為何。」

  • 報表分析。 「對於我們而言,企業專案管理會出現在報表中」,有人可能會說。 「我們需要從專案管理、財務、HR 和其他內部系統提取的報表,以匯總報表以進行管理和決策制定。 在討論報表時,我們也需要動態儀表板、計分卡和其他可見系統。」

  • 預算和成本管理。 「對於我們而言,企業專案管理是與金錢有關。 我們在年初預算。 然後,我們會針對每個專案進行預算,唯一重要的是逐月追蹤計畫的費用。」

  • 時程表。 「請不要介意規劃。 如果您只知道我的人員實際花費在什麼時間上,我們現在就已經領先,我們稱之為 EPM 成功。有人常說。

  • 通訊和共同作業。 「與花式演算法無關。 我們需要協助與我們的人員交談。 您是否可以協助我們連線我們的專案小組,這些團隊現在不只包含規劃人員,也包括資深管理、用戶端、使用者、子約聘人員、外包商和小組成員?」

  • 與外部應用程式整合。 「我們有一個很棒的 ERP/Finance 系統,不同之處在于我們對專案管理隨附的交付專案和成本沒有任何前向預測。 如果您可以將專案管理工具與我們的 ERP/Finance 系統連線,那會為我們提供大量的企業專案管理!

  • 工作流程。 「我們預計系統不僅會以自動化方式追蹤工作,還會追蹤程式。 我們希望專案經理填寫線上表單來要求專案資金,然後移至負責人員,然後以自動化方式接受或拒絕要求。 如果核准,專案會立即包含在 EPM 系統中。 我們想要對所有專案檔案執行相同的動作。 事實上,我們想要透過工作流程管理,以這種方式將所有專案管理程式自動化。 這實際上是企業專案管理。」

  • 商業智慧。 「我們需要的是專案資料的計分卡、儀表板和資料採礦」,有些人會告訴我們。 這會是最終的企業專案管理環境。」

  • 專案管理成熟度模型。 「我們正努力改善依「專案管理成熟度模型」所測量的成熟度層級。」

那麼,正確答案是什麼? 它們都沒問題。 事實上,它可能不是詳盡的清單。 EPM 對許多人而言可能代表許多事物,而且高度取決於您從中查看問題的觀點。

當我們使用資深管理來執行這項操作時,通常會發生這種情形,就是沒有不需要的這其中一個層面。 是,人們想要全部。 而且,當他們在 Microsoft EPM 解決方案部署中詢問這一切是否都可行時,有抱信的答案是「是」。 問題在於,EPM 的每個層面都可以視為向量,或是您可以推送 EPM 環境的方向。 如果我們決定在第一天推送所有這些向量,我們最終設計的專案大小將會很大,因此可能會造成干擾,如此複雜,而且牽涉到許多其他公司系統,因此幾乎不可能成功。

EPM 部署牽涉到策略、人員、程式和技術。

請記住,企業專案管理部署不只是技術。 如果是,實作會在幾天內結束。 否,EPM 部署牽涉到策略、人員、程式和技術。 成功的 Microsoft EPM 解決方案部署幾乎一律會將專案視為「變更管理」專案,而不是技術專案。 我們想要完成的是變更企業運作方式。 怎麼做? 根據構想練習的方向而定,方向可能非常不同。

如果我們嘗試同時實作每個層面和每個方向,我們最終可能會建立一個複雜且難以瞭解的龐大專案,而這只會讓部署變得更具風險。

EPM 部署方法

讓我們討論一下有多少人接近 EPM 部署。 有幾種可能的案例:大孟加拉國文、立即孟加拉國和階段方法。

巨匿

Big Bang 理論指出「讓我們一切完成!」其概念是,我們將花費大量時間來設計、建置、重寫和設計最終的企業專案管理環境。 這需要程式設計人員的分段,而未來某個時候,我們會在指定的週末切換開關,每個人都會有企業專案管理。 如果我們要將此圖形顯示為一段時間的投資報酬率,看起來會像是右側的圖片。

顯示專案結束之前沒有投資報酬率的圖表。

使用 Big Bang 理論有加號和減號。 此外,相較于其他類型的方法,最終結果會更接近原始意圖,還有更好的機會。 畢竟,小組在核取專案開頭建立的所有需求之前,都不會待用。

不過,負面方面有幾個重大挑戰。 首先,在專案完成 100% 之前,組織不會收到任何投資報酬率。 這可能是幾個月或一年或更久的時間。 專案不完整的每一天,都是有人以「更好」的想法在建築物中四處流覽的一天。 此外,生命的本質是它會變更。 任何小組變更、管理變更、公司任務或策略變更、基本技術架構變更、公司擁有權變更,都可能導致專案重新建構或取消。 如果發生這種情況,組織不會收到任何工作。

立即孟加拉國文

當我們討論 Microsoft 之後舊版的立即滿足時,會看到不同現象。 有些用戶端會假設部署 Microsoft EPM 解決方案就像玩 Microsoft Game 一樣。 我們會在 DVD 中載入,稍後我們會以協調、共同作業的方式執行專案。 投資報酬率在幾天或甚至幾周看起來都不錯,因為對新系統最興奮的試驗群組開始使用它。 不過,如果沒有資深主管的投資,就很難影響文化或行為變更,而且專案很少會擴充。 系統會持續使用一小段時間,然後由少數使用者放棄或繼續使用,而這些使用者通常會因為無法吸引組織的其他人員共同作業而感到挫折。

顯示早期投資報酬率很小的圖表。

階段式方法

多年來,我們發現分階段方法是部署企業專案管理環境最成功的方法。 有許多原因。 以下是一些:

  • 首先,組織會在程式初期開始收到投資報酬率。 這有助於保護實作,並驗證管理他們一開始就執行 EPM 部署的決定。

  • 其次,部署會以波為單位來解決技術挑戰,而不是一次解決所有挑戰。 隨著系統的複雜度增加,組織處理該複雜度的成熟度也隨之增加。

  • 第三,部署可簡化一段時間對組織的文化變更,這一律會比較容易。 這是變更造成混亂的截斷原則。 在管理專案時,這種變更會有一些挫折是確定的。 隨著時間部署整個願景,可讓使用者適應不同的商務方式。

  • 最後,無論組織在執行原始設計時花費多少時間,只要看到系統在運作中,就一定會改變心意。 稍早將部署的第一個階段進入生產環境,可讓組織在繼續進行時從中學習。

在階段式方法中,投資報酬率是穩定且累加的。

此計畫最重要的元素是第一個階段。 我們會指示我們的顧問判斷「盡可能最少的部署,這會傳回持續的正投資報酬率」。我已非常仔細地說。 我們想要尋找可投入生產的第一個部署階段,以提供結果,而且每週會提供比產生結果所需的更多好處。 如果我們這樣做,部署將會永久持續。 沒有人會移除部署,因為他們會說:「天哪,我們無法移除,我們每週都會從中取得'this'。」如果我們成功建立這種部署,我們將能夠在接下來的幾個月內建置該部署。 如果不是,專案和部署仍然非常有風險。

開始使用您的 EPM 部署策略

如果我讓您三次考慮執行 EPM 部署,那可能是個不錯的事。 您不應該這麼做,但成功的 EPM 部署一律會以一些額外的思考開始。 那麼,您應該如何進行部署? 讓我們從一些必要條件開始。

1.Project Management Office

如果您打算部署企業專案管理環境,就無法擁有企業專案管理組織。 這通常稱為 Project Management Office 或 PMO。 您可以隨心所欲地呼叫它,但必須集中管理系統,例如 Microsoft EPM 解決方案。 誰會將範本宣告為「官方」範本? 誰將決定誰有權變更資源優先順序? 誰將判斷報表的外觀,以及誰可以存取它? 誰會決定是否要管理風險,如果是的話,哪一個程式必須圍繞它? 依此類推... 否,PMO 是不可或缺的。 如果您沒有這類組織 (即使它是一個人) ,則您必須從該處開始,作為您 EPM 環境的最早步驟之一。

2.主管贊助

接下來,取得資深管理層的贊助和支援。 誰從執行套件支援此專案,不僅需要知道部署的目標為何,也需要多久的時間才能提供支援。 我們通常會告訴主管至少規劃一整年的贊助責任。 我們經常看到的其中一個陷阱是一小組的中間管理或專案經理想要企業專案管理環境,但缺少主管層級支援,並決定他們會嘗試自行進行部署,以取得該支援。 這是一個「建置它,他們將會實現」方法的「實現」領域,而且幾乎永遠不會成功。 問題在於,對管理 (非常有吸引力的優點,例如 PM 方法合規性、全域專案報告、資源容量規劃,以及共同作業專案管理) 是只有參與管理才能達成的優點。

3.我們身為專案經理 - 不需要專案管理!

如果您想要避免 EPM 部署最常見的陷阱,請建立專案計劃。 我知道這聽起來很簡單,但事實上有多少個 EPM 部署專案沒有專案計劃,這真令人驚奇。 我們可以提供給考慮部署 Microsoft EPM 解決方案之組織的最簡單建議之一,就是將它設為專案,並套用其已用於任何其他專案的相同方法。 是否有專案排程;預算;執行贊助者;專案許可;資源;成功計量? 這些專案可能會在組織中的所有其他專案中找到,但就像鞋業者的子系一樣,專案經理通常會忘記將自己的技能套用至自己的專案。

4.設定目標

請在專案的一開始,判斷每個階段的成功量值。 擁有一組清楚的效能計量,不僅有助於專案小組,也有助於管理著重于完成專案的階段。

快速入門

如果您想知道如何開始使用,以下是一些建議。

展望

從與資深管理加速的視覺會話開始。 如果您在專案的其他方面使用外部協助,您會發現它在這裡最有用。 擁有已參與數個其他 EPM 部署的人員是成功的關鍵。 我們不只是在討論曾經是 EPM 系統使用者的人員,還討論過上述所述的一些問題,以及對 Microsoft EPM 解決方案的功能以及組織中專案管理程式有充分瞭解的人員。

誰?

您必須提早決定的其中一件事是,誰是「企業」? 我已在本文中使用過該字詞數次,但企業可能代表您決定的一切。 這是您的部門、部門、整個公司嗎? 執行部署的一個常見錯誤是為整家公司制定計畫,但只擁有自己部門的授權。 希望其他人在系統可用時能上線。 這是一種關於「大寫欄位」方法的變體,它可讓解決方案對那些其他部門沒有吸引力,而且對於您擁有授權的部門而言並不實用。 因此,請及早決定誰將參與,並確定他們已包含在規劃中。

製作專案計劃

就像您對任何其他專案所做的一樣,請花時間進行適當的專案計劃。 線上提供許多方案,可為您提供一些您需要涵蓋之主題的指導方針。 這是很好的起點,但您幾乎可以擁有為 EPM 部署制定適當專案計劃所需的所有技能。

總結

如果您考慮或已開始部署 Microsoft EPM 解決方案,請考慮下列三點來專注部署:

  1. 將此專案視為專案。 使用您在管理專案時已經具備的所有技能來管理 Microsoft EPM 部署專案。 請記住,它主要是變更管理專案,而不是技術專案。

  2. 將專案分成可管理的片段,並將專案的每個階段視為具有自己成功計量、排程、預算和資源的子專案。 您將能更快速地獲得整體系統的一些優點,這有助於從管理取得更多支援。

  3. 請記住,投資報酬率必須可在每個層級運作。 建立適用于資深管理但不適用於必須管理該系統之人員的系統並不夠。 或者,適用于專案經理但不提供資深管理所需報告的系統。 或者,適用于專案經理和資深管理,但對於個別使用者而言太困難或太費力的系統。 每個必須投入時間和精力來使用系統的人,都應該根據自己的投資報酬率來考慮。

如果您要設計遵循階段式方法的部署,並使用您已經針對其他專案使用的基本專案管理方法,您有絕佳的成功機會。 祝您快樂,規劃快樂!

關於作者

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) 。