上一篇文章介紹了如何分解 WBS 以及專案團隊成員在分解過程中的職責。今天，我想繼續探討我在分解 WBS 時遇到的一些常見誤解，也就是不確定是否應該將某些內容納入 WBS。
誤解一：專案經理的工作是否應包含在 WBS 中？ 專案經理的工作，例如「撰寫專案計畫」、「撰寫會議紀錄」、「取得專案資源」等，當然是專案工作的一部分。然而，要判斷這些工作是否應該納入 WBS，首先需要理解 WBS 的目的。
WBS 的目的是：WBS 的主要目的是將龐大而複雜的專案分解為可管理的部分，以便更妥善地規劃、執行、監控和控制專案工作。
簡單來說，WBS 的目的是為了輔助管理，這表示管理者能更妥善地管理其團隊成員的工作。回到先前的問題，專案經理的工作是否應該包含在 WBS 中呢？簡單來說，這牽涉到專案經理是否需要對自身的工作進行更細緻的管理。如果專案經理認為上述工作非常重要，而且是需要交付給客戶的成果之一，那麼將其納入 WBS 是可以考慮的。反過來說，如果專案經理認為這些工作並非直接的交付項目，那麼可以不包含在 WBS 中。
專案經理應關注如何根據管理原則來運作專案。WBS 是否包含其自身的工作並非關鍵，WBS 的重點在於確保所有產生交付成果所需的工作都被充分分解、合理分配並且能夠有效追蹤。專案經理的主要職責是確保這個過程順利進行。
誤解二：會議產生的行動事項是否應該納入 WBS？ 會議後通常會產生許多行動事項（Action Items），這些事項對於完成專案而言往往非常重要。那麼，專案經理是否應該將這些行動事項納入 WBS、排入專案時程並分配負責人呢？這與排定專案時程計畫類似。我的建議是：不應該將行動事項納入 WBS。請將 WBS 視為交付給客戶的重要依據。會議後產生的行動事項通常包括團隊內部需要完成的工作或客戶需要提供的資訊或成果，這些都是為了達成特定的專案交付項目所必需的。然而，許多行動事項本身並非專案的最終交付項目，而僅僅是重要的「任務」。管理行動事項更有效的方法是使用獨立的行動事項追蹤表進行追蹤。在向客戶溝通這些行動事項時，相較於展示結構複雜的 WBS，這種方式更清楚明瞭，並且有助於相關負責人員更專注於各自的任務。
誤解三：WBS 是否應該包含客戶的工作？ 例如，「確認需求規格文件」、「參與系統展示」、「參與使用者驗收測試」等工作。在深入了解 WBS 的細節後，我認為這些工作不應該包含在 WBS 中，而應該在制定專案時程計畫時再為其分配相應的時間。主要原因是，在進行工作分解時，不應該分散團隊的注意力。團隊需要專注於思考自身的工作，避免將精力投入到客戶的職責範圍。這樣能使團隊更專注於自身的任務。另一方面，正如先前所述，WBS 中上層節點的負責人需要對其下層節點負責。因此，如果某個下層節點包含由客戶提供的交付項目時，上層節點的負責人可能無法完全承擔責任。需要客戶配合的事項應該由專案經理負責協調，因為他是專案中協調各方的關鍵人物。總而言之，WBS 的每個工作包都應該由專案團隊負責完成。將客戶的工作納入 WBS 會導致責任歸屬不清。
誤解四：WBS 一旦建立就無需修改嗎？ 針對這個問題，如果在專案執行過程中發生諸如「WBS 工作遺漏」、「技術問題」、「風險發生」等狀況，導致最終交付給客戶的成果受到影響，那麼 WBS 就需要進行調整。調整後，專案經理需要持續評估其對工作量、成本和時程等的影響。當然，WBS 的修改並非毫無限制。如果專案已進入實施階段，這些調整應該遵循專案的變更管理流程進行處理，以確保專案參與人員了解專案的變更情況及其原因。通常，專案中最大的不滿並非來自於調整本身，而是缺乏明確理由或未被告知的調整。
以上是我初次接觸 WBS 時產生的一些困惑。這些問題曾讓我困擾許久，希望這篇文章能對大家有所幫助。
