高项案例分析必背内容

高项案例分析必背内容

立项管理

• 项目立项一般包括——项目建议与立项申请、项目可行性研究、项目评估与决策
• 项目建议书的内容
• 项目的必要性
• 项目的市场预测
• 项目预期成果的市场预测
• 项目建设必需条件
• 项目建议书的作用——国家或上级主管部门选择项目的依据，也是可行性研究的依据
• 信息系统项目的可行性研究包括：技术、经济、社会效益、运行环境、其他方面的可行性分析
• 项目评估的依据：项目建议书及批准文件、项目可行性研究报告、报送组织的申请报告及主管部门的初审意见、项目关键建设条件和工程等协议文件、必需的其他文件和资料

整合管理

1. 制定项目章程、制定项目管理计划、指导和管理项目工作、管理项目知识、监控项目运行、确定项目整体变更、结束项目或阶段
2. 整合管理方面可能存在的问题
   1. 未制定项目章程或者项目章程未得到审批
   2. 项目经理未能得到授权，未能确定项目高层的范围、目标
   3. 没有制定项目管理计划
   4. 计划不能由项目经理一人制定，应全员参与
   5. 计划未经过评审和批准
   6. 项目经理执行不到位
   7. 对问题未能及时监控和分析，未能及时提出纠正、预防、缺陷补救措施
   8. 没有制定合理的整体变更流程
   9. 项目已经变更，计划或者基准未变更
   10. 未做好项目收尾工作，未能总结经验教训
   11. 没有做好项目监控工作，未能及时对比分析计划和实际执行情况
3. 项目章程的内容：项目的目的、项目的目标和成功标准、项目的退出标准、项目的可交付成果、主要干系人名单、项目的审批要求、总体的里程碑进度计划、财务资源、委任的项目经理及其职责、发起人或者批准项目的人员名单和职权
4. 项目章程的作用
   1. 明确项目与组织战略目标之间的直接联系
   2. 确定项目的成立给项目一个合法的地位
   3. 展示组织对项目的承诺
5. 项目管理计划组件
   1. 各个子管理计划——范围、进度、成本、质量、需求、资源、沟通、干系人、采购、风险管理计划
   2. 基准——范围、进度、成本基准
   3. 其他组件——变更、配置管理计划、项目生命周期、开发方法、管理审查
6. 配置管理活动——识别配置项、记录并报告配置项状态、进行配置先核实与审计
7. 变更管理活动包括——识别变更、记录变更、做出变更决定、跟踪变更
8. 结束项目或阶段的工作
   1. 为达到阶段或项目的完工或退出标准所必须的行动和活动
   2. 为关闭项目合同协议或项目阶段合同协议所必需开展的活动
   3. 为完成收集项目或阶段激励、审计项目成败、管理知识分享和传递、总结经验教训、存档项目信息以供组织未来使用等工作所必须开展的活动
   4. 为向下一个阶段或者向生产和运营部门移交项目的产品、服务或成果所必须开展的行动和活动
   5. 收集关于改进或更新组织政策和程序的建议，并将它们发送给相应的组织部门
   6. 测量干系人的满意程度等

范围管理

1. 范围管理中存在的问题
   1. 没有制定范围管理计划和需求管理计划
   2. 没有做好需求收集、分析、调研等工作
   3. 没有做好需求跟踪工作
   4. 不能仅依据过去经验来编写范围说明书
   5. 项目范围说明书内容不全或者范围定义不充分
   6. 项目范围说明书不应由项目经理一人编写
   7. WBS及范围基准应该让项目团队和所有干系人一起来创建，而不是项目经理创建，导致工作遗漏
   8. 项目范围基准未经评审和审批
   9. 缺少范围确认等环节，项目成果等没有得到用户的正式确认和接受
   10. 范围变更没有规范的变更控制流程
   11. 项目变更实施钱没有及时变更合同
   12. 变更结果没有得到客户的确认
   13. 未做好范围控制工作，未对范围管理中的偏差和问题进行及时纠偏
2. 需求管理中存在的问题
   1. 对客户的需求获取不充分
   2. 没有按照规范的需求开发与需求管理的流程及内容开展需求工作
   3. 缺乏需求定义环节，没有定义出需求规格说明书
   4. 缺乏需求验证环节，没有请客户代表一起进行需求评审
   5. 没有制定范围和需求管理计划
   6. 没有求得干系人对需求的承诺
   7. 没有有效地管理需求变更控制
   8. 没有有效地维护对需求进行跟踪管理
   9. 没有及时识别项目工作与需求之间的不一致性
