这一幕很常见：业务主管们觉得，IT人员是帮不擅交际的家伙，一点也不懂业务知识。而IT人员们觉得业务主管对技术一窍不通；要是知道哪个业务主管成功地开启电脑、打开浏览器，就觉得很惊讶。许多项目依赖IT与业务协调一致，可是也有许多项目失败了，原因在于这种协调一致就好比大脚野人——好多人相信大脚野人是存在的，但要在现实中找到一个全凭运气了。

　　我在现实中的所见所闻印证了这一幕。业务主管们发来的电子邮件里面常常充斥着贬损IT人员的这些字眼：什么“计算机迷”、“性格内向的人”和“不善交际的家伙”，等等。

　　另一方面，IT人员也毫不犹豫地指出，典型的业务主管是技术门外汉；说到确保数据安全，他们根本不靠谱；正如有人曾私下对我说：“要是我是黑客，会先找业务主管下手，而不是先找老人下手。因为能从他们身上捞到更多的钱，他们还很容易受骗上当。”

　　正是由于这样的态度，难怪业务部门急于要把IT运营这块外包到印度；也难怪IT人员忙着竭力把技术搞成一门魔法，好让业务主管想方设法对技术避而远之，以免与IT人员谈论技术。

　　好了，诸位看官也看明白了。业务主管和IT人员都不喜欢对方，但是这到底怪谁呢？

　　这不是最令人满意的答案，但你可能猜到这个答案其实蛮有道理，那就是要怪也怪双方。

　　技术咨询公司Pritchard Enterprise Solutions的执行合伙人Larry Pritchard说：“讨论该怪谁只会适得其反，因为这会阻止开会的人无拘无束地给予反馈意见。如果你等着无故挨骂，想让你发表坦诚的反馈意见，确实有些难度。”

　　与此同时，专门指导客户如何提高业务效率的Laura Rose认为，要怪也怪找别人来怪罪的那个人。“相互指责的做法只会破坏融洽的关系。大家不再团结起来工作，群策群力，实现共同的愿景或目标。相互指责实际上清楚地表明哪里出了问题。”

　　所以，关键在于不要再为怪谁而操心了（说说容易做起来难），弄清楚如何停止指责（同样谈何容易），最终学会重新定义业务流程，以便万一技术项目在将来开始出问题时，贵企业知道如何让项目回到正常轨道了（好比矫正牙齿）。

　　知道谁负责什么

　　William Hartman是专门提供“项目赶工”服务的Brand Velocity公司的总经理，据他声称，技术项目的问题几乎从来不是技术方面的问题，而是总是业务方面的问题。Hartman之前在业务和IT部门都干过，担任过可口可乐企业公司的首席信息官和安永会计师事务所负责美洲、欧洲、亚洲和拉丁美洲全球客户咨询业务的首席执行官。

　　Hartman指出，最终要由业务领导人对技术项目承担起责任，而不是仅仅因为不懂技术，就放弃责任。“业务领导人可以下放权力，但绝不应该放弃权力。搞清楚这点区别很重要。”

　　就大多数重要的大项目而言，应该有五个主要的群体为实现一个共同目标而努力：1）管理团队、2）专门的项目团队、3）IT和系统管理员、4）特定的技术团队（通常是企业外部的供应商，如增值经销商或独立软件开发商）；以及5）董事会（针对非常大的项目）。

　　每个群体都要有明确定义的角色；他们要为某些项目目标和衡量标准负起责任，这点很重要。要是有谁的角色不明确，要是没有人为项目没有按时完工或成本超支这些问题负起责任，你最好还是从头搞起。

　　Hartman说：“项目审批上马后被束之高阁是屡见不鲜的现象。业务部门并不负责实现今后的目标，而IT部门并不负责确保新技术得到了实际使用，对公司利润带来直接影响。项目失败也就在所难免了。”

　　八个警告信号

　　不过，明确角色和职责仅仅是个开始。

　　要是团队成员及早知道项目偏离了正常轨道，那么失败的项目取得成功的可能性会更大。由于如今企业文化过于强调成员的“团队精神”，对于持异议者和揭发者又完全显示出一番敌意，于是大家常常犹豫不决，不敢说出自己担心的问题，因为他们害怕被人家以为是反对派。这种明显的消极态度会影响绩效考评、加薪和升职。

　　表明项目出问题的八个警告信号包括：

　　1、加班次数过多，这其实表明项目规划很糟糕。

　　2、业务团队中没有一个人对技术项目“负责”。

　　3、IT团队中没有一个人了解更庞大的业务目标、技术如何实现这些目标。

　　4、项目缺少一名“翻译人员”（通常是既精通技术又熟悉业务的项目经理或业务分析员），他既能把业务语言翻译给IT人员听，又能把技术语言翻译给业务人员听。

　　5、既没有衡量项目开展过程中取得的成果的计划，也没有当情况（内部或外部）出现变化、危及项目成功时可以采取的应急计划。

　　6、IT目标和业务目标从来没有明确写下来、做到相互一致。

　　7、项目团队中没有一个人能明确表述成功的结果对业务和IT部门来说意味着什么。

　　8、变更管理很差劲（或根本就没有）。成功的技术项目本身就会带来变化，可是大多数企业错误地认为，项目实施后的工作会一切照常。

　　另一个观念上的问题是，人们在项目的开始阶段往往很乐观。Asuret这家技术咨询公司的首席执行官Michael Krigsman说：“在项目的开始阶段，大家有一种共同的错觉，没有人愿意认识到项目可能会出岔子。人们在一开始往往很乐观，甚至近乎飘飘然。”

　　他说：“当然，在任何一家比较成功的企业，项目团队中会有头脑比较清醒的专业人士。他们亲身知道，项目有时会误入歧途，而且常误入歧途，但许多人经常忘记这点。”

　　要消除这种错觉异常困难。人们还没有愿意认识到失败是可能出现的一个结果，项目常常就开始出问题了。对于像Krigsman这样的顾问来说，他们明白这个道理：常常需要借助外部人员来评估项目的实际情况。

　　要克服从众心理很棘手，也异常困难。不过，极容易发现表明项目出问题的一些症状。专门提供项目审查和恢复服务的eCameron公司的总裁Todd Williams说：“加班多就是一大症状。客户请我过去后，我做的头一件事常常是取消加班。如果加班在某家公司习以为常，就表明这家公司缺乏良好的规划。”

　　接下来，Williams审查项目，寻找几乎会保证项目失败的一些政策。比如说他接触过这样的公司：公司政策规定：项目人手不足时，公司内部的员工必须顶上，尽管这些员工可能缺少促使项目成功完成的必要技能。

　　Williams说：“你有一个选择。如果你想让公司内部的员工参与项目，最好聘请一些专家，或者专门投入一些必要的时间和资金对员工进行培训，以便他们成为专家。”

　　诸如此类的政策并不是随意制定的。它们常常是在像当前经济衰退这样的低迷时期制定的。它们是削减成本的措施。你没法雇来新员工，无法请来外部合同工，可是你在经济不景气之前准备到位的一批项目仍得完成。迫于实际的经济形势，必须取消一些削减成本的政策，以免到头来它们造成的损失远高于当初要节省的成本。

　　诸如此类的政策几乎可以保证项目会失败，不管你派谁到项目团队中。

　　正如各种分为12个步骤的计划一样，承认自己有问题是关键的头一步。意识到自己有问题很重要，但还不够，更关键的在于之后的实际行动。