X
    Categories: Featured

How to develop an IT Strategy

I’d been asked to write an IT strategy for an SME of approx. 30 people. I do strategies quite often but thought I’d walk through my thought process for this one. It’s a 100-day plan, (which I’ve previously  blogged & podcasted about here) but also a years’ worth of transformation & scale up proposed activity.

My background is hands on sleeve up rolling system administration. I got involved in the murky world of IT since a young boy & my stepfather bought me a Commodore 64. I wrote my first piece of software first in BASIC, then in 6502 assembler & from then on, I knew I’d be involved in technology in one form or another.

But I digress…

My job was to demonstrate what the value would be of the company in question tackling its operational scaling issues & growing its IT function to increase internal user satisfaction, improve internal processes, achieve ISO27001 & much more.

I thought I’d talk through my thought process on what I choose to include in a strategy for an SME looking for digital transformation. It maybe helpful if you’re doing something similar. Especially if you’re leading it.

The triangle below shows the hierarchy of the things I consider as I structure both my thoughts & the first draft plan. Always thinking about the business needs, in fact, you’ll notice everything else underpins those including the IT & Technology, something often forgotten about!

Start at the start

With all IT transformations there’s a core of things to think about. Always. If you do any research, look at any of the consulting firms & how they suggest strategies are written, or any advisory firm for example, they will broadly suggest you think about;

  • Networking & infrastructure
  • Security & compliance (inc any regulatory considerations relating to that specific business)
  • Cloud strategy (inc. Adoption, costs)
  • Data, including storage, mission intelligence & analytics
  • Something around Ai (of course!)
  • End user compute (EUC)
  • Devops, inc. a development strategy
  • All the good management consulting stuff you know & love, inc. a SWOT & Pestle analysis of the business in question
  • A vision & mission, you have to know what the IT function is there to do. How it will support the business & what it won’t do
  • Costs & Commercials (which I won’t go into in this post)
  • Support, for users, clients, customers & such like.

There are a few things I like to ensure are added & thought about also;

  • Success metrics including OKRs & KPIs
  • Vendor management considerations & contract management inc SLA analysis etc
  • Your Org chart. Where will IT fit within the business, what type of people will you need & will you need to use 3rd party resource, consultants etc.
  • How any IT strategy will align with the business objectives & its goals.
  • A communication strategy, for training, support, projects, initiative buy-in
  • Measurement of the as-is state, a discovery if you will.

PESTLE/SWOT mappings

So first up would be a SWOT (Strengths, Weaknesses, Opportunities, Threats). Format doesn’t really matter but this is a great as-is measure of any business, its existing set up, problems & immediate issues which may need tackling. I usually couple this with a PESTLE (Political, Economic, Sociological, Technological, Legal & Environment) mapping to understand & get an overall as-is picture of the business, at an operational & goal level. So many IT strategies fail because the focus is on the IT, but you have to think of the broader business too.

I learnt to do rapid discovery phases through my experience working in consultant firms. You’d parachute into a business & have two weeks to be superficially experienced in every facet of it. Over time I’ve streamlined this approach to make it valuable for me & to allow me to extract just the right information at the right time.

Stakeholder interviews

Next up will be talking to as many people in the business as I can. There are a few ways to tackle this & often I allow the culture & attitude of the people drive it. The purpose is to identify cohorts of people. The noisemakers, the champions, the allies, the ones I’ll need to win over. Or bribe. And I do mean bribe.  If there’s a way to really make people support you, it’s to make their lifes easier. I’ve seen too many individuals wield political power even in the smallest business, & absolutely derail the best intended transformation programmes. The interviews consist of a pre-amble survey which depending on how they fill it in, tells me something about them before I’ve even met them. Then I sit with them, to their schedule (never be a drain on peoples time if you can help it) & spend a rapid sixty minutes understanding things like;

  • Their opinion on what needs to be done to help make the business better
  • Their thoughts on IT & technology
  • What really sucks their time or frustrates them when it comes to IT.

If time allows & the culture allows it, I’ll do interactive group sessions, whiteboards, Post-its, make it as fun as possible. This is a great way to study & obtain sentiment, I| usually do a live visual mural as we go, supply snacks & drinks, & the aim here is to get them to help shape the strategy. When it comes to playing back the analysis there is then no argument I haven’t listened. Massively effective, always works.

Vision/Mission

Now it’s time for the vision & mission. This is tricky. I bundle up all the sentiment analysis & SWOT & PESTLE data I’ve collected, along with a visual mural & maybe some Miro boards which chart everything & sit down with the board.

