9月30日
2013年春天，我被要求开始为一家新公司规划IT业务。那时，公司还没有名字。美卓刚刚宣布，它将开始准备分拆为两家独立的上市公司。
在信息技术领域，各种重组和并购项目很常见，但分拆相对少见。当目标是将一个公司划分为两个可行的公司时，没有什么可以只是部分优化——也就是说，没有什么可以以牺牲其他方面为代价来最大化。
日程安排很有挑战性。规划和非常复杂的实施的时间框架大约是8个月。这种情况是独一无二的。这项任务有一个固定的期限，但没有太多其他先决条件。
在实践中，我们必须实现一个重大的变更，并从头开始创建一个新的操作模型，这两者都不会干扰持续的业务操作。每个人都面临着同样的挑战，因为新公司没有现成的东西。当还没有针对业务操作的策略或操作模型时，构建IT策略和操作模型是非常有趣的。
我的结论是，这项工作需要分为三个阶段:1)生存;2)新的能力和推动因素;3)未来的解决方案和需求。
我们的计划期限是5年，但主要重点始终是努力工作和取得成果。从大局来看，活动之间的依赖关系是一个主要的挑战。这些在日程安排和顺序方面起着至关重要的作用。
在过去的五年里，我们对系统、技术、解决方案和合作伙伴进行了改进、停产、更换和外包。现在我们的主要任务是帮助公司发展壮大。我们是如何走到这一步的，可以总结为三条准则:
1.专注于重要的事情。重要的是要确定最重要的方面，并确保按照商定的时间表取得足够的成功。我们不可能完成所有的事情，而且各方认为重要的事情之间也存在差异。
确定优先级需要广泛理解业务需求，以及由此产生的帮助公司实现目标的具体措施。
2.目标，方向，前进都比完美的计划更重要。不可能每件事都提前计划好，尤其是在大型项目中。一旦方向确定了，开始行动是很重要的。如果能够尽快提供小的成功措施的例子，就更容易促进进展和承诺。我们常常过于谦虚。即使是微小的成功也能鼓舞人心。它们绝对应该用于积极反馈和一般交流中。
3.变化出现从合作。在大多数变更中，涉众群体是广泛的，这使得找到一种共同语言变得更加困难。在传统的线性开发模型中，一个人确定需求，另一个人提出解决方案，第三个人负责规格说明，第四个人实现，第五个人测试，第六个人自豪地将最终产品展示给最初确定需求的人——结果发现不再需要产品，或者需求最初就被误解了。幸运的是，这种瀑布式开发模型越来越少见。
瀑布模型对于某些项目是正确的选择，但不是所有项目。在快速变化和发展的环境中，敏捷方法是实现变更的更明智的方法。然而，如果不同的涉众和不同角色的人不能合作并为共同的目标做出贡献，敏捷方法将无法工作。这种操作方法对交互技能及其发展提出了主要要求。无论使用何种方法，最重要的是要时刻牢记目标。
