，向成員提供與項目相關(guān)的所有詳細資料，并把WBS樹分解到二層三層。然后要花上一段時間讓成員 進行頭腦風暴式（BRAINING STORM）思考，制訂工作產(chǎn)出和相應人員的職責，記錄每一個工作包的完成標準。
比如我們要結(jié)婚了，怎么來分解呢
無非是辦酒席，拍結(jié)婚照，，等等，這個在論壇上曾有人做了詳細的分解，大家都可以找到。
我們說為什么WBS重要，而且大部分項目管理的咨詢都是針對WBS的咨詢
因為WBS做好了，以后工作就有了參考物，你就知道在不同的階段你應該干什么，完成到什么進度。
其實WBS的劃分是沒有規(guī)則的，主要的考慮角度是方便你做各類的統(tǒng)計工作，為管理服務。
同樣的一個項目其管理的側(cè)重點不同，WBS結(jié)構(gòu)的劃分也可能是完全不同的。
衡量劃分好壞的標準應該是看其是否滿足你管理的需要。
甘特圖也叫橫道圖等，很多名稱，我們說它是甘特在第一次世界大戰(zhàn)時開始使用，它就是在WBS的基礎(chǔ)上將WBS形象化老控制進度
對于基準，我象舉個例子。
我們在沒有結(jié)婚之前，你腳踩幾只船？
我們說法律允許但道德不允許，但你可以腳踩N只船：）
但當有一天你和你的朋友進了一個小黑屋子，然后帶了兩個蓋章的本本的時候，你還可以腳踩N只船嗎？
我們說此時就不允許了，因為你過了一個基準線（BASELINE）
如果你還想腳踩N只船就需要重新回小黑屋子再蓋兩個章就可以了。
那我們的項目要越軌怎么辦，也就是項目變更？
我們說對這樣的項目變更會影響各要素比如時間，成本，質(zhì)量等
我們應該統(tǒng)一由項目管理辦公室來進行控制，如果你要變更基準，必須要進行嚴格的限制。
在客戶提出變更請求時，要建立變更申請登記表和變更申請表，并讓客戶簽字。
有時候一些不是非常關(guān)鍵的模塊PM也不至于一點不講情面，該賣面子的時候還是要賣，尤其是當著對方領(lǐng)導的面，千萬要 賣面子，但是也別賣的太干脆，不要讓他們得到的太容易。
PM在變更管理中需要做的是分析變更請求，評估變更可能帶來的風險和修改基準文件。
如果一個項目進行過程中，比如現(xiàn)在的點心的3G項目，你發(fā)現(xiàn)如果再多花一點時間就可以編寫出對以后非常有用處的程序，但這個程序不在本項目范圍之內(nèi)，你要不要做？
對，我們說不能做，你可以重新起一個項目來做，但不能在這個項目里做，這樣會是我們的項目成本超出，風險增加，而且和其他的項目缺少比對性和參照的價值。
這也是我們說現(xiàn)在有大約80%以上的項目失敗的原因，我們說項目失敗并不是項目進行不下去了，徹底破產(chǎn)，在PMI有明確的定義，凡是項目的成本超出預算，質(zhì)量沒有得到保證，時間超過預計等等都在失敗的范圍之內(nèi)。
這個在華為做的很好，華為有個有名的增量開發(fā)的名聲。
只用20%的功能先滿足你80%的需求，其他的功能我可以開發(fā)升級的版本，于是就在小數(shù)點后平明的增加數(shù)字，于是就是了V1，V1.1，V1.11....等版本
它從來不一下子滿足你所有的需求，我們大家想想，誰沒有事情拿出自己的手機把所有的PING碼都試用一下，我們說沒有，我們大部分的需求是在打電話，發(fā)消息，打打游戲，對不對？
這點在項目管理中非常重要，請大家結(jié)合資料好好研究。
項目干系人是什么東東，誰給我舉一個例子？
對，包括項目人員的老婆孩子，正確
我們說有的項目需要的時間很緊張，如果你的項目成功了，但項目的程序員們都成了光棍，那項目還是非常失敗，至少不是喪心病狂的PM這么想。
合理解決項目干系人的沖突是個很累的問題，其中還包括你的只能經(jīng)理們，你的董事長，你的客戶，等等，等等，有的說沒用？
好，如果你的項目進展不下去，你該怎么辦？&nbs