信息系统项目管理师案例理论及常见问题

一、项目管理概论

1、PMO有支持型、控制型和指令型等3种。

2、PMO的一个主要职能是通过各种方式向项目经理提供支持，包括:①对PMO所辖全部项目的共享资源进行管理;②识别和制定项目管理方法、最佳实践和标准;③指导、辅导、培训 和监督;④通过项目审计，监督项目对项目管理标准、政策、程序和模板的合规性;⑤制定和管理项目政策、程序、模板及其他共享的文件（组织过程资产）；⑥对跨项目的沟通进行协调等。

二、立项管理

1、立项管理常见的问题：
（1）立项中请应由（建设方）甲方（非承建方，即乙方）的上级主管单位，而非甲方总经理批准。
（2）做完初步可以行研究就立马上马。
（3）未做详细可行性研究就生成可行性研究报告
（4）可行性研究报告未经评审
（5）仅根据项目符合国家政策就判断项目肯定要上马，判断依据过于单一
（6）可行性分析的中请金额比中请下来的金额超过了上下10%的浮动，还继续使用，没有重写
（7）可行性分析的中请金额比中请下来的金额没超过了上下10%浮动，但没补充内容
（8）投标由软件工程师负责不合适，缺少相关经验（专人专事）
（9）仅从技术角度分析项目可行不全面，需要综合考虑经济、技术、社会等因素。
（10）投标文件不能单独完成，需要比较有经验的各领域专家共同参与编写
（11）未编写项目建议书
（12）未进行项目评估，或项目评估自己做。
（13）没有进行系统的可行性分析，没有进行多方案比较。
（14）调研不充分，没有调研大规模应用的案例。
（15）没有调研国家政策是否允许。
（16）未进行项目论证

2、项目建议与立项申请、初步可行性研究、详细可行性研究、评估与决策是项目投资前时期的四个阶段。

3、立项申请又称为项目建议书，是项目建设单位向上级主管部门提交项目中请时所必须的文件，提出的某一具体项目的建议文件，是对拟建项目提出的框架性总体设想。项目建议书是项目发展周期的初始阶段，是国家或上级主管部门选择项目的依据，也是可行性研究的依据。涉及利用外资的项目，在项目建议书获得批准后，方可开展后续工作。

4、项目建议书应该包括的核心内容有:①项目的必要性；②项目的市场预测；③项目预期成果（如产品方案或服务）的市场预测;④项目建设必需的条件

5、信息系统项目进行可行性研究包括:技术可行性分析、经济可行性分析、社会效益可行性分析、运行环境可行性分析以及其他方面的可行性分析等。

三、整合管理

1、整合管理常见问题

2、项目章程记录了关于项目和项目预期交付的产品、服务或成果的高层级信息:①项目目的;②可测量的项目目标和相关的成功标准；③高层级需求、高层级项目描述、边界定义以及主要可交付成果;④整体项目风险;⑤总体里程碑进度计划;⑥预先批准的财务资源;⑦关键干系人名单;⑧项目审批要求（例如，评价项目成功的标准，由谁对项目成功下结论，由谁签署项目结束）:⑨项目退出标准（例如，在何种条件下才能关闭或取消项目或阶段）;⑩委派的项目经理及其职责和职权;⑪发起人或其他批准项目章程的人员的姓名和职权等。【口诀:目的目标需求要描述;风险进度财务干系人要审批;退出两个职权】

3、项目管理计划组件主要包括：
♦  子管理计划:范围管理计划、需求管理计划、进度管理计划、成本管理计划、质量管理计划、资源管理计划、沟通管理计划、风险管理计划、采购管理计划、干系人参与计划。
♦  基准 :范围基准、进度基准和成本基准。
♦  其他组件:变更管理计划、配置管理计划、绩效测量基准、项目生命周期、开发方法、管理审查。

4、配置管理活动 包括:识别配置项、记录并报告配置项状态、进行配置项核实与审计

5、结束项目或阶段过程所需执行的活动包括：
♦  为达到阶段或项目的完工或退出标准所必须的行动和活动；
♦  为关闭项目合同协议或项目阶段合同协议所必须开展的活动；
♦  为完成收集项目或阶段记录、审计项目成败、管理知识分享和传递、总结经验教训、存档项目信息以供组织未来使用等工作所必须开展的活动；
♦  为向下一个阶段，或者向生产和（或）运营部门移交项目的产品、服务或成果所必须开展的行动和活动；
♦  收集关于改进或更新组织政策和程序的建议，并将它们发送给相应的组织部门；
♦  测量干系人的满意程度等。

