信息系统项目管理师 - 案例分析题

信息系统项目管理师 - 案例分析题

一、可行性研究分析（立项管理）

1、项目的必要性分析：

①原有系统开发不规范，缺少必要的技术文档，原开发人员跳槽，新接手的开发人员很难维护原有系统，维 护成本可能会接近或超过新开发的成本。 ②原系统采用落后的设计或因设计人员的水平有限，系统架构设计不合理，难以扩充和修改。 ③原系统设计虽然合理，也考虑到了日后的扩充，但因业务发展太快，远远超过原来的设想，量变引起质变 ④原系统开发工具已过时，用落后的开发工具继续维护还不如用新的开发工具重新开发。 ⑤原系统所基于的硬件或软件平台已过时，在原有平台继续维护已无必要，需要开发基于当前流行平台的新 系统项目的可能性。

2、可行性研究的内容：

①技术可行性分析； ②经济可行性分析； ③运行环境可行性分析； ④法律可行性、社会可行性

3、可研过程中可能出现的问题？

（1）项目经理的技术经验不足 （2）没有正式、书面的新产品研发项目建议书就开展可行性研究工作 （3）新产品研发的可行性研究工作不充分，尤其缺少技术可行性分析和论证 （4）研发过程中对人才缺乏、竞争对手等带来的风险缺乏充分的分析，没有合理有效的应对方案 （5）没有新产品的初步设计方案就开始研发工作 （6）新产品的需求和技术指标不应由领导把关，应进行外部评审 （7）在项目启动前缺少对项目成本的估算或成本估算工作未到位 （8）可行性研究报告缺少必要的内部论证或外部评估环节 （9）没有制订综合、全面的项目管理计划，进度计划不能代替项目管理计划，领导的指示不能代替项目管理计划 （10）项目发生进度延误的可能性时未及时调整或更新进度计划并与领导及相关各方沟通 （11）前期立项工作中人员参与不充分，缺少关键技术人员和财务人员

4、可行性研究的步骤：

①明确项目规模和目标； ②研究正在运行的系统； ③建立新系统的逻辑模型； ④导出和评价各种方案； ⑤推荐可行性方案； ⑥编写可行性研究报告； ⑦递交可行性研究报告

5、项目建议书批准后的主要工作一般为：

（1）确定项目建设的机构、人员。 （2）选定建设地址，申请规划设计条件，做规划设计方案。 （3）落实筹措资金方案。 （4）落实原料的供应、配套方案、安全消防措施等。 （5）外商投资企业申请企业名称预登记。 （6）进行详细的市场调查分析。 （7）编制可行性研究报告。

6、项目评估的程序：

1)成立评估小组，进行分工，制定评估工作计划； 2)开展调查研究，收集数据资料，并对可行性研究报告和相关资料进行审查和分析； 3)分析与评估； 4)编写评估报告； 5)讨论、修改报告； 6)专家论证会； 7)评估报告定稿。（项目评估的最终成果是项目评估报告）

二、整体管理

1、可能的问题？

（1）项目管理计划不应由一人制定，应有项目组参与。 （2）项目计划缺少相关分计划，如质量计划、沟通计划等。 （3）制定进度计划的方法不合理，没有预留一定的缓冲时间。 （4）项目计划缺少评审和审批环节。 （5）没有处理好外部因素（天气）和内部因素（团队）带来的风险，缺乏有效的应对措施。 （6）项目发生变更时没有及时更新项目计划。 （7）应识别受设备到场所影响的活动，对于不受影响的活动不应推迟进行。

2、编写计划的过程

（1）明确项目目标和阶段目标 （2）成立初步的项目团队 （3）工作准备与信息收集 （4）依据标准、模版等编写初步的概要的项目计划 （5）编写范围管理、质量管理、进度、预算等分计划 （6）将上述分计划纳入项目计划，然后对项目计划进行综合平衡、优化 （7）项目经理负责组织编写项目计划 （8）评审与批准项目计划 （9）项目获批，形成了项目的基准计划

3、项目章程一般包括以下内容：

项目章程应当包括以下内容（直接列入或援引其他文件)。

（1）项目目的或批准项目的原因。 （2）可测量的项目目标和相关的成功标准。 （3）项目的总体要求。 （4）概括性的项目描述。 （5）项目的主要风险。 （6）总体里程碑进度计划。 （7）总体预算。 （8）项目审批要求（用什么标准评价项目成功，由谁对项目成功下结论，由谁来签署项目结束）。 （8）委派的项目经理及其职责和职权。 （10）发起人或其他批准项目章程的人员的姓名和职权。

4、项目管理计划记述了如下内容：

