Business Transformation Requires Transformational Leaders

In this Advisor, I'll offer a few suggestions to firms contemplating how open inflows and outflows might fit into their own innovation strategies.

Recently, the CIO of a non-IT company approached me to help him transform his organization to agile. "We have this tool that provides a real competitive advantage to our domain experts and our clients, but now success haunts us.

We have covered a lot of material since the first Advisor in this series was published. Now it's time for a review.

It is the norm today for the IT shop to be, or have the potential to be, a boundary-spanning function. Organizational theory has long recognized that within the firm there are areas whose focus is mostly internal (e.g., manufacturing and operations) and others whose role is to connect the organization to its outside environment, exchanging information and resources (e.g., R&D, marketing).

The subtitle of Extreme Programming Explained, Kent Beck's groundbreaking book, is "Embrace Change." The full range of behaviors that this seemingly simple phrase can be affect are in fact very far-reaching.

Alice laughed. 'There's no use trying,' she said. 'One CAN'T believe impossible things.'

'I daresay you haven't had much practice,' said the Queen. 'When I was your age, I always did it for half-an-hour a day. Why, sometimes I've believed as many as six impossible things before breakfast.'

In the current edition of Communications of the Association of Computing Machinery (CACM), there is an extremely important article for everyone involved in mission-critical software. The article is titled "Software Engineering and Formal Methods" and is written by a number of illustrious software scientists.

Compared to home-location development teams that may be colocated with domain experts and business champions, software developers at the (offshore) work location are not likely to be familiar with your business. They are learning the details of the business as they code up the application. Even with well-written requirements documentation, don't assume that the team will understand what should be built. Furthermore, intricate business rules and relationships among data elements can be particularly hard to convey.