他們說他們想下個決定
本文是「從馬西斯」集合的一部分。 其中描述您在排程專案時可能會遇到的一些常見挑戰。 其中描述當您嘗試判斷工作應該有多長，以及應該有多少任務要優化專案排程時，會提供最佳方法。 其中討論不同產業通常需要不同類型的排程 (例如軟體發展、EPM (工程、採購和建構) ，以及工廠關機) 。 它也會討論選擇專案解析 (的數個因素，例如專案長度、涉及的資源、管理或劃分資源、收集資料所需的速度和精力，以及資料更新排程) 。
若要下載本文的 Word 版本，請參閱 他們說出他們想要解決方案： (Project Server 2010 的白皮書) 。
若要查看更多文章，請參閱 白皮書。
他們說他們想下個決定
使用適用于標題的 Beatles 拓撲，現今的主題是您專案的解析。
有許多關於如何進行排程的材料，但其中一個最重要的課程很難獲得—您應該在專案排程中有多少個工作，以及每個工作應該有多長？
我經常想要使用看起來不可能很複雜的專案排程，或是因為排程在這樣的摘要層級，而似乎不想在排程中找出問題的專案經理。 我看過超過一百年的專案， (是，真的) 非常適合的長度，而且有幾十年的工作。 我也看過只持續一小時或更短且完全適合的專案排程，而且有些工作只持續一分鐘。 我看過只有少數幾個任務的專案，以及其他具有超過 100，000 個任務的專案。
我們目前使用的軟體可以處理數千個工作和廣泛的持續時間。
那麼，何謂正確方法？
工作應該要多久，以及必須將專案排程優化多少？ 我會將此稱為專案的解析。
不同人員的不同筆劃
由於不同產業、不同類型的專案和不同情況的需求可能不同，因此讓我們看看如何決定要在排程中放入多少任務，以及工作應該要多久。
不同類型的專案自然會呼叫不同類型的排程。 讓我們思考三個不同的範例：
軟體發展。 許多軟體專案都有共同的特性。 雖然每個軟體專案都是唯一的，但通常會有設計階段、程式設計階段、品質保證階段、檔階段和部署階段。 軟體專案通常以周或月為單位來測量，而且適合用於一天到數周的工作。 這裡的資源配置通常會指派給個別層級。
那些已接受敏捷式程式來開發軟體的人員會想要縮短一到兩周的「短期衝刺」，而在該短期衝刺內，則會放置簡短持續時間的工作，但整體專案持續時間仍以周為單位來測量。 稍後我們將深入討論敏捷式開發。
EPC - 工程、採購和建構。 EPC 專案是關鍵路徑排程方法開始的地方。 在這類專案中，正在開發一些非常龐大的專案。 它可能是一個大型防禦專案，例如為 PERT 圖表提供啟動的北極星號專案，也可能是船油鑽機、新船或發電廠。 在這些類型的專案中，有一個工程階段會設計完成的專案。 工程階段通常有一些從未設計過的層面。 採購階段會探討如何尋找、合約和管理專案的專案之供應專案或子合約的傳遞。 在建構階段中，會建構最終產品，然後再進行使用。 我們通常會將 EPC 專案排程考慮為數個月或數年，活動持續時間會持續數周到數個月。 在這類專案上有 5，000 到 20，000 個任務完全不尋常。 這裡的資源排程幾乎一律指派給技能等級而非個人，而 (只是為了新增到有趣的) 可能會有許多子專案組成程式或主要專案，以方便管理。
工廠關機。 當您針對工廠關機和復原進行維護執行專案排程時，您會在其中一個最具挑戰性的排程環境中工作。 工廠關機以進行維護有兩種類型：計劃性和緊急。 讓我們暫時將緊急類型保留在一旁;它本身是一個世界。 計劃性工廠關機的持續時間高度取決於工廠類型。 例如，電力發電廠單位可能會在 12 個月內進行「快速」的工廠關機和復原。 油料可能持續 4-6 周。 但我發現最有趣的工廠專案排程類型是製造工廠，例如工廠、紙張廠或類似專案。 全世界有數千或數萬個這類植物，而且必須每年進行一次定期維護。
這些情況的關機成本通常以商機成本來測量;工廠閒置並進行維護時，不會產生的產品成本。 此成本是以小時為單位，而成本可以超過每小時 $150，000 到 $250，000 美元！ 因此，壓力是以分鐘為依據來完成工作。 在這種情況下，關機通常會持續 5-8 天，而單一天的延遲會以百萬為單位計算。 如果您只習慣使用更長、更傳統的排程，您可能會認為在短時間內「通常會有多少任務？」，但這類關機完全不尋常會有 2，000 到 4，000 個工作，每個工作都持續 15 分鐘到數小時。 這裡的資源指派是透過技能來完成，但資源撫平很少會在人員上完成。 由於每小時的成本非常高，因此，如果您將更多人放在專案上並不重要，只要在急迫中完成即可。 在此情況下，資源撫平通常是針對高度受限的瓶頸而完成。 例如，「我們只能在電室中容納兩個人，因此必須以離散方式管理」。
好的，我們現在有三種範例，還有更多範例，但這三種範例可滿足討論的目的。 在類型 1 (軟體發展) 中，我們會取得通常一天或兩天到兩周的工作。 在類型 2 (EPC) 中，我們會取得數周或數個月的工作。 在第三種 (工廠關機) 中，我們會取得以 6 分鐘為單位 (1/10 小時) 、10 分鐘、15 分鐘 (1/4 小時) 來測量的工作，最長可達數小時。 很明顯地，在某些情況下，短期工作是合理的，而其他較長的工作則更適合。 遵循相同的邏輯，有時候有大量的工作是合理的，有時只是沒有。
選擇專案解析的因素
使用這三個區別，很容易就能看到兩個月的 EPC 專案工作在六天的關機排程中看起來很不錯，而且 15 分鐘的工作在 EPC 或 Software 專案中會不在。 但是，除了回頭提到這篇文章並說出「Vandersluis 說它是軟體專案，所以任務只能是 1-10 天」， (和請勿這麼做，) 專案有哪些特性告訴我們要選擇哪一層解析度？ 讓我們看看一些明顯的問題：
專案多久？
讓我們從最明顯的開始。 如果您的專案預期會有幾天的時間，例如我們的關機範例，則擁有數天長的工作完全沒有意義。 當我們考慮將範圍子分割時，從上而下的方法開始通常會具生產力。 使用工作分解結構思考。 從主要元件開始。 請考慮不小於 4 且不超過 20 個專案。
這是規則嗎？ 否，當然不是。
這是一個共通的。 小於 4 可讓您想知道為何您將工作分割在一起，而超過 20 個工作一次都難以保存在一個人的腦海中。 個人而言，每個 WBS 元素最多隻能有 8 個專案，這是因為我在數年前讀過的一些文章，建議八角形是最複雜的簡單圖形，因此可以立即辨識心意。
請稍候思考一下。 您可以識別圓圈、三角形、方形、凸體、有 6 面的十六進位、有 7 面的十六進位 (確定，也就是難以將) 和八邊形視覺化。
您是否可以在不計算的情況下識別 9 面圖形？ 我不能。 它對您來說稱為「nonagon」。
因此，我個人致力於 8 個專案的限制，但我的經驗法則是 4-20。
針對您所查看的每個元素，請思考您應該如何分割工作。 同樣地，請考慮 4-20 規則。 但知道何時停止是秘密。 較新的專案經理會進行子分割、子分割和子分割，直到每個逐步執行的作業都是受控工作為止。 您可以詢問自己工作長度的一些良好水區問題可能是：
如果此工作已延遲，我該採取什麼動作？ 如果答案為「無」，則表示您所想的工作太小，不值得管理。 如果是這種情況，您會看到太多詳細資料。 備份層級，後退一步，看看是否已完成。
收集此工作更新的資料是否需要比工作本身更長的時間？ 我們不一定會想出管理排程工作需要花費什麼心力，但即使有一段時間，還是值得考慮的。 如果管理工作所花費的時間超過完成所需的工作，則表示工作定義的詳細資料層級太細。
這項工作需要多久時間？ 當我們進行子分割工作時，有時會看不到任務的減去程度。 最上層的大階段可能長達數周，但是當我們降低數個層級的資料細微性時，我們可以輕鬆地進入定義要管理且僅需幾分鐘時間之工作的陷阱。 當我們開始進行小型工作時，必須詢問管理這些工作的好處為何。
讓我們將實境檢查套用至我剛才提到的內容。 在兩年的 EPC 專案中，如果一周的工作晚了一天，幾乎絕對不值得採取動作。 在六個月的軟體專案中，延遲一天的一周工作可能不值得採取動作。 在六天的關機專案中，延遲一天的一周工作是大規模的緊急狀況。 換句話說，EPC 專案中的一周工作可能太細細的詳細資料層級;在軟體專案中，它可能只是正確;在 Shutdown 專案中，幾乎可以肯定地將它細分為更多詳細資料。
涉及多少資源？
我知道我們只在處理範圍，但當我們查看需要何種解決方式時，值得思考一個工作上有多少人正在工作。 例如，在大型 EPC 專案中，我們可能會有數十個來自一項技能的背景工作參與工作階段。 但是，當我們最終在相同工作中擁有許多不同的技能時，管理該工作會變得非常具挑戰性，如果不是不可能。 因此，在這種情況下，可能需要許多不同技能的工作可能必須分割。
在軟體專案中，我們通常會將每個人視為具有獨特功能的高技術資源。 此外，在軟體專案中，通常有許多工作可在部門內重新指派，但只有一個工作指派給一個人。 因此，當我們將工作配置給特定資源群組或部門的單一層級時， (例如介面程式設計) 我們就足以表示我們不需要更多詳細資料。
如何管理或子分割資源？
如何管理資源對於如何細分您的工作而言是一大決定性。 例如，在大型 EPC 專案中，專案通常會切割成子專案，而這些子專案會分割成龐大的子約聘人員。 在此情況下，我們需要執行幾件事：
以可讓專案經理監督子約聘人員的方式定義工作，並確信正在進行的進度是一大因素。
定義工作的方式，讓子承包商的專案管理和工程人員瞭解其意義，而不會模棱兩可。
請確定子約聘人員已瞭解並同意您採用為標準的解決層級。
當我們查看軟體、生物研究或工程等白營運專案時，很可能會遇到矩陣管理結構，其中專案經理不擁有任何資源，而且我們必須跨跨許多不同專案配置這些資源的部門經理工作。 在此情況下，主要問題會是：
資源一天可能會處理多少個專案？
員工從某個專案切換到另一個專案需要多久時間？
是否已定義工作，讓員工和資源部門經理都瞭解如何為其配置正確的技能？
當我們查看關機或建構專案時，我們通常會跨專為建置的專案工作。 在這些情況下，資源小組負責人可能會管理電力小組 (，即使該小組包含木工和管線配接器) 、管線小組或「電工單位輸送小組」。 工作的組織方式必須是讓小組人員在整個班次中保持忙碌，而且不會到達已在該區域中工作的另一個小組。 由於關機專案完成的強大壓力，工作通常會依工作先組織、排程，然後由資源小組負責人重新分組，然後再由資源小組負責人進行子分割，讓每個小組負責人只能在一份檔中逐步執行其工作，而整個專案則在另一份檔中進行。 因此，工作必須以員工和資源小組負責人可理解的方式定義。 此處的工作可能定義為小時，或更細微到一小時的第十或四分之一。
收集資料的速度和花費多少心力？
當您習慣在一周結束時看到所有專案資料都順利地排列以供檢閱時，這聽起來像是一個不錯的問題，但是當您嘗試判斷專案的解決層級時，這可能是一個重要問題。 例如，當您處理許多子約聘人員時，您可能會收到某種每週或每月的更新。 事實上，將專案管理更新子句建置到您的合約中是不可或缺的。 在此情況下，您必須將這些不同公司的資料整合到您自己的公司、驗證進度資料是否合理，然後進行您自己的分析和報告。 在 EPC 模式中，這可能是每月發生一次。
在關機專案中，您必須在每個班次更新專案、快速更新專案，並在下一個班次中取得資源小組負責人的更新。 在此情況下，專案人員會在輪班期間將整個工廠集中，盡可能以接近即時的方式在 中收集資料，並讓資源小組負責人和 Foremen 使用「下拉式」工作表來「取下」其工作分派的進度。 在軟體或研究專案中，您可能正在進行每週排程，或是個人報告自己的進度，並在一兩天后通過核准。
當您查看專案中要有多少任務時，這是要考慮的重要點，因為收集資料需要花費一些成本。
因此，考慮如何快速收集、核准、整合、分析及定期報告資料是關鍵事項，也就是收集資料的成本和所收集資料投資報酬率的考慮。
我們要更新多久一次？
以下兩個索引鍵可決定您可以收集和包含的資料量：
請思考如何收集資料。
請思考您可以合理地更新專案的頻率，並提供管理所需的決策工具，以引導專案和資源朝正確的方向進行。
我看到一些專案經理認為他們想要移至「即時」專案管理和專案集合，雖然這在理論上是可行的，但實際上卻很難實現。
當我們查看專案管理資料時，會進行一些假設。 我們假設：
資料全都存在。 我們不預期會查看一些已更新的工作，以及其他未更新的工作。
資料全都已在類似的時間更新。 我們預期幾分鐘前不會更新一半的工作，但另一半尚未更新兩周。
資料全都經過某種程度的核准。 我們預期專案經理會支援所呈現的資料，而且能夠說「這是專案公平且精確的標記法」。
資料屬於一起。 除非我們特別以這種方式設計報表和分析，否則我們預期成本和資源的風險不會模糊。
我經常詢問那些對即時專案管理概念感到興奮的主管，如果我們能夠克服我剛才提出的重點，他們會怎麼做。 「您是否準備好在一周中制定管理決策？」我會問。 回應應該取決於解析度層級。 在關機專案中，答案最好是「是」。 在軟體專案中，答案可能是「否，我們將每週執行該動作」。 在 EPC 專案中，答案會是「每月」。
在某個時間點，遞減傳回法開始說：「更快地傳遞專案報告並不會讓我們提高效率。」
檢閱您的工作
您現在已經有一些要思考的食物，您已使用「工作分解方法」來細分您的資料，而且您已監看一些警告訊號，指出資料定義太精細。 現在可以將排程靠在牆上、往後一步，並以一些觀點查看專案。 令人驚奇的是，許多專案經理永遠不會這麼做。 他們會在定義最後一個詳細資料時遇到問題，而且一次又一次地忙碌子分割工作，因此會將自己推送至上線期限，而且永遠不會查閱他們所做的內容是否會成為管理的必備物件。
在某些情況下，主管在所有 MBA 訓練中都確定「更詳細」，並針對六個月的專案推送這 5 分鐘或 15 分鐘的工作。
在專案開始之前變更專案一律會比之後的任何時間更輕鬆，因此請在您的排程建置活動中建置時間，以視需要重新處理排程。
是否太多？
有時候專案經理會查看他們所建立的範圍，並瞭解他們太細微的詳細資料層級。 如果是這種情況，則修正是很明顯的。 這可能需要許多工作，但您稍後會感謝自己，藉由上移層級讓排程更簡單。
有時候圖片不是那麼簡單。 在某些情況下，只有在整個排程組合之後，專案經理才會看到其複雜度。 複雜專案本質上是現今經濟中風險較高的專案，也是專案的重要選擇因素。 在進行這類複雜專案之前，值得考慮的一些問題可能是：
我們可以分段執行嗎？ 某些有風險的專案可以分成較小的小規模部分，而當較小的專案時，其風險就會降低。 不過，如果您使用此策略，則每個離散專案在完成時都應該有自己的值。
我們應該重新思考範圍嗎？ 有時候，最簡單的動作是先回到工作的設計工具，說明排程中看似明顯的複雜度，並查看是否可以重新整理工作。 這通常會導致永遠不會有機會發生的創新思考。
我們應該這麼做嗎？
有些專案從來都不是，而取消專案最便宜的時間是它們開始的前一天。 如果現在才明顯發現專案的風險，最好是立即實現它。 當您將執行排程的結果儲存回 Project Portfolio Management (PPM) 程式時，您可能會發現較複雜的專案風險在投資報酬率方面的工作分數會更差。
靈活... 否，敏捷式專案
我承諾要說一些有關敏捷式專案管理的事項，如果您是敏捷式風扇，而且您已經閱讀過這一點，我感謝您的耐心。 透過 Agile 方法管理軟體專案是一個原理，但對於已嘗試大量軟體發展專案失敗的人而言，這是一個越來越熱門的原理。
在敏捷式軟體發展世界中，我們嘗試將專案分成一到三周的小規模「短期衝刺」，而每個迷你專案的目標就是最終使用可使用的程式碼。 在此情況下，我們會在一些相當已知的條件約束內運作，因此我們幾乎會挑選我們的解決層級。
我們有一到三周的時間範圍，這些資源可供我們使用，而且我們會將工作指派給每個資源。 我們可以在該結構中定義的可能工作數目是有限的，這有助於維持適當的解析度層級。 是，您可以藉由定義太短的工作，在 Agile 中遇到問題。 「Define Field1： 10 minutes， Define Field2： 10 minutes， Define Field3： 10 minutes」 etc.
Agile 是專為公司開發環境所設計，我們會在其中建立軟體以供內部使用，而且其用途通常會延伸到商務軟體開發。 (我們會在 HMS 使用 此方法來開發 TimeControl.) 敏捷式方法會產生更靈活且靈活的開發部門，但不會適用于每個產業或甚至每個軟體公司。 如果您要在軟體環境中進行專案管理，我的建議是閱讀 Agile、從中學習，然後採用這些元素 (全部、部分或無) ，讓您更有效率。
總結
與專案管理的大部分層面一樣，一開始似乎如此明顯的問題並沒有設定的答案。 您在專案中有多少個工作，以及每項工作應該要多久，是您需要自行決定的一件事... 但決定您必須。
選擇您的專案解析層級是專案管理責任，可以是專案排程管理的關鍵成功因素。
關於作者
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) 。