项目管理者联盟 | 中国工程管理网 | 中国研发管理网   会员中心 资料库 博客 圈子

PMI-ACP®认证

适合敏捷开发项目
敏捷项目管理最佳实践

网络课程

PMI-PBA®认证

重视项目商业分析
商业价值与需求分析能力

网络课程

NPDP®认证

产品管理国际认证
全球产品管理最佳实践

网络课

PMP®认证

单项目管理经典指南
年轻项目经理首选

北京 | 直播 | 录播

PgMP®认证

大型复杂项目全球标准
定位高级项目管理层

网络班

PfMP®认证

链接战略与项目
实现组织资源投资回报

全球直播

软考项目管理

信息系统项目管理师
系统集成项目管理工程师

计划 | 报名 | 经验

论坛
价值源于交流与分享
会员区:
登陆ID 密  码
功能区: 公告建议 | 帖子搜索 | 管理团队 | 荣誉版主 | 帮助手册






 项目型组织  项目管理  工程项目  科技项目  项目化管理  管理软件  资格认证  职业休闲
EPM体系与流程 综合集成管理 总承包管理 IT软件开发 项目型制造 P3E/P6 PMP | PgMP 职业发展探讨
组织与人力资源 进度,范围,成本 国际工程 生物制药 专业服务 微软PROJECT IPMP | PRINCE2 管理学堂
项目管理信息化 团队建设与沟通 房地产 汽车设计开发 生活项目 PowerOn专版 软考项目管理 英语角|读书版
多项目与大项目 质量与风险 监理与咨询 手机数码 文体娱乐 注册建造师 房车吃游
PMO建设与管理 采购与合同 工程设计 项目管理硕士 闲聊版|商务版
俱乐部北京 | 大连 | 福州 | 广州 | 杭州 | 南京 | 山东 | 上海 | 深圳 | 四川 | 天津 | 武汉 | 西安 | 郑州 | 申请成立 TOP榜精华 | 最新 | 最热 | 会员

版面信息

说明:失败的IT项目比比皆是,进度延迟,预算超支,客户需求多变,成员加班抱怨...IT项目(软件开发.,信息系统实施等)寻求新生

本版版主

camer
登录:2013/7/2
次数:867
注册:2003/3/3
发帖:2745
dorothy
登录:2016/12/15
次数:804
注册:2004/9/6
发帖:993
steveli2008
登录:2009/5/26
次数:464
注册:2003/5/12
发帖:1026
zhf_karen
登录:2015/6/2
次数:346
注册:2005/6/13
发帖:469

俱乐部导航

北京大连福州广州杭州
南京山东上海深圳四川
天津武汉西安郑州 

联盟·近期活动

社区热点

华师大CTO学院:科创生态建设与创.
宏发电声江玫瑰谈PgMP:“下好一盘.
PgMP:交付能力与创造未来的项目管.
开放讲座|《项目组合管理与PfMP认证
开放讲座|项目组合管理与PfMP认证
开放讲座|PgMP:项目管理思维与方法
开放讲座|《项目组合管理与PfMP认证
网络讲座|《项目组合管理与个人职业
开放讲座|《项目组合管理与PfMP认证
网络直播|产品经理的四大核心技能提

精彩专题

如何做好项目沟通计划

软件项目质量管理

国际工程索赔与反索赔

更多:

推荐信息

·项目经理沙龙俱乐部
·推荐项目管理公开课程
·联盟VIP会员服务
·联盟99元大课堂
·建造师课程辅导免费试听

社区圈子

集团企业生态体.
圈主:ETPPM
行业:综合应用

HG信用盘0出租
圈主:de123
行业:综合应用

生态系统体系下.
圈主:ETPPM
行业:综合应用

西安IT项目管理
圈主:muzud
行业:IT软件

房地产项目管理
圈主:13935823
行业:房地产

联系社区管理员

咨询电话 010-82273401/11
斑竹申请 admin@mypm.net


版权所有 © 2003-2004
京ICP证070584号 
BBS业务许可2007第353号 
最佳显示模式:1024*768像素
项目管理与PMP认证
3.6 第五步:形成适合项目管理的企业组织结构——《企业级项目管理体系建设》连载 [发表于 2008/12/30]
状态 开放帖 浏览量 1132   