I talk about catch ball in my Lean thinking presentation (here) & that is a process of getting formal consensus between the management & operational layers of the business. A vision/Mission (freely interchangeable in my opinion) is a small piece of well-crafted prose which outlines what the IT & technology function of a business is there to do. The goal is to when delivering any IT strategy, you’ve got broad by in step by step as you go, & thusly ensuring no big reveals (a key part of my Agile approach) You can use the physical ceremony of a physical ball which you throw to people in the room, giving them a chance to express opinion, provide feedback, or take accountability & own something. The symbolic nature of this is far more powerful than you may think. You can read about it a little more here.

Establishing goals, objectives & initiatives

So in order we’ve now got sentiment analysis, SWOT & PESTLE data, we’ve polled the internal org & we have a vision & a mission from the C-level. Now we’re onto building out an IT strategy which enables the business. Another reason IT strategies fail is because they focus ironically too much on the IT, rather than the goals of the business. I create an asset which usually looks like something like the below, where I get to understand & plot business goals, drivers & focus, and then working from right to left, match those with IT goals, enablers, informing measurements & KPIs (super important which we’ll come onto next) & then a list of practical touchable deployable IT projects (or initiatives) which will achieve those outcomes/goals. By doing this approach you can ensure that the work the IT strategy is proposing is of value to the business rather than the value of just the IT. IT & Tech folk can often be lost in the business of IT rather than the business of deploying IT to help the business.

Measurement, KPI’s & OKRs

With all the previous work in flight, the next question you should ask is how you are going to know when you’re a) finished and b) achieved value. Even more importantly is how do you know you’re getting things wrong? So often in IT transformation projects in organisations the business gets lost in doing what ‘its always done’ even if its stupid. Money is haemorrhaged on consultants, programmes of change work, technology platforms, costs spiral, but no one understands why the decision was made in the first place. I was dropped into one organisation who was spending £20,000 a month on a cloud storage product but had no idea that they had nothing in the storage. Another organisation where change had been implemented but many users were hugely unhappy. No one however had dared to ask the users (as they probably knew the answer) how it was going.

So measurement is important.

Across all the initiatives we’ve mentioned above whether technically tangible or more opaque (which IT change can often be) find a way of implementing clear SMART measurements, & associated OKRs across your IT initiatives. Whilst outside the scope of this blog post, broadly you can think about;

  • Customer satisfaction (using NPS scoring or similar)
  • Cost modelling, costs saved, OPEX reduction, CAPEX decrease,
  • Customers achieved,
  • Service desk tickets volume open, closed, time aged
  • DORA metrics for coding & development, successful merges, code completes, Deployment frequency, mean time to restore, change failure rate

I’ve not even scratched the surface, & just plucked the above from a range of business areas, but its important you have suitable measurements for each IT area. When it comes to OKRs, get used to writing good OKRs which mean something, that demonstrate clear improvements & aren’t just numbers. OKRs must mean something to be valuable. For example;

OKR: End user compute satisfaction

Objective: To reduce our repair & replacement costs on end user IT hardware

Key result 1: Achieve an NPS of >70 from our 100 users

Key result 2: Cut end user compute costs on laptops & consumables by 50%

Although a very loose & subjective example, the above means something. Where possible, its backed with measurement too. Think about baking these into your IT strategy at every opportunity.

The technology approach

Despite the speed to with which technology changes & its difficult to keep up with the pace of advancement, there are few rules to follow to ensure your technical decision making is sound. Like an onion I find working at a IT solution proposal in layers helps organise thoughts, recommendations & my mind to be honest.

Build, Lease, Buy

In any order, this is the notion of as a business deciding consistently whether your approach to innovation & solutioning is first attempted internally, do you buy everything in, a combination, lease etc. Its important to define your build buy lease strategy as this can often impact financial decision making & helps negotiate the way you work with vendors & providers.

How do you know what to do first? The initial goal enablement proces

I speak at length on the importance of an IT strategy enabling the business to do it’s business, not the business of IT. IT strategies often fail due to the sexy shiny easier stuff to do is often first & foremost in any plan. Be it an Ai implementation, blockchain,  NFTs, no code automation, chatbots (eeesssh remember those things) but rarely is analysis done to propritise initiatives & therefore IT projects based on business need & value release.

Through both process stream & value stream mapping, filling in a bit of a document like the one exemplified below can be hugely valuable in synthesising & prioritising the things actually worth doing. They may not be the sexiest shiniest things but value release, I mean true value release comes from enabling the business to reach its commercial objectives. Not because your Tech department has a fetish for Ai & wants to use the companies R&D dime to play with it like a unilateral wet dream.

Vendor Management A.K.A VMO

Just like having a PMO (Project Management Office) a VMO approach helps to navigate the tricky & often murky world of vendor outsourcing. Technology products & platforms are hugely complicated with their own change roadmaps often impacting organisations IT strategies. I remember one organisation where they used Microsoft Dynamics, & an update delivered from Microsoft broke the whole organisation. The org was at the mercy of Microsoft & this was mission critical. More recently I’m involved in several Atlassian Jira on-prem server to Jira Cloud migrations as Atlassian will kill support (at the time of writing this post) within the year.

