IBM敏捷转型前所遇到的最大障碍

IBM一旦决定拥抱变化，成就客户，所面临的实际问题很快涌现出来，虽然恰恰是敏捷所能够解决的最核心问题，但仍然在这个问题上需要艰难的抉择；过去的80年代、90年代我们虽然总结出了强大的IPD软件开发过程，甚至迭代式开放方式，但是所有的计划和迭代需求在一开始就已经确立，团队会参考长期和短期计划完成所需任务，每个人都有非常清晰的明确定位，知道各自的目标和所需完成的工作量；大家形成了一种完全适合传统开发的习惯，那就是设立目标，严格执行之直至完成；项目经理在进度和项目的方向的掌控上有着较大的权力，大家也习惯了服从指挥，做好螺丝钉；当然，与之俱来形成了的规则就是，但凡我要开展工作，我一定要确定“我可以进入”， 每每完成一项工作，大家也非常喜欢以“退出标准”作为尺度标定工作的完满结束；传统的工厂式软件开发的流程逐渐变得沉重，项目经理疲于奔命的忙于各项指标的度量，做各种报表以满足各级领导的视觉需求；而各级团队不得不在各种指标和进度的选择下，为了使得流程得以顺利进行，都极可能的去维系自己的“角色职责”，概要计划、详细计划方方面面，计划面又包括了“首要优先级、次要工作”， 并明确排除了职责可能涉及的“但没有足够掌控能力、或者被可能影响严重"的工作.  因此，延迟和工作流程的臃肿，不同团队之间的壁垒加深，保护意识过强。因此，软件部的智囊团终于发现了IPD，这个本来就基于瀑布式模式所研究出来的开发方法，需要重新调整；

IBM 2009年的软件部规模看来， 全球有26065人广泛分布在各大洲地区， 超过500个来自各个时期的收购，非常独立的产品线；独立而大量的工具和开发平台在公司内被采用；从明眼人眼里看来，IBM分明就是成千上万个小公司组成的；正因为“每家”都有自己的小九九，都充分相信了自身的成功法则；虽不是每个项目组风格各异，但是从IBM的5大品牌来看，行事作风迥异；势必没有一种技术、一种工具、一种流程、一种组织结构能够一统天下；