四、范围管理

1、范围管理常见问题

2、需求方面的问题：
（1）对客户（或用户）的需求获取不充分
（2）没有按照规范的需求开发与需求管理的流程及内容开展需求工作
（3）缺乏需求定义环节，没有定义出需求规格说明书
（4）缺乏需求验证环节，没有请客户代表一起进行需求评审
（5）没有制定范围和需求管理计划
（6）没有求得干系人对需求的一致理解
（7）没有求得干系人对需求的承诺
（8）没有有效地管理需求变更控制
（9）没有有效维护对需求进行跟踪管理
（10）没有及时识别项目工作与需求之间的不一致性
需求改进措施：
（1）建立需求变更控制策略和需求变更控制流程。
（2）采用多种方式充分获取用户需求并进行详细的需求分析
（3）形成需求规格说明书并与用户进行需求验证（确认）和评审
（4）需求定稿建立基线，以后的需求变更必须走变更控制流程，并及时更新需求规格说明书和需求跟踪矩阵
（5）编写需求跟踪矩阵，需求状态表等文档
（6）在需求规格说明书基础上编制技术方案，并进行评审
（7）定期不定期对项目绩效进行监督检查，找出问题原因并指导团队成员解决

3、范围管理计划用于指导如下过程和相关工作:①制定项目范围说明书;②根据详细项目范围说明书创建WBS;③确定如何审批和维护范围基准;④正式验收已完成的项目可交付成果。

4、需求的类别一般包括：业务需求、干系人需求、解决方案需求、过渡和就绪需求、项目需求、质量需求

5、跟踪需求的内容包括:①业务需要、机会、目的和目标;②项目目标;③项目范围和WBS可交付成果；④产品设计;⑤产品开发；⑥测试策略和测试场景;⑦高层级需求到详细需求等。

6、需求踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态和状态日期。为确保干系人满意，可能需要增加一些补充属性，如稳定性、复杂性和验收标准。

7、详细项目范围说明书内容：产品范围描述、可交付成果、验收标准、项目的除外责任

8、创建WBS的方法多种多样，常用的方法包括自上而下的方法、使用组织特定的指南和使用WBS模板。

9、要把整个项目工作分解为工作包 ，通常需要开展如下活动:
①识别和分析可交付成果及相关工作;
②确定WBS的结构和编排方法;
③自上而下逐层细化分解;
④为WBS组成部分制定和分配标识编码;
⑤核实可交付成果分解的程度是否恰当

10、WBS的结构可以采用多种形式：
（1）以项目生命周期的各阶段作为分解的第二层，把产品和项目可交付成果放在第三层。
（2）以主要可交付成果作为分解的第二层。
（3）纳入由项目团队以外的组织开发的各种较低层次组件（如外包工作）。随后，作为外包工作的一部分，卖方须制定相应的合同WBS。

11、在分解的过程中，应该注意以下8个方面：（分解原则）
（1） WBS必须是面向可交付成果的:项目的目标是提供产品或服务，WBS中的各项工作是为提供可交付的成果服务的。（多次重复循环，软件测试）
（2） WBS必须符合项目的范围：WBS必须包括也仅包括为了完成项目的可交付成果的活动。 100%原则（包含原则）认为，在WBS中，所有下一级的元素之和必须100%代表上一级的元素。
（3） WBS的底层应该支持计划和控制:WBS是项目管理计划和项目范围之间的桥梁，WBS的底层不但要支持项目管理计划，而且要让管理层能够监视和控制项目的进度和预算。
（4） WBS中的元素必须有人负责，而且只有一个人负责。
（5） WBS应控制在4〜6层:如果项目规模比较大，以至于WBS要超过6层，此时，可以使用项目分解结构将大项目分解成子项目，然后针对子项目来做WBSo每个级别的WBS将上一级的一个元素分为4〜7个新元素，同一级元素的大小应该相似。一个工作单元只能从属于某个上层单元，避免交叉从属。
（6） WBS应包括项目管理工作（因为管理是项目具体工作的一部分），也要包括分包出去的工作。
（7） WBS的编制需要所有（主要）项目干系人的参与。
（8） WBS并非是一成不变的:完成了 WBS之后的工作中，仍然有可能需要对WBS进行修改。