3. 需求管理问题应对措施
   1. 建立需求变更控制策略和需求变更控制流程
   2. 采用多种方式充分获取用户需求并进行详细的需求分析
   3. 形成需求规格说明书并与用户进行需求验证和评审
   4. 需求定稿建立基线，以后的需求变更必须走变更控制流程，并及时更新需求规格说明书和需求跟踪矩阵
   5. 编写需求跟踪矩阵，需求状态表等文档
   6. 在需求规格说明书基础上编制技术方案，并进行评审
   7. 定期不定期对项目绩效进行监督检查，找出问题原因并指导团队成员解决
4. 范围说明书内容——产品范围描述、验收标准、可交付成果、项目的除外责任、制约因素、假设条件
5. WBS分解方法
   1. 以项目生命周期各阶段作为分解的第二层，产品和可交付成果放在第三层
   2. 以主要可交付成果作为分解的第二层
   3. 纳入由项目团队以外的组织开发的各种较低层次组件。随后，作为外包工作的一部分，卖方须制定相应的合同WBS
6. WBS的表现形式有分级的树形和表格形式
   1. 树形结构图的WBS层次清晰、直观性和结构性强，但不容易修改，对大的、复杂的项目很难表示出项目的全貌
   2. 表格形式的直观性比较差，但能够反映出项目所有的工作要素
7. 分解WBS的原则——面向可交付成果、符合项目的范围、底层支持计划和决策、全员参与、元素有且只有一人负责、既包括项目管理工作，也包括分包出去的工作、控制在4-6层、并非一成不变。
8. 需求跟踪矩阵中记录的典型属性有——唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态和状态日期。
9. 范围基准——批准的项目范围说明书、WBS和WBS词典，项目范围的完成情况是根据项目管理计划来衡量的，产品范围的完成情况是根据产品需求来衡量的
10. WBS分解步骤
    1. 识别和分析可交付成果及相关工作
    2. 确定WBS的结构和分解方法
    3. 自上而下逐层分解
    4. 为WBS的组件制定和分配标识
    5. 核实WBS的分解是否恰当

进度管理

1. 规划进度管理、定义活动、排列活动顺序、估算活动持续时间、制定进度计划、控制进度
2. 进度管理可能出现的问题
   1. 团队成员没有及早参与，需求分析耗时长
   2. 经验不足，进度计划制定不准，没有采取有效的历时估算方法和网络计划技术，制定进度计划
   3. 考虑项目期间特定时期会对进度产生影响
   4. 在安排进度时未考虑法定节假日的因素
   5. 仅仅依靠历史项目来估算本项目的历时根据不充分
   6. 没有对项目的技术方案、管理计划进行详细的评审、需求没有经过确认
   7. 增加人员经验不足，沟通存在问题，加班使得人员的工作效率降低
3. 项目进度出现问题的解决方案
   1. 向公司申请增加资源，或使用经验丰富的员工
   2. 优化网络图，重排活动之间的顺序，压缩关键路径的长度
   3. 临时加班，尽可能补救耽误的时间或提升资源的利用率
   4. 将部分阶段的工作改为并行、内部流程优化
   5. 变更原来的进度计划，根绝前阶段的绩效，对后续工作重新估计，修订计划，并得到项目干系人的同意
   6. 加强同项目干系人的沟通
   7. 加强对交付物、项目阶段工作的及时检查和控制，避免后期出现返工
   8. 尽可能调配非关键路径上的资源用于关键路径上的任务
   9. 优化外包、采购等环节并全程监控
4. 缩短活动的工期
   1. 赶工，投入更多的资源或增加工作时间，以缩短关键活动的工期
   2. 快速跟进，并行施工，以缩短关键路径的长度
   3. 使用高素质的资源或经验更丰富的人员
   4. 减小活动范围或者降低活动要求
   5. 加强质量管理，及时发现问题，减少返工，从而缩短工期
   6. 改进技术或方法，提高生产效率
