信息系统项目管理师--知识梳理

第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小时 项目收尾管理

通用掌握部分

整体管理部分

范围管理部分

时间管理部分

成本管理部分

质量管理部分

人力资源管理部分

沟通管理部分

风险管理部分

采购管理部分

项目管理英语词汇整理

分支主题

关键路线上 上下相等，总时差为0

总时差TF（=LS-ES或者=LF-EF）：不影响总工期，最多玩几天不影响总工期

自由时差FF（紧后工作ES最小值-当前工作EF）：最多玩多久不影响紧后工作（有多个紧后工作，取紧后工作ES的最小值）

时标网络图，箭线长度跟工期有关系，波浪线代表自由时差，没有波浪线的为关键路线

前锋线网络图，在时标网络图基础上增加了检查线

工期大小排序

设计模式可以帮助人们简单方便复用已经成功的设计或体系结构

信息系统包括输入活动、处理活动、输出活动

在信息系统中，信息的删除、修改、统计都属于信息的处理

数字水印必须满足的基本应用需求是安全性、隐蔽性、鲁棒性。

软件开发工具可以分为：计划工具、分析工具、设计工具、集成开发工具。代码生成器属于集成开发工具

数据包过滤是通过度数据包的IP头和TCP头或UDP头的检查来实现，不检查数据包的内容

需求分析阶段作为本阶段工作结果，一般的说软件需求规格说明、数据要求说明、初步用户手册应该编写出来。

UML是一种标准的建模方法，更适用于迭代式开发过程

ER图（实体-关系图），属于设计阶段的工具

软件工程管理包括 定计时，平关度

软件设计包括

对象多态：两个或多个属于不同类的对象，对于同一个消息做出不同的响应方式

网页防篡改技术包括 属于web威胁防护技术

web内容安全防护技术 电网反

耦合性是软件系统结构中各个模块之间相互联系紧密程度的一种度量

内聚性是一个模块内部各个元素之间彼此结合进度程度的度量

当对系统的静态设计视图建模时，通常3种方式使用类图

面向对象分析--描述软件要做什么，不需要考虑技术和实现层面的细节

若一个存储单元被访问，这个存储单元可能很快被访问，该特性称为时间局限性

进行面向对象分析的第一步是确定问题域

项目启动会在项目启动阶段-发布章程，做不做这个项目，开工会在规划阶段--该项目怎么做。

项目边界与项目范围

定性风险分析与定量风险分析

成本估算与成本预算

四审计

已知风险及未知风险

核实的可交付成果&验收的可交付成果

应急计划&弹回计划&权变计划

分解结构

在距离矢量路由协议中，防止路由循环的技术是利用水平分裂法阻止转发路由信息。

HTTP与HTTPS区别

一般项目计划主要关注项目的活动计划，但是对于大型复杂项目，必须优先考虑制定项目的过程计划

在大型及复杂项目管理中，项目控制过程的3个重要因素是：外部变更请求、变更控制、项目绩效跟踪

大型项目在执行过程中，范围与质量更容易出现失真，而成本与进度已经规定好了，反而不容易失真。

对于隐蔽工程应该实行旁站监理

根据服务对象不同，企业中信息系统可以分为三类

BPR业务流程重组

BPM业务流程管理

J2EE平台架构识别

信息系统审计包括安全审计

商业智能主要应用的3个关键技术是

信息系统设备安全三个方面

数据处理大致可以分成两大类

物联网应用的两项关键技术

商业智能（BI）实现方式包括三个层次

BI系统主要包括

在计算机网络中，按照交换层次不同，网络交换分为

智慧城市建设参考模型包括

信息系统主要性能指标

信息系统安全划分为

R/D矩阵（资源/数据矩阵）适用于归纳数据

过程／组织矩阵（P/O矩阵）：把企业组织结构与企业过程联系起来， 说明每个过程与组织的联系，指出过程决策人

创建/用户（C/U）矩阵可以反映数据类型和企业过程之间的关系。

PING使用的是ICMP协议。

病毒是通过主动程序运行的，蠕虫是利用系统漏洞。

项目目标

对代码的静态测试

功能配置审计用于审计配置项的一致性

项目评估主要特征概括为

项目可行性研究报告只算开发总成本，其一般划分为

系统需求是从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束。

在进行项目详细可行性研究时，将有项目的成本与无项目时的成本进行比较，求的差额，这种分析方法被称为 增量净效益法

大多数情况下，变更的审批都是由CCB来完成，但是某些情况下的变更必须由顾客完成。

依据变更的重要性分类，变更一般分为重大变更、重要变更、一般变更。

价值活动分为两类，

质量保证主要包括以下内容

质量控制内容

按照密码系统对明文的处理方法，密码系统可以分为

域名服务器上存储有internet主机的IP地址与域名

软件需求分析一般分为 提树平

质量控制新七种工具中，包含了活动网络图、如计划评审技术、关键路径法、紧前关系绘图法 系统集成项目管理师教程中。

项目的质量保证包括、产品的质量保证、服务的质量保证、系统的质量保证

项目质量保证采用的方法和技术包括

文档种类分布

文档按重要性和质量要求分为

资本预算项目可以分为三类：设备更新，现有产品扩大规模，新产品开发、新业务及新市场拓展。 贴现现金流方法应用的重要程度依上述顺序递减。

在典型的信息系统项目开发过程中，需求分析阶段拟定了系统的目标，范围和要求； 而系统各模块的算法一般在详细设计阶段确定。

在创建工作分解结构时，描述生产一个产品所需要的实际部件、组件的分解层次表格称为物料清单。

CRM注重提高用户满意度，同时帮助企业获取利润能力，以信息技术为手段

边界值分析是一种黑盒测试方法。

J2EE平台采用了多层分布式应用程序模型，各个部分将在J2ee组件描述： 运行在客户端机器的客户层组件。 运行在J2EE服务器中的Web层组件。 运行在J2EE服务器中的业务层组件。 运行在EIS服务器中的企业信息系统（EIS）层软件。

在软件开发中采用工作流技术可以： 降低开发风险、提高工作效率、提高对流程的控制与管理、提供对客户响应的预见性。

UML2.0图分类

分组交换技术适用于计算机网络、数据传输可靠、线路利用率较高且经济成本较低。

项目组为保证系统的设计满足需求规格说明书要求而实施的过程称为需求验证

战略计划可应对环境的改变，长期计划适用于稳定的环境和可预期的环境。

某个活动的松弛时间计算问题如何理解？ 前置活动短的放前面，后置活动短的放后面

压缩工期过程中，选择压缩对象时应该考虑的因素：

冗余设计的缺点是

对于软件失效后果特别严重的场合，采用容错设计。

项目章程作用

引导技术包括

经济可行性分析中经常会用到敏感性分析。

系统方法论基本原则

项目论证围绕着市场需求、开发技术、财务经济三个方面，市场是前提、技术是手段、财务经济是核心。

中间代码不可以用栈和列队表示

一般而言，大型软件系统中实现数据压缩功能，工作在OSI参考模型的表示层

OSi各个层功能介绍

绩效报告一般包括

统一的项目过程一般包括

一般来说，业务流程包括 曹支管

创建基线或发现机选的主要步骤

网络路由器可以连接不同的子网

RFID通过无线电信号识别特定目标并读写相关数据

综合布线系统中，管理子系统是干线子系统和水平子系统的桥梁，同时又可为同层组网提供条件。

网络安全审计从审计级别上可分为：系统级审计、应用级审计、用户级审计