该帖子同步发自:(qiaodong的博客  访问该博客)

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, 决策型。组织协调能力很强,专业知识也很强。这种角色的项目成员是很难得的,既能从专业角度知道事情应该做成什么样,又能在现实环境中知道事情应该怎样才能做成,能够在理想与现实之间找到一个合理的平衡点。这样的人员一般来说成本都是比较高的,很少直接进入具体的项目。
在一个项目团队中,这四种角色一般都是需要的。但这并不意味着项目组中必须要有这样的四个人。一个人可以同时担当多个角色,一个角色也可以由多个人配合而成。例如在某公司的项目团队中,有协调型的项目经理和专家型的系统分析员,但是没有决策型的成员,项目中的决策是由项目经理与系统分析员进行沟通并达成一致意见后形成的,通过两个人的相互配合,共同组成了决策型的角色,使项目内的角色结构保持完整。
对应前面所述三条管理线的要求,专家型的角色更偏重应对产品管理线的要求,协调型的角色更偏重解决项目管理线的要求,同时要协调企业的资源管理线以获得项目资源。如果项目中分别有系统分析员和项目经理,那么系统分析员重点在专业技术方面,项目经理重点在项目管理、资源协调方面。现在还有许多企业中的项目经理,往往都是由技术骨干担任,也就是用专家型的人同时担任协调型的工作,这时的项目经理就需要同时关注产品管理、项目管理和资源管理三条管理线的要求,管理的复杂度就更大了。
在定义了项目的基本组织结构的基础上,企业可以根据不同类型的项目所对应的任务特点,结合专业技术的要求和企业管理的要求,制定出项目组织的具体要求。例如在软件项目中,除了项目经理,在不同阶段要有相应的系统分析员、高级程序员、程序员、质量保证人员、配置管理人员、测试人员等,各种角色的职责都应根据专业技术标准和企业管理这两方面的需要,设定不同类型的项目的内部组织结构的要求,以指导和规范项目经理组织项目组成员的工作,为项目的人力资源管理提供一个相对较好的起点。
举例一
某企业的IT项目由内部的IT部门负责实施,为了保证项目实施的顺利进行,该企业对大型项目过程中的项目组的组织结构做出了具体的规定。
为保证项目中参与各方的协调、沟通,要组成项目工作小组,指定主要的用户部门负责,各个相关的用户部门、IT的开发和运行部门等,都要制定负责人作为项目工作小组的成员,保持密切的沟通,通过这样一个项目工作组的形式,提供了项目的协调型能力,不仅协调项目组内的工作,而且协调项目组与各个相关部门的工作。在工作组当中,要指定业务专家、技术专家和项目管理专家这三个角色,提供专家型的能力,其中,业务专家对业务需求负责,并负责组织制定配套的业务制度和流程和组织面向用户的推广、培训,技术专家对技术产品负责,包括确定技术方案、组织技术开发和系统的部署,项目管理专家则根据各方面的要求和约束,负责确定项目过程的管理方式。在成立项目工作的同时,还会成立项目领导小组,负责就工作小组内不能达成一致意见,或超出工作小组决策权限的问题,做出最终的决策。领导小组通常由各个主要部门的管理高层和企业决策层人员组成,提供项目中的决策型能力。项目中的操作型能力,则通常由企业内部各方面的具体工作人员、各相关供应商来提供。


举例二
在某知名IT公司中,就对IT服务项目组的结构做出了具体的规定。
任何项目都必须有专职的项目经理,主要任务是各方面的组织协调、项目管理,相当于协调型的角色,在一些客户关系比较复杂的项目中,还可以让销售人员配合项目经理,加强对客户方的协调力度。
项目中还必须有系统分析员,负责对项目技术方案做出最终的决定,相当于专家型的角色。
当项目需要做出决策时,必须由项目经理负责组织,与系统分析员一起,综合考虑技术方案和项目管理的要求,形成统一的决策意见,例如在多个可选的技术方案中要选择出符合项目工期、成本要求的方案。这一要求实际上通过项目经理和系统分析员的配合,形成了决策型的角色。
对于项目组中的操作型角色,则可以有很大的选择余地,可以是公司技术部门中的技术人员,也可以是合作伙伴的技术人员,还可以是临时雇佣的自由职业者,只要能满足项目中专业技术的要求,而且满足项目管理的要求即可。

--------------------------------------------------------------------------------------------------------
Qiao Dong PMP
推荐:《写给管理者的项目管理书--建立高效的企业级项目管理体系》
>>> 由论坛统一发布的广告:
楼主 帅哥约,不在线,有人找我吗?qiaodong


职务 无
军衔 中校
来自 不告诉你 :)
发帖 1363篇
注册 2003/2/18
PM币 4342
经验 2003点

  
!  您尚未登录,不能回复主题。    现在 登录  注册
关于联盟 | VIP会员 | 培训服务 | PMP认证 | PgMP认证 | 刊物出版 | 沙龙会议 | 人才服务 | 广告投放 | 联系我们 | 友情链接
建设运营:共创时网络
版权所有 京ICP证070584号 BBS业务许可2007第353号