（1）项目管理团队选择的各个项目管理过程。 （2）每一选定过程的实施水平。 （3）对实施这些过程时使用的工具与技术所做的说明。 （4）在管理具体项目中使用选定过程的方式和方法，包括过程之间的依赖关系和相互作用，以及重要的依据和成果。 （5）为了实现项目目标所执行工作的方式、方法。 （6）监控变更的方式、方法。 （7）实施配置管理的方式、方法。 （8）使用实施效果测量基准并使之保持完整的方式、方法。 （9）项目干系人之间的沟通需要与技术。 （10）选定的项目生命期和多阶段项目的项目阶段。 （11）高层管理人员为了加快解决未解决的问题和处理未做出的决策，对内容、范围和时间安排的关键审查。

三、需求范围管理

1、范围管理可能问题：

（1）没有挖掘到全部隐性需求，缺乏精确的范围定义； （2）没有有效的范围管理，造成二次变更； （3）对范围控制不足； （4）没有和客户进行需求确认 （5）没有制定范围管理计划或项目管理计划 （6）变更结果没有得到客户的确认。 （7）项目范围说明书内容不全面（或者项目范围定义不充分） （8）没有及时评估客户提出的变更要求对项目带来的影响并与客户及时沟通 （9）变更不应由项目经理审批，应有 CCB 审批 （10）项目变更实施前没有及时变更合同 （11）缺少范围确认环节（或项目需求、设计等没有得到用户的正式评审）； （12）范围控制存在问题

2、范围管理应对措施：

（1）项目范围进行清晰定义，并根据定义对工作进行分解，制定 WBS； （2）对项目进行合理估算，对工作量有量化的把握； （3）对项目范围进行有效控制； （4）重新定义项目范围必须得到高层和客户的确认； （5）进行沟通管理，协调多个项目干系人之间的矛盾。

3、项目范围说明书的内容：

（1）产品范围描述 （2）验收标准 （3）可交付成果 （4）项目的除外责任 （5）制约因素 （6）假设条件。

4、需求变更的可能问题：

（1）没有按照严谨的变更控制流程对整个需求变更做完整的记录和跟踪（对于需求变更请求没有记录、没 有对变更进行正式的评审和批准、对于变更的结果没有验证） （2）对需求变更可能造成的影响进行全面的评估和分析（只分析了需求变更对于工期的影响） （3）没有修改项目管理计划并重新评审（项目经理不应口头布置任务，同时里程碑的调整没有通知相应的 管理层） （4）配置管理工作没有做好（没有对需求文件和设计文件进行修改，并升级相应版本，相应的模块编码的 修改也没有进行版本控制） （5）变更结果没有跟客户沟通（需求变更实施完成后，没有让客户对最终结果进行确认）

5、需求变更出现问题的影响：

（1）没有遵循正式的变更控制流程，可能导致需求变更的过程失控和不可追溯。 （2）没有对变更的影响进行完整的分析，可能导致无法全面了解这次变更对项目的进度、范围、成本、质 量等造成多大的影响。 （3）没有修改项目管理计划，可能导致实际工作内容与计划有较大的偏差，使项目管理计划无法指导项目 实施。 （4）没有对相应技术文档进行修改可能导致需求、设计与编码无法对应，不利于后期的测试和以后的维护 工作。版本管理和配置管理没有做好，可能导致在变更失败后无法将项目恢复到变更前的状态。 （5）没有让用户对最终结果进行确认，可能导致双方对变更结果的意见不一致，不利于项目验收和最终交 付。

6、确认范围应该贯穿项目的始终，一般步骤如下

（1）确定需要进行范围确认的时间。 （2）识别范围确认需要哪些投入。 （3）确定范围正式被接受的标准和要素。 （4）确定范围确认会议的组织步骤。 （5）组织范围确认会议。

7、需求管理计划描述在整个项目生命周期内如何分析、记录和管理需求。主要包括以下内容。

（1）如何规划、跟踪和汇报各种需求活动。 （2）需求管理需要使用的资源。 （3）培训计划 （4）项目干系人参与需求管理的策略 （5）判断项目范围与需求不一致的准则和纠正规程 （6）需求跟踪结构，即哪些需求属性将列入跟踪矩阵，并可在其他哪些项目文件中追踪到这些需求 （7）配置管理活动

四、进度管理

1、进度管理可能出现的问题以及可以采用的办法，其中还要注意可能会和成本一起考！

（1）团队成员没有及早参与，需求分析耗时长，要早期参与进项目 （2）经验不足，进度计划制定不准，采取有效的历时估算方法和网络计划技术，制定进度计划 （3）考虑项目期间特定时期会对进度产生影响 （4）增加人手，聘请更有经验的人员，或找兼职人员 （5）加班 （6）并行 （7）重新估算后面的工期 （8）加强沟通，减少变更 （9）加强控制，避免返工 （10）外包 （11）加强沟通，先完成关键需求 （12）增加资源有时可能压缩工期有限 （13）关注关键路径，在关键路径上加资源，有效果 （14）关注里程碑 （15）加强进度与成本、风险、质量等知识点的协调

