一、做好計劃
項目計劃是指導項目執行的依 據，也是衡量項目組績效的基準，做好計劃至關重要。 項目計劃是由項目總體計劃和子計劃組成的。通常，進度計劃、質量計劃、風險計劃、測試計劃、配置管理計劃以及溝通計劃是項目計劃中比較重要、對實際工作也 比較有指導意義的幾個子計劃。其中，進度計劃是所有計劃的基礎，它確定了項目的時間范圍，它讓你知道在哪個時間應該完成哪項工作;質量計劃則告訴你這項工 作是否已經完成，是否滿足要求;風險計劃將會告訴你完成這項工作可能出現的障礙，應如何解決，比如對于維護型的項目要考慮到人員常被借調，突發任務對計劃 的影響等;測試計劃將會告訴你如何循序漸進的發現工作中存在的漏洞，是否可以交工;配置管理計劃將會為你列舉一下這項工作將由哪些部分組成，哪些是關鍵 的，哪些是可變的;溝通計劃將告訴你在做這項工作的過程中你要跟哪些對象共事，應如何跟他們協調一致。 另外要注意項目計劃是項目組全員參與的，目的是項目組團隊對計劃取得一致，另一個原因是獲得雙向的一個承諾。
1、針對確認的需求評估工作量，評估要基于功能細節來做，經過估計計劃才有意義，與實際偏差才會少一些
2、項目計劃的緩沖時間
按常規的項目計劃，一般預留10-20%的緩沖時間，以應對中間可能出現的風險，比如人員變動帶來的影響或接口部門的節奏不一致對項目計劃造成的影響。
3、接口溝通的重要性
一 般項目中難掌控的是接口系統的開發進度，不同部門的工作習慣和人員能力不同，加強溝通和引導。通俗地講，是項目組在溝通過程中，要預先把這部分的工作 分析好。對涉及雙方溝通 的結果需要有文檔記錄，比如會議紀要。確定責任人、完成時間等。出了問題后可追述到人。追究畢竟不是項目組要的結果。為確保項目能順利進行，接口的溝通是 很重要的，比如研發組在溝通過程中能否處于權威的地位?能不能領導其它接口系統的工作?可視情況適當借助上級或對方上級的力量，對相關接口人進行督促。保 障項目的進度。
4、項目計劃是漸進明細的過程：計劃也不是一蹴而的，任何人也沒有料事如神的本事，它是一個由宏觀到微觀、由粗到細逐漸分解逐漸細化的過程。 如果不考慮外部因素的影響，計劃變更的頻率和幅度，可直接反映出制定計劃時存在的問題，比如可操作性�？偨Y經驗，避免下次再犯同樣的問題。
5、項目計劃的粒度
按PMI的提倡工作任務的分配是規則是80小時的單位，軟件行業屬于高新產業，對進度的控制相對要比建筑行業更緊湊一些。所以軟件研發類的項目更應該控制在2-3內比較合適，即16-24小時。
二、需求變更控制
首先需求分析應該有兩層的含義：
1、理解用戶的需求，2：辨別用戶需求。做到這倆點的基礎是需要理解用戶的業務需求，即業務模式和操作習慣(通過信息系統或人工處理事務的方式)。
理解用戶需求：指的是在做調研的時候，要理解用戶表達的意思，不要漏掉用戶提供的細節。比如文檔或口頭的描述。為辨別用戶需求做基礎
辨 別用戶需求：一般系統常見的問題是，業務專家有很多，很多時候，專家意見不一致。甚至天馬行空，不符合邏輯，不切實際的需求很多，需要在了解用戶的業務模 式后，才能辨別出來。注意在調研的時候要做好文字記錄，不要漏掉細節。回頭仔細琢磨。這一點是很多項目經理或需求分析人員忽略的地方，為后期變更埋下隱 患。
避免這種問題的情況是，找理由到客戶現場，想辦法收集基層操作員的需求。
2、預估需求
對于用戶未提到的需求，但可能以后會擴展的需求的應對方法。對于內部系統來說，可以早期引導用戶。對于外部項目要在設計時考慮到，保留必要的接口。等客戶提出后，執行需求變更。增加合同額。
3、焦油坑：需求變更之站得高未必看得遠
“領導層定的需求”或叫“排腦袋型的需求”
很多業務系統的需求，沒有用戶方實際操作人員的參與，導致的現象是“站得高，看得遠，但不一定看得清楚”。這種問題發生后一般是影響范圍很大，但又不能不修改，通常是超出了項目經理控制能力范圍之內。客戶還不愿意加錢，需要盡快和公司領導匯報，由領導出面來解決。
