2.3
啟動專案-立項
經過了以上的專案啟動準備，再明確了以下的5w+1h問題答案之後，就可以進入到立項階段。
為什麼做這個專案（why）
專案目標是什麼（what）
專案價值是什麼（what）
我們能做到什麼（what）
干係人是誰（who）
怎麼做（how）
立項屬於專案啟動的一部分，立項只是乙個點，標誌著專案相關各方（所有干係人）在以上的5w+1h問題中達成一致。
專案後期的進展順利程度就取決於立項中各方所達成一致的程度，也就是說，後期出現的問題，多數是在專案啟動階段，就5w+1h某一項未達成一致的問題！
專案案例2.4：
某重點考試專案進入到專案驗收階段，專案總體狀態處於完成了整體的專案計畫，但是專案未能通過業務方的驗收；對於業務提出的眾多小的功能點的優化，專案團隊處於被動接受狀態；故障層出不窮，乙個故障的修改又會產生新的其他問題；每天全體成員進行加班，團隊士氣受到影響。
前期產品經理在立項的時候，在原型未完成且部分實施方案沒有確定的情況下，專案組進行的快速的立項；產品經理在專案進行到開發中期的時候，完成了產品原型，但是缺乏溝通，原型的細節和邏輯部分，與**實現出現不一致的情況；導致後期的產品功能驗收時已經無法進行驗收。作為該項目的專案經理你應該怎麼辦？
專案經理：
首先對專案的週期進行調整和變更，對延遲上線向客戶進行說明，取得客戶的理解
控制（甚至停止）對外的現有版本的需求，進行任何新的功能性修改承諾
盡快協調產品經理和團隊進行需求和實際**的一致性審核，確保原型和**一致
問題點：
立項時期，
業務和專案團隊的目標未達成一致（業務是要功能更好的產品；專案團隊是做成功這個專案）；
需求未達成一致（業務和產品經理是逐步完善的需求；專案團隊是一步到位的需求）；
專案怎麼做也未達成一致（產品在開發過程中失去對專案的過程性監控；專案團隊因為原型的延遲，也就沒有辦法按照原型設計實施）
可以看出對於專案啟動階段的5w+1h的一致性，是實現專案成功的必要保障。因此在立項的點上，就需要強化對於5w+1h的確認。
以下是我設定的立項專案要點
立項專案分項
說明專案（概要）目標
簡略說明專案概要，要做什麼，達到什麼目的
專案功能需求列表
一般業務或者產品經理提供的功能性需求列表，有些專案也有專案經理提供的開發功能列表
專案風險分析和應對方案
專案可能產生的時間、成本、範圍、質量、安全的風險和應對方案，一對一
專案成本
投入成本，包括專案應急儲備
專案里程碑
專案交付成果物的各個時間點
專案驗收標準
與業務驗收人員達成的一致的，可量化的，可操作的，明確的驗收標準
干係人列表
專案相關所有干係人
資源日曆
人員使用的時間和比例
專案其他
業務和技術方案，原型，匯入檔案模板，測試檔案等等
專案組管理實踐
以下是專案組管理實踐的依循規則，做個記錄 1.以身作則，努力做事 2.樹立目標，注重承諾 3.專案任務並行設計，簡短會議時間，減少溝通成本 4.使用雙周計畫，建立目標 5.使用敏捷流程方法，建立目標進度監督 6.使用測試用例，檢查產出內容，保證產出質量 7.強調團隊學習，強調團隊監督 對專案組長要求...
專案管理實踐（一）
1.總結 2.傳遞 3.驗證理論 4.求得理解 專案管理基礎知識，pmi pmp，pmi acp，敏捷，軟考 專案管理小白，初級專案經理，資深程式猿，資深產品經理，資深運營 後三者旨在讓你理解專案經理的思維 如果你是小白，有志成為專案經理 如果你是個新程序式猿，覺得碼 不適合你，與人打交道很適合你 ...
優秀實踐之專案管理
軟體專案管理方法與專案需求流程緊密相關。專案經理應當根據需要實現的需求，規劃專案時間表 資源以及做出承諾。另一種策略是將開發周期納入 時間盒 即團隊估算出他們在固定迭代時間內能夠完成的工作範圍。敏捷開發專案採用的就是這種方式。範圍可以在計畫時間範圍內協商。這樣一來，範圍蔓延就成了 範圍選擇 產品負責...