以下內容摘自信管論壇文章：我是這樣過高項的（58，63，52）

二、下午案例分析，我是這樣準備的：

我仔細看了近十年的案例分析原題。這個過程我是這樣做的，第一次，我全部看了一遍，對答題的方法和技巧有了一個大致了解。第二遍，我看題干，不看答案，然后自己一條一條分析，并寫出來，最后和答案進行比較，看什么地方拉下了，什么地方不同。最后，我認為，比較高效的是將案例中可能與問題有關的句子勾出來，針對這個句子寫答案要點，并適當進行潤色，就可以寫出答案了。

這里，我總結出以下內容，供大家參考：

1.答題時要觀察題干問題要求，看看是否有以【xxx角度】之類的關鍵詞，如有，答案重點就要往xxx這方面靠。
2.看其它幾問，找出【關鍵詞】，在存在問題中進行【擴散思維】。
3.但凡項目實施中途提出要求，首要考慮變更流程的各項要求；嚴格按變更的流程去辦。
4.對甲方不切實際的要求，要以變更管理流程為依據(jù)，不要簡單迎合甲方。
5.沒有【配置管理】，容易導致【版本混亂】，內容沖突
6.凡【突擊開發(fā)】的，答題要點要注意【配置管理】和【文檔管理】。
7.沒有【經(jīng)過授權】就修改，可能【版本】不一致
8.接到【授權】后，開發(fā)人員實施【變更修改前】必須對【配置項遵循配置管理流程更改】，才能修改，否則配置項易混亂。
9.沒有書面變更申請，容易使【變更不可追溯】
10.成員自行對版本更新，容易引起【基線內容混亂】
11.沒有ccb評價和批準，易【工期、成本質量不可控】；
12.變更批準后pm的工作：【通分計b跟】；（1）根據(jù)變更申請表準備相應的【變更通知單】；（2）將變更任務【分配】給相應的項目組成員；（3）將變更任務【更新】到項目主計劃和項目wbs計劃中；（4）【跟蹤】變更任務直至完成。
13.變更完成后的驗證：1、評審需求文檔、設計文檔、代碼、測試用例,驗證是否與需求一致和正確;2、通過需求跟蹤矩陣維護需求與后續(xù)工作產品的雙向跟蹤關系3、完成代碼測試,據(jù)測試結果確認正確性
14.變更后的任務沒有納入新的項目計劃，實際與計劃脫節(jié)。
15.如果變更可能引起別的方面變更，項目經(jīng)理作出評價并向ccb提出變更申請，必須時還要合同變更。
16.項目變更可能引起【范圍、質量、進度、成本、人員、合同、整體】等方面的變更。
17.用戶需求變更后，可能【需求基線、代碼基線、設計基線、硬件配置基線】會發(fā)生變化。
18.需求變更的【提出】需要遵循【單一接口人制度】，避免令出多門。
19.單元測試后必須采取嚴格的【配置管理流程后才能集成測試】
20.銷售經(jīng)理在項目執(zhí)行過程中作用（1）維護客戶關系【提高客戶滿意度】（2）及時【收集】客戶意見【反映】給項目組（3）關注【合同條款】確保【客戶對合同遵循承諾】（4）促進【客戶對里程碑的確認】
21.關于矩陣環(huán)境下小組成員【配合職能經(jīng)理比配合項目經(jīng)理多，可在項目章程中明確】；
22.項目沒有確定里程碑，沒有階段性評審。
23.項目【里程碑處的評審】，可以使干系人隨時了解項目。一般不會設在單元測試之間。
24.項目的【績效跟蹤】，【進度監(jiān)控與跟蹤】，【績效管理】
25.關鍵角色人員【ab角】
26.解決關鍵人員不足問題，【建立知識管理制度】，【“隱性知識顯性化、個人知識組織化” 】
27.采取【獎罰分明】的方式，避免【無原則的老好人】
28.激發(fā)工作積極性方法：積極向上的【企業(yè)文化】、【和諧寬松的團隊氣氛】、【團隊建設】，
29.項目經(jīng)理要對團隊成員積極【引導】。
30.比如存在【個人英雄主義】，不注意【團隊協(xié)作】。
31.缺乏項目管理經(jīng)驗，工作中的【人際關系】與【項目跟蹤監(jiān)督】【混為一談】
32. 沒有采取【團隊合作】方式，使自己成為“孤家寡人”
33.沒有對新加入的團隊成員【制訂工作經(jīng)驗和能力要求】。新成員與老成員缺少必要的【磨合】。
34.項理經(jīng)理【不能兼任測試經(jīng)理】，不利于保證測試的獨立性。
35.只關注結果的質量，忽視【過程質量】，只關注數(shù)量，沒有分析原因。
36.【風險過高】的技術項目，可以考慮【外包】
37.風險要考慮【售后風險】、【商業(yè)風險】。
38.常用的詞：生搬硬套、不切實際、流于形式，表面文章，只注重形式，不符合實際
39.項目經(jīng)理要主動及時【向組織報告項目實施中存在的問題】
40.對項目【盲目樂觀】，答案中要體現(xiàn)缺乏【風險意識】

該學員其它分享：

前50名告訴你如何過高項之上午綜合準備

前50名學員如何過高項之案例分析準備

前50名學員如何過高項之論文準備