建立工做分解結構

(本文是學習筆記，與你們共享)

本文按照以下的順序進行：

l         定義工做分解結構

l         使用工做分解結構

l         協調工做分解結構組建

l         建立工做分解結構

l         得到審批

做爲項目經理，須要有一個詳盡的工做計劃，明白工做應該分幾個階段，每一個階段有幾個任務，它不是一個簡單的工做，若是你決心把它作好，最終必定能達到目標。

1.       定義工做分解結構

一個IT項目經理不可能也不該該對項目中每一件事都事必躬親，某些項目根本就不可能靠我的獨立完成。固然，項目經理能夠將任務委派給某個項目團隊成員去作。可是項目團隊成員怎麼可以知道委派給他的任務是否應該在其餘成員任務結束前開始，以及是否提早結束，工做分解結構使你可以回答這些問題，它提供瞭解決項目問題的武器以及爲團隊成員分派任務的手段，每一個高層的提交產品還能夠再分爲更細的提交產品，在最底層的是工做包，他們是wbs的最小提交結果，未來編排進度時，對他們再分解爲必要的活動。WBS對全部的項目都很重要，由於他是5個關鍵項目活動的輸入，

2.       使用WBS 建立WBS的方法沒有對錯之分，能夠再白板上精心畫出項目計劃，也能夠在餐巾紙上隨手亂畫，固然最好的方法是採用一些普通的方法進行WBS的工做。項目是一個有肯定結束日期的完整工做，他能完成某種預約的目標，是企業賴以獲利的投資手段，使得項目有明確的工做範圍，清晰的目標，可以使用的你數目和最終完成日期。一個項目裏面又能夠分爲幾個階段，其實從技術角度講，不必定要分階段，可是大多數的項目都有清晰的階段定義，這些階段能夠將工做分爲多個部分，階段是項目的一部分，只有前一部分完成，其餘相關部分的工做才能開始，每一階段都有一個截止日期。通常的，生產的每個階段不會和其餘階段發生重疊，無論是否依賴其餘階段，都有可能並行完成而不是必定要順序完成。每一個階段又能夠分爲幾個工做包，工做包是WBS的最小交付成果，從工做包能夠分解出項目的活動列表，當你對交付成果進行分解的時候，分解的最底層組成了工做包。

3.       協調WBS組件，有些項目經理建議一應該不停的將每一個任務細分下去，直到不能更進一步地細分爲止，可是，這種持續的細分行爲和咱們的傳統思想是相矛盾的，由於他最終會致使工做單元過於瑣碎，雖然爲要完成工做所須要的措施是必要的，但項目經理應該信任他本身的團隊有足夠能力來完成工做要求的那些任務。習慣上，咱們都會找一個能夠接受的時間單元用做最小的工做增量，例如小項目能夠將工做一天爲單位來劃分，而對大一些的項目可能選擇以周爲單位，項目分解的 就是儘可能不要劃分得太細，以避免最終由於每一個活動過於瑣碎而沒法進行有效管理，8/80規則能夠做爲一個分解的建議性依據，這個規則建議最小的工做包完成時間不該該超過80個小時，或者不要小於8小時，儘管這個規則能夠應用到大多數的項目中，但不是老是這樣，例如外包給一個供應商的一個工做包，他多是一個子項目或者項目的一部分，這些承包人能夠再分解他們本身的WBS。

a)         爲何須要WBS 在一些小型的項目上，你可能試圖省掉建立WBS的過程，特別是在一些小型項目上，但不要屈從於這種誘惑，即便是小型項目，經過建立WBS，項目經理能準確地預測下面幾個方面的內容，

l         WBS明確了完成項目所須要進行的工做 在已經開始的項目中，你可能屢次發現徹底忘掉了一個決定性的階段，或者發現一個在整個項目開始以前必須具有的組件根本就不存在，WBS能保證項目經理對項目完成所必備的工做條件瞭如指掌。

l         WBS產生緊迫感，經過生成WBS，項目經理及其團隊會一塊兒爲項目的如期交付而努力，由於WBS的最底層是工做包，從工做包又能夠劃分爲多個任務，而每一個任務又有起始日期和結束日期，WBS能夠保證任務按照合理的進度和順序進行，最後完成交付結果，若是全部的成員都能按時完成他們的任務的話，項目就能夠保持其勢頭，並按計劃進行，WBS能夠幫助項目經理跟蹤其團隊成員的各項任務的完成狀況，這些任務最後建立WBS定義的交付結果，從而斷定成功和失敗的狀況。

