案例讨论：业务部门与 IT 部门关系影响项目成败

小C量子

别弄斜体字，看起来太不顺眼了

nirvanv

分析很重要

iWalkman

假设这个项目需要实施IT方案来满足业务部门的需求。

假设公司已有项目管理流程。

首先，预算问题。预算在年初来做没有问题，但是制定预算的根据是什么呢？也就是制定预算的基线(base line)是什么？预算制定是在项目的什么阶段呢？预算在什么时候确定为基线的呢？

如果项目在年初就可以被计划，那么项目的目标，范围也应有个大致的情况，就算没有明细的需求。此时应该能够知道这个项目会牵扯到那些部门（stakeholder）,那么相关的预算应该有各个部门来进行指定，最终汇总成为这个项目的预算。但是这个时候的预算一定是一个非常粗犷的预算，因此需要给预算定义出相应的假设前提条件。在这些假设前提条件基础上、范围内预算成立，一旦任何一条假设条件发生变化不再成立，该预算需要重新回顾审核并更新。

其次，文中所说的项目申请书听起来更像是SOW（Project Statement of Work， 那么项目管理团队应该根据这份SOW制定出一份更加详细的项目章程，并制定出项目范围。这个时候可以对预算进行一次回顾，检查先期的假设条件是否发生变化，预算是否需要调整。

再次，以我个人的经验，最贴接事实的预算，应该是在需求确定之后，所以在需求确定之后也应该对预算进行回归，更新，最终确认为基线。

高层领导作为项目发起人没有问题，他们出钱咱们办事儿么。但是作为Sponsor 来说，他们也不需要事无巨细的每天盯着项目的实施，一方面接收定期更新，另一方面项目遇到重大问题时以及需要进行决策时需要他们出面了。（steering committee）

项目经理：看情况，这个公司还没有一个成体系或者没有独立的项目管理部门。项目本身是一个临时性的活动，项目组本身也是一个临时性的组织，关于有业务部门的部长出任项目经理没有什么不妥，但问题就是在其位就要谋其政。作为项目经理也必须履行起项目经理的职责。如果公司没有系统的项目管理流程，作为IT项目负责人来讲就需要更加积极的跟进，主动的和该项目经理进行沟通，让其进行必要的协调，沟通，决策等活动。偶尔是不可以地。

Key user: 首先，一定要清楚的定义各项目成员的角色和责任（Role and Responsibility）以及项目团队的组织架构并获得比准认可。这个应该在项目章程指定的时候就定义出来的。有了清晰的角色分配职责描述，那需要大家各尽其职。关于需求确定，实际情况就是不可能有这样一个人对公司的每个部门的需求都明细，那就必然需要每个部门的专家对需求提供输入。最终所有的需求汇总描述制定出需求文档，提交项目团队进行回顾并确定为需求基线。（凡提出需求的部门，都需要有预先定义好可以负责需求确定的人都需要参与需求文档的回顾和确定，一旦确定就意味着承认）需要注意的是，在需求分析阶段，需要识别那些事项目范围内的需求，那些事项目范围外的需求。

与其说获得需求像是一块块的转头，不如说更像是一幅一幅抽象画。接下来需要对确定了的需求设计、制定解决方案。那这个解决方案实际上就是文中所说的设计图纸。最终解决方案也需要项目团队的回顾和确定。在进行方案制定时候有可能对预算产生影响，这个时候需要回顾预算，如有变化则需要申请变更。

项目联系人： 这就是关于IT团队的资源问题了。从项目管理的角度来讲，一个人不可能也不能同时承担这些角色，否则项目实施的质量无法保证。有些角色必须是独立的，不能重叠。工欲善其事必先利其器，如有此问题可以借助其他资源，费用纳入预算。


这一系列的问题若要一朝解决似乎有些难度，看样子这公司需要转变一下，有业务驱动转向有项目驱动，建立一套符合自身的项目管理体系，自然项目管理的价值就会体现出来。现在的情况就是缺乏项目管理理念的体现。

susan_huangyong

