In the early days when I was a developer learning my trade, the word strategy did not really matter as you just get told what to do by your manager. You form a strategy to complete your work but you don’t really need to understand the bigger picture of why you are doing what you are doing. It may be a flawed judgement but I can guarantee that 95% of developers don’t know which business goal they are contributing to. Not every technologist has the curiosity to want to understand the business goals and drivers that effectively determine why they do their jobs but someone up the ladder needs to and must understand why!
In my opinion the technology strategy of an organisation should be viewed as a subset of the business strategy. Although it may be executed separately, it is by no means independent. Together with other areas such as resource strategy, sales strategy, operations strategy etc. they all must come together to achieve the overall goals of the business. Problems will emerge the moment the technology strategy diverges from the business strategy.
Understand & Simplify
It is virtually impossible to come up with a technology strategy if the business itself does not have one or is too complex to understand? This is often the million dollar question but in my years of experience I have always tried to understand that before I implement any technology strategy or solution. As a CTO, a technology manager or a developer, I believe you have the right to know the business strategy. If there is not one available or you cannot understand it, then there are some basic questions you can asks to break it down and help start the alignment.
- What are the business goals?
e.g. Target £200m turnover. Increase sales by 50%. 50% reduction in support cost? New product? Etc.
This phase generally does not talk about budgets or resources, it is blue sky on what the business wants to achieve with no constraints (yet).
- What is feasible, what are the obstacles and what programs of work are required to achieve these goals?
At this point you should have a list of programs that need to be analysed and prioritised. This is the moment you need to go a bit deeper and identify the following.
- Which programs require technology involvement?
- What are the technology projects required for the programs selected?
- How does each project add value to the business (monetary, time saving, efficiencies etc.)
- What is the resource required (people, software and hardware)?
- How long will the project take?
- What is the estimated budget?
As a technologist questions 4, 5 & 6 are the most difficult to answer but you must put a best estimate based on the information you have. It is a somewhat catch 22 scenario as the more time you have to analyse the better the estimate which helps the planning phase.
Once all these questions are answered there should be enough information to prioritise, set budgets, understand resources, predict timeframes and finalise a technology strategy that will be aligned to the business goals.
In many of the financial institutions I have worked, this process has often worked in reverse where there is already a list of technology projects but the prioritisation is flawed and does not align with the business goal. This is often because one individual shouts louder than the next and it does not make business sense. In this scenario it is worth spending the time asking questions of each project and align with the business goal.
Either way the technology strategy will only be as good as the business strategy upon which it is based. This exercise is a not a once a year event so it is wise to periodically review the strategy to make sure that it is aligned with the business goals as often goals and priorities change.
The short video gives an insight to what strategy is and is not. Its always subjective but the bottom line is that it should be simple and understood else any implementation will likely go wrong.