王某为某系统集成公司项目经理，负责某医院信息项目的管理。王某在和客户的接触中，客户对王某的评价很好，认为王某待人客气，技术强，没有架子，和他合作很愉快。

而项目团队成员确对王某有另外一种感觉，认为王某召开的项目会议上主题不明确，内容乏味，会议让人昏昏欲睡。对于王某自己给项目团队成员举办的培训讲座，项目团队成员觉得王某对于培训内容中的细节讲得很深，但不能获得整体概念，经常花了很长的时间，但内容只能讲授一点点。

王某对于内部和外部的评论感到很困惑。

[问题1]王某在沟通管理中存在什么问题？
（1）王某不具备和其他沟通风格的人进行沟通的技巧
（2）王某没有针对项目团队成员的沟通风格作相应的分析
（3）王某不具备组织高效会议的能力
（4）在项目会议中，王某对项目会议的准备并不充分
（5）王某不具备对别人培训时要求的技巧

某系统集成公司最近承接了一个项目，客户是该公司的老主顾。当时公司的总经理急着要出差，所以在软件模块界定和验收标准还不明确的情况下，就和客户签订了合同，并任命张工为这个项目的项目经理。

经过紧张的准备，项目终于启动了。第一个阶段结束后，在结果评估时，双方发生了分歧。客户认为模块中缺少一部分功能，而张工认为客户提出的功能在合同之外，如果要做，就要做项目变更，重新核算成本。由于合同中对此内容的界定不明确，双方各执一词，僵持不下，客户拒绝验收，项目的回款眼瞅着要泡汤。

后来项目组的程序员小王请求张工为他增派人手，说他的任务完不成了，可张工安排给他的工作已经做完了。经过了解，张工才知道，客户小刘几次请小王开发一些小的模块，小王也没向张工请示，就自作主张给做了。这次，他又答应在客户原有的模块上增加统计功能，结果做起来才发现实现不了，这才向张工求救。张工赶紧和客户沟通，要求作项目变更，可客户咬死说前几次都是免费的，这次也应该免费。

[问题1]张工所负责的项目在变更管理中存在哪些问题？
（1）在项目功能和标准不明确的时候就签订了合同，为后来的项目变更埋下了隐患
（2）没有建立项目变更管理制度
（3）涉及变更开发人员随便答应，没有上报给项目经理
（4）变更请求没有经过评估，没有评估产生的费用和技术要求，也没有签字确认，采用口头协议
（5）变更实施时没有考虑对系统其他功能的影响，也没有考虑能否实现
（6）变更后没有进行验证
（7）没有对变更后的内容进行存档，也没有通知给相关的项目干系人

某地区政府部门建设一个面向公众服务的综合性网络应用系统，对现有的零散管理系统和服务平台进行重组和整合，整个项目由政府的信息中心负责统一规划分期建设，由各共建单位的主要领导组成了领导小组，招标选择了监理公司全程监理建设过程。一期重点建设了社保、民政和交换中心三个应用系统。

建设过程中由于机构改革、职能需要重新定位等原因，《需求规格说明书》始终找不到最终用户签字，在监理方和承建单位的一再努力下，只有一个共建单位的主管领导在该子系统的需求分析上签字确认。为了赶进度，承建单位决定先行设计和实施，监理方认为可以理解且就目前的实际情况而言，也只好默许。

工程竣工验收时，承建单位向监理单位提交了验收申请，并将竣工验收所需的全部资料报送监理单位，申请竣工验收。总监理工程师认为系统已经过初验和 3 个月的试运行，并且运行情况良好，随即对验收申请予以签字，并协助建设单位进行后续的验收工作。

[问题1]竣工验收时，总监理工程师在执行验收程序方面的做法正确吗？
不正确
正确的做法是：承建单位提出验收申请后，监理单位（或总监理工程师）应该首先对其验收计划和验收方案进行审查。主要审查内容包括验收目标、各方责任、验收内容、验收标准和验收方式。

某信息系统项目包含如下十个活动。
活动的历时、活动逻辑关系如下图所示：

[问题1]该项目的关键路径和总工期是多少？
关键路径：ADCEIJ；总工期为21天

[问题2]活动E、G的总浮动时间和自由浮动时间是多少？

在项目开始前，客户希望将项目工期压缩为19天，并愿意承担所发生的所有额外费用，经过对各项活动的测算发现，只有活动B、D、I有可能缩短工期，其余活动均无法缩短工期，活动B、D、I最多可缩短的天数及额外费用如下：

[问题3]在此要求下，请计算出费用最少的工期压缩方案及额外增加的费用？
思路：B没必要减少，ABCEHJ19天，ABCEIJ20天可以减少关键路径I一天，D和I都是关键路径，D费用少一些
压缩方案：D压缩一天并增加费用2500元，I压缩一天并增加费用3000元，需额外增加5500元

某公司近年随着项目增多，公司决定开发自己的生产线，为了快速建立自己的生产工艺流程，聘任了有研发设计经验的小张来担任生产部经理
小张通过招聘、内部挖潜等方式建立了自己的生产团队，涵盖了采购、质检、生产等各个环节专业人员，开始组织生产。
在生产过程中，小张发现改动某项设计，产品性能会有提升，于是经常习惯性地在生产过程中就进行了更改，未走设计变更流程（公司早已下发变更流程）。
在项目实施过程中，总会出现一些质量问题，有时较为严重会出现质量事故。
事故追责小组调查发现，生产制造的图纸与提交的管理图纸不一致，有不同程度的改动。生产制造的图纸是会从研发部最新的图纸调取来转入生产；而从研发调用的图纸，生产过程中生产人员又进行了改动（原则上没有更改权限），更改后图纸没有经过评审，因为生产经理总是认为小改动不需要组织评审，耗时耗力。这样就造成研发人员图纸更新不及时，导致研发、生产、综合部归档资料不一致。