静态投资回收期没有特别说明，建设期包括在投资回收期内。

因果分析可以作为项目质量控制中问题识别和问题分析的工具。

基线定义的内容有

数据流程图的主要元素

开发人员对源程序的修改在开发库中进行

外包给企业带来的风险主要有：

西方一些国家对新冠病毒所采取的“群体免疫”策略属于风险应对措施中的接受。

项目集指导委员会是项目集的决策机构，负责为项目集的管理方式提供支持。

储备分析作为进度、风险、成本管理的技术和工具。

自制或外购决策活动应在编制采购计划过程中进行。

工作流是一种能够实现过程集成的技术，一般用于用户的业务流程经常发生改变的场合。

使客户能确认是否接受系统的正式测试为验收测试。

信息安全保障系统，一般简称为信息安全系统，三维空间中， Y轴是OSI网络参考模型，X轴是安全机制，Z轴是安全服务

测试过程中可能发生的风险，其中有的风险是难以避免的，如缺陷风险。

测试进度属于评估测试过程的指标。

问题分析图是一种支持结构化程序设计的流程设计工具， 它的执行顺序是从最左主干线的上端节点开始，自上而下依次执行。

强制访问控制方式（MAC）在军事和安全部门中应用最多。

在信息系统安全技术体系中，安全审计属于运行安全。

对于工作模式或产品界定不甚明确的外包项目，承建方 一般愿意采用的合同形式是工时和材料合同。

安全审计目标是防止内部机密或敏感信息非法泄露和资产的流失。

判断题

案例1：A公司属于弱矩阵结构，该公司项目经理小刘接到一个项目，为客户软件进行升级 ，项目组由5个人组成，只有资深人员M参加过该软件开发，任职最难核心模块开发， 与客户协议，在一个月内完成升级，M隶属研发部，日常经常迟到早退，研发经理口头 批评仍不改善，萌生辞退想法，M离职会严重影响项目工期，小刘提醒M，并于其领导协商， 给M一个机会，但M任然我行我素，项目开始不久，其领导口头告诉小刘要解雇M,小刘感到很为难。

案例2：小方是某集团信息处工作人员，承担集团主网站、分公司及下属机构子网站具体建设的管理工作。 小方根据在学校学习的项目管理知识，制定并发布了项目章程。因工期紧，小方仅确定了项目负责人、 组织结构、概要的里程碑计划和大致的预算，便组织相关人员开始各个网站的开发工作。 在开发过程中，不断有下属机构提出新的网站建设需求，导致子网站建设工作量不断增加， 由于人员投入不能及时补足，造成实际进度与里程碑计划存在严重偏离；同时， 因为与需求提出人员同属一个集团，开发人员不得不对一些非结构性的变更做出让步， 随提随改，不但没有解决项目进度，质量问题时有出现，而且工作成果的版本越来越混乱

案例3：某信息系统集成公司承接了一大型电子政务应用项目，由于项目涉及研发部门的多项相关技术， 合适的项目管理人员暂时缺乏，公司就委派研发部副总经理刘某担任了该项目的项目经理。 同时，公司意识到刘某担任项目经理可能会面临一些问题，特意安排公司项目管理办公室的小王专门协助刘某管理项目。 小王在项目管理办公室一直负责各种项目管理计划的审核，对制定项目管理计划非常重视，也非常熟悉。 小王在初步了解了这个项目的基本情况后，就按照公司的模板与项目组的几个核心成员共同制订了项目管理计划。 考虑到刘某第一次管理这种商业性项目，因此对很多管理细节都进行了细化，并将计划重点集中在项目执行计划的制订方面， 配置管理计划做得比较简单，刘某也根据自身多年的研发项目管理实践提出了相应的项目计划制订意见。 但由于计划涉及很多技术细节，在计划中预留了一些空白。 刘某看小王的计划制订得很详细，也觉得非常合理，就按照小王的计划开始实施项目。 一开始项目进展得非常顺利，各项工作有条不紊地进行，但是项目执行一个月以后， 却发现由于项目计划没有充分考虑到该项目的特殊性，计划内容与现实状况不符， 项目团队成员的能力与项目需要存在一定的差距，多项技术问题得不到有效解决。 项目经理刘某也明显感觉到最近变更的请求明显增加， 自己制订的比较简易的项目配置管理计划不能够满足项目整体变更的需要。

案例4：去年底某大型企业集团的财务处经过分析发现，员工手机通话量的80%是在企业内部员工之间进行的， 而90%的企业内部通话者之间的距离不到1000米。如果能引入一项新技术降低或者免掉内部员工通话费， 这对集团来说将能节省很大一笔费用，对集团的发展意义相当大。财务处将这个分析报告给了集团的总经理， 总经理又把这个报告转给了集团信息中心主任李某，责成他拿出一个方案来实现财务处的建议。 李某找到了集团局域网的原集成商A公司，反映了集团的需求。A 公司管理层开会研究后命令项目经理章某积极跟进，与李某密切联系。章某经过调研，选中了一种基于 无线局域网IEEE802.11n改进的新技术"无线通"手机通信系统，也了解到有一家山寨机厂家在生产这种新技术手机。 这种手机能自动识别"无线通"、移动和联通，其中"无线通"为优先接入。经过初步试验，发现通话效果很好， 因为是构建在集团现有的局域网之上，除去购买专用无线路由器和这种廉价手机之外，内部通话不用缴费。 而附近其他单位听说后，也纷纷要求接入"无线通"，于是章某准备放号并准备收取这些单位适当的话费。 但等到"无线通"在集团内部推广时，发现信号覆盖有空白、噪声太大、高峰时段很难打进打出， 更麻烦的是当地政府的主管部门要他们暂停并要对他们罚款。此时章某骑虎难下，欲罢不能。

案例5、某国有大型制造企业H 计划建立适合其业务特点的ERP系统。为了保证ERP系统的成功实施， H 公司选择了一家较知名的监理单位，帮助选择供应商并协助策划ERP的方案。 在监理单位的协助下，H公司编制了招标文件，并于5月6日发出招标公告，规定投标截止时间为5 月21日17时。 在截止时间前，H公司共收到五家公司的投标书，其中甲公司为一家外资企业。H 公司觉得该项目涉及公司的业务秘密， 不适合由外资企业来承担。因此，在随后制定评标标准的时候， 特意增加了关于企业性质的评分条件：国有企业可加2 分，民营企业可加1 分，外资企业不加分。 H 公司又组建了评标委员会，其中包括H 公司的领导一名，H 公司上级主管单位领导一名，其他4 人为邀请的行业专家。在评标会议上，评标委员会认为丙公司的投标书能够满足招标文件中规定的各项要求， 但报价低于成本价，因此选择了同样投标书满足要求，但报价次低的乙公司作为中标单位。 在发布中标公告后，H公司与乙公司开始准备签订合同。但此时乙公司提出， 虽然招标文件中规定了合同格式并对付款条件进行了详细的要求，但这种付款方式只适用于硬件占主体的系统集成项目， 对于ERP 系统这种软件占主体的项目来说并不适用，因此要求H公司修改付款方式。H 公司坚决不同意乙公司的要求， 乙公司多次沟通未达到目的只好做出妥协，直到第45天，H公司才与乙公司最终签订了ERP项目合同。