So you must think about not only the technology you recommend but the suppliers who will supply, install & support your products. An effective IT strategy never relies on one or two single vendor partnerships (even though by contrast that’s what vendors often strive for) & your infrastructure & environments should support zero reliance on one product or vendor. Vendors work in the other direction, getting you hooked on their platforms, services & solutions which only they can help with. And good Vendor management is key here.

So define what you need, using data to make decisions & get good at the process of RFPs, going out to market to find solutions right for your business. Learn how to set up good proof of concept testing, & being able to do it quickly & effectively will really help ensure you can ingest new technology, test it & deploy it at will for the benefit of your business, not the vendor.

One more thing on vendors though, it is a slice of the IT Strategy puzzle which emphasises the importance of relationship building. My points above come from the experience of as soon it looks like on Linkedin for example, you’re responsible for IT purchasing, you get hit up by every organisation wanting to sell you their solution. However, I’ve also over the years built up solid relationships with a number of vendors whom the relationship is entirely reciprocal. I go out of my way to give them business because not only are they good, honest & ethical, with my success at the top of their agenda, but they’ve also helped me out in a pinch when a platform failed at 3am on a Friday, or I’ve underestimated a sprint plan & need that specialist Dynamics developer for one more fortnight. So relationship is key in this particular element of the strategy.

Communication strategy

The wrong IT strategy answers to the C level suite, and the C level suite only. The correct IT strategy answers to the business, its users, it’s staff, & the businesses commercial objectives. Communication is key. It starts with that vision & mission strategy I mentioned earlier, but it also involves a series of experiential onboarding & alignment sessions ensure everyone in the org understands who IT are, what they do, & how they do it. Even more important is to communicate the reasons for particular strategies around security, development, ways of working. Keep people involved, help them co-author the thing that work (but avoiding design-by-committee) & ensure both bottom up & top down communications happen regularly. I do this by regular town halls, encouraging the C-level suite to get out onto the shop floor & speak with the users. I also get my Scrum teams & departments talking to one another, whether that’s effective Show & Tells, Lunch & Learns, or similar.  The communication strategy & its execution should also be visible. So ensure there’s clear documentation on the broad vision & mission but also the more nuanced elements of any strategy which impacts the business or it’s users.

Ways of Working & Process

Now I’ve built a career out of this one so I’ll not meander down the Agile road for too long, literally every other post on my blog talks about Agile & of course you can get drip fed by visiting the delivery manager daily on Spotify. (or wherever you get your podcasts from) but it’s important to go through a methodical assessment of what the business & its processes do now, understand value stream mapping, where efficiencies can be made & what you absolutely shouldn’t touch.

Often each team or department needs (& likes) working in a different way. Tread carefully when trying to ‘harmonise’ or ‘align’ across the business. This is rarely needed or worth the effort. An effective operating model should be robust enough to allow for different processes & ways of working to be effective. However, in an effort to be practical here are my go to WoWs which seem to work time & time again;

  • Scrum for Engineering teams
  • Kanban for Project Management & inter-team collaboration & communication
  • Nexus (Scaled Scrum) for engineering teams spanning a) multiple products b) more than nine teams
  • ITILv3 for any service desk environment

Often the above (or any other process or framework or solutions) are blended to match the needs of the business. An effective IT strategy & its practitioners within are fluent enough with the framework(s) to know how to pick from them (like a buffet) with only the things which work. Trying to shoehorn SAFe or TOGAF into a 30 seat SME scale up is not the one!

There are also a few rules I like to embed with not only the strategy or approach, but to ways of working & how I conduct myself also. A bit like a personal manifesto. You should think about this as if you’re responsible for heading up & leading your own strategy, how you work is important too.

  • No surprises, there should never be anything which occurs that wasn’t foreseen, discussed or planned for
  • Do the difficult things first, never pro-crastinate on fancy looking reports or burn down charts which give directors the false sense of progress. Find the hairy dragons & slay them. The number of times I’ve seen programmes of work derailed because something complex known about from the start, on a plan, in a few months’ time was ignored until the time. In fact, I was in this position with a vendor, we all saw the hairy dragon on the Gannt chart.  The vendor had phased the work in an order which supported their resourcing plan & not the needs of the client or the project. The project overran massively & this is something a good IT strategy & leader/Delivery Manager will spot & hold people accountable for.
  • Put your mortgage on the line, contentious this one but as I’ve been brave (or stupid) enough to do this pretty much on each & every occasion I rightly or wrongly dictate those around me (especially in leadership positions) do the same. In short, do the right thing because it’s the right thing to do. Even if its at your own expense. Whether that’s supporting the project, the users, the clients or the business itself. Too many projects & IT strategies self-serve to keep people in post, chiefdoms & knowledge towers are built often strangling an organisation’s ability to scale or innovate. Projects are often funded with the wrong motivations & the wrong incentives drive the wrong behaviour. As a leader, it starts with you. Put your mortgage on the line to do the right thing.

