题5答案：
⏹EAC是根据项目绩效和定性风险分析确定的最可能的总体估算值，是既定项目工作完成时，计划活动、WBS组件或项目的预期或预见最终总估算。
⏹当前偏差被看成非典型的，以后不会发生类似偏差，公式：
EAC=AC+BAC-ev
⏹当前偏差被看成是可代表未来偏差的典型偏差时，公式：
EAC=累计AC+（（BAC-EV）/累计CPI）
⏹BAC是完成工作所需要的预算=PV
⏹本题适用第一种类型：
EAC=AC+BAC-ev=4110+7440-3820=7730
采取的措施：
⏹在软件开发项目中合理、有效地进行挣值管理
⏹确定剩余工作的规模和工作量
⏹确定剩余工作的需求
⏹严格控制项目的进度和成本
⏹在保证项目质量的前提下，进行的必要的赶工和成本缩减工作
案例四：
需求评审案例
⏹建议一：
分层次评审
我们知道用户的需求是可以分层次的，一般而言可以分成如下的层次：
目标性需求：
定义了整个系统需要达到的目标；
功能性需求：
定义了整个系统必须完成的任务；
操作性需求：
定义了完成每个任务的具体的人机交互；
目标性需求是企业的高层管理人员所关注的，功能性需求是企业的中层管理人员所关注的，操作性需求是企业的具体操作人员所关注的。
对不同层次的需求，其描述形式是有区别的，参与评审的人员也是不同的。
⏹建议二：
正式评审与非正式评审结合
正式评审是指通过开评审会的形式，组织多个专家，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职责，对需求进行正规的会议评审。
而非正式的评审并没有这种严格的组织形式，一般也不需要将人员集合在一起评审，而是通过电子邮件、文件汇签甚至是网络聊天等多种形式对需求进行评审。
两种形式各有利弊，但往往非正式的评审比正式的评审效率更高，更容易发现问题。
因此在评审时，应该更灵活地利用这两种方式。
⏹建议三：
分阶段评审
应该在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审。
分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低了需求返工的风险，提高了评审的质量。
比如可以在形成目标性需求后进行一次评审，在形成系统的初次概要需求后进行一次评审，当对概要需求细分成几个部分，对每个部分进行各个评审，最终再对整体的需求进行评审。
⏹建议四：
精心挑选评审员
需求评审可能涉及的人员包括：
需方的高层管理人员、中层管理人员、具体操作人员、IT主管、采购主管；供方的市场人员、需求分析人员、设计人员、测试人员、质量保证人员、实施人员、项目经理以及第三方的领域专家等等。
在这些人员中由于大家所处的立场不同，对同一个问题的看法是不相同的，有些观点是和系统的目标有关系的，有些是关系不大的，不同的观点可能形成互补的关系。
为了保证评审的质量和效率，需要精心挑选评审员。
首先要保证使不同类型的人员的都要参与进来，否则很可能会漏掉了很重要的需求。
其次在不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，否则很可能使评审的效率降低或者最终不切实际的修改了系统的范围。
⏹建议五：
对评审员进行培训
在很多情况下，评审员是领域专家而不是进行评审活动的专家，他们没有掌握进行评审的方法、技巧、过程等，因此需要对评审员进行培训，同样对于主持评审的管理者也需要进行培训，以便于参与评审的人员能够紧紧围绕评审的目标来进行，能够控制评审活动的节奏，提高评审效率，避免发生案例一和案例二中出现的现象。
对评审员的培训也可以区分为简单培训与详细培训两种。
简单培训可能需要十几分钟或者几十分钟，需要将在评审过程中的需要把握的基本原则，需要注意的常见问题说清楚。
详细培训则可能要需要对评审的方法、技巧、过程进行正式的培训，需要花费较长的时间，是一个独立的活动。
需要注意的是被评审人员也要被培训。
⏹建议六：
充分利用需求评审检查单
需求检查单是很好的评审工具，需求检查单可以分成两类：
需求形式的检查单和需求内容的检查单。
需求形式的检查可以由QA人员负责，主要是针对需求文挡的格式是否符合质量标准来提出的，需求内容的检查是由评审员负责的，主要是检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等等，这是需求评审的重点。
检查单可以帮助评审员系统全面地发现需求中的问题，检查单也是随着工程财富的积累逐渐丰富和优化的。
⏹建议七：
建立标准的评审流程
对正规的需求评审会需要建立正规的需求评审流程，按照流程中定义的活动进行规范的评审过程。
比如在评审流程定义中可能规定评审的进入条件、评审需要提交的资料、每次评审会议的人员职责分配、评审的具体步骤、评审通过的条件等等。
⏹建议八：
做好评审后的跟踪工作
在需求评审后，需要根据评审人员提出的问题进行评价，以确定哪些问题是必须纠正的，哪些可以不纠正，并给出充分的客观的理由与证据。
当确定需要纠正的问题后，要形成书面的需求变更的申请，进入需求变更的管理流程，并确保变更的执行，在变更完成后，要进行复审。
切忌评审完毕后，没有对问题进行跟踪，而无法保证评审结果的落实，使前期的评审努力付之东流。
⏹建议九：
充分准备评审
评审质量的好坏很大程度上取决于在评审会议前的准备活动。
常出现的问题是，需求文档在评审会议前并没有提前下发给参与评审会议的人员，没有留出更多更充分的时间让参与评审的人员阅读需求文档。
更有甚者，没有执行需求评审的进入条件，在评审文档中存在大量的低级的错误或者没有在评审前进行沟通，文档中存在方向性的错误，从而导致评审的效率很低，质量很差。
对评审的准备工作，也应当定义一个检查单，在评审之前对照检查单落实每项准备工作。
案例五：
公司组织结构对项目管理的影响
分析：
1、弱矩阵应用
弱矩阵组织保留了职能型组织的许多特点，项目经理的角色更像协调人员而非一个管理者。
对于技术简单的项目适合采用弱矩阵型组织。
为什么呢？
因为技术简单的项目，各职能部门所承担的工作，其技术界面是明晰的或比较简单，跨部门的协调工作很少或很容易做。
2、平衡型矩阵应用
对于有中等技术复杂程度而且周期较长的项目，适合采用平衡型矩阵组织。
采用平衡型组织结构，需要精心建立管理程序和配备训练有素的协调人员才能取得好的效果。
3、强矩阵应用
在强矩阵组织中，具有项目型组织的许多特点：
拥有专职的、具有较大权限的项目经理以及专职的项目管理人员。
对于技术复杂而且时间相对紧迫的项目，适合采用强矩阵组织。
建议答案：
1、项目章程明确责任
资源的冲突主要是项目基线的建设缺乏规范，组员的工作在开始时不明确，项目经理未能有效管理项目的进度，项目中任何工作上的延误直接影响其他项目的启动和进度。
所以要解决项目经理与部门经理间对资源调配及管理的问题。
项目基线的建设机制包括明确的项目生命周期和合适的开发体系应用，在开发过程中各阶段的工作量及资源需求（技术、工作范围、责任等）必须明确及合理。
要点：
◆在项目章程中为项目经理使用组织资源进行项目活动提供授权。
◆企业必须建立项目基线的建设机制，巩固项目经理本身对项目实施的进度管理方法。
2、项目经理和职能经理的协调
要点：
◆明确部门经理和项目经理职责,其次,部门经理需要下放部分资源分配权,同时施行项目责任制,再者,部门经理的绩效考核主要依据在各项目经理之间的资源协调能力,项目质量监管能力,项目经理的绩效考核主要依据项目完成质量和数量
◆实行多项目管理
项目经理面对的问题应属于多项目管理的问题。
要彻底解决这种局面，还是要从公司着手，在公司内部要实行多项目管理的方法，例如设立项目资源部经理，公司人力资源统一由资源部经理统一分配，项目所需要的人员要从公共资源库中挑选，再分配到项目中来。
由于公司人员短缺的实际情况，短期的解决方法就是把同一个项目经理负责的项目合并为一个大项目，每个项目为大项目中的一个子项目，为每个子项目设立优先级，优先级高的有获得资源的优先权。
◆发现问题，及时沟通
当发现某组员的工作可能受到延误，不能如期在指定时间释放该组员时，应尽快与该组员的部门经理及等待接收该组员的项目经理进行沟通，提出有关风险，让其他项目组能够尽早建立应变措施，调整工作计划，或另找其他资源代替。
尽量降低项目组与部门间，或项目组与项目组间的争议。
综合案例一：
变更控制
升级会员 