案例一
某外资大型汽车零配件公司，以项目形式从事汽车主要零配件的研发和销售业务。公司组建强矩阵型项目部，项目部成员来自各职能部门(如销售部门)，由项目经理对项目的财务指标、进度和质量等负责。在项目执行过程中，来自职能部门的成员(如销售人员)不能按时完成工作。项目经理与职能部门经理(如销售经理)沟通后，仍无法让这些成员按时完成工作。项目经理不得不向总经理报告问题，由总经理直接要求职能经理督促他们按时完成工作。结果又导致职能经理认为项目经理在打小报告，从而又造成了对项目的不利影响。
理论要点：
1. 需要进一步调整组织结构。从表面上看，公司采用了强矩阵，但从项目经理和职能经理的权力分配来看，项目的强矩阵组织结构是很不到位的，例如：项目经理对来自职能部门的员工基本没有指挥、考核和控制的权力;这些员工名义上对项目经理负责，实际上却仍是直接对职能经理负责(因为职能经理负责员工的业绩考核);项目团队所采用的流程都是各职能部门出于各自为政的目的而分别编制的。所以，组织结构需要调整成真正的强矩阵或项目制的组织结构，减弱或消除部门经理对于项目团队成员的管控。部门经理可以以业务专家的方式对团队成员进行支持。既然公司要求项目成败的第一责任人是项目经理，那么就必须让项目经理对项目责、权、利保持一致。
2. 组织文化调整。导致强矩阵式组织流于形式和表面的根本原因，是公司没有建立起跨部门合作的组织文化，而仍然是各职能部门分工负责、各自为政的组织文化。组织结构是明规则，组织文化是潜规则。如果明规则与潜规则相矛盾，那一定是潜规则获胜。如果组织文化支持跨部门合作，那么项目经理与职能经理协商后，通常都能够解决问题，无需再向总经理报告。即便要向总经理报告，职能经理也不会认为项目经理在打小报告。如果有跨部门合作的文化的支持，那么职能部门员工在参与项目工作后，职能经理就会鼓励员工首先注重完成项目任务，而不是首先注重维护本职能部门的利益。
3. 建立定期的跨部门沟通机制。项目经理不能等到有问题了再去找职能经理沟通，而要在出现问题之前就要沟通。特别是在项目计划编制阶段，项目经理必须主要邀请职能经理参与，请他们发表意见。如果职能经理不发表意见，项目经理也要设法请他们发表意见，以便防止“虚假一致性”。在采用各部门的业务流程时，项目经理要注意分析这些流程之间的不一致甚至矛盾，引导职能经理达成协调。
4. 请公司总经理定期召开跨部门项目协调会。这是项目治理层面对项目相关事务的高层级协调。有了这种协调会，不仅可以避免所谓的“打小报告式”，专门向总经理汇报，而且有助于各职能部门在协调会召开之前解决相关问题，以免在协调会上被指名批评。《微权力下的成功项目管控》一书中讲到了一个“星期二奇迹”。公司规定每周二召开项目跨部门协调会。如果某部门的工作没有做到位，就会在会议上被领导批评。在上周四或五看起来还解决无望的问题，到了本周一大多都能得到解决，因为谁都不想被公开批评。
案例二
在目前的一个项目中，我们是乙方，由中方和德(国)方公司组成，中方是主导方。甲方也是由中方和德方公司组成的。在甲方中，中方管理方面强、技术方面弱，德方则管理方面弱、技术方面强。与乙方始终由中方主导不同，在甲方，初期由德方主导，后期由中方主导。项目前期进行很好，但现在乙方的德方经常直接找甲方的德方讨论问题，导致甲方误认为乙方也是由德方主导的，使乙方的中方事实上处于被架空的状态。
理论要点：
1. 联营协议。对于由两家公司联合组成的乙方联营体，这两家公司之间必须签订一份联营协议，其中明确规定哪家公司是主导公司，以及两家公司的权责。这个联营协议应该向甲方公开，甚至应该按照甲方提供的格式来签订。
2. 制定明确可行的沟通计划。在项目中，由于大家都是为了这个项目而第一次合作，相互之间不了解，所以必须认真编制沟通计划。甲乙双方在合同执行开始之前，要坐下来，认真地讨论，制定一份双方都愿意采纳的沟通计划，明确规定针对什么事情，应该由双方的什么人以什么方式来沟通。沟通必须严格按沟通计划中的规定进行。
3. 会议。由于甲乙方之间的大量沟通是通过会议进行的，所以乙方的主导方要尽可能参加这些会议。即便是由两个德方进行的技术讨论会议，乙方的中方也要尽量参加。在这种会议上，可以主要由乙方的德方代表乙方发言，但乙方的中方必须代表乙方发表开场讲话和结束讲话，并注意掌控会议中的关键点。这种对开场、关键点和结束的掌控，就可以体现出中方作为主导方的地位。
4. 要授权，不要分权。必须承认，有些纯技术性的事项，由两个德方直接沟通更有效。对于这些事项，乙方的中方必须事先以书面方式通知甲方。这样一来，乙方的德方直接找甲方的德方沟通，那也是根据中方的授权进行的。注意，不要让乙方的德方“瓜分”了乙方的中方的权力。项目管理强调授权，反对分权。
案例三
手机游戏软件开发项目，需求变化频繁，版本迭代快，团队成员多，如何在传统项目管理和敏捷间寻找平衡?
理论要点：
1. 不能无规则的敏捷。要用敏捷项目管理方法，必须先很好地掌握传统项目管理方法。
2. 收集需求。需要更仔细地收集需求。注意多召开跨部门、跨专业的引导式需求研讨会，注意邀请用户代表参加，注意请综合素质高、预见力强的人来主持需求收集工作。
3. 小规模全功能团队。敏捷项目管理方法要求团队规模小但拥有所需的各工种人员，以便在很短时间内开发出产品原型。这个公司40多人的团队，规模太大，应该按可以并行的产品模块把这个大团队分成一些小团队(如5-7人组成)。这些小团队在产品总体设计框架下分别并行工作并密切沟通，开发出作为组成部分的原型，这些原型可以组装成更大的原型。
4. 迭代期划分。照理，需求在两个迭代期之间必须变化，但在同一个迭代期内不能变化。如果在一个迭代期中会发生需求变化，那就说明迭代期太长了，就需要缩短迭代期。当然，也可能是迭代期开始前的准备工作做得很不到位。在划分迭代期时，要特别注意每个迭代期必须实现的产品功能。产品的全部功能要通过各个迭代期逐渐实现。在敏捷方法中，产品功能通常要串行实现，而为实现某个功能所需开展的工作，通常要并行，以便缩短开发时间。
案例四
我公司作为乙方，用总价合同为某集团公司的某个下属单位开发信息管理系统。项目在实施过程中发生了多次需求失控的情况，都是因为在向有关专家和领导进行阶段汇报时，他们提出了新增需求模块。第一次汇报会，从原来的8个需求模块增加到20个。第二次汇报会，又增加到40个需求模块。作为乙方，我们要协调这十几位专家和领导的意见，实在太困难了。
理论要点：
1. 合同类型。像这种需求很容易变化的项目，本来是不应该签总价合同的。如果不得不签总价合同，最好分阶段签，或在合同中约定什么情况下应该如何调整合同价格。
2. 沟通管理。从情况来看，似乎与这些专家和领导的沟通太晚了，太被动了。建议把阶段末汇报改为阶段开始之前汇报，这样就更主动，而去可以让专家和领导体会到你对他们的充分尊重。阶段前会议旨在明确需求，阶段末会议旨在确认需求的实现情况，而不是提出新的需求。必须通过制定会议议程来限制会议内容，防止会议内容失控。
3. 干系人管理和收集需求。可以看出，乙方的干系人识别工作做得不够到位，没有把这些专家和领导列为重要干系人，并尽早收集他们的需求。在项目管理中，很强调尽早尽可能全面地识别干系人。
4. 风险管理。对于专家和领导提出的需求变更或增加，乙方必须从风险管理的角度来分析可能对项目的影响，并结合自己的风险承受力和风险临界值确定应该采取什么风险应对措施。如果需求变更或新增所导致的风险会超出自己的承受力，就坚决要求甲方办理合同变更手续。如果低于承受力但高于临界值，就可以不办合同变更手续，但乙方自己要采取一定的措施来应对。如果低于临界值，就可以简单接受需求变更或新增。
案例五
为某省交通系统政府机关整合五大业务信息系统，以方便数据录入、审批，以及调阅与查询。总价合同，合同期1年。项目执行过程中发现数据录入者、审批者和调阅者的需求存在严重矛盾，如录入者想要有关领导承担审批的责任，但有关领导却只想调阅，不想做出明确审批。还发现相关法规变化太快，以至于在执行过程中不得不为符合新颁布的法规而进行额外的工作调整，导致工作量大大增加。
理论要点：
1. 收集需求。项目的三级用户之间的需求矛盾，应该是在项目开始之前就能够预见到的。对同一个系统，不同的用户有不同甚至矛盾的需求，是非常正常的。项目经理必须分别了解他们各自的需求，然后分析这些需求之间的一致性和矛盾性。对于矛盾之处，必须召集他们一起讨论、达成协议，也许可以用折中的办法来处理需求矛盾。例如：将需要领导审批或同意的部分，以“No Objection (不反对)”替换，既能满足政府机关对办事流程的需要，又能使责任主体不能推卸责任。
2. 明确项目范围。必须明确项目范围只是把本来用传统的纸笔方式进行的业务流程电子化，而不包括为甲方制定新的业务流程，也不包括修改已有的业务流程。如果要包括后两部分工作，合同就需要签成另外的样子了。
3. 分阶段进行。考虑到法规变化快的风险，就要尽可能缩短工期。如果实在缩短不了工期，就应该设法把整个项目分成多个阶段，并按阶段签署合同。要设法使这种分阶段有利于实现领导关心的利益。例如，可以在第一阶段先搭好系统的总体框架并以适当方式发布，让大家看到项目很快就做出来成果。这样，领导也会觉得很有面子，相关部门和人员也更容易支持项目。