Welcome to the 6th ‘IT Strategy Matters’ newsletter. I’m delighted that you are on this journey with me.
I’m conducting some research. If you have not done so already, please help me by sharing your views in the IT Strategy Matters survey at https://forms.office.com/e/MDZam3JjXN
It's anonymous, but if you leave your details, I'll let you know how your answers compare to your peers.
I believe that IT strategy matters! And what matters is how IT leaders and team members develop and deliver valuable strategies, how they work effectively with business leaders and end-users to do so.
So, whether you are an IT leader, IT professional, business leader or a user of IT services your opinion matters!
Thank you for contributing to my research. Your input is valuable and much appreciated.
What’s the most important element of an IT strategy?
That’s not really a fair question. All elements of an IT strategy are important, and the strategy would not be completely successful without any one of its components.
Strategy is fundamentally two things:
-
A future state which is better than it would otherwise be without the impact of this strategy
-
A change plan to achieve this
But once you know this, the question that you are left with is how do you achieve this?
The phases and elements of an IT strategy
I’ve talked previously about the phases of strategy development and delivery:
-
Hypothesise
-
Develop and Plan
-
Deliver
-
Measure, Research and Analyse
In each phase, it’s important to consider the four key elements that make up the strategy and that are all a different component of the ‘how’ of that strategy:
Most strategies focus on the what: what is it that we are changing, what is it that we are doing, what are we doing it with, etc. We probably spend most time defining and implementing the what.
When is important when it comes to planning. A project plan takes the actions of the ‘what’ and applies the dimension of time to create a plan so that we know when each task needs to happen.
The ‘who’ is extremely important and is often overlooked. ‘Who’ is another dimension of the plan because we need to know which resources will deliver each task, but ‘who’ also defines the users, stakeholders, and their needs and requirements. Most technology is created to be used by or to benefit humans. Even modern AI solutions are often rooted in ‘human flourishing’ i.e. the idea that artificial intelligence should be designed and implemented in ways that enhance human well-being and promote the development of virtuous character traits. This approach emphasises the importance of creating AI systems that not only deliver results but also uphold values such as honesty, empathy, and fairness.
But if I were to pick one of these components to be the most important, it would be ‘why’. Why? Because the ‘why’ brings all the other components together, explains the goal of the strategy and most importantly the reason for doing it in the first place. It’s the ‘why’ that gets people to support what you are doing, to invest, to back you and to help you deliver.
The ‘why’ is the business case
And what is the artefact that embodies the ‘why’? It’s the business case.
There are many definitions of what should go into a business case. Sometimes it’s a simple articulation of the value that will be delivered, and sometimes it’s so extensive that it almost articulates the whole strategy.
Jack Welch, the former CEO of General Electric said:
"Without a solid business case, you’re just guessing. A well-crafted business case provides the foundation for making informed decisions and ensures that every investment aligns with strategic goals."
I find too often though that IT professionals struggle to create compelling business cases. It’s not something that we are routinely taught, and by the time that you need one, it’s often too late to learn!
When writing strategies, we focus on cost and effort, often with only a cursory acknowledgement of the benefits that the strategy should deliver. We leave it to the reader to infer the value of the changes that we are proposing, and the business case is therefore down to their subjective interpretation of what this value is.
Too often I hear IT people say: “The Business won’t accept that!”. Most of the time I don’t believe that is true! Most of the time, 'The Business' will say 'YES' to anything that benefits the business i.e. that delivers a good return on investment and there is cashflow to pay for it.
If IT think that something really should be done, but The Business is saying no, it's most likely because:
-
IT have not fully articulated the benefits
-
IT have not correctly calculated the risk
-
IT have not provided The Business with enough explanation
-
IT have not fully considered the impact for people
-
IT have not put the proposed solution in the right context
In short, IT have not fully developed the business case.
If you are an IT professional, it is your responsibility to develop the business case for every change that you want to make, not just to focus on the technology.
The make-up of a business case
So, what should a business case contain? How do you make sure that you have considered everything and created the most compelling business case that you can?
A business case is basically the justification for why something should be done. The focus is that the activity or product will or should deliver positive commercial value. I therefore think that the most important element is to develop a robust cashflow with costs and benefits clearly and thoroughly defined.
In addition, you need to tell a good story: This is the narrative of why the strategy will deliver value and what that value will be. If you don’t explain the numbers in the cashflow, then you might as well have just made them up, because nobody will believe that they are accurate.
There is no prescriptive way to tell this story, and the amount of detail that you go into will vary depending on what the business case is for, who the audience is, and how bin an investment you are making.
As a guide, you might want to consider covering off content in these 10 sections:
-
Executive Summary: A brief overview of the project, including its objectives, benefits, and key points.
-
Problem Statement: Clearly define the business problem or opportunity that the project aims to address.
-
Analysis of the Situation: Provide a detailed analysis of the current situation, including any relevant data or research.
-
Options Considered: Outline the different options or solutions that were considered, including the pros and cons of each.
-
Recommended Solution: Present the preferred solution, explaining why it was chosen over the other options.
-
Implementation Plan: Detail the steps required to implement the solution, including timelines, resources needed, and key milestones.
-
Financial Analysis: Include a financial appraisal, such as cost-benefit analysis, return on investment (ROI), and any other relevant financial metrics.
-
Risk Assessment: Identify potential risks and mitigation strategies to address them.
-
Conclusion: Summarise the key points and reiterate the benefits of the proposed project.
-
Appendices – optional detail that can be read if needed
Types of benefits
To make the story compelling, you’re going to need some strong benefits. It’s important to think thoroughly about the value that will be delivered and to categorise and position those benefits appropriately: Not all benefits are equal!
Some benefits are tangible: they naturally make a material difference to the business. Typically, this is a reduction in cost or an increase in revenue, but it needs to be one which will happen i.e. the new solution costs less per month to operate than the old one did.
If a benefit is not tangible, then it is intangible. Intangible benefits are things like increased employee happiness, or maybe time saved on a manual task. They have a benefit to the business, but this benefit is usually difficult to quantify, can only be quantified with subjective measures, or is not certain to happen.
It is possible to make an intangible benefit tangible but be careful to do this in the most objective way, because if the reader or approver of the business case does not agree with the way in which you have done so, it could discredit your business case.
For example, increased employee happiness is likely to lead to an improved employee retention rate. This in-turn means that less time, effort and money need to be spent on the recruitment and training of replacement staff. These are real costs to a business and can be used to make your intangible benefit of employee happiness tangible. Be careful though to do so through specific measures where you are sure of the correlation between the intangible benefit and the tangible effect.
In my experience, if the tangible benefits are strong enough to repay the investment, then business case approvers are more likely to accept the intangible benefits as well.
Conclusion
Building a business case is not easy. It’s certainly too big a subject for me to go into all the aspects in this newsletter. Hopefully this provides you with food for thought, and some pointers in the right direction.
I’m planning to launch an online course about how to build a compelling business case for an IT investment soon which will go into much more detail. If you are interested in that course, or have any thoughts to share on this subject, do let me know.
Thank you for reading this edition of IT Strategy Matters. I hope you found it useful and informative. Please feel free to share it with your colleagues and friends who might benefit from it.
Until next time, remember: IT strategy matters!
Dan – The IT Strategy Coach
Might I be able to help you?
Click here to express interest in our upcoming online courses and coaching programmes.
Click here to enquire about a bespoke engagement with The IT Strategy Coach.
Responses