解决方案: （1）向公司申请增加资源，或使用经验丰富的员工 （2）优化网络图，重排活动之间的顺序，压缩关键路径 （3）临时加班（赶工），尽可能补救耽误的时间或提高资源利用率 （4）将部分阶段的工作改为并行，并进行内部流程的优化 （5）变更原来的进度计划。根据上一阶段的绩效，对后续工作重新评估，修订计划，并征得项目干系人的同意 （6) 加强同项目干系人的沟通 （7) 加强对交付物、项目阶段工作的及时检查和控制，避免后期出现返工 （8）尽可能调配非关键路径上的资源用于关键路径上的任务 （9）优化外包，采购等环节，并全程监控。

2、进度压缩的方法：

（1）赶进度 （2）快速跟进。

3、缩短工期的方法：

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

4、进度提前的变更方法

（1）分析进度，找出哪些地方需要采取纠正措施； （2）确定应采取哪种具体纠正措施； （3）修改进度计划，并将纠正措施列入计划； （4）重新计算进度，估计计划采取的纠正措施。

5、如何保证满足项目的进度要求：

（1）进行计划的贯彻 （2）调整工作 （3）抓住关键路径 （4）提高资源利用率 （5）加强组织管理工作 （6）加强进度控制。

6、监督和跟踪项目进度的步骤：

（1）细化 WBS，基于 WBS 和工时估算制定活动网络图，制定项目工作计划； （2）建立对项目工作的监督和测量机制； （3）确定项目里程碑，并建立有效的评审机制； （4）对项目中发现的问题、及时采取纠正和预防措施，并进行有效的变更管理。 （5）使用有效的项目管理工具，提升项目管理的工作效率。

其实进度管理主要是计算题，要会找关键路径、会求 6 标时、自由时差，要会调整工期，还需要会结合 挣值进行分析。

提示：在压缩了一个活动之后，要分析关键路径是否有变化，不管有没变化，都需要在答题纸上说明。

五、成本管理

成本估算和预算的联系：都运用类比估算、参数模型、自下而上等工具和技术；都是以 WBS 为基础的。

成本估算和预算的区别： 估算成本是对完成项目活动所需资金进行近似估算的过程；估算成本其输出是成本估算，这种估算并未得到 管理层的批准；成本估算的精确程序以工作包为基础；制定预算是汇总所有单个活动或工作包的估算成本， 建立一个经批准的成本基准的过程；成本预算将基于工作包的成本估算分配到每项活动及相应时间段；成本 预算输出的是成本基准计划即经过批准的成本预算。

其实成本管理主要是计算题，注意和进度的结合。 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 当前偏差被看做是代表未来的典型偏差
• VAC=BAC-EAC

提示：一定要按过程写，就算是不会，也一定要多写，写公式，能写几步是几步。另外呢？如果是和进度结合的题目，如果题目里没特殊说明，求 PV 的时候要按照网络图来，就是按最早开始算，当然，如果题目里有限制条件，则按照限制条件来。

成本估算的步骤 （1）识别并分析成本的构成科目 （2）根据已识别的项目成本构成科目，估算每一科目的成本大小 （3）分析成本估算结果，找出各种可以相互替代的成本，协调各种成本之间的比例关系。

成本预算的步骤 （1）将项目总成本分摊到项目工作分解结构的各个工作包。分解按照自顶向下，根据占用资源数量多少而 设置不同的分解权重。 （2）将各个工作包成本再分配到该工作包所包含的各项活动上。 （3）确定各项成本预算支出的时间计划及项目成本预算计划。

项目成本控制的定义，包括如下内容： ①对造成成本基准变更的因素施加影响； ②确保变更请求获得同意； ③当变更发生时，管理这些实际的变更； ④保证潜在的成本超支不超过授权的项目阶段资金和总体资金； ⑤监督成本执行（绩效），找出与成本基准的偏差； ⑥准确记录所有的与成本基准的偏差； ⑦防止错误的、不恰当的或未批准的变更被纳入成本或资源使用报告中 ⑧就审定的变更，通知项目干系人； ⑨采取措施，将预期的成本超支控制在可接受的范围内。

成本超支进度落后措施：用高效人员、在预防风险的情况下并行施工等、提高工作效率

成本超支进度超前措施：抽调人员、放慢进度，采取措施控制成本，必要时调整基线。

六、质量管理

