IT Strategy that Speaks to non-IT Stakeholders: How to Deliver Instant Results with Few Resources?

Problem Statement:
Have you ever read an IT Strategy or IT Strategy map that is excruciatingly detailed with techno jargon, yet conveys nothing about how these technologies will help the mission of the organization? Such documents contain no consensus among affected stakeholder on who is going to be held responsible not only for the implementation but also for the definition and exploitation.

The purpose of this blog is to share our experience from number of recent engagements on how we approached this topic, what lessons were learnt and what the client did with the completed artifacts and deliverables.

Engagement:
Specifically, last week we had the opportunity to work with a non-profit organization with a noble cause. Their board of directors had a very clearly defined mission of the organization, we call this the Strategic Intent in our Capability Based value delivery model [1]. The IT Organization had a good understanding of their current IT capabilities, what new capabilities are required by each Line of Business to ensure all resources are optimally employed. They also had a fairly good understanding of available technologies in the market place and their capabilities. After a quick review of major process sites and meeting with several subject matter experts, we realized that the strength of this process-rich organization was its people.
The goal of our engagement was to:

• Ensure the client architects had considered all needs and essential capabilities, aligned them to the Strategic Intent from the top-down (i.e. the instinctive architecture) and bottom-up (i.e. contextual architecture). The capabilities needed to be sufficiently detailed to understand the business value of migrating each capability to their target state without excessive risk or residual impact on the people of the organization.
• Ensure a pragmatic methodology had been adopted to not only to identify the right capabilities but define, build and exploit them correctly.
• Validate that the resulting IT strategy map, transition plan and value map spoke to the board and line of business (LOB) heads.
• Demonstrate that due diligence instilled confidence in the board and that the team had done the work correctly and they had a structured methodology to transition defined capabilities to the end state.

The QRS Approach:

• Step 1: We visited several production sites (locations where value is generated) and met the workers who actually did the work. This was immensely valuable to get first hand understanding of the core business of the organization and to understand its culture.
• Step 2: Understand from the client their strategic intent, capabilities of each LOB, including IT and target technologies.
• Step 3: Educate the client’s architects on [1] the QRS Capability Based Value Delivery process and Strategy Mapping Techniques [2]. Step 2 and Step 3 allowed us to develop the common vocabulary.
• Step 4: From the top-down (via the instinctual architecture), define the Strategy Themes and Required Capabilities. The strategy themes and required capabilities will be modified in step 5.
• Step 5: Based on the Value Chain Map of each LOB, summarize the capabilities required by each LOB and extract the information capabilities from them. This results in a new LOB, IT (CTO’s Organization) and IT (CIO’s Organization) capabilities map. Reverse updated the strategic map. For each capability, define their attributes as they were revealed. [3]
• Step 6: Adapt the QRS Capability Based Value Delivery process to fit into the organization’s culture.

These 6 steps and the communication package were completed in days; not weeks or months.

QRS Deliverables:

• A Strategy Map, Value Map and Transition Plan
• An Adapted methodology to identify the right capabilities to define, build and exploit
• A Strategy package that is ready to be socialized with the LOB heads and the Board

Lessons Learnt:

• Sanity Check – Once you map all capabilities and define the transition map, consider how much of your effort is going into capabilities that create (Valuable Final Product) revenue, manage costs or provide support. A minimum of 50% of total effort – if not more – should go into Production Capabilities.
• Culture Matters – Take the time to understand the culture of the organization, without understanding the organization’s strength first hand, an effective architecture could not be defined.
• Debate the Right Things – When capability maps describe Business Value that can be realized by transitioning them from current to target, the technology debate disappears. This also results in establishing clear goals for solution architects and project managers.
• System Thinking – Instinctively and contextually architect the entire scope, conceptually, logically and physically architect each capability.

Questions for Further Discussion:
If you ever undertook similar work, what challenges did you encounter? What resolutions did you propose and what results did you achieve? Perhaps your experience can help others.