建立企业级项目管理体系建设3.6

3.6    形成适合项目管理的企业组织结构

3.6.1 选择企业的组织结构

我们在前面曾经提到，项目管理对企业的组织结构一定会产生影响，通常情况下，项目会与企业传统的职能式结构互相影响，形成矩阵式的组织结构，随着企业对传统职能管理和项目管理的偏重不同，形成了弱矩阵、平衡矩阵和强矩阵的不同形式。这些不同的组织方式之间，并不存在孰优孰劣的差别，它们所适应的管理要求是不同的，企业完全没有必要为了追求项目管理而一味的向项目式管理倾斜，不必一定要采用强矩阵或者干脆采用项目式的组织结构。企业需要根据自己的使命和任务，选择适合自身需要的组织形式。

以软件公司为例。对于一个以产品开发为主的产品公司来说，如果它专注于产品的研发，它的销售和实施可能主要依靠合作伙伴来完成，那么职能型的组织结构也许就是合适的。而对于一个纯粹的施工队式的系统集成公司来说，可能强矩阵或项目式的组织结构更为合适。对于既有自己的产品研发，同时又自行承担产品的销售和实施的公司来说，就要根据企业产品所发展的阶段，采用不同的组织方式。例如在产品开发初期，产品与研发项目一一对应，职能部门与项目就可能完全重合，既可以作为职能式结构，也可以作为项目式的结构；当产品研发完成后开始推向市场时，在推向市场的初期，项目中有大量的工作涉及产品的完善，项目中的产品管理的需要更为重要，所以此时弱矩阵的结构更为适合；当产品达到比较成熟时，产品已经基本定型，产品销售后的实施工作基本不会导致产品本身的变化，而更多的是考虑在项目中如何满足客户的特定需求，这时就更适合采用平衡矩阵或强矩阵的组织方式，产品管理的职能部门在其中的影响也变得比较小。

在有些企业中，为了尽量提高资源共享程度，产品研发部门的技术人员同时要参加项目中的系统实施，并在实施过程中，根据客户的新需求改进产品，在完成项目任务满足具体客户需求的同时，对产品进行改进。在这样的项目中，既有项目管理，又有产品管理，要同时满足两方面的要求，这种情况下的管理难度是最大的。因此可以说，平衡矩阵的管理结构，对企业的管理水平的要求是最高的。在本章后续部份中，将会重点说明产品管理与项目管理这两者之间的关系。

不论企业采用何种组织方式来支持项目，当企业中的项目主要是跨部门涉及整个企业范围的，企业都可以设置一个独立的机构，称为项目管理办公室（PMO），企业中的这个机构专门负责企业内项目的组织、管理工作。通常情况下，项目管理办公室会负责制定企业的项目管理制度、流程，负责建立企业的项目管理信息系统，负责对项目经理进行培训和指导，负责协调、管理项目相关的事务。有的企业中，将项目经理作为项目管理办公室的成员，不隶属于任何其他的职能部门，当企业成立项目时，就由项目管理办公室直接任命项目经理，并对项目进行跟踪管理。在不同的企业中，或者是在企业的不同发展时期，项目管理办公室的职能不尽相同，这和企业整体的各部门职责分工和业务特点是密切相关的，不能简单的一概而论。有关项目管理办公室，在以后的章节中还有进一步讨论。

对于企业中传统的职能，则需要根据企业的核心任务、项目路线图的基本内容，按照三条管理线的具体管理需要，将企业所需的各类角色进行组合，结合过程管理的特点，将全部所需的角色组织成若干的职能部门。这种基于角色需求的职能部门设计，使得职能部门的职责也变得非常清晰，他们在整个企业任务过程中的配合关系也非常清楚，这样将非常有利于企业的项目管理，有利于企业的流程化管理。

3.6.2 RAEW矩阵

当企业中大量存在着跨越部门的项目时，对应的企业关键任务也一定是横跨整个企业的，为完成任务而存在的工作流程也必然是跨部门的。在这种情况下，企业内流程的设计是首要的，各个职能部门的定义是基于流程的，这在前面的企业任务部分已经有过讨论。但是在传统的企业管理中，很多企业的职能部门都是相互独立的，工作流程主要是在部门内部的，部门之间的联系并不多，在考虑如何完成企业的任务时，往往表现出来的现象就是首先考虑各个部门的职责分工，而不是首先分析整体流程。这种思路会给需要流程的企业造成很大的困难。流程定义已经有很多工具可以支持，基于前面介绍的项目路线图进一步细化企业的各项关键任务，从而形成企业内部的工作流程，这也是一种很有效的方法。

