项目管理：名词解释、区别联系、案例分析

信息系统项目管理师目录           
1， 绪论                         
2， 项目生命期和组织             
3， 项目管理过程                 
4， 项目可行性研究与评估         
5， 项目整体管理                 
6， 项目范围管理                 
7， 项目时间管理                 
8， 项目成本管理                 
9， 项目质量管理                 
10，项目人力管理                 
11，项目沟通管理                 
12，项目风险管理                 
13，项目采购管理                 
14，合同管理                     
15，配置管理                     
16，外报管理                     
17，需求管理                     
18，职业道德规范                 
19，组织级项目管理与大型项目管理 
20，战略管理概述                 
21，业务流程管理与重组           
22，知识管理                     
23，项目整体绩效评估             
24，信息安全系统与安全体系       
25，信息系统安全风险评估         
26，安全策略                     
27，信息安全技术基础             
28，PKI公开密钥基础设施          
29，PMI权限（授权）管理基础设施  
30，信息安全审计系统S-Audit      
31, 信息安全系统的组织管理       
32，信息安全系统工程ISSE-CMM     

 1、合同总结

• 一、 合同分类

合同类型	定义/关键字	优点	缺点（风险）
总价合同	设定一个总价；定义需求/工作范围明确；不会出现重大范围变更	价格、范围明确	卖方承担全部风险
成本补偿合同	开口合同；成本+其他费用；工作范围会有很大变动	买方承担全部风险
双方分担	单价确定，总数不定;工作性质清楚、工作量不定;时间&材料合同	双方分担

- 二、总价合同

合同类型	定义/关键字
固定总价合同	最常用 ;不能改变价格;买家喜欢
总价加激励费用合同	财务奖励;受卖方成本、进度、技术绩效影响;设置价格上限，超出部份卖方承担
总价加经济价格调整合同	长周期合同，不受外界不可控制情况影响

- 三、成本补偿合同

合同类型	定义/关键字
成本加固定费用CPFF	所有可列支成本；加固定费用；费用金额一般不变（除非范围改变）
成本加激励费用CPIF	成本按绩效支付；达到绩效后再支付激励费用；费用固定
成本加奖励费用CPAF	所有可列支成本；卖方满足合同规定买方才支付费用；奖励费用由买决定，不允许申诉

- 成本加激励费用CPIF示例：

(万元)	合同约定价格	实际使用价钱1	实际使用价钱2
成本	100	80	120
费用	10	10	10
分成	8/2	+20(实际节省成本20)	-20(实际超出成本20)
真实总价	110	80+10+20*0.2=94	120+10+（-20*0.2）=126

简单总结

1.  范围清楚——总价合同；
2. 范围不清楚——成本补偿合同；
3.  没有范围（无法定义SOW）——工料合同。

招投标几个时间

2、资源平衡和资源平滑

项目进度计划一般需要用进度网络分析技术这个工具来编制，常用的进度网络分析技术包括关键路径法、资源优化技术以及进度压缩等。一般第一步先用关键路径法编制出理论可行的进度计划；第二步运用资源优化技术根据项目实际的资源制约因素，把理论可行的进度计划变为实际可行的进度计划；最后用进度压缩法来进一步优化项目进度计划。本文主要通过举例详细讲述第二步资源优化技术下的两种子技术资源平衡和资源平滑。

先来熟悉一下二者的概念：资源平衡与资源平滑 - 简书

资源平衡(Resource Leveling)，是根据资源制约因素对活动的开始日期与完成日期进行调整的一项技术。这儿的资源制约因素可以是关键资源只在特定时间可用，或者数量有限，或者被过度分配等等情况。资源平衡往往会改变关键路径（通常是延长）。

资源平滑(Resource Smoothing)，是为了让项目资源需求不超过预定的资源限制而对进度活动进行调整的一种技术。资源平滑不会改变项目关键路径，也可以把资源平滑看做一种特殊的资源平衡。

3、管理储备和应急储备对比

储备分析用于确定项目所需的应急储备和管理储备。
应急储备：
在考虑持续时间估算时，需要考虑应急储备（有时也称“进度储备”），以应对进度的不确定性。应急储备是包含在进度基准中的一段持续时间，用来应对已接受的已识别风险。应急储备和与“已知-未知”风险有关，应该在项目文件中列出应急储备。
管理储备：
管理储备是为了管理和控制项目而特别留出来的项目预算，来应对项目中的不可预见的工作，管理储备用来应对“未知-未知”风险。使用管理储备可能会变更进度基准。
成本基准包括应急储备，不包括管理储备。但是管理储备属于项目总预算和资金需求的一部份。动用管理储备应对不可预见的工作时，就要把管理储备增加到成本基准中去，从而导致成本基准的变更。
如果已识别的风险没有发生，就可能要把储备从项目预算中扣除，当做项目盈利。相反可能会发起变更，请求更多的储备来应对新识别的风险。

4、控制账户、规划包、工作包

1、控制账户是一个管理控制点，在该控制点上，把范围、预算和进度加以整合，并与挣值比较，以测量绩效。控制账户拥有2个或以上的工作包，但每个工作包只与一个控制账户关联。

2、规划包是一种低于控制账户而高于工作包的工作分解结构组件，工作内容已知，但详细的进度活动未知。

3、工作包是WBS 的最低层级是带有独特标识号的工作包。这些标识号为进行成本、进度和资源信息的逐层汇总提供了层级结构，构成账户编码。

3、工作包是WBS底层的可交付成果，是WBS的一部分，活动不是WBS的一部分。

3、工作包不表示时间、也不表示顺序，只表示项目范围；活动可表示时间、顺序、是资源估算、历史估算、费用估算的重要依据。

4、活动 (Activity) 是由工作包 (Work package) 分解而来，是实现工作包所需的具体工作。

 5、缺陷补救、纠正措施和预防措施

缺陷补救（Defect Repair）是为了修正不一致产品或产品组件的有目的的活动。其中提到的缺陷（Defect）是指项目组成部分中不能满足要求或规范，需要修补或更换的瑕疵或缺点。

纠正措施（ Corrective Action）是为使项目工作绩效重新与项目管理计划一致而进行的有目的的活动。

预防措施（Preventive Action）是为确保项目工作的未来绩效符合项目管理计划而进行的有目的的活动。

为了认清这仨的真面目，先来个生活栗子热热身：

一天，你突然发现牙钻心地疼，到医院去检查——龋齿。二话不说，医生拿来一大堆寒气逼人的牙科工具帮你修理这颗病牙（医生此时做的是缺陷补救工作）。

经历完吱吱呀呀哇哇哎哟之后，你想今后可不能受这罪了，赶快让医生帮你检查其他牙齿有无问题，医生一脸严肃地告诉你另外三颗处于对称位置的牙齿有些前期症状。听闻此言，你妈呀一声从牙科台上弹起来，马上用求助的眼神问医生如何保护这三颗牙齿。医生说要正确刷牙，少吃甜食、酸醋类和坚硬食物等等（这时医生告诉你的是纠正措施，把你从偏离牙健康的轨道中拉回来）。

天天嚼巧克力、喝可乐、吃酸辣粉的你这回悲催了，但是为了保护牙，只好咬咬牙戒了。哎哟，又痛上了，还是别咬牙了。贪心的你在没给医生发红包的情况下，继续追问医生如何让剩下为数不多的几颗健康牙齿在未来的日子都不会出现问题。由于你平常爱学**人品好，这次遇上了好医生，给你提供增值建议：除保持口腔清洁之外，还要固本，多运动、常磕牙、补充富含钙和无机盐的食物，食用高纤维食物（这时医生告诉你的是让你一开始就不出错的预防措施）。

照惯例，专业栗子该出场了：

在一个大型改造项目中，项目经理发现新设计制造的部件与其它相邻部件装配时出现干涉。为了不影响新系统的按时投产，项目经理马上安排人对新部件进行现场返工（改正错误，此谓缺陷补救），经过6小时全力补救，终于保证了试产成功。回过头来，项目经理马上会同相关功能组负责人一起查找原因，结果发现是机械工程师向采购部提供旧版图纸导致，而最新版图纸并没有在图库中存档。项目经理安排专人就此问题对图纸管理、配置管理和变更管理进行全面审计，对审计出来的10多项潜在问题和隐患进行整改（纠正偏离，回到正轨，称为纠正措施）。同时，项目经理汇报发起人，建议对原来的纸质管理和多头管理进行改善，建立配置、变更电子化管理系统，并进行整体集中管理，防止此类问题再次发生（使得未来工作一开始就符合计划要求，正是预防措施）。

6、验证与确认 区别

验证和确认的关键区别是：
1. 验证检查产品是否构建正确。确认检查是否构建了正确的产品。
2. 验证通常是一个内部过程，而确认是外部的。
3. 验证通常发生在确认之前。

7、解决冲突 ：回避、缓和、妥协、强制、合作

举个例子：古惑仔里的故事，山鸡跟生番抢屯门扛把子的位置，有一天两边的小弟打了起来，山鸡小弟把对方打残废了。生番要求山鸡让出屯门老大的位置，以表示赔礼道歉。
这个时候山鸡有几个策略：
1，缓和（也叫包容）：山鸡让步了，说退出此次屯门老大的竞争。生番很得意。
2，妥协（也叫调解）：后来山鸡想想不甘心，于是找双方的大哥恐龙和浩南一起来聊一下，双方也考虑了蒋先生的意思，最后经过各位老大的调节，劝双方各让一步，有一定的妥协，由山鸡出钱给生番小弟治疗，并且让出两个场子作为赔礼道歉。
3，强迫（也叫命令）：山鸡实在忍不了，觉得各位老大的调解虽然是好意，但是这口气难以平息。所以等各位老大走了之后，就直接恐吓生番说“啥都不赔你，不服的话晚上单挑啊！就是要操翻你，不然就不是你鸡爷”，生番早知道山鸡的威名，思来想去觉得算了，还是就认了吧。