12、范围基准 ：是经过批准的范围说明书、WBS和相应的WBS词典，只有通过正式的变更控制程。

13、确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求。控制质量过程通常赶确认范围过程，但二者也可同时进行。

14、干系人关注点的不同

五、进度管理

1、进度管理常见问题

2、缩短活动工期方法
（1）赶工，投入更多的资源或增加工作时间，以缩短关键活动的工期。
（2）快速跟进，并行施工，以缩短关键路径的长度
（3）使用高素质的资源或经验更丰富的人员
（4）减小活动范围或降低活动要求
（5）改进方法或技术，以提高生产效率
（6）加强质量管理，及时发现问题，减少返工，从而缩短工期
【口诀】赶快使减改为加

如果是成本超支，则答下面7-10条（补充）
（7）关注成本超支较严重的工作。
（8）对成本的支出进行细化分析，找出成本超支的原因。
（9）针对不同的成本超支原因，采取对应的措施。例如:减少不必要的工作、优化工作流
程提高效率、削减不必要的资源。
（10）定期对项目的成本绩效进行评估，及时按情况进行调整。

3、确定和整合依赖关系

4、进度压缩技术包括:
♦ 赶工:是通过增加资源，以最小的成本代价来压缩进度工期的一种技术。

赶工的例子包括: 批准加班、增加额外资源或支付加急费用来加快关键路径上的活动。赶工只适用于那些通过增加资源就能缩短持续时间的且位于关键路径上的活动。但赶工并非总是切实可行的，因它可能导致风险和/或成本的增加。

♦ 快速跟进:将正常情况下按顺序进行的活动或阶段改为至少是部分并行开展。

例如，在大楼的建筑图纸尚未全部完成前就开始建地基。快速跟进可能造成返工和风险增加，所以它只适用于能够通过并行活动来缩短关键路径上的项目工期的情况。若进度加快而使用提前量，通常会增加相关活动之间的协调工作,并增加质量风险。还有可能增加项目成本。

5、资源优化
♦ 资源平衡：是为了在资源需求与资源供给之间取得平衡，根据资源制约因素对开始日期和完成日期进行调整的一种技术。如果共享资源或关键资源只在特定时间可用而且数量有限,如一个资源在同一时段内被分配至两个或多个活动，就需要进行资源平衡。也可以为保持资源使用量处于均衡水平而进行资源平衡。资源平衡往往导致关键路径改变。可以用浮动时间平衡资源。
♦ 资源平滑：对进度模型中的活动进行调整，从而使项目资源需求不超过预定的资源限制的一种技术。相对于资源平衡而言，资源平滑不会改变项目的关键路径,完工日期也不会延迟。也就是说，活动只在其自由和总浮动时间内延迟，但资源平滑技术可能无法实现所有资源的优化。

6、进度问题解决方法
进度落后，成本超支可以采取的措施：
（1）用高效人员代替低效人员；
（2）加班或赶工在预防风险的情况下并行施工；
（3）提高资源利用率；
（4）加强、改进沟通，提高效率；
（5）尽可能一次性把事情做对，减少返工。
（6）加强沟通
（6）增强优质资源
（7）外包和缩小项目范围
进度落后，成本节约可以采取的措施：
（1）赶工（例如全体加班方式）加快进度
（2）使用高效资源来替换低效资源加快进度
（3）改进方法，提高工作效率
进度超前，成本超支可以采取的措施：
（1）整个项目需要抽出部分人员以放慢工作进度；
（2）整个项目存在成本超支现象，需要采取控制成本措施；
（3）项目中区分不同的任务，采取不同的成本及进度措施；
（4）必要时调整成本基准。
（5）优化施工方案、提高效率、加强质量管理减少返工、加强沟通，以降低成本；
（6）在确保进度按期完成的基础上，可以降低进度以节约成本；
（7）总结项目进度“提前”的经验，并记录下来，把这经验传播到项目的其他班组，甚至其他 
项目或未来的项目；
进度超前，成本节约可以采取的措施：
（1）抽调部分人员用于其他项目
（2）加强质量控制，密切监控项目
（3）必要时调整计划或基准等方法改进，或者改变相关计划

7、掌握三点估算和完工概率的计算:

图的含义为：
工程在估算工期前后1期间内完工的概率为68%, 
在估算工期前后2期间内完工的概率为95%, 
估算工期前后3期间内完工的概率为99%

