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