“計劃趕不上變化!”一個項目經(jīng)理感嘆道。
的確，項目中有相當多的不確定因素，項目經(jīng)理辛辛苦苦做的WBS（工作分解結(jié)構(gòu)），可能因為客戶的改變，甚至領(lǐng)導的一句話，就分崩離析了。
一些公司高層沒有經(jīng)過仔細考慮，也沒有充分征求各個方面的意見，在制定總體計劃時比較隨意，修改起來更是“信手拈來”。項目經(jīng)理也常常借口工作忙等理由，拖延制定詳細的WBS，甚至有項目經(jīng)理認為，不應(yīng)該制定詳細的WBS。
而沒有詳細WBS的危害也是明顯的：造成計劃與控制管理脫節(jié)，無法進行有效的進度控制管理，最終導致項目延期或成本上升?？梢哉f，沒有WBS或者是隨意的不負責任的WBS的項目是一種無法控制的項目。面對各種潛在的變化，項目經(jīng)理應(yīng)該怎樣制定WBS呢？
首先項目經(jīng)理應(yīng)該對WBS有正確的認識，制定WBS就是一個對項目逐漸了解掌握的過程，通過這個過程，項目經(jīng)理可以知道哪些要素是明確的，哪些是要逐漸明確的，通過漸近明細不斷完善。漸近明細也是項目的一個特點，因此WBS的制定需要在一定條件的限制和假設(shè)之下采用漸近明細的方式進行不斷完善。
再者，制定WBS需要有一個現(xiàn)實的方法。一個大型的軟件開發(fā)項目，通常是采用二次WBS方法。即根據(jù)總體WBS，在需求調(diào)研階段結(jié)束、概要設(shè)計完成后，再專門針對詳細設(shè)計或編碼階段制定二次WBS 。
一個方面，需求的顆粒度在一開始往往是比較粗的，因此根據(jù)功能點對于整體項目規(guī)模的估計誤差范圍也是比較大的，只能據(jù)此制定總體的WBS。
另一個方面，需求和編碼工作分解不是一一對應(yīng)的，一個需求的功能點可能對應(yīng)多個代碼模塊，而多個需求的功能點也可能只對應(yīng)一個或少數(shù)代碼模塊。只有在概要設(shè)計完成以后才能準確地得到詳細設(shè)計或編碼階段的二次WBS。
例如，某系統(tǒng)集成公司與銀行簽訂了一個銀行前置機的軟件系統(tǒng)的項目。合同規(guī)定，6月28日之前系統(tǒng)必須投入試運行。項目經(jīng)理小丁組織大家制定了項目的WBS，并制訂了本項目的進度計劃，簡單描述如下：
1．應(yīng)用子系統(tǒng)：1月5日～2月5日需求分析，2月6日～3月26日系統(tǒng)設(shè)計和軟件設(shè)計，3月27日～5月10日編碼，5月11日～5月30日系統(tǒng)內(nèi)部測試；
2．綜合布線：2月20日～4月20日完成調(diào)研和布線；
3．網(wǎng)絡(luò)子系統(tǒng)：4月21日～5月21日設(shè)備安裝、聯(lián)調(diào)；
4．系統(tǒng)內(nèi)部調(diào)試、驗收：6月1日～6月20日試運行，6月28日系統(tǒng)驗收。
2月17日，小丁發(fā)現(xiàn)系統(tǒng)設(shè)計剛剛開始，由此推測3月26日很可能完不成系統(tǒng)設(shè)計。小丁應(yīng)該如何做，以保證項目整體進度不拖延呢？
小丁編制的這個WBS比較粗糙，不適合作為編織項目計劃的基石。只有一個項目的大概框架和子系統(tǒng)各部分的期望完成時間。從該WBS上面可以看出最底層任務(wù)的工期至少也在半個月左右。如果任何一個任務(wù)出現(xiàn)了問題，就必然會出現(xiàn)小丁現(xiàn)在遇到的問題，即延期和延期發(fā)生了較長時間才知道。
在這種情況下，小丁最好是制定二次WBS。最終分解任務(wù)的工期最好不要長于一周，否則可能出現(xiàn)失去控制的情況。而且，在不同階段應(yīng)該有具體直接的責任人。作為項目經(jīng)理，小丁需要保持與某階段的直接責任人溝通，了解進度、發(fā)現(xiàn)問題。