项目质量管理可能问题： （1）有制定可行的质量管理计划并积极实施； （2）没有全面的质量管理进展情况报告； （3）沟通方式单一或不全面，容易误导用户，致用户不必要的担心 （4）质量保证过程中缺乏 QA 的参与 （5）质量控制环节缺失，例如评审和测试 （6）测试方法不当或不充分 （7）测试控制的流程不对，或测试安排的紧张，或未进行质量控制就进行了范围确认。 （8）没有质量保证经验。 （9）检查频率的设定有问题。 （10）应加强项目过程中的质量控制或检查，不能等到工作产品完成后才检查。 （11）QA 发现问题应与当事人协商，如果无法达成一致要向项目经理或更高级别的领导汇报，而不能自作主张。 （12）在质量管理中，没有与合适的技术手段相结合。 （13）对程序员在质量意识和质量管理的培训不足 （14）职责分配不清楚 （15）项目经理在项目质量管理方面的经验欠缺 （16）进度计划制定的不合理（或进度计划安排过于紧张） （17）需求分析、系统设计阶段的质量控制可能不到位、缺少评审环节 （18）测试过程中配置管理工作未到位 （19）项目缺乏质量标准和质量规范 （20）没有建立项目的质量保证体系 （21）在质量管理中，没有采用合适的工具、技术和方法

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

质量保证体系包含？ 1、是否制定明确的质量计划 2、是否建立健全专职的质量管理机构 3、是否实现管理业务标准化，管理流程程序化 4、是否配备必要的资源条件 5、是否建立了一套灵敏的质量信息反馈系统。

质量保证人员，在整个项目中应该完成哪些工作? （1）计划阶段制定质量管理计划和相应的质量标准 （2）按计划实施质量检查，是否按标准过程实施项目工作。注意项目过程中的质量检查，每次进行检查之 前准备检查清单（checklist），并将质量管理相关情况予以记录 （3）依据检查的情况和记录，分析问题，发现问题，与当事人协商进行解决。问题解决后要进行验证；如 果无法与当事人达成一致，应报告项目经理或更高层领导，直至问题解决 （4）定期给项目干系人发质量报告 （5）为项目组成员提供质量管理要求方面的培训或指导

质量控制的工作应做好以下几方面内容： 1、维护工作进行质量控制，做好相关文档工作； 2、在有条件情况下，开始对已交付系统进行文档建设，尤其是用户手册的建设工作； 3、建立组织级的质量管理体系和相关的标准及规范，取得高层领导的支持和信任，开展整体质量控制观念的培养，在以后工作中实施严格的质量控制工作。

质量管理体系的改进步骤： （1）找出目前质量体系不合适项目实际情况的问题 （2）制定改进计划，对项目实施流程进行改进 （3）将改进工作分配给各部门 （4）修改体系文件并会同各部门进行评审 （5）在部分项目中试运行改进后的体系，找出问题，改进 （6）正式发布改进后的体系并持续改进

企业的质量管理体系主要存在以下问题： （1）目标工作与实际工作和原有管理割裂开来，认为目标归目标，实际工作中没沿用原来的管理模式； （2）未能结合企业的实际情况，照搬照抄，其后果导致旧的方法弃之不用，新的方法不知如何使用； （3）实际运行中缺乏指导性、操作性。 （4）在体系建立和实施过程，个别领导和富有管理职能的人员，对体系理解不透、不准确，而其又要具体指导目标工作，以致于体系无法在本单位得到有效的贯彻； （5）把目标工作看成是额外安排的一件事，被动应付，不推不动，实施不用心，满足于上级下达的目标任务； （6）个别单位对体系的宣传力度不够，使一些部门领导和员工对体系的认识存在偏差； （7）在体系的建立和实施过程中的各种工作较为肤浅，缺乏深入的研究及遇到问题主动的解决。

改进之策： （1）加强领导的组织和协调作用； （2）统一认识，牢固树立目标的长久思想； （3）加强培训和教育； （4）以质量管理体系为中心，整合各种管理制度间的关系； （5）强化内审和管理评审工作； （6）重视持续改进； （7）重视质量管理制度化建设，加强考核，强化监督保障机制的作用。

质量控制的方法：

• 4 个：统计抽样、检查、测试、6 西格玛
• 老七种工具：因果图、流程图、直方图、检查单、散点图、排列图（帕累托图）、控制图（管理图、趋势 图）
• 新七种工具：相互关系图、亲和图、树状图、矩阵图、优先矩阵图、过程决策程序图、活动网络图

质量管理过程可以分解为 4 个环节： （1）确立质量标准体系。 （2）对项目实施进行质量监控。 （3）将实际与标准对照。 （4）纠偏纠错。

项目管理过程的质量保证活动的基本内容如下： （1）制定质量标准。 （2）制定质量控制流程。 （3）提出质量保证所采用方法和技术。 （4）建立质量保证体系。

项目质量控制过程一般要经历以下基本步骤： （1）选择控制对象。 （2）为控制对象确定标准或目标。 （3）制定实施计划，确定保证措施。 （4）按计划执行。 （5）对项目实施情况进行跟踪监测、检查，并将监测的结果与计划或标准比较。 （6）发现并分析偏差。 （7）根据偏差采取相应对策.

7、质量控制跟质量保证的区别：

• 质量保证主要是按照既定的质量计划来对过程进行追踪，并且还包含质量改进；而质量控制则监控项目的具体结果，确定其是否符合项目的质量标准，并进行不合格情况的追踪。

