I’ve had a few months now out of running an in-house technology team to be able to start to reflect on the experience. One thing that is particularly notable, and this is true of technology teams and many other professions too is the prevalence of the proverb of Physician, heal thyself.
Put simply, too often technology teams don’t employ the same approaches to their own organisation and change as they expect of others, and as a result, they can be found to have processes and approaches that leave gaps that can significantly impact their ability to deliver. Some of the worst software implementations can be found in the software that technology teams use to manage their own work.
Over the past few years, we have seen an increase in user-centred and service design approaches around the implementation of technology. This is by no means universal, but it is increasingly common to find technology projects beginning with the assessment of the needs of the end-users of technology, rather than requirements- (or wants-) based approaches.
The distinction between needs and “wants” is subtle and often misunderstood. There is a quote almost certainly misattributed to Henry Ford that says “If I had asked people what they wanted, they would have said ‘faster horses'”. Ignoring the provenance of the saying, it’s still a useful starting point to understand the distinction (and why user-centred and Service design approaches are different).
If you ask people what they want, they will probably answer within the constraints of their current worldview (faster horses) rather than with a view of broader possibilities that might come from more dramatic change (cars offering to support the need to get somewhere more quickly). The job of user-centred designers is to derive from interviews and observations what are likely to be underlying needs that can then be catered for through new approaches.
These approaches don’t need to be limited to thinking about how one designs technology. They can be super valuable in understanding how one designs a service that includes people, their organisation, the skills, knowledge and experience that they require, the processes they follow, and how that all manifests to the consumers of that service.
I’ve yet to find an IT department, whether currently using these approaches in helping their organisations to make change happen, that has methodically deployed them on their own operations.
Over the course of the next few articles, I’m going to use a tool that I have found to be particularly useful in defining services to think about what an internal technology department might think about to improve its delivery of services to its consumers.
The tool is the Value Proposition Canvas from Strategyzer, and it’s a really simple way to express what it is that a consumer needs, and how a service provider matches its offers to meet those needs.
We’ll explore the canvas more over the course of the articles, but to start we need to understand the different types of customers or consumers that a technology team in-house might be trying to service. Here is a first stab:
Internal end users of technology
The staff who use business systems are probably the people that those working in an IT team would most readily see as their customers or consumers.
The biggest shift in focus in my working life for in-house technology teams is that many are now providing technology services to people who are outside of the traditional employees and particularly to an organisation’s customers.
Whether consumer websites or business-to-business systems and data integrations, managing services to people who sit outside of the hierarchy of management control demand quite different approaches (many of which like user-centred design have in turn filtered back into how we run projects for colleagues).
The managers of the in-house people who are using technology services have a different set of needs to the end users themselves.
Other support functions
Finance, Human Resources and Facilities (and possibly other areas like Legal too) also have a different set of needs from the technology team, whether because of a reliance on specific business systems for them to deliver their services, co-reliance on data between one another (movers, leavers and joiners processes with HR, for example), and also specific regulatory needs too.
People in the organisation who are able to commission new technology or changes from the technology team have yet another set of needs…
…as do the overall leadership of the organisation.
Partner and supplier organisations
Business-to-business relationships with supply-chain and partners (and their management) also require a specific set of needs to be met.
Shareholders will require a set of needs that are primarily associated with good governance and effective operations.
Whilst external regulators from the ICO to industry-specific ones will require another set of governance and potentially reporting to be in place from the technology team.
The list isn’t exhaustive, but it’s a good start to allow us to then think next about how those different service consumers have different sets of needs to be met by an in-house technology team. Which we will do next time when we think about the jobs that those groups have to be done.