一、接手項目階段
項目經理在接手項目時，應該進行項目干係人分析，得出哪些人員對項目起積極推動作用，哪些人員對項目持有消極抵抗態度。隨後，客戶及公司領導會要求制訂一份項目整體計劃，此計劃往往是需要根據客戶方要求的結束日期進行倒推，此份計劃比較粗，只需要按時間點列出進度計劃安排、相應可交付物、投入人力資源。（其實我個人理解這時候的整體計劃更像是里程碑計劃）
除此之外，我覺得還應該準備一份項目範圍說明書，明確項目範圍描述、項目驗收標準等，這在後期範圍變更以及項目驗收時是一個依據。
二、需求階段
此階段需要反覆跟客戶方業務員及相關關係人進行溝通，明確需要開發的需求。此時需要制訂需求說明書，並與客戶方進行確認。
在與客戶方確認需求的同時有可能有些需求暫時無法確認，爲了進度不受影響，此時需要項目經理先確認能夠確認的需求，並同時安排項目組成員進行功能設計，這二個過程往往是同時進行的。
確認需求的過程中項目經理需要提交需求說明書、未確認需求的清單說明。
項目經理安排項目組員進行設計過程中需要設計人員提交設計說明書（一般都是界面原型設計），完成設計說明書後有必要提交給客戶方相關人員進行確認。
三、任務分配階段
根據已確認的需求，項目經理需要進行任務分配，任務分配前需要結合需求及設計進行工作分解，將需要完成的工作分解到每個按鈕功能，儘量做到能分解成能在3天內完成的工作。我個人很不贊成項目經理“獨裁”完成任務分配(現實中會出現實施過程中有很多工作任務不在計劃中，而且會出現死命加班的情況)，此過程需要考慮項目組員的業務及技術能力，所以分解過程需要讓項目組員參與，分解完成後提交任務清單文檔。
任務分解完成後，根據任務清單及任務優先級關係分配任務到人，提交任務進度計劃表。
四、定期溝通及監控階段
此階段需要根據項目組員的工作情況進行跟蹤監控，包括工作過程及結果完成情況，需要監控任務完成情況、任務完成與需求匹配情況、代碼編寫的規範性，找出實際與計劃的偏差，分析偏差，並採取相應措施，提交項目實施過程日檢表、需求矩陣跟蹤表、項目進度跟蹤表、階段性項目進度報告表
監控過程需要做的工作比較多，項目經理往往需要將部分工作交給項目組員完成，比如代碼編寫的規範性審查可交給技術稍好些的組員協助完成。
監控項目實際完成情況項目經理往往需要通過組員的周工作日誌、項目例會、項目週報來了解，根據實際完成情況與計劃進行對比，找出偏差原因，並採取相關措施，提交進度偏差控制表、糾正預防措施記錄表文檔。
監控任務完成與需求匹配情況項目經理往往需要通過組員完成需求監控清單，將需求落實到代碼。
定期將可交付物給客戶方進行演示。
此過程還需要制訂出與團隊內部及客戶方進行溝通的計劃，加強溝通，重視溝通。針對會議等形成的決議要定期進行跟蹤，形成會議決議跟蹤表。
五、範圍變更控制階段
在項目實際開發過程中，客戶往往會有需求的調整或變更，這時候需要妥善處理好客戶提出的調整意見或變更要求。
項目經理可根據調整的工作量及業務對系統的整體影響情況與客戶進行溝通，如果調整工作是必須開展的那麼必提交調整或變更申請、評審意見報告，那怕是形式也得提交，因爲如果項目因此延期則有理由說不是因爲我們的原因；如果調整可放到後期進行則可先把問題記錄下來後期再調整。
此外，變更對項目造成了影響，需要更新項目進度計劃表。
六、團隊建設階段
項目開始項目經理需要制度一些制度，比如上下班制度，會議制度、周工作日誌制度。
項目開發工作繁忙而緊張，團隊成員壓力增大，情緒因此受影響導致工作效率下降在所難免，項目經理要經常觀察團隊成員的情緒，要與團隊成員經常溝通談心，遇到問題要與其一起解決。此外，定期組織團隊活動，如聚餐等。
我個人更喜歡人性化的管理方式，能多照顧團隊成員的儘量多照顧，而不是一味只想着自己。
要想把一個項目做好真的不容易，或多或少會與客戶方產生矛盾。我個人覺得我們作爲乙方，應該站在甲方客戶的位置多思考問題，找到雙方都能較爲認可的解決方案，做到“尊重、聆聽、理解、共贏”。