• 简单记忆：质量保证看得是整个项目，控制是关注各阶段具体可交付成果，另外质量保证工具有质量审计跟过程分析，从这两点上区分控制跟保证。此题也可以结合输入工具输出来作答

七、人力资源管理

人力资源可能问题： ①缺乏足够的项目管理能力和经验； ②兼职过多，精力和时间不够用，顾此失彼； ③没有进入管理角色，定位错误，疏于对项目的管理； ④新人缺乏培训和全程的跟踪和监控； ⑤没有进行良好的冲突管理。

应对措施： （1）事先制定岗位的要求、职责和选人的标准，并选择合适的人选； （2）对工作进行全面估算，如果有人负荷过重，需要找人代替，解决负载平衡问题； （3）事前沟通并对相应人员明确要求，明确角色的轻重缓急，促使尽快转换角色； （4）上级应该注意平时对人员的培养和监控； （5）对项目团队进行有效的冲突管理。 （6）采用合适的团队建设手段，消除团队成员间的隔阂。 （7）明确项目团队的目标及项目组各成员的分工。 （8）建立清晰的工作流程和沟通机制。 （9）建立明确的考核评价标准。 （10）鼓励团队成员之间建立参与和分享的氛围。 （11）制定有效的激励措施。

团队组建常见问题： ①招募不到合适的项目成员； ②团队的组成人员尽管富有才干，但却很难合作； ③团队气氛不积极，造成项目团队成员的士气低落； ④项目团队的任务和职责分配不清楚； ⑤人员流动过于频繁。

产生原因： ①没有能够建立人力资源获取和培养的稳定机制； ②没有完整识别项目所需的人力资源种类、数量和相关任职条件； ③没有建立一个能充分、有效发挥能力的团队； ④没有清楚地分配工作职责到个人或人力单元。

应对措施： ①建立稳定的人力资源获取和培养机制； ②在项目早期，进行项目的整体人力资源规划，明确岗位设置、工作职责和协作关系； ③进行项目团队建设，加强团队沟通，建立合作氛围； ④根据项目团队成员的工作职责和目标，跟踪工作绩效，及时予以调整和改进，提升项目整体绩效。

八、沟通管理

项目干系人包括：

• ①项目经理
• ②顾客/客户
• ③执行组织
• ④项目团队成员
• ⑤项目管理团队
• ⑥出资人
• ⑦有影响的人
• ⑧项目管理办公室。

如何进行项目干系人分析： ①进行项目干系人识别； ②分析项目干系人的重要程度； ③进行项目干系人的支持度分析； ④针对不同项目干系人，特别是重要的项目干系人，给出管理项目干系人的建议，并予以实施。

如何改进项目沟通： ①使用项目管理信息系统； ②建立沟通基础设施； ③使用项目沟通模版； ④把握项目沟通基本原则； ⑤发展更好的沟通技能； ⑥把握人际沟通风格； ⑦进行良好的冲突管理。

保证团队沟通顺畅的六点措施： ①有效的沟通者； ②发布者； ③避免沟通阻断器； ④紧密矩阵式结构； ⑤指挥室； ⑥有效的会议。

沟通基本原则： ①沟通内外有别； ②非正式的沟通有助于关系的融洽； ③采用对方能接受的沟通风格； ④沟通的升级原则； ⑤扫除沟通的障碍。

可能问题和应对措施的补充 （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）发挥总包的牵头和监理的协调作用 （28）对共用资源可用性进行分析，引入资源日历 （29）建立健全项目管理制度并监管其执行 （30）采用项目管理信息系统

沟通管理计划应该包括以下内容： （1）通用术语表 （2）干系人的沟通需求 （3）需要沟通的信息，包括语言、格式、内容、详细程度 （4）发布信息的原因 （5）发布信息及告知收悉或做出回应（如适用）的时限和频率 （6）负责沟通相关信息的人员 （7）负责授权保密信息发布的人员 （8）将要接收信息的个人或小组。 （9）传递信息的技术或方法。 （10）为沟通活动分配的资源，包括时间和预算。 （11）问题升级程序，用于规定下层员工无法解决问题时的上报时限和上报路径。 （12）随项目进展，对沟通管理计划进行更新与优化的方法 （13）项目信息流向图、工作流程（兼有授权顺序)、报告清单、会议计划等 （14）沟通制约因素，通常来自特定的法律法规、技术要求和组织政策等。

沟通管理计划中还可包括关于项目状态会议、项目团队会议、网络会议和电子邮件信息等的指南和模板。

沟通管理计划中也应包含对项目所用网站和项目管理软件的使用说明。

较为详尽的绩效报告可能包括： （1）对过去绩效的分析。 （2）项目预测分析，包括时间与成本。 （3）风险和问题的当前状态。 （4）本报告期完成的工作。 （5）下个报告期需要完成的工作。 （6）本报告期被批准的变更的汇总。 （7）需要审查和讨论的其他相关信息。

