在開發活動中，項目計畫是項目啟動後的頭一件重大事件，但也是經常被忽略的一件事。
項目計畫好比是一份項目的交通圖，指導項目準確的達到目標，即使它沒有被形成規範文檔，它至少會在項目經理的腦子裡，只不過比較粗糙和模糊罷了。
為什麼每個項目都需要一份項目計畫，並且要形成規範的文檔呢？這是因為：
第一、通過制定計畫，使得小組和有關管理人員，對項目有關事項，如資源配備、風險化解、人員安排、時間進度、內外接口等形成共識，形成事先約定，避免事後爭吵不清；
第二、通過計畫，可以使得一些支持性工作以及並行工作及時得到安排，避免因計畫不周造成各子流程之間的相互牽掣。比如測試工具的研發，人員的培訓都是需要及早計畫和安排的。
第二、可以使項目實施人員明確自己的職責，便於自我管理和自我激勵；
第三、計畫可以有效的支持管理，作為項目經理、業務經理、qa經理、測試經理們對開發工作跟蹤和檢查的依據；
第四、做好事先計畫，就可以使注意力專心於解決問題，而不用再去想下一步做什麼？
第五、計畫是項目總結的輸入之一，項目總結其實就是把實際運行情況與項目計畫不斷比較以提煉經驗教訓的過程。通過計畫和總結，項目過程中的經驗和教訓別很好的記錄和升華，成為“組織財富”。
制定項目計畫的過程被稱為項目策劃。在項目策劃時，要儘量讓員工估計自己的工期，使團隊成員積極參與到項目中來，而且由於技術發展如此迅速，往往只有具體模組開發人員對那部分工作最了解；但是項目經理也不是完全消極的，他應該積累項目管理數據，推動開發過程能力成熟度的提高，以便可以協同開發人員進行越來越準確的項目估計。計畫常以文本文檔和圖形文檔結合的形式出現，文本主要記錄項目的約束和限制、風險、資源、接口約定等方面的內容，對於進度和資源分解、職責分解、目標分解最好通過項目管理軟體工具（如普遍套用的microsoft project）來進行規劃和管理，不要分散在文檔的若干個地方，那樣非常不利於同步修改。項目計畫需要設計成“可檢查”的檔案，這要求任務的劃分要細到具體產品，如果存在有形產品的輸出，要羅列出來。比如測試這一任務，不要簡單分解為測試準備、測試執行，而是分解為測試環境搭建、測試方案編制、測試執行、測試報告編制為好。
使用microsoft project編制的檔案可以稱為計畫進度表，可以用來規劃項目時間進度，輔助項目跟蹤。計畫進度表的制定步驟是：工作分解和定義（wbs）、任務排序、活動歷史估算、編制。
估算是計畫活動的基礎之一，有工作規模估算、工作量估算、成本估算等。估算要求有歷史數據，要求在項目過程中通過不斷的維護項目資料庫積累歷史數據。這些數據既可以分析和總結本項目，又可作為後續項目的歷史數據。
在計畫實施過程中需要注意的一點是，不能把計畫“固定化”。“計畫趕不上變化”，但“要跟上變化”。實際運作中，要對計畫進行周期性維護。開發計畫會受到很多影響，比如相關計畫（質量保證計畫、採購計畫、測試計畫、驗收計畫等）的影響，實際進度變動的影響、資源變動的影響、項目目標變動的影響、還有隨著需求的逐漸明確引起的項目計畫細化，如果在這些變化發生後，沒有及時維護開發計畫，開發計畫於實際的偏離會越來越大，最後變得沒有價值，人們就會不再閱讀它。所以實際工作中要有具體的責任人和一套指導書來對計畫實施指導和維護。計畫變更時，要保留舊的版本，在總結階段需要閱讀舊版本的信息以對項目過程的變更歷史作評價。總之：變化的計畫才有生命力！
實際工作執行項目計畫常常遇到各種困難。有的企業文化中有種觀念認為計畫是一種約束，反正大家努力往前趕就對了，沒必要自己捆住手腳；另外一種情況是大家沒有按照計畫工作的習慣，計畫雖然做好了，做的時候還是我行我素，管理人員也沒有維護計畫的習慣，項目開始沒多久，計畫就被完全撂了一邊；還有一種情況是資源不能保障，比如，設備不能到位，人員也頻繁被抽調從事計畫外活動，每天改計畫都來不及，只好放棄計畫，這種情況常見於一些規模較小的還在“求生存階段”的公司。
事實上，不僅是在項目計畫這一問題上，在其它引入制度化的場合都遇到了類似的困惑。據說，美國家庭常會對做家庭清掃這樣的事情列出一張“責任矩陣表”，按表的內容順序進行掃除活動，完成一項作一個記號，這其實就是一種簡單的項目管理，他們在如此自然的運用，對於中國人是不可想像的。但是制度化是商業社會的基石，遲早要滲透到社會生活的每一個縫隙。具體到項目管理中的計畫活動，除了儘量把計畫做的更具可行性以外，努力在組織內傳播和培育制度化的企業文化將是項目經理們的一項長期責任，除此，別無選擇。