l         WBS能防止項目範圍盲目擴大，當管理部門打算向已存在的項目增長新的內容時，WBS能避免這種事情發生，由於WBS是一個將通往項目成功之路的每一個活動的日程表，他能夠很容易地讓項目經理取消那些向已經開始的項目中所添加的內容，固然，他也容許爲WBS添加新的內容，但必定要從新安排日程表和從新編制預算來反映這種調整。

l         WBS提供了一種控制手段，做爲項目經理，手頭可能同時負責了多個不一樣的IT項目，WBS可以讓你經過可視化的方式清楚地看到每個項目的狀態以及是怎樣達到這個狀態的。你能夠很容易地對某個特別的過程，工做單元或任務加以留意，也能夠適當調整，對團隊成員給與某些建議，或者根據須要調整日程，有所控制終歸是好的。

l         WBS是範圍基線，不在WBS中的任務就不是項目的工做，它做爲項目經理、客戶、項目發起人、團隊成員、供應商和其餘項目相關人就那些是項目任務，那些不是項目任務的討論達成一致提供了依據。

4.       建立WBS 定義了項目範圍，該範圍明確了項目最終應該交付的成果，這個可交付成果就是你努力不停工做所尋求的目標，而WBS就能夠當作你爲達到項目最終目標的步驟的組合，建立了WBS以後，就能夠列出活動列表，他們是完成可交付成果的實際任務。

WBS也提供了一種給團隊成員分派任務和肯定每一個任務相應時間的方法，一旦建立了WBS，就能夠進行項目進度的安排和資源分配，WBS是一種過程和對工做的可視化描述，可以幫助你組織和規劃那些使項目成功完成的活動。有兩種建立WBS的方法，自頂向下和自底向上。自頂向下方法採用的是演繹推理的方法，自底向上是一種從特殊向通常方向進行，兩種方法都有其優勢，自底向上方法是一種理想的發揮創造力的解決問題方法。自頂向下方法須要有更多的邏輯和結構，他也是建立WBS的最好方法，使用自頂向下方法來生成WBS要先肯定每個解決方案，然後將該方案劃分紅爲可以實際執行的若干步驟，在平常生活中，你可能已經不自覺的使用過自頂向下的工做方法，。

1.         建立WBS的過程 建立WBS的過程一般不是一個我的行爲，通常狀況下，他須要項目經理和項目團隊一塊兒參與，在某些狀況下，他也許須要項目發起人或其餘監督管理人員在場，雖然在通常狀況下這個時候團隊已經早就開始行動了，並且此時的監督管理也不是頗有必要，因爲項目團隊人員數目的限制，將全部成員都召集到某一個計算機屏幕前來討論建立WBS的方法並非一中理想的方法，下面列出若干種組織引導團隊成員建立wbs的方法：做爲初學者，首先要肯定你有一個白板，足夠的記號筆，即時貼以及會議的控制，要使你的職員明白，這個過程有助於大家明確什麼是達到項目目標所必須完成的活動，能夠先從最頂層開始，這個最頂層目標一般是項目的各個階段，這多是項目主要交付成果，或者是項目各階段的項目目錄等，若是沒有作預算或者預算裏沒有包含項目階段部分，能夠經過回答一下問題來肯定項目階段。

l         項目內部存在邏輯上的劃分嗎，

l         存在表明各個階段的可識別的里程碑嗎？

l         在項目中是否考慮了大家企業的商業週期？

l         在項目中是否有財務責任或限制來標示各個階段？

l         在公司項目生命週期中有什麼因素能影響項目？

l         你的公司如今正採用的系統開發過程是什麼？

一旦你肯定下來各個階段，將他們分別寫在即時貼上，而後按照階段執行順序將他們貼在白板上，如今開始考察階段，將這些結果部分分解爲更小的交付成果，而後繼續分解這些交付成果直到分解爲比較容易管理的工做包，WBS的最小的單元。