六、成本管理

1、成本管理常见的问题:

 2、成本的类型：
（1）可变成本:随着生产量、工作量或时间而变的成本为可变成本。又称变动成本。
（2）固定成本:不随生产量、工作量或时间的变化而变化的非重复成本为固定成本。
（3）直接成本:直接可以归属于项目工作的成本为直接成本。如项目团队差旅费、工资、项目使用的物料及设备使用费（一个项目承担）
（4）间接成本:来自一般管理费用科目或几个项目共同担负的项目成本所分摊给本项目的费用，就形成了项目的间接成本，如税金、额外福利和保卫费用（几个项目分摊）
（5）机会成本:是利用一定的时间或资源生产一种商品时，而失去的利用这些资源生产其他最佳替代品的机会就是机会成本，泛指一切在做出选择后其中一个最大的损失。
（6）沉没成本:是指由于过去的决策已经发生了的，而不能由现在或将来的任何决策改变的成本。沉没成本是一种历史成本，对现有决策而言是不可控成本，会很大程度上影响人们的行为方式与决策，在投资决策时应排除沉没成本的干扰。

3、成本管理主要是计算题，注意和进度的结合。
EV、PV、AC、BAC、CV、SV、EAC、ETC、CPI、SPI
公式：CV=EV-AC,     >0节省;  <0超支; SV=EV-PV,     >0提前;  <0滞后
CPI=EV/AC, >1,节省；<1,超支 SPI=EV/PV, >1,提前；<1,落后
ETC= （BAC-EV）当前偏差被看做是非典型的
ETC= （BAC-EV） /CPI当前偏差被看做是代表未来的典型偏差
EAC=AC+ETC—-衍化为下面两个公式
EAC=AC+BAC-EV当前偏差被看做是非典型的
EAC=AC+ （BAC-EV） /CPI当前偏差被看做是代表未来的典型偏差

4、下图中标示：①SV （进度偏差）;②CV （成本偏差）;③BAC （完工预算）;④VAC （完工偏差） 
⑤项目整体拖延日期;⑥项目当前拖延日期

七、质量管理

1、项目质量管理可能问题:

 2、应该怎么解决或提高项目质量？
（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）提出合理有效的质量整改措施（如建议的纠正措施、对项目计划可能的更新等）

3、质量成本 

4、质量管理计划内容一般包括:①项目采用的质量标准;②项目的质量目标；③质量角色与职责;④需要质量审查的项目可交付成果和过程;⑤为项目规划的质量控制和质量管理活动;⑥项目使用的质量工具;⑦与项目有关的主要程序，例如处理不符合要求的情况、纠正措施程序以及持续改进程序等。
5、管理质量过程执行在项目质量管理计划中所定义的一系列有计划、有系统的行动和过程，有助于:①通过执行有关产品特定方面的设计准则，设计出最优的成熟产品;②建立信心，相信通过质量保证工具和技术（如质量审计和故障分析）可以使未来输出在完工时满足特定的需求和期望;③确保使用质量过程并确保其使用能够满足项目的质量目标;④提高过程和活动的效率与效果，获得更好的成果和绩效并提高干系人的满意度。
6、质量审计目标一般包括:①识别全部正在实施的良好及最佳实践;②识别所有违规做法、差距及不足;③分享所在组织和/或行业中类似项目的良好实践;④积极、主动地提供协助，以改进过程的执行，从而帮助团队提高生产效率;⑤强调每次审计都应对组织经验教训知识库的积累做出贡献等。
7、测试类型：
>  软件测试可能包括单元测试、集成测试、黑盒测试、白盒测试、接口测试、回归测试、α测试等；
>  硬件开发中，测试可能包括环境应力筛选、老化测试、系统测试等。
>  建筑项目中测试可能包括水泥强度测试、混凝土和易性测试，在建筑工地进行的旨在测试硬化混凝土结构的质量无损伤测试，以及土壤试验；
8、规划质量管理过程关注工作需要达到的质量，管理质量则关注管理整个项目期间的质量。控制质量关注工作成果与质量要求的比较，确保结果可接受。
9、质量与等级的区别。质量与等级是两个不同的概念。质量作例如：
（1）一个低等级（功能有限）、高质量（无明显缺陷，用户手册易读）的软件产品，该产品适合一般使用，可以被认可。
（2） 一个高等级（功能繁多）、低质量（有许多缺陷，用户手册杂乱无章）的软件产品，该产品的功能会因质量低劣而无效和/或低效，不会被使用者接受。