企业内部流程定义之后，就需要开始考虑各个部门在流程中的职责分工。RAEW矩阵是一个非常有帮助的工具，如下表所示：

 其中，R(Responsibility)表示负有责任，A(Authority)表示有决策权，E(Expertise)表示提供专业知识，W(Work)表示提供劳动力，在一项工作任务中，每个部门都可能承担不同的角色，如果某项工作完全由一个部门承担，那么这个部门就应该同时具有RAEW四项内容，如果是由多个部门承担，那么就可能各个部门分别具有R、A、E、W。这样，通过分析企业的一项任务对各个部门的要求，定义出各个部门在企业不同任务中具体承担的角色，从而可以整理出一个职能部门在企业所有任务中应具有的职责，定义出我们通常所说的部门职责分工。

在该表中，一个方向是企业的各个职能部门，另一个方向是企业的关键任务，在中间的各个单元格中，表示了各个部门在各项任务中担当的角色。

这个工具也可以用于分析现有企业流程的合理性。根据企业各项任务中现有的部门职责分工填写该表，全部填写完成后，可以从企业任务的方向进行检查。有时在一个任务中会没有部门提供A，或者在不止一个部门有A，那么在此任务中将会出现无人决策或多头决策的问题。如果在某个任务中不存在E，那么就有可能反映出企业在完成某项任务中还不具备相应的专业知识，可能需要考虑采购、外包等相应的解决办法。

举例一：

某企业内部的软件研发单位，其RAEW矩阵如下：

 在本例中，软件研发单位要为企业提供软件项目的技术可行性分析，还要承担企业软件开发的具体实施工作。需求管理部负责需求管理，与用户部门澄清需求和控制需求变更，并按规定牵头负责可行性分析的工作。PMO负责研发部门的所有开发项目的综合管理。
在技术可行性分析任务中，CTO对技术的可行性作出最终的决策，所以表示决策权的A在CTO，需求管理部牵头负责组织可行性分析工作，所以表示负责的R在该部门。在分析过程中，CTO、软件部、商务部、PMO都要参与，分别从技术方向、现有架构和运行的系统、项目过程组织、成本等角度提出意见，所以在这些部门都有表示专业知识的E。最终形成可行性分析报告的工作，由需求管理部和软件部具体完成，所以表示工作量的W就在这两个部门。
在软件开发实施过程中，通常都以项目的方式进行管理，PMO对项目的进程具有决定权，管理立项、里程碑评审、计划变更、结项等工作，所以管理工作的A在PMO。需求管理部、软件部、PMO，在开发过程中提供相应的专业知识，包括软件知识和项目管理知识，所以这三个部门都有E。具体项目任务的实施，主要由软件部完成，如果涉及对外采购，商务部也要跟踪付款，所以表示具体纯粹出力的W就在软件部和商务部。

举例二：

本例中是一个集成公司在售前投标和项目实施两项关键任务上，相关部门之间的职责分布。

在售前投标任务中，最终的决策由COO负责，所以表示决策的A在COO，售前任务都是由销售部负责组织，所以表示牵头负责的R在销售部，在售前投标的方案建议书中，既包含专业技术方案方面的内容，也包括项目过程组织的内容，还包括商务方面的内容，所以CTO、商务部、售前支持部和以后将可能承担项目的技术部这四个主要部门，要对投标方案建议书的内容贡献自己的聪明才智，所以这四个部门都有表示专业知识的E，在编写投标方案建议书的过程中，主要的工作量是售前支持部和商务部实际完成，包括方案建议书的编写、制作等，所以表示工作量的W主要由这两个部门。