（1）撤退/回避
从实际或潜在冲突中退出，将问题推迟到准备充分的时候，或者将问题推给其他人员解决。

（2）缓和/包容
强调一致而非差异；为维持和谐与关系而退让一步，考虑其他方的需要。

（3）妥协/调解
为了暂时或部分解决冲突，寻找能让各方都在一定程度上满意的方案，但这种方法有时会导致“双输”局面。

（4）强迫/命令
以牺牲其他方为代价，推行某一方的观点； ​只提供赢 — 输方案。通常是利用权力来强行解决紧急问题，这种方法通常会导致“赢输”局面。

（5）合作/解决问题
综合考虑不同的观点和意见，采用合作的态度和开放式对话引导各方达成共识和承诺，这种方法可以带来双赢局面。​​

7、规划风险应对 — 威胁和机会

8、属性抽样与变量抽样的区别

一、属性抽样

属性抽样时，每个样本的结果都是非此即彼（比如，要么是，要么不是；要么合格，要么不合格），但是其统计结果却可以是一个数量，比如，合格率80%。

举例一，某商场决定提升服务水平，确定是否增加一个儿童设施，这时需要调研来商场的儿童比例，调研表上规定年龄低于14周岁以下的确定为儿童（定性，非儿童即成年人），并进行调研，调研结果显示，来商场儿童所占的比例为38%。

举例二，某车间对其生产的产品“钢圈”进行检查，钢圈的直径范围落在5.3～5.4之间的为合格品（范围界限，非里即外），之外的为次品，某日进行了500批次的抽检，其合格率为89%。

二、变量抽样  变量量抽样是在连续的量量表上标明结果所处的位置，表明合格的程度

变量抽样时，需要从量的角度通过样本来推断总体，比如，估算中体的平均值，预测总体的偏差情况等，其结果是一个数量，这个数量说明什么则根据具体应用而定。

举例一，某商场决定提升服务水平，确定是否增加一个儿童设施，这时需要调研来商场儿童的平均年龄，再根据平均年龄的分布来确定购买什么样的儿童设施，商场工作人员连续一周对进入商场的儿童的平均年龄进行调研，得出结果为1～3岁18%，3～6岁56%，6岁以上26%。

举例二，某车间对其生产的产品“钢圈”进行检查，来确定总体各批次的平均直径和标准偏差，工作人员随机抽取的8个批次，每个批次抽取100个进行检验，得出相应的数据。

9、马斯洛需求层次论、赫兹伯格：双因素理论、麦格雷戈：X-Y理论

1、马斯洛的需求层次理论----人有五个层次的需求，从最低等级到最高等级依次是：生理需求、安全需求、社交需求、尊重需求、自我实现需求。通常，人们只有在较低层次的需求得到满足后，才会追求较高层次的需求。

2、赫兹伯格的双因素理论----有两类因素（保健因素和激励因素）会决定人的行为。

保健因素----是导致不满足感的因素，这些因素做得好不一定不会提高激励员工，做得不好就会损害激励， 会消极地影响员工的积极性，
比如：工作环境或条件、工资、同事或上下级之间关系、个人生活、安全、地位、职务等；相当于马斯洛需求层次理论的较低层次的需求（生理需求、安全需求、社交需求）
激励因素----是导致满足感的因素，能够真正起激励作用的。积极的激励行为会使员工努力积极地工作，以达到公司的目标和员工自我实现的满足感和责任感。
比如：成就感、责任感、得到任何和赞赏、挑战性和兴趣、发展前途、个人成长等；
相当于马斯洛需求层次理论的较高层次的需求（尊重需求、自我实现需求）

3、维克多*弗罗姆的期望理论认为，一个目标对人的激励程度受目标效价和期望值两个因素影响。如果实现该目标对个人来说很有价值，则个人的积极性就高；反之，积极性则低。只有个人认为实现该目标的可能性很大，才会去努力争取实现，从而在较高程度上发挥目标的激励作用；反之，目标的激励作用则小，以至完全没有。

4、麦格雷戈：X-Y理论

麦格雷戈的X理论----认为人是消极懒惰的，缺乏进取心，不想工作，总是逃避责任（传统管理偏向此“人性本惰”论）
麦格雷戈的Y理论----认为人是积极的，愿意进步，愿意承担责任，并从工作中获得满足感和成就感。（现代管理偏向此“人性本善”论）Y理论、期望理论、马斯洛理论和赫兹伯格的卫生
X理论认为只能用低层次的需求进行激励；Y理论认为人更应该受到高层次需求的激励。

采购中的几种文件，RFI、RFQ、RFP和IFB的对比

建议邀请书(Request for Proposal，RFP)用于采购方要求供应商提供问题的解决方案的建议。它允许采购人员在没有发现最佳资源之前，还没有决定向谁采购时，可以去广泛地搜集供应商信息并进行谈判。

REQUEST FOR QUOTATION (RFQ) 报价邀请书。在民营企业中，RFQ通常被认为与RFP相同，但在某些组织中，RFQ则被用于取得为计划目的之约略资讯，此时在要求中需明确说明。在政府采购中，RFQ只被用于计划资讯的取得

一般使用顺序：都使用在采购规划阶段，RFI：征求供应商意见，以使需求明确化，如果需求很明确，则用RFP，征求供应商的建议书（Proposal）, 招标或要求供应商报价前，使用RFQ，以作为招标底价及比价的参考（前提是给所有供应商的报价格式都一样的，如果不一样，则无法比较，也失去了意义），在这些过程中，能够降低需求不明确及预算不精确的风险（这个风险确实存在的哦，你看哪个项目到最后不是超标的？就好比装修房间，最后的花费肯定比预算要多出20%属于正常。

投标邀请书(Invitation for Bid，IFB)为所有供应商报价提供他们最佳方案的平等的机会。因为招标流程会约束了采购方和供应方，IFB只有在满足以下条件时才可以使用：已经清楚地定义了规范书和工作种说明书（Statement Of Work）；采购金额足够大；法规或企业规程条例强制的要求；其他方法不适合。因为正式的招标流程对采购方和供应方来说都是花费比较高的，所以当其他方法可以提供必要的信息时，就不应该使用IFB方法。

卖方建议书

卖方为响应采购文件包而编制的建议书，其中包含的基本信息将被评估团队用于选定一个或多个投标人（卖方）。如果卖方将提交价格建议书，最好要求他们将价格建议书与技术建议书分开。

评估团队会根据供方选择标准审查每一份建议书，然后选出最能满足采购组织需求的卖方。

	信息邀请书RFI	报价邀请书RFQ	建议报价邀请书RFP	投标邀标书IFB
目的	获得与产品、服务、供应商相关的信息	取得供应商对所需产品、服务或服务的承诺	要求供应商对需求提出最好解决方案的建议	为所有的供应商做出最好的方案而提供平等的机会
使用条件	适用于具体申请之前	对所需要的物料或服务的具体要求已经明确	用于评估供应商，或采购方不清楚的流程、质量、服务、准标或其他元素	用于定价比价高的物料，或者该物料存在最低价格
灵活性	非正式的、不是招标	正式的、提出具体要求	采购方可以开始谈判、信息收集，在最佳来源确定前，不承诺一定采购	对采购和供应双方都有约束
结果	目录、价格表和产品信息	比较供应商提交的方案	可供选择的大量潜在解决方案	最好的和最终的方案
优点	简单、快捷	供应商受限于报价的承诺，而采购方可以就所有问题进行谈判	采购方可以对提交的方案中的任何问题与某一个或所有的供应商进行谈判	正式的流程。各招标或流程文件都是可比较的
缺点	没有确定目标，仍然需要RFQ或IFB	如果没有很好地准备报价申请书请求，各个供应商的投标可能无法比较	如果允许一个供应商修改方案，就必须允许所有的投标者修改方案	因为其他方法为采购提供了更多的灵活性。最好不使用这个方法

10、相关方登记册、相关方参与计划、沟通管理计划

相关方登记册：是识别相关方的输出，记录关于已识别相关方的信息，包括:身份信息、评估信息、相关方分类;

相关方参与计划：是确定用于促进相关方有效参与决策和执行的策略和行动; 。相关方现有的参与项目的程度，以及所需的参与项目的程度。

• 为了获得所需的参与程度，应该采取的与相关方打交道的策略和措施。

沟通管理计划：描述将如何规划，结构化、执行与监督项目沟通，以提高沟通的有效性。

• 什么时候、以什么方式、向谁发送什么信息。没收到报告，没收到通知

通俗地说，相关方登记册是记录了有哪些人; 相关方参与计划是规定人们怎样参与项目; 沟通管理计划是如何与相关方交流信息。

如果不知道项目有哪些相关方，或者相关方有什么要求，查看相关方登记册;

如果不知道相关方如何参与项目，看相关方参与计划。

如果相关方抱怨收到的报告、信息或者会议内容不合适，传达方式不合理，这些与沟通管理计划有关。

行政收尾、合同收尾、项目收尾区别与联系

 项目收尾包含合同收尾和行政收尾