分解項目交付成果須要必定的技巧，你可能不想將任務劃分得更細，但你必定想將什麼時候的時間和資源分配各每一個階段中必須完成的活動，能夠參照8、80規則，每一個人物的時間不該該超過80個小時，也不該該小於8個小時。你只要可以把握住大的方向，而沒必要詳細描述具體的工做機制，這樣就能夠了，完成了以上分析或者第一個主要交付成果之後，你就能夠進行下一階段的工做並重覆上述過程，以此類推，直到全部的交付成果都被分解爲工做包，而且每一個工做包都被劃分紅所須要的任務，如今呈如今你面前的白板上必定已經粘滿了即時貼，實際上已經清楚的表達了項目執行過程。

2.         檢查科交付成果 當項目開始建立時，咱們就已經有一個項目完成後應該是什麼樣的認識，當制定WBS時，項目經理會將項目費分割爲各個階段，在每個階段都應該有可交付成果來標示一個階段的結束和另外一個階段的開始。當生成WBS時，須要檢查一下每一個階段的主要交付成果，這些里程碑可以保證團隊和他的領導朝正確的方向進發，應該指定這些里程碑的截止日期或者結束日期，結束日期標識着把每個我的完成的任務彙總起來達到項目的最終完成。

5.       得到管理層批准 WBS一旦建立，他必須經過管理層最終批准，在某些狀況下，好比當項目經理和項目團隊是諮詢人員或技術集成供應商，項目經理沒必要再進入WBS中的每個項目單元時都要通過管理層批准。

a)         提交給項目發起人 做爲項目的倡議者的項目發起人多是批准WBS的第一個障礙，項目經理必定要作好向項目發起人解釋WBS中每一步的過程的準備，若是項目經理已經根據企業週期和團隊成員日程表對WBS進行了充分的研究和巧妙的計劃，那麼日程安排就不須要進行大的改動。可是若是項目經理沒有很好的和團隊合做，沒有考慮商業週期或者沒有考慮公司內部執行的其餘項目，那麼項目發起人就得和項目經理一塊兒改正時間表，若是由於出現計劃失誤或沒有充分地理解一個組織內部IT領域的其餘活動而致使不得不從新建立WBS的狀況發生，你能夠想象可能帶來的挫折，更不用說建立WBS失敗對項目發起人和項目團隊信心的打擊。

b)        提交給項目相關管理人員 一旦項目發起人批准了WBS，項目經理就要將WBS提交給項目關鍵相關人員，他們多是項目的客戶或者是企業內部的一個部門或者是管理層，說通常地，要根據聽衆喜愛準備好講稿，在講述WBS時不須要對每個階段的每個任務都作很詳細的描述，在開始介紹WBS時，從項目提交結果的地方開始，經過再一次提醒領導們所要作的項目將要產生什麼結果，就可以得到他們對項目進行進一步的支持，向管理層講述WBS的中心思想是向他們確保項目包括了他們要求的可交付成果，另外這個能夠做爲項目範圍的基線，因此要求你們意見一致。

在可交付成果肯定之後，再來展示一下爲達到這一可交付成果須要哪些階段，經過時間基線來演示是最有效果的，這個時間基線可使用Pownpoint之類的軟件來建立，很能清楚的反映項目開始和項目結束日期，演示完每個階段後，在時間基線圖上添加一個箭頭，來清楚的現實相對項目完成日期而言，每個階段應該放在那裏，這可以給你的觀衆一個可視化的感受，讓他們瞭解你的計劃時如何構思的以及每個階段都會產生怎樣的結果，從而是你的整個團隊，公司都能向着項目最終結果進發。

       在每個階段內，沒有必要列舉每個階段所需完成的任務狀況，同時應該準備好對每個階段的詳細討論，這樣有時會改變報告方式，把項目每一個階段的每個任務包括進來。若是管理層沒有批准日程，項目經理應該立刻記下相關的問題，有些狀況是隻要進行一些修正管理層就會批准，而另外的一些狀況，管理層多是由於想仔細研究WBS而推遲對你的批准，若是管理層老是在開始項目的問題上延遲作決定，就不要讓他們的延遲對項目執行形成破壞，在計劃召開WBS評審會時要給管理層留出足夠的時間來評論和修改計劃。若是WBS須要當即審批，要對管理層特別強調該日程必須在某些天數以內執行，若是問題不是出如今日程的開始階段的話，那麼在管理層仔細評審後面的具體內容時，也許這部分計劃至少能夠開始執行了。