工作分解結構(轉載)
什麼是工作分解結構(WBS)?
工作分解結構(Work Breakdown Structure,簡稱WBS)跟因數分解是一個原理,就是把一個專案,按一定的原則分解,專案分解成任務,任務再分解成一項項工作,再把一項項工作分配到每個人的日常活動中,直到分解不下去為止。
即:專案→任務→工作→日常活動
工作分解結構(WBS,Work Breakdown Structure),以可交付成果為導向對專案要素進行的分組,它歸納和定義了專案的整個工作範圍,每下降一層代表對專案工作的更詳細定義。
WBS總是處於計劃過程的中心,也是制定進度計劃、資源需求、成本預算、風險管理計劃和採購計劃等的重要基礎。WBS同時也是控制專案變更的重要基礎。專案範圍是由WBS定義的,所以WBS也是一個專案的綜合工具。
WBS的主要用途
WBS具有4個主要用途:
- WBS是一個描述思路的規劃和設計工具。它幫助專案經理和專案團隊確定和有效地管理專案的工作。
- WBS是一個清晰地表示各專案工作之間的相互聯絡的結構設計工具。
- WBS是一個展現專案全貌,詳細說明為完成專案所必須完成的各項工作的計劃工具。
- WBS定義了里程碑事件,可以向高階管理層和客戶報告專案完成情況,作為專案狀況的報告工具。
WBS是面向專案可交付成果的成組的專案元素,這些元素定義和組織該專案的總的工作範圍,未在WBS中包括的工作就不屬於該專案的範圍。WBS每下降一層就代表對專案工作更加詳細的定義和描述。專案可交付成果之所以應在專案範圍定義過程中進一步被分解為WBS,是因為較好的工作分解可以:
- 防止遺漏專案的可交付成果。
- 幫助專案經理關注專案目標和澄清職責。
- 建立視覺化的專案可交付成果,以便估算工作量和分配工作。
- 幫助改進時間、成本和資源估計的準確度。
- 幫助專案團隊的建立和獲得專案人員的承諾。
- 為績效測量和專案控制定義一個基準。
- 輔助溝通清晰的工作責任。
- 為其他專案計劃的制定建立框架。
- 幫助分析專案的最初風險。
工作包的特點
WBS的最低層次的專案可交付成果稱為工作包(WorkPackage),具有以下特點:
- 工作包可以分配給另一位專案經理進行計劃和執行。
- 工作包可以通過子專案的方式進一步分解為子專案的WBS。
- 工作包可以在制定專案進度計劃時,進一步分解為活動。
- 工作包可以由惟一的一個部門或承包商負責。用於在組織之外分包時,稱為委託包(CommitmentPackage)。
工作包的定義應考慮80小時法則(80-HourRule)或兩週法則(Two Week Rule),即任何工作包的完成時間應當不超過80小時。在每個80小時或少於80小時結束時,只報告該工作包是否完成。通過這種定期檢查的方法,可以控制專案的變化。
任務分解的原則
1、將主體目標逐步細化分解,最底層的日常活動可直接分派到個人去完成;
2、每個任務原則上要求分解到不能再細分為止;
3、日常活動要對應到人、時間和資金投入。
任務分解的方法
1、採用樹狀結構進行分解;
2、以團隊為中心,自上而下與自下而上的充分溝通,一對一個別交流與討論,分解單項工作。
任務分解的標準
1、分解後的活動結構清晰,從樹根到樹葉,一目瞭然,儘量避免盤根錯節;
2、邏輯上形成一個大的活動,整合了所有的關鍵因素包含臨時的里程碑和監控點,所有活動全部定義清楚,要細化到人、時間和資金投入。
在我們日常管理專案時,要學會分解任務,只有將任務分解得足夠細,足夠明瞭,才能統籌全域性,安排人力和財力資源,把握專案的進度。
建立WBS的基本要求
建立WBS時需要滿足以下幾點基本要求:
- 某項任務應該在WBS中的一個地方且只應該在WBS中的一個地方出現。
- WBS中某項任務的內容是其下所有WBS項的總和。
- 一個WBS項只能由一個人責任,即使許多人都可能在其上工作,也只能由一個人負責,其他人只能是參與者。
- WBS必須與實際工作中的執行方式一致。
- 應讓專案團隊成員積極參與建立WBS,以確保WBS的一致性。
- 每個WBS項都必須文件化,以確保準確理解已包括和未包括的工作範圍。
- WBS必須在根據範圍說明書正常地維護專案工作內容的同時,也能適應無法避免的變更。
WBS的表示方式
WBS可以由樹形的層次結構圖或者行首縮排的表格表示。
在實際應用中,表格形式的WBS應用比較普遍,特別是在專案管理軟體中。
WBS的分解方式
WBS的分解可以採用多種方式進行,包括:
- 按產品的物理結構分解。
- 按產品或專案的功能分解。
- 按照實施過程分解。
- 按照專案的地域分佈分解。
- 按照專案的各個目標分解。
- 按部門分解。
- 按職能分解。
建立WBS的過程
建立WBS的過程非常重要,因為在專案分解過程中,專案經理、專案成員和所有參與專案的職能經理都必須考慮該專案的所有方面。制定WBS的過程是:
- 得到範圍說明書(ScopeStatement)或工作說明書(StatementofWok,承包子專案時)。
- 召集有關人員,集體討論所有主要專案工作,確定專案工作分解的方式。
- 分解專案工作。如果有現成的模板,應該儘量利用。
- 畫出WBS的層次結構圖。WBS較高層次上的一些工作可以定義為子專案或子生命週期階段。
- 將主要專案可交付成果細分為更小的、易於管理的組分或工作包。工作包必須詳細到可以對該工作包進行估算(成本和歷時)、安排進度、做出預 算、分配負責人員或組織單位。
- 驗證上述分解的正確性。如果發現較低層次的項沒有必要,則修改組成成分。
- 如果有必要,建立一個編號系統。
- 隨著其他計劃活動的進行,不斷地對WBS更新或修正,直到覆蓋所有工作。
檢驗WBS的標準
檢驗WBS是否定義完全、專案的所有任務是否都被完全分解可以參考以下標準:
- 每個任務的狀態和完成情況是可以量化的。
- 明確定義了每個任務的開始和結束。
- 每個任務都有一個可交付成果。
- 工期易於估算且在可接受期限內。
- 容易估算成本。
- 各項任務是獨立的。
建立WBS需要考慮的因素
(1)確定適當的WBS層次,最低層WBS的元素需對應有形的交付物。
(2) 對WBS生命週期的考慮,需要考慮在專案不同階段的活動發展,包括專案管理。
(3)專案計劃、績效報告、整體變更控制、範圍管理的需要。
(4)資源計劃和風險管理的需要。
WBS的使用
對WBS需要建立WBS詞典(WBSDictionary)來描述各個工作部分。WBS詞典通常包括工作包描述、進度日期、成本預算和人員分配等資訊。對於每個工作包,應儘可能地包括有關工作包的必要的、儘量多的資訊。
當WBS與OBS綜合使用時,要建立賬目編碼(Code ofAccount)。賬目編碼是用於惟一確定專案工作分解結構每一個單元的編碼系統。成本和資源被分配到這一編碼結構中。
WBS的實踐經驗
最多使用20個層次,多於20層是過度的。對於一些較小的專案4-6層一般就足夠了。
WBS中的支路沒有必要全都分解到同一層次,即不必把結構強制做成對稱的。在任意支路,當達到一個層次時,可以作出所要求準確性的估算,就可以停止了。
工作分解結構的作用
1.明確和準確說明專案的範圍;
2.為各獨立單元分派人員,規定這些人員的相應職責;
3.針對各獨立單元,進行時間、費用和資源需要量的估算,提高時間、費用和資源估算的準確度;
4.為計劃、預算、進度計劃和費用控制奠定共同基礎,確定專案進度測量和控制的基準;
5.將專案工作與專案的財務帳目聯絡起來;
6.便於劃分和分派責任;
7.確定工作內容和工作順序;
8.估算專案整體和全過程的費用。
工作分解結構的優點
(一)、能夠為工作定義提供更有效的控制。
一般來說,良好的專案管理具有下列幾個原則:
1.通過設施的結構化分解來進行管理;
2.關注結果:實現什麼,而不是怎樣實現;
3.通過工作分解結構,技術和人員、系統和組織之間可以平衡結果;
4.在專案涉及的所有部門之間,通過定義角色、責任和工作關係來建立一個契約;
5.採用一個簡明的報告結構。
使用工作分解結構可以滿足有效專案管理的五個原則中的前三個,而避免了計劃的誤區——即只在一個詳細的層次上定義工作。以一個結構化的方式來定義工作可以保證得到更好的結果。通過可交付成果來進行工作定義,在專案向前進行時,只有那些對生產設施有必要的工作才做,因此計劃也變得更加固定。在環境不斷變化的情況下,專案所需的工作可能發生變化,但不管怎麼變化,一定要對最終結果的產生有益。
(二)、把工作分配到相應的工作包中(相應的授權)。
WBS中的工作包是自然的,因為WBS的目的是生產產品,在分配責任的同時也賦予每個產品或服務的單獨的部門。如果工作只是在一個詳細的層次上定義,並彙整合工作包,那麼這個工作包就不是自然的了,專案經理只能每天忙於告訴人們一些技術和方法,而不是讓他們自己獨立去完成工作。
(三)、便於找到控制的最佳層次。
我們在較低層次上進行控制可能意味著在控制上所花的時間要比完成工作所需的時間更多,而在較高層次上進行控制則意味著有些重要情況在我們不經意時會溜走。通過WBS,我們可以找到控制的最佳層次。一般情況下,控制活動的長短應該與控制會議召開的頻度相一致。
(四)、有助於限定風險。
在以上討論時我們都限定計劃和控制的範圍都不包含較高的風險。實際上WBS的分解層次不一定是固定不變的,WBS的最低層次可根據風險的水平來確定。在風險較低的專案中,工作分解的最低層次可以是工作包,而在一個風險較高的專案中,我們可以繼續到專案的一個最低層次上。
專案經理在規劃和控制其工程專案的過程中,工作分解結構是非常有用的工具。編制完整的WBS確定了工程專案的總目標,並確定了各項單獨的工作(部分)與整個專案(整體)的關係。
(五)、是資訊溝通的基礎。
在現代大型複雜專案中,一般要涉及大量的資源,涉及許多公司、供應商、承包人等等,有時還會有政府部門的高技術設施或資金投入,因而要求的綜合資訊和資訊溝通的數量往往相當大。這些大專案涉及巨資並歷時若干年,因此專案開始進行時設想的專案環境會隨著專案的進展而發生很大的變化,即我們已經多次提到的專案早期階段的不確定性[pp1] 。這就要求所有的有關集團要有一個共同的資訊基礎,一種各有關集團或使用者從專案一開始到最後完成都能用來溝通訊息的工具。這些集團包括:業主、供應商、承包人、專案管理人員、設計人員以及政府有關部門等等。而一個設計恰當的工作分解結構將能夠使得這些集團或使用者有一個較精確的資訊溝通聯結器,成為一種相互交流的共同基礎。利用工作分解結構作為基礎來編制預算、進度和描述專案的其它方面,能夠使所有的與專案有關的人員或集團都明瞭為完成專案所需要做的各項工作以及專案的進展情況等。
(六)、為系統綜合與控制提供了有效手段。
典型的專案控制系統包括進度、費用、會計等不同的子系統。這些子系統在某種程度上是相互獨立的,但是各個子系統之間的系統資訊轉移是不可缺少的,必須將這些子系統很好地綜合起來,才能夠真正達到專案管理的目的。而工作分解結構的應用可以提供一個這樣的手段。
在WBS的應用中,各個子系統都利用它收集資料,這些系統都是在與WBS有直接聯絡的程式碼詞典和編碼結構的共同基礎上來接受資訊的。由於WBS程式碼的應用使所有進入到系統的資訊都是通過一個統一的定義方法作出來的,這樣就能確保所有收集到的資料能夠與同一基準相比較,並使專案工程師、會計師以及其他專案管理人員都參照有同樣意義的同種資訊,這對於專案控制的意義是顯而易見的。
例如:許多專案中的典型問題之一是會計系統和進度控制系統不是採用完全相同的分類或編碼,但是在一個有組織的共同基礎之上對成本和進度作出統一、恰當的解釋、分析和預測對於專案的有效管理是非常重要的。此外,各個子系統之間在WBS基礎上的共同聯絡越多,對專案控制就越有益,因為這樣可以減少或消除分析中的系統差異。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7942439/viewspace-18493/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 婚禮籌備之WBS工作分解結構(轉)
- 結構化面試法(轉載)面試
- 專案工作分解的步驟和注意問題(轉)
- data guard的結構常識(轉載)
- 伯恩PAC人格結構理論(轉載)
- Java中的資料結構(轉載)Java資料結構
- HashMap工作原理(轉載)HashMap
- 工作教練法(轉載)
- 工作要素法(轉載)
- 轉載] magento 產品資料表結構
- 薪酬水平與結構設計方法(轉載)
- 轉載:ResNet50網路結構圖及結構詳解
- 工作列視窗以及其子視窗結構 (轉)
- 工作分解和計劃能力是專案經理的核心能力(轉)
- 工作測量法(轉載)
- SSD結構與工作原理
- RMAN備份效率之-oracle block internal(block 內部結構分解)OracleBloC
- 深度探索通過資料共享(data sharing)優化 Amazon Redshift 工作負載分解優化負載
- 個人工作總結(轉)
- 工作分析的步驟 (轉載)
- 工作日誌法(轉載)
- 工作總結--系統架構架構
- PHP 陣列轉樹結構/樹結構轉陣列PHP陣列
- 轉載-知乎工作後的經驗
- 8D工作方法(轉載)
- 質量管理的核心工作(轉載)
- 質量管理基礎工作(轉載)
- Oracle體系結構:記憶體結構和程式結構(轉)Oracle記憶體
- XForms文件結構 (轉)ORM
- 多維度的軟體架構分解架構
- 一年工作的總結 (轉)
- 【轉載】什麼工作能成為事業
- 海氏工作評價系統(轉載)
- 旅行保險公司工作豐富模型(轉載)模型
- 工作豐富化的步驟(轉載)
- ANT命令總結(轉載)
- 【轉載】如何在Oracle中複製表結構和表資料Oracle
- Data block 內部結構的解析(轉載gyj_hobby的文章)BloC