九、干系人管理

干系人管理计划，为有效调动干系人参与而制定的管理策略。通常包括： （1）关键干系人的所需参与程度和当前参与程度。 （2）干系人变更的范围和影响。 （3）干系人之间相互关系和潜在关系。 （4）项目现阶段的干系人沟通需求。 （5）需要分发给干系人的信息。 （6）分发相关信息的理由，以及可能产生的影响。 （7）向干系人发送信息的频率和时限。 （8）随着项目的进展，更新和优化干系人管理计划的方法。

管理干系人参与包括以下活动： （1）调动干系人适时参与项目，以获得或确认他们对项目成功的持续承诺。 （2）通过协商和沟通管理干系人的期望，确保项目目标实现。 （3）处理尚未成为问题的干系人关注点，预测干系人未来可能提出的问题。需要尽早 （4）识别和讨论这些关注点，以便评估相关的项目风险。 （5）澄清和解决巳经识别出的问题

十、配置管理、变更管理

配置管理包括 6 个主要活动：

• 制订配置管理计划
• 配置标识
• 配置控制
• 配置状态报告
• 配置审计
• 发布管理和交付

配置管理问题 （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）根据分析结果由干系人确定整体变更计划并实施； （16）加强整体版本管理。

配置库的作用 (1)记录与配置相关的信息、 (2)利用库中的信息可评价变更后的后果 (3)从库中可提取各种配置管理过程的管理信息，可利用库中的信息查询回答许多配置

管理问题 配置项：典型配置项包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所 需的各种数据，它们经评审和检查通过后进入软件配置管理。

配置管理中的权限问题： 所有配置项的操作权限应由配置管理员（CMO）严格管理，基本原则是：基线配置 项向软件开发人员开放读取的权限；非基线配置项可以向项目经理（PM）变更管理委员会（CCB）及相关人 员开放；

配置识别的内容如下：（不需要认真背） (1)识别需要受控的软件配置项。 (2)给每个产品和它的组件及相关的文档分配唯一标识。 (3)定义每个配置项的重要特征及识别其所有者。 (4)识别组件、数据及产品获取点和准则。 (5)建立和控制基线。 (6)维护文件盒组件的修订与产品版本之间的关系。

创建基线或发行基线的主要步骤如下（不需要认真背） （1）配置管理员识别配置项； （2）为配置项分配标识； （3）为项目创建配置库，并给每个项目成员分配权限； （4）各项目团队成员根据自己的权限操作配置库； （5）创建基线或发行基线并获得 CCB 的授权。

建立配置管理系统的基本步骤（不需要认真背） 1)组建配置管理方案构造小组。包括：

• 小组负责人
• 技术支持专家
• 配置管理技术专家
• 配置管理系统用户代表。 2)对目标机构进行了解、评估。 3)配置管理工具及其提供商评估。 4)制订实施计划。 5)定义配置管理流程。 6)试验项目的实施。 7)全面实施。

什么时候进行配置审核： (1)产品交付或是产品正式发行前 (2)阶段工作结束以后 (3)在维护工作中，定期的进行

参与配置审核的人员可以是项目租人员或非项目组人员，例如其他项目的配置管理人员、项目组织内部的审核人员以及组织的配置管理人员。

配置审计的实施是为了确保项目配置管理的有效性，体现了配置管理的最根本要求---不允许出现任何混乱现 象,例如： （1）防止向用户提交不适合的产品，如交付了用户手册的不正确版本。 （2）发现不完善的实现^如开发出不符合初始规格说明或未按变更请求实施变更。 （3）找出各配置项间不匹配或不相容的现象。 （4）确认配置项已在所要求的质量控制审核之后纳入基线并入库保存。 （5）确认记录和文档保持着可追溯性。

变更的流程： 1、接受变更申请；2、对变更的初审；3、变更方案论证；4、批准或拒绝； 5、实施；6、监控 7、效果评估；8、验证变更。

变更的原因： 1、计划、定义有误；2、项目执行有偏差；3、外部环境的改变；4、客户新的需要；5、为了应对紧急事件。

变更中常见的问题： 1、没有遵循变更控制流程；2、没有书面的记； 3、应该有 CCB 进行审批 4、没有及时更新项目管理计划。

十一、合同管理

项目合同签订的注意事项（不需要认真背）

