由上至下或由下至上
本文是「從馬西斯」集合的一部分。 其會討論專案管理、組合管理和工作管理，並比較與專案相關的由上而下和自下而上管理實務。
若要下載本文的 Word 版本，請參閱 由上而下或由下而上： (Project Server 2010 的白皮書) 。
若要查看更多文章，請參閱 白皮書。
由上而下或由下而上？
「我們需要專案管理... 我指的是組合管理... um，其實我指的是工作管理... 瞗瞗，我們需要他們。」 是一場我經常聽到的激響聲。 這三個概念的定義並不缺乏造成混淆的定義，而在於其相似度。
我們這些已在 IT 中工作許多年的人，通常會從技術觀點來看，有時無法為我們提供良好的服務。 如果我們查看公事包管理、專案管理和工作管理中的資料，看起來可能非常類似。 我有識別碼欄位、描述欄位，以及這三個欄位的開始和結束日期。 那麼，連結這三個應該都是自然的。
也許不會。
讓我們一次一個接受這三個概念。 很容易就能看到其相似性，但三個觀點有基本差異。
公事包管理 - 由上而下的方法
人員可透過「組合管理」來表示許多不同的專案，但最常見的意義可能是專案選取和優先順序。 原則最終會影響組織中的每個人，但該程式對資深主管非常感興趣。 管理會從某些條件約束開始，例如可用預算總計，以及回答「我們可以及應該使用此金額來完成什麼？」問題的需求如果公事包管理程式已足夠成熟，這項分析可能不只包含新的想法，也包含現有的專案。
若要建立公事包選擇和優先順序程式，管理必須瞭解推動公司的商務準則，並事先同意查看新專案和現有專案時將考慮的計量。 投資報酬率應該是關鍵計量嗎？ 或許我們應該考慮對用戶端滿意度或員工保留或與策略目標一致的影響。 無論關鍵計量為何，管理都必須權衡每個專案計劃，以瞭解該專案如何推進這些目標，以及每個專案如何與可用金錢的替代計畫進行比較。
這是高度分析的程式，即使是以一個頭完成也一樣。 當您使用專案組合管理軟體時，這當然是高度分析。 即使軟體的分析抵達報表或檢視，幾乎一律會有一些管理層級監督，其中會對優先順序做出最終決策。 完成時，最終結果必須傳送給將執行每個專案之專案管理的人員。 這些決策的效果是要為某些專案提供資金，而不是為其他專案提供資金、將可用的資源設為某些專案的較高優先順序，而非其他專案，以及提高某些專案的排程，以及延遲其他專案。
專案管理 - 由上而下和由下而上
一旦專案獲得核准，它就會完全移至不同的領域。 現在，專案排程的較傳統檢視已成為焦點。 現在，我們必須在核准之前，實際建置我們在業務理由中所述的專案。
專案經理開始思考專案範圍和交付專案。 專案經理知道必須建立的最終產品，不論是軟體片段，還是可供佔用的建築物。 他們可以考慮該專案的主要階段，並建立工作分解結構。
完成專案所需的邏輯步驟關鍵路徑會進行設計。 專案經理也知道，將會考慮所產生的排程，因此他或她會諮詢專案中的一系列主題專家。 專案經理會依任務查看任務，並將這些工作匯總到專案階段，最後將這些工作匯總到專案本身，以建立專案的自下而上檢視。 此時，專案經理可能也會開始依技能、部門或甚至依名稱配置資源。 這些資源可能會有相關聯的成本。 計算任務工期、所需資源及其速率的結果，可讓我們自下而上估計專案。
目前為止，一切都好。
但是，當我們查看專案組合選取程式的由上而下方法時，也會產生成本。 事實上，專案的預估成本是管理在核准專案時所考慮之商業理由的一部分。 如果我們現在只是從主題專家的合併專業知識取得專案的自下而上預估，他們在執行套件的專案選取中使用了什麼？
這是個不錯的問題。 在某些組織中，專案會從專案部門獲得粗略估計，以建立專案的業務理由。 在其他組織中，會先建立完整的自下預估，再考慮組合程式中的專案。 這兩種方法的問題在於它們需要投入心力。 完整的預估可能需要花費很多心力，但專案尚未獲得核准來為任何工作提供資金。 因此，在許多組織中，管理人員只是猜測此專案的成本。
因此，此程式看起來全都已整合，但這裡可能有一些 catch-22。 首先，要花在執行預估或選取專案的工作，才能將時間花在專案上？
此外，如果自下而上估計值不符合公事包選取程式的估計值，會發生什麼事？ 如果估計值較少，則可能沒有任何問題，但如果工作無法在公事包選擇人員所估計的時間或預算中完成，則會發生衝突。
您可能會認為，要做的自然是重新建立資深管理，並只討論問題，但有許多情況並不像看起來那麼簡單。
首先，公事包選擇委員會很少是專案管理人員。 資深專案管理人員成員幾乎一律包含在公事包選取委員會中，但群組本身通常是非常資深的主管，他們覺得組織時間在一起很困難。 其次，選取委員會可能會不規則地開會，因此，讓他們回到一起討論一個專案與估計值不相符成本的所有影響，可能是一大挑戰。 最後，在某些公司文化中，不必將新聞傳遞給資深主管，讓他們猜測這個專案的適當排程和預算完全錯誤，這不會是職涯前一步的移轉。
工作管理 - 自下而上的方法
當我們思考工作管理時，我們通常會非常有操作性地思考，而這通常會將我們帶入每日議程和 Outlook 之類的產品。
我們現在是在個別或小型小組成員層級工作。 我們在內容中看不到工作。 我們看到我們已承諾的那些專案，或可能是我們要求小組成員認可的專案。 這完全不是分析檢視。 有一些工作需要執行，而個人已承諾要執行這些工作。
工作管理的核心非常簡單。 您會執行工作，而當您完成時，您會告訴提供您工作執行該工作的人員該工作已完成。 此功能的所有功能都已在 Outlook 中。
類似資料的錯誤
有句語句：「如果它看起來像是一隻和技術，而且像是一隻小子，它就必須是一隻小子。」這對於小子而言是正確的，但工作型資料不一定正確。
讓我們考慮下列三個層級的專案導向資料：
在公事包層級，我們有一個專案，而且可能位於該專案下方的階段。 階段資訊可能有代碼號、描述、持續時間、開始日期和結束日期。
在專案層級，我們在專案下方有專案和工作。 工作資訊可能有代碼號、描述、持續時間、開始日期和結束日期。
在該工作管理層級，我們有一個工作，而工作資訊可能有代碼號、描述、持續時間、開始日期和結束日期。
它們看起來確實相同，但事實上，資料的觀點會讓這些相當常見的記錄都有不同的用途。
我經常會問：「我可以將資料從公事包檢視移至專案檢視，再移回 Outlook。」
該問題的簡短答案是「是」。
但在公司中，當我們提供技術建議時，我們會對自己說一個「不要告訴我該怎麼做，請告訴我您該怎麼做」。
若要說明這點，請想像這個範例。 我們建立完全整合的環境。 在規模的頂端，我們有依組合組織的專案清單。 我們不僅會選取這些專案，還會進一步整合，在 EPM 系統將它們啟動至即時專案之後，再加以追蹤。 若要這樣做，我們使用已可供使用的功能，將專案和階段定義從整合式系統的公事包端移至系統的專案端。 資料看起來完全相同。
在企業專案管理系統中，我們現在會使用從上到下推送之組合定義的原始階段，來進行更詳細的定義。 這樣做可讓我們在更新專案時，在組合系統中更新該摘要。 我們進行許多工作，並指派許多資源。 我們現在會進行資源撫平分析，以判斷許多專案之間的容量。
我們會使用資源指派，將工作和指派資料推送至每位使用者，做為 Outlook 工作或行事曆事件。 使用者不再需要移至「專案管理系統」。 他們現在可以在每日議程中查看其資料。 資料看起來就像在專案清單中一樣，而且會進一步連結到公事包檢視。
這些工作的進度和 Outlook 的可用性會從個人移回專案管理系統，以及此工作的完成時間估計值。 資料看起來就像在其他兩個系統中一樣，因此移動資料相當容易。
在技術上，使用現今可用的工具以及一些設定和開發，建立這類系統非常簡單。 而且會以美觀的方式示範。
系統會定期要求我們使用這種類型的結構。 但是，即使我們可以這麼做，還是應該這麼做嗎？
想像一下，在工作層級，一個人為了緊急車程而請假，並更新她的 Outlook，指出她目前早上將無法使用。 這對於他而言是個壞消息，但對專案的波閂效果可能很大。 現在，專案系統會計算排定要在今天上午完成的工作將不會完成;它只會在明天中完成。 它會適當地查看關鍵路徑，以及從這個路徑下游的所有工作，並將它們向前推送四個小時。 可能有數百個工作受到影響。 結果可能會在半天后推送專案的結束日期。 其他專案也會受到影響，因為處理此專案的其他人現在必須重新排列其工作，且公事包檢視本身會向前滑動幾個圖元。
如果我們即時想像這一點，問題就會放大。 每天有數百或數千人進行變更，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) 。