Planning Your IT Transformation Strategy

Organizations allocate considerable budget for planning and implementing their IT strategies every year, and yet it never seems enough—every few years, your IT strategies seem insufficient, underestimated, overly expensive and complex. Demands change, forcing you to reorganize your organization and align with the evolutionary aspects of your maturity, business and industry.

Though such transformation is almost in every case marked with success or conditional success, it seems you somehow end up at that exact same starting point in a few months or years—asking the exact same questions and getting the exact same answers.

There are many possible approaches to identify and mitigate problems, and so many different ways you can plan your current or next strategy. Regardless of what path or corrective measures you take, you need to be prepared, informed and organized with the right data and tools to evolve in your approach.

That’s the exact focus of this article—it does not focus on what solutions, products or services can be used; rather on how to go about planning your strategy and how to prepare, inform and organize yourself—and your organization—before you start your journey into the unknown.

Personally, I believe the best state of balance is where you can achieve maximum output with the minimum possible input on multiple levels of your organization’s needs. For me, IT transformation strategy is “delivering to lean requirements where continuity is maintained through contextual focus and progressive clearance at every stage of execution.”

This series primarily focuses on preparing you to embark on your transformation journey and help you ask the right questions, understand and accept facts, define realistic goals and consider the right parameters in planning such transformations. Most importantly, it helps you establish continuity and sustain such strategies in the long term. Since this is a very big topic, I will attempt to address it in three parts:

●      Part 1: Ask the right questions and accept facts

●      Part 2: Plan and sell your IT transformation strategy

●      Part 3: Establish continuity and sustain progress

Before we start, I think it’s only fair to understand and accept the meaning of a word before you construct a whole world on the mere notion of its existence. In an organizational context, “transformation” is defined by Business Dictionary as “a process of profound and radical change that orients an organization in a new direction and takes it to an entirely different level of effectiveness.” This is a very good definition that without further explanation justifies its high cost and rightful place in organizational strategy.

Part 1: Ask the right questions and accept facts.

Let’s consider the most common scenario: Your organization is at the juncture of re/planning its IT strategy, and you are getting a huge downpour of advice, ideas and opinions from your team, organization and industry in general.

In this phase, it’s critical to assess and align these large and often disconnected pieces of the puzzle to their right context—and use them effectively to plan your IT transformation strategy. While there are many different ways to organize and employ information (and believe me, that’s not the focus of this article), as a minimalist, one good place to start is to understand your own questions, make a comprehensive list and get answers to only those questions (at least to start with).

In the context of planning your IT transformation strategy, the right questions could be (but are not limited to):

Look back (if this is not your first time)

1.    What were the goals of the last transformation?

2.    What goals did we achieve in the last transformation?

3.    What approach did we take to define and implement the last IT strategy?

4.    What were the gaps in this approach? Where did we fail?

5.    What were the problems and opportunities in the last transformation?

6.    What did we learn from the last transformation?

7.    What are the “don’ts” based on our learnings?

Justify

1.    How did we come here?

2.    Why do we need a transformation?

3.    What happens if we do nothing?

Dive in

1.    What’s our vision?

2.    Are the right stakeholders involved?

3.    Do we have consensus on the vision?

4.    What problems and opportunities are we trying to address through transformation?

5.    What are our high-level goals?

6.    Are our goals aligned to our vision?

7.    Do we understand our requirements?

8.    What are our high-level requirements?

9.    Are requirements aligned to our goals?

10.  Do we cover all problems and opportunities through the defined requirements?

11.  What approach do we want to take to plan and execute the strategy?

12.  Why this approach? What alternatives have we considered?

13.  Why is this approach better than the last one?

14.  Does this approach address all gaps and opportunities identified in the last approach and help us achieve all stated goals?

There are many additional and relevant questions you can ask, like:

1.    Do we have the right skills and people to plan such strategy?

2.    How much time do we have?

and the list goes on. But to start with, it’s important to establish a focus. Personally, I think the above questions nudge you in the right direction. Regardless of your ideas on how the end product/solution should look, it’s good to have these questions answered before you proceed to plan your strategy. These questions are intended to establish focus, so it’s very important that the data generated through these questions is kept transparent and highly accessible during and after your strategy planning workshops.

Additionally, the answers to these questions are of no help if the generated data cannot be organized and established into work products that can be used as a tool to support your planning process. The data generated from the above questions can be organized into work products like:

●      The vision statement

●      Problems and opportunities log

●      High-level goals in the form of a backlog

●      High-level requirements in the form of a backlog

●      An approach preferably in the form of a roadmap that can be further used to define the sub-programs and projects in the transformation program

●      A goals-coverage matrix (mapping between high-level requirements and goals)