案例6、国有资金投资依法必须公开招标的某建设项目,采用工程量清单计价方式进行施工招标, 招标控制价为3568万元,其中暂列金额280万元。招标文件中规定： (1)投标有效期90天,投标保证金有效期与其一致。 (2)投标报价不得低于企业平均成本。 (3)近三年施工完成或在建的合同价超过2000万元的类似工程项目不少于3个。 (4)合同履行期间,综合单价在任何市场波动和政策变化下均不得调整。 (5)缺陷责任期为3年,期满后退还预留的质量保证金。 投标过程中,投标人F在开标前1小时口头告知招标人,撤回了已提交的投标文件,要求招标人3日内退还其投标保证金。 除F外还有A、B、C、D、E五个投标人参加了投标,其总报价(万元)分别为： 3489、3470、3358、3209、3542。评标过程中,评标委员会发现投标人B的暂列金额按260万元计取, 且对招标清单中的材料暂估单价均下调5%后计入报价;发现投标人E报价中混凝土梁的综合单价为700元/m3, 招标清单工程量为520m3,合价为36400元。其他投标人的投标文件均符合要求。 招标文件中规定的评分标准如下:商务标中的总报价评分60分,有效报价的算术平均数为评标基准价, 报价等于评标基准价者得满分(60分),在此基础上,报价比评标基准价每下降1%,扣1分;每上升1%,扣2分。

案例7、项目经理李工和近五十人的项目团队经过9个月的辛苦努力，在某信息系统项目约定的最后期限内 完成了信息系统的开发工作，并通过了系统试运行。尽管这是李工负责的第一个项目，但还是算圆满地结束了。 李工感觉很有成就感，也对团队成员充满了感激。由于项目工期几度耽搁，在项目最后阶段，项目团队成员 加班加点工作了近3个月，团队成员不仅精神疲惫而且因此耽误了其他项目的很多工作。 鉴于项目已经完成了试运行，李工就组织大家召开了项目总结会。在总结会上李工表示了对大家的感谢， 然后就宣布项目已经结束，项目团队成员可以各自按照原先的人力资源计划进入新的项目。 项目总结会后的第二天，建设方的项 目负责人就打来了电话，说是建设方总经理发现该信息系统还有一项功能需要添加， 尽管该功能在原先的合同中没有体现，但是总经理还是希望添加该项目功能。而且建设方的项目负责人还指出， 运行之后相关部门发觉还有一些相关的操作手册没有提供，希望建设方补充提供相关文档。 刚接完建设方项目负责人的电话，公司财务审计部门和项目管理办公室的人员也敲门进来， 首先问李工该项目是否已经完成，如果已经完成就需要走公司的相关项目收尾流程。 接着就要求李工和他的项目团队成员配合组织项目审计和项目收尾方面的工作， 并告诉李工，该项目的尾款，20%的合同金额对方还没有付，请李工催促对方尽快付款。

案例8、收尾管理：某系统集成公司承接了一个政府部门的系统集成大项目，任命张工为大项目项目经理。 张工按照项目内容，将项目分成子项目1、子项目2和子项目3，分别任命李工、王工和廖工负责。 三个项目在张工的领导及协调下进展顺利。在整个项目进行到80%时，出资人提出子项目1由于政策原因 需要终止，子项目2、子项目3继续按照原计划进行。因此张工通知李工将子项目1资料归档并提交给公司管理 资产的人员。随后为了保证子项目2、子项目3的顺利进行，张工将子项目1的项目团队解散， 有关员工加入到子项目2、子项目3中。子项目2、子项目3在张工引入新的资源后，进展顺利， 因此张工觉得不需要再加强阶段审查，等项目全部完成后再统一进行验收。 在项目结束后，张工组织客户对子项目2、子项目3分别进行验收，结果客户对子项目2的成果很不满意。 因子项目3需要的一个关键部件是子项目2提供的，最后影响了二者的总体验收，项目因此没有按时交工。

案例9、A公司是为保险行业提供全面的信息系统集成解决方案的系统集成企业。齐工是 A公司的项目经理，目前正在负责某保险公司P公司的客户管理系统开发项目，当前该 项目己经通过验收。 齐工将项目所涉及的文档都移交给了P公司，认为项目收尾工作已经基本完成， 所以解散了项目团队，并组织剩下的项目团队成员召开了项目总结会议。项目组成员 小王提出"项目组有人没有参加总结会议，是否要求所有人员都要参加？"，齐工解释 说"项目总结会议不需要全体人员参加，没有实质性的工作内容。

案例10、某高校计划建设校园一卡通项目，选择了具有自主一卡通产品的A公司作为系统集成商。 项目的主要内容是对学校的3个学生食堂、1个图书馆和1个体育馆实现统一管理， 并与学校的后勤保障和财务部门的主要业务系统联通。为保证项目的实施， 校方聘请了监理公司对此项目进行监理。 经双方协定，合同规定工期为6个月。A公司指定了项目经理小李负责该项目。项目组经 需求调研后制订了项目计划，将项目划分为需求分析、设计、卡机具生产、应用系统开发、 综合布线及硬件安装调试、软硬件系统联调、现场测试，以及验收等活动。 项目进入编码阶段后，校方领导指示，要求把另外一个教职工食堂也纳入一卡通管理， 并对学校重点教研室和实验室进行门禁管理。因此，校方代表直接找到A公司领导提出增加项目内容， 并答应会支付相应的费用，延长项目工期。由于该高校是公司重要的客户，A公司领导口头答应了客户的要求。

案例11、某市工商局为了给各个企业提供更好的服务，提高工作效率，决定建设电子政务系统， 并选择A公司承担该项目，项目的工期经双方协定为9个月。A公司指定项目经理李某负责该项目。 李某带领项目团队完成了项目的需求分析，编制了项目范围说明书，并通过了审查，得到了甲方的确认。 项目进入编码阶段后，工商局项目负责人通知李某，由于政策的变化，一些业务流程发生变更， 并答应延长项目工期2个月，同时支付相应的费用。李某凭借自己项目管理的经验， 认为这些变更在约定的工期内可以完成，因此直接答应了对方的变更要求。随后， 李某找到负责变更模块的项目组成员，要求其完成对业务流程变更的修改。 在项目继续实施的过程中，项目组成员抱怨业务流程变更较大，原来的代码很多需要重写， 很难在计划的时间内完成业务流程的变更任务。而且，系统其他模块的成员发现已经完成的 一些功能突然出现错误，经过分析发现是受业务流程变更的影响。项目团队不得不重新修改 并测试出现问题的功能模块，从而导致项目进度大大落后于计划，整个项目看来很难在预定工期内完工。

案例11、某单位甲建设数据中心管理系统，与乙公司签定了单价建设合同，与丙公司签定了监理合同。 建设合同中规定：系统提供的网络带宽不低于2Mbps，操作响应时间不超过5秒， 可支持的最大并发用户数不少于5000个。乙公司项目经理张某根据项目要求编写了范围说明书， 将WEB服务器和数据库服务器部署在一个小型机上，并编制了WBS字典，其中规定服务器安装 要在10月5日前完成，主要性能指标为响应时间不超过5秒，可支持最大并发用户数不少于5000个。 在现场设备安装调试前，建设方技术总监与张某沟通，要求提高系统可支持的最大并发用户数 至10000个并说明了原因。张某为此邀请乙公司技术总监和相关技术人员进行了商讨并制定了新的技术方案， 该方案中建议用两台小型机分别担当WEB服务器和数据库服务器。 乙公司技术总监批准了该方案，随后报建设方领导出具意见，建设方领导也批准了新方案。 张某按照批准的新方案重新采购、安装和调试了设备。项目完成后，建设方代表对系统的性能指标满意， 但不同意追加投资。乙公司为此请丙公司出面协调，然而丙公司总监以对新技术方案不了解为由拒绝在 项目验收报告上签字。