（1）当事人的法律资格 当事人订立合同，应当具有相应的民事权利能力和民事行为能力。 （2）质量验收标准 质量验收标准是一个关键指标。如果双方的验收标准不一致，就会在系统验收时产生纠纷。 （3）验收时间 当事人没有约定设备的交付时间或者约定不明确的，可以协议补充，不能达成协议的，依照合同有关条款或交易习惯确定。若仍不能确定，则供货方可以随时履行，采购方也可以随时要求履行，但应当给予对方必要的准备时间。 （4）技术支持服务 （5）损害赔偿 原则上，委托方与被委托方都具有损害赔偿这项权利，但比较多的情况是因为承建方对于企业实施信息系统的困难估计不足，结果陷入到期后难以完成项目的尴尬局面。 （6）保密约定 当事人在订立合同过程中知悉的商业秘密，无论合同是否成立，不得泄露或者不正当地使用。泄露或者不正当地使用该商业秘密给对方造成损失的，应当承担损害赔偿责任。 （7）合同附件 合同生效后，当事人就质量、价款或者报酬、履行地点等内容没有约定或者约定不明确的，可以协议补充：不能达成补充协议的，按照合同有关条款或者交易习惯确定。 （8）法律公证 为避免合同纠纷，保证合同订立的合法性，当事人可以将签订的合同拿到公证机关进行公证。经过公证的合同，具有法律强制执行效力。

合同管理里可能会出现的问题： （1）合同没订好，没有就具体完成的工作形成明确清晰的条款 （2）甲方没有对需求及其变更进行统一的组织和管理 （3）缺乏变更的接收/拒绝准则 （4）项目干系人及其关系分析不到位，范围定义不全面、不准确 （5）甲乙双方对项目范围没有达成一致认可或承诺 （6）缺乏项目全生命周期的范围控制 （7）缺乏客户/用户参与 （8）甲方无法进行跨部门协调 （9）实施范围不清楚、验收标准不清楚 （10）项目沟通有问题 （11）客户不验收或拖延验收、签字、客户有情绪、不付款 （12）客户对项目质量信心不足、售后没有承诺等。 （13）缺少违约责任相关条款； （14）缺少变更处理及索赔相关条款

索赔流程： 1、提出索赔要求；2、报送索赔资料、3、监理工程师答复 4、监理工程师逾期答复后果 5、持续索赔 6、仲裁与诉讼

如果甲方向乙方公司提出索赔要求，乙方应该如何处理？

1. 公司在接到甲方的索赔要求及索赔材料后，应根据公司与甲方签订的合同，进行认真分析和评估，给出索赔答复；
2. 在双方对索赔认可达成一致的基础上，向甲方进行赔付；如双方不能协商一致，按照合同约定进行仲裁或诉讼；
3. 同时公司依据与其他相关公司（下游供应商或分包商）签订的合同，向其他公司提出索赔要求，按索赔流程处理。

后续可以怎么做？ (1)对双方的需求（项目范围）做一次全面的沟通和说明，达成一致，并记录下来，请建设方签字确认。 (2)就完成的工作与建设方沟通确认，并请建设方签字。 (3)就待完成的工作列出清单，以便完成时请建设方确认。 (4)就合同中的验收标准、步骤和方法与建设方协商一致。 (5)必要时可签署一份售后服务承诺书，将此项目周期内无法完成的任务做一个备忘，承诺在后续的服务期内完成，先保证项目能按时验收。 (6)对于建设方提出的新需求，可与建设方协商进行合同变更，或签订补充合同

十二、收尾管理

项目收尾的具体内容主要是项目验收、项目总结和项目评估审计。

项目总结会的内容 总结的内容应包括：项目绩效、技术绩效、成本绩效、进度计划、绩效识别问题和解决问题意见和建议。

项目总结内容和意义 （1）了解项目全过程的工作情况及相关的团队或成员的绩效状况。 （2）了解出现的问题并进行改进措施总结。 （3）了解项目全过程中出现的值得吸取的经验并进行总结。 （4）对总结后的文档进行讨论，通过后即存入公司的知识库，从而纳入企业的过程资产。

对于系统集成项目，所涉及的文档应该包含如下部分： （1）系统集成项目介绍（2）系统集成项目最终报告（3）信息系统说明手册 （4）信息系统维护手册（5）软硬件产品说明书、质量保证书等 项目团队的转移。转移的时候需要考核绩效、评估团队成员，并进行奖励。

团队成员转移的流程：（不需要认真背） （1）项目团队成员的管理计划，也就是项目人力资源管理计划中描述所说的人员转 移条件已经触发 （2）项目团队成员所承担的任务已经完成，提交了经过确认的可交付物并已完成工作交接 （3）项目经理与项目团队成员确认该成员的工作衔接已告一段落或已经完成。 （4）项目经理签发项目团队成员转移确认文件 （5）项目经理签发项目团队成员的绩效考核文件 （6）项目经理通知所有相关的干系人 （7）若是项目收尾全体项目成员结束工作，应召开项目总结表彰大会，肯定项目的成绩、团队人员的业绩， 同时总结项目的经验教训。

怎么才可以促使甲方项目验收？ 1、请求公司的管理层出面去与甲方协调 2、重新确认需求并获得各方认可 3、和甲方明确合同、以及双方确认的补充协议等，包括修改后的范围、进度和质量方面的文件等，作为验 收标准 4、准备好相应的项目结项文档，向甲方提交