八、资源管理

1、资源可能问题:

 2、项目经理的权力有5种来源：

职位权力、惩罚权力、奖励权力来自于组织的授权，专家权力和参照权力来自于管理者自身。对于双重汇报关系和非直接汇报关系人员的管理，项目经理更注重运用奖励权力、专家权力和参照权力,尽量避免使用惩罚权力。

3、优秀团队的建设5个阶段：

4、马斯洛的需要层次理论【底层的4种需求即生理、安全、社会交往、受尊重被认为是基本的需求，而自我实现是最高层次的需求】

5、X理论：【不好】
（1）人天性好逸恶劳，只要有可能就会逃避工作。
（2）人生来就以自我为中心，漠视组织的要求。
（3）人缺乏进取心，逃避责任，甘愿听从指挥，安于现状，没有创造性。
（4）人们通常容易受骗，易受人煽动。
（5）人们天生反对改革。
（6）人的工作动机就是为了获得经济报酬。

（1）人天生并不是好逸恶劳，他们热爱工作，从工作得到满足感和成就感。
（2）外来的控制和处罚对人们实现组织的目标不是一个有效的办法，下属能够自我确定目标，自我指挥和自我控制。
（3）在适当的条件下，人们愿意主动承担责任。
（4）大多数人具有一定的想象力和创造力。
（5）在现代社会中，人们的智慧和潜能只是部分地得到了发挥，如果给予机会，人们喜欢工作，并渴望发挥其才能。

6、资源计划内容：识别资源、获取资源、角色与职责、项目组织图、项目团队资源管理、 培训、团队建设、资源控制、认可计划
7、团队章程包括:团队价值观、沟通指南、决策标准和过程、冲突处理过程、会议指南和团队共识
8、虚拟团队模式使人们有可能:①在组织内部地处不同地理位置的员工之间组建团队;②为项目团队增加特殊技能，即使相应的专家不在同一地理区域;③将在家办公的员工纳入团队;④在工作班次、工作小时或工作日不同的员工之间组建团队;⑤将行动不便者或残疾人纳入团队;⑥执行那些原本会因差旅费用过高而被搁置或取消的项目；⑦节省员工所需的办公室和所有实物设备的开支等。
9、建设项目团队的目标包括:①提高团队成员的知识和技能②提高团队成员之间的信任和认同感;③创建富有生气、凝聚力和协作性的团队文化;④提高团队参与决策的能力。

10、可采用的沟通技术包括：
>  共享门户:共享信息库（如网站、协作软件或内部网）对虚拟项目团队很有帮助。
>  视频会议:一种可有效地与虚拟团队进行沟通的重要技术。
>  音频会议:有助于与虚拟团队建立融洽的相互信任的关系。
>  电子邮件/聊天软件：使用电子邮件和聊天软件定期沟通也是一种有效的方式。
11、5种常用的冲突解决方法：①撤退/回避；②缓和/包容；③妥协/调解；④强迫/命令; ⑤合作/解决问题；

12、控制资源过程关注:①监督资源支出;②及时识别和处理资源缺乏/剩余情况;③确保根据计划和项目需求使用并释放资源;④出现资源相关问题时通知相应干系人;⑤影响可以导致资源使用变更的因素;⑥在变更实际发生时对其进行管理等。
13、多标准决策分析可使用的选择标准包括:可用性、成本、能力、经验、知识、技能、态度、国际因素。

九、沟通管理

1、沟通管理常见问题：

2、沟通方法

3、沟通管理计划内容主要包括:①干系人的沟通需求;②需沟通的信息，包括语言、形式、内容和详细程度;③上报步骤;④发布信息的原因;⑤发布所需信息、确认已收到或作出回应（若适用）的时限和频率;⑥负责沟通相关信息的人员;⑦负责授权保密信息发布的人员;⑧接收信息的人员或群体，包括他们的需要、需求和期望;⑨用于传递信息的方法或技术，如备忘录、电子邮件、新闻稿，或社交媒体;⑩为沟通活动分配的资源，包括时间和预算；⑪随着项目进展（如项目不同阶段干系人社区的变化）而更新与优化沟通管理计划的方法；⑫通用术语表；⑬项目信息流向图、工作流程（可能包含审批程序）、报告清单和会议计划等；⑭来自法律法规、技术、组织政策等的制约因素；⑮关于项目状态会议、项目团队会议、网络会议和电子邮件等的指南和模板；⑯项目网站和项目管理软件
4、沟通渠道的总量为n (n-1)/2,其中，n代表干系人的数量