原帖由 iWalkman 于 2009-9-17 14:04 发表
假设这个项目需要实施IT方案来满足业务部门的需求。

假设公司已有项目管理流程。

首先，预算问题。预算在年初来做没有问题，但是制定预算的根据是什么呢？也就是制定预算的基线(base line)是什么？预算制定是在项目的什么阶段呢？预算在什么时候确定为基线的呢？

如果项目在年初就可以被计划，那么项目的目标，范围也应有个大致的情况，就算没有明细的需求。此时应该能够知道这个项目会牵扯到那些部门（stakeholder）,那么相关的预算应该有各个部门来进行指定，最终汇总成为这个项目的预算。但是这个时候的预算一定是一个非常粗犷的预算，因此需要给预算定义出相应的假设前提条件。在这些假设前提条件基础上、范围内预算成立，一旦任何一条假设条件发生变化不再成立，该预算需要重新回顾审核并更新。

其次，文中所说的项目申请书听起来更像是SOW（Project Statement of Work， 那么项目管理团队应该根据这份SOW制定出一份更加详细的项目章程，并制定出项目范围。这个时候可以对预算进行一次回顾，检查先期的假设条件是否发生变化，预算是否需要调整。

再次，以我个人的经验，最贴接事实的预算，应该是在需求确定之后，所以在需求确定之后也应该对预算进行回归，更新，最终确认为基线。

预算的制定由IT部门经理决定，应该算是根据经验来估算吧，业务部门是不会参与估算的。IT提出的预算一般来说规划部门会在此基础上再砍一些，降成本嘛。最后，当项目招标时，规划部门还会参与招标会，并最终再砍下来一些。最后的合同金额就是项目总金额了，属于总价合同，除非有大的变更外是绝不会增加预算。对了，补充一句，招标之前，投标的供应商是花上2、3天来公司进行简单的调研，工作量的估算、成本的估算是相当地不准了，而且为了拿下合同，估计也会不惜代价来缩短工期，也为将来的项目实施带来了隐患。

liuhai

理论上当然可以说得头头是道了，根据我的实际工作经验，这个问题在现实环境中式无解的，顶多能够想办法改善一些，全按理论上的来，估计楼主是没这个资源的了，他要是有办法能获得这些资源，估计也不会只当一个小小的PM了，起码能当上CIO了，现状下，估计只能是楼主另谋高就到一个规范化的地方去或者留本公司，努力成为一个多面手了，事实上我也处于类似的境遇之中。

susan_huangyong

原帖由 iWalkman 于 2009-9-17 14:04 发表
Key user: 首先，一定要清楚的定义各项目成员的角色和责任（Role and Responsibility）以及项目团队的组织架构并获得比准认可。这个应该在项目章程指定的时候就定义出来的。有了清晰的角色分配职责描述，那需要大家各尽其职。关于需求确定，实际情况就是不可能有这样一个人对公司的每个部门的需求都明细，那就必然需要每个部门的专家对需求提供输入。最终所有的需求汇总描述制定出需求文档，提交项目团队进行回顾并确定为需求基线。（凡提出需求的部门，都需要有预先定义好可以负责需求确定的人都需要参与需求文档的回顾和确定，一旦确定就意味着承认）需要注意的是，在需求分析阶段，需要识别那些事项目范围内的需求，那些事项目范围外的需求。

补充一句，我们是有项目管理流程的，流程应该是没什么问题，但执行力是不够的，不知道是不是和组织机构有关。

而且我们在项目团队建立时，是要求业务部门推荐业务专家加入项目组的，而且也定义了角色和职责。不过，专家们基本都身兼数职，难免业务不足。而且，即使对需求文档作了回顾和承认，仍然可能变更，从业务部门部长到专家都认为“业务流程是会变化的，谁说我签了字就不能变更”，这话也没错，但有时真是疲于应付变更而无力关注其它方面。我在想，是不是专家们并没有真正地担负起这个责任，或者没有把项目当作自己的项目，更愿意以一种帮忙的心态来“配合”。

susan_huangyong

