There is an old joke about five frogs who are sitting on a log, and four decide to jump off. However, all five frogs remain on the log after making the decision, because deciding to do something is very different from actually doing it. This joke seems a very appropriate analogy for IT organizational transformation.
In my experience, it takes most organizations two business cycles after declaring the jump from the log to realize that they do not know how to change the organization. Part of the delay seems to come from a lack of understanding as to the scope of the changes that are required in making transformation happen. The broad range of decisions required for transformation results in some decisions not being made because the organization does not recognize the need for a decision. I refer to this as the “fish don’t know water” syndrome; many teams of executives simply do not see the organizational issues until they are taken out of the situation, like the fish that don’t experience the water until they are out of it and in the boat.
The other reason for the delay seems to be a result of making decisions in isolation. Many interrelated decisions are required in order to make transformation work. Isolated decision making that comes from siloed thinking can stop transformation dead in its tracks. To improve decision making, an organization must understand and successfully deal with three realities of transformation: core, context, and capability.
This raises the question of why railroad companies failed to evolve into trucking and air freight. Why didn’t the US Post Office evolve into UPS, FedEx, and DHL? Why? One word: inertia. The principle of inertia is that things at rest tend to stay at rest, and things in motion tend to stay in motion. Organizations have inertia. They tend to find a groove and stay in that same groove. To get out of one groove and get into another, an organization must address the three realities of all organizations. First is an organization’s foundation, which I call the organizational core. Second is the organizational building blocks on top of the foundation, which I call the organizational context. Third is the fundamental abilities of the organization, which I call organizational capability.
IT organizations find themselves here, and we talk a lot about this. The problem with IT organizational transformation is that its organizational roots run deep. Infrastructure, processes, and procedures that were developed and constructed around the business have created strong, long-lasting roots of tradition and culture. These roots, which were critical to the success of the overall company in its growth stages, have now become a liability when the company needs to change direction to avoid disruption.
Just as the business organization’s core is composed of its purpose, long-range intention, and identity, so is IT’s. A purpose is a reason why the organization exists, but IT has a fuzzy understanding at times as to its real purpose. Long-range intention is the mission of the larger organization, and this is something that is sorely missing from IT organizations that are mainly focused on the day-to-day operations and “keeping the lights on.” Identity is who the company is, and although I think IT thinks it knows who it is, that seems to be a moving target.
During business organizational transformation, there is often a conflict between what needs to happen for the company to transform, and its perception of its purpose, long-range intention, and identity. Until the organization deals with the necessary changes relative to its core, the transformation will likely suffer false starts and the effects of inertia. IT has a key role to play here, as technology is the lifeblood of business today. It is critical that IT figure itself out and start to think about its obsolete business model; it needs to develop a solid value proposition and put itself on the path of being the enabler of business transformation instead of an obstacle to progress.
There is another way to look at this to paint a clearer picture. There is a tourist attraction called “The Winchester Mystery House.” As it turns out, there is not a lot of mystery, but there is a lot of house. Sarah Winchester, believing herself cursed by Native Americans who had been killed by Winchester firearms, dedicated much of her life and a large amount of money to launching a never-ending stream of building projects for the purposes of staving off the curse and prolonging her life. Whether real or imagined, her core belief that she was cursed drove the project investments she made and the structure she created. The house, with its stairways that lead nowhere and doors that open into thin air, reflects Sarah’s unstable mind, or “core.” Core drives context. Some IT organizations fail in their attempts at transformation because they haven’t considered how their core and context must change for the organization to transform. When core and context are out of alignment, project investments are likely to lack coherence. Sound familiar? It should.
To get a rough idea of how complicated it can be to transform the IT organization’s context, consider that all of the following aspects that create context must be orchestrated in a synchronized fashion to create organizational transformation:
- Goals
- Metrics
- Central strategy
- Culture
- Structure
- Systems
- Markets
- Point of differentiation
After considering all these aspects of organizational context, the IT organization must then examine what its capabilities are today and compare them to the capabilities needed in the future.
Starting from a clean slate is something that most of the people I’ve talked to don’t have the luxury of. With an existing enterprise, the inertia of the past becomes the baggage of the future. An IT organization adopting a transformational strategy faces what I call in-flight kite repair. The business of IT, unlike a kite, cannot be brought down to earth to work on and then be relaunched into flight. Transformation is accomplished on top of full agendas. As such, transformation must be done in-flight. This puts enormous pressure on four aspects of capability that most of IT doesn’t have a solid handle on: portfolio management, program management, project management, and process management.
What I’m suggesting here is that transformation of IT organizations is executed in consideration of the purpose, long-range intention, and identity of the organization. It entails modification to goals, metrics, central strategy, culture, structure, systems, target market, and point of differentiation. It requires the critical capabilities of process management, project management, and program management, all under the comprehensive capability of portfolio management. The reality here is that organizations have a tendency to enter transformation with more enthusiasm than comprehension. As a result, many struggle as they spin their wheels and become frustrated with the lack of progress.
I’m going to close this article with a story. Few things cause an allergic reaction among us quite like someone throwing out the idea of adopting best practices. A best practice is what used to work for some other company in its context and in its time. Bleeding people to cure their illnesses was once a best practice. A six sigma bleeding practice will not negate the fact that the practice is flawed from the point of view of medical treatment efficacy. George Washington learned the hard way. He ultimately went into shock as a result of bleeding, while a leading practice called a “tracheotomy” was available but not attempted, because his doctors refused to abandon best practice.
Innovation in IT does and will not come from the adoption of best practices. It comes from looking upstream from the best practices. Before something was a best practice, it was a leading practice. Before that it was an experiment, and before that it was a theory. Before that it was a thought, and before that it was an observation. What gave rise to the value of the observation was experience or wisdom or intelligence. My final suggestion: let’s take a look at the obsolete IT business model and begin to test our observations and theories. Let’s experiment with the business model canvas, see how we can create the new IT organization, and then work to transform it. In the next article in this series, we will start focusing on the business model canvas and breaking down the sections as they relate to the IT organization.