十、干系人管理

1、干系人管理常见问题：

权力利益方格/权力影响方格

基于干系人的职权级别（权力）、对项目成果的关心程度（利益）、对项目成果的影响能力（影响），或改变项目计划或执行的能力

B区（重点管理、及时汇报一项目的客户和项目经理的主管领导）；
C区（随时告知）；
A区（令其满意）；
D区（化最少的精力来监督他们）；

3、干系人登记册:记录已识别干系人的信息，主要包括：
♦ 身份信息:姓名、组织职位、地点、联系方式，以及在项目中扮演的角色。
♦ 评估信息:主要需求、期望、影响项目成果的潜力，以及干系人最能影响或冲击的项目生命周期阶段。
♦ 干系人分类:用内部或外部，作用、影响、权力或利益，上级、下级、外围或横向，或者项目经理选择的其他分类模型进行分类的结果等。
4、干系人参与度评估矩阵：用于将干系人当前参与水平与期望参与水平进行比较
①不了解型:不知道项目及其潜在影响。
②抵制型:知道项目及其潜在影响，但抵制项目工作或成果可能引发的任何变更。此类干系人不会支持项目工作或项目成果。
③中立型:了解项目，但既不支持, 也不反对。
④支持型:了解项目及其潜在影响, 并且会支持项目工作及其成果。
⑤领导型:了解项目及其潜在影响,而且积极参与以确保项目取得成功。

C代表每个干系人的当前参与水平，而D是项目团队评估出来的、为确保项目成功所必不可少的参与水平（期望的）。应根据每个干系人的当前与期望参与水平的差距，开展必要的沟通，有效引导干系人参与项目。弥合当前与期望参与水平的差距是监督干系人参与中的一项基本工作。

十一、风险管理

1、风险管理中存在常见问题

2、风险的可预测性：已知风险、可预测风险、不可预测风险

3、威胁应对策略

上报、规避、转移、减轻、接受

4、机会应对策略

上报、开拓、分享、提高、接受

5、整体项目风险应对策略

6、风险管理计划内容：①风险管理策略；②方法论；③角色与职责；④资金；⑤时间安排； ⑥风险类别；⑦干系人风险偏好；⑧风险概率和影响；⑨概率和影响矩阵；⑩报告格式；⑪跟踪
7、SWOT分析：对项目的优势、劣势、机会和威胁（简称SWOT）进行逐个检查
8、风险识别阶段风险登记册：已识别风险的清单、潜在风险责任人、潜在风险应对措施清单
9、险识别阶段风险报告内容主要包括：（1）整体项目风险的来源；（2）关于已识别单个项目风险的概述信息。

十二、采购和合同管理

1、采购管理中存在常见问题

2、合同管理常见问题：
（1）没有做好签订合同之前的调查工作，合同签订过于草率
（2）合同没有制定好，缺乏明确清晰的工作说明或更细化的合同条款
（3）没有采取措施，确保合同签约双方对合同条款的一致理解
（4）合同中缺乏相应的纠纷处理条款
（5）对于签订总价合同的风险认识不足
（6）合同中可能未对工期、质量和项目目标等关键问题进行约束
（7）合同中缺少必要的项目需求描述及违约责任约定
（8）合同执行过程中没有做好记录保存工作（或合同档案管理不规范）
（9）缺少事先约定的合同变更流程。
（10）合同中对项目的维护和保养责任约定不明确，应当明确约定项目的维护责任、期限及相关费用的支付方式
（11）合同中对合同履行地没有详细的约定，应当明确约定合同履行地
（12）合同条款不严谨，没有就产品的型号、质量等进行严格的约定，合同中的付款条件没有产品质量验收的约束，缺少对合同交付物必要的质量检验和付款条件的把控
（13）在项目执行过程中，项目经理发现了问题，没有及时采取措施，对合同进行变更，将可能的影响降到最低
（14）合同条款中的验收标准存在问题
（15）缺乏合同管理的意识

