|
 项目管理者联盟
项目管理对企业的组织结构一定会产生影响，通常情况下，项目会与企业传统的职能式结构互相影响，形成矩阵式的组织结构。项目管理者联盟
本文关键字： 项目管理 组织机构service.mypm.net
1.1 形成适合项目管理的企业组织结构项目管理者联盟
1.1.1 选择企业的组织结构项目管理者联盟
我们在前面曾经提到，项目管理对企业的组织结构一定会产生影响，通常情况下，项目会与企业传统的职能式结构互相影响，形成矩阵式的组织结构，随着企业对传统职能管理和项目管理的偏重不同，形成了弱矩阵、平衡矩阵和强矩阵的不同形式。这些不同的组织方式之间，并不存在孰优孰劣的差别，它们所适应的管理要求是不同的，企业完全没有必要为了追求项目管理而一味的向项目式管理倾斜，不必一定要采用强矩阵或者干脆采用项目式的组织结构。企业需要根据自己的使命和任务，选择适合自身需要的组织形式。club.mypm.net
以软件公司为例。对于一个以产品开发为主的产品公司来说，如果它专注于产品的研发，它的销售和实施可能主要依靠合作伙伴来完成，那么职能型的组织结构也许就是合适的。而对于一个纯粹的施工队式的系统集成公司来说，可能强矩阵或项目式的组织结构更为合适。对于既有自己的产品研发，同时又自行承担产品的销售和实施的公司来说，就要根据企业产品所发展的阶段，采用不同的组织方式。例如在产品开发初期，产品与研发项目一一对应，职能部门与项目就可能完全重合，既可以作为职能式结构，也可以作为项目式的结构;当产品研发完成后开始推向市场时，在推向市场的初期，项目中有大量的工作涉及产品的完善，项目中的产品管理的需要更为重要，所以此时弱矩阵的结构更为适合;当产品达到比较成熟时，产品已经基本定型，产品销售后的实施工作基本不会导致产品本身的变化，而更多的是考虑在项目中如何满足客户的特定需求，这时就更适合采用平衡矩阵或强矩阵的组织方式，产品管理的职能部门在其中的影响也变得比较小。项目管理者联盟
在有些企业中，为了尽量提高资源共享程度，产品研发部门的技术人员同时要参加项目中的系统实施，并在实施过程中，根据客户的新需求改进产品，在完成项目任务满足具体客户需求的同时，对产品进行改进。在这样的项目中，既有项目管理，又有产品管理，要同时满足两方面的要求，这种情况下的管理难度是最大的。因此可以说，平衡矩阵的管理结构，对企业的管理水平的要求是最高的。在本章后续部份中，将会重点说明产品管理与项目管理这两者之间的关系。项目管理者联盟
不论企业采用何种组织方式来支持项目，当企业中的项目主要是跨部门涉及整个企业范围的，企业都可以设置一个独立的机构，称为项目管理办公室(PMO)，企业中的这个机构专门负责企业内项目的组织、管理工作。通常情况下，项目管理办公室会负责制定企业的项目管理制度、流程，负责建立企业的项目管理信息系统，负责对项目经理进行培训和指导，负责协调、管理项目相关的事务。有的企业中，将项目经理作为项目管理办公室的成员，不隶属于任何其他的职能部门，当企业成立项目时，就由项目管理办公室直接任命项目经理，并对项目进行跟踪管理。在不同的企业中，或者是在企业的不同发展时期，项目管理办公室的职能不尽相同，这和企业整体的各部门职责分工和业务特点是密切相关的，不能简单的一概而论。有关项目管理办公室，在以后的章节中还有进一步讨论。项目管理者联盟
对于企业中传统的职能，则需要根据企业的核心任务、项目路线图的基本内容，按照三条管理线的具体管理需要，将企业所需的各类角色进行组合，结合过程管理的特点，将全部所需的角色组织成若干的职能部门。这种基于角色需求的职能部门设计，使得职能部门的职责也变得非常清晰，他们在整个企业任务过程中的配合关系也非常清楚，这样将非常有利于企业的项目管理，有利于企业的流程化管理。项目管理者联盟
1.1.2 RAEW矩阵pmp.mypm.net
当企业中大量存在着跨越部门的项目时，对应的企业关键任务也一定是横跨整个企业的，为完成任务而存在的工作流程也必然是跨部门的。在这种情况下，企业内流程的设计是首要的，各个职能部门的定义是基于流程的，这在前面的企业任务部分已经有过讨论。但是在传统的企业管理中，很多企业的职能部门都是相互独立的，工作流程主要是在部门内部的，部门之间的联系并不多，在考虑如何完成企业的任务时，往往表现出来的现象就是首先考虑各个部门的职责分工，而不是首先分析整体流程。这种思路会给需要流程的企业造成很大的困难。流程定义已经有很多工具可以支持，基于前面介绍的项目路线图进一步细化企业的各项关键任务，从而形成企业内部的工作流程，这也是一种很有效的方法。www.mypm.net
企业内部流程定义之后，就需要开始考虑各个部门在流程中的职责分工。RAEW矩阵是一个非常有帮助的工具，如下表所示：项目管理者联盟
其中，R(Responsibility)表示负有责任，A(Authority)表示有决策权，E(Expertise)表示提供专业知识，W(Work)表示提供劳动力，在一项工作任务中，每个部门都可能承担不同的角色，如果某项工作完全由一个部门承担，那么这个部门就应该同时具有RAEW四项内容，如果是由多个部门承担，那么就可能各个部门分别具有R、A、E、W。这样，通过分析企业的一项任务对各个部门的要求，定义出各个部门在企业不同任务中具体承担的角色，从而可以整理出一个职能部门在企业所有任务中应具有的职责，定义出我们通常所说的部门职责分工。
在该表中，一个方向是企业的各个职能部门，另一个方向是企业的关键任务，在中间的各个单元格中，表示了各个部门在各项任务中担当的角色。training.mypm.net
这个工具也可以用于分析现有企业流程的合理性。根据企业各项任务中现有的部门职责分工填写该表，全部填写完成后，可以从企业任务的方向进行检查。有时在一个任务中会没有部门提供A，或者在不止一个部门有A，那么在此任务中将会出现无人决策或多头决策的问题。如果在某个任务中不存在E，那么就有可能反映出企业在完成某项任务中还不具备相应的专业知识，可能需要考虑采购、外包等相应的解决办法。项目管理者联盟
举例一：项目管理论坛
某企业内部的软件研发单位，其RAEW矩阵如下：talent.mypm.net
项目管理培训
在本例中，软件研发单位要为企业提供软件项目的技术可行性分析，还要承担企业软件开发的具体实施工作。需求管理部负责需求管理，与用户部门澄清需求和控制需求变更，并按规定牵头负责可行性分析的工作。PMO负责研发部门的所有开发项目的综合管理。项目管理者联盟文章
在技术可行性分析任务中，CTO对技术的可行性作出最终的决策，所以表示决策权的A在CTO，需求管理部牵头负责组织可行性分析工作，所以表示负责的R在该部门。在分析过程中，CTO、软件部、商务部、PMO都要参与，分别从技术方向、现有架构和运行的系统、项目过程组织、成本等角度提出意见，所以在这些部门都有表示专业知识的E。最终形成可行性分析报告的工作，由需求管理部和软件部具体完成，所以表示工作量的W就在这两个部门。项目管理者联盟
在软件开发实施过程中，通常都以项目的方式进行管理，PMO对项目的进程具有决定权，管理立项、里程碑评审、计划变更、结项等工作，所以管理工作的A在PMO。需求管理部、软件部、PMO，在开发过程中提供相应的专业知识，包括软件知识和项目管理知识，所以这三个部门都有E。具体项目任务的实施，主要由软件部完成，如果涉及对外采购，商务部也要跟踪付款，所以表示具体纯粹出力的W就在软件部和商务部。项目管理者联盟
举例二：项目管理者联盟
本例中是一个集成公司在售前投标和项目实施两项关键任务上，相关部门之间的职责分布。service.mypm.net
在售前投标任务中，最终的决策由COO负责，所以表示决策的A在COO，售前任务都是由销售部负责组织，所以表示牵头负责的R在销售部，在售前投标的方案建议书中，既包含专业技术方案方面的内容，也包括项目过程组织的内容，还包括商务方面的内容，所以CTO、商务部、售前支持部和以后将可能承担项目的技术部这四个主要部门，要对投标方案建议书的内容贡献自己的聪明才智，所以这四个部门都有表示专业知识的E，在编写投标方案建议书的过程中，主要的工作量是售前支持部和商务部实际完成，包括方案建议书的编写、制作等，所以表示工作量的W主要由这两个部门。项目管理者联盟
本文为项目管理者联盟联盟会员原创文章，授权发布，非经同意不得转载！
|
