分解的原則:

①在創(chuàng)建WBS時,需要考慮將不同人員的工作分開。

②在創(chuàng)建WBS時,需要適應組織結(jié)構(gòu)形式。

③項目生命周期的各階段作為分解的第二層,產(chǎn)品和項目可交付成果放在第三層。

④主要可交付成果作為分解的第二層

⑤總的系統(tǒng)劃分為幾個主要的子系統(tǒng)

注意事項:

①WBS必須是面向可交付成果的

②WBS必須符合項目的范圍,必須并且只能包括100%的工作

③WBS的底層應該支持計劃和控制

④WBS中的元素必須有人負責,而且只由一個人負責

⑤WBS的指導，WBS應控制在4~6層,一個工作單元只能從屬于某個上層單元

⑥WBS應包括項目管理工作,也要包括分包出去的工作

⑦WBS的編制需要所有(主要)項目干系人的參與,不是某個項目團隊成員的責任，應該由所有干系人共同完成和一致確認

⑧WBS并非是一成不變的,在完成了WBS之后的工作中,仍然有可能需要對WBS進行修改

WBS不是某個項目團隊成員的責任，應該由全體項目團隊成員，用戶和項目干系人共同完成和一致確認。

WBS是面向可交付的項目元素的層次分解，它組織并定義了整個項目范圍，當一個項目的WBS分解完成后，項目相關(guān)人員對完成的WBS應該給予確認，并對此表達共識。

范圍確認完成時，同時應當對確認中調(diào)整的WBS和WBS詞典進行更新。

編制方法：類比方法，自上而下與自下而上的方法，使用指導方針，滾動式規(guī)劃。WBS是一個大事化小的過程。分解取決于所需的控制程度。如果WBS過細，將導致管理時間耗費，資源使用效率地低下。一份好的WBS必須明確設定項目的范圍邊界，防止高估或低估項目的復雜性。

WBS分為兩種形式：樹型和列表型。

列表形式能夠反映出項目所有的工作要素，但直觀性較差，常用在一些大型復雜的項目中。樹型直觀結(jié)構(gòu)性強，但不容易修改，一般在一些中小型的應用項目中用得最多。

注意點：

①WBS中各項工作是為提供可交付成果服務的

②WBS經(jīng)常按照系統(tǒng)或子系統(tǒng)進行逐層分解

③WBS需要考慮將不同的人員分開

④一個工作單元只能從屬于某個上層單元

做成WBS的步驟：

1。識別和確認項目的階段和主要可交付物

2。分解并確認每一組成部分是否分解的足夠詳細

3。確認項目主要交付成果的組成要素

4。核實分解的正確性

相關(guān)真題試題：

閱讀下列說明，回答問題1至問題4，將解答填入答題紙的對應欄內(nèi).

【說明】

某集團公司希望對總部現(xiàn)有信息系統(tǒng)進行升級改造，升級后的系統(tǒng)能收集整合子公司各類數(shù)據(jù)，實現(xiàn)總部對全集團人力資源、采購、銷售信息的掌握、分析及預測。

小王擔任項目經(jīng)理，項目交付期為60天。小王研究了總部提出的需求后，認為項目核心在于各子公司數(shù)據(jù)收集以及數(shù)據(jù)可視化及分析預測功能。各子公司數(shù)據(jù)收集可以以總部現(xiàn)有系統(tǒng)中的數(shù)據(jù)格式模板為基礎(chǔ)，為各子公司建立數(shù)據(jù)上傳接口。針對數(shù)據(jù)的分析預測功能，由于牽涉到人工智能等相關(guān)算法。目前項目組還不具備相關(guān)方面的知識儲備，因此項目組對該模塊功能直接外包。小王將數(shù)據(jù)收集與可視化工作進行了WBS分解，WBS的部分內(nèi)容如下∶

此外，雖然總部沒有提出修改界面，但小王認為舊版的軟件界面不夠美觀，讓軟件研發(fā)團隊重新設計并更改了軟件界面。

試運行階段，總部人員試用后，認為已經(jīng)熟悉舊版的操作模式，對新版界面的布局極其不適應；各子公司數(shù)據(jù)報送人員，認為數(shù)據(jù)上報的字段內(nèi)容與自己公司的業(yè)務并不相關(guān)，填寫困難?？偛亢透髯庸镜脑囉萌藛T大部分認為新系統(tǒng)不是很好用。

【問題1】（12分）

（1）請結(jié)合案例，簡要分析該項目經(jīng)理在WBS分解中存在的問題。

（2）寫出WBS分解時，需要注意的事項。

【問題2】（8分）

請結(jié)合案例，除WBS分解的問題外，項目在范圍管理中還存在哪些問題。

【問題3】（3分）

請描述項目范圍說明書的內(nèi)容。

【問題4】（2分）

請將下面（1）～（4）處的答案填寫在答題紙的對應欄內(nèi)。

項目范圍是否完成要以（1）來衡量，包括（2），（3），（4）。

【信管網(wǎng)參考答案】：http://www.njjt123.com/st/4575423679.html