The Tech Team Value Prop – services offered

So far in this short series, I have looked at identifying who a modern technology team might be providing services to, the jobs those people might be doing, the gains they can receive if they are successful, and the pains that they might experience if they fail, or that get in the way of them succeeding.

This time around I will look at what a technology, IT or Digital team might be offering to those consumers of services.

When I was first involved in technology management in the 1990s and 2000s, a consensus emerged across IT about how an IT department should be run. The various functions and services could be described to such a repeatable level of consistent detail that a whole world of IT outsourcing sprang up. Many organisations shipped out their entire operations to big players like IBM, Fujitsu and others.

Rarely did these big contracts work. Partly because they were too big. Partly because clients could never really express what they wanted in a way that stood the test of time. But in hindsight often because that happened just at the point at which the role of technology in organisations was shifting from a back office cost to, through the internet, a route to market with customers and a source of revenue. But, it has to be stressed, not for everyone in every industry all at the same time.

For the past decade or so, I’ve been convinced that the hardest part about technology management in today’s organisations is that it is heavily contextual. A law firm has a whole different set of technology needs from a retailer. A small government policy department has a whole different set of needs to a citizen-facing transactional government agency. There is no one model to do it. Yet still, people crave that silver bullet.

As such the things that an internal technology team need to deliver effective and functional technology to their organisation to do isn’t a fixed list applicable to all. It’s a grab-bag assortment that technology leaders need to construct based on the needs of the people within and outside of their businesses (which is why I started with them in the first two articles!).

What might be on offer?

The above diagram is the result of bringing together the ideas from some of my colleagues at Equal Experts, as well as those from some of the listeners to my podcast WB-40. Thanks to everyone who got involved.

The layout tries to show some sort of relationship between the functions, but that might just be my interpretation rather than any sort of reality. There are six key areas:

In pink I have activities related to building and running technology products. These include user-centred design methods, software development, project delivery, testing and Development Operations (DevOps).

In yellow are the activities associated with running services on an ongoing basis, from networks to managing assets, support for users, training and the provision of end-user devices. There was a bit of debate about whether this was “Business as usual” or if such a term is obsolete in the era of continuous change – I sort of sidestepped the debate by calling it Service Delivery.

The green boxes contain the various flavours of technology architecture: Software Solutions architecture, Enterprise architecture, Infrastructure architecture and Data architecture. There are probably many more.

In grey, I have a series of activities that are associated with Governance, from financial management and budgeting, project oversight, contract management, information and cyber security and the regulation of data privacy.

In teal are a group of things that might have a place elsewhere, but feel somehow linked – collaboration platforms, knowledge management and data and insight services. I’ll call that group Information and Data.

And finally, in blue, are a group of activities relating to managing relationships, from the provision of operating performance data about how the function is running to procurement, business relationship, and vendor management.

This is not a target design for a technology team. Nor is it precise or absolute – as I described earlier, a technology team design outside of the context of the organisation in which it is needed is meaningless. However, it will give us a starting point to begin describing value, which will be the subject of the next article.