合同收尾（Contract Closure）
合同收尾即工作完成、产品验收和移交、价款结算和争议解决等
组织对外的活动

行政收尾（Administrative Closure）
对项目工作进行全面、系统和深入的回顾，进行完工后评价，考察“如果有机会重新做该项目可以如何改进”，把有关经验教训提炼出来并形成文档，并使它成为“组织过程资产”的一部分。
组织内部的活动

先后顺序
先合同再行政，如果分阶段项目那么每个阶段也根据约定进行合同收尾。

在收尾过程组中也对收尾的内容进行了诠释如下：

• 获得客户或发起人的验收，以正式结束项目或阶段；
• 进行项目后评价或阶段结束评价；
• 记录裁剪任何过程的影响；
• 记录经验教训；
• 更新组织过程资产；
• 将所有相关项目文件在项目管理信息系统中归档，以便作为历史数据使用；结束所有采购活动，确保所有相关协议的完结；
• 庆功宴
• 对团队成员进行评估，释放项目资源。

在对PMP的试题研究中发现，实际的收尾内容不止如此，还应该加上下列内容：

• 财务收尾（收付款）
• 客户满意度调查
• 最后项目绩效报告 

敏捷项目管理思想下每个项目必需经历的五个阶段：

1. 构想阶段：确定产品构想、项目范围、项目社团及团队共同工作的方式；
2. 推测阶段：制定基于功能的发布计划、里程碑和迭代计划、确保交付构想的产品；
3. 探索阶段：在短期内提供经测试的功能，不断致力于减少项目风险和不确定性；
4. 适应阶段：审核提交的结果、当前情况以及团队的绩效，必要时做出调整；
5. 结束阶段：终止项目、交流主要的学习成果并庆祝；

敏捷管理中，强调迭代性，项目的五个阶段在整个项目中不断的迭代前行，产生可交付产品，进入下一个计划工作，开始新的迭代。不断的修正项目前景和用户需求，使用户整个项目周期内都能参与到项目中，避免产品偏离客户的真实需求。这是一个非常有效的需求管理的方法，因为产品首先要能满足客户的功能性要求，产品开发人员对需求的理解不可避免的会存在出入，此时与客户对每个迭代产生的可交付成果的评估，是纠正错误和修正产品标准的机会，以避免偏离产品目标太远。相对于瀑布式的管理模式，从项目计划到交付产品，这一个相当长的时间内，由于客户参与不够、客户表述原因、项目组成员的理解误区、客户需求的修正和变更等客观原因，往往会出现产品与产品说明书相去甚远，这并不是项目团队所希望的。

敏捷开发过程当中，有四种会议

分别是
 计划会，
 每日站会，
 回顾会，
 评审会，
 其中数计划会最为重要。应该来说会议是有点多的，不是流传一种说法嘛，不开会的团队的一定不是一个好团队，好的团队一定经常开会。经常开会是需要时间的，因此有利有弊，如果会议时间和节奏控制的不好，就会占用掉团队很多的精力和工作时间，那就得不偿失了。在敏捷开发模式中，每种会议都有其特殊的职责和使命，不同的会议上所讨论的内容是不一致的，只要把握住会议的关键点，就可以为团队的敏捷模式服务。
关于开会，日常工作当中各种会议、培训、沟通等都会占用掉大量的工作时间，因此会议贵精不贵多，在最短的时间内达成最有效的决议，这才是一个有成果的好会议。产品团队必然也会面临这样的问题，在敏捷团队内部，除了必要的全员培训外，尽量保持在团队内部只有敏捷的这四个会议，其余的沟通和会议都可以由PO和SM去参加，然后回来传达给团队成员即可，这样可以减少团队整体的时间消耗，保证团队的工作效率。

Sprint Planning敏捷迭代计划会议
在每个敏捷迭代开始之初，由产品负责人讲解需求，并由开发团队进行估算工时的计划会议。 在会议上需要：排列需求优先级；分析和评估产品Backlog并确定该迭代的目标；计划会议上还需要制定迭代计划，包括： 根据产品Backlog（功能点）创建Sprint Backlog（即迭代任务）；然后为Sprint backlog中的任务做估算；团队成员从产品Backlog中挑选他们承诺完成的条目。
敏捷的迭代实现始于计划会议，所以一个好的计划会议是每个迭代成功的基础，一般分两个阶段进行，两个阶段参与会议的人员会不一样；

计划会议的目标：
1、基于敏捷规划产生的Product Backlog以及优先级，通过计划会议，确定迭代的目标、团队成员、形成Sprint Backlog，明确评审会、回顾会时间；
2、分解Sprint Backlog并确定相应的完成时间，并由团队成员共同挑选这些Sprint Backlog；

阶段一参与人员：产品经理、Product Owner、Scrum Master、团队成员，有业务人员的话还可以邀请业务人员一起参加。
会议时长：1-4小时
一般参考进程安排如下：
1、Scrum Master公开迭代时间表；
2、产品经理和Product Owner讲述Product Backlog，对应的业务价值和优先级；
3、团队针对Sprint Backlog和优先级达成一致；
4、Scrum Master和团队成员共同确定Sprint Backlog；

阶段二参与人员：Scrum Master、团队成员，其他人员选择性参加
会议时长：1-4小时
一般参考进程安排如下：
1、团队成员针对Sprint Backlog共同分解任务；
2、团队成员共同进行工作量评估(每个Task不超过2天)，确定开始时间和完成时间；
3、团队成员共同认领任务；
4、共同确定DoD，团队达成一致；
5、团队共同确认迭代目标和价值；
如果单个迭代内安排的Product Backlog安排的比较多的话，一般迭代计划会议需要开一个整天，虽然时间有点长，但这个会议会确认整个迭代的详细计划和安排，因此也是值得的。

Daily Stand-up Meeting每日站会
团队每天进行沟通的内部短会，因一般只有15分钟且站立进行而得名，团队成员通常会在会议上讲述如下3点内容：
1) 昨天我做了什么
2) 今天我计划要做什么
3) 我遇到了什么问题，妨碍了我尽可能有效地工作
Scrum Master记录会议上提出的问题，但是不要在会议上讨论和解决问题，而是要会后在找相关人员进行讨论和解决。

Sprint Review敏捷迭代评审会议
在迭代结束前给产品负责人演示并接受评价的会议，并根据反馈结果，提出新的产品Backlog
参与人员：产品经理、Product Owner、Scrum Master、团队所有成员
会议时长：1-4小时，视演示内容而定
主要是检验迭代成果，检查是否完成迭代计划中的迭代目标，有可能的话要求用户参与测试流程，并得到用户对产品的认可，鼓励用户自己进行测试设计和进行破坏性测试，充分暴露产品的设计和功能问题。
由Scrum Master来推进会议进程，Product Owner记录用户反馈，根据结果维护产品 backlog，一般在迭代结束前做一次。

Sprint Retrospective敏捷迭代回顾会议
在每个迭代结束后召开的关于自我持续改进的会议，围绕如下三个问题进行讨论：
1) 本次迭代有哪些做得好；
2) 本次迭代我们在哪些方面还能做得更好；
3) 我们在下次迭代准备在哪些方面改进；
团队确定问题优先级，并根据优先级确定团队能够解决的Top问题；团队讨论Top问题的措施，并选择在下一个迭代可以完成措施，分配责任人进行跟踪。
参与人员：Scrum Master，Product Owner，团队成员。
会议时长：0.5-1.5小时
主要针对当前迭代，团队成员自由讲述可以需要保持的做法，改进的点以及持续跟踪计划。
Scrum Master将团队讨论以及行动计划形成会议纪要，并发送给整个团队和有关同事。需要按照回顾会议的结论，维护一份待办事项列表，在下次回顾会议上进行跟踪。

案例分析
案例一：某Team在每日站会中，Scrum master准时组织大家开始晨会，成员一个接着一个说，昨天做了什么事情，今天计划做什么事情，遇到什么问题，成员A说昨天遇到了一个问题未能解决，Scrum master问遇到的是什么问题，成员A详细说明了该问题，这时成员B说这个问题他也遇到过，他是通过XX方式解决的，讨论后成员A明白了，然后继续晨会，由于小组成员有10个人，整个会议开下来大概花费了30分钟。
问题分析：Scrum master不应该在每日站会上询问详细的问题细节，而应该转移到会下询问，当团队成员之间进行讨论的时候，Scrum master需要及时拉回来，讨论应该转移到会下进行，晨会要在固定的时间固定的地方并且在固定的时间内完成。会议时间需要控制在15分钟之内。
案例二：某Team在开回顾会议中，Scrum master详细总结了本次迭代中有哪些做不够好的，并指出了对应的事和人，接着对应的责任人开始述说哪些地方确实是做的不够好及其原因，最后给出改进措施然后结束会议。
问题分析：回顾会不是批斗会，不应该只说做的不好的，做的好的也要说，Scrum master主要是鼓舞大家的士气，应该先从做的好的方面开始说起；并且做的不好的方面都只对事，不对人，做的不好是整个Team的责任，不仅仅是某几个人的责任；最后的改进措施需要给有后续跟踪的责任人和有效性的反馈。
在敏捷的迭代执行过程中，上述四种会议会随着每个迭代一直进行，基本上形成了一个闭环，可以让团队在每个迭代的执行过程当中去学习和总结，从而正确的按照敏捷的要求去做，使团队真正的敏捷起
———————————————— 

工作分解结构、资源分解结构、职责分配矩阵、资源日历

通过制定项目章程，完成了项目范围的确定，紧接着对项目内容进行WBS工作包拆解，那么 关于工作和人员的对应关系，关系顺序如下:

