根據(jù)PMI的解釋，接單之后項(xiàng)目自然轉(zhuǎn)入啟動(dòng)階段。啟動(dòng)階段PM的主要任務(wù)是率領(lǐng)總體架構(gòu)設(shè)計(jì)師和系統(tǒng)分析員收集盡可能詳細(xì)的數(shù)據(jù)，確立盡可能詳細(xì)的需求，進(jìn)一步確立詳細(xì)的項(xiàng)目范圍，預(yù)估資源，確立其他方案并獲得進(jìn)入下一階段的批準(zhǔn)。
在這個(gè)階段，隨著需求分析的深入，PM也開(kāi)始在公司內(nèi)部進(jìn)行人員挑選和資源爭(zhēng)奪，著手組建自己的項(xiàng)目團(tuán)隊(duì)。項(xiàng)目即將進(jìn)入計(jì)劃階段。在收集完數(shù)據(jù)之后，PM要和客戶開(kāi)始明確項(xiàng)目的大小，成本，規(guī)格，期限等重要特征并將其寫入合同文本，同時(shí)準(zhǔn)備內(nèi)部的包括預(yù)算，衡量標(biāo)準(zhǔn)等文檔，建立項(xiàng)目的評(píng)估標(biāo)準(zhǔn)。接下來(lái)就是需求分析。由于專業(yè)的原因，我們這里僅討論軟件工程項(xiàng)目的需求分析（以下簡(jiǎn)稱需求分析）。需求分析的主要參與人員有PM，總體架構(gòu)設(shè)計(jì)師，系統(tǒng)分析員，熟悉業(yè)務(wù)流程的客戶。PM統(tǒng)領(lǐng)的團(tuán)隊(duì)這時(shí)候還不是真正的開(kāi)發(fā)團(tuán)隊(duì)，我們叫做前期團(tuán)隊(duì)。
隨著需求分析的逐步深入，新的團(tuán)隊(duì)成員不斷加入，啟動(dòng)階段結(jié)束的時(shí)候正式的團(tuán)隊(duì)將建立。對(duì)一個(gè)已經(jīng)啟動(dòng)的項(xiàng)目來(lái)說(shuō)，需求分析直接決定了項(xiàng)目的成功與失敗。最初的需求體現(xiàn)在客戶的工作說(shuō)明書或招標(biāo)文件及附件上。這種需求一般比較含糊，無(wú)法體現(xiàn)客戶真正的需求。前期團(tuán)隊(duì)要根據(jù)自己的經(jīng)驗(yàn)和客戶溝通并引導(dǎo)客戶進(jìn)入正軌。有時(shí)候客戶會(huì)很不講道理或者思路僵化，就要求按照他的思維去定一些明顯錯(cuò)誤的需求。這個(gè)時(shí)候團(tuán)隊(duì)成員要耐心和客戶舉事實(shí)，談經(jīng)驗(yàn)，講道理，用圖形或模型等直觀的方式將需求描述出來(lái)，比如常見(jiàn)的數(shù)據(jù)流圖等。所以說(shuō)，爭(zhēng)論再所難免，客戶有時(shí)候會(huì)吹胡子瞪眼睛拍桌子甚至?xí)f(shuō)"這個(gè)東西不要你們做了"之類的話。PM此時(shí)除了要親身參與需求分析綜合整理文檔之外，還要處理好團(tuán)隊(duì)成員與客戶的關(guān)系，確保關(guān)系不會(huì)惡化到無(wú)法收拾的地步。只要PM盡力約束團(tuán)隊(duì)中的成員，這個(gè)度還是很容易控制的。
對(duì)快速開(kāi)發(fā)和疊代開(kāi)發(fā)來(lái)說(shuō)，需求和實(shí)現(xiàn)往往是同步進(jìn)行，開(kāi)發(fā)速度快是一大優(yōu)勢(shì)。對(duì)有相同或類似模式的小項(xiàng)目來(lái)說(shuō)采用快速開(kāi)發(fā)或疊代開(kāi)發(fā)是很合算的做法，時(shí)下流行的極限編程就是針對(duì)這方面建立的思維模式。然而，大中型項(xiàng)目中有太多不一樣的需求和模塊。如果不是因?yàn)轫?xiàng)目有差異，那么市場(chǎng)上就只有產(chǎn)品而沒(méi)有項(xiàng)目了。所以，大中型項(xiàng)目的需求要認(rèn)真仔細(xì)的去做。我們要討論一個(gè)問(wèn)題，究竟應(yīng)該在需求分析和總體設(shè)計(jì)上花費(fèi)多少時(shí)間？我們熟悉的瀑布開(kāi)發(fā)模式基本上分需求分析，總體設(shè)計(jì)，軟件開(kāi)發(fā)，測(cè)試等幾個(gè)階段，然而究竟應(yīng)該在前兩個(gè)階段上花多少時(shí)間卻沒(méi)有定論。實(shí)際項(xiàng)目操作的例子表明，分析設(shè)計(jì)的時(shí)間越長(zhǎng)，需求設(shè)計(jì)做的越詳細(xì)，測(cè)試的時(shí)間就越短，返工率越低，風(fēng)險(xiǎn)也越小，成本越容易得到控制。而需求分析和總體設(shè)計(jì)沒(méi)有做好就急忙上馬進(jìn)行開(kāi)發(fā)的項(xiàng)目在項(xiàng)目初期進(jìn)展順利的時(shí)候問(wèn)題不大，到了項(xiàng)目后期和測(cè)試階段一些潛伏期比較長(zhǎng)但是破壞作用比較大的問(wèn)題就會(huì)凸顯出來(lái)，造成返工，延長(zhǎng)測(cè)試時(shí)間。所以與其把問(wèn)題堆積到緊張的項(xiàng)目后期，不如把時(shí)間多花點(diǎn)到需求分析和總體設(shè)計(jì)上?；A(chǔ)夯實(shí)了，金字塔就容易造了。
在日本公司打工的程序員們可能都知道，小日本的軟件規(guī)范非常厲害，他們花在需求分析和總體設(shè)計(jì)上的時(shí)間通常在40%到50%左右，遠(yuǎn)遠(yuǎn)超過(guò)國(guó)內(nèi)軟件項(xiàng)目的實(shí)施，效果也要強(qiáng)的多。他們總體設(shè)計(jì)的規(guī)范甚至詳盡到某個(gè)過(guò)程該如何判斷，確立什么樣的條件，換言之就是把什么時(shí)候該如何寫(if...else)語(yǔ)句都幫程序員定好了。在這樣的軟件規(guī)范下，程序員更象是裝配流水線上的工人，對(duì)一個(gè)模塊或技術(shù)熟悉到一定程序就變成了完全的重復(fù)性勞動(dòng)。所以在日本和歐美經(jīng)常會(huì)有程序員是低級(jí)工作一說(shuō)，很多人不明就里，對(duì)國(guó)內(nèi)程序員也照搬，對(duì)國(guó)內(nèi)的程序員來(lái)說(shuō)是很不公平