目录
1.
可研立项
6
1.1. 可行性研究报告的内容 6
1.2. 项目内部立项主要有几方面原因 6
2.
整体管理
6
2.1. 项目章程内容 6
2.2. 项目章程作用 7
2.3. 变更的流程 7
2.4. 变更的角色 & 职责 7
3.
范围管理
8
3.1. 范围说明书内容 8
3.2. WBS分解步骤 8
3.3. WBS分解原则 8
3.4. WBS 结构分为树型和列表型 8
4.
进度管理
8
4.1. 缩短工期的办法 8
4.2. 进度压缩 8
4.3. 资源平衡和资源平滑区别 9
4.4. 依赖关系 9
5.
成本管理
9
将项目总成本分摊到项目工作分解结构的各个工作包。 9
将各个工作包成本再分配到该工作包所包含的各项活动上。 9
确定各项成本预算支出的时间计划及项目成本预算计划。 9
6.
质量管理
9
6.1. 质量成本 9
6.2. 质量审计 10
6.3. 质量工具和技术 10
7.
人力资源管理
12
7.1. 好团队5个阶段 12
7.2. X,Y理论 12
7.3. 虚拟团队优缺点 12
7.4. 冲突的解决办法 13
7.5. 沟通方式 13
7.6. 权力利益方格 13
7.7. 干系人参与评估矩阵 14
8.
采购管理
14
9.
风险管理
14
9.1. 3法 14
9.2. 风险图解技术可包括: 14
9.3. 风险管理计划 14
9.4. 风险识别原则 15
10.
合同管理
15
10.1. 条款 15
10.2. 过程 15
10.3. 索赔流程 15
10.4. 合同分类 15
11.
配置管理
16
11.1. 过程 16
11.2. 3个库 16
11.3. 版本号 16
11.4. 配置审计 17
12.
计算题
17
12.1. 沟通渠道的总量 17
12.2. EMV 17
12.3. 加权系统 17
12.4. 进度 17
12.5. 挣值分析、预测技术 18
12.6. 投资回收期 18
12.7. 归一化评估结果 18
13.
案例万金油简版
18
14.
案例万金油详版
19
14.1. 可研过程中可能出现的问题 19
14.2. 整体管理可能的问题 19
14.3. 软件项目失控的可能问题 20
3.1.技术无法扩展 20
3.2.技术是错误的解决方案 20
3.3.技术不具有要求的功能性等。 20
7.1.开发商与客户的关系 20
7.2.销售人员与技术人员的关系 20
7.3.项目管理者与开发人员的关系等。 20
14.4. 范围管理可能问题 & 措施 20
14.5. 需求变更的可能问题 21
14.6. 进度管理可能问题 21
14.7. 成本管理可能问题 21
14.8. 项目质量管理可能问题 22
14.9. 应该怎么解决或提高项目质量 22
14.10. 人力资源可能问题 23
14.11. 团队组建常见问题 23
14.12. 沟通管理和干系人管理可能问题 24
14.13. 风险管理可能问题 24
14.14. 管配置管理问题 25
14.15. 变更中常见的问题 26
14.16. 合同管理里可能会出现的问题 26
14.17. 可能的收尾的问题 26
14.18. 外包的害处 27
14.19. 如何做好外包 27
1. 可研立项
1.1. 可行性研究报告的内容
项目概述
项目建设单位概况
需求分析和项目建设的必要性
总体建设方案
本期项目建设方案
项目招标方案
环保、消防、职业安全
项目组织机构和人员培训
项目实施迸度
投资估算和资金来源
效益与评价指标分析
项目风险与风险管理
1.2. 项目内部立项主要有几方面原因
第一，通过项目立项方式为项目分配资源。
第二，通过项目立项方式确定合理的项目绩效目标，有助于提升人员的积极性。
第三，以项目型工作方式，提升项目实施效率。
2. 整体管理
2.1. 项目章程内容
概括性的项目描述和项目产品描述。
项目目的或批准项目的理由，即为什么要做这个项目。
项目的总体要求，包括项目的总体范围和总体质量要求。
可测量的项目目标和相关的成功标准。
项目的主要风险，如项目的主要风险类别。
总体里程碑进度计划。
总体预算。
项目的审批要求，即在项目的规划、执行、监控和收尾过程中，应该由谁来做出哪种 批准。
委派的项目经理及其职责和职权。
发起人或其他批准项目章程的人员的姓名和职权。
2.2. 项目章程作用
确定项目经理，规定项目经理的权力。
正式确认项目的存在，给项目一个合法的地位。
规定项目的总体目标，包括范围、时间、成本和质量等。
通过叙述启动项目的理由，把项目与执行组织的日常经营运作及战略计划等联系起来。
项目管理计划内容
所使用的项目管理过程。
每个特定项目管理过程的实施程度。
完成这些项目的工具和技术的描述。
选择的项目的生命周期和相关的项目阶段。
如何用选定的过程来管理具体的项目。
如何执行工作来完成项目目标。
如何监督和控制变更。
如何实施配置管理。
如何维护项目绩效基线的完整性。
与项目干系人进行沟通的要求和技术。
为项目选择的生命周期模型。
为了解决某些遗留问题和未定的决策，对于其内容、严重程度和紧迫程度进行的关键管 理评审。
2.3. 变更的流程
提出变更申请
变更影响分析 项目经理在接到变更申请以后，首先要检查变更申请中需要填写的内容是否完备，然后对变更 申请进行影响分析。变更影响分析由项目经理负责，项目经理可以自己或指定人员完成，也可 以召集相关人员讨论完成。
CCB 审查批准
实施变更
监控变更实施
结束变更
2.4. 变更的角色 & 职责
项目经理：项目经理对项目负责，也对整个项目变更管理过程负责。项目经理负责变更申请的影响分析， 负责召开变更控制委员会会议，负责监控变更及已批准变更的正确实施等。
CCB：变更控制委员会是一个正式的组织，负责审查、评价、批准、推迟或否决项目变更。 CCB 由项目所涉及的多方人员共同组成，通常包括甲方和乙方的决策人员。
3. 范围管理
3.1. 范围说明书内容
项目目标
产品范围描述
项目需求
项目边界
项目的可交付成果
项目的制约因素
假设条件
3.2. WBS分解步骤
识别项目交付物和相关工作
对WBS的结构进行组织
对WBS进行分解
对WBS中各级工作单元分配标识符或编号
对当前的分解级别进行检验，以确保它们是必须的，而且是足够详细的。
3.3. WBS分解原则
在各层次上保持项目的完整性，避免遗漏必要的组成部分。
一个工作单元只能从属于某个上层单元，避免变叉从属。
相同层次的工作单元应有相同性质。
工作单元应能分开不同的责任者和不同工作内容。
便于项目管理进行计划和控制的管理需要。
最低层工作应该具有可比性，是可管理的，可定量检查的。
应包括项目管理工作，包括分包出去的工作。
WBS 的最低层次的工作单元是工作包。需要遵守 8/80 原则。
3.4. WBS 结构分为树型和列表型
树型层次清晰，非常直观，结构性很强，但是不容易修改， 适用于中小型项目。
列表型直观性差，适用于大型项目。
4. 进度管理
4.1. 缩短工期的办法
赶工，投入更多的资源或增加工作时间，以缩短关键活动的工期;
快速跟进，并行施工，以缩短关键路径的长度;
使用高素质的资源或经验更丰富的人员;
减小活动范围或降低活动要求;-----注意甲方同意
改进方法或技术，以提高生产效率;
加强质量管理，及时发现问题，减少返工，从而缩短工期。
4.2. 进度压缩
赶进度。对费用和进度进行权衡，确定如何在尽量少增加费用的前提下最大限度地缩 短项目所需时间。赶进度并非总能产生可行的方案，反而常常增加费用。
快速跟进。这种进度压缩技术通常同时进行按先后顺序的阶段或活动。快速跟进往往造 成返工，并通常会增加风险。
4.3. 资源平衡和资源平滑区别
资源平衡是一种进度网络分析技术，用于已经利用关键路线法分析过的进度模型之中。 资源平衡的用途是调整时间安排需要满足规定交工日期的计划活动，处理只有在某些时间才能 动用或只能动用有限数量的必要的共用或关键资源的局面，或者用于在项目工作具体时间段按 照某种水平均匀地使用选定资源。这种均匀使用资源的办法可能会改变原来的关键路线。
资源平滑对进度模型中的活动进行调整，从而使项目资源需求不超过预定的资源限制的一种技术。相对于资源平衡而言，资源平滑不会改变项目关键路径，完工日期也不会延迟。资 源平滑技术可能无法实现所有资源的优化。
4.4. 依赖关系
1)强制性依赖关系:是法律或合同要求的或工作的内在性质决定的依赖关系
2)选择性依赖关系:有时又称首选逻辑关系、优先逻辑关系或软逻辑关系。
3)外部依赖关系:是项目活动与非项目活动之间的依赖关系。这些依赖关系往往不在项目团队的控制范围内。例如，软件项目的测试活动取决于外部硬件的到货。
4)内部依赖关系:是项目活动之间的紧前关系，通常在项目团队的控制之中。
5. 成本管理
管理 & 应急储备
应急储备是是包含在成本基准内的一部分预算，用来应对已经接受的己识别风险，以及已经 制订应急或减轻措施的已识别风险。应急储备通常是预算的一部分，用来应对那些会影响项目 的“已知一未知”风险。
管理储备是为了管理控制的目的而特别留出的项目预算，用来应对项目范围中不可预见的工 作。管理储备用来应对会影响项目的“未知一未知”风险。管理储备不包括在成本基准中，但 属于项目总预算和资金需求的一部分，使用前需要得到高层管理者审批。
成本估算
识别并分析成本的构成科目
根据已识别的项目成本构成科目，估算每一科目的成本大小
分析成本估算结果，找出各种可以相互替代的成本，协调各种成本之间的比例关系。
成本预算
将项目总成本分摊到项目工作分解结构的各个工作包。
将各个工作包成本再分配到该工作包所包含的各项活动上。
确定各项成本预算支出的时间计划及项目成本预算计划。
6. 质量管理
6.1. 质量成本
预防成本：是指那些为保证产品符合需求条件，无产品缺陷而付出的成本。如，项目质量计划、 质量规划、质量控制计划、质量审计、设计审核、过程控制工程、质量度量、测试系统建立、质量培训、供应商评估等都是预防成本。
评估成本：是指为使工作符合要求目标而进行检查和检验评估所付出的成本。如，设计评估、收 货检验、采购检验、测试、测试结果的分析汇报等都是评估成本。
缺陷成本：又进一步分为内部的和外部的缺陷成本。
内部缺陷成本是指交货前弥补产品故障和失 效而发生在公司内的费用。如，产品替换、返工或修理、废料和废品、复测、缺陷诊断、内部 故障的纠正等都是内部缺陷成本。
外部缺陷成本是指发生在公司外部的费用，通常是由顾客提 出的要求。如，产品投诉评估、产品保修期投诉、退货、增加营销费用来弥补丢失的客户、废品召回、产品责任、客户回访解决问题等都是外部缺陷成本。
6.2. 质量审计
1)识别全部正在实施的良好及最佳实践;
2)识别全部违规做法、差距及不足;
3)分享所在组织或行业中类似项目的良好实践;
4)积极、主动地提供协助，以改进过程的执行，从而帮助团队提高生产效率;
5)强调每次审计都应对组织经验教训的积累做出贡献。
6.3. 质量工具和技术
7个老的质量工具散点图、直方图、帕累托图、因果图、以及流程图、表差表和控制图
7个新的质量工具：亲和图、过程决策程序图、关联图、树形图、优先矩阵、活动网络图、矩阵图
老7个
1)因果图，又称鱼骨图或石川馨图，用来追溯问题来源，回推到可行动的根本原因。通过看问 题陈述和问“为什么” 來发现原因，直到发现可行动的根本原因，或者列尽每根鱼骨上的合理 可能性。
2)流程图，也称过程图，用来显示在一个或多个输入转化成一个或多个输出的过程中，所需要 的步骤顺序和可能分支。
3)核查表，又称计数表，是用于收集数据的查对清单。
4)帕累托图，用于识别造成大多数问题的少数重要原因。排列图也被称为帕累托图，是按照发 生频率大小顺序绘制的直方图。表示有多少结果是由已确认类型或范畴的原因所造成的。按等 级排序的目的是指导如何采取主要纠正措施。该法则认为:相对来说数量较小的原因往往造成 绝大多数的问题或者缺陷。此项法则往往称为二八原理，即 80%的问题是 20%的原因所造成的。 也可使用帕累托图汇总各种类型的数据，进行二八分析。
5)直方图，用于描述集中趋势、分散程度和统计分布形状。可反映各变量的分布。每一栏代表 一个问题或情况的一个特征或属性。每个栏的高度代表该种特征或属性出现的相对频率。这种 工具通过各栏的形状和宽度来确定问题的根源。
6)控制图，可以判断某一过程处于控制之中还是处于失控状态。它是一种带控制界限的质量管 理图表。运用控制图的目的之一就是，通过观察控制图上产品质量特性值的分布状况，分析和 判断生产过程是否发生了异常。
7)散点图，可以显示两个变量之间是否有关系，一条斜线上的数据点距离越近， 两个变量之 间的相关性就越密切。
新7个
1）亲和图。针对某个问题，产生出可联成有组织的想法模式的各种创意。在项目管理中，使 用亲和图确定范围分解的结构，有助于 WBS 的制订。
2）过程决策程序图。用于理解一个目标与达成此目标的步骤之间的关系。PDPC 有助 于制订应急计划，因为它能帮助团队预测那些可能破坏目标实现的中间环节。
3)关联图。它是关系图的变种，有助于在包含相互交叉逻辑关系的中等复杂情形中创新性地 解决问题。
4)树形图也称系统图，可用于表现诸如 WBS、RBS 和 OBS 的层次分解结构。
5)优先矩阵。用来识别关键事项和合适的备选方案，并通过一系列决策，排列出备选方案的 优先顺序。先对标准排序和加权，再应用于所有备选方案，计算出数学得分，对备选方案排序。
6)活动网络图。进度网络图
7)矩阵图。一种质量管理和控制工具，使用矩阵结构对数据进行分析。在行列交叉的位置展 示因素、原因和目标之间的关系强弱。
7. 人力资源管理
7.1. 好团队5个阶段
形成阶段:—个个独立的个体成员转变为团队成员，开始形成共同目标，对未来团队往往 有美好的期待。
震荡阶段:团队成员开始执行分配的任务，一般会遇到超出预想的困难，希望被现实打破。 个体之间开始争执，互相指责，并且开始怀疑项目经理的能力。
规范阶段:经过一定时间的磨合，团队成员之间相互熟悉和了解，矛盾基本解决，项目经 理能够得到团队的认可。
发挥阶段:随着相互之间的配合默契和对项目经理的信任，成员积极工作，努力实现目标。 这时集体荣誉感非常强，常将团队换成第一称谓，如“我们那个组” “我们部门”等，并会努 力捍卫团队声誉。
结束阶段:随着项目的结束，团队也被遣散了。 不管目前团队处于什么阶段，新增加一个人或减少一个人，都是从形成阶段重新开始。
马斯洛理论
马斯洛的需求层次结构是心理学中的激励理论，包括人类需求的五级模型，通常被描绘成金字塔内的等级。从层次结构的底部向上，需求分别为：生理，安全，社交需要，尊重和自我实现。这种五阶段模式可分为不足需求和增长需求。前四个级别通常称为缺陷需求，而最高级别称为增长需求
7.2. X,Y理论
1)X 理论主要体现了独裁型管理者对人性的基本判断，这种假设认为:
一般人天性好逸恶劳，只要有可能就会逃避工作。
人生来就以自我为中心，漠视组织的要求。
人缺乏进取心，逃避责任，甘愿听从指挥，安于现状，没有创造性。
人们通常容易受骗，易受人煽动。
人们天生反对改革。
2)Y 理论对人性的假设与 X 理论完全相反，其主要观点为:
一般人天生并不是好逸恶劳，他们热爱工作，从工作得到满足感和成就感。
外来的控制和处罚对人们实现组织的目标不是一个有效的办法，下属能够自我确定目标， 自我指挥和自我控制。
在适当的条件下，人们愿意主动承担责任。
大多数人具有一定的想象力和创造力。
在现代社会中，人们的智慧和潜能只是部分地得到了发挥。
7.3. 虚拟团队优缺点
优点：
1在公司内部建立一个由不同地区员工组成的团队。
2为项目团队增加特殊技能的专家，即使这个专家不在本地。
3把在家办公的员工纳入虚拟团队，以协同工作。
4由不同班组员工组成一个虚拟团队。
5把行动不便或残疾的员工纳入团队。
6可以实施那些原本因为差旅费用过高而被忽略的项目。
缺点：
虚拟团队也有一些缺点，例如，可能产生误解、有孤立感、团队成员之间难以分享知识和经验、 采用通信技术也要花费成本等。
措施：
在建立一个虚拟团队时，制订一个可行的沟通计划就显得更加重要。
7.4. 冲突的解决办法
问题解决:问题解决就是冲突各方一起积极地定义问题、收集问题的信息、制定解决方案， 最后直到选择一个最合适的方案来解决冲突，此时为双赢或多赢。但在这个过程中，需要公开 地协商，这是冲突管理中最理想的一种方法.
合作:集合多方的观点和意见，得出一个多数人接受和承诺的冲突解决方案。
强制:强制就是以牺牲其他各方的观点为代价，强制采纳一方的观点。
妥协:妥协就是冲突的各方协商并且寻找一种能够使冲突各方都有一定程度满意、但冲突 各方没有任何一方完全满意、是一种都做一些让步的冲突解决方法。
求同存异:求同存异的方法就是冲突各方都关注他们一致的一面，而淡化不一致的一面。 一般求同存异要求保持一种友好的气氛，但是回避了解决冲突的根源。也就是让大家都冷静下 来，先把工作做完。
撤退:撤退就是把眼前的或潜在的冲突搁置起来，从冲突中撤退。
沟通和干系人
7.5. 沟通方式
参与讨论方式、征询方式、推销方式、叙述方式
以上四类沟通方式从参与者的观点看，参与讨论方式的控制力最弱，随后逐步 加强，以叙述方式的控制力最强。从参与者的观点看，其他参与者的参与程度 恰巧相反，也就是讨论方式下参与程度最高，然后逐步减弱，以叙述方式下参与程度最弱。 在发送方自认为已经掌握了足够的信息，有了自己的想法且不需要进一步听取多方意见时，往 往选择控制力极强、参与程度最弱的“叙述方式”;其次，选择“推销方式”，而当自己掌握信 息有限，没有完整成型的意见，需要更多的听取意见时，一般选择“讨论方式”或者“征询方 式”。
7.6. 权力利益方格
7.7. 干系人参与评估矩阵
8. 采购管理
招投标法和采购法相关日期记下，主要考选择
9. 风险管理
9.1. 3法
德尔菲法，也称专家调查法，其本质上是一种反馈匿名函询法，其大致流程是在对所要预测的问题征得专家的意见之后，进行整理、归纳、统计，再匿名反馈给各专家，再次征求意见，再集中，再反馈，直至得到一致的意见。
头脑风暴法，是指由美国BBDO广告公司的奥斯本首创，该方法主要由价值工程工作小组人员在正常融洽和不受任何限制的气氛中以会议形式进行讨论、座谈，打破常规，积极思考，畅所欲言，充分发表看法
所谓SWOT分析，即基于内外部竞争环境和竞争条件下的态势分析，就是将与研究对象密切相关的各种主要内部优势、劣势和外部的机会和威胁等，通过调查列举出来，并依照矩阵形式排列，然后用系统分析的思想，把各种因素相互匹配起来加以分析，从中得出一系列相应的结论，而结论通常带有一定的决策性。
9.2. 风险图解技术可包括:
因果图，又称石川图或鱼骨图，用于识别风险的起因。
系统或过程流程图，显示系统各要素之间的相互联系及因果传导机制。
影响图，用图形方式表示变量与结果之间的因果关系、事件时间顺序及其他关系。
9.3. 风险管理计划
方法论
角色与职责
预算
时间安排
风险类别
风险概率和影响的定义
概率和影响矩阵
修订的干系人承受力
报告格式
跟踪
9.4. 风险识别原则
由粗及细，由细及粗。
严格界定风险内涵并考虑风险因素之间的相关性。
先怀疑，后排除。
排除与确认并重。对于肯定不能排除但又不能肯定予以确认的风险按确认考虑。
必要时，可作实验论证。
10. 合同管理
10.1. 条款
范围
验收时间
验收标准
10.2. 过程
合同管理主要包括合同签订管理
合同履行管理
合同变更管理
合同档案管理
10.3. 索赔流程
提出索赔要求
提交索赔资料
索赔答复
索赔认可
提交索赔报告 或者:索赔分歧 提请仲裁
10.4. 合同分类
范围分
总承包合同
总承包合同也称“交钥匙承包”，发包人把信息系统工程建设从开始立项、论证、施工到竣 工的全部任务，一并发包给一个具备资质的承包人。这种承包方式有利于充分发挥那些在工程 建设方面具有较强的技术力量、丰富的经验和组织管理能力的大承包商的专业优势，保证工程 的质量和进度，提高投资效益。采用总承包的方式进行承包，发包人和承包人要签订总承包合 同。
分包合同
总承建单位将其承包的某一部分或某几部分项目，再发包给子承建单位。签订分包合同应 当同时具备两个条件:第一，承包人只能将自己承包的部分工程分包给具有相应资质条件的分 包人;第二，分包工程必须经过发包人同意。另外，还有只能将非关键、非主体部分进行分包， 而且不可以进行二次分包。
付款方式
总价合同
总价合同又称固定价格合同，是指在合同中确定一个完成项目的总价，承包人据此完成项 目全部合同内容的合同。这种合同类型能够使建设单位在评标时易于确定报价最低的承包商， 易于进行支付计算。适用于工程量不太大且能精确计算、工期较短、技术不太复杂、风险不大 的项目，同时要求发包人必须准备详细全面的设计图纸和各项说明，使承包人能准确计算工程量。
总价合同也可以为达到或超过项目目标而规定财务奖励条款。另外也允许根据条件变化，以事先确定的方式对合同价格进行最终调整。
工料合同
这类合同的适用范围比较宽，其风险可以得到合理的分摊，并且能鼓励承包人通过提高工 效等手段从成本节约中提高利润。这类合同履行中需要注意的问题是双方对实际工作量的确定。
成本补偿合同
成本加酬金合同，是由发包人向承包人支付工程项目的实际成本，并且按照事先约定的某 一种方式支付酬金的合同类型。在这类合同中，建设单位须承担项目实际发生的一切费用，因 此也承担了项目的全部风险。承建单位由于无风险，其报酬往往也较低。这类合同的缺点是建 设单位对工程造价不易控制，承建单位也往往不注意降低项目成本。
这类合同主要适用的项目有
需立即开展工作的项目。
对项目内容及技术经济指标未确定的项目。
风险大的项目。
11. 配置管理
11.1. 过程
制定配置管理计划、配置标识、配置控制、配置状态报告、配 置审计、发布管理和交付。
11.2. 3个库
开发库，也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体。 动态中的配置项被置于版本管理之下。动态库是开发人员的个人工作区，由开发人员自行控制。 库中的信息可能有较为频繁的修改，只要开发库的使用者认为有必要，无需对其进行配置控制，因为这通常不会影响到项目的其他部分。
受控库，也称为主库，包含当前的基线加上对基线的变更。受控库中的配置项被置于完全 的配置管理之下。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。
产品库,也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于 完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内， 等待交付用户或现场安装。
11.3. 版本号
处于“草稿”状态的配置项的版本号格式为 0.YZ。
处于“正式”状态的配置项的版本号格式为 X.Y。 配置项第一次成为“正式”文件时，版本号为 1.0。 如果配置项升级幅度比较小，可以将变动部分制作成配置项的附件，附件版本依次为 1.0，.1.1,......。当附件的变动积累到一定程度时，配置项的 Y 值可适量增加，Y 值增加一定程 度时，X 值将适量增加。当配置项升级幅度比较大时，才允许直接增大 X 值。
处于“修改”状态的配置项的版本号格式为 X.YZ。配置项正在修改时，一般只增大 Z 值， X.Y 值保持不变。当配置项修改完毕，状态成为“正式”时，将 Z 值设置为 0,增加 X.Y 值。
11.4. 配置审计
防止向用户提交不适合的产品，如交付了用户手册的不正确版本;
发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更;
找出各配置项间不匹配或不相容的现象;
确认配置项己在所要求的质量控制审核之后纳入基线并入库保存;
确认记录和文档保持着可追溯性。
12. 计算题
12.1. 沟通渠道的总量
n*/2；n为干系人数量
12.2. EMV
EMV=概率1*影响1+概率2*影响2+...+概率n*影响n；
投资或扩建方案，哪个利大选哪个，自制和外购决策，哪个便宜选哪个
12.3. 加权系统
12.4. 进度
总时差=LS-ES=LF-EF或用关键路径-当前活动所在的路径
自由时差=min
LF=LS+工期；EF=ES+工期
期望公式
期望时间=/6
标准差=/6
示意题：A任务持续时间悲观估计为36天，最大可能估计为21天，乐观估计为6天。那么A行为在16到26天之间完成的概率有多大？解答：
求出σ σ = / 6 = 5
期望时间=/6=21
由 σ可知 21+5=26 21-5=16， 因此16—26天落在1 σ分布内。
由1 σ的概率P为68.3可得答案为 68.3%
数值 -1σ~1σ=68.3%；-2σ~2σ=95%；-3σ~3σ=99%；
12.5. 挣值分析、预测技术
EV、PV、AC、BAC、CV、SV、EAC、ETC、CPI、SPI公式
CV=EV-AC>0节省，否则超支；SV=EV-PV>0提前，否则滞后
CPI=EV/AC>1节省，否则超支；SPI=EV/PV>1提前，否则落后
ETC=BAC-EV 非典型
ETC=/CPI典型 EAC=AC+ETC演化EAC=AC+BAC-EV——非典型；EAC=AC+/CPI 典型
VAC=BAC-EAC
12.6. 投资回收期
12.7. 归一化评估结果
13. 案例万金油简版
士气低落：团队建设没做好
客户投诉：沟通有问题，干系人没管理好
争吵：冲突没做好
加班：成本超支、质量有返工
时间/工期紧张：没有冗余思想
推诿扯皮：职责不清
不满意：沟通不畅
验收不通过：验收标准没定义好
变更：变更流程控制
新技术：存在风险
一个人编写计划：应该全员参与
多头汇报：项目经理权限问题
文档不清晰、混乱：文档配置没做好
不断提出新需求：需求蔓延
活动并行：存在风险
WBS 不熟悉:早期没有参与
项目文档:甲方是否参与、批准
过了很久:监控不力
项目章程发布:项目经理只能写，不能发布
外包商:监控不力
评审:甲方是否参与
方案:甲方是否批准
技术人员:项目经验不足
核心人员离职:团队管理有问题
身兼数职:管理经验不足，身心疲惫
14. 案例万金油详版
14.1. 可研过程中可能出现的问题
1．项目经理的技术经验不足
2．没有正式、书面的新产品研发项目建议书就开展可行性研究工作
3．新产品研发的可行性研究工作不充分，尤其缺少技术可行性分析和论证
4．研发过程中对人才缺乏、竟争对手等带来的风险缺乏充分的分析，没有合理有效的应对方案
5．没有新产品的初步设计方案就开始研发工作
6．新产品的需求和技术指标不应由领导把关，应进行外部评审
7．在项目启动前缺少对项目成本的估算或成本估算工作未到位
8．可行性研究报告缺少必要的内部论证或外部评估环节
9．没有制订综合、全面的项目管理计划，进度计划不能代替项目管理计划，领导的指示不能代替项目管理计划
10．项目发生进度延误的可能性时未及时调整或更新进度计划并与领导及相关各方沟通
11．前期立项工作中人员参与不充分，缺少关键技术人员和财务人员
14.2. 整体管理可能的问题
1．项目管理计划不应由一人制定，应有项目组参与。
2．项目计划缺少相关分计划，如质量计划、沟通计划等
3．制定进度计划的方法不合理，没有预留一定的缓冲时间。
4．项目计划缺少评审和审批环节。
5．没有处理好外部因素和内部因素带来的风险，缺乏有效的应对措施。
6．项目发生变更时没有及时更新项目计划。
7．应识别受设备到场所影响的活动，对于不受影响的活动不应推迟进行。
14.3. 软件项目失控的可能问题
1.需求不明确，即需求过多、需求不稳定、需模棱两可或需求不完整等。
2.不充分的计划和过于乐观的评估
2.1.工作责任范不明确，WBS 与项目组织结构不明确或者不对应，各成员之间的接ロ不明确，导致一些工作根本无人负责；
2.2.每个开发阶段的提交结果定义不明确，中间结果是否已经完成、完成了多少模不清，以致项目后期堆积了大量工作；
2.3.开发计划没有指定里程碑或检查点，也没有规定设计评期：
2.4.开发计划没有规定进度管理方法和职责，导致无法正常进行进度管理：
2.5.对工作量的重要性认识不足：软件开发经常会出现一些平时不可见的工作量，如人员的培训时间、各个开发阶段的评审时间等，经验不足的项目经理经常会遺：
2.6.出于容户或公司上层的压カ在工作量估算上予以妥协，例如客户威胁要用工数更少的开发商，公司因经营困难必须削减费用、缩短工期，最后只能妥协，寄布望于员工加班；
2.7.设计者过于自信或出于自尊心问题，对一些技术问题不够重视；
2.8.过分相信经验，没有具体分析就认为此次项目差不多，却没有想到此次项目有可能规模更大、项目成员更多且素质差异很大，或者项目出自于一个新的行业。
3.采用新技术，或关心创新而不关心费用和风险
3.1.技术无法扩展
3.2.技术是错误的解决方案
3.3.技术不具有要求的功能性等。
4.管理方法缺乏或不恰当。
5.性能问题。
6.团队组织不当
6.1.项目团队过小，所分配的技术人员水平达不到特定项目的要求；
6.2.项目团队缺少资源人员，从而设计能カ不足：
6.3.没有对分包商的设计能力仔细评价。
7.人际因素
7.1.开发商与客户的关系
7.2.销售人员与技术人员的关系
7.3.项目管理者与开发人员的关系等。
14.4. 范围管理可能问题 & 措施
问题
1．没有挖掘到全部隐性需求,缺乏精确的范围定义
2．没有有效的范围管理,造成二次变更
3．对范围控制不足
4．没有和客容户进行需求确认
5．没有制定范围管理计划或项目管理计划
6．变更结果没有得到容户的确认。
7．项目范围说明书内容不全面
8．没有及时评估容户提出的变更要求对项目带来的影响并与容户及时沟通
9．变更不应由项目经理审批,应有CCB审批
10．项目变更实施前没有及时变更合同
11．缺少范围确认环节
12．范围控制存在问题
措施
1．项目范围进行清晣定义，并根据定义对工作进行分解，制定WBS
2．对项目进行合理估算，对工作量有量化的把握
3．对项目范围进行有效控制
4．重新定义项目范围必须得到高层和容户的确认
5．进行沟通管理，协调多个项日干系人之间的矛盾
14.5. 需求变更的可能问题
1.没有按照严谨的变更控制流对整个需求变更做完整的记录和跟踪
2.对需求变更可能造成的影响进行全面的评估和分析
3.需求变更后没有修改项目管理计划并重新评审
4.配置管理工作没有做好
5.变更结果没有跟容户沟通
14.6. 进度管理可能问题
1.团队成员没有及早参与，需求分析耗时长，要早期参与进项目
2.经验不足，进度计划制定不准，没有采取有效的历时估算方法和网络计划技术，制定进度计划
3.没有考虑项目期间特定时期会对进度产生影响
4.増加资源有时可能压缩工期有限，1项任务10个人做，和10个人做一个项目的效果不一样
解决方案
1．増加人手，聘请更有经验的人员，或找兼职人员
2．加班
3．并行
4．重新估算后面的工期
5．加强沟通,减少变更
6．加强控制，避免返工
7．外包
8．加强沟通，先完成关键需求
9．关注关鍵路径，在关键路径上加资源
10．关注里程碑
11．加强进度与成本、风险、质量等知识点的协调
12．向公司中请増加资源，或使用经验丰富的员エ
13．优化网络图，重排活动之间的顺序，压缩关键路径
14．临时加班，尽可能补救耽误的时间或提高资源利用率
15．将部分阶段的工作改为并行，并进行内部流程的优化
16．变更原来的进度计划。根据上一阶段的绩效，对后续工作重新评估，修订计划，并征得项目干系人的同意
17．加强同项目千系人的沟通
18．加强对交付物、项目阶段工作的及时检查和控制，避免后期出现返工
19．尽可能调配非关键路径上的资源用于关键路径上的任务
20．优化外包，采购等环节，并全程监控。
14.7. 成本管理可能问题
1.没写成本管理计划
2.估算不准确
3.预算不准确
4.没做好成本控制
5.成本观念淡薄
6.指标没有量化
14.8. 项目质量管理可能问题
1．没有制定可行的质量管理计划并枳极实施
2．没有全面的质量管理进展情况报告
3．沟通方式单一或不全面，容易误导用户，导致用户不必要的担心
4．质量保证过程中缺乏QA的参与
5．质量控制环节缺失，例如评审和测试
6．测试方法不当或不充分
7．测试控制的流程不对,或测试安排的紧张，或末进行质量控制就进行了范围确认
8．没有进行质量保证
9．检查频率的设定有问题。
10．应加强项目过程中的质量控制或检査，不能等到工作产品完成后オ检查
11．QA发现问题应与当事人协商，如果无法达成一致要向项目经理或更高级别的领导汇报，而不能自作主张。
12．在质量管理中，没有与合适的技术手段相结合
13．对程序员在质量意识和质量管理的培训不足
14．职责分配不清楚
15．项目经理在项目质量管理方面的经验欠缺
16．进度计划制定的不合理
17．需求分析、系统设计阶段的质量控制可能不到位、缺少评审环节
18．测试过程中配置管理工作未到位
19．项目缺乏质量标准和质量规范
20．没有建立项目的质量保证体系
21．在质量管理中，没有采用合适的工具、技术和方法
14.9. 应该怎么解决或提高项目质量
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.提出合理有效的质量整改措施
14.10. 人力资源可能问题
1.缺乏足够的项目管理能カ和经验:
2.兼职过多，精力和时间不够用，顾此失彼:
3.没有进入管理角色，定位错误，疏于对项目的管理
4.新人缺乏培训和全程的跟踪和监控
5.没有进行良好 的冲突管理
1．事先制定岗位的要求、职责和选人的标准,并选择合适的人选:
2．对工作进行全面估算，如果有人负荷过重，需要找人代替，解决负载平衡问题
3．事前沟通并对相应人员明确要求，明确角色的轻重缓急，促使尽快转换角色
4．上级应该注意平时对人员的培养和监控
5．对项目团队进行有效的冲突管理
6．采用合适的团队建设手段，消除团队成员间隔
7．明确项目团队的目标及项目组各成员的分工
8．建立清晰的工作流程和沟通机制
9．建立明确的考核评价标准。
10．鼓励团队成员之间建立参与和分享的氛围。
11．制定有效的激励措施
14.11. 团队组建常见问题
问题
1.招募不到合适的项目成员:
2.团队的组成人员尽管富有オ千，但却很难合作
3.团队气氛不积极，造成项目团队成员的士气低落
4.项目团队的任务和职责分配不清楚
5.人员流动过于频繁
6.没有能够建立人カ资源获取和培养的稳定机制
7.没有完整识别项目所需的人力资源种类、数量和相关任职条件
8.没有建立一个能充分、有效发挥能力的团队
9.没有清楚地分配工作职责到个人或人力单元
措施
1．建立稳定的人力资源获取和培养机制
2．在项目早期，进行项目的整体人力资源规划，明确岗位设置、工作职责和协作关系
3．进行项目团队建设，加强团队沟通，建立合作氖围
4．根据项目团队成员的工作职责和目标，跟踪工作绩效，及时予以调整和改进，提升项目整体绩效
14.12. 沟通管理和干系人管理可能问题
问题
1.缺乏沟通，合作氛围不够
2.没有对团队成员的测通需求和沟通风格进行分析
3.没有开一个高效的会
4.沟通方式单一
5.没有冲突管理
6.内部管理有问题，监管不力
7.没有或极少与容户进行直接沟通
8.现场管理制度执行不力
9.总包与分包责任不清
10.容户获取的信息失真，总包推卸责任
11.客户自己本身的问题，包括资金、管理水平等
12.可能监理工作没到位
措施
1．及时信息分发，加强沟通，让客户了解项目具体情况
2．注重沟通技巧，建立融治的合作气氛
3．分析成员的沟通风格,从而采用相应的沟通方式
4．多种沟通方式
5．采用一些沟通模板
6．加强冲突管理
7．采用一些沟通模板
8．加强冲突管理
9．多供应商的沟通
10．解決冲突，包括千系人对项目期望之间的冲突、资源冲突等
11．做好干系人分析，调研各集成商的沟通需求
12．周期性的沟通
13．突发事件的协调
14．发挥总包的牵头和监理的协调作用
15．对共用资源可用性进行分析，引入资源日历
16．建立健全项目管理制度并监管其执行
17．采用项目管理信息系统
14.13. 风险管理可能问题
问题
1.没有正确理解业务问题
2.用户不能恰当的使用系统
3.拒绝需求变更
4.对工作的分析和评估不足
5.人员流动
6.缺乏合适的开发工具
7.缺乏合适的开发与实施人员
8.缺乏适合的开发平台
9.使用了过时的技术
原因
1．项目干系人对业务问题的认识不足、计算起来过于复杂、不合理的业务压力、不现实的期限
2．信息系统没有与组合战略相结合、对用户没有做足够的解释、帮助手册编写的不好、用户培训工作做的不够
3．固定的预算、固定的期限、决策者对市场和技术缺乏正确的理解
4．缺乏项目管理经验、工作压力过大、对项目工作不满意
5．不现实的工作条件、较差的工作关系、缺乏对职员的长远期望、行业发展不规范、企业规模较小
6．技术经验不足、缺乏技术管理准则、技术人员的市场调研或对市场理解有误、研究预算不足、组织实力不够
7．对组织架构缺乏认识、缺乏中长期的人カ资源计划、组织不重视技术人オ的技术工作、行业 人才紧缺
8．缺乏远见、没有市场和技术研究、团队庞大陈旧难以转型、缺乏预算
9．缺乏技末前瞻人オ、轻视技术、缺乏预算
措施
1.用户培训、系统所有者和用户的承诺与参与、使用高水平的系统分析师
2.用户的定期参与、项目的阶段交付、加强用户培训、完善信息系统文档
3.变更管理、应急措施
4.采用标准技术、使用具有丰富经验的项目管理师
5.保持好的职员条件、确保人与工作匹配、保持候补、外聘、行业规范
6.预先测试、教育培训、选择替代工具、増强组织实力
7.外聘、招募、培训
8.全面评估、推迟决策
9.延迟项目、标准检测、前期研究、培训
14.14. 管配置管理问题
问题
1．没有项目管理经验,不适合项目经理的职位。
2．项目经理兼任配置管理员，精力不够，无法完成配置管理工作
3．范围管理有问题
4．版本管理没有做好，没有统一的版本管理机制，各版本不可追溯，导致重要版本丢失
5．项目中没有建立基线，导致需求、设计、编码无法对应:
6．没有做好变更管理，项目中的变更不可控
7．配置管理计划不应由CCB制定
8．基线变更流程缺少变更验证环节
9．CCB成员的要求不应以人数作为规定，而是以能否代表项目干系人利益为原则
10．该公司可能没有版本管理規定或甲乙没有统一执行版本規定
11．变更审查应该提交CCB軍核
12．变更发布应交由CMO完成
13．甲乙两人不能同时修改错误
14．没有做配置管理规划，缺少完整的配置管理方案
15．缺少配置管理及变更管理流程，没有配置管理委员会
16．试运行的系统版本没有及时建立基线并让各业务部门正式确认:
17．配置权限管理存在问题:
18．人员职责不清晰，没有CMO的参与并控制配置权限
19．开发人员没有按照变更流程的要求修改系统及代码
20．开发人员修改代码后没有及时修改文档，导致两者不一致
21．代码被修改后没有及时进行回归测试并请干系人确认
22．文档管理存在问题，没有做好文档的交接、更新、变更管理工作
23．配置管理过程中没有做好相应的记录;
24.新人的培训工作没有跟进到位。
措施
1.从项目整体出发,做好配置管理规划
2.定义合理的配置管理流程,规定项目中出现变更的处理办法
3.与各方干系人达成共识，组建配置管理委员会
4.识别配置项，并为配置项建立惟一标识，保证其可追溯
5.建立配置基线,使重要配置项处于受控状态
6.定期提效配置状态报告,改进配置管理方法
7.组建配置管理方案设计小组
8.仔细了解单位的情况、历史、人员、组织形式等
9.对配置管理工具进行有效评估
10.制定全面有效的配置管理计划，包括建立配置管理环境、组织机构、成本、进度等，在配置管理计划中详描述，建立示例配置库、配置标识管理、配置库控制、配置的检查和评审、配置库的备份、配置管理计划附属文档
11.梳理变更脉络，确定统一的最终需求和设计:
12.梳理配置项及其历史版本
13.对照最终需求和设计逐项分析现有配置项及历史版本的符合情况
14.根据分析结果由干系人确定整体变更计划并实施
15.加强整体版本管理。
14.15. 变更中常见的问题
1．没有遵循变更控制流程
2．没有书面的记录
3．应该有CCB进行审批
4．没有及时更新项目管计划。
14.16. 合同管理里可能会出现的问题
1.合同没定好，没有就具体完成的工作形成明确清晰的条款
2.甲方没有对需求及其变更进行统一的组织和管理
3.缺乏变更的接收/拒绝准则
4.项目干系人及其关界分析不到位，范围定义不全面、不准确
5.甲乙双方对项目范围没有达成一致认可或承诺
6.缺乏项目全生命周期的范围控制
7.缺乏客户/用户参与
8.甲方无法进行跨部门协调
9.实施范围不清楚、验收标准不清楚
10.项目沟通有问题
11.客户不验收或拖延验收、签字、容户有情绪、不付款
12.客户对项目质量信心不足、售后没有承诺等
13.缺少违约责任相关条款
14.缺少变更处理及索赔相关条款
14.17. 可能的收尾的问题
1．没有充分做好验收前的准备，或软件系统没有达到验收前的标准，或软件还存在计划修复的缺陷，这些缺陷未经修复和确认便进入正式验妆环节。
2．在验收过程中末根据变更控制流程对软件进行修改，导致文档与软件不一致
3．软件更新后没有对文档进行变更便交付给客户
4．项目验收未正式完成，未签署验收报告变更进行了项目总结
5．项目收尾过程不完整，缺少正式的项目总结环节，不能只编写总结报告
6．项目总结报告末能反映项目的实际情况
7．缺少项目评估或审计环节验收中存在的主要问题
8．没有进行有效的系统测试
9．没有准备好相应的文档
10．没有按照规范的流程进行验收
11．与客户的沟通不良
14.18. 外包的害处
1.无法达到预期的成本降低目标
2.以前内部自行管理领域的整体品质降低
3.未和服务供应商达成真正的合作关系
4.企业雇主和服务提供商在服务品质和酬劳议题上有争议
5.无法借机开拓出满足客户新层次需求和符合弹性运作需求的机会。
14.19. 如何做好外包
1．慎重的选择合格的外包商
2．互相同意对方的承诺
3．需要经常保持交流
4．根据合同的承诺跟踪承包商实际完成的情况和成果，也就是说要多沟通，多监控。