5. 进度压缩的技术有哪些？分析利弊？
   1. 赶工——增加资源，以最小的成本来压缩进度工作的一种技术，只适用于通过增加资源就能缩短持续时间的且位于关键路径上的活动。赶工并非切实可行，可能导致风险和成本的增加
   2. 快速跟进——将正常情况下按顺序进行的活动该为至少是部分并行开展，只适用于通过并行活动来缩短关键路径上的项目工期的情况。可能增加质量风险和项目成本
6. 确定依赖关系
   1. 强制性依赖关系
   2. 选择性依赖关系
   3. 外部依赖关系——项目的测试活动取决于外部硬件的到货
   4. 内部依赖关系——只有机器组装完毕，才能对其进行测试
7. 资源优化技术
   1. 资源平衡——导致关键路径改变
   2. 资源平滑——可能无法实现所有资源的优化
8. 进度计划包括的种类和用途
   1. 里程碑进度计划——里程碑图
   2. 概括性进度计划——横道图
   3. 详细进度计划——项目进度网络图
9. 进度落后，成本超支可以采取的措施
   1. 用高效人员替代低效人员
   2. 加班或者赶工在防范风险的情况下并行施工
   3. 减小活动范围或者降低活动要求
   4. 通过改进方法或技术提高生产效率
   5. 分析成本超支原因，再找出针对性的对策如改进方法、优化方案、提高效率等
10. 进度落后，成本节约
    1. 赶工加快进度
    2. 使用高效资源替换低效资源加快进度
    3. 改进方法，提高工作效率
11. 进度超前、成本超支
    1. 整个项目需要抽出部分人员以放缓工作进度
    2. 整个项目存在成本超支现象，需要采取控制成本措施
    3. 项目中区分不同的任务，采取不同的成本及进度措施
    4. 必要时调整成本基准
    5. 优化施工方案、提高效率、加强质量管理减少返工、加强沟通、降低成本
    6. 在确保进度按期完成的基础上，可以降低进度以节约成本
    7. 总结项目进度提前的经验，并记录，传播并推广到其他项目
12. 进度超前、成本节约
    1. 抽调部分人员用于其他项目
    2. 加强质量控制，密切监督项目
    3. 必要时调整计划或者基准等方法改进、或者改变相关计划

成本管理

1. 规划成本管理、成本估算、成本预算、控制成本
2. 成本估算的步骤
   1. 识别并分析构成成本的科目
   2. 根据已识别的项目成本构成科目，估算每一科目的成本大小
   3. 分析成本估算结果，找出可替代的成本，协调各种成本之间的比例关系
3. 成本预算所经过的步骤
   1. 将项目总成本分摊到WBS的各个工作包
   2. 将各个工作包成本再分摊到各项活动上
   3. 确定各项成本预算支出的时间计划及项目成本预算计划
4. 项目成本控制的目标
   1. 成本超支控制在可接受范围内
   2. 对造成成本基准变更的因素施加影响
   3. 及时处理变更请求
   4. 管理变更
   5. 防止出现未批准的变更
   6. 向干系人汇报已批准的变更
   7. 监督工作绩效
   8. 找出偏差
   9. 确保支出不超额
5. 成本类型
   1. 可变成本
   2. 固定成本
   3. 直接成本——归属于一个项目工作的成本，如项目团队差旅费、工资、项目使用的物料及设备使用费
   4. 间接成本——一般管理费用或几个项目工作担负的项目成本所分摊给本项目的费用，如税金、额外福利和保卫费用
   5. 机会成本
   6. 沉没成本
6. 应急储备
   1. 包含在成本基准内
   2. 应对已经接受的已识别风险
   3. 是预算的一部分，应对已知-未知的风险
7. 管理储备
   1. 应对项目中不可预见的工作
   2. 应对项目的未知-未知风险
   3. 不在成本基准中，但属于项目总预算和资金需求的一部分，使用前需得到高层管理者审批

质量管理