一、工作分解结构

工作分解结构（简称WBS）跟因数分解是一个原理，就是把一个项目，按一定的原则分解，项目分解成任务，任务再分解成一项项工作，再把一项项工作分配到每个人的日常活动中，直到分解不下去为止。即：项目→任务→工作→日常活动。
关联：工作内容决定了需要哪些资源完成，资源（人员）水平决定工作完成时间。

二、资源分解结构

工作内容明确后，需要明确由哪些人来完成这些功能，此时进入资源分解结构。在项目中，人=资源的一种。
项目活动的资源分解结构可以用表1所示的资源矩阵来描述。
       
其中，如果某项关键活动，需要特定的人员来完成，这名特定的人员就是强制性资源；其他工作在某个水平线上都可以顺利完成，就是非强制性资源要求。

三、职责分配矩阵

在经过与公司申请资源，和职能经理讨价还价后，我们得到一些团队成员，通过职责分配矩阵来分配工作与职责。
责任分配矩阵是，明确其角色与职责的有效工具，通过这样的关系矩阵，项目团队每个成员的角色，也就是谁做什么，以及他们的职责，也就是谁决定什么，得到了直观地反映。项目的每个具体任务都能落实到参与项目的团队成员身上

e.g 某城镇节日庆典活动项目需要完成的项目工作单元有文娱节目、宣传、志愿者名单、游戏、清洁、保安、食品、服务等；
项目团队由刘明等16人组成，通过责任分配矩阵可以将所需完成的工作合理分配给每一位团队成员，并明确各自在各项工作中应承担的职责。
用字母表示的该项目的责任分配矩阵如下表所示:

四、资源日历
前面我们已经明确了工作内容，也获取了相应的资源，可是到了某一个里程碑节点，chick时发现某项任务还是延期了。PM分析后发现，该任务的成员在节点前休假两周，虽然他的水平和态度都很不错，但任务还是不可避免的延期了。
此时我们需要资源日历来调配成员和任务之间的关系。

资源日历是在项目日历上定义的工作时间和休息日是每个资源或资源组的默认工作时间。资源日历初始确定为项目日历。
如果需要，可以为个别资源定义单独的资源日历，以指定其特殊工作时间、假期、缺勤和计划个人时间。这有助于创建更准确的日程。 

《工作说明书 》和 《范围说明书 》的区别

项目工作说明书是对项目产品、成果的叙述性说明，而范围说明书是对产品、成果的详细说明，还要加上验收标准和除外责任等。

采购工作说明书是规划采购管理过程的输出，在得到自制外购决策之后，确定了要外购，我们会有一个外购内容的叙述性说明。

如果是内部项目，发起人提供； 
如果是外部项目，客户、招标文件、合同提供；

对于外部项目，项目工作说明书来自于客户、招标文件或合同。那么我们在外购的时候，给卖方一个工作说明书，对于卖方来讲，我们不就是客户么，卖方拿到了这个工作说明书，了解到我们的需求，以便制作投标文件，如果得到了合同的授予，还要根据这个SOW来制作自己的项目章程。

 核对单和核查表的区别

三大审计：质量审计、风险审计、采购审计

类比估算、参数估算、自下而上估算、三点估算分别都在什么情况下使用？

类比估算适用于项目早期，缺乏详细信息时，或有类似项目时使用；

参数估算在有数据库、参数模型时使用，可靠性一般高于类比估算；

自下而上估算在无法整体估算时，它的准确性最高；

三点估算主要是存在风险和不确定性时使用，以便提高估算的准确度。

人际关系技能 包括

领导力；
团队建设；
激励；
沟通；
影响力；
决策；
政治和文化意识；
谈判；
建立信任；
冲突管理；
教练技术。

 领导力风格 

• 放任型领导（例如，允许团队自主决策和设定目标，又被称为“无为而治”）；
• 交易型领导（例如，关注目标、反馈和成就以确定奖励，例外管理）；
• 服务型领导（例如，做出服务承诺，处处先为他人着想；关注他人的成长、学习、发展、自主性和福祉；关注人际关系、团体与合作；服务优先于领导）；
• 变革型领导（例如，通过理想化特质和行为、鼓舞性激励、促进创新和创造，以及个人关怀提高追随者的能力）；
• 魅力型领导（例如，能够激励他人；精神饱满、热情洋溢、充满自信；说服力强）；
• 交互型领导（例如，结合了交易型、变革型和魅力型领导的特点）。

案例分析

具体的考查内容包括可行性研究、项目立项、合同管理、项目启动、项目管理计划、项目实施、项目监督与控制、项目收尾、信息系统的运营、信息（文档）与配置管理、信息系统安全管理。

1 试题解答方法

根据软考命题的习惯，下午案例分析会有5道大题，全部以问答题的形式出现，有时也会出现有选做题，满分为75分。
下午试题I对于考生的基本要求将体现在：
（1）需要具有一定的信息系统项目管理实践经验，有较好的分析问题和解决问题的能力。
（2）对于有关项目管理方面，有广博而坚实的知识或见解。
（3）对应用的背景、事实和因果关系等有较强的理解能力和归纳能力。
（4）对于一些可以简单定量分析的问题已有类似经验并能进行估算，对于只能定性分析的问题能用简练的语言抓住要点加以表达。
（5）善于从一段书面叙述中提取出最必要的信息，有时还需要舍弃一些无用的叙述或似是而非的内容。
考生应当加强上述要求的训练。
提示：考生解答试题时可按以下途径来分析和解决问题。
（1）标出试题中要回答的问题要点，以此作为主要线索进行分析和思考。
（2）对照问题要点仔细阅读正文。阅读时，或者可以列出只有几个字的最简要的提纲，或者可在正文上作出针对要回答问题的记号。
（3）通过定性分析或者定量估算，构思答案的要点。
（4）以最简练的语言写出答案。注意不要超过规定字数，语言要尽量精简，不要使用修饰性的空洞词汇，也不要写与问题无关的语句，以免浪费时间。

6，范围管理

1、合同阶段
明确工作说明书或更细的合同条款
合同期间双方的权利和义务
变更
措施
干系人

2、计划阶段
编制项目范围说明书
创建工作分解WBS
制定项目范围管理计划

2、执行阶段
跟踪和监管并记录
建立项目管理制度并监管执行
干系人沟通
建立完善的变更流程，变更控制
加强对项目阶段性的评审和确认

范围管理可能存在的问题：

1. 1、没有制定范围管理计划和需求管理计划
2. 2、不能仅依据过去经验编写/不够充分、完整
3. 3、没有做好需求收集、分析、调研等工作
4. 4、没有做好需求跟踪/需求评审工作进行验证
5. 5、项目范围说明书不应由项目经理一人编写，需要相关人员参与
6. 6、WBS制定应该由所有干系人共同完成和一数确认，而非项目经理一人完成
7. 7、项目范围基准未经评审和审批/缺少正式的确认范围工作，没有和客户进行需求确认
8. 8、范围变更没有规范的变更控制流程/针对范围管理中的偏差和问题，没有做好范围监控工作
9. 9、范围变更的结果没有得到用户的确认
10. 对范围控制不足；

改进方法：

1. 1、明确添加需求获取过程，使用访谈、焦点小组会议、头脑风暴、问卷调查、原型法等多种方式获取需求;
2. 2、通过多种方式进行用户需求分析，包括使用图形表示法、原型等可视方法、系统可行性需求分析及模块描述系统;
3. 对项目范围进行清晰定义， 并根据定义对工作进行分解，制定WBS；
4. 3、编写需求和范围说明书;
5. 4、进行需求验证和需求评审，并邀请客户参与;
6. 5、求得干系人对需求的承诺，进行需求确认，对定稿的需求建立需求基线;
7. 6、需求变更严格按照整体变更控制流程进行;
8. 对项目范围进行有效控制；
9. 进行沟通管理，协调多个项目干系人之间的矛盾。

补充： WBS的主要作用：
① 防止应该做的工作被遗漏掉，也防止镀金
② 方便与项目圆队的沟通，项目成员很容易找到自己负责部分在整个项目中的位直
③ 防止不必妥的变史
④ 提供个基本的资源（人员和成本）估算依据
⑤ 帮助获取团队认同和创建团队

创建WBS的原则一这个需要记住
①在各层次上保持项目的完整性，避免遗漏必妥的组成部分
②个工作单元只能从属于某个上层单元，避免交叉从属
③相同层次的工作单元应用相同性质
④工作单元应能分开不同责任者和不同工作内容
⑤便于满足项目管理计划、 控制的管理需妥。
⑥最低层工作应该具有可比性、 走可管理的，可定量检查的。
⑦应包括项目管理工作（因为是项目具体工作的往被忽视）
⑧遵守 8/80 原则。

形成WBS的主要活动”答题要点如下：

1. (1)识别和分析可交付成果及相关工作;
2. (2)确定WBS的结构和编排方法;
3. (3)自上而下逐层细化分解;
4. (4)为WBS组件制定和分配标识码;
5. (5)核实可交付成果分解的程度是否恰当;

项目范围说明书包含什么内容？ 

1. 1、产品范围的描述
2. 2、验收标准
3. 3、可交付成果
4. 4、项目的除外责任
5. 5、制约因素
6. 6、假设条件

作用

1. 1、确定范围
2. 2、沟通基础
3. 3、规划和控制依据
4. 4、变更基础
5. 5、规划基础

 
范围变更控制的要点有哪些？
①确定范围变更是否已经发生：
②对造成范围变史的因素施加影响 以确保这些变更得到 致的认可：
③当范围变史发生时 ，对实际的变更进行管理 。