而在得到项目后的项目实施过程中，该公司规定项目经理和项目组的主要成员，都来自技术部，项目实施的各方面工作主要由技术部牵头负责，所以技术部中就有表示负责项目的R。在项目实施过程中，关于项目进程变化的重大决策，仍然后COO做出最终的决策，所以表示决策的A在COO（该公司的CTO主要负责自有产品的研发）。在项目过程中，项目中的各类具体问题，可以由技术部、售前支持部、CTO和销售部来提供参考意见，项目中的具体工作，主要包括项目范围内的具体工作和商务工作两部分，由于该公司是一家集成公司，所以在项目中经常还包括有分包商和产品供应商，所以商务工作中又包括了从客户收款和向其他供应商付款的工作，这些实际工作量主要由技术部（项目工作）和销售部（收款）、商务部（付款）负责，所以表示工作量的W就表现在这三个部门。同时，公司中所有的商务工作都由商务部负责，所以商务部还有一个针对商务工作的R。

 RAEW矩阵方法，不仅可以用于分析企业关键任务在组织结构中的职责分布，还可以进一步对各项工作职责进行分解、细化。在一些大型项目中，有许多企业参与项目，那么也可以使用这一方法，作为项目中的职责分配矩阵（RAM），来明确项目中各项任务的职责分配。

3.6.3 规定项目的组织结构

由于项目的临时性和动态性的特点，项目组在企业中不是一种常设的、固定的组织，所以企业应该对于企业中常见项目类型的项目组织结构作出通用的规定，以指导项目团队的建立。下图是一种项目团队组织的模型，它从团队能力角度出发，对团队中所需的四种能力作了分析：

 1， 操作型。组织协调能力一般，专业知识能力一般。这种角色的项目成员适合作简单、重复性的工作，例如在软件开发项目中的一些缺乏工作经验的初级程序员，就属于操作型的角色。

2， 专家型。组织协调能力一般，专业能力很强。这种角色的项目成员适合解决复杂的专业技术问题，在几乎所有的项目中，都需要领域中的专家参与，来负责解决项目的关键技术问题，他的关注重点是项目中的工程类要求。例如在软件项目中的系统分析员、首席架构师，工程类项目中的总工程师等。

3， 协调型。组织协调能力很强，专业知识一般。这种角色的项目成员最适合作协调、沟通的工作。最典型的代表就是项目经理，在PMBOK中提出，一个典型的项目经理，应该有75％－90％的时间是用于沟通的。在实践当中，确实对于项目经理的组织协调能力有着很高的要求，在有些企业中的项目经理，就是重点要求项目管理方面的能力，而对于专业知识方面的要求却很一般。

4， 决策型。组织协调能力很强，专业知识也很强。这种角色的项目成员是很难得的，既能从专业角度知道事情应该做成什么样，又能在现实环境中知道事情应该怎样才能做成，能够在理想与现实之间找到一个合理的平衡点。这样的人员一般来说成本都是比较高的，很少直接进入具体的项目。

在一个项目团队中，这四种角色一般都是需要的。但这并不意味着项目组中必须要有这样的四个人。一个人可以同时担当多个角色，一个角色也可以由多个人配合而成。例如在某公司的项目团队中，有协调型的项目经理和专家型的系统分析员，但是没有决策型的成员，项目中的决策是由项目经理与系统分析员进行沟通并达成一致意见后形成的，通过两个人的相互配合，共同组成了决策型的角色，使项目内的角色结构保持完整。

对应前面所述三条管理线的要求，专家型的角色更偏重应对产品管理线的要求，协调型的角色更偏重解决项目管理线的要求，同时要协调企业的资源管理线以获得项目资源。如果项目中分别有系统分析员和项目经理，那么系统分析员重点在专业技术方面，项目经理重点在项目管理、资源协调方面。现在还有许多企业中的项目经理，往往都是由技术骨干担任，也就是用专家型的人同时担任协调型的工作，这时的项目经理就需要同时关注产品管理、项目管理和资源管理三条管理线的要求，管理的复杂度就更大了。

在定义了项目的基本组织结构的基础上，企业可以根据不同类型的项目所对应的任务特点，结合专业技术的要求和企业管理的要求，制定出项目组织的具体要求。例如在软件项目中，除了项目经理，在不同阶段要有相应的系统分析员、高级程序员、程序员、质量保证人员、配置管理人员、测试人员等，各种角色的职责都应根据专业技术标准和企业管理这两方面的需要，设定不同类型的项目的内部组织结构的要求，以指导和规范项目经理组织项目组成员的工作，为项目的人力资源管理提供一个相对较好的起点。
 

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友