1. 规划质量管理、管理质量、控制质量
2. 质量管理可能遇到的问题
   1. 没有制定质量管理计划
   2. 质量职责分配不合理，没有QA或者QA不独立与项目组，或者QA没有全程参与项目
   3. 管理质量活动做的不到位，或未实施管理质量
   4. 质量控制缺少必要的环节如评审、测试
   5. 质量控制方法不合理
   6. 没有按照变更流程的要求处理质量标准或验收标准的变更
   7. 项目经理再质量管理方面经验不足或质量保证人员经验不足
   8. 没有建立质量的保证体系
   9. 缺乏质量标准和质量规范
   10. 在质量管理中，没有采用合适的工具、技术和方法
   11. 测试过程中配置管理工作未到位
   12. 项目在重大里程碑处没有设置阶段成果评审，无法确保结果和预期目标一致
   13. 技术评审会没有达到预期目标
   14. 设计文件没有经过正式评审，可能没有发现设计文件的错误
   15. 需求评审没有客户参与或没做好，导致最终需求不能达成一致
   16. 项目团队成员缺乏质量意识
   17. 与客户沟通存在问题，方式单一，导致用户不必要的担心
3. 针对质量问题提出的解决措施
   1. 使用相关行业经验、项目经验和质量管理经验丰富的质量管理人员
   2. 制定和实施科学的质量管理计划
   3. 重视软件项目的测试环节，安排必要的时间，采用合理方法进行充分测试
   4. 重视软件开发过程中的管理质量工作，采用相应的工具和技术，避免将检查、测试作为项目质量保证的唯一方法
   5. 加强需求和设计方案的评审和质量控制工作
   6. 加强项目实施过程中的配置管理
   7. 建立项目的质量管理体系，包括制定可行的过程规范和质量目标、质量标准
   8. 对发现的缺陷进行统计分析，确保软件质量，提出合理有效的质量整改措施
   9. 为项目组成员提供质量管理方面的培训
   10. 加强与客户在质量管理方面的沟通和交流
4. 管理质量与质量控制的具体内容和区别
   1. 管理质量——针对过程改进和审计，强调的是过程改进和信息保证
   2. 实施质量控制——按照质量要求、检查具体可交付成果的质量，强调的是具体的可交付成果
   3. 联系
      1. 都是为了保证项目及产品符合质量要求
      2. 管理质量和质量控制都应贯穿项目始终
      3. 管理质量为质量控制提供更好的保证和条件，同时质量控制的结果也是管理质量过程的输入
5. 确认范围与质量管理的不同之处
   1. 确认范围——强调可交付成果获得客户或发起人的接受，质量控制强调可交付成果的正确性
   2. 质量控制一般在确认范围前进行，也可同时进行
   3. 质量控制属于内部检查，由执行组织的相应质量部门实施，确认范围则是由外部干系人对项目可交付成果进行检查验收
6. 质量管理计划内容——质量标准、质量目标、质量角色和职责、质量审查的项目可交付成果和目标、为项目规划的质量控制和管理活动、项目使用的质量工具、与项目有关的主要程序
7. 质量成本
   1. 一致性成本
      1. 预防成本——培训、文件过程、设备、完成时间
      2. 评估成本——测试、破坏性试验损失
      3. 检查
   2. 非一致性成本
      1. 内部失败成本——返工、报废
      2. 外部失败成本——债务、保修工作、失去业务
8. 质量与等级的概念
   1. 质量——一系列内在特性满足要求的程度
   2. 等级——对用途相同但技术特性不同的可交付成果的级别分类
   3. 低等级、高质量的产品，适合一般使用，可以被认可
   4. 高等级、低质量的产品，会因质量低劣而无效或低效，不会被使用者接受
9. 质量审计的目标
   1. 识别全部正在实施的良好实践
   2. 识别所有违规做法、差距和不足
   3. 分享所在组织或行业中类似项目的良好实践
   4. 积极主动地提供帮助，以改进过程的执行，从而帮助团队提高生产效率
   5. 强调每次审计都应该对组织的经验教训知识库做出贡献
10. 帕累托图，识别造成大多数问题的少数重要原因，又称28法则，80%的问题是20%的原因造成的

资源管理

1. 规划资源管理、估算活动资源、获取资源、建设团队、管理团队、控制资源
2. 资源可能出现的问题
   1. 缺乏足够的项目管理能力和经验
   2. 兼职过多，精力和时间都不够用，顾此失彼
   3. 没有进入管理角色，定位错误，疏于对项目的管理
   4. 新人缺乏培训和全程的跟踪和监控
   5. 没有进行良好的冲突管理
   6. 组建团队出现问题
   7. 建设团队出现问题
   8. 没有清楚地分配工作职责到个人或人力单元
   9. 没有对人员实行绩效考核或相应的激励机制
   10. 团队管理存在问题，主要是没有及时发现冲突并分析原因，采取有效的冲突管理
   11. 招募不到适合的项目成员
   12. 团队的组成人员很难合作
   13. 团队气氛不积极，造成项目团队成员士气低落
   14. 项目团队的任务和职责分配不清楚
   15. 人员流动过于频繁
   16. 未制定共识并遵守团队的规则
