一、 項目需求分析
項目的需求階段需要注意的問題:
1) 項目需求的切入點是“業務層面”的，當選擇技術方案、制定項目規劃、確定驗收標準等環節時，“業務目標”比“技術實現”重要的多，首先搞明白的是客戶爲什麼這樣做，而不是怎麼做；不能客戶說什麼就做什麼，只有理清客戶要拿來做什麼，你才能爲後續的技術方案的擬定，準確描述項目計劃及功能驗收奠定基礎。
2) 項目干係人確定。不要忽視那些並不關心項目，而且又不直接與你聯繫項目相關人員，比如客戶的領導，在需求擬定之後，一定要相關人員對於項目的目標達成一致。多數情況下，需求並不是技術部門提出的，而是業務部門提出的，技術部門提出的需要，不能直接作爲最後的需求，一定要業務部門給予確認，避免不必要的麻煩。
3) 在項目需求階段，對項目的中可能引起爭議的問題給予確認，明確自己的需求範圍，避免客戶提出超出項目需求範圍的功能，這樣對於後期項目的進度及技術實現，驗收標準等等造成影響。對於需求之外的問題，儘早給予明確的回覆。
4) 其中還有一點最重要的問題，是合同問題，其實很多問題，可以在雙方達成一致之後，在合同中說明變更控制流程，這樣可以有效避免後續客戶對於需求變更無底線。
二、 項目計劃
1) 項目里程碑節點設置
項目的里程碑比驗收節點重要，把握住過程就把握住了結果，對於項目控制來講，里程碑就是最有效的過程控制手段。設置項目的驗收節點，屬於“硬性”壓力，沒有迴旋的空間，但里程碑有時候是“軟性”壓力，但忽視里程碑式是將壓力進行積累，將風險做實的過程。
項目管理者對里程碑要給予重視。
a) 計劃階段：合理規劃里程碑節點，使其有可行性，有驗收價值；
b) 執行階段：圍繞着每個里程碑安排工作，找到項目“節奏”；
c) 溝通過程：項目動起來，讓項目成員清楚項目目標，將里程碑的壓力傳達給項目中的每一個人包括客戶；
2) 項目計劃中對於現有資源利用
項目計劃中要對現有資源進行合理分配，項目的資源分爲很多種，人員，相關資源，經費，客戶或者業務給予支持的人員及相關材料，將資源落實下來，而不是打招呼，這是個很煩人的事情，當你需要的時候沒有了，這樣對於項目進度的影響很大，人員的變動，項目的預支是否合理，都要明確。提前預見可能出現的資源衝突問題。以“例會”爲單位，討論並確認未來幾周資源變動情況及項目進度。客戶和業務人員的工作，我們可能無法控制，但儘早知道可以早作打算。
3) 項目風險的控制
項目開發中會遇到各種問題，如人員變動、資源衝突、對於技術的不熟悉等問題，能夠在項目開始前給予風險規劃，則對於項目風險的控制更加穩固。如新技術作爲風險項，可以對員工進行技術培訓，人員變動情況，與員工溝通側面瞭解其內心想法，給予提前的人員備份，資源衝突提前的預見及協調等解決有段去合理安排及溝通。
三、 項目控制
1) 項目進入執行階段，關鍵要大家找到節奏感，這樣才能推動項目，才能佔有主動權，如何找到這個節奏感？根據不同的項目成員及項目的性質不同方法不一定，但大體上相差不大，設立里程碑，作爲中長期的目標，週報及項目例會保證短期目標的實現。無論中長期里程碑還是短期的項目例會，核心目標是通過這種方式及時的讓大家瞭解項目的情況，預見可能的問題，找到解決問題的方法，同時週期性的與主要項目干係人進行溝通（項目週報+面對面的討論）。
2) 關於項目的文檔
我相信很多程序員及項目經理都不喜歡寫文檔，但項目文檔對於項目的經驗延續、體現個人工作價值方面及後期的系統維護有很大的用途。掌握寫文檔的技巧及養成寫文檔的習慣可以避免不必要的麻煩。比如：某個功能的修改，沒有形成文檔，對於功能修改者清楚爲什麼修改，修改位置，時間已久估計修改者本身都記不得了；寫出文檔給業務或客戶確認他們所提出的問題，並給予解決的問題方法的描述。這樣可以避免以後爭論。
寫文檔有幾個注意點：
a) 搞清楚文檔給誰看的？目的是什麼？客戶或者領導想看到什麼樣子的文檔？即使同一份文檔，對已不同對象，所關心的側重點也不同。例如：一份功能需求規格說明書，業務人員（客戶）不管你怎麼做，只關心你做出的效果及完成日期；程序員關係的是如何實現這個功能；
而項目經理可能關心的是所需投入的人員及其它資源成本。
b) 要善於把複雜問題簡單化，讓不懂技術的業務人員（客戶）、管理層，通過文檔明白關鍵點的所在。比如：可通過圖表，插圖之類的可視性強視圖文檔給予說明。枯燥的文字很難讓所有人都認真去讀的。
3) 項目變更問題
沒有完全按照最初的計劃執行的項目，或多或少都會發生需求變更的，用戶的想法有時候是不確定的，我們完全控制不住了。想盡一切辦法避免需求變更，估計也是不現實的，但至少有幾點我覺得可以力求做到：
a) 在需求階段，儘可能的把需求搞清楚；
b) 在執行階段，嚴格遵循變更控制流程；
c) 對於發生了的變更，相應的調整文檔；
問題也許發生在執行階段，但根還是在需求過程中，要了解用戶爲什麼要做（業務動機），以及什麼是可行的方案，而不是業務說做什麼就做什麼。
4) 項目驗收及最終投產
項目的驗收標準是根據最初的業務需求編寫的，而且由業務部門給予確認，項目組完成相關項目功能的開發，提交給業務測試及修復業務反饋的問題，待最後業務驗證通過後，進行最後的投產，投產中需要注意的在根據開發階段積累下的腳本進行梳理時，儘量多人蔘與防止遺漏，造成上線失敗。
四、 項目團隊與溝通
1) 團隊成員的選擇。對於經驗重要還是工作熱情重要，我想對於項目管理者而言，項目組成員的工作熱情相對更重要。留下工作經驗相對多的人不易過多，因爲公司不會同時滿足所有有經驗者的要求，從而也調動不了所有人的熱情，留下幾個經驗豐富，給予一定的物質上的滿足，同時加入一些新鮮血液，這樣的團隊才能更好的完成項目。當然這都是因爲公司資源不足的情況下才採取的方法。
2) 項目團隊的成員從技能、性格，甚至是地域上的不同，給溝通帶來了不便，你認爲正確的方法不一定所有人都這樣認爲，這樣的情況下，項目組管理者要起到協調各個人員，和睦相處的前提下高效的完成任務。比如：一個不善於溝通的同事，要瞭解到他的愛好，給予不定期的鼓勵，讓其慢慢適應去說出自己的想法；一個多動愛說的人，就讓其主動擔起組織活動的任務；
同時項目經理要及時溝通，要了解每個同事所遇到的 困難，及時給予幫助，給予支持。要在不壓制每個人 個性的情況下，融合整個團隊，讓他們在團隊中都能 體現其存在的價值。
3) 如何與客戶溝通，讓客戶和老闆滿意？
客戶滿意是項目達到預期目標？是按時完成？老闆滿意是盈利？這些似乎都是滿意的答案。但是實際的項目中多多少少會有不如意的問題出現，但問題本身是否解決並不重要，而在於你是否與客戶與老闆進行了充分的、良好的溝通。
4) 項目經理整合團隊力量
項目中每個成員要讓自己有價值，無論是領導者還是普通員工，只有自己在團隊中體現自己的價值，才能立足於項目之中，作爲項目經理，要通過良好的溝通能力，理解每個人的處境、動機；力所能及，提供團隊成員所需的；通過合理的渠道，向上級領導反饋成員的工作績效。總之要了解每個成員，爲項目風險提供消息，做出進一步的判斷。
5) 對於里程碑的認可度的檢驗
不管平時項目組怎麼樣，關鍵里程碑還是要準時完成，保證了過程了纔能有好的結果，期間要明確我們的里程碑及驗收標準，傳達到每位成員，項目開始階段及執行階段要檢驗每位成員對里程碑的理解是否準確無誤。