案例12、甲公司准备启动某软件项目，在项目可行性研究报告中提高项目可能会面临的市场方面的风险， 在进行项目可行性研究论证时专家提出应该把该市场风险细化，并提出解决的对策。 于是公司在可研报告之外，以会议记录的方式提出了应对该市场风险的方法， 那如果4G技术能够在2015年年底普及率达到70%及以上，则应该按照较快的进度安排尽快实施该项目， 并争取在2016年5月让产品上市，并建议项目采用V模型开发，项目的预算为1000万元。 如果届时4G普及率达不到预期的70%。则建议项目采用迭代开发模型，分阶段进行开发， 只需要在2016年5月完成部分产品即可，项目到该时点的预算为450万元， 并建议将项目的开始时间由原定的2015年8月，推迟到2015年12月，以降低项目的可能风险。 李工被临时任命为该项目的项目经理，直接归公司负责营销的王总领导。 王总让公司人力资源部门准备了项目章程，通知了财务部、人力资源部和营销部的相关人员一 起召开了项目启动会，并在会议上正式发布了项目章程和对项目经理的任命。 项目章程中包括了项目团队成员、项目的历时、项目经理的权限、项目的预算等内容， 其中的项目预算根据王总对市场的理解和判断，为1000万元。项目章程要求项目于2015年8月开始， 于2016年5月完成产品研发. 李工在项目执行过程中，发现项目章程中没有任何对于项目风险和开发模型的说明与规定， 所以李工就根据自身的经验采用了瀑布模型来安排项目工作，当项目进行到2015年12月时， 发现4G的普及率没有达到70%。公司决定暂停此项目。但是到此时为止，项目已经进展到了差不多一半， 而且项目也不能够分阶段进行开发，否则将前功尽弃。而公司质量管理部门追究相关环节的错误时， 李工觉得这样的风险不属于项目层面风险管理的内容，作为项目经理只要按照项目章程的规定执行项目就是尽责了。

案例13、某软件开发项目已进入编码阶段，此时客户方提出有若干项需求要修改。 由于该项目客户属于公司的重点客户，因此项目组非常重视客户提出的要求， 专门与客户就需求变更共同开会进行沟通。经过几次协商，双方将需求变更的内容 确定下来，并且经过分析，认为项目工期将延误二周时间，并会对编码阶段里程碑 造成较大的影响。项目经理将会议内容整理成备忘录让客户进行了签字确认。随后， 项目经理召开项目组内部会议将任务口头布置给了小组成员。会后，主要由编码人员 按照会议备忘录的要求对已完成的模块编码进行修改，而未完成的模块按照会议备忘录 的要求进行编写。项目组加班加点，很快完成了代码编写工作。项目进入了集成测试阶段。

案例14、某公司承接了一个银行业务系统的软件开发项目，质量要求非常高。 项目经理小赵制定了项目的整体计划，将项目划分为需求、设计、编码和测试四个阶段， 他将测试阶段预留了大量时间，以便开展充分的测试工作。 需求分析完成后，项目组编写了《需求分析报告》，项目经理小赵召集部分骨干人员 召开评审会。为了尽快进入下一阶段工作，评审会从早上9点一直开到晚上9点， 终于把全部的文件都审完了。评审组找到了几处小问题，并当场进行了修改， 项目经理宣布可以进入设计阶段了。编程结束后，进入了测试阶段。第一轮测试， 发现了70个缺陷。项目组对发现的缺陷进行了修改，又重新提交了测试。 第二轮又发现了100多个缺陷，就这样反复修改和测试，直到第六轮，发现了33个缺陷。 各轮发现的缺陷数如下： 轮数\缺陷数 ：第一轮/70；第二轮/117；第三轮/89；第四轮/54；第五轮/158；第六轮/33 这时，小赵终于松了一口气，由于第六轮只剩下33个缺陷，他觉得测试工作应该很 快就会结束了。

☆☆☆☆☆案例15、某系统集成企业承接了一个环保监测系统项目，为某市的环保局建设水污染自动监测系统。 该企业以往的主要业务领域为视频监控及信号分析处理，对自动控制系统也有较强的技术能力， 但从未在环保领域开发应用。该企业的老李被任命为此项目的项目经理。 该企业已按照ISO9001的要求建立了一套质量管理体系，对于项目管理、软件开发等的流程 均有明确的书面规定。但公司中很多人认为这套管理体系的要求对于项目来说是多余的，条条框框的 约束太多，大部分项目经理都是在项目结项前才把质量体系要求的文档补齐以便能通过结项审批。 公司的质量管理员也习以为常，只要在项目结束前能把文档补齐，就不会干涉项目建设。 老李组织了技术骨干对客户的需求进行了调研，通过对用户需求的分析和整理， 项目组直接制定了一个总体的技术方案，然后老李制定了一个较粗略的项目计划： 1.对市场上的采集设备进行调研，选择一款进行采购；2.利用公司已有的控制软件平台直接进行 修改开发；3.待设备选定后，将软件与采集设备进行联调实验，实现软件与设备的控制功能； 4.联调成功后，按技术方案开展整个项目的实施工作。 在软件与采集设备的联调过程中，老李请环保局的客户代表来检查工作。 客户代表发现由于项目组不了解环保领域的一些参数指标，完成的系统达不到客户方的要求。 由于项目从一开始就没有完整的项目文档，老张为了避免再出现重大问题，只好重新进行需求调研。 客户方很不满意，既担心项目不能按时上线又担心项目质量无法保证。

案例16、2007 年3 月系统集成商BXT 公司承担了某市电子政务三期工程，合同额为5000万元，全部工期预计6个月。该项目由BXT 公司执行总裁涂总主管，小刘作为项目经理具体负责项目的管理，BXT 公司总工程师老方负责项目的技术工作，新毕业的大学生小吕负责项目的质量保证。项目团队的其他 12个成员分别来自公司的软件产品研发部、网络工程部。来自研发部的人员负责项目的办公自动化软件 平台的开发，来自网络工程部的人员负责机房、综合布线和网络集成。 总工程师老方把原来类似项目的解决方案直接拿来交给了小刘，而WBS 则由小刘自己依据以往的经验进行分解。小刘依据公司的计划模版，填写了项目计划。因为项目的 验收日期是合同里规定的，人员是公司配备的，所以进度里程碑计划是从验收日期倒推到启动日期 分阶段制定的。在该项目计划的评审会上，大家是第一次看到该计划，在改了若干错别字后， 就匆忙通过了该计划。该项目计划交到负责质量保证的小吕那里，小吕看到计划的内容，该填的 都填了，格式也符合要求，就签了字。 在需求分析时，他们制作的需求分析报告的内容比合同的技术规格要求更为具体和细致。 小刘把需求文档提交给了甲方联系人审阅，该联系人也没提什么意见。 在项目启动后的第二个月月底，甲方高层领导来到开发现场听取项目团队的汇报并观看系统演示， 看完后甲方领导很不满意，具体意见如下： 系统演示出的功能与合同的技术规格要求不一致，最后的验收应以合同的技术规格要求为准。 进度比要求落后2周，应加快进度赶上计划。

