以下内容摘自信管论坛文章：我是这样过高项的（58，63，52）

二、下午案例分析，我是这样准备的：

我仔细看了近十年的案例分析原题。这个过程我是这样做的，第一次，我全部看了一遍，对答题的方法和技巧有了一个大致了解。第二遍，我看题干，不看答案，然后自己一条一条分析，并写出来，最后和答案进行比较，看什么地方拉下了，什么地方不同。最后，我认为，比较高效的是将案例中可能与问题有关的句子勾出来，针对这个句子写答案要点，并适当进行润色，就可以写出答案了。

这里，我总结出以下内容，供大家参考：

1.答题时要观察题干问题要求，看看是否有以【xxx角度】之类的关键词，如有，答案重点就要往xxx这方面靠。
2.看其它几问，找出【关键词】，在存在问题中进行【扩散思维】。
3.但凡项目实施中途提出要求，首要考虑变更流程的各项要求；严格按变更的流程去办。
4.对甲方不切实际的要求，要以变更管理流程为依据，不要简单迎合甲方。
5.没有【配置管理】，容易导致【版本混乱】，内容冲突
6.凡【突击开发】的，答题要点要注意【配置管理】和【文档管理】。
7.没有【经过授权】就修改，可能【版本】不一致
8.接到【授权】后，开发人员实施【变更修改前】必须对【配置项遵循配置管理流程更改】，才能修改，否则配置项易混乱。
9.没有书面变更申请，容易使【变更不可追溯】
10.成员自行对版本更新，容易引起【基线内容混乱】
11.没有ccb评价和批准，易【工期、成本质量不可控】；
12.变更批准后pm的工作：【通分计b跟】；（1）根据变更申请表准备相应的【变更通知单】；（2）将变更任务【分配】给相应的项目组成员；（3）将变更任务【更新】到项目主计划和项目wbs计划中；（4）【跟踪】变更任务直至完成。
13.变更完成后的验证：1、评审需求文档、设计文档、代码、测试用例,验证是否与需求一致和正确;2、通过需求跟踪矩阵维护需求与后续工作产品的双向跟踪关系3、完成代码测试,据测试结果确认正确性
14.变更后的任务没有纳入新的项目计划，实际与计划脱节。
15.如果变更可能引起别的方面变更，项目经理作出评价并向ccb提出变更申请，必须时还要合同变更。
16.项目变更可能引起【范围、质量、进度、成本、人员、合同、整体】等方面的变更。
17.用户需求变更后，可能【需求基线、代码基线、设计基线、硬件配置基线】会发生变化。
18.需求变更的【提出】需要遵循【单一接口人制度】，避免令出多门。
19.单元测试后必须采取严格的【配置管理流程后才能集成测试】
20.销售经理在项目执行过程中作用（1）维护客户关系【提高客户满意度】（2）及时【收集】客户意见【反映】给项目组（3）关注【合同条款】确保【客户对合同遵循承诺】（4）促进【客户对里程碑的确认】
21.关于矩阵环境下小组成员【配合职能经理比配合项目经理多，可在项目章程中明确】；
22.项目没有确定里程碑，没有阶段性评审。
23.项目【里程碑处的评审】，可以使干系人随时了解项目。一般不会设在单元测试之间。
24.项目的【绩效跟踪】，【进度监控与跟踪】，【绩效管理】
25.关键角色人员【ab角】
26.解决关键人员不足问题，【建立知识管理制度】，【“隐性知识显性化、个人知识组织化” 】
27.采取【奖罚分明】的方式，避免【无原则的老好人】
28.激发工作积极性方法：积极向上的【企业文化】、【和谐宽松的团队气氛】、【团队建设】，
29.项目经理要对团队成员积极【引导】。
30.比如存在【个人英雄主义】，不注意【团队协作】。
31.缺乏项目管理经验，工作中的【人际关系】与【项目跟踪监督】【混为一谈】
32. 没有采取【团队合作】方式，使自己成为“孤家寡人”
33.没有对新加入的团队成员【制订工作经验和能力要求】。新成员与老成员缺少必要的【磨合】。
34.项理经理【不能兼任测试经理】，不利于保证测试的独立性。
35.只关注结果的质量，忽视【过程质量】，只关注数量，没有分析原因。
36.【风险过高】的技术项目，可以考虑【外包】
37.风险要考虑【售后风险】、【商业风险】。
38.常用的词：生搬硬套、不切实际、流于形式，表面文章，只注重形式，不符合实际
39.项目经理要主动及时【向组织报告项目实施中存在的问题】
40.对项目【盲目乐观】，答案中要体现缺乏【风险意识】

该学员其它分享：

前50名告诉你如何过高项之上午综合准备

前50名学员如何过高项之案例分析准备

前50名学员如何过高项之论文准备