2022年项目管理失败的案例分析
都说项目经理的时间分配应该是3-7法则，即30%时间用于管理，70%时间用于沟通，可见沟通的重要性。下面，小编为大家分享项目管理失败的案例分析，希望能帮助到大家!
沟通管理案例
某系统集成商B负责某大学城A的3个校园网的建设，是某弱电总承包商的分包商。田某是系统集成商B的高级项目经理，对三个校园网的建设负总责。关某、夏某和宋某是系统集成商B的项目经理，各负责其中的一个校园网建设项目。项目建设方聘请了监理公司对项目进行监理。
系统集成商B承揽的大学城A校园网建设项目，计划从2002年5月8日启动，至2004年8月1日完工。期间因项目建设方的资金问题，整个大学城的建设延后5个月，其校园网项目的完工日期也顺延到2005年1月1日，期间田某因故离职，其工作由系统集成商B的另一位高级项目经理鲍某接替。
鲍某第一次拜访客户时，客户对项目状况非常不满。和鲍某一起拜访客户的有系统集成商B的主管副总、销售部总监、销售经理和关某、夏某和宋某3个项目经理。客户的意见如下：
你们负责的校园网项目进度一再滞后，你们不停地保证，又不停地延误。
你们在实施自己的项目过程中，不能与其他承包商配合，影响了他们的进度。
你们在项目现场，不遵守现场的管理规定，造成了现场的混乱。
你们的技术人员水平太差，对我方的询问，总不能提供及时的答复。
听到客户的意见，鲍某很生气，而关某、夏某和宋某也向鲍某反映项目现场的确很乱，他们已完成的工作经常被其他承包商搅乱，但责任不在他们。至于客户的其他指控，关某、夏某和宋某则显得无辜，他们管理的项目不至于那么糟糕，他们项目的进展和成绩客户一概不知，而问题却被扩大甚至扭曲。
问题1
请简要叙述发生上述情况的可能原因有哪些?
问题2
针对监理的作用，承建方如何与监理协同?
问题3
简要指出如何制定有多个承包商参与的项目的沟通管理计划?
案例分析
问题1
田某是系统集成商B的高级项目经理，但后来离职，由鲍某接替。而鲍某接任高级项目经理时，似乎对整个项目一无所知，这至少说明系统集成商B的内部管理有问题，对整个项目监管缺位或不得力，没有及时把项目经验累积为组织资产。
“期间因项目建设方的资金问题，整个大学城的建设延后5个月”，这说明客户自己本身的原因，导致项目发生延迟以后的混乱状况。
“至于客户的其他指控，关某、夏某和宋某则显得无辜，他们管理的项目不至于那么糟糕，他们项目的进展和成绩客户一概不知，而问题却被扩大甚至扭曲”，这则说明，系统集成商B没有或极少与客户进行直接沟通，导致客户对自己的工作不熟悉。
客户从总承包商或其他承包商那里获得的信息有失真。从试题描述来看，显然，总承包商报告渲染了问题，推卸了责任。
“听到客户的意见，鲍某很生气，而关某、夏某和宋某也向鲍某反映项目现场的确很乱，他们已完成的工作经常被其他承包商搅乱，但责任不在他们”，这说明系统集成商B没建立现场管理制度，或者现场管理制度不严密不明确，或现场管理制度执行不力。
而且，总承包商与分包商(系统集成商B)责任不是十分清楚。
最后，因为在这个项目中，还有第三方(监理方)的参与，监理方是代表建设方对整个项目进行监控的，但在监控之下，项目仍然发生混乱，这说明项目的监理工作没有到位。
问题2
这是一个理论性问题，与试题的案例描述没有关系。
监理作为独立的第三方，需要公平、公正、公立地处理项目建设过程中所出现的问题，维护各方利益。监理方与承建方是没有合同关系的，监理方与建设方签订监理合同，按照监理合同的要求来对承建方的建设工作进行监控，其监控的依据之一就是承建方和建设方所签订的建设合同，其目的就是要确保项目按期完成，并达到建设合同的要求。
因此，承建方要正确认识监理方的作用，要认识到承建方和监理方不是对立关系，而是有着共同的目标，就是完成项目目标。
在项目管理方法上，采取的是“三方一法”，即建设方、承建方、监理方都采用项目管理方法来对项目进行管理，监理的主要内容是“四控三管一协调”，承建方也需要在这些方面进行配合，接受监理的监督和协调，有关中间成果需要通过监理的审核或评审。
另外，承建方要积极主动地与监理方搞好关系，进行周期性的沟通，确保项目“沟通无障碍”。
问题3
这也是一个理论性试题，与试题描述的案例背景的关系不大，考查的内容是项目沟通管理计划的制定。有关这方面的内容，在第12章中有详细的介绍，在此不再重复。
解答要点
问题1
(1)系统集成商B内部管理有问题，至少监管缺位或不得力。
(2)系统集成商B没有或极少与客户进行直接沟通。
(3)没建立现场管理制度，或者现场管理制度不严密不明确，或现场管理制度执行不力。
(4)总承包商与分包商责任不是十分清楚。项目经理圈子
(5)客户从总承包商或其他承包商那里获得的信息有失真。总承包商报告渲染了问题，推卸了责任。
(6)客户自己本身的原因。
(7)监理工作做得不好。
问题2
(1)承建方要正确认识监理的作用，他们和监理方不是对立关系，而是有共同的目标，就是把项目做好。
(2)双方都采用项目管理的方法，承建方协助和配合监理方对项目的“四控三管一协调”，接受监理方的协调和监督，中间成果需要通过监理方的评审。
(3)承建方和与监理方要进行周期性的沟通。
问题3
(1)调研各集成商的沟通需求，进行项目干系人分析。
(2)发挥总承包商牵头作用和监理方的协调作用。
(3)对共用资源的可用性进行分析，引入资源日历。
(4)解决冲突，包括干系人对项目期望之间的冲突、资源冲突等。
(5)建立健全项目管理制度并监管其执行。
(6)采用项目管理信息系统。
一个失败的项目管理案例分享
1、背景介绍
从 2020 年三月底开始做一个设计管理平台的项目，我被指派为这个项目的项目经理，项目成员包括产品经理（1）、后端（4）、前端（2）、UED（1）、UI（1），共 10 位成员。从项目正式启动，到七月初，第一个被需求方、发起人都认可的 V1.0 版本原型才确定。在这接近四个月的过程中，几乎项目管理的全部坑都踩了个遍，特别是干系人管理、冲突管理以及变更管理与项目管理的基本要求几乎完成全部背离。这个项目为何会走到这个几乎失控的地步呢？
2、原因分析下面全面来进行一下问题的分析，可以从项目筹备阶段开始
1、 项目定位不清晰（干系人管理）
关于这个项目的定位，业务方领导与技术方领导有完全不同的定位，技术领导认为应该要设计管理平台，而业务方领导明确表示我们需要的设计协同平台，双方经过几次交流，但是始终未能够对产品的定位达成一致。产品经理找需求方确认过的需求，技术领导不认可，不仅技术领导不认可，甚至业务领导也不认可。
此处项目经理有较大责任，需求的确认完全交由产品经理处理，但是在项目的进行过程中，明确发现产品经理确认的需求、设计的原型得不到技术领导与业务方的双方的认可，此时应该组织需求讨论会议，让相关的干系人（技术领导、业务领导）需同时参加，明确 alpha 版本的需求。而不是只埋头在进度控制中，需求没有得到核心干系人一致认可的时候，做的越多，偏离越远。
2、 责任权限不清晰
项目中有产品经理、项目经理，在项目启动阶段并没有明确说明产品经理与项目经理的职责与权限。产品经理管理需求，但是未对干系人进行有效管理，项目经理此时要不要去强力干预对干系人进行管理 ？
项目经理是作为整个项目的负责人，但是常常被定义在技术负责人的位置，管理技术选型，开发进度控制，没有对整体项目的成败负责，常常对着两位老总不同的产品定位叹气，但是没有采取有效的措施来解决这种问题。
3、迭代内容周期控制（项目进度计划管理）
项目节点是在 6.30 号发布第一版，实际开发时间有两个月，产品一边出原型，开发同时同步进行开发。按照约定的第一个原型版本，是有足够的时间进行开发的。这时对接的业务方要求增加四个审批流程，并且这四个流程可以循环往复交替进行。当时接到产品经理的这个需求时，我第一反应是拒绝的。这个地方描述增加一下产品经理背景描述，产品经理有深厚的行业背景，产品开发经验稍有不足。 我跟产品进行沟通，询问是否可以放到下个迭代，得到的回复是可以，但是没有这个流程，用户是无法使用这个产品的。我考虑到有当时还有较为充沛的'时间，同时这个需求设计到核心的功能，决定在这个开发周期内将这个新增的流程功能开发完成。最终完成了任务流程功能的开发，但是由于业务逻辑较为复杂，一方面产品并未完全梳理清晰全部业务逻辑，另一方面，此功能为经过充分测试，在一次产品演示的时候，技术领导表示该流程交互太复杂，业务领导表示这这个任务流程完全不是他想要的。
这里的问题是在需求原型确定的情况下，项目经理应该缩短每个迭代的任务周期，最多不超过三周。一个迭代版本的时间近两个月的时间，最后核心干系人告诉你这不是他想要的。应该在每完成一次迭代的时候，举行迭代回顾会议，演示产品，让核心干系人对阶段成果进行演示。必须完成第一个迭代的验收，才能进行下一个阶段的开发工作。 如若不然，还不学学新技术实在。
4、变更控制严重缺乏（变更管理）
由于文件版本管理做为其他应用获取模型信息的一个统一入口，技术领导对项目比较关心，时常要求产品演示，同时针对产品提出许多改进意见，态度较为强势，产品经理与我扛不住压力，频繁变更。由于这个变更，业务方是不知情的，所以变更后的产品同时又得不到业务方的认可，这样最后就导致了一个干系人不认可、目标用户不接受的产品的产生。
项目经理在这件事情上负有主要责任，作为一个项目经理，一定需要严格的管控变更。如果要进行变更，必须核心干系人同意，技术领导的优化意见必须要业务领导认可，才能执行变更。并且变更是不在当前迭代周期内进行的，把变更作为需求记录起来，在下个迭代内进行讨论开发。
3、解决方案这种情况在 PMO 的强力介入后，得到了极大的改善，推了一个核心干系人都满意的 v1.0 版本原型，那么是怎么做到的呢 ？
1、强力的干系人管理。 每次进行需求确认时，确保全部干系人认可。具体流程是先与业务对接人进行需求讨论，然后与需求领导进行需求原型评审确认（需求确认时最好技术领导在场），最后与技术领导进行原型评审确认。若有异议，组织与业务领导的讨论，直到双方都同意该原型为止，最终确定原型为 1.0 版本。不管领导多么强势，一定要坚持自己的立场，守住自己的原则，不跟着领导天马行空，只做跟需求方确认过的需求，其他一切需求都要经过讨论后再进行设计开发。
2、严格的范围控制。确定一个最小 mvp 进行迭代，迭代周期改为 2~3 周，这两到三周内任何变更都不做，只记录变更点，在下一个迭代启动时，再进行变更的讨论。
3、强力推动项目。对于设计管理与设计协同的争议，先不去管他。将争议搁置，先看需求方当前最需要什么东西，我们先在最小范围内，用最简单的方式满足其需求。搁置争议，推动项目。
4、总结这个项目遇到的问题都是项目管理中较为常见的问题。 PMO 介入后，用这一套组合拳，虽然非常简单，甚至是许多方法有点老生常谈，但是很有效。项目的新原型，业务方与技术方领导都较为满意。其实许多项目的点，我们开始也有做，但是没有强有力的去执行，遇到强势的领导以及需求方就妥协了。这种妥协的结果只能是一个妥协的产品，在可用性、稳健性上都无法得到保证。
项目经理一定要有对整个项目负责的准备，不要只把自己定义在进度管理的小慈祥的微笑里。此外就是项目经理必须做好干系人管理，同时在遇到外界压力时，必须坚持自己的原则，此时的一分妥协，后期需要十分的加班去填坑。