原帖由 iWalkman 于 2009-9-17 14:04 发表

这一系列的问题若要一朝解决似乎有些难度，看样子这公司需要转变一下，有业务驱动转向有项目驱动，建立一套符合自身的项目管理体系，自然项目管理的价值就会体现出来。现在的情况就是缺乏项目管理理念的体现。

我不太确定是否理解“项目驱动”，这是否需要是一个项目型组织机构呢？

iWalkman

原帖由 susan_huangyong 于 2009-9-17 16:06 发表


预算的制定由IT部门经理决定，应该算是根据经验来估算吧，业务部门是不会参与估算的。IT提出的预算一般来说规划部门会在此基础上再砍一些，降成本嘛。最后，当项目招标时，规划部门还会参与招标会，并最终再砍下来一些。最后的合同金额就是项目总金额了，属于总价合同，除非有大的变更外是绝不会增加预算。对了，补充一句，招标之前，投标的供应商是花上2、3天来公司进行简单的调研，工作量的估算、成本的估算是相当地不准了，而且为了拿下合同，估计也会不惜代价来缩短工期，也为将来的项目实施带来了隐患。

是否是由IT经理决定取决于你们IT的组织架构以及职责划分。业务部门不直接进行估算但是必须提供需求数据，否则你凭什么估算呢。既然知道他们会砍，那你拿给他们之前先加个10%-20%的空间好了。赔本的买卖没人会做，砍来砍去最终有个底线。
所谓不惜代价缩短工期，这有点不可理解。你的供应商承诺了你的时间表那他就要按照时间表进行实施。这此前需要做风险识别，制定好风险应对措施。不然的话自然会很有隐患。

iWalkman

原帖由 liuhai 于 2009-9-17 16:12 发表
理论上当然可以说得头头是道了，根据我的实际工作经验，这个问题在现实环境中式无解的，顶多能够想办法改善一些，全按理论上的来，估计楼主是没这个资源的了，他要是有办法能获得这些资源，估计也不会只当一个小小的PM了，起码能当上CIO了，现状下，估计只能是楼主另谋高就到一个规范化的地方去或者留本公司，努力成为一个多面手了，事实上我也处于类似的境遇之中。

问题终归有解决的方法，不是从操作层面就是从战略层面。 关键看公司，自己做不做了。

iWalkman

原帖由 susan_huangyong 于 2009-9-17 16:12 发表


补充一句，我们是有项目管理流程的，流程应该是没什么问题，但执行力是不够的，不知道是不是和组织机构有关。

而且我们在项目团队建立时，是要求业务部门推荐业务专家加入项目组的，而且也定义了角色和职责。不过，专家们基本都身兼数职，难免业务不足。而且，即使对需求文档作了回顾和承认，仍然可能变更，从业务部门部长到专家都认为“业务流程是会变化的，谁说我签了字就不能变更”，这话也没错，但有时真是疲于应付变更而无力关注其它方面。我在想，是不是专家们并没有真正地担负起这个责任，或者没有把项目当作自己的项目，更愿意以一种帮忙的心态来“配合”。

有流程很好啊，角色职责定义清楚了也很好啊，不管身兼几值既然分配到了项目团队就因该尽项目团队里的职啊。似乎说起来很简单的样子，其实这就牵扯到了在项目之初在制定项目计划的问题了。项目计划不是你项目经理一个人制定出来的，是需要各个部门分派来的专家共同制作出来的，他们做某项任务需要多少时间，需要什么资源等等，最终这个计划出来需要大家伙坐下来一起看看，你能不能办得到？能办的到，好确认，一旦确认就是为承诺。在实际实施过程中如果遇到你协调无法解决的问题，那么你就需要将问题升级。这似乎是有打小报告之嫌，但是如果你把你的升级流程 Escalation Process一并定在你的项目计划中，丑化说在前面，那到时候咱没办法，咱调不动您咱就不得不按流程办事情了。说白了，用他的老板去调动他，再不行老板的老板。让团队里的知道这是他们的分内之事，真不是帮忙配合。您不是给我干的。