Cloud adoption

Your IT strategy in 2024 is no doubt going to use Cloud. Many orgs over the last decade have either completed digital transformations, moved to cloud or stuck with some hybrid nearly-done solution that was never quite right. Teams of management consultants have been wheeled in to do these digital transformations with some successful, some not so. Trends like big data & associated machine learning from that data to deliver actionable insights, artificial intelligence, time-based workloads, digital sustainability, are all things at the top of an IT leaders mind.

I personally think your cloud adoption strategy should be one which allows for safe secure scale, & where you’re in the business of developing digital product of some sort, that your platforms are easy to use, accessible & available.

Your organisation should have a data strategy & have guard rails on how data is used, created, safe guarded & interrogated. A data approach should form part of any good IT strategy. A dedicated data strategy should be created to support the overall technological needs of the business.

Cloud cost

One of the issues of cloud is cost complexity.  It’s difficult to plan quarterly or annual spend on cloud platforms as theirs a dichotomy of only being billed for what you use, but you may not know what you will use or what you will need. This can drive the bean counters in finance mad. I don’t blame them. Cloud vendors are often guilty of mind cripplingly complex cost models, & traps such as free plans to injest an infinite amount of data to their platform, but then charge per gigabyte to egress out. How many times have you signed up for a too good to be true cloud platform trial, only to find once you’ve span up some services, onboarded some data, then trying to move off platform or cancel your account is nigh impossible.

So in comes the notion of observability. Not only for platform health but for financial monitoring too. Having an ability to monitor, alert & configure thresholds on cloud compute usage, do financial modelling & make the bean counters life easier by giving them access to this data helps the business.

Your practical move to cloud & identifying cloud candidates & all that kind of thing is outside the scope of this post, but I’d definitely recommend your IT strategy includes some thoughts on Cloud cost management at-least.

Ai & ethics

I have to talk about this one, although I hate talking about it. I hate talking about Ai is I don’t want to be lumbered with everyone else who talks about Ai & frankly is either jumping on the bandwagon for clicks, or just fundamentally doesn’t understand what Ai is.

Ai is on a massive hype cycle at the minute, & if you’re not careful it’ll be forefront to any strategy just because you think it needs to be there.  At this relatively immature stage of Ai, your IT strategy should include space to obtain expertise & then define how your organisation will tackle some of the known problems with which Ai brings. You don’t have to figure it all out, & an IT strategy should not talk about Ai as if it’s a done thing. The conversation of Ai in the workplace needs time to breath & space to grow & your strategy should support that. I do recommend you think about these two;

  • Ai driven code gen tooling such as Code Whisperer, Google Duet & Copilot. How that will drive quality of your digital product. How you protect yourself against regulatory compliancy, safety & security & mal-practice.
  • LLMs (Large Language Models) being trained on internal company data & collateral. Whilst it may sound like a great ideal to train a third party LLM on your organisation’s secrets, you may want to think about those hard coded API strings & passkey secrets you have in your code first.

People, process & Technology

As a management consultant you become used to looking at transformation through a 3-part lense. Is this a process thing, a technology thing or a people thing. And it’s always a people thing! From people getting in the way of change & being resistant, using negativity to derail initiatives, the political chiefdoms we discussed earlier. A clear vision & mission can help get people on board our out the door, but a good IT strategy discussed how to hire, maintain & develop talent. Although I’m often looked at quizzically by members of my fellow executives, I try & do myself out of a job. You should to.

If the strategy creates the supportive scaffolding for IT transformation & the technology delivers it, the people enable it & are transformed by it. Although lofty, your IT strategy should consider the notion of people not only to hire, but also how the strategy & direction could impact people the other way. Automation & Ai in particular help increase efficiency but also move people from their roles. Ensure your strategy & who delivers it are sensitive & emotionally competent enough to tackle the challenges that come with fleshy human beings.

In Summary

There’s a lot more to strategies than either I know, have yet learnt or will be relevant to your org but these are not only some common things, but the go to things I think about & craft when building out a direction in technology. The biggest thing I’ve learnt which has stayed with me forever is something many pay lip service to but very few execute. Technology is about people, change is about people & teams are often greater than an individual.

If you enjoyed this post, please reach out to me on X & say so & give the deliverymanagerdaily podcast a follow. I’d really appreciate it.

Mario De'Cristofano:
Related Post