開始一個新項目或版本時候，首先是和用戶一起確認需求，進行項目的范圍規(guī)劃。項目是范圍，進度，質量和資源四要素的平衡，用戶對項目進度要求和優(yōu)先級高的時候，我們往往要縮小項目范圍，對用戶需求進行優(yōu)先級排序，排除優(yōu)先級低的需求。另外我們做項目范圍規(guī)劃的一個重要依據(jù)就是我們的歷史經(jīng)驗數(shù)據(jù)，對項目特征的清楚認識，項目范圍規(guī)劃初期需求你進行一個較宏觀的估算，否則你很難判斷清楚或給用戶承諾在現(xiàn)有資源情況下，你3個月時間里面是否可以完成20個或更多用戶功能。

　　正規(guī)過程好像是先確認項目范圍，然后根據(jù)WBS->進度計劃確認實際的項目周期，但實際情況往往很難如此，用戶往往對進度的關注度大于對范圍的關注度，一個項目半年或一年都看不到具體的產(chǎn)品出來用戶肯定是無法接受的，所以我們的軟件項目一般也是按版本增量迭代進行開發(fā)。

　　另外這里需要強調(diào)下項目目標的確定，項目的目標不能簡單理解為在某個時間點完成所有功能。項目另外一個重要目標就是項目的質量目標，你完成的這個項目需要達到那個等級的質量標準，交出的產(chǎn)品BUG泄漏率要控制在什么范圍內(nèi)等內(nèi)容。項目的質量目標不會影響到我們的范圍，但會影響到我們后續(xù)評審，測試等時間的安排，直接影響到項目的進度。

　　PMBOK里已經(jīng)明確提到項目范圍定義的另一個重要目的就是項目的績效測量和驗收準則，你交付項目的時候用戶會根據(jù)用戶需求說明書內(nèi)容對項目進行驗收，所有我們項目的范圍的定義必須是明確，量化，可驗證和可測試的，這樣才能夠避免后期無謂的糾紛。

　　另外在概述階段需要分析項目的假設和約束，假設和約束又分為技術方面和非技術方面，在這里我們分析的所有假設都可能成為項目的風險。