案例17、A公司是从事粮仓自动通风系统开发和集成的企业，公司内的项目管理部作为研发与外部的接口， 在销售人员的协助下完成与客户的需求沟通。 某日，销售人员小王给项目管理部提交了一条信息，说客户甲要求对“JK型产品的P1组件更换为另外 型号的组件”的可行性进行技术评估。项目经理接到此信息后，发出正式通知让研发部门修改 JK型产品并进行了测试，再把修改后的产品给客户试用。但客户甲对此非常不满，因为他们的意图 并不是要单一改变JK产品的这个P1组件，而还要求把JK产品的 P1组件放到其他型号产品的外壳中，上述技术评估只是他们需求的一个方面。 经项目管理部了解，销售部其实知道客户的目的，只是认为P1组件的评估是最关键的，所以只向 项目经理提到这个要求，而未向项目经理说明详细情况。

案例18、某信息系统集成公司的项目经理李工承接了一家大型国有企业（甲方）的内部网络建设项目， 接到该任务后李工组织项目组的相关人员对该项目工作进行了仔细分析，李工根据分析结果并结合 自身的项目管理经验，得出该项目的总工作量为60人月，计划工期6个月。这样的成本估算和进度 计划也正好能够满足甲方的合同要求，项目的相关计划也得到了公司内部和甲方的认可。 项目开始一个月之后，李工的直接领导，公司的项目总监找到李工说，由于公司其他项目出现了问题， 因此要求李工要在5个月内完成项目，同时作为补偿，可以为项目增添两名开发人员。李工很为难， 他没有当时就答应项目总监的要求，而是说考虑几天再给项目总监答复。 李工在之后的几天中，一方面在团队内部召开了几次会议，广泛听取大家的意见，同时也与公司 出现问题项目的项目经理进行了沟通，基本明白了另外一个项目存在的问题和当前的状况， 李工提出了自己的解决方案，将项目分为两部分来完成，第一部分任务是基本花费4个半月的时间， 开发客户当前最重要和急需的系统；第二部分是计划历时2个月，开发客户需求的另外的功能。 同时，李工还分别编写了相关的文档，描述了新的项目计划中各部分的主要工作、相关的验收标准 和可能存在的项目风险等方面的问题。 为谨慎起见，李工在向项目总监汇报前，在项目团队内部对该计划进行了讨论，并通过甲方的 项目经理进行了侧面了解，得知甲方应该有70%的可能性同意此计划。李工就找到公司项目总监， 向其汇报了自己新的项目计划，项目总监觉得，如果按照新的项目计划实施，尽管项目工期可能 会延长半个月，但是不需要再增添开发人员，同时还能够满足另外一个问题项目对资源的要求。 大概能够为项目节约成本6万余元。项目总监在与甲方领导沟通和确认后，同意了新的项目计划。 最终项目按计划在没有增加人员的情况下顺利完成，客户对项目最终交付的系统也非常满意， 项目组成员在项目过程中也非常愉快，没有感觉到太大的压力，而公司的问题项目， 也由于获得了资源方面的及时支持，终于步入到了正常的轨道，并顺序结项。

案例19、乙公司是一家信息技术公司，主要从事信息系统集成和软件开发业务。 该公司通过员工王工的介绍与甲公司签订了大型系统开发合同，合同金额650万元， 工期11个月，该项目主要为甲公司开发一套综合管理系统，并要求新系统要与 现有生产管理系统、财务管理系统连通，以帮助甲公司落实两化（信息化和工业化） 深度融合的战略部署，提升甲公司的核心竞争力。甲公司指派信息技术中心的 赵主任负责该项目。项目启动时，乙公司领导安排王工担任此项目的项目经理， 王工自己按照公司项目章程模板撰写项目章程，进入了下一个过程， 新撰写的项目章程内容包括：质量控制人员、项目组织结构、项目基本需求、 项目完工日期。 同时为了保证项目质量，王工亲自撰写了初步的项目范围说明书。王工依照以前 公司的经验撰写的初步的项目范围说明书内容包括：项目概述、产品要求、 项目完工日期、项目约定条件、初始风险。初步的项目范围说明书撰写完成后， 王工通知了项目组成员，按照初步的项目范围说明书开始工作，项目组成员有人 认为初步范围说明书内容太过简单，跟以往项目范围说明书差别太大，但担心 项目经理不高兴，也没有直接说。 刚进入项目规划阶段，发生的几个事件让王工觉得非常棘手： （1）项目组成员就系统是否包含数据库导出、备份功能产生了分歧，查看初步的 项目范围说明书发现也没有相应描述。 （2）有项目组成员认为初步的项目范围说明书中给出的系统安全等级过高， 实现难度非常大，还可能导致项目成本大幅度增加 （3）项目组成员不确定项目验收时是否要给客户交付《产品使用手册》， 有成员建议既然不确定就不要做了，这样可以节约成本。 （4）在初步的项目范围说明书中没有涉及到项目的质量管理要求，乙公司内部的 质量技术部因此没有安排专门的人员配合王工工作。 （5）一些项目组成员经常抱怨王工大包大揽，项目启动阶段的工作不严格遵照 公司管理流程执行，也未征求其他项目组成员的意见和建议。

案例20、某公司2014年初承接了一个周期为一年的OA信息系统项目，并指派项目经理小张负责。 该项目属于定制型项目，涉及的用户方较多，小张根据自己的经验预测到项目可能会涉及频繁的 需求变更，因此小张在将项目组分成了业务组、实施组、开发组后，定义了如下需求管理及控制流程： （1）指派专门的业务组进行需求分析，分析完成后马上与用户进行需求确认，确认后填写需求状态表 （包括需求提交日期、需求状态、是否属于变更等）； （2）实施组获得需求分析文档后，一周内进行技术方案设计； （3）技术方案完成后，业务组视情况与用户进行二次沟通确认，确认后填写需求状态表 （包括需求技术方案提交日期、需求技术方案状态）； （4）需求分析、技术方案完成后，开发组每周对已确定需求进行工作量评估，形成月度开发计划； （5）开发组根据开发计划进行定制开发工作； （6）每周开发组根据需求状态库的需求、方案进行工作量重新评估，更新开发计划。 项目进行过程中，发生了如下事件，导致项目延期半年才完成： [事件1]根据2014年初的计划开发完成了OA信息系统项目并上线，但用户役有真正使用。 2014年底推广使用的时候发现，业务流程有缺失，程序有BUG，于是项目组重新按照 以上流程梳理了需求，并重新开发上线。 [事件2] 2014年底，开发组提出需求分析在深度、广度上不够，导致开发返工任务多。

案例21、项目经理小李负责了一个新的项目，该项目的内容是为某市开发一套智慧城市 公共综合信息服务平台。项目启动阶段，甲方仔细查看了小李提交的项目实施方案， 提出由于该项目的投资方构成复杂，项目需求不清晰，希望项目组能想办法解决这个问题。 小李向公司申请了几名经验丰富的系统分析师，加强需求分析阶段的工作。经过较为充分 的需求调研，形成了初步的需求说明书。小李认为需求分析工作较为详细，按照公司常用 的软件开发生命周期模型，选择了瀑布模型进行开发。 在编写概要设计和详细设计说明书的过程中，客户方提供了几处需求的修改要求。 由于其工作量不大，小李直接安排系统分析师按客户的要求进行了修改。在编码阶段后期， 由于客户的投资方发生了变化，新的投资方采用了新的运营模式，导致需求发生较大变化， 由于前期甲方已经强调过项目需求特点和要求，小李只能接受客户新的变更要求。 在执行变更的过程中，项目组发现新的需求将导致系统架构的更改， 经过评估该变更将使项目延期。

