立項管理的目的是確立符合企業利益的專案，將人力資源、資金、時間投入到有價值的專案上。反之，拒絕接受不能給企業帶來利益的立項建議，避免浪費人力資源、資金和時間。
立項管理是決策行為，其目標是「做正確的事情」（do right things）。立項之後的研發活動和管理活動的目標是「正確地做事情」（do things right）。只有「正確的決策」加上「正確地執行」才可能產生良好的產品。
通俗地講，立項管理關注的是：是否立項？要花費多少錢？需要多少人？多少時間？誰負責？
在規範化水平比較低的企業裡，通常由少數領導做立項決策。獨斷式的決策存在如下隱患：
（1）企業領導個人的智慧型畢竟有限，乙個人做決策難免存在較多的主觀臆斷，決策風險比較高，而且領導承擔的責任太大。it企業的群眾大都是高智商的人才，把群眾撇在一邊的做法顯然不合理。
（2）即使領導做出了英明的決策，但是群眾卻難以學習並繼承這種英明的決策過程，浪費了寶貴的知識財富。企業的繁榮昌盛和可持續發展不能依賴於個別領導人的智慧型和鞠躬盡瘁。
對於小企業而言，領導獨斷決策可能不會有太大的問題。但是對於大中型企業而言，領導獨斷決策是很危險的，應當盡早引入「群體決策機制」的立項管理方法：不僅讓群眾貢獻智慧型，而且讓群眾分擔責任；使成功的經驗不斷被企業復用，並昇華成為企業的制度。
立項管理的流程如圖3-1-0所示，主要活動有：立項申請、pmo受理、立項評審和專案啟動。該流程的主要工作成果和責任人見表3-1-0。
圖3-1-0 立項管理流程
表3-1-0 立項管理流程的主要工作成果和責任人
對於自主產品，產品經理負責撰寫《立項申請書》，並將相關附件（主要是產品建議書，產品調研分析報告）一起提交給pmo。
對於合同專案，銷售人員負責撰寫《立項申請書》，並將相關附件（主要是合同檔案）一起提交給pmo。
提示：由於《立項申請書》中涉及技術問題，產品經理或銷售人員可以和研發人員共同撰寫《立項申請書》，格式見表3-1-1。
表3-1-1 立項申請書
pmo受理人審閱《立項申請書》和相關附件，如果發現檔案內容不合流程要求或者質量不合格，則退還給申請人重新改進，直到檔案合格為止。之後，pmo受理人將檔案轉交給研發總監。提示：
這樣做的目的是提高立項評審的效率。
研發總監根據專案的特徵，選定「立項評審委員會」，確定評審時間。
pmo受理人發起立項評審通知，格式見表3-1-2。提示：如果專案涉及面很廣，難以一次性在立項評審會議上決定，那麼研發總監可以先召開「預評審」會議，之後再進行正式的立項評審。
表3-1-2 立項評審通知
（1）pmo通知相關人員在既定的時間參加立項評審會議。
（2）評審負責人主持評審會議，把控會議程序。
（3）立項申請人陳述《立項申請書》和相關檔案的主要內容。評審委員提出疑問，立項申請人解答。雙方應當對有爭議的內容提出處理意見、達成共識。
（4）每個評委發表（填寫）自己的評審意見。評審負責人彙總所有評審委員的評審意見，給出評審結論：「同意立項」或者「不同意立項」。
提示：評審期間應當商議「專案人力資源計畫」，避免立項之後人員不能到位的問題。
（5）記錄員（pmo受理人）填寫會議記錄。
（6）評審結束後，公司級的專案由公司領導（如研發總監）給出「終審結論和意見」，部門級專案由部門領導給出「終審結論和意見」。《立項評審報告》格式見3-1-3。
如果領導的終審結論與評審委員會的結論「一致」，則領導和評審委員會共同分擔立項評審工作的責任。如果領導的終審結論與評審委員會的結論「相反」，領導可以行使「一票否決權」，則領導應當對立項評審工作負全部責任。
不論是否同意立項，評審者都可以給出建議，幫助立項申請人改進《立項建議書》或者更好地進行專案籌備。
表3-1-3 立項評審報告
一、確定專案團隊
部門經理（或上級領導）根據專案特徵和立項評審報告，任命合適的專案經理，並確定該項目的主要成員。專案經理對立項之後的專案進度和質量負責。專案成員向專案經理匯報工作。
專案經理向部門經理匯報工作。
很多人樂觀地認為，專案經理被任命後，就可以安心地開發產品了。在現實之中很少有這麼順利的事情。
企業的資金和資源是有限的，可能難以完全按照《立項建議書》或者《合同》的要求給專案分配充足的資源。專案經理要學會爭取完成本專案的必要資源，否則會把自己和下屬累死，卻做不好專案，有苦勞卻無功勞。
二、確定專案總體計畫
專案經理和專案成員共同商議，制定初步的《專案總體計畫》，格式參見表3-1-4。部門經理（或上級領導）審批該《專案總體計畫》，如果有修改意見，請專案經理及時修正。提示：
在專案開發過程中，專案經理可以不斷細化和修正計畫。
表3-1-4 專案總體計畫
三、初始化軟體配置管理工具
（1）部門經理（或上級領導）或公司的專職配置管理員，建立該項目的配置庫，授予專案經理控制本專案的許可權。
（2）專案經理再分配許可權給其他專案成員。
四、使用mainsoft對應功能
（1）功能選單：mainsoft決策分析系統→專案決策管理。「組織管轄範圍」為「本組織或全系統」的使用者可以看到「本組織人員或全系統人員」的資料，普通使用者只能看到本人相關的資料。
（2）系統管理員先在後台設定「專案評審分類」。一般地，立項評審和結項評審都需要受理人，而專案內部的評審不需要受理人。
（3）申請人使用「mainsoft決策分析系統→專案決策管理→我建立的」功能。《立項申請書》等檔案可以作為申請單的附件。
（4）受理人使用「mainsoft決策分析系統→專案決策管理→我受理的」功能。
（5）評審人使用「mainsoft決策分析系統→專案決策管理→我評審的」功能。
（6）逐級審批人（可選）使用「mainsoft決策分析系統→專案決策管理→我審批的」功能。
（7）立項評審通過後，系統授權者（如pmo受理人或部門經理）使用「mainsoft決策分析系統→專案決策管理→立項與結項」功能，建立新專案，然後將立項評審關聯到該專案。功能示例見圖3-1-1。
提示：如果公司不需要使用「專案決策管理」功能來管理立項過程，那麼系統管理員可以在後台直接建立新專案。
（8）建立專案之後，專案經理登入「mainsoft專案管理系統」，進入該專案，執行初始化操作：
初始化專案成員表，分配角色許可權（否則專案成員無法訪問專案）。
根據《專案總體計畫》初始化任務進度表。
把立項過程的相關檔案上傳到本專案的文件庫中。
圖3-1-1 專案決策管理-立項功能示例
結項管理的主要目的是：
（1）對專案的資產進行清算，防止資產流失，並重複利用資產。
（2）對專案進行綜合評估，並考核專案成員的業績。
（3）專案成員總結經驗教訓，相互交流，共享知識財富。
結項管理的流程如圖3-2-0所示，主要活動有：結項申請、pmo受理、結項評審、遺留問題跟蹤和專案工作總結。該流程的主要工作成果和責任人見表3-2-0。
圖3-2-0 結項管理流程
表3-2-0 結項管理流程的主要工作成果和責任人
正常情況下，當專案開發工作結束時，專案經理撰寫《結項申請書》，遞交給pmo。《結項申請書》的格式見表3-2-1。
對於異常結束的專案，部門經理（或上級領導）應當明確指示專案經理，確定何時結束專案，向員工們解釋為什麼要異常終止專案。異常中止專案的結項流程與正常結項流程相同。
第3章專案管理過程 答案解析
專案管理過程 1 在專案每個階段結束時進行專案績效評審是很重要的，評審的目標是 a 根據專案的基準計畫來決定完成該專案需要多少資源 b 根據上一階段的績效調整下一階段的進度和成本基準 c 得到客戶對專案績效認同 d 決定專案是否可以進入下乙個階段 解析 退出檢驗與啟動判定。2 在專案的乙個階段末，開...
PMP學習筆記第3章單個專案的專案管理過程
第3章單個專案的專案管理過程 一.啟動過程組 啟動過程組 獲得授權，定義乙個新專案或現有專案的乙個新階段，正式開始該專案或階段。1.制定專案章程 輸入 專案工作說明書 商業論證 合同 事業環境因素 組織過程資產 輸出 專案章程 2.識別干係人 輸入 專案章程 採購檔案 事業環境因素 組織過程資產 輸...
專案管理過程組
管理知識 專案整合管理 啟動過程組 制定專案章程 規劃過程組執行過程組監控過程組 監控專案工作實施整體變更控制確認範圍控制範圍收尾過程組 專案收尾和結束 制定專案管理計畫指導與管理專案工 專案成本管理規劃成本管理估算成本制定預算 專案質量管理專案人力資源管理 規劃質量管理規劃人力資源管理 實施質量保...