專案規劃是預測未來，確定要達到的目標，估計會碰到的問題，並提出實現目標、解決問題的有效方案、方針、措施和手段的過程。
方法/步驟
認識到信心來自規劃的過程，而不是計劃本身。
建立專案計劃會迫使您早在編寫程式碼之前就考慮如何構建您的系統——減少專案的風險，因為您已經考慮了各種策略和方法並且已經選擇了最有意義的一項。您的目的不應該只是不花氣力產生一個計劃；它應該是一個實際可行的計劃，您可以根據它來成功管理您的專案。
軟體過程推動計劃的開發。
每個軟體過程都有一個不同的集合，它包括組織團隊的活動方法以及規劃專案常用的技術。由於這個原因，基於 Rational Unified Process （RUP）的專案規劃不同於OOSP專案的規劃，而OOSP專案的規劃也不同於eXtreme Programming （XP） 專案的規劃。不同的過程有不同的計劃。
從粗粒度的計劃開始。
在專案將要開始時，應該制定一個粗粒度的、確定專案高階活動和預期里程碑的計劃。粗粒度的計劃將組織成迭代——根據專案的大小和性質，每次迭代通常在三週到八週之間發生（四周到六週為更佳）。其中一些迭代將集中在專案初期，而很多迭代將集中在整個應用的功能部分開發，還有一些迭代集中在將您的系統轉變成產品。
實施者應該是計劃人員。
建立專案計劃的最佳人員是負責實施該計劃的人員。當規劃由一個人建立而由另一個人實施時，如果專案不能按時完成或超出預算，他們不太會相信計劃，而很有可能會責備它。也就是說，參與專案的每個人都應該投入到專案計劃的開發和進展中。
不要忘記“不該忘記的事。
計劃不僅要反映需求設計、建模、程式設計和測試的“真實”工作，而且還應該反映輔助活動（然而仍是重要的），它包括：休假和法定假日、培訓和教育、專案管理活動（如規劃和人員管理）、開銷（如系統當機時間、會議和回覆電子郵件）、體系結構定義、測試之後的系統返工、系統交付、與重用相關的活動（如普遍化 ）。
將任何設想和約束編入文件。
規劃時您總要作一些假設，如能夠及時獲得應用程式伺服器的新發行版，或可以得到熟悉您正在應用的技術和技巧的開發人員。同時，您將在一些約束下工作，如影響計劃的強制截止期限或資源限制。將這些假設和約束編入文件，這樣，當您實施專案的任何時候更新計劃時，都可以記起您先前做出的一些“不尋常”決定。
認識到不同的資源意味著不同的計劃。
十名有經驗的開發人員組成的團隊創造出的成效要遠遠多於十名初學者組成的團隊所創造的成效。要想更加實際的話，您的計劃必須反映專案可使用的資源的真實情況。
建立現實的計劃。
專案組必須相信其專案的目的、估價和時間表。要做到這點，您必須真實地規劃，避免規劃超出您能理解的範圍。僅當您打算研究未知事項時，才能容忍無知。
只規劃有價值的事。
然而，根據專案的性質，不是所有這些技術都將適合於您的獨特情況。要將這些最佳實踐簡單地看作是您放置在“專案管理工具箱”中的工具，您可以根據需要適當使用這些工具。
適當使用專案管理工具。
一些專案管理工具，如 Microsoft Project，提供了重要功能， 如Gantt圖表（活動時間表）的開發、規劃與實際結果的比較、PERT 圖表（網路圖表）的開發、任務的定義、任務之間相關性的定義、對任務的資源分配和資源平衡。所有這些事情似乎象是一個好主意，並且它們通常是好主意——但它們還需要許多精力來建立和維護，而且很少為專案組提供實際價值。的確，它讓一些專案管理人員感到富有成效。的確，高階管理喜歡看見您有一個計劃。但是，沒有一行程式碼是由所有這個活動產生的。規劃是有價值的活動；但投入大量的時間來建立規劃圖表通常不是有價值的活動。