企业解决方案项目管理的组织机构及职责.docx

企业解决方案项目管理的组织机构及职责 软件开发的过程包括： 用户需求分析、系统概要设计、系统详细设计、编码、测试等环节。但是对于一个企业解决方案而言在软件开发的每一个过程中由于项目组人员的复杂性可能会存在着较为复杂的情况。 在本文中企业解决方案是指业务部门提出了对系统的需求， 通过招投标选择了一个或多个开发商， 参与项目的人员包括业务部门、企业 IT 部门、开发商和最终用户。此外，在这里也对企业的类型限定为功能型的组织架构， 对于项目型组织架构的企业存在的问题可能相对较少一些。 在第一部分将介绍目前许多软件项目大多使用的组织架构及其职责， 指出其不足之处，然后说明该种组织机构的实质是什么。 第二部分将给出作者认为较好的组织机构，并对其职责进行了较为详细地描述。 在本文中基于如下的企业解决方案为例进行展开： A 企业的采购部门提出了建立 B2B电子商务的需求，经过和 IT 部门合作选择了 B 和 C两家开发商，其中 B 开发商负责 B2B网站的开发， C 开发商负责数据分析和报表的开发。参加需求调研和参与测试的供应商包括 D、 E 和 F。 功能型的组织架构 对于功能型组织架构的企业而言， 对于前言中提出的 B2B项目的组织架构一 般而言。这种组织机构的特点是按照企业的组织架构组成了企业解决方案的组织 架构，其最上层 -- 也就是项目经理的角色 -- 是企业的较高级别的管理人员。 在接 下来的一层分别是业务部门和 IT 部门的管理人员。由于供应商是经常和业务部 门进行沟通的， 因此将供应商的相关人员安排在业务部门负责人的下面，  而一般 开发商和  IT  部门有较多的沟通，因此将开发商放在  IT  负责任的下面。 这种组织机构存在着以下的不足： 1）项目经理应该对整个项目的成功负责，但是考虑到企业的高层管理人员 其他相关工作已经非常满，因此很难有时间来承担起项目经理的角色。 2）由于第一个先天的缺陷，导致了整个项目的决策会较为缓慢。比如当业 务部门和 IT 部门产生矛盾时，由于较高级别管理人员可能没有时间来了解矛盾 细节而导致业务部门和 IT 部门会就某些事情争执不下，很难达成统一的认识， 导致项目的拖延。 比如，就项目范围而言， 可能在需求分析阶段会有不一致的地 方。 3）当开发商和业务部门产生了矛盾的时候 -- 比如对需求的完成程度 -- 解决 这些问题也会较为拖延。由于问题最终需要一层一层地汇总到 IT 部门负责人和 业务部门负责人这里进行解决。 4）开发商 A 和开发商 B 产生矛盾分歧的时候解决问题也存在着困难，因为 A 和 B 都在为自己争取的利益，当产生矛盾时，双方会产生相互推委的现象。 5）由于业务部门负责人和 IT 部门负责人可能也有许多其它工作， 因此实际 上变成了业务部门实施人员和 IT 部门实施人员来推进项目管理。由于其所处于 项目的较低层，因此处理问题的能力有限。 总结为一句话，这种组织机构可能产生的后果就是在项目组织的职责不明确， 决策缓慢，项目拖延等问题。 改善的组织架构 针对于功能组织架构存在的问题点，下面将论述作者认为较好的组织架构。 首先考虑到企业较高管理层人员的时间关系， 因此不适合将他们放在项目经理的位置上，而是将高管人员置于评价者和支持者的位置。 在上一部分谈到了业务部门和 IT 部门可能会存在着争执， 如何解决这个矛盾，结合第一个问题点的解决，就是将业务部门和 IT 部门的相关负责人共同组成双人的项目经理，这里对两个 项目经理的要求是业务负责人要较为精通业务但是也要具有 IT 的相关知识， IT 负责人要熟悉 IT ，了解 IT 项目的特性并且熟悉 IT 项目管理和业务流程，他们 也需要有充足的时间花在项目上， 此外一个较高的要求是他们必须有较强的沟通能力。这样就形成了高管进行评价和支持，业务和 IT 相关负责人来具体管理项目的项目决策、支持和管理层。项目经理主要进行项目的范围管理、时间管理、质量管理和沟通管理。 尤其值得一提的是项目的需求变更必须由项目经理牢牢把 握，因为许多企业项目不能按时、 按质完成的主要原因是需求变更无法有效控制，而设置业务和 IT 人员作为项目经理的设置方式可以有效地避免存在以上的问题。由于项目经理是管理人员，对于业务和 IT 一般而言并不是专家，这时考虑到 IT 项目在需求分析和 IT 架构设计阶段需要专家的支持。因此建议增加业务和 IT 专家对项目经理进行专业级的支持， 这些专家可以来自公司内部， 也可以来自相应的咨询公司或监理公司。业务和 IT 专家的支持可以保障项目能够避免业务上的错误，也可以较宽深的视野来评判 IT 架构。 此外作者推荐较为扁平的组织架构， 除非项目非常庞大。 作者建议每位项目经理直接下属控制在 5 人左右，如果项目