3、工作说明书会充分详细地描述拟采购的产品、服务或成果，以便潜在卖方确定是否有能力提供此类产品、服务或成果。工作说明书的内容包括:规格、所需数量、质量水平、绩效数据、履约期间、工作地点和其他要求。
4、招标文件可以是信息邀请书、报价邀请书、建议邀请书，或其他适当的采购文件。

5、合同的分类:

7、合同管理包括：合同签订管理、合同履行管理、合同变更管理、合同档案管理、合同违约索赔管理。
8、索赔的流程：①提出索赔要求、②报送索赔资料、③监理工程师答复、④监理工程师逾期答复后果、⑤持续索赔、⑥仲裁与诉讼
9、熟悉招投标法、政府采购法相关内容
10、招投标流程：①招标人采用公开招标方式的，应当发布招标公告一②招标人根据招标项目的具体情况，可以组织潜在投标人踏勘项目现场一③投标人投标一④开标一⑤评标一⑥确定中标人一⑦订立合同。
11、政府采购方式有：①公开招标；②邀请招标；③竞争性谈判；④单一来源采购；⑤询价；⑥其他

十三、配置与变更管理

1、配置、变更管理问题
(1)没编写配置管理计划
(2)没进行配置识别
(3)没进行配置控制
(4)没进行配置状态报告
(5)没进行配置审计
(6)没进行发布管理与交付
(7)修改完成后未进行验证
(8)对用户的要求未进行记录
(9)对变更的请求未进行足够的分析，也没有获得批准
(10)在修改的过程中没有注意进行版本管理
(11)项目经理兼任配置管理员，精力不够，无法完成配置管理工作；
(12)变更控制委员会组成成员不合理
(13)项目中没有建立基线，导致需求、设计、编码无法对应；
(14)配置管理计划不应由CCB制定
(15)基线变更流程缺少变更验证（或确认）环节
(16)对配置管理工具没有进行有效评估
(17)没有将变更可能造成的影响告诉变更提出方。应该对变更提出方施加影响，确认变更的必要性，确保变更是有价值的
(18)没有对变更实施进行监控，没有对变更作记录并形成文档，造成变更内容无法追溯

(19)直接在受控库中增加修改权限
(20)没有统一的版本管理机制，各版本不可追溯，导致重要版本丢失
(21)没有对配置库进行很好的分类管理
(22)变更管理没有走流程或没有规范的变更流程。
(23)项目发生变更时没有及时更新项目计划
(24)没有很好的配置管理系统
(25)变更结束后要通知相关影响人员，而不仅仅只项目经理确认
(26)甲乙两人不能同时修改错误
(27)变更没有记录文件
(28)开发库与产品库的内容均不完整，且文档更新很不及时
(29)项目经理严重缺乏配置管理的意识与经验
(30)不能删除配置项
(31)配置管理意识不足
(32)没编写可行的配置管理方案
(34)变更发布应交由CMO完成

2、变更问题与措施
常见问题：①未制定标准的变更管理流程；②未书面记录变更；③未充分评估变更影响；④未成立CCB (CCB未包括客户)⑤未及时更新项目管理计划及文件；⑥未及时与干系人沟通; ⑦未验证和监控变更；
应对措施：①建立规范的变更控制流程；②书面中请和记录变更；③应充分评估变更影响；④应建立CCB,包含客户等干系人；⑤及时更新项目计划和文件；⑥及时与干系人沟通变更影响和结果；⑦变更后要验证和监控变更；

3、请分析该项目实施过程中存在哪些主要问题。
(1)未提交书面变更中请，项目经理没有按照变更管理的流程要求制定变更规则。
(2)变更控制委员会组成成员不合理，应该包括客户代表，最好是高级管理人员，并明确分工
(3)几乎所有变更都被批准和接受，说明CCB没有严格控制项目变更申请的提交，没有认真审核；
(4)应该对变更因素施加影响，积极沟通，确认变更的必要性
(5)没有进行变更后的评审，对变更造成的影响没有进行分析。
(6)没有将变更可能造成的影响告诉变更提出方(或对应的干系人)。
(7)没有严格按照变更控制流程进行变更管理。
(8)没有对变更作记录并形成文档，造成变更内容无法追溯。
(9)变更批准后，没有及时更新相应的项目计划和文件，导致内容不一致
(10)变更结果没有进行正式验证，未得到客户的确认
(11)是否接受或拒绝变更，不应该全部由项目经理(或某个人)决定；
(12)项目变更后没有相应的变更合同。
(13)客户需求发生变化时，应该由项目经理进行变更影响评估，而不是由其他人进行。
(14)对于变更请求，任何人不能直接进行修改，应该由CCB (变更控制委员会)决策， 
同意修改后，由项目经理安排相关人员进行修改。
(15)没有对变更影响作评估以及对变更方案的论证。
(16)没有成立CCB (变更控制委员会)。
(17)缺乏对变更过程的监控措施。
(18)没有对变更的效果作评估。
(19)没有变更文件。