小张是 XYZ 信息系统集成公司的项目经理，负责一电子政务项目的管理。李先生是甲方负责该项目的项目经理。

一次，小张邀请李先生出去吃饭，同行的还有双方的部分团队成员。几杯酒过后，小张团队有两名成员由项目的技术架构开始争论，进而抱怨项目的激励政策，最后开始攻击 XYZ 公司，指出其人力资源管理方面的诸多问题。

小张感到非常没面子，认为在外人面前贬低团队和公司是一种非常恶劣的行为。事后，这两名队员打电话给李先生，声称他们负责的模块含有“逻辑炸弹”代码。
这件事给小张负责的项目造成了很大的被动。

【案例背景】

小张是某公司的项目经理，他一直为安排下属工作而感到苦恼，主要在以下几个方面：
1.安排好的工作，员工做的结果与小张预期的结果相差较大，每次提交上来的结果，小张都必须重新整理，有些甚至需要重做；

2.员工做事情时，小张因为工作忙，所以不能去检查每个人的工作，但员工从来不主动报告进展情况，所以稍微没注意，原本安排好的事情就不能按时完成；

3.每次对员工考核时，不知道该怎么进行考核，因为所有的人员感觉都没有很好的完成他们的工作，但每一个人都有很充分的理由推卸责任；

4.因为公司业务扩大，小张需要同时管理两个项目，原来一个项目都精疲力尽，如果再加一个项目，小张不敢想象工作会如何….

[问题1]导致这种情况出现的原因是什么？

1.问题出在安排工作的规范上，需求不够规范或描述过于自我，没有站在对方的理解角度去描述
2.沟通机制不清晰，或权重不足，造成团队成员不重视项目或领导权威
3.没有主动建议建立考核机制，导致团队没有明确绩效目标
4.没有分权给合适的人去分担管理压力
5.员工做的不好的工作他会帮忙“擦屁股”，这会无意中增加员工的依赖性

[问题2]小张该怎么解决这种情况呢？
1.确认项目整体绩效，签订绩效任务书或项目任务书（项目章程、会议纪要都可以）；
2.确定责任分配矩阵，规范工作流程和标准，考核一定要清晰明确和可量化的验收标准
3.制定具体的沟通规则和频次，如统一的工作汇报模板，日报或周报等；或使用管理工具把控任务进展
4.团队中注意分权，比如对于项目绩效，可以设立绩效负责人对阶段性进行考核，和绩效负责人进行一对一沟通做改进事项记录和调整

【案例背景】

小张在传统制造业工作，公司有专门的产品部和产品经理，负责产品开发。公司使用的开发流程为门径管理。

由于公司没项目部门，涉及到多部门协作的产品开发项目，其他部门参与程度较低，积极性也很低。

目前产品开发项是由小张（研发经理）主导，但是协调资源比较困难，公司高层没有项目管理意识，主观上认为其他部门应该积极配合。偶尔高层过来时，其他部门配合程度会有改善，但高层一回总部，配合就基本没有了。

[问题1]什么是门径管理流程？该公司的管理流程需要改进吗？

（1）一种广泛使用的产品开发流程，有管理决策关口分隔开的一时间排序的不同阶段。在获得管理许可进入下一产品开发阶段之前，多职能开发团队必须成功完成当前阶段的相关任务，这项规则适用于每一阶段。门径管理流程的框架包括工作流程和决策流程。门径管理流程定制出确保流程得以顺利进行的支持体系。优点是有原则好管理，缺点是易僵化官僚化。

【案例背景】

某省财政厅在2003年定制开发了一套业务信息系统，通过7年的使用，运行稳定。

但是，这7年来，内部各业务处室的设置发生了很多大变化。同时，由于国家有关政策也进行了相应的调整，该厅所辖市、区、县的对应机关也有所变化。

因此，原来的系统已经满足不了当前业务的需要，该省财政厅在征集了各业务处室的改进建议后， 决定借鉴原系统的成功经验，重新开发一套新的业务信息系统。

为了保证新系统不但能满足当前的需求，同时还要具有一定扩展性和先进性，以及业务处理的灵活性，该省财政厅信息中心聘请了 C 顾问团项目管理专业的首席顾问田先生担任项目顾问，咨询项目开发注意事项。

【案例背景】

陈某为某系统集成公司项目经理，负责某国有企业信息化项目的建设。

陈某在带领项目成员进行业务需求调研期间，发现客户的某些部门对于需求调研不太配合，时常上级推下级，下级在陈述业务时经常因为工作原因在关键时候被要求离开去完成其他工作，而某些部门对于需求调研只是提供一些日常票据让其进行资料收集，为此陈某非常苦恼。

勉强完成了需求调研后，项目组进入了软件开发阶段，在软件开发过程中，客户经常要求增加某个功能或对某个表进行修改，这些持续不断的变更给软件开发小组带来了巨大的修改压力，软件开发成员甚至提到该项目就感觉没动力。

项目期间由于客户需求变更频繁，陈某采取了锁定需求的办法，即在双方都确认变更后，把变更内容一一列出，双方盖上公司印章生效，然而这样做还是避免不了需求变更，客户的变更列表要求对方遵守承诺，客户却认为这些功能是他们要求的， 如果需要新的变更列表，他们可以重新制作并加盖印章。