一、前期與客戶需求調研階段：
1） 抓住主要的人物
這個項目的實際使用者，提出項目需求具有決定權的人。這一點比較難做到。主要是看對方是屬於什麼單位，如果是政府部門就麻煩很多，因爲政府部門等級制度觀念很明確，他們是很討厭越級之類的需求提出。在一個需要找準找對能提出具體需求的人。即使提出了具體需求如果他不能確認需求這樣也是一大危險。必須找準可以給你在具體需求書上簽字確認的那位領導。不然一旦沒有這個環節，那日後的工作量就要成倍的付出，才能挽回。（重點）
2） 不能輕易將需求分析看成是客戶提出的要求
有些項目客戶方面可以抽調一些人協助調研需求。但是這些協助的人員只能是大概的說清楚具體使用者的要求。不能詳細的說明具體的重點放在什麼功能上面所實現的表示。而且他們一般給的需求僅僅是他們能理解到的，還不能完全具體到使用者的上面。項目經理或是需求調研人員需要自己在重新分析作出相應的需求報告，不然一味的拿過來讓開發人員去理解，去喫透這些那簡直是一種折磨。因爲“你”是整個項目的調研人員不是真正的開發人員去理解需求，而是你來喫透需求徹徹底底的將需求轉化成你所理解的程序流程，程序中所要涉及到的某些關鍵點。如果人人都可以拿別人寫的需求分析來做爲你的需求交給開發人員的話，那麼人人都可以做項目經理作調研人員了。（次重點）
3） 分析需求要透徹必須具體到某個點，把握住關鍵點的控制，不可擴大需求
經過前面兩點後可能這一點相對來說不時非常重要了。但是如果前面兩點都不注意的話後面談和控制？假設一個項目中也有需求分析了，但是最重要的控制關鍵點沒有名確。那如果別人在已有的需求上面加多幾個功能都不爲過，主要原因是沒有明白的告訴別人在什麼時間此類的需求已經明瞭的確認。並且除了以前提出的需求，其他的需求不能在次提出。所以別人突然想到了什麼就是可以提出來讓你修改，這是最可怕的。如果明確了關鍵點的確認，那就算是提出也沒有關係，可以做爲二次開發來再次簽訂相應的開發合同。俗話說得好“空口無憑，立字爲證”嘛。這是需要建立在需求調研階段最難最不好控制的地方。（必需做的工作）
二、中期演示工程的編寫
1）一旦確認了所有的需求，就需要具體來設計一個演示的模型確認開發效果。
（經過了上面的需求調研，具體的需求分析已經徹底明確後，這一步的工作就比較輕鬆一些）這裏就需要公司中一些部門的具體配合協同完成了。完成後又要開始前面第一部分相同的工作了此時將需求更換成了演示工程。這個時候應該是需要客戶確認書的，因爲一旦確認後以後的開發工作相對就輕鬆多了，即便是更改某些細節上的需求也是控制在前期。
2）開發文檔整理
經過了這兩個階段，相應的需求全面了，界面明確了。剩下的就是將一些文檔性的東西拼補齊全，這是項目經理應該做的大事情，當然如果之前的需求文檔都明確簽字，這裏的工作可以說是複製粘貼了（首先確認你縮寫的東西你帶領的開發團隊（Team）能看的明白）。
三、項目後期開發工程
1）初期階段的開發
進入初期階段的時候就已經不需要再重複的進行相關需求的調研階段了，還是那句話前期的工作要充分作盡。具體的開發工作就應該是項目經理集合團隊（Team）分配工作，將前期自己所做的具體需求分析分發下去，根據需求文檔來編寫項目了。這時候項目經理所做的就是將自己調研階段理解透徹的需求分析講解給每一個開發人員。大家共同協作推進項目進度。此時這個團隊裏面需要進行必要的溝通，保證每個環節不出現不必要的差錯。這時候項目經理就是這個環節的協調者（謹慎行事，這裏如果控制不好將對以後的驗收帶來困難）。這個階段應該是加快速度開發完成。完成具體模塊的功能，經過測試部門測試通過。
2）中期階段開發
進入中期，將初期開發的成果交付客戶試用，讓客戶提出應用界面的修改意見（注意：這裏是界面的修改意見。如果功能需要修改這時候你就可以拿出以前確認的文檔去說事了。所以前期的需求調研客戶確認需求開發文檔是非常重要的。這時候就是拿來力爭的憑據。）如果需要加功能在改動不打得情況下可以做爲一種服務性質來更改。如果需要改動項目的底層後臺可就要嚴格控制了。
4） 後期開發收尾
到了這個階段經過前兩個階段不斷的修改，這裏應該是離終點線不遠的地方了。也應該是準備臨門一腳的時刻。這裏經過修改後基本上達到了客戶的滿意是時候可以讓客戶進行相關的上線測試使用階段了。這裏要堅決杜絕客戶的需求提出，能做的僅僅是調試工作。項目組成員開始整理整個項目的開發文檔交付項目經理整合，以備驗收階段。
四、項目驗收
項目的驗收主要的就是看整個開發過程中是否能嚴格的按照“代碼+註釋+文檔”的過程來了。如果到項目完成後再去補齊項目文檔也是可以的，當然如果可以提前做的工作儘量的提前作好。以免突擊出來的文檔被打回。
五、項目的經驗總結
這個就看個人了，看你是否在這個項目當中得到經驗的積累，知識技巧的提升了。
六、整個項目中項目經理擔當的角色
在整個項目中，項目經理的位置要擺正，你是一個技術型的經理，還是溝通型的經理。這裏的技術型和溝通型是相對而說的。技術型的經理往往自己獨裁比較嚴重，不能有效地聽取採納他人意見（這裏注意：畢竟你是經理，是一位協調人不是總裁，不能一味的獨斷專行。這種做法容易讓你很難接受一些新的理念）。溝通型的相對來說容易聽取別人提出的建議，但是不能絕對聽取，因爲你纔是最後的決定者。可以通過一些方式和實際的結果來證實你所採用的方案優於別人。