3. 资源问题的应对措施
   1. 采用合适的团队建设手段，消除团队成员间的隔阂
   2. 明确项目团队的目标及项目组各成员的分工
   3. 建立清晰的工作流程和沟通机制
   4. 建立明确的考核评价标准
   5. 建立并不断强化项目的目标
   6. 制定并组织规则和规律
   7. 积极做团队建设活动，保持良好的团队氛围，分享和开放的沟通
   8. 制定有效的激励措施
4. 资源管理计划的内容——识别资源、获取资源、角色与职责、项目组织图、项目团队资源管理、培训、团队建设、资源控制、认可计划
5. 团队章程——团队创建团队价值观、共识和工作指南的文件，包括：团队价值观、沟通指南、决策标准和过程、冲突处理过程、会议指南和团队共识
6. 虚拟团队模式的优点
   1. 使不同地理位置的员工组建团队
   2. 为项目团队增加技能，即使专家不在同一地理区域
   3. 将在家办公的员工纳入团队
   4. 将不同工作班次、工作小时、工作日的员工纳入团队
   5. 将行动不便者或者残疾人纳入团队
   6. 执行那些原本因为差旅费过高而被搁置的项目
   7. 节省所需办公室和所有办公设备的开支
7. 团队建设5个阶段
   1. 形成——一个个的个体转变为团队成员，逐渐相互认识并了解项目的情况，形成共同目标
   2. 震荡——团队成员开始执行分配的任务，个体之间开始争执，相互指责，开始怀疑项目经历的能力
   3. 规范——经过一段时间的磨合，开始协同工作，相互信任，项目经理能够得到团队的认可
   4. 发挥——团队成员之间相互、依靠、平稳高效地解决问题，集体荣誉感会非常强
   5. 解散——项目结束、团队解散
8. 影响冲突解决方法的因素
   1. 冲突的重要性和激烈程度
   2. 解决冲突的紧迫性
   3. 涉及冲突的人员的相对权力
   4. 维持良好关系的重要性
   5. 永久或暂时解决冲突的动机
9. 冲突解决方法
   1. 撤退、回避——从实际或潜在冲突中退出，将问题推迟到准备充分的时候，或者将问题推给其他人解决
   2. 缓和、包容——强调一致而非差异，为维持和谐关系而退让一步
   3. 妥协、调解——为暂时或部分解决冲突，寻找能让各方都在一定程度上接受的方案，会导致双输局面
   4. 强迫、命令——以牺牲其他方为代价，推行某一方的观点，只提供输赢方案。通常是利用权力来强行解决问题，会导致输赢的局面
   5. 合作、解决问题——综合考虑不同的观点和意见，采用合作的态度和开放式对话引导各方达成共识和承诺，双赢的局面
10. X理论——好逸恶劳、自我为中心、安于现状、易被人煽动、反对革命、工作动机就是为了获得报酬
11. Y理论——热爱工作、自我控制、主动承担责任、有创造力、渴望发挥才能
12. 马斯洛的需求层次理论
    1. 生理需求——员工宿舍、工作餐、工作服、班车、工资、奖金、补贴
    2. 安全需求——养老保险、医疗保障、长期劳动合同、意外保险、失业保险
    3. 社会交往的需求——定期员工活动、聚会、比赛、俱乐部等
    4. 受尊重的需求——颁发奖章、作为导师培训别人
    5. 自我实现的需求——给他更多的空间让他负责、成为智囊团、参与决策、参与公司的管理会议
13. 项目经理5中权力来源
    1. 职位权力——管理者在组织中的职位和职权
    2. 惩罚权力——使用降职、扣薪、惩罚、批评、威胁等负面手段的能力
    3. 奖励权力——给予下属奖励的能力
    4. 专家权力——来源于个人的专业技能
    5. 参照权力——由于成为别人学习参照榜样所拥有的权力