可能的收尾的问题？ （1）没有充分做好验收前的准备，或软件系统没有达到验收前的标准，或软件还存在计划修复的缺陷，这 些缺陷未经修复和确认便进入正式验收环节。 （2）在验收过程中未根据变更控制流程对软件进行修改，导致文档与软件不一致 （3）软件更新后没有对文档进行变更便交付给客户。 （4）项目验收未正式完成，未签署验收报告变更进行了项目总结 （5）项目收尾过程不完整，缺少正式的项目总结环节，不能只编写总结报告 （6）项目总结报告未能反映项目的实际情况 （7）缺少项目评估或审计环节。

项目收尾的具体内容？

• 项目收尾的具体内容主要是项目验收、项目总结和项目评估审计。
• 项目的正式验收包括验收项目产品、文档及已经完成的交付成果。
• 项目总结属于项目收尾的管理收尾，而管理收尾有时候又被称为行政收尾，就是检查项目团队成员及相 关干系人是否按规定履行了所有责任。实施行政收尾过程还包括收集项目记录、分析项目成败、收集应 吸取的教训，以及将项目信息存档供本组织将来使用等活动统一为一个整体。
• 项目评估的意义是将项目的所有工作加以客观的评价，从而对项目全体成员的成果形成绩效结论。好的 项目评估会引导后续项目的开展，并对项目过程的改进起到很重要的作用。
• 项目审计应由项目管理部门与财务部门共同进行，相关的审计项目应在项目成本管理中列出，在项目收 尾的时候，对已经列出的支出和收入进行财务审计，对不合理的支出和收入加以分析，为改进项目的管 理服务。

验收中存在的主要问题： （1）没有进行有效的系统测试； （2）没有准备好相应的文档； （3）没有按照规范的流程进行验收； （4）与客户的沟通不良。

验收工作的步骤： 1、系统测试 2、系统试运行 3、文档验收 4、最终的验收报告。

**验收需要正式的验收报告：**对于系统集成项目，一般来说，需要证书的验收测试工作，验收测试工作 可以由业主和承建单位共同进行，也可以由第三方公司进行，但无论哪种方式都需要双方认可的正式 文档为依据进行验收测试。

十三、风险管理

主要风险来源： ①需求风险； ②技术风险； ③团队风险； ④关键人员风险； ⑤预算风险； ⑥范围风险。

风险管理计划包括以下内容。 （1）方法论。确定实施项目风险管理可使用的方法、工具及数据来源。 （2）角色与职责。确定风险管理计划中每项活动的领导、支援与风险管理团队的成员组成。为这些角色分配人员并澄清其职责。 （3）预算 （4）时间安排 （5）风险类别 （6）风险概率和影响的定义 （7）概率和影响矩阵。根据风险可能对实现项目目标产生的潜在影响，对风险进行优先排序。 （8）修改的项目干系人承受度 （9）报告格式 （10）跟踪

风险应对计划的主要内容： （1）需要应对的风险清单。 （2）形成一致意见的应对措施。 （3）实施所选应对策略采取的具体行动。 （4）明确风险管理人和分配给他们的责任。 （5）风险发生的征兆和预警信号。 （6）实施所选应对策略需要的预算和进度计划活动。 （7）设计好要准备的符合有关当事人风险承受度的用在不可预见事件上的预留时间和费用。 （8）应急方案和要求实施方案的引发因素。 （9）要使用的退出计划，它作为对某个已经发生，并且原来的应对策略已被证明不当的风险的一种反应。 （10）对于特定的风险，如果它们可能发生，为了规定各方的责任，可以准备用于保险、服务或其他相应事项的合同。

十四、采购管理

采购与外包的作用 采购方要进行 IT 项目的采购或外包，不管是什么原因，将进行项目的采购和外包至少有如 下作用： (1) 有利于专注于核心业务 (2) 得到技能和技术 (3) 提高效益 (4) 规避项目风险 (5) 降低企业长期营运成本

采购的基本原则 (1) 成本效益原则 (2) 质量原则 (3) 进度配合原则 (4) 公平竞争原则

供应商管理 (1) 供应商调查 (2) 供应商选择指标 (3) 供应商评估方法 (4) 采购供方的合格评价 (5) 供应商质量管理

采购说明书中的信息有： (1) 规格说明书； (2) 期望的数量和质量的等级； (3) 性能数据； (4) 履约期限、工作地及其他要求。

常见的采购文件有：

• (1) 方案邀请书（RFP）：用来征求潜在供应商建议的文件。
• (2) 报价邀请书：依据选择供应商时，用于征求潜在供应商报价的文件。多用于简单产品招标中使 用 RFQ，也叫请求报价单
• (3) 询价计划编制过程常用的的其他文件：
  • 1 征求供应商意见书（RFI）：用来征求供应商意见，以使需求明确化。
  • 2 投标邀请书
  • 3 招标通知