案例22、2018年1月，某系统集成公司中标本市某地铁线路的列车乘客信息系统项目， 内容包括地铁公司运营中心节目控制软件、地铁列车节目接受软件以及服务器、播放 终端等硬件设施的搭建工作。 公司任命小陈为项目经理，并从各部门抽调了经验丰富的工程师组成了项目团队。 小陈依据过去多年从事会议场所多媒体播控系统的经验，自己编写了项目范围说明书， 并依此创建了WBS和WBS词典，形成项目范围基准。在项目实施过程中，由于与 供应解码设备的厂商发生合同纠纷，项目组不得不重新寻找新的合作厂商， 并针对新的解码设备，重新开发接口软件，导致项目工期拖延。客户针对播放控制软件， 要求增加断点续传的功能，开发人员认为工作量不大就自行增加了该功能。项目测试时， 小陈发现与之前做的项目不同，地铁运行时数据是通过车地无线网络传输，带宽有限， 网络丢包现象严重，导致视频节目播放时，经常卡顿，马赛克现象严重，究其原因发现 是WBS中解决该问题的软件模块没有开发。验收时，客户对项目执行情况很不满意， 小陈觉得客户吹毛求疵与客户发生了争执，导致客户向公司高层投诉。

案例23、某信息技术有限公司中标了某大型餐饮连锁企业集团的信息系统项目， 该项目包含单店管理、物流系统和集团ERP等若干子项目。由该信息技术有限公司 的高级项目经理张工全面负责项目实施。张工认为此项目质量管理的关键在于系统地进行测试。 张工制订了详细的测试计划用来管理项目的质量。在项目实施过程中，他通过定期发给客户 测试报告来证明项目质量是有保证的。可是客户总觉得有什么地方不对劲，对项目的质量还是没有信心。

案例24、A公司是国内一家大型系统集成企业，已建立基于SJ/T11234、SJ/T11235 的涵盖公司所有部门和人员的质量管理体系。在公司建立质量管理体系之初，质量部要 求各业务部门都参加体系建设，编写程序文件和作业指导，但这些部门都说忙，难以 抽出人力。质量部便借鉴了其它公司的体系文件，对其简单修改后形成了A公司的 质量管理体系文件。 质量管理体系运行一年后，公司承担了一个大型软件集成项目。公司领导对此项目 非常重视，任命高级项目经理陈工管理此项目，并强调一定要保质保量完成。同时， 公司要求销售部、采购部、质量部各派一个人参与该项目，配合项目组开展工作。 根据公司的质量管理体系要求，项目的每个里程碑节点都要召开评审会，主要开发文档 （包括要求规格说明书、总体设计和详细设计等）都需要通过评审。事实上，在以往的 项目中，这些评审会都是项目组内讨论，讨论出结果后让相关部门负责人签字，质量部 只要看到有签字的评审记录就不干预项目的实施。由于本项目关系重大，各部门都怕出 了问题而承担责任，因此所有部门都参加了该项目的评审会。 几个评审会开完，项目组成员开始抱怨。说以前的项目评审都是我们自己讨论，其它 部门根本没人仔细看。可是现在这个项目，各个部门都有人参与，评审会上每个人都提 意见，并且意见经常不一致，没有人负责最后拍板；对于有些技术文件的评审，评审 人员明明不懂还提出很多问题，还要费很大力气给他们解释。 在以往的项目中，虽然公司的程序文件中规定评审没通过就不能进入下一环节，但如果 进度要求紧张的话，一般也不管什么流程了，抢进度要紧。但是在这个项目中，设计方案 经过几次讨论都没有结果。项目经理陈工为了保证进度，向采购部提出提前采购设备， 采购部以设计方案没有定稿为理由拒绝处理。无奈陈工找了好几次公司领导，最终领导 拍板可以提前采购。项目就这样在不断的争执过程中进行，每次争执不下时陈工就去找 公司领导。如此多次争执后，陈工发现质量管理体系文件中规定那么多评审纯粹是 浪费时间，希望修改。 按照计划，现在项目应该进行到测试阶段，但实际上项目的详细设计还未通过评审。

案例25、小赵被任命为某软件开发项目的专职质量管理人员，他此前只有过 三个月的软件开发经历。项目经理李工要求他按照项目进度计划中的工作安排， 按时做好检查，发现问题随时汇报。 项目启动后，由于进度紧张，项目组经常加班，小赵在质量检查中，总会遇到 这样那样的问题，例如，计划时间点已到，工作却没有按时完成，因此，无法 开展检查；相关人员工作太忙，无法配合检查等。不久，项目组成员对小组的 工作颇有怨言，说他不懂技术，还得浪费时间跟他解释，有的还说进度已经 这么紧张了，他不帮忙却来添乱。小赵很无奈，将这些情况汇报给项目经理 李工，李工也觉得比较棘手，要求小赵尽量在不打扰大家工作的情况下执行检查。 项目组在超负荷运转中完成了编码任务，虽然天天加班，但进度还是延误了 20%，此时己经不能按原计划开展测试工作，项目经理李工决定调整计划， 不划分测试阶段，将所有模块一次集成后统一开始测试。软件模块集成后， 头一轮测试刚开始就出现了致命错误，导致测试元法继续，李工只好让开发 人员先修复软件，之后再提交侧试，随后的测试过程更加混乱，由于模块由 不同人员开发，需要不同的人来修改，常常是已修复的BUG，在修复其他的 BUG之后又再次出现，开发人员不停修改，项目交付时间临近，程序中还有 大量BUG没有修复。

案例26、A公司是一家大型信息系统集成公司，具有多年的系统集成项目实施经历， 成功地在多个行业进行了系统集成项目建设，取得了较多的成果，在业内具有较好 的口碑。 2013年年初，A公司通过竞标获得某市人口管理信息系统工程项目。A公司高层 认为，尽管该项目的许多需求还没有完全确定下来，但是总体感觉上同以往曾经 开发过的项目比较，还是比较简单，对完成这样的项目充满信心。 项目前期，A公司请王副总经理负责此项目的启动工作。王副总经理简单了解项目 的概要情况后制定并发布了项目章程，任命小丁为项目经理。项目团队根据分工 制定了相应的项目管理子计划。据此，项目经理小丁把各个子计划归并为项目 管理计划。 为了保证项目按客户要求尽快完成，小丁基于自身的行业经验和对客户需求的 初步了解，即安排项目团队开始进行项目实施，在系统开发过程中，建设方提出 的建设需求不断变化，小丁本着客户至上的原则，总是安排项目组进行修改， 从而导致开发工作多次反复。而因为项目计划的多次变化，导致项目团队的成员 也经历过多次调整，实际进度与里程碑计划存在严重偏离，并且项目的质量指标 也经常暴露出问题。 A公司项目管理办公室在对项目阶段审查时，感到很吃惊，并对发生这种情况 觉得很不理解，认为即使是需求不完善也不至于导致项目存在这么多问题， 觉得该项目在管理方面肯定存在很多问题。