1. 1、规划范围管理过程输入：项目章程、经验教训知识库、项目管理计划、人事管理制度;
2. 2、项目变更过程，对项目范围的控制和对范围基准的理解：范围基准包括范围说明书、WBS与WBS词典三大部分
3. 3、范围管理计划描述了项目范围将如何被定义、制定、监控、控制和确认;
4. 4、规划范围管理应至少包含如下活动：制定详细的范围说明书、使用WBS把项目分解成离散的可交付成果、确定范围变更和修订的构成以及如何通过正式的变更控制过程对范围变更进行管理、维护WBS和范围基准、如何验收可交付成果;
5. 5、需求管理计划的活动至少包括：规划活动(收集、分析、分类、排序、文档化、确定测量指标、定义追踪结构)、管理活动(跟踪、报告、追踪、确认、执行配置管理);
6. 6、项目的成功受两方面因素的直接影响：发现与分解干系人的需求而成为需求，关注与产品需求、服务和项目结果有关的确定、归档和管理过程;
7. 7、需求的分类：业务需求、干系人需求、解决方案需求、过渡需求、项目需求、质量需求;
8. 8、需求跟踪矩阵用于在整个项目生命周期中跟踪不同的需求属性，塔奥使用来自需求文件的信息，跟踪项目其他方面的需求是如何被提出的;
9. 9、项目范围说明书描述了项目范围、主要的可交付成果、假设条件和制约因素;它包含了整个范围，被认为是项目的关键文件之一，它提供了基于项目的干系人关于项目范围的通用理解;
10. 10、项目范围说明书有助于定义、制定和制约项目以及产品的范围;它使用来自项目章程以及干系人需求的信息，并对那些信息渐进明细，从而能够定义可交付成果、项目例外事项以及验收标准;
11. 11、项目范围说明书应至少包括以下信息：产品范围描述、项目可交付成果、产品验收标准、项目的除外责任、项目制约因素、项目假设条件;
12. 12、WBS用于分解项目的所有工作，开始于项目分层，成功地把项目细分成更小的层次;最底层的是工作包，工作包代表可交付成果，它被分解成产生可交付成果的活动;
13. 13、项目需求将决定进行WBS的方法，第二层决定了WBS的组织方式;
14. 14、组织和安排WBS的方法包括：地理位置、主要可交付成果、生命周期、子项目;
15. 15、控制账户：范围、进度和成本的整合，用于测量项目绩效;每个工作包指向有且仅有一个控制账户;
16. 16、WBS词典通过提供有关工作包和包含工作包的控制账户的详细信息，对工作分解结构(WBS)提供支持;
17. 17、WBS词典的信息可以包括：账户标志代码、工作描述、假设条件和制约因素、责任组织或责任人、里程碑清单、进度活动清单、资源需求、成本估算、质量需求、验收标准、技术信息或参考、协议(合同)信息;
18. 18、项目绩效报告由项目经理填写并定期提交给项目发起人、项目组合经理、项目管理办公室，或其他项目负责人或小组;项目绩效报告跟踪当前报告阶段的进度和成本状态，并提供下一报告阶段的计划信息，它说明对里程碑和成本储备的影响，以及识别在当前报告阶段正在显现的新风险和问题;
19. 19、项目绩效报告包括：当前报告阶段已经完成的工作、当前报告阶段计划完成但没有完成的工作、 产生偏差的根本原因、对即将要完成的里程碑或项目到期日的影响、计划的纠正或预防措施、当前报告阶段已花费的资金、产生偏差的根本原因、对整个预算或应急储备的影响、计划的纠正或预防措施、下一报告阶段的工作、下一报告阶段计划的成本、识别的新风险、问题、说明;
20. 20、偏差分析报告收集和评估项目绩效偏差的信息，通常包括进度、成本和质量偏差;
21. 21、偏差分析报告包括：进度偏差(计划结果、实际结果、偏差、根本原因、计划的应对措施)、成本偏差(计划结果、实际结果、偏差、根本原因、计划的应对措施)、质量偏差(计划结果、实际结果、偏差、根本原因、计划的应对措施);

7，进度（ 时间）管理：计算题

【问题1】可以用什么方法和技术来估算项目的工期

（1）明确定义项目的工作分解结构（WBS）。

（2）由于是升级项目，所以部分工作的工期估计方法可以采用类比估算法。

（3）对于新增的移动接入模块，可以联系业界专家，采用德尔菲法进行估算。

（4）对于WBS进行足够细化后，可依据历史数据采用参数估算或三点估算进行进一步历时估算。

影响进度的主要因素
①人的因素，
③方法 、 技术、经验、能力的因素，
②材料、设备的因素
③资金因素， 
⑤环境因素．

进度万金油：

项目经理经验不足， 进度估算不准确（出现几率100%，其他管理也可以套用）
项目资源配直不足或者配置不合理（或人力， 或物〉
注：记忆方式是人才（材） 有技术但缺钱发展是社会环境造成的。