●      A requirements-coverage matrix (mapping between requirements and problems/opportunities)

Further, the output generated from these questions can be used as input for strategy planning and eventually for program initiation to ensure team effort is focused and guided in the right direction. For example, if high cost is one of the problems with the current strategy, it will be part of the problems and opportunities log, which will in turn be detailed through multiple high-level requirements. Once these work products are established, you will have a very clear, point-based understanding of what you want to achieve and—more importantly—a clear list of “don’ts” to consider in planning your IT strategy.

Now before you start setting your vision and goals, it’s important to stand on solid ground to ensure the investments your organization is willing to make are based on realistic data—and that facts are taken into consideration in planning your IT transformation strategy. False assumptions and out-of-context discussions/arguments can have ongoing negative impacts on your strategy. Here are a few facts I personally feel every organization should accept and reach consensus on before embarking on their transformation journey:

●      Change is eminent. You cannot control its occurrence, but you can influence its effect. Change is coming, whether it’s in your industry, region, business, internationally, politically or in other areas. Change is one thing you can be sure of, and the one thing you can be well prepared for in planning your IT transformation strategy. You have to consider this fact and plan your strategy—and eventually the resulting systems and services to accept change (with minimum possible impact to the ecosystem). For most organizations, a majority of these changes can be foreseen. Even otherwise, with the current possibilities in IT systems architecture, you can still neutralize (or at least minimize) ongoing impact by considering this fact in your architecture planning phase.

●      Change always comes at a cost, but you can decide your budgetNothing comes free; you can choose to pay now or later, and sometimes even decide what you can afford to pay for such change. But eventually it involves costs—especially transformation. Depending on the size and scale of your vision and requirements, the cost is inevitable. The maturity of your IT systems and associated processes to handle change determines your control on incoming costs.

●      Transformation is a journey, not a project—but you can have projects within the transformation program. Many organizations consider IT transformation as a project, thereby setting wrong expectations to start with. It’s like saying we stop evolving after this project, or maybe we will start all over again each time. In fact, it should be the exact opposite: Transformation strategies should prepare you for the future and offer ongoing advantages to evolve with your ecosystem and adapt to change.

●      Evolution is not driven by your needs alone, but you can decide your pace of adoption. Information technology is one of the fastest evolving sectors in today’s world. That means whether you drive it or not, the industry is going to evolve—and your interfaces to the evolution aspects need catching up. If you have the right IT strategy combined with the right IT architecture—and an ongoing, high-level program to monitor and evolve with the developments—you keep such development aspects in control and decide the pace of adaption with minimum impact.

●      Your transformation is limited by your organization’s maturity. That’s the most important fact to consider: You cannot expect to define the right goals, think outside the box, bring the right advantages or even reach consensus without the necessary knowhow and data on the current maturity of processes and functions within your organization. Executing an IT transformation strategy requires communication and collaboration at all levels within the organization, and also demands stakeholder support and acceptance on an ongoing basis. It’s highly recommended to establish a maturity assessment on different aspects of readiness and execution requirements to prepare and train the organization for such long-term strategies.

●      The industry has lot to offer, but your needs are limited. Especially with the current developments and ongoing rapid innovation, the industry has a lot to offer—where every expectation is matched and supplemented with more expectations. That can be good and bad for your strategic initiative. Let’s say you want simple sales automation software; your “simple” is rapidly replaced with “complex” given the overwhelming number of solutions and services in the market, all trying to differentiate on specific ways they can enhance and even expand your perspective. Solution or service evaluation has become a segment in itself, supplemented with cutthroat competition among providers and a hungry market where there are lots of promises with very little effect. It’s important to have options, but only those that relate to your acceptance parameters defined through your requirements. An overblown solution with millions of possibilities would also mean directly or indirectly maintaining 100% of a product with 30% to 50% usage—which is also not bad if you have such information in the assessment phase, where such data can be used to evaluate and rate the available options.

No matter what your approach, you are only as good as the quality of data you collect and the effectiveness with which you can use such data in the process of planning and executing your strategy. So it’s extremely important to not only collect the data, but also organize it into usable and accessible work products throughout your transformation journey.

Additionally, it’s important to have an active and motivated team with differed but collaborative focus to work on such initiatives—possibly a steering committee with a mix of management, executives, architects, program/project managers and end users to ensure that stakeholders from every aspect of your transformation reach logical consensus on an ongoing basis.

The second installment of this series will focus on the “planning and selling your strategy” part, where we discuss the parameters to consider and ways to identify, plan and sell your strategy to stakeholders.

Related Posts

© 2024 Project Management - Theme by WPEnjoy · Powered by WordPress