案例27、某系统集成公司A中标某信息中心IT运维平台开发项目，公司A任命小李为项目经理。 小李在项目启动阶段确定了项目团队和项目组织架构，项目团队分为三个小组：研发组、测试组 和产品组。各组成员分别来自研发部、测试部以及产品管理部。 小李制定了项目整体进度计划，将项目分为需求分析、设计、编码、试运行和验收五个阶段。 为保证项目质量，小李请有着多年的编码、测试工作经历的测试组组长张工兼任项目的质量保证人员。 在项目启动会上，小李对张工进行了口头授权，并要求张工在项目的重要阶段（如完成需求分析、 完成总体设计、完成单元编码和测试等）必须对项目交付物进行质量检查。在检查时，张工可以 根据自己的经验提出要求，对于不满足要求的工作，必须立即进行返工。 项目在实施过程中，遇到一些问题，具体如下： 在项目组完成编码与单元测试工作，准备进行系统集成前，张工按照项目经理小李的要求进行了 质量检查。在检查过程中，张工凭借多年开发经验，认为某位开发人员负责的一个模块代码存在 响应时间长的问题，并对其开具了不符合项报告。但这位开发人员认为自己是严格按照公司编码 规范编写的，响应时间长不是自己的问题。经过争吵，张工未能说服该开发人员，同时考虑到该 模块对整体项目影响不大，张工没有再追究此事，该代码也没有修改。 在项目上线前，信息中心领导组织技术专家到项目现场进行调研和考察。专家组对已完成的编码 进行了审查，发现很多模块不能满足甲方的质量要求。

案例28、A公司属于创业型公司，随着公司业务规模的扩大，公司领导决定成立专门 的质量管理部门，全面负责公司所有项目的质量，并降低产品的缺陷率。公司还聘任 了具有多年质量管理经验的张工担任公司质量管理部门的经理。 张经理上任后，从每个项目组中抽调了一名QA，QA隶属于公司质量部，工作地点在 各个项目所在地点，与项目组一起工作，负责所在项目的质量管理。小王是X项目的 QA，当前X项目正在研发阶段。张经理要求小王按照项目进度提交一份项目质量管理 计划，并提供了常规质量管理计划的模板，主要包括质量检查点、检查人、检查内容、 检查时间、检查方式等。小王于是按照张经理的要求编写并提交了《项目质量管理 计划-X项目》。 过了2个月，张经理根据质量管理计划的某一个时间点，询问小王某一个设计评审的 会议情况时，小王没有找到有关的会议记录。张经理又电话询问X项目的项目经理有关 质量管理的情况，该项目经理认为质量管理是由小王根据质量管理部门的要求进行的， 自己会大力配合。

案例29、A公司承接了某银行大型信息系统建设项目，任命张伟担任项目经理。 该项目于2017年年初启动，预计2018年年底结束。 项目启动初期，张伟任命项目成员李明担任项目的质量管理员，专职负责质量管理， 考虑到李明是团队中最资深的工程师，有丰富的实践经验，张伟给予李明充分授权， 让他全权负责项目的质量管理。 得到授权后，李明制定了质量管理计划，内容包括每月进行质量抽查、每月进行 质量指标分析、每半年进行一次内部审核等工作。 2017年7月份，在向客户进行半年度工作汇报时，客户表示对项目的不满，一是 项目进度比预期滞后:二是项目的阶段交付物不能满足合同中的质量要求。 由于质量管理工作由李明全权负责，张伟并不清楚究竟发生了什么问题，因此， 他找李明进行了沟通，得到两点反馈: 1.在每月进行质量检查时，李明总能发现些不符合项。每次都口头通知了当事人， 但当事人并没有当回事，同样的错误不断重复出现： 2.李明认为质量管理工作太得罪人，自己不想继续负责这项工作。 接着，张伟与项目组其他成员也进行了沟通，也得到两点反馈: 1.李明月度检查工作的颗粒度不一致。针对他熟悉的领域，会检查得很仔细： 针对不熟悉的领域，则一带而过: 2.项目组成员普遍认为:在项目重要里程碑节点进行检查即可，没必要每月进行检查。

案例30、系统集成商B公司中标了某电子商务A企业的信息系统硬件扩容项目，项目内容为采购 用户制定型号的多台服务器、交换设备、存储设备，并保证系统与原有设备对接，最后实现A企业 的多个应用系统迁移，公司领导指定小周为该项目的项目经理。 小周担任过多个应用软件开发项目的项目经理，但没有负责过硬件集成项目 小周召开了项目启动会，对项目进行了分解，并给项目成员分配了任务，接下来，安排负责技术 的小组长先编制项目技术方案，同时小周根据合同中规定的时间编制了项目的进度计划并发送给 项目组成员，进度计划中确定了几个里程碑点：集成技术方案、设备到货、安装调试完成、 应用系统迁移完成。由于该项目需要采购多种硬件设备，小周将进度计划发送给了采购部经理， 并与采购经理进行了电话沟通。 技术方案完成后通过了项目组的内部评审，随后项目组按照技术方案开始进行设备调试的准备工作， 小周找到采购部经理确认设备的到货时间，结果得到的答复是：服务器可以按时到场，但存储设备 由于运输的原因，要晚一周到货。 由于存储设备晚到的原因，安装调试工作比计划延误了一周时间，在系统调试的过程中，项目组 发现技术方案中存在一处错误，又重新改进了技术方案，造成实际进度比计划延误了两周，A企业 得知系统迁移时间要延后，非常不满意，并到B公司高层领导投诉。

案例31、某系统集成商A公司承担了某科研机构的信息系统集成项目， 建设内容包括应用软件开发、 软硬件系统的集成等工作。在项目建设过程中，由于项目建设单位欲中报科技先进单位， 需将此项目成果作为申报的重要内容之一，在合同签订后 30天内，建设单位向A公司 要求总工期由 10个月压缩到6个月，同时增加部分功能点。由于此客户为 A 公司的 重要客户，为维护客户关系， A公司同意了建设单位的要求。为了完成项目建设任务， A公司将应用软件分成了多个子系统，并分别组织开发团队突击开发， 为提高效率， 尽量采用并行的工作方式， 在没有全面完成初步设计的情况下， 有些开发组同时 开始详细设计与部分编码工作； 同时新招聘了6 名应届毕业生加入开发团队。 在项目建设过程中， 由于客户面对多个开发小组， 觉得沟通很麻烦， 产生了 很多抱怨，虽然 A公司采取了多种措施来满足项目工期和新增功能的要求， 但项目还是频繁出现设计的调整和编码工作的返工，导致项目建设没有在约定的 6个月工期内完成，同时在试运行期间系统出现运行不稳定情况和数据不一致的情况， 直接影响到建设单位科技先进单位的申报工作； 并且项目建设单位对 A公司按合同 规定提出的阶段验收申请不予回应。

案例32、某项目经理将其负责的系统集成项目进行了工作分解，并对每个工作单元 进行了成本估算，得到其计划成本。第四个月底时，各任务的计划成本、实际成本 及完成百分比如下表：

案例33、张某是M公司的项目经理，有着丰富的项目管理经验，最近负责某电子商务 系统开发的项目管理工作。该项目经过工作分解后，范围已经明确。为了更好地对项目 的开发过程进行监控，保证项目顺利完成，张某拟采用网络计划技术对项目进度进行管理。 经过分析，张某得到了一张工作计划表，如表1所示。 事件1：为了表明各活动之间的逻辑关系，计算工期，张某将任务及有关属性用以下样图表示， 然后根据工作计划表，绘制单代号网络图。 其中，ES表示最早开始时间；EF表示最早结束时间；LS表示最迟开始时间；LF表示最迟结束时间； DU表示工作历时；ID表示工作代号。 事件2：张某的工作计划得到了公司的认可，但是项目建设方（甲方）提出，因该项目涉及融资， 希望项目工期能够提前2天，并可额外支付8万元的项目款。 事件3：张某将新的项目计划上报给了公司，公司请财务部估算项目的利润。