(1)  团队成员没有及早参与， 需求分析耗时长， 要早期参与进项目
(2）经验不足， 进度计划制定不准，采取有效的历时估算方法和网络计划技术， 制定 进度
(3）考虑项目期间特定时期会对进度产生影响
(4）增加人手， 聘请史有经验的人员 ，或找兼职人员
(5）加班
(6）并行
(7）重新估算后面的工期
(8）加强沟通， 减少变史
(9）加强控制， 避免返工
(10）外包
(11) 加强沟通， 先完成关键需求
(12）增加资源有时可能 压缩工期有限
(13）关注关键路径， 在关键路径上加资源， 有效果
( 14）关注里程碑
(15）加强 进度与成本、 风险、 质量等知识点的协调

【问题2】加快进度、 压缩工期方法

 

1、赶工。加班 赶工 

2、快速跟进；然后可以加大并行工作的程度。将部分阶段的工作改为并行 ，并进行内部流程的优化

3、使用经验丰富的员工、向公司申请增加资源， 增加优质资源；

4、改进方法技术，提高效率

5、明确目标、责任和奖惩机制，提高员工的工作绩效。

6、与客户进行沟通，梳理业务需求中的关键需求，与客户进行协商能否在期限前先完成关键需求，其他部分分期交付。

7、与客户进行沟通，外包和缩小项目范围

8、加强对支付物、 项目阶段工作的及时检查和控制， 避免后期出现返工。

加强质量管理，及时发现问题，减少返工，从而缩短工期

 变更原来的进反计划。根据上一阶段的绩效， 对后续工作重新评估，修订计划， 并征得项目干系人的同意 

在工期压缩过程中妥注意加强与项目干系人的沟通。 
①与客户进行沟通确 定能否缩小范围和外包 ，以应对强制性日翔的支付；
③与项目成员沟通， 制定好的绩效考核办法 ，提高每个成员的绩效 ；
④与职能经理及高层领导沟通， 申请增加优质资源等。

【问题3】采用哪些方法来跟踪项目的进度，以确保项目能够按期交付

（1）基于WBS和工时估算制定活动网络图，制定项目工作计划。

（2）建立对项目工作的监督和测量机制。
（3）确定项目的里程碑，并建立有效的评审机制。

（4）对项目中发现的问题，及时采取纠正和预防措施，并进行有效变更管理。

（5）使用有效的项目管理工具，提升项目管理的工作效率。

8， 成本管理    

9、质量管理 

【问题1】项目质量管理可能问题：

质量管理计划     
1、缺乏整体的项目管理经验，经验不足
1、因其他项目而未对本项目投入足够的精力，身兼数职
2、有制定可行的质量管理计划作为指导并积极实施；质量标准，质量目标、质量测量指标
质量保证 
5、没有建立质量保证体系
5、质量保证过程中缺乏QA的参与
5、质量保证工具质量审计，识别分享协助积累确认，识别问题，解决方案，改善建议
3、没有全面的质量管理进展情况质量报告：
3、产出的各类质量文档，未经过评审 
质量控制
6、质量控制环节缺失，例如评审和测试
6、质量控制做的不到位，测试方法不当或不充分，测试指标，测试标准，粒度不一样
6、测试控制的流程不对， 或未进行质量控制就进行了范围确认。
3、仅向用户提交测试报告,而没有提交全面质量管理进展情况的报告
沟通管理
4、沟通方式单一（或不全面）， 容易误导用户， 致用户不必要的担心
团队管理
4、缺少对项目质量管理工作的监督指导
4、团队成员对质量意识步骤，培训不足

【问题2】项目质量管理计划应该包括哪些内容？
1、质量职责与人员分工（或职责）；
2、程序与过程（或项目的各个过程及其依据的标准）；
3、质量保证的方法、重点
4、质量控制的方法、工具与重点
5、质量管理所需的资源；
6、质量标准。

【问题3】质量计划可采用的工具和技术
效益成本分析、基准比较、流程图、实验设计、质量成本分析等

【问题3】应该怎么解决？
1、建立项目质量目标和质量改进计划；                                                                                                                                        
2、制定质量管理计划：
2、建立工作中的质量保证和质量控制规范；体系；
2、严格执行公司的质量管理体系规范工作流程；

如何实施项目的质量保证？实施质量保证的方法：QA应该做哪些

1. 制定质量标准； 计划阶段制定质量管理计划和相应的质量标准
2. 执行质量保证计划；执行项目的质量管理计划；按计划实施质量检查， 是否按标准过程实施项目工作。 
3. 采用质量保证的工具和技术：如编制质量计划时所采用的工具和技术、质量审计、过程分析和基准分析等。
4. 建立质量保障体系。提出相应质量整改措施，如建议的纠正措施、对项目计划可能的更新、对组织资产可能的更新、变更请求。
5. 检查的情况和记录， 分析问题， 发现问题， 与当事人协商进行解决。 
6. 问题解决后要进行验证；如果无法与当事人达成一致， 应报告项目经理或更高层领导， 直至问题解决，
7. 定期给项目干系人发质量报告
8. 为项目组成员提供质量管理要求方面的培训或指导

质量控制过程的基本步骤？质量控制应做好以下几方面内容：

1. 建立质量管理体系和相关的标准及规范
2. 制定实施计划；选择质量控制的对象，制定控制的标准；做好相关文档工作；
3. 对项目实施的结果进行检查，并将检查结果与预定的标准比对；质量控制测量结果，形成测试报告
4. 发现偏差并分析原因，采取措施纠偏，对质量问题的出现次数和影响程度依次进行分析，找出原因并提出改进措施；
5. 在项目中对过程和产品进行测量/检查，将实际情况与目标和规范进行对比以发现质量问题，并对质量问题的处理进行监督和控制；
6. 对维护工作进行质量控制， 做好相关文档工作；测试报告
7. 在有条件情况下， 开始对已交付系统进行文挡建设， 尤其是用户手册的建设工作；
8. 取得高层领导的支持和信任，开展整体质量控制观念的培养，在以后工作中实施严格的质量控制工作。
9. 调配相关资源、（人、 财、 物等）加强后续质量保证工作；
10. 加强后期的质量控制和测试； 
11. 提前加强产品支付后的客户服务和维护工作；
12. 加强沟通；
13. 建议必妥时修改质量基准争取以最小的代价获得用户认可。
14. 

【问题4】质量控制与质量保证的区别与联系：

1. 质量计划是质量控制与质量保证的共同依据；
2. 达到质量要求是质量控制与质量保证的共同目的；
3. 质量保证的输出时下一阶段质量控制的输入。
4. 一定时间内质量控制的结果也是质量保证的质量审计对象。质量保证的成果又可以指导下一阶段的质量工作（包括质量控制和质量改进）。
5. 质量保证一般是每隔一定时间如阶段末进行的，主要通过系统的质量审计来保证项目的质量（或质量保证是按照质量管理计划正确地做）。按照既定的质量计划来对过程进行追踪，并且还包含质量改进；
6. 质量控制是实时监控项目的具体结果，以判断他们是否符合相关质量标准，并进行不合格情况的追踪。制定有效方案，以消除产生质量问题的原因（或质量控制检查是否做的正确并纠错）。（简羊记忆：质量保证看得是整个项目， 控制是关注各阶段具体可交付 成果， 另外质量保证工具有质量审计跟过程分析， 

10、人力资源管理 ，团队管理，项目经理

3、人力资源管理可能存在的问题

1. （1）项目经理、职能经理，职责不清
2. （2）建设团队、提升绩效
3. （3）管理团队，处理问题(例如冲突处理方式：单一)
4. （4）关注人力资源风险(例如关键路径的可替代资源)

“人机料法环”举例：

1. （1）缺少项目管理经验、团队领导经验(缺乏领导经验、事必躬亲)
2. （2）技术骨干不一定合适
3. （3）公司重视不够、缺乏培训
4. （4）缺乏沟通能力与技巧、人际关系技能、冲突管理
5. （5）奖惩制度不合理、缺乏绩效评估体系

【问题1】项目中出现这些情况的可能原因，项目失控的可能原因。

1. 项目经理的选择上。李某缺乏担任项目经理所需的足够的能力和经验。开发人员要胜任项目经理岗位，不仅需要技术背景、行业知识，还需要具备一定的管理知识和经验。普通技术人员，未经培训和考查就直接任命为项目经理，在实际工作中，很可能会出现问题。
2. 身兼数职， 精力和时间不够用， 颇此失彼；职责不清
3. 自身角色思想态度转变。没有进入管理角邑， 定位错误，只关注于编程工作， 疏于对项目的管理；
4. 公司对项目经理的培养不重视、对项目经理的选拔任命不规范。
5. 章某对李某的帮带做得不够、或不到位。缺乏事先培训
6. 公司对项目经理的工作缺乏指导和监督。培训和全程的跟踪和监控；
7. 没有进行良好的冲突管理。 
8. 项目工作中的沟通没有建立有效的沟通机制和方式方法。
9. 缺乏有效的项目绩效管理机制。
10. （1）项目经理、职能经理，职责不清
11. （2）建设团队、提升绩效
12. （3）管理团队，处理问题(例如冲突处理方式：单一)
13. （4）关注人力资源风险(例如关键路径的可替代资源)

【问题2】怎么做，高级项目经理章某应该如何指导和帮助李某

1. 事先制定岗位的要求、职责和选人的标准，并选择合适的人选担任子项目的项目经理。；
2. 由于企业人才紧缺，找不到合适的人选，要委任程序员小张担任项目经理，则需要对小张进行岗前培训。
3. 对工作进行全面估算，避免负荷过重， 解决好负载平衡问题。如果有人负荷过重，需要找人代替 xx正在从事的技术工作，，确保项目经理的工作都能完成。
4. 培养和监控；  
5. 章某应明确李某的工作职责，明确轻重缓急，帮助其实现向项目经理角色的转变。让小张放弃编程工作，专心从事管理工作，学习管理知识。
6. 参加小李组织的周例会，以及时发现问题，并予以指导。
7. 对李某提供相关工作的指导或培训，尤其是在项目管理方面。
8. 从整体项目层面对各子项目进行计划和协调，对子项目提出具体的工作要求。
9. 加强对子项目的日常监管，要项目经理以身作则。
10. 上级应该注意平时对人员的培养和监控。以便及时发现问题，避免项目失控。
11. 针对子项目中出现的问题，及时提出纠正和预防措施。
12. 对项目团队进行有效的冲突管理。  

、采用虚拟团队形式的利弊

1)优点：

1. (1)在组织内部地处不同地理位置的员工之间组建团队;
2. (2)将在家办公的员工纳入团队;
3. (3)为项目团队增加特殊技能，即使相应的专家不在同一地理区域;
4. (4)在工作班次、工作小时或工作日不同的员工之间组建团队;
5. (5)将行动不便者或残疾人纳入团队;
6. (6)执行那些原本会因差旅费用过高而被否决的项目;

2)缺点：

1. (1)可能产生误解，有孤立感;
2. (2)团队成员之间难以分享知识和经验;
3. (3)采用通信技术的成本;

 冲突产生的原因： 项目的高压环境、 责任模糊、 多个上级的存在、 新科技的流行。
,/ 冲突管理策略：

五种常用的冲突解决方法：

1. 撤退/回避：从冲突中退出，推迟，推给他人。
2. 缓和/包容：强调一致而非差异；考虑其他方的需要。
3. 妥协/调解：部分解决问题，一定程度上满意。
4. 强迫/命令：推行一方观点；通常通过权力强行解决紧急问题。
5. 合作/解决：综合考虑不同的观点，合作的态度和开放式对话达成共识

 如何对待项目中出现的冲突？

① 运用冲突解决办法正确解决双方冲突；
① 项目角色职责是否制定合理；
② 妥与项目组成员有良好的沟通， 妥听取各方面意见和建议。
④ 和团队成员增强沟通和交流， 获得团队成员的信任；
③ 冲突发生后妥及时解决， 如果处理失败妥及时上报， 不能力口入
② 提高自己的技术能力， 行使专家权力说服冲突双方， 获得双方信任；
③ 对消极怠工员工行使强制力让其努力工作；
④ 因冲突发生， 导致消极怠工， 要行使强制力。
⑤ 跟踪个人和固队的执行情况 及时反馈和协调变更：
⑥ 如果造成人员流失， 妥做好站补工作， 提前预防人员流失。
⑥ 实行奖励制度以激励团队。

【问题3】项目经理要承担哪些角色？ 具备哪些知识与技能？

1. 作为一名项目经理，要同时承担项目管理者和项目领导者的角色，这些角色的工作包括了项目的计划、组织、协调、领导和控制。
2. 项目经理应同时具备管理能力和一定的专业技能，包括：项目管理知识、IT知识、客户行业知识，丰富的经历与经验，良好的协调能力，良好的职业道德，良好的沟通与表达能力，良好的领导能力。

【问题3】要求考生回答，典型的系统集成项目团队的角色构成，以及在组建项目团队、建设项目团队和管理项目团队方面所需的活动。

1．针对选定的项目，根据项目的特点，需要的角色：

1. 管理类（如，项目经理）；
2. 工程类（如，系统分析师、架构设计师、软件设计师、程序员、测试工程师、美工、网络工程师、主机人员、实施人员）；
3. 行业专家；
4. 辅助类（如，文档管理员、秘书）。

2．结合实际项目，叙述进行如下活动的经验：

（1）组建项目团队，明确责任（制订责任分配矩阵）。

（2）建设项目团队。

1. 提高项目团队成员的个人绩效；
2. 提高项目团队成员之间的信任感和凝聚力，以通过更好的团队合作提高工作效率。

（3）管理项目团队。

1. 跟踪个人和团队的执行情况、提供反馈；
2. 协调变更，以提高项目的绩效、保证项目的进度；
3. 项目管理团队还必须注意团队的行为、管理冲突、解决问题；
4. 评估团队成员的绩效。

11、采购和合同管理

制定采购计划
采购策略：支付方式，合同支付类型
招标文件：邀请书（报价、建议、信息）
采购工作说明书
供方选择标准:如何选出来的，评分标准和评价准则是什么？资质、成本、质量、技术方案得分。预先批准的买房清单
制定询价计划
 
以上的采购文档
卖方建议书
广告、招标人会议、专家判断
选定卖方
协议
谈判
实际询价

索赔管理
数据分析：绩效审查、挣值分析、趋势分析
检查，审计

合同管理
合同收尾
采购总结 

14，合同管理项目验收 （合同管理、项目管理控制和项目沟通的实施方法。）

假设某项目的主要工作已经基本完成，经核对项目的"未完成任务清单"后，终于可以提交客户方代表老刘验收了。在验收过程中，老刘提出了一些小问题。项目经理张斌带领团队很快妥善解决了这些问题。但是随着时间的推移，客户的问题似乎不断。时间已经超过了系统试用期，但是客户仍然提出一些小问题，而有些问题都是客户方曾经提出过，并实际上已经解决了的问题。时间一天一天的过去，张斌不知道什么时候项目才能验收，才能结项，才能得到最后一批款项。

【问题1】分析发生这件事情可能的原因？

【问题2】说明现在张斌应该怎么办？

【问题3】说明应当吸取的经验和教训？ 

【问题1】发生这件事情可能的原因。

（1）合同中缺乏以下内容：

项目目标中关于产品功能和交付物组成的清晰描述。
项目验收标准（规定哪些工作必须完成、完成到什么程度、交付哪些产品（项目的交付物）等）、
验收步骤和方法（或流程）（验收时具体按何流程进行操作，包括何时提供验收、验收表格、验收人员、验收步骤、验收有关问题的处理）。

（2）项目实施过程控制中出现的问题：

在项目实施过程中没有及时将项目绩效报告递交给客户，因此客户对项目进展和质量状况不了解。

没有让客户及时对阶段成果签字确认。

（2）项目的变更管理可能做得不好，变更未以书面形式提出申请。

（3）由于没有售货服务的承诺，客户担心没有后续服务保证。老刘对项目质量如何心里没底，在故意拖延时间。

（4）还可能存在双方的沟通问题。客户代表老刘不断提出相同的问题，这说明项目经理张斌对于老刘所需信息的传递不够或者有误，客户获得的信息不全或不及时。

（4）合作氛围不良，客户存在某种程度的抵触情绪，双方缺乏信任感，客户对项目质量信心不足，怕承担责任，因此不愿签字。

【问题2】根据项目现状，需要采取补救措施，加强沟通以解决问题。

（1）就项目验收标准和客户达成共识，确定哪些主要工作完成即可通过验收。

（2）就项目验收步骤和方法与客户达成共识。通过签订补充合同跟客户签订一个详细的验收计划等方式，将验收标准、流程规定清楚，双方需要签字确认。

（3）就项目已经完成的程度让用户确认。例如出具系统测试作报告，请客户签字确认。
如果没有完善的文档，则需尽快完善文档。将阶段性验收的结果、变更的结果、试运行的报告等作详细记录，逐一让客户签字确认。

（4）向客户提出明确的服务承诺，使客户没有后顾之忧。

（4）进一步做好沟通工作。除了把项目文档发送给有关项目干系人外，项目经理张斌需要跟客户代表老刘多进行非正式的沟通，解除其中可能存在的疙瘩，让老刘了解项目的进展，了解主要工作已经完成，并理解项目结项对张斌的重要性，达成理解和融洽的关系。

【问题3】要求考生说明应当吸取的经验和教训。

（1）合同管理方面。
项目合同中要规定项目成果的正式验收标准、验收步骤、验收流程和运营维护服务承诺等内容。

（2）加强项目执行过程中的控制。加强变更控制
在信息系统集成项目中，变更是很频繁的，也是很正常的，关键的是要制订和执行一个完善的变更控制流程。
包括制定变更控制流程，按流程进行变更的评估、审核、实施、记录、确认等工作。
在项目活动过程中，文档要齐全，使项目进展有据可查。
加强项目配置管理，设置项目里程碑，进行阶段性验收，并要求客户签字确认。

（3）沟通方面。加强项目沟通管理。
在项目计划编制阶段制订一份详尽的项目沟通计划，并按其执行。
包括及时向客户提供项目绩效报告，让客户了解项目进展，让项目干系人了解项目的进展情况。如果发生变更，则要及时把信息提供给项目干系人。
设置对阶段性成果的验收，并让客户对阶段性成果进行签字确认；
项目文档要齐全，使项目进展有据可查。

加强计划执行的控制。制订详尽的项目管理计划（包括进度管理计划、成本管理计划等各分项计划），按计划实施和检查。

（3）营造良好的客户关系。
项目经理还应注重跟客户相处的技巧，努力促成双方的良好合作氛围。项目经理要经常与客户方进行非正式的沟通，需要营造良好的客户关系，让客户成为自己真正的和长期的朋友。

2.4 项目整体管理体系

项目章程：
1 项目理由，需求，干系人期望 
2 目标，论证结果，成功标准
3 项目描述或产品描述
4 总体要求，总体范围和质量要求
5 风险，风险类别
6 进度计划和里程碑
7 总体预算
8 审批要求，规划执行监控收尾，谁做出那种批准
9 任命项目经理和职责职权授权
10 干系人

所使用的管理过程
每个过程的实施程度
工具和技术
生命周期和阶段
过程，管理项目
执行，完成目标
监督和控制
变更控制，申请审批，批准的实施
配置管理
项目绩效考核
关系人沟通

项目管理计划的主要用途有：

(1)指导项目执行、监控和收尾。

(2)为项目绩效考核和项目控制提供基准。

(3)记录制订项目计划所依据的假设条件。

(4)记录制订项目计划过程中的有关方案选择

(5)促进项目干系人之间的沟通。

(6)规定管理层审查项目的时间、内容和方式。

项目管理计划制订的步骤：

(1)各具体知识领域制订各自的分项计划

(2)整体管理知识领域收集各分项计划，整合成项目管理计划

(3)用项目管理计划指导项目的执行和监控工作，并在执行过程中监控

(4)对提出的必要的变更请求，报实施整体变更控制过程审批。

(5)根据经批准的变更请求，更新项目管理计划

某公司是一家中小型系统集成公司，在2006年3月份正在准备对京发证券公司数据大集中项目进行投标，某公司副总裁张某授权销售部的林某为本次投标的负责人，来组织和管理整个投标过程。

林某接到任务后，召集了由公司商务部、销售部、客服部和质管部等相关部门参加的启动说明会，并把各自的分工和进度计划进行了部署。

随后，在投标前3天进行投标文件评审时，发现技术方案中所配置的设备在以前的项目使用中是存在问题的，必须更换，随后修改了技术方案。最后某公司中标并和客户签订了合同。根据公司的项目管理流程，林某把项目移交到了实施部门，由他们具体负责项目的执行与验收。

实施部门接手项目后，鲍某被任命为实施项目经理，负责项目的实施和验收工作。鲍某发现由于项目前期自己没有介入，许多项目前期的事情都不是很清楚，而导致后续跟进速度较慢，影响项目的进度。同时鲍某还发现设计方案中尚存在一些问题，主要有：方案遗漏一项基本需求，有多项无效需求，没有书面的需求调研报告；在项目的工期、系统功能和售后服务等方面，存在过度承诺现象。于是项目组重新调研用户需求，编制设计方案，这就增加了实施难度和成本。可是后来又发现采购部仍是按照最初的方案采购设备，导致设备中的模块配置功能不符合要求的情况。

而在希赛集成公司中，类似现象已多次发生。

【问题1】针对说明中所描述的现象，分析某公司在项目管理方面存在的问题（200字以内）。

【问题2】针对某公司在该项目管理方面存在的问题，提出补救措施（300字以内）。

【问题3】针对某公司的项目管理现状，结合你的实际经验，就某公司项目管理工作的持续改进提出意见和建议（300字以内）。
例题4分析

本案例是一道综合题，主要考查考生对项目组织结构、项目管理流程等方面存在的问题进行分析的能力，并针对问题提出相应改进的建议。

在回答问题之前，应仔细审题，以明了题目要求。

【问题1】要求分析某公司在项目管理方面存在的问题，这可以通过阅读试题的说明而得到。如依次读试题一的第1段、第2段和第3段内容，可知某公司整体上是职能型组织，分售前（投标）和售后（实施）。销售部的林某作为投标的负责人没有邀请后续的实施部门参与投标活动，仅仅在中标后作了简单移交，在这一环节就容易出问题。另外以前的技术方案中出现的问题设备在本次投标文件中重复出现，说明某公司在项目管理的经验教训的传承和传播上是不重视的，缺乏组织方面和方法方面的有效保证。接着读案例的第4段、第5段乃至全篇，就会不禁发问：一个有过度承诺的方案，是怎样提交出去的呢？某公司有相应的评审和批准程序吗？如果有，是否适当？如果适当，执行得如何?既然项目组重新编制了设计方案，这就意味着发生了重要变更，而采购部门的采购方案为什么没有做相应变更呢？另外，类似错误在某公司屡有发生，也要分析：某公司对过去发生的类似经验教训是否有文档记载？
如果有，那么，某公司关于对该类文档的了解和使用的规定是怎样的？执行得又如何？

在【问题1】找出问题之后，自

然地在【问题2】中就可以有针对性地提出补救措施了。

由于企业的不同、所从事的行业的不同、项目规模和复杂程度的不同，要回答【问题3】，应主要针对某公司的项目管理现状，再结合考生自己的实际经验，就可以对某公司项目管理工作的持续改进全面地、系统地提出意见和建议。
例题4解答要点

【问题1】

（1）投标前的项目内部启动会上，没有邀请技术或实施部门。

（2）没有把以往的经验教训收集、归纳和积累。

（3）没有建立完善的内部评审机制，或虽有评审机制但未有效执行。

（4）项目中没有实行有效的变更管理。

（5）公司级的项目管理体系不健全，或执行得不好。

【问题2】

（1）改进项目的组织形式，明确项目团队和职能部门之间的协作关系和工作程序。

（2）做好项目当前的经验教训收集、归纳工作。

（3）明确项目工作的交付物，建立和实施项目的质量评审机制。

（4）建立项目的变更管理机制，识别变更中的利益相关方并加强沟通。
（5）加强对项目团队成员和相关人员的项目管理培训。

【问题3】

（1）建立企业级的项目管理体系和工作规范。

（2）加强对项目工作记录的管理。

（3）加强项目质量管理和相应的评审制度。

（4）加强项目经验教训的收集、归纳、积累和分享工作。

（5）引入合适的项目管理工具平台，提升项目管理工作效率。

2.8 项目组织形式

某系统集成商B最近正在争取某钢铁公司A的办公网络迁移到外地的项目。李某是系统集成商B负责捕捉项目机会的销售经理，鲍某是系统集成商B负责实施的项目经理。由于以往项目销售经理的过度承诺给后继的实施工作带来了很大困难，此次鲍某主动为该项目做售前支持。该办公网络迁移项目的工作包括钢铁公司A新办公楼的综合布线、局域网网络系统升级、机房建设、远程视频会议系统、生产现场的闭路监控系统等5个子系统。钢铁公司A对该项目的招标工作在2006年8月4日开始。该项目要求在2006年12月29日完成，否则将严重影响钢铁公司A的业务。

时间已到2006年8月8日，钢铁公司A希望系统集成商B能在8月15日前能够提交项目建议书。钢铁公司A对项目的进度非常关注，这是他们选择集成商的重要指标之一。根据经验、钢铁公司A的实际情况和现有的资源，鲍某组织制定了一个初步的项目计划，通过对该计划中项目进度的分析预测，鲍某认为按正常流程很难达到客户对进度的要求。拟订的合同中将规定对进度的延误要处以罚款。但是销售经理李某则急于赢得合同，希望能在项目建议书中对客户做出明确的进度保证，首先赢得合同再说。鲍某和李某在对项目进度承诺的问题上产生了分歧，李某认为鲍某不帮助销售拿合同，鲍某认为李某乱承诺对以后的项目实施
不负责任。本着支持销售的原则，鲍某采取了多种措施，组织制订了一个切实可行的进度计划，虽然其报价比竞争对手略高，但评标委员会认为该方案有保证，是可行的，于是系统集成商B中标。系统集成商B中标后，由其实施部负责项目的实施。

【问题1】

在制订进度计划时，鲍某可能会采取哪些措施使制订的进度计划满足客户的要求？

【问题2】

实施项目的系统集成商B目前的组织类型是什么？如何改进其项目的组织方式？如何改进其项目管理的流程？如何降低管理外地项目的成本？

【问题3】

在项目实施过程中，负责售前工作的李某应继续承担哪些工作？
试题8分析

【问题1】

案例的背景"钢铁公司A对项目的进度非常关注"和"按正常流程很难达到客户对进度的要求"，现在试题问的是"在制订进度计划时，鲍某可能会采取哪些措施使制订的进度计划满足客户的要求"。也就是说，在现有资源受限的情况下，如果按照正常流程安排进度，是肯定不能满足用户的进度要求的，因此，必须采取一些压缩项目工期的方法，包括增加工作的并行度（赶工）、缩短工作历时、增加资源或提高资源资源率（加班）、外包等。

【问题2】

从试题介绍来看，"李某是系统集成商B负责捕捉项目机会的销售经理，鲍某是系统集成商B负责实施的项目经理"，以及后面关于李某和鲍某的争执，可以看出系统集成商B实施项目的组织方式是职能式的。职能式项目组织结构有很多不好的地方，例如，在各部门之间的协调就存在问题，正如本题案例所描述的情况，这是职能式项目组织的一个通病。因此，系统集成商B实施项目的组织方式应该改进为矩阵式结构。项目下一个阶段的人员要提前介入到前一个阶段，例如，实施阶段的项目经理正式参与售前工作。也可以选择做好各流程间交接工作，例如，实施与售后服务之间的技术交底。

本项目是一个外地项目，那么如何降低管理外地项目的成本呢？与本地实施项目相比，外地实施项目需要增加人员差旅费、通信费，以及管理成本。因此，为了降低成本，可以委托或分包给当地有相应资质的集成商，或在当地招人。如果材料或服务在当地获得可降低成本，则尽量在当地采购。另外，要尽量压缩人员差旅成本，使用QQ、MSN、E-mail等电子沟通手段，以降低通信成本。

【问题3】

由于在项目实施以前，一直都是负责售前工作的李某与客户联系，而且，也是由于李某"急于赢得合同，希望能在项目建议书中对客户做出明确的进度保证"，导致整个项目进度难以安排。鲍某本着支持销售的原则，采取了多种措施，组织制订了一个切实可行的进度计划，但该计划的执行需要一些资源的支持，也需要客户的支持。因此，需要李某继续与客户高层沟通，了解客户对项目实施情况的反映，维护客户关系。同时，也可能会发掘一些新的项目机会。

作为内部来说，为了便于与客户沟通，李某应该参加周例会，或至少每周收一次周报以了解项目的进展和问题，要参与可能发生变更的前期评审工作。最后，在项目收尾时，李某要负责或者协助收款。
例题8解答要点

【问题1】

（1）沟通。强调该项目对系统集成商B的意义，提高该项目优先级。例如开会这种方式，争得相关部门建议、支持与承诺。

（2）从现有的资源和实际情况出发，优化网络图，例如重排活动之间顺序，压缩关键路径长度。

（3）增加资源，或者使用经验丰富的员工。

（4）子任务并行、内部流程优化。

（5）尽可能地调配非关键路径上的资源到关键路径上的任务。

（6）优化外包、采购等环节并全程监控。

【问题2】

（1）目前系统集成商B实施项目的组织方式是职能式的。

（2）系统集成商B实施项目的组织方式应该改进为矩阵式。

（3）项目下阶段人员提前介入到前一阶段，如实施阶段的项目经理正式参与售前工作。也可选择做好各流程间交接工作，如实施与售后服务之间的技术交底。

（4）委托、分包给当地有相应资质的集成商，或在当地招人。如果材料或服务在当地获得可降低成本，则尽量在当地采购。尽量压缩人员差旅成本。使用虚拟远程的沟通手段。

【问题3】

（1）与客户高层继续沟通，了解客户对项目实施情况的反映，维护客户关系，发掘新的项目机会。

（2）参加周例会，或至少每周收一次周报以了解项目的进展和问题。

（3）参与可能发生变更的前期评审工作。

（4）负责或者协助收款。

2.2 变更管理 

【问题1】存在的主要问题有：

（1）对用户的要求未进行记录；
任何变更申请都必须以书面的形式提出。缺乏对变更请求的记录可能会导致对产品的变更历史无法追溯，并会导致对工作产物的整体变化情况失去把握。

（2）对变更请求未进行足够的分析，没有分析和评估用户变更请求。也没有获得批准；
开发人员在获得用户的变更请求后，分析可能会导致后期的变更工作出现工作缺失、与其他工作不一致等问题，对项目的进度、成本、质量方面也会产生一定影响

（2）提交给CCB审批 。在得到CCB的批准后，才能开始实施变更。

（3）在修改过程中没有注意进行版本管理；（更新文档）
开发人员直接对系统软件进行修改，没有进行任何配置管理工作，可能会导致当变更失败时无法进行复原，造成成本损耗和进度拖延；

（4）修改完成后未进行验证；

所以对软件修改后，一定要进行验证测试。确认变更是否正确实现，为变更付出的工作量也无法得到承认。

（5）修改的内容未和项目干系人进行沟通。
由于变更请求是由"一个系统的用户"提出的，这种请求不一定合理，不一定在项目范围之内。一个配置项出现变更，可能会涉及到一些相关的部件和文档进行变更，这将影响到项目开发工作中的许多人员，所以需要和项目干系人沟通。可能会导致项目干系人的工作之间出现不一致之处，进而影响项目的整体质量。

【问题3】变更管理的基本流程如下：

1. 变更申请。应记录变更的提出人、日期、申请变更的内容等信息。
2. 变更评估。对变更的影响范围、严重程度、经济和技术可行性进行系统分析。
3. 变更决策。提交CCB审批，由具有相应权限的人员或机构决定是否实施变更。
4. 通过后更新 变更日志/项目管理计划 
5. 通知相关方
6. 变更实施。由管理者指定的工作人员在受控状态下实施变更。
7. 变更验证。由配置管理人员或受到变更影响的人对变更结果进行评价，确定变更结果和预期是否相符、相关内容是否进行了更新、工作产物是否符合版本管理的要求。
8. 沟通存档。将变更后的内容通知可能会受到影响的人员，并将变更记录汇总归档。如提出的变更在决策时被否决，其初始记录也应予以保存。
9. 总结经验教训