国外CIO的关系经 关系比技术更重要

今年早些时候，管理型医疗保健提供商Centene部署了一套新的财务系统。该公司的CIO DonImholz表示，这个项目在12个月内“非常迅速”地完成了，预算也没有超支。该项目涉及部署仁科公司的多个模块和海波龙公司的财务规划和报表软件。

Imholz认为，这个项目取得成功的因素有很多，其中包括公司实施了成熟可靠的技术，并且请了仁科产品方面经验丰富的系统集成商来帮忙。他表示，该项目能成功，最重要的因素还是“IT部门、财务部门和系统集成人员之间的紧密合作。”

换句话说，项目取得了成功主要还是归结于人际交往能力。

遇到困难时，IT部门与财务部门、特别是Imholz与Centene的CTOWilliamScheffel保持的紧密合作关系最终确保项目处于正常轨道。

比如，项目团队很难构建海波龙模块所需的技术环境，于是，第三方机构准备托管运行该模块。Imholz表示，IT部门遇到的这些困难导致项目裹足不前。

这位CIO说，如果两个部门是紧密合作的，双方会找回丢失的时间、确保部署工作按时进行：“如果关系紧张，我们会指责对方，告诉他们我们爱莫能助。但这么做毫无意义——这只会推迟解决方案的交付。如果IT或财务部门试图自己推进进度，又不会如愿以偿，我们必须共同努力。”

信任是关键

IT主管和项目管理专家们表示，IT与业务人员、项目经理与IT人员以及项目经理与利益相关者之间的良好关系能确保IT项目处于正常轨道，糟糕关系是导致项目失败的罪魁祸首。

地面装饰材料生产商ShawIndustries负责信息系统规划和系统开发的主管GregLivingston说：“见过很多原本有望成功的项目完全因为关系出了问题而失败。”

关系好坏对项目起到的影响显而易见。IT领导力和项目管理咨询公司Ouellette&Associates的高级顾问BillHagerup说：“消极的关系会让人希望避免见到对方，或者不愿与对方合作。”

Imholz表示，另一方面，如果IT项目经理与利益相关者之间有一种相互信任的关系，IT项目经理更愿意讨论那些对项目构成威胁的新问题。如果双方关系交恶，项目经理就可能不太愿意指出这些问题，或者会试图掩盖问题。

Imholz说：“如果看一下失败的项目，参与这些项目的人之前肯定知道情况会变得糟糕起来。如果没有良好的关系，彼此不信任，那些问题就不会暴露出来。而如果CIO没有及时地采取措施，这些问题势必会变得更严重。许多情况下，小问题变成大问题的原因在于，它们没有及时得到解决。坦诚交流的文化氛围对搞好项目来说绝对必不可少。”

ShawIndustries的Livingston表示，当项目的确出现问题时，如果业务人员尊重IT人员，他们不太可能完全怪罪于IT方面。实际上，他们更有可能给IT人员留有宽松的余地。

Livingston说：“项目使用什么技术、技术人员有多能干、业务人员对于改善流程和业务有多了解，这些统统不重要：每个系统部署时都会遇到问题。如果CIO没有良好的关系，到头来只会指责、推诿，而不会老实承认‘是我们搞砸了’或‘我们没有测试该系统’;如果CIO有良好的关系，双方就会坐下来，想办法进行改正。”

要是各方面相处融洽，也有利于项目的决策。Imholz说：“迅速制定合理决策是确保项目处于正常轨道的关键。高层人员没有制定决策，意味着决策会由企业中较低级别的人员来制定。如果CIO的软件开发人员等着业务需求方面的决策出来，那么项目受到不利影响的几率就很大。”

关系不受重视

尽管良好关系会给项目管理带来积极影响，但CIO们在需要改善项目交付时，很大程度上还是依赖软件和方法，而不是建立良好的关系。这是因为建立关系要花很长的时间，而软件似乎可以临时解决问题，这么想也就不足为怪了。而且，IT项目经理们更习惯于使用工具。

Ouellette&Associates的Hagerup说：“作为IT专业人士，我们是吃技术这碗饭的。多年来我们接受的所有培训几乎都只涉及工具和流程。”IT专业人士认为流程和技术才是解决所有问题的方法，包括有效的项目管理。他表示，尽管项目管理框架和工具有用，但项目基本上依赖于人。

不过，现在才开始出现注重项目中“人”这个环节，以及管理关系的培训和认证计划。据Hagerup声称，大多数计划注重的只是任务管理。项目管理培训和认证计划强化了这个概念：项目管理就是地位被抬高的任务管理，这是个错误的概念。

Hagerup估计，CIO通常要把80%的时间用在任务管理上，只有20%的时间用在关系管理上;他们应当把更多的时间用在关系管理上。他说：“项目越重要、预算越大，CIO用于关系管理上所花费的时间就应当更多。”

敏捷开发改善关系

ShawIndustries的Livingston正在使用敏捷软件开发方法Scrum，以改善IT与业务人员之间的关系，确保项目成功。

Livingston表示，有了Scrum，业务人员与IT人员一起参加规划会议，分析积压的所有项目，共同确定哪个项目会给企业带来最大的价值。然后，IT人员把该项目细分成几个部分，每个部分的迭代开发周期为30天。IT人员完成一个迭代开发周期后，业务人员就评估IT人员的进度，并建议任何必要的变更。

Livingston说：“敏捷开发方法在设计上有助于改善关系。Scrum和敏捷方法迫使IT和业务人员经常进行交流。这样一来，IT人员就能逐步向业务人员交付解决方案，而不是像使用传统的瀑布方法那样，业务人员在一年半载后才能看到项目成果。”

Livingston表示，为了让敏捷开发取得良好成效，IT与其他业务职能部门没必要相处得极其融洽。他表示，即便双方最初存在紧张关系，敏捷开发也能改善情况。他说：“我们遇到过这样的情况，团队关系有点僵，最初的会议也未必总是一开始就卓有成效。但至少我们能达成一致：我们会在今后30天重点关注15个关键交付项。30天后，我们会如期交付。”

这种方法迫使IT和业务人员一起确定项目的优先级，并且共同列出IT人员30天后完成的15个交付项。然后，Scrum也会推动IT部门的工作。30天后，IT人员就得拿出工作成果。Scrum确保IT人员对业务人员负责。

业务人员看到IT人员每隔30天就会取得实实在在的进展，IT人员的信心也会随之增长。Livingston说：“如果业务人员比过去更经常地看到成果，关系会变得好起来。敏捷开发逼双方不断进行交流，从而有助于改善关系。”

转载：感谢您对网站平台的认可，以及对我们原创作品以及文章的青睐，非常欢迎各位朋友分享到个人站长或者朋友圈，但转载请说明文章出处。