close
5.1概論
製作WBS的方法很多。它可以是一個全新的文件，或使用現有的WBS，或可參考WBS模版，或可依據前文所定義的WBS標準。當使用現有的WBS組成成份時，WBS要素可以從相似專案或WBS模版擷取出來，採用哪種方法端視組織覺得哪種方法最適當。
本章討論製作WBS的方法，同樣的在發展WBS時有一些因素必需考慮到。本章的某節欲提供一個發展WBS的指引，在其它節則提供發展及優化WBS的查核表。本章後續也下列節：
5.2準備開始
5.3必需考慮的一般因素
5.4基本判斷
5.5WBS品質評估
5.6WBS全面(CONTINUUM)用法
5.7計劃及組合管理的WBS
5.8總結
所有專案、計劃、組合管理的需求條件(Requirements)，在發展WBS時必需被考慮。專案成功的重要因素是製作一個高品質的WBS。
5.2準備開始
WBS必需反覆的考慮下列因素：專案的目的與目標(包含商業及技術上的)、功能及績效標準、專案範圍、技術表現需求條件及其他技術屬性。一個高層級的WBS*往往在專案的早期概念階段就能發展出來。一旦專案定義及規格確定後，就能產出較詳細的WBS。WBS的致作必需滿足專案的個別需求與條件。所有非必要的工作及可交付成果，都必需被移除，讓WBS只展現專案的範圍，不能多也不能少。WBS的最終結果是代表專案完整的可交付成果。
*註：高層級就不精確。低層級就會精確與詳細。
WBS能協助專案經理與利害關係人清楚的溝通專案的最終產品，以及產出最終產品的所有流程。它可幫助溝通必需完成的工作，以及期中及期末必需完成的可交付成果。當發展WBS時，下列問題清單必需同時考慮：
●專案章程是否已定義清楚並發佈？
●專案範圍說明書是否已定義清楚並發佈？
●專案經理及其團隊是否以規劃出專案的最終產品、服務或結果？
●是否有指派專人負責製做作WBS？
●專案的組成成份是什麼？
●如何將個別工作結合？
●什麼是必需做的？
●專案意圖達成的商業目標已界定清楚？完成商業價值的要求是什麼？
●整個專案都被徹底的考慮過了？高層級的可交付成果是否已被逐步的分解了？
●所有的可交付成果(包含期中、最終成果)都已辨識清楚？
●每個WBS組成成份與最終產品的關係都已辨識清楚？這些WBS組成成份對最終可交付成果有何貢獻？
●可交付成果產出的流程都已辨識清楚？什麼方法被使用？需要什麼特定的流程？品質要求標準為何？必需有哪種檢視需求？
●支持可交付成果的所有必要活動，都已辨識清楚？包含那些直接、間接有助於可交付成果產出的活動？
●來自技術專家的技術意見，是否與主要技術專家溝通過？是否有被主要技術專家驗證過？
●專案所需的任何外部資源，都已辨識清楚？
●與風險管理有關的所有工作，已辨識清楚？風險與專案假設的關係，都已辨識清楚？
這些想法及問題意圖幫助專案經理發展一個清楚的產品說明。這些必需不斷的被檢視，直到所有問題都被完全的辨識及所有訊息都被知悉為止。一旦完成，所有的工作包將可構成專案可交付成果的完整清單。
5.2.1準備方法
許多的方法與工具可以用來產出WBS，包含綱要、組織圖、魚骨圖、腦力激盪技術、由上而下及由下而上的發展策略。WBS模版、企業指導方針或標準能做為WBS發展的參考或快速的複製。
使用工具來發展WBS有許多的好處。例如，在發展WBS時，工具常常能促進一致性及重複使用，特別是生產力工具。WBS工具同樣能促進並強化組織的WBS指導方針或標準的原則。也能顯著的降低WBS發展所需的力氣，簡化WBS流程，甚至促進WBS要素的再使用。
一些較常使用來發展WBS的方法，包含由上而下途徑、由下而上途徑、企業指導方針或標準及WBS模版。何種方法較適合，端視專案目標、需求條件、假設與限制。表5-1點出了一些前述所介紹方法的好處與挑戰。
製作WBS方法 | 好處 | 挑戰 |
由上而下途徑 | ●專案的結構化便於進行狀態報告 ●幫助確認專案具備邏輯化架構 ●利於腦力激盪∕發現專案可交付成果 ●便於增加額外的可交付成果 | ●需要持續的關注是否有工作包被忽略了 ●WBS必需詳細到足以進行管理與監督控制 |
由下而上途徑 | ●以所有的可交付成果及工作向上歸納至專案 ●確認所有工作包都已包含在內 | ●在製作WBS前就辨識出所有可交付成果 ●確認工作包被有邏輯的分類 ●可能對專案的完整性失焦(見樹不見林) |
WBS標準 | ●格式都已事先定義 ●強化跨專案WBS的一致性 | ●讓專案符合標準 ●可能會包含不必要的可交付成果而漏失專案獨特的可交付成果 ●並非所有專案都能符合高結構化的WBS標準 |
WBS模版 | ●提供製作WBS的起點 ●可以幫助決定所需的適當詳細層級 ●強化跨專案WBS的一致性 | ●專案需要符合標準 ●可能會包含不必要的可交付成果而漏失專案獨特的可交付成果 ●並非所有專案都能符合高結構化的WBS模版 |
表5-1 WBS製作方法
5.2.1.1由上而下途徑
下文描述使用由上而下途徑發展WBS的步驟：
●步驟1：確認專案的最終產品─什麼是達到專案成功所必需交付的成果。徹底檢視高層次專案範圍文件(如工作說明書(SOW)及技術需求)是確保WBS與專案需求一致的方法。
●步驟2：定義專案主要的可交付成果，這些包含專案所必需的期中可交付成果，而這些並不能滿足商業需求(如設計規格)。
●步驟3：分解主要的可交付成果到足以控制與管理的適當層級。這些WBS元素連結可交付產品。各層級的元素總合表示這元素層級以上100%(所有)的工作(這就是之前所說的100%原則)。WBS裡每個工作包應只包含一個可交付成果。
●步驟4：檢視及精煉WBS，直到專案利害關係人同意專案規劃能成功的完成，以及執行、控制都能成功的產出期望的可交付成果與結果。
5.2.1.2由下而上途徑
下文描述使用由下而上途徑發展WBS的步驟：
●步驟1：辨識專案的所有可交付成果或工作包。注意包含的是可交付成果而不是活動。這包含努力的所有產出。每一個工作包應只包含一個可交付成果
●步驟2：將工作包或可交付成果邏輯化的加以歸類。
●步驟3：將歸類的可交付成果聚集至上一層，即所謂的父項。每一層元素的總和必需100%的包含下一層的工作，就是前所述的100%原則。
●步驟4：一旦一群相關的任務聚集到父項，再次分析子項確保所有的工作都已被完成。
●步驟5：重複一直到所有子項都能聚集到單一的父項，並能描繪出專案。確保完成的結構包含所有的專案範圍。
●步驟6：檢視並精化WBS直到專案利害關係人同意，能成功的完成專案規劃。並讓執行與監控流程能成功的產出所欲的可交付成果與結果。
5.2.1.3 WBS標準
●步驟6：檢視並精化WBS直到專案利害關係人同意，能成功的完成專案規劃。並讓執行與監控流程能成功的產出所欲的可交付成果與結果。
5.2.1.3 WBS標準
一個組織化的WBS標準是一組建構WBS的原則，包含編排、編碼、命名規則及所需具備的元素。在許多組織裡WBS標準已具有高度專案管理成熟度。這標準能幫助確認組織使用WBS的一致性與完整性。WBS標準包含下列：
●專案管理至少需到達4.4.2層級2的WBS元素。
●發展及維護圖形或文字化的WBS。
5.2.1.4 WBS模版
WBS模版是一種WBS範本，在某種詳細的層級上具有階層狀元素。組織可能有不同型式及不同生命週期的WBS模版。
WBS標準及WBS模版的使用，可以幫助提升WBS或WBS組成成份重複使用的一致性。當再使用現有的組成成份時，需先確定客製化，以符合專案獨特需要與必要條件。任何非必要的工作或可交付成果應被排除以讓WBS與專案範圍一致。5.2節的幾個問題必需以這量個方法(指WBS標準及WBS模版)反覆的檢視。使用WBS標準及WBS模版製作WBS，經由應用WBS最佳實務可以幫助提升 品質保證。
使用WBS標準及WBS模版再使用現存的WBS材料，這與由上而下或由下而上的方法不同。
5.2.2選擇WBS製作方法的指引
在發展WBS時，專案管理團隊首先需決定所採用的發展方法。採用由上而下或由下而上途徑完全依據專案團隊習慣與思考模式或組織的實際需要。除前述外，採取哪種途徑較適合也可考慮下列
5.2.2.1由上而下：下列情況採用由上而下途徑：
●專案經理及專案團隊發展WBS的經驗不足或沒有發展WBS的經驗。由上而下途徑允許逐步的完善WBS。
●專產品或服務並不未清楚的瞭解。當專案範圍不明確時採用由上而下途徑與利害關係者共同發展WBS，可以讓專案範圍與性質得到清楚的瞭解與共識。
●專案生命週期並不清楚，由上而下的途徑可以較容易的揭露生命週期的問題與其特徵。
●沒有適當的WBS模版適用。當從頭開始發展WBS，採用由上而下途徑會較從所有的專案可交付成果來的容易，例如建造自行車然後反覆的決定次一層的工作。
5.2.2.2由下而上：下列情況採用由下而上途徑：
●專案產品或服務很清楚。例如，組織在早先專案發展過類似的產品或服務，此時專案團隊對新專案所需的所有過渡期間的可交付成果會有很清楚的瞭解。
●專案生命週期是清楚且為人熟悉的。若組織總是使用相同的專案生命週期，專案團隊熟悉過渡期的可交付成果，且可以用來由下而上發展WBS。
●有適當的WBS樣版可使用。若組織曾有產出類似產品或服務的專案，這些WBS經過修改就可以再使用，由下而上途徑能增強團隊的客製化WBS樣版的能力。
5.2.2.3WBS標準與樣版：
一般來說，若WBS標準或樣版適用，必需注意表5-1的警告。在文獻中有許多可用的WBS範例，但要將WBS範例作為樣版則需謹慎。組織在每個類似的專案都能使用WBS樣版，組織也鼓勵使用這些樣版。然而，若專案明顯的與過去不同，又沒有可使用的樣版，則用由上而下途徑發展WBS。
5.2.2.4重複
建構WBS是一個反覆的過程，而且有時必需使用幾種不同的方法以產出高品質的WBS。例如，可以使用WBS樣版及由上而下途徑以決定WBS整體結構，與由下而上途徑相比，它更適合辨識為完成特殊可交付成果所需的所有元素。
不論使用哪種方法，最終的WBS必需具備高品質WBS的所有主要特徵。WBS必需100%包含專案的所有工作；必需是以可交付成果取向而不是活動取向；也必需是階層化的架構。詳細的WBS品質原則請看第四章，特別是4.2節有關WBS主要品質特徵的描述。
5.3必需考慮的一般因素
發展WBS時下列基本宗旨必需考慮：
●每一個WBS元素代表一個可交付成果(一個產品或服務)。
●可交付成果包含最終或期中的可交付成果，而這些可交付成果是為完成最終結果所必需要的。
●可交付成果包含不可見的項目，如資訊/溝通、整合、行政管理、訓練、流程管理及採購等。
●所有的可交付成果需明確的包含在WBS內。
●可交付成果需是唯一且獨特的。
●所有重要的報告機制，如檢討會議、月報、測試報告等都必需包含在WBS裡。
●清楚的界定專案可交付成果，每一個可交付成果是唯一的，並確保專案的成果或產出最終產品的工作，不會重複。
●每個工作包都可被指派給專案團隊成員或外包商負責。如果無法指派必需考慮工作包是否需進一步分解。註：表示原來的工作包仍然太大
●每一個WBS元素若代表外包或來自外部的可交付成果，則必需與外包商的WBS元素吻合。
●可交付成果被邏輯化的分解至它們被製造或管理的層級。(例如：設計、採購、外包、組裝)
●所有WBS元素是與組織或會計結構一致。
當組織WBS元素成為階層化WBS時，下列指導原則應該被考慮：
●每一個WBS元素向上只能屬於一個父項。
●正如100%原則所說，所有的子項元素能組合成父項的元素。
●編碼系統可清楚的代表WBS元素的層級。
●每個WBS不見得都要分解成一樣的深度。某些WBS必需要分解的比其他的WBS詳細。
●不需要每個工作包都在同一層上。
WBS發展過程應：
●反覆進行
●隨著專案規劃的進展不斷的檢討、修正
●需有足夠的彈性，特別是專案範圍改變時經過增減仍可使用
一個好的專案必需有嚴謹的變更控制流程以管理文件及範圍變更。當發生工作範圍變更，WBS必需更新。WBS的任何變更相關的專案管理工具需隨之改變，如WBS詞典、網路圖、時程表等。
5.3.1專案管理知識領域的考量
在WBS反覆的發展過程，下述指引及問題應該在每一個有關的知識領域被考慮：
5.3.1.1專案整合管理
●專案整合管理包含整合WBS內的工作。WBS元素都需被歸納整合在適當地層級。
●為使整合管理發揮效能所有必需的溝通或會議都必需包含在WBS內。
●是否所有WBS所定義的工作都被邏輯化的歸納？所有報告及控制機制都被納入？
5.3.1.2專案範圍管理
●發展WBS對範圍管理非常重要。必需反覆地檢視。
●所有的需求都已界定清楚並且被核准？
●是否已有工作說明(SOW)？一套有關合約的要求及其他文件要求(requirement)？須確認WBS元素都能被追溯到這些要求。專辦範圍管理包含範圍內的這些活動且這些活動都能被追溯到合約或其他文件要求。
●當WBS被界定後，必須有一張活動或努力的清單以便隨時檢視是否超出專案範圍。定期與利害關係人檢視WBS及超出範圍的活動清單。
●可交付成果在WBS明確的被定義出來了嗎？
●水平或滾動式規劃不斷的被使用在發展或進一步分解專案範圍。
●參考歷史資料、風險登記簿、查核表及學到的經驗教訓都會被用來確保所有工作都被辨識出來？
5.3.1.3專案時間管理
●可交付成果應被分解至足夠詳細的程度，以便能估算所有產出或獲得此交付成果所需的工作與努力。
●如何決定進行中的工作狀態？
註：是指在指定的時間某一工作進行到什麼程度。
5.3.1.4專案成本管理
●可交付成果必需限制其大小，以便能有效做成本控制(不可太小，使得成本控制本身變得不符成本效益。不可太大，變得無法管理與出現不可控的風險)。
●如何建立預算？
●能將預算與工作連結嗎？
●WBS詳細的程度適於進行有效的規劃與控制？
5.3.1.5專案品質管理
●工作的品質可經由測試、檢查評估而來？
●專案有品質要求嗎？如果有，品質要求的定期檢視、品質管理活動、品質稽核、品質檢討，確定已將WBS元素納入。
●這些品質標準是否遵守ANSI、IOS或其他標準的要求？如果有，WBS元素也應納入外部稽核的範圍。
●可交付成果的品質要求是否在WBS被敘述？
●是否有可交付成果如何被衡量的規定？
5.3.1.6專案人資管理
●確保每項WBS元素都有負責人。如果發現WBS元素有多個人負責的話，應考慮將該元素再分解。
●是否所有的工作都能規劃到足夠的詳細程度，以便讓指派的人做出負責的承諾？
註：是指工作被清楚的定義，讓被指派負責這項工作的人清楚的知道他必需執行什麼工作、完成什麼成果。
●工作指派能建立在不斷完善的WBS上？
●工作如何被指派與控制？
●是否能將個人工作與正式的工作進度協調一致？
●有一個以上的組織參與，在進行詳細的資源規劃前需要獲得另一方的確認或批准？
5.3.1.7專案溝通管理
●所有溝通需求都被考慮？
●有遠距、地區、國內、跨國溝通的需求嗎？
●有跨國溝通的特別要求嗎？如翻譯及其他國家特別的要求。
●在WBS對溝通需求有任何的敘述嗎？
5.3.1.8 專案風險管理
●WBS考慮了高風險，並考慮將WBS解構到更詳細的層級。這會使專團隊有較佳的假設與期望，且也會有較精確的規劃，因而降低了風險。
●可交付成果被完整而清楚的定義？
●變更的可能性是什麼？
●技術更新的速度比專案完成的速度還快嗎？
●人力、設備產能、內部資源可用性及潛在供應商已經查核過了嗎？
●正式的變更流程已經定義及執行了嗎？
●可交付成果被評估的方式已經定義清楚了嗎？
●其他的風險被辨識了嗎？包含利害關係人的接受、公共關係、管理核決、團隊共識？
●內部、外部溝通計劃都已定義及執行了嗎？
●有獨立的第三者瞭解並監控變更？
●產品、供給及專家有備用的供應商嗎？
●參考歷史資料、風險登記簿、查核表及學到的經驗教訓都會被用來確保所有風險都被辨識出來？
●風險管理及應急工作都已包含？
5.3.1.9專案採購管理
●有大量的下包商可供選擇？
●每一個採購的可交付成果都有對應的WBS元素？
●有管理採購流程的可交付成果？
●採購是被專案小組或組織原有的採購部門所管理？
5.4基本判斷
有效的應用相關的特徵完全依賴經驗與判斷。本節會更詳細的檢視這些概念。專案間的不同完全依賴WBS所欲達成的目的，包含但不限於下列所述之要素：可交付成果所需分解的詳細程度、WBS元素型態的選擇、分解的邏輯架構。
5.4.1決定WBS適當的詳細程度
WBS發展過程被描述成一個逐步完善的過程，一直到專案範圍內所有的元素都被包含在WBS內。這個過程也提供了對專案清楚的溝通並可以有效的進行專案管理。WBS詳細的程度端視專案的大小以及反應複雜性、風險、專案經理監控的需求間的平衡。WBS詳細的程度在專案進行期間也會改變。從下而上途徑或上而下途徑的分析能釐清WBS的完整與適當的詳細程度。
短期間的專案一開始就會解構至較高層級的WBS。較長期間或複雜的專案一直到對專案所有可交付成果有更清楚的瞭解後才會開始進行解構。這表示任何一個專案在WBS的解構層級都會有所不同。尤其是採用滾動式規劃更可證明此言為真，當專案隨著工作的進展日益明朗，越近期的工作會越清楚，越後面的工作會比較不清楚。
當專案持續進行時必需謹記100%原則。這規則闡明了子項的工作總和必需100%等於父項。WBS的每一隻腳不必都要是對稱的。
註：因為WBS的各個元素複雜性不同，較複雜的元素會分解至較多的層級。反之簡單的元素只要幾個層級就能得到必要的工作包了。
WBS是否該進一步的分解？下列這幾個問題提供了一個指導方針。如果答案都是”YES”，那你必需考慮需要進一步的分解。”YES”的答案越多，越應該考慮需要進一步的分解。
5.4.1.1範圍與工作包
●對測量WBS元素進展是否失去清楚、客觀的評估標準？
●WBS元素是否包含了超過一個的可交付成果？
●包含在WBS元素內的內部可交付成果是否不同？
●包含在WBS元素內的工作可否作為時程表上的一個單元？
●在整個WBS元素執行前是否有可接受的評估標準？
●WBS元素完整而清楚的被專案經理等利害關係人(包含顧客)所瞭解？
●在內部WBS元素及外部WBS元素是否有關係？
●利害關係人有興趣的狀態分析與績效報告，只有部分包含在WBS元素內？
●當需要時工作進度能被評估？
5.4.1.2資源與風險
●工作元素能被指派至單一的負責人？
當各種資源被指派給指定的WBS元素，最後只應有一個負責人。
●是否有特別的風險，以致需要特別關注在某個WBS元素？
●在WBS元素中是否辨識出風險？
5.4.1.3成本與時程
●在執行工作時是否有重要的時間差距？
●是否有改善持續時間估算或成本精確度的需要？
●是否有分別定義工作成本或可交付成果成本的需要？
●是否有精確知道及報告可交付成果的時程的需要？
5.4.2選擇WBS元素的型式
WBS組織並定義整個專案的範圍。然而，並非每個WBS都需包含所有的工作型式。甚至，在WBS內工作的類型，在WBS發展時被範圍及專案本質所指定。下列例子就顯示這樣的情況。
●有些專案需要某種型式的WBS元素，但某些就不需要。例如，一個專案是製造幾個不同的零組件，然後組裝成最終成品。那這個專案的WBS就會包含組合及裝配兩種WBS元素，讓組裝工作能被辨識、分配資源、追蹤與報告。
●所有專案的WBS至少需要達到4.4.2的層級2，這是為了確保工作的規劃、追蹤及報告能被適當的被掌握及管理。某些組織可能使用標準的WBS模版，而不包含某些型式的WBS元素(如，行政、文件化、報告等元素)，因為這種需求被組織建立的商業流程所規範。在這些例子，不需要這些元素。
●品質保證可適用於所有專案。有些組織有它所適用的特定品質標準。在這些例子，WBS必須包含這些元素：如，文件與稽核，以對遵守這些特定流程負責。
5.4.3分解的邏輯架構
WBS的基本樣貌經由可交付成果的分解到較細的組成成份，清晰的界定專案範圍。因此提供了一個基本的方法管理複雜的專案。專案經理分解專案的方法(分解專案的邏輯)會隨組織的需要與條件而有所不同。下列例子說明了這個狀況：
●組織可能依嚴格的功能別架構組成，所以幫助次級組織溝通的商業流程很少。在這例子，分解的架構依據工作或次可交付成果，每一個功能屬性都是獨立的。相反的，在沒有功能部門的專案型組織，同樣的可交付成果能更有效的分解成較細的成份。
●依序列週期進行的新產品發展流程，後工作完全依賴前工作的完成才能進行。因此，依據產品生命週期來組織WBS是有意義的，比依據產品的物理性組成來的妥當。
●一個為發展新連鎖餐廳的地區性餐飲業，會發現依地理性來建構WBS，特別有價值。當總部建物發包、食材來源、市場行銷等會發現依地理子系統來分解新連鎖餐廳專案會很有用。
在所有的例子裡，WBS必需保持可交付成果取向，更甚於流程取向，並明確的包含期中可交付成果。
5.5WBS品質評估
在製作WBS時有幾個重點需考慮。如第四章詳述的，WBS都必需具備能滿足專案需求的一組核心特徵。沒有經過這些考慮，將導致專案的失敗。因為事先沒有辨識所有應做工作，會產生高風險。
5.5.1核心特徵
●WBS結構不是基於組成成份的時間或邏輯順序。時間、邏輯順序及依賴關係是專案時間管理最關心的因素。
●WBS不是僅依據流程或組織來建構。
●WBS界定所有專案成份間的邏輯關係。
●WBS所有元素都是可交付成果導向。
●專案活動未列清單。專案活動是專案時程的組成成份而不是WBS的。
●所有元素都是名詞。動詞不被用來辨識WBS元素。
●WBS僅包含必需的可交付成果。所有可交付成果是在專案範圍內定義的專案產品、服務或最終結果。
●所有專案可交付成果必需被辨識及詳細的描述，包含管理許可、工作包、分類或行銷，也包含初步的、期中的、內部、外部或最終的可交付成果。
●沒有WBS元素產生職責重疊。每一WBS元素必需由一個人負起完成的責任。
註：WBS的元素可能有一組團隊執行，但仍需有一個leader負管理與成敗之責。
第四章曾討論使用導向的特徵使每一個WBS與其他的WBS不同。這些特徵使WBS的使用無論是在特殊專案、產業或環境、或在應用特別方式的個別專案，都是獨特的。關於使用導向的特徵，WBS的品質依賴WBS元素的獨特內容及型式發展的是否完整，以滿足使用WBS的目的。
5.5.2使用導向特徵
●辨識關鍵的專案管理工作，如
。。啟動、規劃、執行、監控、結案
。。流程管理
。。服務與供應
。。資訊/溝通
。。行政文件、訓練、軟體
這些可被界定為WBS元素的努力程度。在某些案例，它們會是期中可交付成果，它們自己不會產出分離的可交付成果*也可能不會包含在最終產品的交付上。
*說明：係指所有的可交付成果都在專案範圍內，在WBS內不會出現專案範圍外的可交付成果。
●包含跨專案的WBS元素，如開始及結案階段(例規劃、組裝、整合及測試)
●平衡WBS資料收集報告的需求。WBS基本的目的在經由可交付成果的分解來界定專案的範圍。
●經由達成平衡專案複雜度、風險、PM的監控需求，將WBS分解至適當的層級。
●不要把WBS分解的太細。WBS是一個設計來幫助PM分解專案到適當而必要的層級，以滿足專案需要、工作的本質、團隊的信心*工具。過度的WBS層級會需要不切實施的維護與報告成本。
*說明：工作內容越清楚，專案團隊完成的信心就會越高。
●不要忘記WBS發展，如甘特圖、網路圖制定前的CPM或緊前關係圖(PDM又譯前置關係圖)等。忽略WBS的發展或改進會導致不可測的困難，包含專案延誤、成本超支、專案徹底的失敗等。
5.6WBS全面(CONTINUUM)用法
WBS滿足專需求的能力與專案管理團隊管理職能的層級有直接關係。
有經驗的專案管理團隊能夠辨識明顯或隱含的專案需求，並在WBS界定出來。更有經驗的專案管理團隊能夠確認WBS能被各種不同的專案角色使用，而且以更有效及精確的方法使用WBS。WBS可以是高品質的，即使專案管理團隊不具備完全使用WBS的能力。
專案管理團隊發展與使用WBS做為一種有效規劃及控制的工具，代表團隊位於WBS全面的使用。換句話說，一旦專案管理團隊在專案裡開始使用WBS，他們讓WBS扮演定義與控制範圍、預算、風險的角色的能力，類同於專案管理方法論或工具逐漸全面使用。下列是WBS發展與全面使用：
有限的 | 中等的 | 廣泛的 |
●發展WBS包含所有核心特徵 ●至少應用極少的專案估算經驗 ●應用專家判斷 | ●發展WBS包含所有核心特徵 ●辨識及包括部份的使用導向特徵 ●有效的應用WBS在專案時程發展及資源指派 ●在WBS中應用專案估算技術 | ●發展WBS包含所有核心特徵 ●辨識及包括所有必需的使用導向特徵 ●有效的應用WBS在專案時程發展及資源指派 ●在WBS中應用專案估算技術於發展及管理專案 ●有效的應用WBS於變更控制、規劃與執行、品質規劃與控制、風險規劃與管理、成本及預算規劃與控制等 |
5.7計劃及組合管理的WBS
依據PMBOK第三版Project、Program、Portfolio的定義如下：
專案(Project)：一個暫時性的努力以產出一個獨特的產品、服務或結果。
計劃(Program)：一組相關的專案，協調管理以獲得較大的利益與控制。計劃包含計劃內不同專案範圍外的相關工作元素*。
*說明：因為要作計劃協調管理，勢必增加一些協調管理的工作，這些額外的協調管理工作並不在任一個別專案內。
組合管理(Portfolio)：一群專案或計劃及其他工作的集合，有效的管理這些專案或計劃及其他工作能符合組織的策略目標。組合管理的專案或計劃可能互相獨立，也可能互相有關聯。
WBS不只對專案很有用，同樣的對計劃或組合管理也非常有用。WBS在這個層級的實務仍然在增加中。專案WBS、計劃WBS、組合管理WBS沒有概念上的差異。無論在計劃、組合管理，高品質的WBS與個別專案的高品質WBS擁有相同精確的特徵與屬性。它們的差別只在範圍的大小而已。
所有本章第四節所定義使用在WBS上的原則同樣都適用在計劃WBS、組合管理WBS。然而，在組合管理時必需要賦予更大的關注*。範圍明顯的擴大，所有工作與可交付成果的核實驗收也越困難。
*說明：因為組合管理更大更複雜了。
5.8總結
本章顯示製作WBS有許多不同的方法。它能以全新的文件發展，能以現存WBS加以再使用的方式發展、能使用WBS樣版來發展，能以先前所界定的WBS標準來發展。無論採取哪種方式，經由反覆的考慮專案範圍逐步展開WBS，包含專案目標與目的(商業的或技術的)、功能及績效標準、技術績效要求及其他技術屬性。
本章也提供幾個指引及查核表，幫助準備WBS。其他專案管理知識領域(如時間管理、成本管理、品質管理)均高度依賴WBS。最後，高品質WBS提供了一個建構成功專案的強大基礎。
全站熱搜
留言列表
