軟體產品策劃書 篇1
一、產品的定位
縱觀世界所有的成功軟體，其最初都是有了一個好的定位才能取得注目的成績。如windows、office、qq多的很。很多成功產品的負責人在回憶產品前期的時候常會提到：我們當時做這個是為了什麼什麼，提供什麼什麼。。之類的話。是呀，他要是不為了什麼什麼提供什麼什麼，我想是很難成功的，正是因為其初期的成功定位，才有了先天的優良。當然並不是定位做好了就代表後期就能成功，這是第一步!
我們很多企業特別是小企業，一個產品的初期更多考慮的是能否快速的開發出成品並取得效益，而不是去考慮將來能做多，有多少多少產值。其實一個企業能做多確實不敢保證，一個產品能賺多少錢也不好說。但是如果20xx年去開發一個windows95類似的產品，估計這個企業很難成為微軟。所以必須給產品一個方向，一個使命，讓家明白做出來的產品是為了什麼?比如，我們的期望就是做到有微軟的1/10000就夠了，做一個windows95也許能達到此目標。因為有了一個方向、一個使命，明白了要做什麼!
另外，產品的定位客群面很重要，不同的客群取得的結果是不同的。如面向製造業的軟體產品可能單價高但門檻也高，小公司要涉及不容易，而且競爭過於激烈市場份額不容易擴。而如果做專業行業軟體產品，可能就需要專業領域的業務，這是需要時間來沉澱的，對於很多小公司來說投入太，但對於有這方面經驗的人或者群體容易進入並快速發展，有很多人就是從某公司跳出來組建一個公司，因為有了基礎，很快就能站住腳。這就是客群帶來的影響，微軟的作業系統客群主要是普通pc電腦，而pc電腦的`數量如今已是非常巨，所以這個客群對微軟來說是空前的，也就沒有理由不取得成就了。另外舉一個例子：當初使用彙編和c語言作軟體開發的時候，也許當時的程式設計師非常少，而且這些開發工具的套用都比較高端，很少會涉及到普通民眾，所以那時的程式設計師少，軟體也少。如今，集成開發環境已經越來越先進，軟體的需求量也巨，如此一來程式設計師就多出不少，軟體公司也遍地都是。所以說定位軟體產品的客群將會是個非常重要的課題。
產品的定位對企業來說除了客群外，對產品規模的定位非常重要，比如一個只用於某個製造企業展示產品的網頁，這個產品可能只需要2個開發人員用1個月的時間就能完成並交付。但是對於windowsxp作業系統，可能是要20000相關人員才有可能達成最終的產品並交付到各個pc電腦上。又如企業管理軟體，有針對型製造業的sap，也有針對小企業的速達軟體，他們的客群都是製造企業，但是由於軟體規模不同，所以對產品的研發也不同，開發一個速達軟體肯定比sap要簡單的多，相應的成本也要低的多。產品規模對於不同的群體及個人或者是企業集體參於到某個行業產品的競爭提供了不同的選擇。
總結一下產品定位，定位最主要的是確定客群，另外便是在這個客群群體裡找到目標客戶，定位自己的產品規模，接著就向目標為之努力。
二、產品體系的規劃
有了產品定位，接著要考慮產品開發。
在產品在整個生命周期過程中會產生量的工作。比如：與需求方的交流，前期人員投入，後期的計畫，市場部門的.參與，包括辦公場地，人員規模等等等等。如何規劃好這個過程對於企業來說是深遠的。
產品的運營是跟企業規模不同而不同的，創業初期的企業可能考慮的是如何將產品快速開發並交付用戶，而中型軟體公司可能會要考慮多部門、多公司、跨區域的聯合工作。但無論是小公司還是公司都有一個共同點，即貫穿整個過程的就是產品，如何將產品運營好守鍵。那如何才能讓產品有序運營並為企業創造更的價值呢?必須建立產品體系。
建立產品體系是個過程，小企業沒有基礎所有東西都要建立起來，而公司可以通過資源分配以加快這一過程。但道理都是一樣：都要去一步步的做。對於小企業來說，建立產品體系可能是個痛苦的過程，沒有專門的市場部門，沒有足夠的資金來招收員工，更沒有運行銷售團隊。所以小企業一切都很難，但一切又都要去做。此時的老闆會是非常關鍵的人物，其要在所有的事情上投入相當的精力，為企業所有的人以指導。有難處事情還是要做呀，所以老闆要組織市場人員開始收集產品需求，組織技術人員著手設計產品，組織銷售工作，還需要有組織來管理公司的財務。這些都是體系，看看，如果這個產品能夠順利投入市場，我想市場與開發及銷售至少這四個重要部門應該有點樣子了，如果產品銷售較好，人員就能訊速擴，接下來人力資源部門、技術支持部門、客戶服務部門，行政管理部門都會相應的建立。部門的建立一定程度上是體現了體系的子系，但並不代表了體系就是部門的建立。
很多企業產品銷售較好時企業一直在擴張，積累了量的財富，同時也有了許多問題。如市場部門是否與技術部門能夠合理的溝通，及時的饋市場信息呢?人力資源部門是否能為各個部門提供優質的人才呢?客服部門是否能夠讓用戶享受到良好的服務呢?等等等，這就是具有一定規模企業應該注意的問題，如何建立體系的運轉系統?在很多情況下，企業達到一定規模後需要擴充自己的產品線，投入新的產品以增長企業業績。而正是這種情況下，往往能發現企業存在的量問題，因為在公司創業初期時，家都是為了一個產品來開展工作的，家都有了一套固定的工作方式，可以流暢的溝通。但是新產品就需要相關部門的人員接受新的工作交流方式。比如市場人員之前可能就是保持與一些客戶的聯繫，繼續擴展現有產品的市場深度與廣度，但是新產品可能就需要重新尋找用戶或者是讓老用戶接受新的產品，這是個很難的工作，對於企業來說不可能會像企業初期一樣找一些不相干的人來做，因為有了專門的市場部門，這個部門就必須為企業提供新產品的市場調研及開發工作。同時問題就來了，市場人員人手不夠，需要招收新成員，同時需要技術部門組織需求人員參於工作，人力資源部門及財務部門都需要參與進來，如果一個環節沒有處理好，可能就會引發系列問題，比如，技術部門無法抽出需求設計人員參與到這個工作中來，人力資源部門也無法招收到足夠好的人，財務部門也無法快速的提供足夠的資金供應。很多公司會採用建立專項組的形式來做這個工作，這是一種解決方法，但不見的是個好方法。專項組要占用專門的人力物力，另外在企業內部會形成一個不好的風氣，就是這個專項組比較重要，家都會帶有想法。
看來企業的產品體系的建立關係到的是整個公司的運作，我們可以發現目前一些業務增長穩定的企業都是很好的解決了體系運轉問題。創業型企業更多的是要考慮到未來的發展，在產品初期加以足夠的規劃，為將來的高增長鋪路。具有一定規模的企業更多的是平衡企業資源，形成長效機制以合理投入新產品線的投入。
結束語
此文寫完後自己也看了一篇，感覺有些亂，但也不願去修改了。如果我開始就把思路整理清楚，並充分考慮到了文章的字數及內容規模就可以比較從容的寫，但結果卻是我沒有想好內容的核心就開始寫，結果肯定不好。
軟體產品策劃也是如此道理，先有了衝動，馬上要清醒一下，想清楚要幹啥!然後就去動手，也許產品就能越做越。
軟體產品策劃書 篇2
一、產品的定位
縱觀世界所有的成功軟體，其最初都是有了一個好的定位才能取得注目的成績。如windows、office、qq多的很。很多成功產品的負責人在回憶產品前期的時候常會提到：我們當時做這個是為了什麼什麼，提供什麼什麼。。之類的話。是呀，他要是不為了什麼什麼提供什麼什麼，我想是很難成功的，正是因為其初期的成功定位，才有了先天的優良。當然並不是定位做好了就代表後期就能成功，這是第一步!
我們很多企業特別是小企業，一個產品的初期更多考慮的是能否快速的開發出成品並取得效益，而不是去考慮將來能做多大，有多少多少產值。其實一個企業能做多大確實不敢保證，一個產品能賺多少錢也不好說。但是如果20xx年去開發一個windows95類似的產品，估計這個企業很難成為微軟。所以必須給產品一個方向，一個使命，讓大家明白做出來的產品是為了什麼?比如，我們的期望就是做到有微軟的1/10000就夠了，做一個windows95也許能達到此目標。因為有了一個方向、一個使命，明白了要做什麼!
另外，產品的定位客群面很重要，不同的客群取得的結果是不同的。如面向製造業的軟體產品可能單價高但門檻也高，小公司要涉及不容易，而且競爭過於激烈市場份額不容易擴大。而如果做專業行業軟體產品，可能就需要專業領域的業務，這是需要時間來沉澱的，對於很多小公司來說投入太大，但對於有這方面經驗的人或者群體容易進入並快速發展，有很多人就是從某大公司跳出來組建一個公司，因為有了基礎，很快就能站住腳。這就是客群帶來的影響，微軟的作業系統客群主要是普通pc電腦，而pc電腦的數量如今已是非常巨大，所以這個客群對微軟來說是空前的，也就沒有理由不取得成就了。另外舉一個例子：當初使用彙編和c語言作軟體開發的時候，也許當時的程式設計師非常少，而且這些開發工具的套用都比較高端，很少會涉及到普通民眾，所以那時的程式設計師少，軟體也少。如今，集成開發環境已經越來越先進，軟體的需求量也巨大，如此一來程式設計師就多出不少，軟體公司也遍地都是。所以說定位軟體產品的客群將會是個非常重要的課題。
產品的定位對企業來說除了客群外，對產品規模的定位非常重要，比如一個只用於某個製造企業展示產品的網頁，這個產品可能只需要2個開發人員用1個月的'時間就能完成並交付。但是對於windowsxp作業系統，可能是要20000相關人員才有可能達成最終的產品並交付到各個pc電腦上。又如企業管理軟體，有針對大型製造業的sap，也有針對小企業的速達軟體，他們的客群都是製造企業，但是由於軟體規模不同，所以對產品的研發也不同，開發一個速達軟體肯定比sap要簡單的多，相應的成本也要低的多。產品規模對於不同的群體及個人或者是企業集體參於到某個行業產品的競爭提供了不同的選擇。
總結一下產品定位，定位最主要的是確定客群，另外便是在這個客群群體裡找到目標客戶，定位自己的產品規模，接著就向目標為之努力。
二、產品體系的規劃
有了產品定位，接著要考慮產品開發。
在產品在整個生命周期過程中會產生大量的工作。比如：與需求方的交流，前期人員投入，後期的計畫，市場部門的參與，包括辦公場地，人員規模等等等等。如何規劃好這個過程對於企業來說是深遠的。
產品的運營是跟企業規模不同而不同的，創業初期的企業可能考慮的是如何將產品快速開發並交付用戶，而大中型軟體公司可能會要考慮多部門、多公司、跨區域的聯合工作。但無論是小公司還是大公司都有一個共同點，即貫穿整個過程的就是產品，如何將產品運營好是關鍵。那如何才能讓產品有序運營並為企業創造更大的價值呢?必須建立產品體系。
建立產品體系是個過程，小企業沒有基礎所有東西都要建立起來，而大公司可以通過資源分配以加快這一過程。但道理都是一樣：都要去一步步的做。對於小企業來說，建立產品體系可能是個痛苦的過程，沒有專門的市場部門，沒有足夠的資金來招收員工，更沒有運行銷售團隊。所以小企業一切都很難，但一切又都要去做。此時的老闆會是非常關鍵的人物，其要在所有的事情上投入相當的精力，為企業所有的人以指導。有難處事情還是要做呀，所以老闆要組織市場人員開始收集產品需求，組織技術人員著手設計產品，組織銷售工作，還需要有組織來管理公司的財務。這些都是體系，看看，如果這個產品能夠順利投入市場，我想市場與開發及銷售至少這四個重要部門應該有點樣子了，如果產品銷售較好，人員就能訊速擴大，接下來人力資源部門、技術支持部門、客戶服務部門，行政管理部門都會相應的建立。部門的建立一定程度上是體現了體系的子系，但並不代表了體系就是部門的建立。
很多企業產品銷售較好時企業一直在擴張，積累了大量的財富，同時也有了許多問題。如市場部門是否與技術部門能夠合理的溝通，及時的反饋市場信息呢?人力資源部門是否能為各個部門提供優質的人才呢?客服部門是否能夠讓用戶享受到良好的服務呢?等等等，這就是具有一定規模企業應該注意的問題，如何建立體系的運轉系統?在很多情況下，企業達到一定規模後需要擴充自己的產品線，投入新的產品以增長企業業績。而正是這種情況下，往往能發現企業存在的大量問題，因為在公司創業初期時，大家都是為了一個產品來開展工作的，大家都有了一套固定的工作方式，可以流暢的溝通。但是新產品就需要相關部門的人員接受新的工作交流方式。比如市場人員之前可能就是保持與一些客戶的聯繫，繼續擴展現有產品的市場深度與廣度，但是新產品可能就需要重新尋找用戶或者是讓老用戶接受新的產品，這是個很難的工作，對於企業來說不大可能會像企業初期一樣找一些不相干的人來做，因為有了專門的市場部門，這個部門就必須為企業提供新產品的市場調研及開發工作。同時問題就來了，市場人員人手不夠，需要招收新成員，同時需要技術部門組織需求人員參於工作，人力資源部門及財務部門都需要參與進來，如果一個環節沒有處理好，可能就會引發系列問題，比如，技術部門無法抽出需求設計人員參與到這個工作中來，人力資源部門也無法招收到足夠好的人，財務部門也無法快速的提供足夠的資金供應。很多公司會採用建立專項組的形式來做這個工作，這是一種解決方法，但不見的是個好方法。專項組要占用專門的人力物力，另外在企業內部會形成一個不好的風氣，就是這個專項組比較重要，大家都會帶有想法。
看來企業的產品體系的建立關係到的是整個公司的運作，我們可以發現目前一些業務增長穩定的企業都是很好的解決了體系運轉問題。創業型企業更多的是要考慮到未來的發展，在產品初期加以足夠的規劃，為將來的高增長鋪路。具有一定規模的企業更多的是平衡企業資源，形成長效機制以合理投入新產品線的投入。
結束語
此文寫完後自己也看了一篇，感覺有些亂，但也不願去修改了。如果我開始就把思路整理清楚，並充分考慮到了文章的字數及內容規模就可以比較從容的寫，但結果卻是我沒有想好內容的核心就開始寫，結果肯定不好。
軟體產品策劃也是如此道理，先有了衝動，馬上要清醒一下，想清楚要幹啥!然後就去動手，也許產品就能越做越大。
軟體產品策劃書 篇3
一、項目計畫的要素
根據PMBOK20xx，項目計畫可以包含如下要素：
1、項目範圍說明
項目範圍說明闡述進行這個項目的原因或意義，形成項目的基本框架，使項目所有者或項目管理者能夠系統地、邏輯地分析項目關鍵問題及項目形成中的相互作用要素，使項目干係人在項目開始實施前或項目相關文檔編寫以前，能夠就項目的基本內容和結構達成一致；項目範圍說明應當形成項目成果核對清單，作為項目評估的依據，在項目終止以後或項目最終報告完成以前進行評估，以此作為評價項目成敗的依據；範圍說明還可以作為項目整個生命周期監控和考核項目實施情況的基礎，和項目其他相關計畫的基礎。
2、項目進度計畫
進度計畫是說明項目中各項工作的開展順序、開始時間、完成時間及相互依賴銜接關係的計畫。通過進度計畫的編制，使項目實施形成一個有機的整體。進度計畫是進度控制和管理的依據，可以分為項目進度控制計畫和項目狀態報告計畫。
在進度控制計畫中，要確定應該監督哪些工作、何時進行監督、監督負責人是誰，用什麼樣的方法收集和處理項目進度信息，怎樣按時檢查工作進展和採取什麼調整措施，並把這些控制工作所需的時間和人員、技術、物資資源等列入項目總計畫中。
3、項目質量計畫
質量計畫針對具體待定的項目，安排質量監控人員及相關資源、規定使用那些制度、規範、程式、標準。項目質量計畫應當包括與保證與控制項目質量有關的所有活動。質量計畫的目的是確保項目的質量目標都能達到。根據ISO9001要求和PMBOK20xx，為實現質量目標，組織應遵循以顧客為中心、領導作用、全員參與、過程方法、管理的系統方法、持續改進、基於事實的決策方法、互利的供方關係等8項質量管理原則。
4、項目資源計畫
有了項目範圍計畫和進度計畫後，資源計畫就是決定在項目中的每一項工作中用什麼樣的資源（人、材料、設備、信息、資金等等），在各個階段使用多少資源。項目費用計畫包括資源計畫、費用估算、費用預算。
5、項目溝通計畫
溝通計畫就是制定項目過程中項目干係人之間信息交流的內容、人員範圍、溝通方式、溝通時間或頻率等溝通要求的約定。
6、風險對策計畫
風險對策計畫是為了降低項目風險的損害而分析風險、制定風險應對策略方案的過程，包括識別風險、量化風險、編制風險應對策略方案等過程。
7、項目採購計畫
項目採購計畫過程就是識別哪些項目需求可應通過從本企業外部採購產品或設備來得到滿足。如果是軟體開發工作的採購，也就是外包，應當同時制定對外包的進度監控和質量控制的計畫。
8、變更控制、配置管理計畫
由於項目計畫無法保證一開始就預測得非常準確，在項目進行過程中也不能保證準確有力的控制，導致項目計畫與項目實際情況不符的情況經常發生，所以必須有效處理項目的變更。變更控制計畫主要是規定變更的步驟、程式，配置管理計畫就是確定項目的配置項和基線，控制配置項的變更，維護基線的完整性，向項目干係人提供配置項的準確狀態和當前配置數據。
二、項目計畫編制過程
由於軟體開發的手工性、個體性特徵，軟體開發項目計畫不可能是一個靜態的計畫，一次在項目啟動時，可以先制定一個顆粒度相對比較粗的項目計畫，先確定項目高層活動和預期里程碑。粗顆粒度的項目計畫需要不斷地更新疊代，根據項目的大小和性質以及項目的進展情況進行疊代和調整。疊代和調整的周期也是根據項目的情況進行制訂的，一般短到一周，長到2個月左右。經過不斷的計畫制訂、調整、修訂等工作，項目計畫從最初的粗粒度，變得非常詳細。這樣的計畫將一直延續到項目結束，延續到項目的成果出現。
制定計畫的過程就是一個對項目逐漸了解掌握的過程，通過認真地制定計畫，項目經理可以知道哪些要素是明確的，哪些要素是要逐漸明確的，通過漸近明細不斷完善項目計畫。階段計畫中包含的匯報和下一階段工作安排是掌握項目進度的依據，從階段計畫對照總體計畫，才能一目了然地看出工作的進展情況。制定計畫的過程，也是在進度、資源、範圍之間尋求一種平衡的過程。制定計畫的精髓不在於寫出一份好看的文檔，而在於運用您的智慧去應對各種問題和面臨風險並儘可能做出前瞻性的思考。一旦計畫被負責任地完成，他就可以給自己一個和管理層或客戶交流與協商的基礎，幫助你在項目過程中防範各種問題的出現，幫助你保證項目按時完成。
企業確定要開始某個項目時一般會下達一個立項的檔案，暫且叫“項目立項檔案”，主要內容是遵照的契約或相關協定，項目的大致範圍、項目結束的截止時間和一些關鍵時間，指定項目經理和部分項目成員等等。
接下來的項目計畫編寫一般要按照以下過程：
1、成立項目團隊：相關部門收到經過審批後的“項目立項檔案”和相關資料，則正式在“項目立項檔案”中指定的項目經理組織項目團隊，成員可以隨著項目的進展可以在不同時間加入項目團隊，也可以隨著分配的工作完成而退出項目團隊。但最好都能在項目啟動時參加項目啟動會議，了解總體目標、計畫，特別是自己的目標職責，加入時間等等。
2、項目開發準備：項目經理組織前期加入的項目團隊成員準備項目工作所需要的規範、工具、環境。如開發工具、原始碼管理工具、配置環境、資料庫環境等。前期加入的項目團隊成員主要由計畫經理，系統分析員等組成，但快要制定好的項目計畫一定要儘可能經過在所有項目團隊成員和項目干係人中間的充分溝通。如果項目中存在一些關鍵的（指將影響項目成敗）技術風險，則在這一階段項目經理應組織人員進行預研。預研的結果應留下下書面結論以備評審。
說明：項目計畫書必須在相應階段對項目目標、階段目標和各項任務進行精確的定義，就是要在相應階段進一步進行項目目標的細化工作；特別是在概要設計完成，詳細設計或編碼實現開始之前應該對下一階段的目標任務進行細化。應當充分調查並掌握影響項目計畫的一切內部和外部影響因素；應當儘可能充分地分析項目工作分解結構，通過分析項目工作分解結構不僅獲得項目的靜態結構，而且通過邏輯分析，獲得項目各工作任務之間動態的工作流程；應當將項目目標、任務進行分解，制定詳細的實施方案。
3、項目信息收集：項目經理組織項目團隊成員通過分析接收的項目相關文檔、進一步與用戶溝通等途徑，在規定的時間內儘可能全面收集項目信息。項目信息收集要講究充分的、有效率的溝通，並要達成共識。有些成員認為，電子郵件發來的文檔（計畫、需求、周計畫等）是在溝通不夠充分的情況下完成的，成員看過後有不了解或與自己的能力或意願不符的情況，但通過電子郵件等方式溝通的效率不高，這也許是個習慣的問題，也許和某個具體問題本身是否容易通過電子郵件溝通清楚有關。因此重要的內容需要開會進行Q&A討論，確保所有重要問題都得到理解，最終達成共識。討論會上達成共識的應當記錄成文字落實在具體的文檔中。
4、編寫《軟體項目計畫書》
項目經理負責組織編寫《軟體項目計畫書》。《軟體項目計畫書》是項目策劃活動核心輸出文檔，它包括計畫書主體和以附屬檔案形式存在的其他相關計畫，如配置管理計畫等。《軟體項目計畫書》的編制參考《GB8567－88計算機軟體產品開發檔案編制指南》中項目開發計畫的要求。各企業在建立ISO9001質量管理體系或CMM過程中也會建立相應的《軟體開發項目計畫書規範》。
編制項目計畫的過程應當分為以下幾個步驟：
a、確定項目的應交付成果。這裡的項目的應交付成果不僅是指項目的最終產品，也包括項目的中間產品。例如通常情況下軟體開發項目的項目產品可以是：需求規格說明書、概要設計說明書、詳細設計說明書、資料庫設計說明書、項目階段計畫、項目階段報告、程式維護說明書、測試計畫、測試報告、程式代碼與程式檔案、程式安裝檔案、用戶手冊、驗收報告、項目總結報告等等；
b、任務分解：從項目目標開始，從上到下，層層分解，確定實現項目目標必須要做的各項工作，並畫出完整的工作分解結構圖。軟體開發項目剛開始可能只能從階段的角度劃分，如需求分析工作、架構設計工作、編碼工作、測試工作等等，當然規模較大時也可把需求、設計拆分成不同的任務。不過特別是在概要設計完成時可以對下一階段的目標任務進行橫向的細化。
c、在資源獨立的假設前提下確定各個任務之間的相互依賴關係，以確定各個任務開始和結束時間的先後順序；獲得項目各工作任務之間動態的工作流程。
d、確定每個任務所需的時間，即根據經驗或套用相關方法給任務需要耗費的時間；確定每個任務所需的人力資源要求，如需要什麼技術、技能、知識、經驗、熟練程度等等。
e、確定項目團隊成員可以支配的時間，即每個項目成員具體花在項目中的確切時間；確定每個項目團隊成員的角色構成、職責、相互關係、溝通方式。
f、確定管理工作，管理工作是貫穿項目生命周期的，如項目管理、項目會議等、編寫階段報告。項目團隊成員之間的溝通時間、項目團隊成員和其他項目干係人之間的溝通時間也比較容易被忽視，而溝通時間也是比較不容易固定地量化和日程化。但這些工作在計畫中都應當充分地被考慮進去，再回師項目計畫更加合理，更有效地減少因為計畫的不合理而導致的項目進度延期。
g、根據以上結果編制項目總體進度計畫，總體進度計畫應當體現任務名稱、責任人、開始時間、結束時間、應提交的可檢查的工作成果。
h、考慮項目的費用預算、可能的風險分析及其對策、需要公司內部或客戶或其他方面協調或支持的事宜。
5、軟體項目計畫書評審、批准
項目計畫書評審、批准是為了使相關人員達成共識、減少不必要的錯誤，使項目計畫更合理更有效。
項目經理完成《軟體項目計畫書》後，首先組織項目團隊內部的項目團隊負責人、測試負責人、系統分析負責人、設計負責人、質量監督員等對項目計畫書進行評審，評審可採取電子或會議方式，並進行階段成果項目團隊內評閱記錄。應當要求所有相關人員在收到軟體項目計畫書後的一個約定時間內反饋對計畫書的意見。項目經理確保與所有人員就項目計畫書中所列內容達成一致。這種一致性是要求所有項目團隊成員對項目計畫的內容進行承諾，無法承諾或者說是無法達成一致的，要么修改項目計畫去適應某些項目團隊成員，要么是由某些項目團隊成員採取妥協措施，去適應項目計畫的要求。
項目經理將已經達成一致的軟體項目計畫書提交項目高層分管領導或其授權人員進行審批，審批完成時間不能超過預先約定的時間。對於意義重大的項目，由過程控制部門如質量管理部和項目分管領導同時對《軟體項目計畫書》進行審批。批准後的軟體項目計畫書作為項目活動開展的依據和本企業進行項目控制和檢查的依據，並在必要時根據項目進展情況實施計畫變更。項目質量監督員根據《軟體項目計畫書》和《軟體開發項目質量計畫書規範》編制軟體開發項目質量計畫。大型的項目應當編制單獨的《軟體開發項目質量計畫書》；規模較小的可以在《軟體項目計畫書》的某個章節說明“軟體開發項目質量計畫”，也可單獨編制類似“軟體開發項目質量控制表”的文檔。
配置管理員根據計畫書編制《項目配置管理計畫》。以項目工作計畫書中的階段成果為依據，根據配置管理計畫規範編制配置管理計畫，項目經理審批配置管理計畫，並對配置管理計畫的有效性負責。項目策劃工作完畢，軟體項目計畫書通過評審，一般情況下，對軟體開發項目來說，工作轉入需求分析階段。
三、項目計畫內容確定
項目計畫內容的確定一般要按照以下過程：
1、確定項目概貌
契約項目以契約和招投標檔案為依據，非契約項目以可行性研究報告或項目前期調研成果為依據，明確項目範圍和約束條件，並以同樣的依據，明確項目的交付成果。進一步明確項目的工作範圍和項目參與各方責任。
2、確定項目團隊
確定項目團隊的組織結構和與項目開發相關的職能機構，包括管理、開發、測試、QA、評審、驗收等。確定項目團隊人員及分工。與相關人員協商，確定項目團隊人員構成。如內部不能滿足人員需求，則提出人員支援申請。
3、明確項目團隊內、外的協作溝通
明確與用戶單位的溝通方法。明確最終用戶、直接用戶及其所在本企業/部門名稱和聯繫電話。客戶更多的參與是項目成功的重要推動力量，加強在開發過程中與用戶方項目經理或配合人員的主動溝通，將有助加強客戶等項目的參與程度。建議採用周報或月報的方式通告項目的進展情況和下一階段計畫，出現的需要客戶協調或了解的問題。
當項目團隊需要與外部單位協作開發時，應明確與協作單位的溝通方式。確定協作單位的名稱、負責人姓名、承擔的工作內容以及實施人的姓名、聯繫電話。
明確本企業內部協作開發的部門名稱、經理姓名、承擔的工作內容以及工作實施責任人的姓名、聯繫電話。明確項目團隊溝通活動。項目團隊成員規模在3人以上的項目應該組織項目團隊周例會，項目團隊採用統一的交流系統建立項目團隊的交流空間。
4、規劃開發環境和規範
說明系統開發的所採用的各種工具，開發環境，測試環境等。列出項目開發要遵守的開發技術規範和行業標準規範。對於本企業還沒有規範的開發技術，項目經理應組織人員制訂出在本項目中將遵守的規則。
5、編制工作進度計畫
根據本企業規定和項目實際情況，確定項目的工作流程。編制項目的工作計畫，此計畫為高層計畫，各階段的工作時間安排要包括完成階段文檔成果、文檔成果提交評審及進行修改的時間，各階段結束的標誌是階段成果發布。在計畫中要求明確以下內容：
a、工作任務劃分；
b、顯示項目各階段或疊代的時間分配情況的時間線或甘特圖；
c、確定主要里程碑、階段成果；
d、要求用文字對項目工作計畫做出解釋。最終用一張時間表格來完整說明整個工作計畫；對於疊代開發的項目，應編制出第一階段的階段計畫。階段內的任務分割以2-5天為合適，特殊任務的時間跨度在兩個星期內；在項目的進行過程中，項目經理編制雙周工作計畫，指導成員的具體工作。
6、編制項目的監控計畫。其中說明進度控制、質量控制、版本控制、預算控制等。
7、編制項目的風險計畫，分析項目過程中可能出現的風險以及相應的風險對策。對於大型項目，建議以附屬檔案方式編制，便於不斷更新。
8、制定輔助工作計畫。根據項目需要，編制如培訓計畫、招聘計畫等。
9、規劃開發支持工作，如供方管理計畫。
10、規劃項目驗收：制定項目的驗收計畫。此項工作可以視需要進行裁減。
11、規劃項目收尾與交接活動。制定項目的驗收、培訓和項目進入維護階段與技術支持部的交接工作。