1. 建立正式的申請和處理流程
雖然眾多項(xiàng)目管理人員對于變更可能帶來的巨大影響有深刻的理解，但令人不解的是我們常?？吹竭@些變更的提出、討論和執(zhí)行卻常常停留在口頭上。這樣做有兩個弊端：首先是時間一長，無論是當(dāng)事人還是開發(fā)團(tuán)隊(duì)的其它成員都說不清楚變更是因何發(fā)生以及結(jié)果怎么樣了。顯然，這對于提高項(xiàng)目管理質(zhì)量、改進(jìn)開發(fā)過程是很不利的。其次是由于缺乏形式上的約束和對變更沖擊的定量化分析，變更會被非常隨意地提出、或被草率地執(zhí)行，大大影響了項(xiàng)目的進(jìn)展和開發(fā)質(zhì)量。因此建立一個正式的變更處理流程并真正得以實(shí)施非常重要。
2. 定量化的變更沖擊分析
變更作為一個計(jì)劃外的風(fēng)險(xiǎn)因素對項(xiàng)目肯定存在沖擊，只是大小的差別。因此，如果能夠定量化地評估變更帶來的影響就能幫助開發(fā)團(tuán)隊(duì)作出正確的應(yīng)對決策。這就是變更管理中的沖擊分析環(huán)節(jié)。上面談到了，分析的基礎(chǔ)是追蹤矩陣，它記錄了項(xiàng)目管理要素之間的聯(lián)系關(guān)系。從這些關(guān)聯(lián)關(guān)系中我們可以找到每一個潛在會受到影響的要素，評估對其的影響，從而組合出變更對整個項(xiàng)目可能造成的沖擊。
從上面的例子可以看到，即使是加了一個看似與其他關(guān)系不大的需求，也會造成一系列的潛在影響，更不用說是在需求眾多、關(guān)系復(fù)雜的大型應(yīng)用系統(tǒng)開發(fā)項(xiàng)目中了。
3. 組成變更控制管理委員（CCB）
作為變更管理的一個核心控制環(huán)節(jié)，變更控制委員會（簡稱CCB）起決策和管理作用。它通常由客戶代表和開發(fā)團(tuán)隊(duì)代表共同組成，負(fù)責(zé)評估變更沖擊以及 決定是否要實(shí)施這樣的變更。這種綜合了需求方（客戶）和開發(fā)方（開發(fā)團(tuán)隊(duì)）力量的委員會能夠較好地權(quán)衡變更代價(jià)，從而減少了單方面考慮變更所帶來的不利影響。
4. 不要忽視變更執(zhí)行的管理
在實(shí)踐中很多開發(fā)團(tuán)隊(duì)雖然組成了CCB并有一定的處理流程，卻往往忽視了對于變更執(zhí)行的管理。而變更實(shí)施的好壞、完整性對于項(xiàng)目本身的影響同樣是巨大的。在這方面，根據(jù)沖擊分析和變更評審的結(jié)果，建立一個變更任務(wù)列表并且追蹤它的執(zhí)行是一個很好的實(shí)踐。
總結(jié)
軟件項(xiàng)目與傳統(tǒng)的工程項(xiàng)目有著很大的不同，這種不同導(dǎo)致描述需求的方式，實(shí)現(xiàn)需求，進(jìn)行項(xiàng)目計(jì)劃、監(jiān)控項(xiàng)目進(jìn)度的方式都有很大的不同。由于這種不同，傳統(tǒng)的基于任務(wù)的項(xiàng)目管理方法對于應(yīng)用類的軟件項(xiàng)目并不適用。這里我們提出以需求為中心的軟件項(xiàng)目管理。 通過提高需求描述的質(zhì)量、采用小版本發(fā)布策略、將用戶需求作為小版本的目標(biāo)來組織和計(jì)劃項(xiàng)目開發(fā)、積極應(yīng)對需求變更、提供以用戶需求為中心的項(xiàng)目進(jìn)展視圖，從而和客戶一起來保證項(xiàng)目的成功。