14. 控制资源关注哪些方面
    1. 监督资源支出
    2. 即使识别和处理资源缺乏/剩余情况
    3. 确保根据计划和项目需求使用并释放资源
    4. 出现资源相关问题时通知相应干系人
    5. 影响可以导致资源使用变更的因素
    6. 在变更实际发生时对其进行管理

沟通、干系人管理

沟通管理

1. 规划沟通管理、管理沟通、控制沟通
2. 识别干系人、规划干系人参与、管理干系人参与、控制干系人参与
3. 沟通管理可能出现的问题
   1. 内部管理有问题，监管不力
   2. 没有或极少与客户进行直接沟通
   3. 现场管理制度执行不力
   4. 总包与分包责任不清
   5. 客户获取的信息失真，总包推卸责任
   6. 客户自身的问题，包括资金、管理水平等
   7. 监理工作没到位
4. 沟通管理应对措施
   1. 做好干系人分析
   2. 发挥总包的牵头和监理的协调作用
   3. 对共用资源可用性进行分析，引入资源日历
   4. 解决冲突
   5. 建立健全项目管理制度并监督执行
   6. 采用项目管理信息系统
5. 沟通管理计划内容
   1. 干系人的沟通需求
   2. 需沟通的信息
   3. 上报步骤
   4. 发布信息的原因
   5. 发布所需信息、确认已收到或作出回应的时限和频率
   6. 负责沟通相关信息的人员
   7. 负责授权保密信息发布的人员
   8. 接受信息的人员或群体
   9. 用于传递信息的方法或技术
   10. 为沟通活动分配的资源，包括时间和预算
   11. 随着项目进展而更新与优化沟通管理计划的方法
   12. 通用术语表
   13. 项目信息流向图、工作流程、报告清单和会议计划等
   14. 来自法律法规、技术、组织政策等的制约因素等
6. 沟通方法
   1. 互动沟通——会议、电话、社交媒体和视频会议
   2. 推式沟通——信件、备忘录、报告、电子邮件、传真、语音邮件、博客和新闻稿
   3. 拉式沟通——适用于大量复杂信息或大量信息受众的情况，门户网站、组织内网、电子在线课程、经验教训知识库
7. 权力利益方格
   1. 权力高、利益低——令其满意
   2. 权力高、利益高——重点管理
   3. 权力低、利益低——监督，花最少精力
   4. 权力低、利益高——随时告知

风险管理

1. 规划风险管理、风险识别、风险定性分析、风险定量分析、规划风险应对、实施风险应对、控制风险
2. 常见问题
   1. 未结合本项目的实际情况编制计划，仅参照以前的项目模板来编制
   2. 编制风险管理计划不能只有项目经理一人，应由项目团队和相关干系人共同参与，并充分沟通和评审后才能发布实施
   3. 缺乏风险识别过程，没有对风险进行全面识别，以做好后续风险管理
   4. 缺乏风险的定性和定量分析过程，没有对风险进行详细分析，风险评估和控制缺少依据
   5. 缺乏风险应对规划，没有提前制定好风险的规划应对措施，出现问题时只按各自理解对风险进行处理，导致问题不断
   6. 没有做好风险控制工作，对风险做再评估和审计及偏差趋势分析等，缺乏有效的风险监控的工具和技术
   7. 没有对进度风险及关联影响进行充分评估，在应对进度风险方面没有做好相应的准备和安排，也未预留储备
   8. 没有做好技术绩效测量工作，及时进行评审和绩效对比，及时纠偏
   9. 在项目执行过程中，与客户缺少沟通，这会产生很多不必要的项目风险和隐患
   10. 风险管理计划也没有进行追踪检查和更新，没有及时记录和归档
3. 内容——风险管理策略、方法论、角色和职责、资金、时间安排、风险类别、干系人风险偏好、风险概率和影响、概率和影响矩阵、报告格式、跟踪
4. 应对措施
   1. 积极风险——上报、开拓、分享、提高、接受
   2. 消极风险——上报、规避、转移、减轻、接受

采购管理