4、典型的配置项包括项目计划书、技术解决方案、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据、设备型号及其关键部件

5、配置项可以分为基线配置项和非基线配置项两类。

  6、配置项的状态可分为“莫稿” “正式”和“修改”三种。
配置项刚建立时，其状态为 “草稿” 【0.YZ】。配置项通过评审后，其状态变为“正式”【X.Y】。 
此后若更改配置项，则其状态变为“修改”【X.YZ】。当配置项修改完 毕并重新通过评审时，其状态又变为“正式”。
  7、配置库可以分开发库、受控库、产品库3种
8、配置库的建库模式有两种：按配置项类型建库和按任务建库

9、配置管理相关角色常包括:变更控制委员会（CCB）、配置管理负责人、配置管理员和配置项负责人等。
10、配置管理负责人也称配置经理，负责管理和决策整个项目生命周期中的配置活动，具体有：①管理所有活动，包括计划、识别、控制、审计和回顾;②负责配置管理过程;③通过审计过程确保配置管理数据库的准确和真实;④审批配置库或配置管理数据库的结构性变更;⑤定义配置项责任人;⑥指派配置审计员;⑦定义配置管理数据库范围、配置项属性、配置项之间关系和配置项状态;⑧评估配置管理过程并持续改进;⑨参与变更管理过程评估;⑩对项目成员进行配置管理培训。
11、配置管理员负责在整个项目生命周期中进行配置管理的主要实施活动，具体有:①建立和维护配置管理系统;②建立和维护配置库或配置管理数据库;③配置项识别;④建立和管理基线;⑤版本管理和配置控制;⑥配置状态报告;⑦配置审计;⑧发布管理和交付。（20下52）
12、配置项负责人确保所负责的配置项的准确和真实:①记录所负责配置项的所有变更;②维护配置项之间的关系;③调查审计中发现的配置项差异，完成差异报告;④遵从配置管理过程; 
⑤参与配置管理过程评估。
13、配置管理的日常管理活动主要包括:制订配置管理计划、配置项识别、配置项控制、配置状态报告、配置审计、配置管理回顾与改进等。
14、基于配置库的变更控制，某软件产品升级流程：
①将待升级的基线（假设版本号为V2.1）从产品库中取出,放入受控库。
②程序员将欲修改的代码段从受控库中检出（Checkout）,放入自己的开发库中进行修改。 
代码被Checkout后即被“锁定”，以保证同一段代码只能同时被一个程序员修改，如果甲正对 
其修改，乙就无法Checkouto
③程序员将开发库中修改好的代码段检入（Checkin）受控库。Checkin后，代码的“锁定” 
被解除，其他程序员可以Checkout该段代码了。
④软件产品的升级修改工作全部完成后，将受控库中的新基线存入产品库中（软件产品的 
版本号更新为V2.2,旧的V2.1版并不删除，继续在产品库中保存）。
15、功能配置审计是审计配置项的一致性（配置项的实际功效是否与其需求一致），验证： 
①配置项的开发已圆满完成；②配置项已达到配置标识中规定的性能和功能特征；③配置项的操作和支持文档己完成并且是符合要求的。
16、物理配置审计是审计配置项的完整性（配置项的物理存在是否与预期一致），验证： 
①要交付的配置项是否存在；②配置项中是否包含了所有必需的项目。
17、变更分类
（1）根据变更性质可分法 重大变更、重要变更和一般变更。通过不同审批权限控制。
（2）根据变更的迫切性可分为：紧急变更、非紧急变更。通过不同变更处理流程进行
18、信息系统项目鱼，除项目经理和CCB外，通常还会定义变更管理负责人、变更请求者、变更实施者和变更顾问委员会等。

19、变更的流程：①变更申请一②对变更的初审一③变更方案论证一④变更审查一⑤发出通知并实施一⑥实施监控一⑦效果评估一⑧变更收尾；