案例34、A公司是一家专门从事系统集成和应用软件开发的公司，目前有员工100多人， 分属销售部、软件开发部、系统网络部等业务部门。公司销售部主要负责服务和产品的 销售工作，将公司现有的产品推销给客户，同时也会根据客户的具体需要，承接信息 系统集成项目，并将其中应用软件的研发任务交给软件开发部实施。 经过招投标，A公司承担了某银行的系统集成项目，合同规定，5月1日之前统必须完成， 并且进行试运行。合同签定后，项目的软件开发任务由软件开发部负贡，硬件与网络 由系统网络部负责设计与实施。王工担任这个项目的项目经理。王工根据项目需求， 组建了项目团队，团队分成软件开发小组和网络集成小组，其中软件开发小组组长 是赵工，网络集成小组组长是刘工。王工制定了项目进度计划，图1该项目的进度网络图。 软件开发中，发现有两个需求定义得不够明确，因此增加了一些功能，导致功能模块设计 延长了五天。网络集成过程中，由于涉及到物联网等新技术，综合布线延迟了五天， 接着采购的一个新设备没有按时到货，到货之后在调试过程中遇到了以前没有遇到的问题， 使网络设备安装调试延迟了7天。两个小组分别通过电话向各自部门通报项目进展， 而网络集成工作是在用户现场进行的，因此阿络集成的进度状况在公司总部进行开发工作 的软件开发小组并不了解。上述问题导致了项目整体进度的拖延，绩效状况不佳。

案例35、某项目进入详细设计阶段后，项目经理为后续活动制定了如图2所示的网络计划图， 图中的“△”标志代表开发过程的一个里程碑，此处需进行阶段评审，模块1和模块2都要通过 评审后才能开始修复。 项目经理对网络图中的各活动进行了成本估算，估计每人每天耗费的成本为1000元，安排了 各活动的人员数量并统计了模块1、模块2的开发和测试活动的工作量（如表2所示），其中 阶段评审活动不计入项目组的时间和人力成本预算，如表2所示。

案例36、W公司与所在城市电信运营商Z公司签订了该市的通信运营平台建设合同。W公司为此 成立了专门的项目团队，由李工担任项目经理，参加项目的还有监理单位和第三方测试机构。 李工对项目工作进行了分解，制作出如下表所示的任务清单。经过分析后李工认为进度风险 主要来自需求分析与确认环节，因此在活动清单定义的总工期基础上又预留了4周的应急储备时间 。该进度计划得到了Z公司和监理单位的认可。 在项目启动与人员、资源调配（任务A）阶段，李工经过估算后发现编码、单元测试、集成测试 （任务F）的技术人员不足。经公司领导批准后，公司人力资源部开始招聘技术人员，项目前期 工作进展顺利，进入详细设计（任务E）后，负责任务E的骨干老杨提出，详细设计小组前期没有 参加需求调研和确认，对需求文档的理解存在疑问。经过沟通后，李工邀请Z公司用户代表和项 目团队相关人员召开了一次推进会议。会后老杨向李工提出，由于先前对部分用户需求的理解有误， 须延迟4周才可完成详细设计。考虑到进度计划中已预留了4周的时间储备，李工批准了老杨的请求， 并按原进度计划继续执行。 任务E延迟4周完成后，项目组织开始编码、单元测试和集成测试（任务F）。此时人力资源部招聘 的新员工陆续到职，为避免进度延误，李工第一时间安排他们上岗。新招聘的员工大多是应届毕业生， 即便有老员工带领，工作效率仍然不高。与此同时，W公司领导催促李工加快进度，李工只得组织新 老员工加班。虽然他们每天加班，可最终还是用了20周才完成原来计划用15周完成的任务F。此时 已临近春节假期，在李工的提议下，W公司决定让项目组在假期结束前提前1周入驻Z公司进行现场安装 与软硬件联合调试。由于Z公司和监理单位春节期间只有值班人员，无法很好地配合项目组工作， 导致联合调试工作进展不顺利。为了把延误的进度赶回来，经公司同意，春节后一上班，李工继续组织 项目团队加班。此时许多成员都感到身心疲惫，工作效率下降，对项目经理的安排充满了抱怨。

案例37、某项目是一个新产品开发项目，项目计划开发周期为12个月，项目团队有11个人， 包括：项目经理1人，开发工程师5人，测试工程师2人，文档工程师1人，配置管理1人，SQA1人。 项目于2010年7月1日开始，项目计划如下：需求分析一个月，总体设计一个月，详细设计二个月， 编码五个月，测试一个半月，文档准备、客户验收测试半个月，修改BUG 并发布半个月，项目开工后，项目团队充满激情地努力工作，项目经理也非常有信心按期完成该项目， 并在开工会上公布了该项目的考核与激励制度。 2010年8月1日，项目组按期完成《需求规格设计说明书》；2010年9月1日，按期完成了总体设计。 此时，市场部提出，最近有几名客户都问到这个产品了，9月份可能有客户要看演示的DEMO,需要加快 开发进度，问项目经理是否可以先开发DEMO,详细设计后后面再补充，先把产品的原型做出来。 项目经理经过与项目组及项目管理部协商，决定去掉详细设计这个环节，直接进入产品的编码阶段， 安排开发工程师根据总体设计负责各自模块的开发工作。 5名开发工程师组成的开发小组进入非常忙碌的编码阶段后，经常加班加点，开发过程中，由于原来制定 的计划已完全被打乱，SQA无法再根据原来的质量保证计划进行跟踪，项目组其他人员也已无法发挥作用。 2011年2月15日，项目经理向公司管理层反映这个项目存在的问题，市场部提的需求有部分不能实现， 遇到了技术瓶颈，而且有团队成员要离职，为此由项目管理部组织会议，对新增的部分需求进行评审， 包括研发总监、研发副总裁在内，最终决定产品要继续开发， 确定关键技术问题的解决时间为2011年3月15日，其他工作继续进行。 遗憾的是，关键技术问题一直到5月1日才解决，这时已有2名开发人员因为信心问题而离职，项目经理 除了要考虑项目进度外，还要考虑项目资源，由于此时其他项目任务也很重，公司资源很紧张，他不得 不重新招聘开发人员。 等项目经理招到2个新人后，已是2011年6月15日，这本应是项目计划中系统测试结束的关键里程碑， 但现在编码任务至少还需要1个月，在公司的月度会议上，项目经理向包括总裁在内的各位高层领导 做了汇报，并因为项目进度延迟受到了批评。 2011年8月1日，测试部终于拿到了系统的第一个测试版本。 2011年10月20日，系统终于开发和测试完毕，测试部输出最终的测试报告，同意该产品向市场发布， 所有的文档，包括《详细设计》、《需求规格说明书书》、《产品说明书》 等还没有上传到配置库。

案例38、一个信息系统集成项目有A、B、C、D、E、F共6个活动，目前是第12周末，活动信息如下： 活动A：持续时间5周，预算30万元，没有前置活动，实际成本35.5万元，已完成100%。 活动B：持续时间5周，预算70万元，前置活动为A，实际成本83万元，已完成100%。 活动C：持续时间8周，预算60万元，前置活动为B，实际成本17.5万元，已完成20%。 活动D：持续时间7周，预算135万元，前置活动为A，实际成本159万元，已完成100%。 活动E：持续时间3周，预算30万元，前置活动为D，实际成本0万元，已完成0%。 活动F：持续时间7周，预算70万元，前置活动为C和E，实际成本0万元，已完成0%。 项目在开始投入资金为220万元，第10周获得投入资金75万元，第15周获得投入资金105万元，第20周获得投入资金35万元。