1. 规划采购管理、管理采购、控制采购
2. 采购中存在的问题
   1. 没有做好采购管理计划，未制定合理的采购管理计划、供方选择标准等
   2. 没有编写采购工作说明书，未提前列明采购货物的质量等级、标准要求等
   3. 在实施采购中，仅凭借价格低就选择卖方，未综合评价卖方综合情况，采购流程制度不规范
   4. 采购过程项目经理未重视采购管理，未说明采购备件的要求和参与采购过程监督
   5. 未将项目的进度与采购货物的时间进行综合考虑
   6. 库存规划不合理或库存管理混乱
   7. 未及时做好货物验收工作
   8. 为做好控制采购工作，应及时监控卖方绩效，有问题要及时纠偏，而不是等到临近交货或交货时才发现问题
   9. 未记录号采购过程中的相关采购文档和往来凭证，出问题难以找证据
   10. 可能为在合同中规定交付验收标准、要求，或规定不合理，导致各种争议
   11. 合同中未规定索赔和违约条款，无法进行有效合同管理
   12. 沟通存在问题，应充分做好会前准备工作，做好会议引导
3. 采购步骤
   1. 准备采购工作说明书SOW或工作大纲TOR
   2. 准备高层级的成本估算，制定预算
   3. 发布招标广告
   4. 确定合格卖方的名单
   5. 准备并发布招标文件
   6. 由卖方准备并提交建议书
   7. 对建议书开展技术评估
   8. 对建议书开展成本评估
   9. 准备最终的综合评估报告，选出中标建议书
   10. 结束谈判，买方和卖方签署合同
4. 招标文件有哪些？——信息邀请书、报价邀请书、建议邀请书
5. 采购管理过程——规划采购管理、实施采购、控制采购
6. 按照项目范围划分，合同分为项目总承包合同、项目单项承包合同、项目分包合同
7. 以项目付款方式分，总价类、成本补偿类、混合型的工料合同
   1. 总价合同
      1. 固定总价
      2. 总价加激励费用
      3. 总价加经济价格调整
      4. 订购单（单边合同）
   2. 成本补偿合同
      1. 成本加固定费用合同
      2. 成本价激励费用
      3. 成本加奖励费用
   3. 合同管理——签订合同、合同履约管理、合同变更管理、合同档案管理、合同违约索赔管理
8. 索赔流程
   1. 提出索赔要求
   2. 报送索赔材料
   3. 监理工程师答复
   4. 索赔认可
   5. 持续索赔
   6. 仲裁与诉讼
9. 政府采购方式——公开招标、邀请招标、竞争性谈判、单一来源采购、询价、其他

配置管理

1. 制定配置管理计划、配置项识别、配置项控制、配置状态报告、配置项审计、配置管理回顾与改进
2. 常见问题
   1. 未建立配置管理系统和机制，配置管理混乱
   2. 未设置专门的配置管理员，对配置进行综合管理
   3. 没有做好整体版本管理
   4. 没有建立基线，导致需求、涉及、编码无法对应
   5. 没有做好变更管理
   6. 缺乏项目整体管理的权衡
   7. 缺乏各种单元测试和集成测试
   8. 配置管理，人员经验不足
   9. 对配置管理工具没有进行有效评估
   10. 未进行配置管理工具及配置管理的培训
   11. 未制定配置管理计划
   12. 未建立配置管理机制及权限管理，配置管理混乱
   13. 没有定义配置管理流程
3. 应对措施
   1. 组建配置管理委员会，必要时加强对配置人员的培训或引进有经验人员
   2. 引进配置管理工具并进行有效评估
   3. 制定有效的配置管理计划
   4. 建立配置管理机制，严格进行权限管理
   5. 做好配置工作，包括识别配置项、建立基础、做好版本管理等
   6. 定义合理的配置管理流程，制定合理的变更控制流程
   7. 识别配置项，并为配置项建立唯一标识，保证其可追溯
   8. 建立配置基线，使重要配置项处于受控状态
   9. 定期提交配置状态报告，改进配置管理方法
4. 典型的配置项——项目计划书、技术解决方案、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据、设备型号及其关键部件等
5. 配置项的状态——草稿——经过评审后——正式发布——按照变更控制流程更改配置项——正在修改——评审后——正式发布
6. 配置库分为开发库、受控库（主库）、产品库（静态库、发行库、软件仓库）
7. 配置库的建库模式
   1. 配置项类型建库——通用软件的开发组织
   2. 按任务建库——专业软件的开发组织
