一、基礎知識
PMBOK_相關知識 / 定義。
1. 項目vs日常運營：
項目： 目標-臨時一次性努力，提供獨特產品、服務或成果。具有臨時性、獨特性、漸進性的特點。
項目管理：把各種知識、技能、手段和技術應用於項目活動之中，以達到項目的要求。
日常運營：如每月給員工發工資。目標是維持運營，是重復發生事件，這是兩者最主要區別。
2. 項目目標需遵守的原則及特征：
SMART原則：SPECIFIC + MEASUABLE + AGREED + REALISTIC + TIME-BOUND。
項目具有特征：多目標性（多方面要求）、優先性（優先級別不同）、層次性。
因此，在特定領域的項目基本目標表現在三個方面：時間、成本、技術性能。
3. 五大專業知識：
這個書上還是講的比較好，截圖如下。
二、九大知識域
包括0.-整體管理、1-范圍管理、2-時間管理、3-成本管理、4-質量管理、5-人力資源管理、6-溝通管理、7-風險管理、8-采購管理。
其中最重要是范圍管理、時間管理、成本管理和質量管理。其它的人力資源、溝通、風險、采購是間接過程或輔助過程/知識域。
三、項目干系人
利害關系者，會對項目的目標或結果施加影響。
PM經理最重要的就是平衡各方利益關系，盡可能消除項目干系人對項目的不利影響。
——對項目干系人分類，並采用不同的應對策略。
四、項目組織機構類型
1. 職能型組織
適用項目：規模較小，偏重技術。
適用企業：中小型、產品品種單一、生產技術變化較慢、外部環境較穩定、經營管理相對簡單、部門較少、橫向協調難度小、對適應性要求較低的組織。
特點及優缺點：每個員工都有一個明確的上級，員工按照專業分組。項目的范圍會限制在職能部門內。
優點：便於技術、技能、經驗交流與分享，員工職業生涯、晉升路線明確，直線溝通-責任和權限清晰
2. 項目型組織
適用規模較大、技術復雜、對項目時間、成本、質量或其它方面有特別要求的項目。
個人理解，類似於項目外包或人力外包，優缺點非常類似，員工缺乏事業上的連續性和保障。
3. 矩陣型組織
兼有職能型和項目型特征的組織形式，分弱、平衡、強矩陣3種，項目經理權力不同。
適用規模較大，技術復雜的項目
| |理缺乏權威。 | 以保持平衡 |缺乏事業的連續保障。
-----------------------------------------------------------------------------------------------------------------------------------------
五、項目生命周期
任何一個項目的階段通常包括概念、開發、實施、結束四個階段。
將項目各個階段合在一起即為項目的生命周期，它定義了項目從開始到結束的階段（每個項目階段都以一個或一個以上的可交付物的完成和正式批准為標志）。
注意： 項目生命周期只是產品生命周期的一部分。但也有相同點3條。
1. 瀑布模型
傳統的瀑布模型：
加入迭代模型的瀑布模型：
某一項活動 / 階段的實施工作成果需要進行評審，若其可交付成果得到確認，則繼續進行下一活動，否則返回前一項，甚至更前項。
瀑布模型的優點（參考百度百科）：
1）為項目提供了按階段划分的檢查瀑布模型查點。
2）當前一階段完成后，只需要去關注后續階段。
3）可在迭代模型中應用瀑布模型。
4）它提供了一個模板，這個模板使得分析、設計、編碼、測試和支持的方法可以在該模板下有一個共同的指導。
瀑布模型的缺點：
1）各個階段的划分完全固定，階段之間產生大量的文檔，極大地增加了工作量。
2）由於開發模型是線性的，用戶只有等到整個過程的末期才能見到開發成果，從而增加了開發風險。
3）通過過多的強制完成日期和里程碑來跟蹤各個項目階段。
4）瀑布模型的突出缺點是不適應用戶需求的變化。
5）早期的錯誤可能要等到開發后期的測試階段才能發現，進而帶來嚴重的后果。
2. 螺旋模型
是一種演化的軟件過程模型，將原型實現的迭代特征與線性順序（瀑布）模型中的控制結合起來，從而使軟件的增量版本的快速開發成為可能。其開發過程具有周期性重復的螺旋形狀，強調了風險分析，特別適用於龐大而復雜的高風險系統。
螺旋模型的基本思想是：使用原型及其他方法來盡量降低風險。理解這種模型的一個簡便方法，是把它看作在每個階段之前都增加了風險分析過程的快速原型模型。
優點
1）設計上的靈活性,可以在項目的各個階段進行變更。
2）以小的分段來構建大型系統,使成本計算變得簡單容易。
3）客戶參與每個階段的開發,保證了項目不偏離正確方向及項目的可控性。
4）客戶始終掌握項目的最新信息, 能夠和管理層有效地交互。
5）客戶認可這種公司內部的開發方式帶來的良好的溝通和高質量的產品。
缺點
1）很難讓用戶確信這種演化方法的結果是可以控制的。
2）建設周期長，而軟件技術發展比較快，所以經常出現軟件開發完畢后，和當前的技術水平有了較大的差距，無法滿足當前用戶需求。
3. 迭代模型
四個階段：初始、細化、構造、移交 ——> 周期、階段、迭代。
4. V模型
在開發過程中強調測試，明確標明了測試過程中存在的不同級別，不同階段測試與開發的對應關系。
常用於對軟件的可靠性、質量要求高，強調測試的行業中，例如金融業、國防航空等軟件開發。
5. 原型模型
彌補瀑布模型的不足產生的，將瀑布模型和V模型的思想用於需求分析環節，來解決因為需求不明確而導致產品出現嚴重后果缺陷的模型。適用於需求不明確的，復雜度不是特別高的中小型軟件開發。
快速原型模型 原型進化模型
六、項目管理過程
包括通用項目管理過程（重點！）和產品（技術）實現過程。通用的項目管理過程是遵守按照PDCA循環思想進行控制與管理。過程組不僅與項目有關，而且還與項目的階段有關，即項目的每個階段里都可以包含五大過程組。
項目管理既可以從九大知識域進行理解，也可以從五大過程組進行理解。二者的不同點在於： 前者是從PM必須掌握的知識面來理解什么是項目管理，后者是從項目管理執行流程、順序的角度來理解什么是項目管理。——二者相輔相成，互為補充。
1. 啟動過程組
定義或批准項目或階段的開始。
2. 規划過程組
定義和細化目標，規划最佳的行動方案，實現項目或階段所承擔的目標和范圍。
3. 執行過程組
整合人員和其他資源，在項目的生命周期或是某個階段根據規划來執行任務。
4. 監控過程組
通過定期測量和監控進展，來識別與項目管理計划的偏差，以便及時采取糾錯措施，確保項目或階段目標的達成。
5. 收尾過程組
正式接受產品、服務或工作成果，有序地結束項目或階段。
項目管理既可以從九大知識域進行理解，也可以從五大過程組進行理解。二者的區別是：
> 九大知識域：從項目經理必須掌握的知識面來理解什么是項目管理；
> 五大過程組：從項目管理執行流程、順序的角度來理解項目管理。
七、項目立項管理
概念： 管理一個項目從提出申請到批准立項的整個過程。其中承建方的立項管理，和建設方的立項管理不相同。
建設方的立項管理：編寫項目建議書 ---> 申報和審批 ---> 初步可行性研究 ---> 詳細可行性研究 ---> 編寫可行性報告 ---> 項目論證與評估 ---> 招標及簽訂合同等。對於其項目建議書的申報和審批，通常采取的是 “下級上報，上級審批” 原則。
承建方的立項管理： 項目識別 ---> 項目論證 ---> 投標。
項目論證：審查項目可行性研究的可靠性、真實性、客觀性。評估的對象可以是未完成或未選定的方案。分為機會研究、初步可行性研究、詳細可行性研究三個階段。
1）費用：屬於立項前的工作費用，不計入項目的總投資之內。
2）內容：圍繞市場需求、開發技術、財務經濟三個方面展開調查和分析，市場是前提，技術是手段，財務經濟是核心。
項目評估：評估的對象通常需要正式提交，更強調要得出可信的結論。---在項目可行性研究的基礎上，采用的方法有：
1）德爾菲法：確定項目風險專家，匿名參加會議-->協調員問卷征求重要項目風險意見-->反饋給每一位專家討論-->反復並在主要的項目鋒線上達成一致意見。
2）相關關系法：
3）頭腦風暴法：
4）SWOT方法：
注意：論證和評估可分開也可合並，差異不大但側重點不同，實踐中大部分都是合並操作。
1. 需求分析
2. 編制項目建議書（立項申請）
項目建設單位向組織內的管理層/上級主管部門提交項目立項申請時所必須的文件。
主要內容：項目的必要性（經濟、技術、工程、組織等）、項目的市場預測、產品方案或服務的市場預測、項目建設的必須條件等。
3. 項目可行性研究
1）可行性一般包括可能性、效益性和必要性三個方面，確定項目的投資價值。
2）初步可行性研究（立項決策），詳細可行性研究。其中詳細可行研究方法有：經濟評價法、市場預測法、投資估算法、增量近效益法。
3）可行性研究的順序：（機會研究-->初步可行性研究）-->詳細可行性研究-->可行性研究評估與決策。------項目前期的4個階段，升級改造項目只做初步和詳細研究，升級改造項目只做詳細可行性研究。
4）可行性研究內容一般包括：（1）投資必要性；（2）技術可行性；（3）財務可行性；（4）組織可行性；（5）經濟可行性；（6）社會可行性；（7）風險因素及對策；
注意：項目需求確定是詳細可行性研究的內容。
4.招投標
5.簽訂合同
八、項目整體管理
具有綜合性、全局性和系統性的特點。
1. 制定項目章程
項目章程：正式批准一個當前項目的文檔，或批准現行項目是否進入下一階段的文檔（可以詳細具體，也可以概括粗略）。應當由項目組織以外的項目發起人或投資人發布，其在組織內的級別應能批准項目，並有相應的為項目提供所需資金的權利。
項目目標的描述：項目的目標要求尊求SMART原則，即--具體的、可測量的、可達到的、有相關性的、有明確時限的，因此項目的目標要求是可以量化的。
| 輸入 | 工具與技術 | 輸出 |
| 合同 工作說明書（SOW） 組織過程資產 環境和組織因素 |
項目管理方法 項目管理信息系統（PMIS） 專家判斷 |
項目章程/項目范圍說明書（初步） |
工作說明書：關於項目所要提供的產品或服務的描述。
2. 制定項目范圍說明書（初步）
對項目范圍的定義，即項目需要做什么，主要是確定項目的特點和范圍邊界、交付的相關產品和服務，以及驗收標准和范圍控制方針等。
項目目標的特性為多目標性、優先性、層次性。
如何確定項目目標（要遵循SMART原則）：
（1）分析項目情況
（2）界定項目問題
（3）確定項目目標因素
（4）建立項目目標體系
（5）確認項目目標體系中各目標關系
3. 制定項目管理計划
| 輸 入 | 工具與技術 | 輸 出 |
| 項目章程 項目范圍說明書（初步） 其它計划過程的輸出 組織過程資產 環境和組織因素 |
項目管理方法 項目管理信息系統（PMIS） 專家判斷 |
項目管理計划 配置管理系統 變更控制系統 |
項目管理和其他工作開展一樣，也需要制定合適的計划。項目管理計划是關於對項目進行規划、執行、監控、收尾做出的規定，為項目管理團隊在項目規划、執行、監控和收尾提供行動指南。
項目管理計划包括：
3個基准（進度基准、成本績效基准、范圍基准）。
10個知識域子管理計划（九大知識域子計划 + 過程改進計划）。
項目管理計划 = 3個基准 + 10個知識域資管理計划 + 2個非知識域子管理計划。
4. 指導和管理項目執行
實施已批准的變更通常有三種措施來表示：糾正措施、預防措施、缺陷補救。
| 輸 入 | 工具與技術 | 輸 出 |
| 項目管理計划 已批准的糾正/預防措施 已批准的變更申請/缺陷修復 確認缺陷修復 管理收尾規程 |
項目管理方法 項目管理信息系統（PMIS） 專家判斷 |
可交付物（沒得到客戶驗證、認可的） 變更請求 已實施的變更申請/糾正措施/預防行動缺陷修復 工作績效信息
|
更新措施主要是對項目受控的文件或計划等的變更，以反映項目修改或增加的意見或內容。
5. 監督和控制項目工作
貫穿於整個項目周期的項目管理活動之一。
| 輸 入 | 工具與技術 | 輸 出 |
| 項目管理計划 工作績效信息 績效報告 被拒絕的變更申請 |
項目管理方法 項目管理信息系統（PMIS） 掙值管理 專家判斷 |
推薦的糾正/預防措施/缺陷修復 變更申請 項目報告 |
績效報告包含了完成活動、成果、里程碑、發現的問題等信息（狀態報告報告關鍵的項目信息如項目當前狀態）。
項目報告：通常包括狀態報告、進度報告、成本報告、績效報告、配置狀態報告，以及預測等內容。
6. 整體變更控制
整體變更控制是審查所有變更請求，批准變更，並管理對可交付成果、組織過程資產、項目文件和項目管理計划的變更過程。整體變更控制過程貫穿項目整個生命周期始終。
區別：
配置控制系統：重點關注的是可交付成果及各個過程的技術規范；
變更控制系統：着眼於識別、記錄和控制對項目及產品基准的變更；
| 輸 入 | 工具與技術 | 輸 出 |
| 項目管理計划 變更申請 工作績效信息 推薦的預防/糾正措施/缺陷修復 可交付物 |
項目管理方法 項目管理信息系統（PMIS） 專家判斷 |
已批准/拒絕的變更申請 項目管理計划（已批更） 項目范圍說明書（已批更） 已批准的糾正/預防措施/缺陷修復 可交付物（已批） |
7. 項目收尾
完結所有項目管理過程組中的所有活動，以正式結束項目或階段的過程。包括管理收尾和合同收尾兩部分。
| 輸 入 | 工具與技術 | 輸 出 |
| 項目管理計划 合同文件 事業環境因素 組織過程資產 工作績效信息 可交付物（已批） |
項目管理方法 項目管理信息系統（PMIS） 專家判斷 |
管理收尾章程 合同收尾章程 最終產品、服務或成果 組織過程資產（已更新） |
-----------------------------------------End------------------------------------------
論題：論信息系統項目的整體管理
項目整體管理包括選擇資源分配方案、平衡相互競爭的目標和方案，以及協調項目管理各知識領域之間的依賴關系。
請以“論信息系統項目的整體管理”為題進行論述：
1.概要敘述你參與管理過的信息系統項目（項目的背景、項目規模、發起單位、目的、項目內容、組織結構、項目周期、交付的成果等），並說明你在其中承擔的工作（項目背景要求本人真實經歷，不得抄襲及杜撰）。
2.請結合你所敘述的信息系統項目，圍繞以下要點論述你對信息系統項目整體管理的認識，並總結你的心得體會：
（1）項目整體管理過程：
（2）項目整體變更管理過程，並結合項目管理實際情況寫出一個具體變更從申請到關閉的全部過程記錄。