导图社区 信息系统项目管理师案例分析万金油
- 84
- 0
- 0
- 举报
信息系统项目管理师案例分析万金油
这是一篇关于信息系统项目管理师案例分析万金油的思维导图，大家有兴趣的可以看一下哟。
编辑于2022-10-26 21:14:58 广东- 信息系统项目管理师案例分析万金油
- 相似推荐
- 大纲
案例分析万金油
信息化 信息系统开发方法
软件生命周期
可行性分析与项目开发计划
需求分析
概要设计
详细设计
编码
测试
维护
软件维护
更正性维护
适应性维护
完善性维护
预防性维护
软件测试 （按开发阶段划分）
单元测试
集成测试
系统测试
验收测试
测试管理
测试部门管理
日常事务
部门人员
部门下属项目
部门资产等的跟踪及管理
测试项目管理
需求风险
测试用例风险
缺陷风险
代码质量风险
测试环境风险
测试技术风险
回归测试风险
沟通协调风险
其他不可预计风险
项目管理
立项管理
详细可行性研究的内容（必记）（你概述一下需（需求确定）要的资源、技术、进度、资金和人；看效益怎么样，要不要合作）
概述
需求确定
现有资源、设施情况分析
设计（初步）技术方法
项目实施进度计划建议
投资估算和资金筹措计划
项目组织、人力资源、技术培训计划
经济和社会效益分析（效果评价）
合作，协作方式
项目论证的作用
确定项目是否实施的依据
筹措资金、向隐含贷款的依据
编制计划、设计、采购、施工 以及机构设置、资源配置的依据
项目论证是防范风险、 提高项目效率的重要保证
详细可研究的方法
经济评价法
市场预测法
投资估算法
增量净效益法
可研过程中可能出现的问题
没有正式、书面的新产品研发项目建议书就开展可行性研究工作
新产品研发的可行性研究工作不充分，尤其缺少技术可行性分析和论证
研发过程中对人才缺乏、竞争对手等带来的风险缺乏充分的分析，没有合理的应对方案
没有新产品的初步设计方案就开始研发工作
在项目启动前缺少对项目成本的估算或成本估算工作未到位
可行性研究报告缺少必要的内部论证和外部评估环节
前期立项工作人员参与不充分，缺少关键技术人员与财务人员
招投标重要条款（必记）
招标人可以要求投标人提供有关资质证明文件和业绩情况，并进行资格审查； 国家对投标人有资格规定的，按规定执行；招标人不得以不合理条件限制或 排斥潜在投标人，不得对潜在投标人实行歧视待遇
投标人应当确定投标人编制投标文件所需的合理时间，自招标文件发出之日起到投标人提交投标文件截止之日起，最短不得小于20日
两个以上法人或者其他组织可以组成一个联合体，以一个投标人的身份共同投标。 联合体各方应当具备承担招标羡慕的相应能力； 国家或招标文件对投标人资格条件有规定的，联合体各方应具备规定的相应资格条 件。同一专业的单位组成的联合体，按照资格等级较低的单位确定资质等级。
评标有招标人依法组建的评标委员会负责。依法必须进行招标的项目，其评标委员会由招标人的代表和有关技术、经济等方面的专家组成，成员人数为五人以上单数，其中技术、经济等方面的专家不得少于成员数的三分之二
招标人和中标人应当自中标通知书发布之日起三十日内，按照招标文件和中标人的投标文件订立书面合同。招标人和中标人不得再行定背离合同实质性的其他协议。
涉及国家安全、国家秘密、抢险救灾或者属于利用扶贫资金实行以工代赈、需要使用农民工等特殊情况，不适宜使用招标的项目，按照国家有关规定可以不进行招标
整体管理
项目启动会议
一般由项目经理组织召开
明确范围的目标、范围、需求、背景及各自职责与权限
做好五个方面工作
确定会议目标
做好会议前准备工作
明确并通知参加会议人员
明确会议的主要议题
做好记录
项目章程（重要必记）
项目章程是正式批准的项目文件
包含内容（目的-目标-要求要概括，风险-进度-预算要审批）
项目目的或批准项目的原因
可测量的项目目标和相关的成功标准
项目的总体要求
概括性的项目描述
项目的主要风险
总体里程碑进度计划
总体预算
项目审批要求（用什么标准评价项目成功， 由谁对项目成功下结论，由谁来签署项目结束）
委派的项目经理及其职责与职权
发起人或其他批准项目章程人员的姓名与职权
作用：（确定权力和地位，规定目标，叙述启动理由，联系战略。）
确定项目经理及权力
正式确认项目的合法地位
规定项目的总体目标（包括范围、时间、成本、质量等）
通过叙述项目启动的理由，把项目与执行组织的运作与战略计划联系起来
项目管理计划的内容（重要必记）
一、计划过程组的各个计划子过程的全部成果
项目管理团队选择的各个项目管理过程
每一选定过程的实施水平
对实施这里过程时使用的工具与技术所做的说明
在管理具体项目中使用选定过程的方式和方法，包括过程之间的依赖关系与相互作用，以及重要的依据和成果
为了实现项目目标所执行工作的方式、方法
监控变更的方式、方法
实施配置管理的方式、方法
使用实施效果测量基准并使之保持完整的方式方法
项目关系人之间的沟通需要与技术
选定的项目生命期和多阶段项目的项目阶段
高层管理人员为了加快解决问题和处理未作出决策，对内容、范围和时间安排的关键审查
二、多个分计划（或辅助计划）（九大领域计划+过程改进计划+进度、成本、范围基准）
范围管理计划
需求管理计划
进度管理计划
成本管理计划
质量管理计划
过程改进计划
人力资源管理计划
沟通管理计划
风险管理计划
采购管理计划
干系人管理计划
其他内容：进度基准、成本基准、范围基准等
指导和管理项目执行的行动 （开展活动、付出资金、培训人员；取得报价、选定卖方、取得资源；实施方法、创造成果；管理风险、管理卖方；纳入变更、建立渠道；收集数据、收集教训。）
开展活动实现项目目标
付出努力与资金，实现项目目标
配备、培训并管理分派到本项目上的项目团队成员
根据具体情况取得报价、标书、要约或建议书
在潜在的卖方中间进行比较、选定卖方
取得、管理并使用资源，包括材料、工具、设备与设施
实施已列入计划的方法和标准
创造、控制、合适并确认项目可交付成果
管理风险并实施风险应对活动
管理卖方
将批准的变更纳入项目的范围、计划和环境
建立并管理项目团队内外的项目沟通渠道
收集项目数据并报告费用、进度技术与质量绩效，以及有助于预测的状态信息
收集与记载吸取的教训，并实施批准的过程改进活动
项目管理计划制定常见问题
计划应大家一起参与制定
计划内容不周全或不充分
没有评审和审批
项目已经变更，计划未更新
没有处理好内部依赖关系和制约因素，对计划产生影响
执行不到位
整体管理可能存在的问题（重要必看）
未制定项目章程（或章程未得到审批）
项目经理未能得到授权，未能确定项目高层的范围、目标
没有指定整体项目管理计划（或计划不周全）
计划应大家一起参与制定，不能项目经理一个人制定
计划没有经评审和批准
项目执行不到位
没有做好项目监控工作，未能及时对比分析计划和实际执行情况
对问题未能及时监控和分析，未能及时提出纠正/预防/缺陷补救措施
没有指定合理的整体变更流程
项目已经变更，计划或基准未更新
未能做好项目收尾工作，未能总结经验教训
范围管理
范围说明书的内容（重要必记）（产验可除制假）（21下）（20下）
产品范围描述
验收标准
可交付成果
项目的除外责任
制约因素
假设条件
范围说明书的作用（确定范围，验规变控沟的依据）20下
用于确定范围
作为验收的依据
作为规划的依据
作为变更的依据
作为控制的依据
作为沟通的依据
分解工作包活动包括（重要必记）
识别和分析可交付成果及相关工作
确定WBS的结构和编排方法
自上而下逐层细化分解
为WBS组件制定和分配标识编码
核实可交付成果分解的程度是恰当的
造成项目范围变更的主要原因
项目外部环境发生变化，例如，政府政策的问题
项目范围的计划编制不周密详细，有一定的错误或遗漏
市场上出现了或是设计人员提出了新技术、新手段或新方案
项目实施组织本身发生变化
客户对项目、项目产品或服务的要求发生变化
范围管理过程中存在的问题（重要必看）20下
没有指定范围管理计划和需求管理计划
没有做好需求收集、分析、调研等工作
没有做好需求跟踪工作
不能仅依据过去的经验来编写现在项目的范围说明书等工作
项目范围说明书不应由项目经理一人来编写
WBS及范围基准应让项目团队和所有关键干系人一起来创建，而不是项目经理创建，导致工作遗漏
项目范围基准未经评审和审批
缺少范围确认等环节，项目成果等没有得到用户的正式确认和接受
范围变更没有规范的变更控制流程
项目变更实施前没有及时变更合同
变更结果没有得到客户的确认
未做好范围控制工作，对范围管理中的偏差和问题未进行及时的纠正
没编制WBS和WBS词典，没有范围基准
需求管理可能的问题（重要必看）（21下）
对客户（或用户）的需求获取不充分
没有按照规范的需求开发与需求管理的流程及内容开展需求工作
缺乏需求定义环节，没有定义出需求规格说明书
缺乏需求验证环节，没有请客户代表一起进行需求评审
没有指定范围和需求管理计划
没有求得干系人对需求的一致理解
没有求得干系人对需求的承诺
没有有效地管理需求变更控制
没有有效维护对需求进行跟踪管理
没有及时识别项目与需求之间的不一致性
没有制定范围管理计划
需求管理问题应对措施（重要必看）
建立需求变更控制策略和需求变更控制流程
采用多种方式充分获取用户需求并进行详细的需求分析
形成需求规格说明书并与用户进行需求验证（确认）和评审
需求定稿建立基线，以后的需求变更必须走变更控制流程，并及时更新需求规格说明书和需求跟踪矩阵
编写需求跟踪矩阵，需求状态表等文档
在需求规格书基础上编制技术方案，并进行评审
定期不定期对项目绩效进行监督检查，找出问题原因并指导团队成员解决
WBS分解中存在的问题（21下）
WBS分解不应由项目经理一个人来完成，需要有充分的团队参与
未对项目可交付成果进行全面识别和分析
WBS组件不应有多负责人的情况
WBS不符合8/80原则，工作包的知道时间应该最低8小时，最高80小时
WBS没有包含管理工作
WBS没有包括外包出去的工作
WBS分解完成后，未经项目干系人一致确认
修改WBS没有经过CCB审批，没有走变更管理流程
没有满足滚动分解原则，因为WBS并非一成不变的
WBS分解时的注意事项（21下）
WBS必须是面向可交付成果的
WBS必须符合项目的范围
WBS的底层应该支持计划和控制
WBS中的元素必须有人负责，而且只有一个人负责
作为指导而不是原则，WBS应控制在4-6层
WBS应包括项目管理工作
WBS的编制需要所有（主要）项目干系人的参与
未与干系人进行良好沟通
存在范围蔓延的风险
项目范围是否完成要以范围基准来衡量，包括经过批准的范围说明书，WBS和WBS词典
可交付成果和里程碑，标志着某个可交付成果获阶段的正式完成
项目干系人提出变更申请后，一般由项目经理或项目配置管理员进行初审
进度管理
缩短工期方法（重要必记）（赶快使减改为加）
赶工，投入更多的资源或增加工作时间，以缩短关键活动的工期
快速跟进，并行施工，以缩短关键路径的长度
使用高素质的资源或经验更丰富的人员
减小活动范围或降低活动要求
改进方法或技术，以提高生产效率
加强质量管理，及时发现问题：减少返工，从而缩短工期
成本超支、进度落后措施
用高效人员代替低效人员
加班或者赶工在防范风险的情况下并行施工
减小活动范围或降低活动要求
通过改进方法或技术提高生产效率
分析成本超支原因，再找出针对性的对策如改进方法、优化方案、提高效率等
成本超支、进度超前措施
抽调部分人员，放慢工作进度
采取措施，控制成本
对于不同的任务，采取不同的成本进度措施，必要时调整成本基准
分析成本超支原因，再找出针对性的对策如改进方法、优化方案、提高效率等
制定进度计划和进度控制的工具与技术（重要必记）
制定进度计划的工具与技术
进度网络分析
关键路线法
关键链法
资源优化技术
建模技术
提前量与滞后量
进度压缩
进度计划编制工具
进度控制工具与技术
绩效审查
项目管理软件
资源优化技术
建模技术
提前量与滞后量
进度压缩
进度计划编制工具
进度管理中可能出现的问题（重要必看）
团队成员没有及早参与，需求分析耗时长
经验不足，进度计划制定不准，没有采取有效的历时估算方法和网络计划技术，制定进度计划
考虑项目期间特定时期会对进度产生影响
项目经理经验不足，进度估算不准确，资源与配置不足
没有充分利用分配项目资源
在安排进度时未考虑法定节假日的因素
仅仅依靠某项目来估算项目的历时根据不充分
没有对项目的技术方案、管理计划进行详细的评审、需求没有经过确认
增加人员经验不足，沟通存在问题，加班使得人员工作效率降低
项目进度出现问题的解决方案（重要必看）
向公司申请增加资源，或使用经验丰富的员工
优化网络图，重排活动之间的顺序，压缩关键路径的长度
临时加班（赶工），尽可能补救耽误的时间或提升资源的利用效率
将部分阶段的工作改为并行、内部流程优化
变更原来的进度计划，根据前阶段的绩效，对后续工作重新估计，修订计划，并得到项目干系人的同意
加强同项目干系人的沟通
加强交付物、项目阶段工作的及时检查和控制，避免后期出现返工
尽可能调配非关键路径是哪个的资源用于关键路径上的任务
优化外包，采购等环节并全程监控
出现整体进度拖延的原因
缺乏绩效报告系统，没有统一的绩效报告
缺乏变更控制系统
缺乏进度控制
实施进度控制的方法
建立项目统一的绩效管理体系，建立绩效报告的流程
建立变更管理体系，变更控制流程,建立CCB
采取赶工、快速赶进等措施
进度控制过程的工具与技术
进展报告
进度变更控制系统
绩效测量
项目管理软件
偏差分析
进度比较横道图
成本管理
成本估算三步骤（重要必记）
识别并分析成本构成的科目
根据已识别的项目成本构成科目，估算每一科成本的大小
分析成本估算结果，找出各种可以相互替代的成本，协调各成本之间的比例关系
成本预算步骤（重要必记）
将项目总成本分摊到项目工作分解结构的各个工作包
将各个工作包成本在分配到该工作包所包含的各项活动上
确定各项成本预算支出的时间计划及项目成本预算计划
成本控制主要工作内容
对造成成本基准变更的因素施加影响
确保变更请求获得同意
当变更发生时，管理这些实际的变更
保证潜在的成本超支不超过授权的项目阶段资金和总体资金
监督成本执行，找出成本基准的偏差
准确记录所有的成与成本基准的偏差
防止错误的、不恰当的或未获批准的变更纳入成本或资源使用报告中
就审定的变更通知项目干系人
采取措施，将预期的成本超支控制在可接受的范围内
信息系统项目成本估算困难或不准的原因（重要必看）
在项目范围尚未确定时进行成本估算
过于乐观或保守的估计
复杂的信息，需考虑的因素多
技术的变化
缺乏同类项目的参考
缺乏专业和有经验的人才
信息系统项目需求变化大，目标不明确
管理层的压力
成本失控原因
对信息系统项目工程成本控制的特点认识不足
项目的成本估算不合理或估算不准
项目经理，或设计人员和实施人员缺乏成本意识，缺乏责任感，随意开支，铺张浪费
组织制度不健全
成本控制的方法有问题，没有及时纠偏
技术的制约
需求范围管理不当，范围没有得到很好控制，变更频繁，导致成本不断增加
进度拖延，导致成本不断增加
对质量的过于苛刻要求，未考虑成本
质量管理
质量管理应完成的工作
应制定确实可行的质量管理计划
应安排独立于项目组的质量保证人员负责质量保证工作
对软件开发的过程实施质量保证
加强对需求和设计等开发过程文件的技术评审工作
注重测试工作，应安排相对独立的测试人员
对发现的缺陷进行统计分析，制定措施，确保软件质量符合要求
加强质量控制，对各项成果要进行评审和检查
ISO9000的八项原则
以顾客为中心
领导作用
全员参与
过程方法
管理的系统方法
持续改进
基于事实的决策方法
互利的供方关系
质量管理计划的内容（重要必记）（用一个策略来组织程序制度，用一个措施来控制改进资源）
质量策略，目标及方针及制定依据
质量组织结构、人员职责
质量管理程序
质量管理制度
质量保证措施
质量过程控制
过程改进计划和措施
建立质量管理所需的资源
质量保证的作用
是保证质量的一个重要环节
为持续的质量改进提供基础和方法
为项目干系人提供对质量的信任
是项目质量管理的一个重要内容
与质量控制共同构成对质量的跟踪和保证
质量保证与质量控制的具体内容及区别联系（重要必看）
质量保证：旨在建立对未来输出或未完输出（在进行的工作）将在完工时满足特定的需求和七万的信心
按项目计划开展具体的质量活动，把项目过程及产品做得符合质量要求，即按照计划做质量
设法提高项目干系人对项目满足质量要求的信心
按照过程改进计划，进行过程改进，使项目过程更加稳定并减少非增值环节
根据过去的质量控制测量结果对质量标准进行重新评价，确保所采用的质量标准是合理的可操作的
质量控制：（结果符合要求、纠偏控制）监督项目的具体实施结果，判断其是否符合质量标准；确定消除产生不良结果的根源的方法和途径
按照质量标准检查质量，发现质量偏差和质量缺陷，并对不可接受的质量偏差提出纠偏建议，对质量缺陷提出缺陷补救建议
识别过程低效或产品质量低劣的原因，建议并采取措施消除这些原因
确认项目可交付成果及工作满足干系人既定需求，足以进行最终验收
两者的联系
都是为了保证项目及产品符合质量要求
质量保证和质量控制都应贯穿项目始终
质量保证为质量控制提供了更好的保证和条件，同时质量控制的测量结果也是质量保证过程的输入
质量管理可能遇到的问题（重要必看）
没有指定质量管理计划
质量职责分配不合理，没有QA或QA不独立于项目组，或QA没有全程参与项目
质量保证活动做得不到位，或未实施质量保证
质量控制缺少必要的环节（评审、测试）
质量控制方法不合理，效果不佳（评审、测试）
没有按照变更流程的要求处理质量标准或验收标准的变更
项目经理在质量管理方面经验不足或质量保证人员经验不足
没有建立治理质量的保证体系
缺乏质量标准和质量规范
在质量管理过程中，没有采用合适的工具、技术、方法
测试过程中配置管理工作未到位
项目在重大里程碑处没有设置阶段成果评审，无法确保结果和预期目标一致
技术评审会没有达到预期的目标
设计文件没有经过正式评审，可能没有发现设计文件的错误
需求评审没有客户参与或没做好，可能导致最终对需求不能达成一致
项目团队成员缺乏质量意识
与客户沟通存在问题，方式单一，导致用户不必要的担心
针对质量问题可以提出的解决措施（重要必看）
应使用有关行业经验，项目经验和质量管理经验的质量保证人员
应科学制定和实施质量管理计划
重视软件项目的测试环节，安排必要的时间，采用合理方法进行充分测试
应重视软件开发过程中的质量保证工作，采用相应的工具和技术，避免将检查、测试作为项目质量的唯一方法
应加强需求和设计方案的评审和质量控制工作
应加强项目实施过程中的配置管理
应建立项目的质量管理体力，包括制定可行的过程规范和质量目标、质量标准
对发现的缺陷机型统计分析，确保软件质量 ，提出合理有效的质量整改措施
为项目组成员提供质量管理要求方面的培训
加强与客户在质量管理方面的沟通和交流
质量体系存在的问题（重要必看）
体系建设应全员参与
体系应结合企业自身的质量要求和特点，不能照搬其他公司的文件或经验
体系建设后应及时运行，不断完善，而不是束之高阁
在运行过程中，发现问题并进行改进，采用PDCA原则
质量部门应全程参加质量管理和体系建设及运行
项目应遵循组织质量体系，在组织的质量体系框架下进行质量管理
过程改进方法（重要必看）
分析目前质量体系（或质量管理）的现状
找出问题及原因
制定改进计划，确定措施
确定改进职责，将工作分配到相关部门及人员
按改进计划进行执行
对执行的成果及过程进行检查和评估
进行总结和修正，形成正式质量体系，再不断持续改进
人力资源管理
★【重要必记】人力资源管理计划的内容
角色与职责
组织结构图
人员配备管理计划:描述人力资源需求何时及怎么被满足（人资培训人，好认真“啊”安全）
1)人员招募:内部、外部?集中办公还是分散办公?等
2）资源日历:资源的可用工作日和工作班次的日历。何时需要何种人员;招募活动何时开始等(可用资源直方图来显示个人、团队在每周或每月需要工作的小时数)
3)人员遣散计划:事先确定的团队成员遣散方法、时间等，以便平滑过渡
4）培训需要:预分派员工不具有要求的技能和能力，需提前制定培训计划
5)认可和奖励:奖励标准、奖惩系统及计划
6)合规性:政府规章制度、工会合同、其他人力政策等
7)安全性:规定一些政策和程序，使团队成员远离安全隐患。
★项目团队建设的目标包括但不限于如下目标:
·提高项目团队成员的个人技能，以提高他们完成项目活动的能力，与此同时降低成本、缩短工期、改进质量并提高绩效。
提高项目团队成员间的信任感和凝聚力，以提高士气，降低冲突，促进团队合作。
·创建动态的、团结合作的团队文化，以促进个人与团队的生产率、团队精神和团队协作，鼓励团队成员之间交叉培训和切磋以共享经验和知识。
★【重要必记】项目团队建设方法（如何进行团队建设)︰
·一般管理技能。如经常与项目团队成员进行沟通，了解其后顾之忧，并帮助他们解决问题。
·培训。培训个人和团队，以分别提高二者的绩效
团队建设活动。每一次的集体活动都是一次团队建设活动，团队建设活动更多地体现在团队的日常工作中，也可以通过专门的团队建设活动来进行。
·共同的行为准则。越早建立清晰的准则，越能减少误解，提高生产率。
尽量集中办公。如果条件不允许集中办公，则可以通过大会、虚拟技术等方式弥补
·恰当的奖励与表彰措施。
★【重要必记】成功的团队具有如下的共同特点（有目标有组织，有方法有标准，有纪律要协同）
·团队的目标明确,成员清楚自己的工作对目标的贡献。
·团队的组织结构清晰，岗位明确。
·有成文或习惯的工作流程和方法，而且流程简明有效。
·项目经理对团队成员有明确的考核和评价标准，工作结果公正公开，赏罚分明。
·共同制订并遵守的组织纪律
·协同工作，也就是一个成员工作需要依赖于另一个成员的结果，善于总结和学习。
★虚拟团队(Virtual Teams)的使用为招募项目团队成员提供了新的可能性。
虚拟团队可定义为具有共同目标、在完成角色任务的过程中很少或没有时间面对面工作的一群人。现代沟通技术(如电子邮件、电话会议、社交媒体、网络会议和视频会议等）使虚拟团队成为可行。
虚拟团队的利：
·在组织内部地处不同地理位置的员工之间组建团队。
·为项目团队增加特殊技能，即使相应的专家不在同一地理区域。
·将在家办公的员工纳入团队。
·在工作班次、工作小时或工作日不同的员工之间组建团队。
·将行动不便者或残疾人纳入团队。
虚拟团队的弊：
虚拟团队也有一些缺点,例如,可能产生误解,有孤立感,团队成员之间难以分享知识和经验，采用通信技术的成本。
在虚拟团队的环境中，沟通规划变得尤为重要。项目管理团队需要花更多时间，来设定明确的期望,促进沟通,制定冲突解决方法,召集人员参与决策，理解文化差异，以及共享成功喜悦。
【重要必记】项目经理应具备的能力（一般要求，常与人力资源问题一起考)·
·足够的知识
·丰富的项目管理经验
·良好的协调和沟通能力
·良好的职业道德
·一定的领导和管理能力
★多项目资源冲突解决:
·建议单位统一管理所有的项目和资源，制定资源在项目之间分配的原则。
·定期检查项目的执行情况,根据项目进展情况和企业整体绩效重新排定项目的优先顺序,从资源上优先支持重要的和进展良好的项目。
·可以用外包的方式将部分工作进行外包。
·在必要时，增加资源或进行资源的平衡。
·建立项目管理体系，设立项目管理办公室，统一管理单位所有项目。
★冲突的特点
冲突是自然的,而且要找出一个解决办法。
冲突是一个团队问题,而不是某人的个人问题。
应公开地处理冲突。
冲突的解决应聚焦在问题,而不是人身攻击。
冲突的解决应聚焦在现在，而不是过去。
★【重要必记】冲突解决办法（不许撤退缓和妥协，只能强迫合作）
撤退/回避。从实际或潜在冲突中退出，将问题推迟到准备充分的时候，或者将问题推给其他人员解决。双方在解决问题上都不积极，也不想合作。撤退是一种暂时性的冲突解决方法。
缓和/包容。强调一致、淡化分歧（甚至否认冲突的存在);为维持和谐与关系而单方面退让一步。这是一种慷慨而宽厚的做法，为了和谐和大局，而迁就对方，或者暂时放下争议点，谋求在其他非争议点与对方协作。缓和也是一种暂时性的冲突解决方法。
妥协/调解。为了暂时或部分解决冲突，寻找能让各方都在一定程度上满意的方案。双方在态度上都愿意果断解决冲突，也愿意合作。双方都得到了自己想要的东西，但只是一部分，而不是全部。双方都做了让步，都有得有失。妥协是双方面的包容，包容是单方面的妥协。
强迫/命令。以牺牲其他方为代价，推行某一方的观点;只提供赢输方案。通常是利用权力来强行解决紧急问题。一方赢，一方输。
合作/解决问题。综合考虑不同的观点和意见，采用合作的态度和开放式对话引导各方达成共识和承诺。这是冲突双方最理想的结果,前提是双方要相互尊重、愿意合作、愿意倾听对方。
★【重要必看】人力资源可能出现的问题:
缺乏足够的项目管理能力和经验;
·兼职过多，精力和时间都不够用，顾此失彼;
·没有进入管理角色，定位错误，疏于对项目的管理;
·新人缺乏培训和全程的跟踪和监控;
·没有进行良好的冲突管理;
·组建团队出现问题（选人、挑人出现问题，缺乏对工作能力和团队合作精神方面进行考核);
·建设团队出现问题(或没有采取有效的团队建设措施);
·没有清楚地分配工作职责到个人或人力单元;
·没有对人员实行绩效考评或相应的激励机制;
团队管理存在问题，主要是没有及时发现冲突并分析原因，采取有效的冲突管理（或过于简单);
·招募不到合适的项目成员;
·团队的组成人员尽管富有才干，但却很难合作;
·团队气氛不积极,造成项目团队成员的士气低落
·项目团队的任务和职责分配不清楚;
·人员流动过于频繁;
·未制定共认并应遵守的团队规则
★【重要必看】人力资源问题的应对措施:
·采用合适的团队建设手段，消除团队成员间的隔阂-明确项目团队的目标及项目组各成员的分工
·建立清晰的工作流程和沟通机制
建立明确的考核评价标准
·建立并不断强化项目的目标-制定并组织规则和纪律
·积极做团队建设活动，保持良好的团队氛围，分享和开放的沟通·制定有效的激励措施
沟通及干系人管理
沟通管理过程说明
规划沟通管理
管理沟通
控制沟通
沟通渠道数量
N=n(n-1)/2
沟通管理计划的内容（沟通的需求、信息，发布的原因，和频率，负责的接收的人员，传递的技术，分配的资源）
通用术语表
干系人的沟通需求
需要沟通的信息，包括语言、格式、内容、详细程度
发布信息的原因
发布信息及告知收悉或做出回应（如适用）的时限和频率
负责沟通相关信息的人员
将要接收信息的个人或小组
传递信息的技术或方法
为沟通活动分配资源，包括时间和预算
问题升级程序，用于规定下层员工无法解决问题时的上报时限和上报路径
随项目进展，对沟通管理计划进行更新与优化的方法
项目信息流向图、工作流程（兼有授权顺序）、报告清单、会议计划等
沟通制约因素，通常来自特定的法律法规、技术要求和组织政策等
沟通管理计划中还可包括关于项目状态会议、项目团队会议、网络会议和电子邮件信息等的指南和模板。沟通管理计划中也应包含对项目所用网站和项目管理软件的使用说明。
沟通方法
·交互式沟通。在两方或多方之间进行多向信息交换。这是确保全体参与者对特定话题达成共识的最有效的方法，包括会议、电话、即时通信、视频会议等。
·推式沟通。把信息发送给需要接收这些信息的特定接收方。这种方法可以确保信息的发送，但不能确保信息送达受众或被目标受众理解。推式沟通包括信件、备忘录、报告、电子邮件、传真、语音邮件、日志、新闻稿等。
·拉式沟通。用于信息量很大或受众很多的情况。要求接收者自主自行地访问信息内容。这种方法包括企业内网、电子在线课程、经验教训数据库、知识库等。
报告绩效
是指收集和发布绩效信息，包括状况报告、进展测量结果及预测结果。应该定期收集基准数据与实际数据，进行对比分析，以便了解和沟通项目进展与绩效，并对项月结果做出预测。 较为详尽的绩效报告可能包括:
·对过去绩效的分析。
·项目预测分析，包括时间与成本。
·风险和问题的当前状态。
·本报告期完成的工作。
·下个报告期需要完成的工作。
·本报告期被批准的变更的汇总。
·需要审查和讨论的其他相关信息。
补充知识（沟通方式的参与程度与控制程度）
参与讨论
征询
推销
叙述
管理关系人过程说明
·识别干系人∶识别能影响项目决策、活动或结果的个人、群体或组织，以及被项目决策、活动或结果所影响的个人、群体或组织，并分析和记录他们的相关信息的过程。这些信息包括他们的利益、参与度、相互依赖、影响力及对项目成功的潜在影响等。
·编制项目干系人管理计划:基于对干系人需要、利益及对项目成功的潜在影响的分析，制定合适的管理策略，以有效调动干系人参与整个项目生命周期的过程。
·管理干系人参与:在整个项目生命周期中，与干系人进行沟通和协作，以满足其需要与期望，解决实际出现的问题，并促进干系人合理参与项目活动的过程。
·控制干系人参与:全面监督项目干系人之间的关系，调整策略和计划,以调动干系人参与的过程。
项目干系人管理的重要性
对项目干系人需求、希望和期望的识别，并通过沟通上的管理来满足其需要、解决其问题的过程。项目干系人管理将会赢得更多人的支持，从而能够确保项目取得成功。
1）将会赢得更多的资源，通过项目干系人管理，能够得到更多有影响力的干系人的支持，自然会得到更多的资源。
2）快速频繁的沟通将能确保对项目干系人需要、希望和期望的完全理解;从某种意义上来说需求管理是项目干系人管理的一部分。
3）能够预测项目干系人对项目的影响，尽早进行沟通和制订相应的行动计划，以免受到项目干系人的干扰。
通常由项目经理负责干系人管理。
★【重要必记】干系人管理计划
除了干系人登记册中的资料，干系人管理计划通常还包括:(1）关键干系人的所需参与程度和当前参与程度;
(2)干系人变更的范围和影响;
(3)干系人之间的相互关系和潜在关系;
(4)项目现阶段的干系人沟通需求;
(5)需要分发给干系人的信息，包括语言、格式、内容、详细程度等;
(6）分发相关信息的理由，以及可能对干系人参与所产生的影响;
(7)向干系人发送信息的频率和时限
(8）随着项目的进展，更新和优化干系人管理计划的方法。
干系人分析的步骤
(1）识别干系人及其相关信息。
(2)分析干系人可能的影响并把他们分类和排序。
(3评估干系人对不同情况可能做出的反应，以便制定相应策略对他们施加正面影响。
★【重要必记】干系人分类模型
权利/利益方格。根据干系人的职权大小和对项目结果的关注（利益）程度进行分类。
1.利益高、权力高:他们对项目有很高的权力，也很关注项目的结果，项目经理应该“重点管理，及时报告”，应采取有力的行动该类干系人满意。项目的客户和项目经理的主管领导，就是这样的项目干系人。
2.利益高、权力低:尽管该类干系人权力低,但关注项目的结果,因此项目经理要“随时告知”项目状况，以维持该类干系人的满意程度。如果低估了该类干系人的利益，可能产生危险的后果，可能会引起其的反对。大多数情况下，要全面考虑到该类干系人对项目可能的、长期的以及特定事件的反应。
3.利益低、权力高:该类关键干系人具有“权力大、对项目结果关注度低”的特点，因此争取他们的支持,对项目的成功至关重要,项目经理对该类干系人的管理策略应该是“令其满意”。
4.利益低、权力低:该类干系人的特点是“权力低、对项目结果的关注度低”，因此项目经理主要是通过“花最少的精力来监督他们”即可。对他们的态度也应该“要好一些”，以争取他们的支持、降低他们的敌意。
干系人登记册
用于记录已经识别的干系人的相关详细信息
包括:基本信息、评估信息、干系人分类。
应定期查看并更新干系人登记册,以为整个项目生命周期中干系人可能发生变化,也可能识别出新的干系人。
风险管理
★【重要必记】风险管理计划的基本内容:（风险管理计划的内容：方世玉，排两个险阵，干式跟踪）
·方法论:确定项目风险管理将使用的方法、工具及数据来源。
·角色与职责:确定风险管理计划中每个活动的责任者和支持者，以及风险管理团队的成员，并明确其职责。
·预算:根据分配的资源估算所需资金，并将其纳入成本基准,制定应急储备和管理储备的使用方案。
时间安排:确定在项目生命周期中实施风险管理过程的时间和频率,制定进度应急储备的使用方案，确定风险管理活动并纳入项目进度计划中。
风险类别:规定对潜在风险成因的分类方法。有多种方法可以使用,常用的方法一般是基于项目目标的分类方法。风险分解结构(Risk Breakdown Structure,RBS）有助于项目团队在识别风险的过程中发现有可能引起风险的多种原因，不同的RBS适用于不同类型的项目。
·风险概率和影响的定义:为了确保风险分析的质量和可信度,项目经理需要对项目环境中特定的风险概率和影响的不同层次进行定义。
概率和影响矩阵:概率和影响矩阵是把每个风险发生的概率和一旦发生对项目目标的影响映射起来的表格。根据风险可能对项目目标产生的影响，对风险进行优先排序。进行排序的典型方法是使用查询表或概率和影响矩阵。通常由组织来设定概率和影响的各种组合，并据此设定高、中、低风险级别。
·修订的干系人承受力:可在规划风险管理过程中对干系人的承受力进行修订,以适应具体项目的情况。
·报告格式:规定将如何记录、分析和沟通风险管理过程的结果，规定风险登记册及其他风险报告的内容和格式。
·跟踪∶规定将如何记录风险活动，促进当前项目的开展，以及将如何审计风险管理过程。
★风险识别的内容
·识别并确定项目有哪些潜在的风险
·识别引起这些风险的主要因素
识别项目风险可能引起的后果
★【重要必看】在项目中可能遇到的风险:
·需求风险
·技术风险
·政策风险
·法律法规风险
·市场风险
·运行风险
·团队风险
·关键人员风险
★风险识别的原则包括:
·由粗及细，由细及粗。
·严格界定风险内涵并考虑风险因素之间的相关性。
·先怀疑,后排除。
·排除与确认并重。对于肯定不能排除但又不能肯定予以确认的风险按确认考虑。必要时，可作实验论证
★【重要必看】风险管理中存在常见问题
·编制风险管理计划存在问题,未结合本项目的实际情况编制计划,仅参照以前的项目模板来编制;
·编制风险管理计划不由只由项目经理一个人来编制,应由项目团队和相关干系人共同参与,并经充分沟通和评审后才能发布实施;
·缺乏风险识别过程，没有对风险进行全面识别，以做好后续风险管理;
·缺乏风险的定性和定量分析过程，没有对风险进行详细分析，风险评估和控制缺少依据;
缺乏风险应对规划,没有提前制定好风险的规划应对措施,出现问题时只按各自理解对风险进行处理，导致项目问题不断;
·没有做好风险控制工作,对风险做再评估和审计及偏差趋势分析等,缺乏有效的风险监控的工具和技术;
·没有对进度风险及关联影响进行充分评估，在应对进度风险方面没有做好相应的准备和安排，也未预留储备
·没有做好技术绩效测量工作，及时进行评审和绩效对比，及时纠偏;
·在项目执行过程中，与客户缺乏沟通，这会产生很多不必要的项目风险和隐患;·风险管理计划也没有进行追踪检查和更新，没有及时记录和归档。
采购管理
★采购计划内容
·拟采用的合同类型;
·风险管理事项;
是否采用独立估算作为评估标准，由谁来准备独立估算、何时进行独立估算;
·如果项目的执行组织设有采购、合同或者发包部门，项目管理团队本身能采取哪些行动;
·标准的采购文件(如果需要的话);
-如何管理多个供应商;
如何协调采购与项目的其他方面，例如确定进度与绩效报告;
·可能对计划的采购造成影响的任何约束和假定;
·如何处理从卖方购买产品所需的提前订货期，并与他们一起协调项目进度制订过程;
·如何进行“自制/外购”决策，并与活动资源估算过程、制订进度计划过程联系起来;
·如何确定每个合同中规定的可交付成果的日期安排，并与进度制订过程、进度控制过程相协调;
·如何确定履约保证金或者保险合同，以减轻项目的风险;
·如何为卖方提供指导,以帮助其制订与维护工作分解结构;
·如何确定用于采购或合同工作说明书的形式和格式;
·如何识别通过资格预审的卖方;
·如何管理合同和评估卖方的衡量指标。
★企业采用外包管理模式的目的(或收益，也是差不多这么答）
·降低成本，降低企业组织的人事成本和获得服务所产生的成本降低
·提高效率
·取得专业知识
·改善服务
·获得额外的管理时间
·专注于核心服务、发挥核心竞争力等。
·品质改善
·转移风险
·资本投资减少
·现金流通
★采购管理中存在的问题
·没有做好规划采购工作，未制定合理的采购管理计划、供方选择标准等。
·没有没有编写采购工作说明书，未提前列明采购货物的质量等级、标准要求等。
·在实施采购过程中，仅凭价格低就选择卖方，未综合评价卖方综合情况，采购流程制度不规范。
·采购过程项目经理未重视采购管理，未说明采购备件的要求和参与采购过程监管。
·未将项目的进度与采购货物的时间进行综合考虑。
·库存规划不合理或库存管理混乱。
·未及时做好货物验收工作。
·未做好控制采购工作，应及时监控卖方绩效，有问题要及时纠偏，而不是等到临近交货或交货时才发现问题。
·未记录好采购过程中的相关采购文档和往来凭证，出问题难以找证据
·可能未在合同中规定交付验收标准、要求，或规定不合理，导致各种争议。
·合同中未规定索赔和违约条款，无法进行有效合同管理
·沟通存在问题，应充分做好会前准备工作，做好会议引导。
合同管理
★【重要必记】合同签订时应注意的内容及条款
·项目及产品目标和范围
·质量验收标准:质量验收标准是一个关键指标，包括产品质量及技术要求及验收流程、验收标准等。
·验收时间
·项目费用及工程款的支付方式
·合同变更约定
·技术支持服务
·损害赔偿
·合同附件
·法律公证
·违约责任以及发生争执的解决方式。
★合同管理可能出现的问题:
·没有签订合同或条款不全;
·合同条款约定不明（产品或服务范围目标，时间、地点、质量要求、费用等);
·没有做好签订合同之前的调查工作,合同签订过于草率
·没有采取措施，确保合同签约双方对合同条款的一致理解
·合同执行过程中没有留下相应的记录;
·项目变更中没有相应的进行合同变更;
·甲乙双方对项目范围没有达成一致认可或承诺;
缺少违约责任相关条款;
缺少变更处理相关条款;
·缺少索赔及纠纷处理条款
★合同问题的应对措施（主要针对需求和范围、验收标准等不清问题)
·重新梳理和确认需求，并获得各方认可
·梳理和确定范围、进度和质量方面的要求，并经双方同意确认，明晰验收标准
·和甲方明确合同，进行补充协议等。
必要时,应请求公司的高层和客户高层进行沟通协调,就合同的变更及项目的继续执行达成原则一致
·及时有效沟通，提前准备好各验收和收尾文档,向客户提交。
变更管理与控制
★【重要必记】变更的常见原因
·产品范围(成果)定义的过失或者疏忽;
·项目范围(工作)定义的过失或者疏忽;
·客户提出新需求;;
·应对风险的紧急措施或规避措施
·项目执行过程与项目基准要求不一致带来的被动调整（如进度、质量、成本等);
·项目团队人员调整;
·技术革新的要求;
·外部事件（例如政策变动或自然环境变化等)。
★【重要必记】项目变更有多种分类方式
(1）按变更性质分为重大变更、重要变更和一般变更，可通过不同审批权限控制。
(2）按变更的迫切性分为紧急变更和非紧急变更，可通过不同的变更处理流程进行控制。
(3）按变更所发生的领域和阶段，可分为进度变更、成本变更、质量变更、设计变更、实施变更和工作（产品)范围变更等。
(4）按变更来源可分为内部变更和外部变更等。
★【重要必记】变更管理工作程序（申请初审要论证，审查实施要监控，效果评估入轨道）
1.提出与接受变更申请
2.对变更的初审
3.变更方案论证
4.项目管理委员会审查
5.发出变更通知并组织实施
6.变更实施的监控
7.变更效果的评估
8.判断发生变更后的项目是否已纳入正常轨道
★没有做好变更可能的后果(影响)∶
·没有遵循正式的变更控制流程，可能导致需求变更的过程失控和不可追溯。
·没有对变更的影响进行完整的分析，可能导致无法全面了解这次变更对项目的进度、范围、成本、质量等造成多大的影响。
·没有修改项目管理计划,可能导致实际工作内容与计划有较大的偏差,使项目管理计划无法指导项目实施。
·没有对相应技术文档进行修改可能导致需求、设计与编码无法对应,不利于后期的测试和以后的维护工作。
·版本管理和配置管理没有做好，可能导致在变更失败后无法将项目恢复到变更前的状态。·没有让用户对最终结果进行确认,可能导致双方对变更结果的意见不一致,不利于项目验收和最终交付。
★【重要必看】变更管理可能出现的问题:
·未提交书面变更申请
·变更控制委员会组成成员不合理，应该包括客户代表，最好是高级管理人员，并明确分工
·几乎所有变更都被批准和接受，说明CCB没有严格控制项目变更申请的提交，没有认真审核
·应该对变更因素施加影响，积极沟通,确认变更的必要性
·没有进行变更后的评审,对变更造成的影响没有进行分析。
·没有将变更可能造成的影响告诉变更提出方(或对应的干系人)。
·没有严格按照变更控制流程进行变更管理。
·没有对变更作记录并形成文档,造成变更内容无法追溯。
·变更批准后，没有及时更新相应的项目计划和文件，导致内容不一致·变更结果没有进行正式验证，未得到客户的确认
·是否接受或拒绝变更,不应该由项目经理（或某个人)决定;
·项目变更后没有相应的变更合同。
★变更问题应对:
·邀请客户的代表、相关业务领导及高层领导等加入变更控制委员会。
·对变更施加影响,确认变更的必要性,积极同干系人进行沟通。
·对变更进行评审论证,确定变更的信息完整，实际可行。
·分析变更造成的进度、成本、质量等方面的影响，并告知相关人员。
·要对变更的实施进行监控跟踪，记录变更信息并形成文档，以便于追溯。
·要对变更的效果进行评估。
·严格按照变更控制流程进行变更管理,对于不必要的变更申请应拒绝,确保批准的变更的有效性。
·变更应进行严格验证，并得到相关干系人的确认。
配置管理
★配置管理的目标
配置管理是为了系统地控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性
★【重要必记】配置管理包括6个主要活动(工作)（计标控，报审发）
制定配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付。
★配置项的内容
1.外部交付的软件产品和数据
2.指定的内部软件工作产品和数据、指定的用于创建或支持软件产品的支持工具、供方/供应商提供的软件和客户提供的设备/软件。
典型配置项包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入配置管理。
★【重要必记】配置项的状态有三种:草稿、正式发布和正在修改。
★【重要必记】配置库
·开发库(动态库)∶存放开发过程中需要保留的各种信息。
·受控库(主库)∶存放某个阶段的成果，库内信息的读写和修改都受限。
·产品库（静态库)∶形成最终产品，等待交付或现场安装。库内信息严格受限。
·备份库:重要配置信息的备份，应急时恢复受损的配置库数据
★【重要必记】配置库的主要作用:
1.记录与配置相关的所有信息，其中存放受控的软件配置项是很重要的内容。
⒉.利用库中的信息可评价变更的后果，这对变更控制有着重要的意义。
3.从库中可提取各种配置管理过程的管理信息。
★配置审计(主要功能
为了确保项目配置管理的有效性，体现了配置管理的最根本要求―—不允许出现任何混乱现象,例如:
·防止向用户提交不适合的产品，如交付了用户手册的不正确版本;
·发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更;
·找出各配置项间不匹配或不相容的现象;
·确认配置项己在所要求的质量控制审核之后纳入基线并入库保存;
·确认记录和文档保持着可追溯性。
★【重要必看】配置管理可能出现的问题: 20下
·未建立配置管理系统和机制，配置管理混乱
·未设置专门的配置管理员,对配置进行综合管理
·没有做好整体版本管理
·没有建立基线,导致需求、设计、编码无法对应
·没有做好变更管理
缺乏项目整体管理的权衡;
·缺乏各种单元测试和集成测试。
·配置管理人员经验不足
·对配置管理工具没有进行有效评估
·未进行配置工具使用及配置管理的培训
·未制定配置管理计划
·未建立配置管理机制及权限管理，配置管理较乱
·没有定义配置管理流程
★【重要必看】配置管理问题的应对措施（应如何做好配置管理)︰
·组建配置管理委员会，必要时加强对配置人员的培训或引进有经验人员
引进配置管理工具并进行有效评估
·制定有效的配置管理计划
·建立配置管理机制，严格进行权限管理
·做好配置工作，包括识别配置项、建立基础、做好版本管理等。
·定义合理的配置管理流程，制定合理的变更控制流程
·识别配置项，并为配置项建立惟一标识，保证其可追溯·建立配置基线，使重要配置项处于受控状态
·定期提交配置状态报告，改进配置管理方法
收尾管理
★【重要必记】收尾管理四类典型的工作（验收总结维护后评价）
·项目验收工作的主要内容包括:验收验收测试、系统试运行、系统文档验收以及项目终验。
·项目总结工作的主要内容包括∶检查项目团队成员及相关干系人是否按规定履行了所有职责;收集项目记录、分析项目成败、收集应吸取的教训;以及将项目信息存档供本组织将来使用等活动;并召开项目总结会。
系统维护工作的主要内容包括:信息系统日常维护工作、硬件产品更新、满足信息系统的新需求。
·项目后评价的主要内容包括:信息系统目标评价、信息系统过程评价、信息系统效益评价、信息系统可持续性评价。
★【重要必记】系统集成项目在验收阶段主要工作内容
1.验收测试:验收测试是对信息系统进行全面的测试，依照双方合同约定的系统环境，以确保系统的功能和技术设计满足建设方的功能需求和非功能需求，并能正常运行。验收测试阶段应包括编写验收测试用例，建立验收测试环境，全面执行验收测试，出具验收测试报告以及验收测试报告的签署。
⒉试运行:信息系统通过验收测试环节以后，可以开通系统试运行。系统试运行期间主要包括数据迁移、日常维护以及缺陷跟踪和修复等方面的工作内容。在试运行期间，甲乙双方可以进一步确定具体的工作内容并完成相应的交接工作。
3.系统文档验收 系统经过验收测试后，系统的文档应当逐步、全面地移交给客户。客户也可按照合同或者项目工作说明书的规定，对所交付的文档加以检查和评价;对不清晰的地方可以提出修改要求。在最终交付系统前，系统的所有文档都应当验收合格并经双方签字认可。
4.项目终验 在系统经过试运行以后的约定时间，例如三个月或者六个月，双方可以启动项目的最终验收工作。通常情况下，大型项目都分为试运行和最终验收两个步骤。对于一般项目而言，可以将系统测试和最终验收合并进行，但需要对最终验收的过程加以确认。 最终验收报告就是业主方认可承建方项目工作的最主要文件之一，这是确认项目工作结束的重要标志。对于信息系统而言，最终验收标志着项目的结束和售后服务的开始。 项目最终验收合格后，应该由双方的项目组撰写验收报告提请双方工作主管认可。这标志着项目组开发工作的结束和项目后续活动的开始。
★【重要必记】系统文件验收，所涉及文档（项目最终说明，维护产品质量）
·系统集成项目介绍。
·系统集成项目最终报告。
·信息系统说明手册。
·信息系统维护手册。
·软硬件产品说明书、质量保证书等。
★项目总结的主要意义:
·了解项目全过程的工作情况及相关的团队或成员的绩效状况。
·了解出现的问题并进行改进措施总结。
·了解项目全过程中出现的值得吸取的经验并进行总结。
·对总结后的文档进行讨论，通过后即存入公司知识库，从而纳入企业的过程资产。
★【重要必看】项目总结会（项目技术成本和进度，沟通问题和建议）
需要全体参与项目的成员都参加，并由全体讨论形成文件。项目总结会议所形成的文件一定要通过所有人的确认，任何有违此项原则的文件都不能作为项目总结会议的结果。一般的项目总结会应讨论如下内容:
·项目绩效:包括项目的完成情况、具体的项目计划完成率、项目目标的完成情况等，作为全体参与项目成员的共同成绩。
技术绩效∶最终的工作范围与项目初期的工作范围的比较结果是什么，工作范围上有什么变更，项目的相关变更是否合理，处理是否有效，变更是否对项目的质量、进度和成本有重大影响，项目的各项工作是否符合预计的质量标准，是否达到客户满意。
·成本绩效∶最终的项目成本与原始的项目预算费用,包括项目范围的有关变更增加的预算是否存在大的差距，项目盈利状况如何。这牵扯到项目组成员的绩效和奖金的分配。
·进度计划绩效:最终的项目进度与原始的项目进度计划比较结果是什么,进度为何提前或者延后，是什么原因造成这样的影响。
·项目的沟通:是否建立了完善并有效利用的沟通体系;是否让客户参与过项目决策和执行的工作;是否要求让客户定期检查项目的状况;与客户是否有定期的沟通和阶段总结会议，是否及时通知客户潜在的问题，并邀请客户参与问题的解决等;项目沟通计划完成情况如何;项目内部会议记录资料是否完备等。
·识别问题和解决问题:项目中发生的问题是否解决，问题的原因是否可以避免，如何改进·意见和建议:项目成员对项目管理本身和项目执行计划是否有合理化建议和意见,这些建议和意见是否得到大多数参与项目成员的认可，是否能在未来项目中予以改进。
★项目人员的转移的前提条件（步骤方式)∶
·项目团队成员的管理计划，也就是项目人力资源管理计划中描述所说的人员转移条件已经触发。
项目团队成员所承担的任务已完成，提交了经过确认的可交付物并已完成工作交接。
·项目经理与项目团队成员确认该成员的工作衔接已经告一段落或者已经完成。
·项目经理签发项目团队成员转移确认文件。
·项目经理签发项目团队成员的绩效考核文件。
·项目经理通知所有相关的干系人。
·若是项目收尾全体项目成员结束项目工作，应召开项目总结表彰大会，肯定项目的成绩、团队成员的业绩,同时总结项目的经验教训。
★项目收尾可能存在问题
·未制定规范的项目收尾规程
·没有做好验收前的准备工作，软件还存在缺陷，缺陷未经修复和确认便进入正式验收环节。
·在验收过程中未根据变更控制流程对软件进行修改，导致文档与软件不一致
·软件更新后没有对文档进行变更便交付给客户
·项目产品未经正式验收和确认，未签署验收报告就进行了项目总结
·项目总结报告未能反映项目的实际情况
·未经过正式规范的收尾就提前报告项目结束、可进行人员转移，给项目带来诸多风险
·项目总结会议没有让全部项目人员参与
·项目收尾时应提交的必要文件没有准备好，并经客户签收验证
·催收剩余款项没有正式和必要的依据
·项目收尾时与建设方的沟通工作没有做好
·项目在产品和项目工作上都还不满足收尾条件
服务管理
★服务级别协议
是指提供服务的企业与客户之间就服务的品质、水准、性能等方面所达成的双方共同认可的协议或契约。
典型的服务级别协议包括下列内容:
参与各方对所提供服务及协议有效期限的规定;
·服务提供期间的时间规定，包括测试、维护和升级;
·对用户数量、地点以及/或提供的相应硬件的服务的规定;
·对故障报告流程的说明,包括故障升级到更高水平支持的条件。应包括对故障报告期望的应答时间的规定;
·对变更请求流程的说明。可能包括完成例行的变更请求的期望时间;·对服务级别目标的规定;与服务相关的收费规定;
·用户责任的规定（用户培训、确保正确的桌面配置、没有不必要的软件、没有妨碍变更管理流程等);
·对解决与服务相关的不同意见的流程说明。
★IT服务生命周期由规划设计、部署实施、服务运营、持续改进和监督管理5个阶段组成，简称PIOIS。
·规划设计:从客户业务战略出发，以需求为中心，参照ITSS对IT服务进行全面系统的战略规划和设计，为IT服务的部署实施做好准备，以确保提供满足客户需求的IT服务;
·部署实施:在规划设计基础上，依据ITSS建立管理体系、部署专用工具及服务解决方案;
·服务运营∶根据服务部署情况，依据ITSS采用过程方法，全面管理基础设施、服务流程、人员和业务连续性，实现业务运营与IT服务运营融合;
·持续改进:根据服务运营的实际情况，定期评审IT服务满足业务运营的情况，以及IT服务本身存在的缺陷，提出改进策略和方案，并对IT服务进行重新规划设计和部署实施，以提高IT服务质量;
·监督管理:本阶段主要依据ITSS对IT服务服务质量进行评价，并对服务供方的服务过程、交付结果实施监督和绩效评估。
★运维团队建设中的可能存在的问题:
1.招聘人员时不能仅凭是否有设备维修经验，还应该注意综合能力的考核。
2.对新进人员缺少服务培训
3.在安排日常工作时，不应满负荷，防止因事假、病假等造成其它成员的超负荷工作
4.人员安排上应有后备人员安排,并形成人才梯次
5.项目经理未能给成员予必要的帮助和辅导
6.未建立团队基本规则，人员工作状态和行为随意
7.缺少团队建设活动
8.项目经理的管理意识弱，团队管理的核心不是不发生冲突，而是合作解决问题，提高成员和项目绩效。
项目集管理
★【重要必记】项目集
项目集定义为“经过协调管理以获取单独管理所无法取得的收益的一组相关联的项目、子项目集和项目集活动”。项目集内的所有项目通过共同的目标相关联，该目标对发起组织而言具有非常重要的战略意义。如果项目集各干系人有不同的目标，并且这些目标不具有协调收益的交付特征，只是在资金、技能、干系人等方面存在关联，则这些最好通过项目组合来管理。
★项目集经理监控和分析组件之间的相互依赖关系，以协助确定将这些组件作为项目集来管理的最佳方法。与这些依赖关系相关的行动包括:
(1）领导和协调共同的项目集活动，如跨所有项目集组件、工作或阶段的财务与采购。解决影响项目集内多个组件的资源限制和/或冲突问题。
(2)以一种可以体现项目集内所有活动的方式传递并报告给干系人。
(3）积极响应项目集内跨多个组件的风险。
(4)将项目集工作与影响和作用于单独的组件、组件群或项目集目的目标和组织（战略)方向保持一致。
(5）在共享的治理结构内解决范围、成本、进度、质量和风险影响。
(6）裁剪项目集管理活动、过程和接口，有效地处理项目集内的文化、社会经济、政治和环境差异。
★项目集管理与项目管理之间的关键区别是项目集的战略聚焦，以及项目集确保组织收益的实现。
★项目集治理涵盖了由发起组织对项目集战略进行定义、授权、监督和支持的体系和方法，是项目集发起组织确保项目集被有效和持续管理而执行的实践和流程。
★项目集治理主要包括以下具体内容:
(1)项目集指导委员会的建立。
(2)项目集指导委员会的职责界定。
(3)项目集治理和项目集管理之间的关系。
(4)与项目集治理相关的个人角色。
(5)项目集作为治理主体――项目集组件治理。
(6)其他支持项目集管理的治理活动。
★项目集路线图按照时间顺序以图形化的方式展现项目集预期发展方向,并在每个时间顺序事件建立系列的文档化标准，同时建立了项目集活动与预期收益之间的关系，以及项目集里程碑之间的关键依赖，传递业务战略与规划的优先级之间的连接。
★根据项目集收益的实现情况将项目集生命周期划分为项目集定义阶段、项目集收益交付阶段和项目集收尾阶段三个过程。
项目组合管理
★【重要必记】项目组合是将项目、项目集,以及其他方面的工作内容组合起来进行有效管理，以保证满足组织的战略性的业务目标。项目组合中的部件不见得要相互依赖或者直接相关。项目组合代表的组织的投资决策、项目优先级的排序以及资源的分配。
★项目组合包含项目集、项目、项目组合子集以及日常运作业务，其目的在于通过组合管理方式来实现组织的战略目标。项目集则是项目子集、项目以及日常运作业务的集合，组织通过项目集管理来支持项目组合管理。
★项目组合管理活动包括:
1)识别和确定组织的优先活动
2)确定项目治理和项目绩效管理的管理框架
3)衡量项目价值/项目利益
4)做出投资决策
5)管理风险、沟通、资源。
项目组合是组织战略意图、战略方向以及战略进展的体现形式。
★在组织级项目管理中，要求项目组合、项目集与项目与组织的战略方向保持一致;另一方面，三者为实现战略目标所做出的贡献又各有不同:
1.项目组合通过选择正确的项目集和项目、设定工作的优先级别并提供必需的资源的方式来促成组织的战略实现;
⒉项目集管理则是对其所包含的项目子集和项目的依赖关系进行有效管理，从而实现项目集的特定利益;
3.项目管理通过制定和实施集合来完成特定的工作范围，支持项目集和项目组合目标的实现，最终确保组织战略得以实现。
★实施项目组合管理的收益主要来自于以下几个方面:
(1)为公司项目管理标准的实施提供支持，从而使项目更容易按照预先确定的时间、预算和范围完成，带来成本节约。
(2)识别项目风险和资源约束，从而降低成本，带来成本节约。
(3)提供项目组合报告，为资源与投资分配划分优先级,从而使资源和资金的使用效率更高。
★项目组合治理管理包括对项目组合进行计划、定义、优化和批准，以及监督项目组合的执行情况，其目的在于支持组织级别的完整决策。项目组合治理管理主要包如下五个子过程:
(1）制定项目组合管理计划。制定项目组合管理计划包括定义项目组合的组件、建立项目组合管理和组织结构图以及制定项目组合管理计划。
2）定义项目组合。定义项目组合即创建合格的项目组合组件，并对组件进行持续评估、选择和设定优先级。
(3）优化项目组合。优化项目组合是对项目组合中的组件进行评审、分析和更改，通过不断优化平衡项目组合中的组件来达到组织的战略目标。
(4）批准项目组合。批准项目组合包括为准备项目组合组件的建议书分配资源、批准项目组合组件的资源申请、沟通项目组合中的决策结果。
(5）执行项目组合监督。执行项目组合监督即监督项目组合，以确保其与组织的战略目标保持一致。执行项目组合监督时需要根据项目组合路线图、交付所遇到的问题和风险、当前进度以及资源等条件对项目组合的绩效目标、项目组合组件的变更等作出决策。
★【重要必记】项目组合管理过程组
(1）定义过程组:过程组成包括∶设定组织战略和目标如何在一个项目组合中被实现;确定项目组合战略计划;确定项目组合结构和路径;定义和授权一个项目组合或者子项目组合;制订项目组合管理计划和子计划。
(2）调整过程组:由管理和优化项目组合的一些过程构成。本过程组确定如何在项目组合中对项目组合组件讲行分类、评估、选择，以便进行总结、修正或删除、管理。
(3)授权与控制过程组:包含决定如何授权的过程以及对进行中的项目组合进行监控的过程。这两个过程是所有项目组合管理过程的核心，是能让项目组合作为一个整体来执行，从而实现组织定义的基准和过程步骤和必需的活动。
★项目组合风险管理过程主要包含制订项目组合风险管理计划以及管理项目组合风险两个子过程
(1）制订项目组合风险管理计划:包括识别项目组合的风险、风险责任人、风险承受能力以及风险管理过程。
(2）管理项目组合风险:执行项目组合风险管理计划，包括风险评估、风险响应以及监督风险。
信息系统安全管理
★信息系统安全策略是指针对本单位的计算机业务应用信息系统的安全风险(安全威胁）进行有效的识别、评估后，所采取的各种措施、手段，以及建立的各种管理制度、规章等。由此可见，一个单位的安全策略一定是定制的,都是针对本单位的。
★安全策略的核心内容就是“七定”，即定方案、定岗、定位、定员、定目标、定制度、定工作流程。
★把信息系统的安全目标定位于“系统永不停机、数据永不丢失、网络永不瘫痪、信息永不泄密”，是错误的，是不现实的，也是不可能的。系统安全是相对的，是一个风险大小的问题。我们不能一厢情愿地追求所谓的绝对安全，而是要将安全风险控制在合理程度或允许的范围内。这就是风险度的观点。
★怎样才是适度安全，需要运用风险评估的方法才能得出结论。风险评估围绕威胁、资产、脆弱性、安全措施展开分析。在评估时不仅要考虑现有环境,还要考虑近期和远期发展变化趋势。同时，还要评估控制风险所需的安全代价。安全代价低，显然安全风险肯定很大;反之，安全风险要降得很低，安全的代价也就很大。这个代价不光指资金投入，包括系统性能下降、效率低下等引出的“代价”。一个好的信息安全保障系统的标志就是有效控制两者的“平衡点”，既能保证安全风险的有效控制,又使安全的代价可以接受。这个平衡点对于不同行业、不同单位、不同时间点都不一样，要实现“动态”控制。
木桶效应的观点∶是将整个信息系统比作一个木桶，其安全水平是由构成木桶的最短的那块木板决定的。同时，保护信息系统的各个安全要素是同等重要的，各方面要素均不容忽视。但是要强调的是，安全管理在所有要素中具有极其重要的地位。有人将安全管理的漏洞比作存在于木桶桶底的漏洞。如果安全管理有漏洞，其他安全措施即使投入再大也无济于事。
★安全与应用的依存关系
安全与应用是矛盾统一的。没有应用，就不会产生相应的安全需求;发生安全问题，就不能更好地开展应用。另外，安全是有代价的，不但会增加系统的开销，也会增加系统建设和运行的费用，同时还会规定对使用的限制，从而给应用带来不便。应用需要安全、安全为了应用。过分强调安全或者应用,都是有失偏颇的,都不是正确的态度。