8. 配置库变更控制流程
   1. 将待升级的基线从产品库中取出，放入受控库
   2. 程序员将欲修改的代码段从受控库中检出，放入自己的开发库中修改
   3. 程序员将开发库中修改好的代码段检入受控库
   4. 软件产品的升级修改工作全部完成后，将受控库的新基线存入产品库中
9. 功能配置审计——审计配置项的一致性
   1. 配置项的开发已圆满完成
   2. 配置项以达到配置标识中规定的性能和功能特征
   3. 配置项的操作和支持文档已完成并且使符合要求的
10. 物理配置审计——配置项的完整性
    1. 要交付的配置项是否存在
    2. 配置项中是否包含了所有必须的项目等
11. 配置审计的作用
    1. 防止向用户提交不适合的产品
    2. 发现不完善的实现
    3. 找出各配置项间不匹配或者不相容的现象
    4. 确认配置项一再所要求的质量控制审核之后纳入基线并入库保存
    5. 确认记录和文档的可追溯性

变更管理

1. 变更申请、变更初审、变更方案论证、变更审查、发布通知并实施、实施监控、效果评估、变更收尾
2. 变更管理出现的问题
   1. 未提交书面变更申请
   2. 变更控制委员会组成成员不合理们应该包括客户代表，最好是高级管理人员，并明确分工
   3. 几乎所有变更都被批准和接受，说明CCB没有严格控制项目变更申请的提交，没有认真审核
   4. 应该对变更因素施加影响，积极沟通，确认变更的必要性
   5. 没有进行变更后的评审，对变更造成的影响没有进行分析
   6. 没有将变更可能造成的影响高速变更提出方
   7. 没有严格按照变更控制流程进行变更管理
   8. 没有对变更作记录并形成文档，造成变更内容无法追溯
   9. 变更批准后，没有及时更新相应的项目计划和文件，导致内容不一致
   10. 变更结果没有进行正式验证，未得到客户的确认
   11. 是否接受或拒绝变更，不应该由项目经理一人决定
   12. 项目变更后没有相应的变更合同
3. 应对措施
   1. 邀请客户代表、相关业务领导及高层领导等加入变更控制委员会
   2. 对变更施加影响，确认变更的必要性，积极通干系人进行沟通
   3. 对变更进行评审论证，确定变更的信息完整，实际可行
   4. 分析变更造成的进度、成本、质量等方面的影响，并告知相关人员
   5. 要对变更的实施进行监控跟踪，记录变更信息并形成文档，以便于追溯
   6. 要对变更的效果进行评估
   7. 严格按照变更控制流程进行变更管理，对于不必要的变更申请应拒绝，确保批准的变更的有效性
   8. 变更应进行严格验证，并得到相关干系人的确认
4. 变更的决策机构是——CCB
   1. 成员——客户和实施方的决策人员
   2. 职责——是决策机构不是作业机构，通过评审手段来决定项目基准是否能变更，但不提供变更方案
5. 变更管理负责人也称变更经理，通常是变更管理过程解决方案的负责人，职责有
   1. 负责整个变更过程方案的结果
   2. 负责变更管理过程的监控
   3. 负责协调相关的资源，保障所有变更按照预定过程顺利进行
   4. 确定变更类型，组织变更计划和日程安排
   5. 管理变更的日程安排
   6. 变更实施完成之后的回顾和关闭
   7. 承担变更相关责任，并且具有相应权限
   8. 可能以逐级审批形式或团队会议的形式参与变更的风险评估和审批等
6. 变更涉及到的人员及职责
   1. 变更管理负责人
      1. 负责整个变更过程方案的结果
      2. 负责变更管理过程的监控
      3. 负责协调相关的资源，保障变更按照预定过程顺利运作
      4. 确定变更类型，组织变更计划和日程安排
      5. 管理变更的日程安排
      6. 变更实施之后的回顾和关闭
      7. 承担变更相关责任，并且具有相应权限
      8. 可能以逐级审批形式或团队会议的形式参与变更的风险评估和审批等
   2. 变更请求这
      1. 提交初步的变更方案和计划
      2. 初步评价变更的风险和影响，给变更请求设定适当的变更类型
      3. 对理解变更过程有能力要求
   3. 变更实施者
   4. 变更顾问委员会
   5. 项目经理和CCB