Choosing new technology

As part of the 12 months of digital transformation series, we’re kicking off with an activity around how to choose new technology. In this article we’ll cover the following:

• A bit of background to choosing new technology
• Good practice and things to think about
• A process to follow
• Exercise: thinking about your situation

The aim is to leave you with some resources and a process to follow the next time that you’re in a position where you need to make some choices.

Background

As technology itself comes in many forms, so too do situations where people start to think about its selection. You may not have anything in place yet and be in a completely ‘greenfield’ situation. Perhaps you’re replacing something older, because it’s no longer meeting needs; is too expensive; inefficient; unsupported. Or you may be introducing an entirely new element into an existing ecosystem and need everything to play nicely together.

These situations apply to everything from buying a new games console, to choosing a JavaScript framework, a content management system, or purchasing the software to manage a nuclear power reactor. However, depending on which of these you’re window shopping for, you may decide to follow more or less of a formal process.

For starters, let’s think about a kettle. Yours won’t turn on any more, so you’re probably going to run out to a shop, or head to your nearest online kettle stockist. You probably have a rough price range of what you feel is acceptable. Maybe you have some brands that you tend to like. There will be certain kettles that you find more or less visually appealing. And finally, there may be feedback from other people - friends, or online reviewers. Perhaps you’re the sort of person who wants to whip up a spreadsheet to start comparing options, but more likely is that all of these criteria will fly through your mind almost unconsciously in the background once you’re stood in front of the shelves. In a pretty short space of time you’ll probably have picked out your new kettle and be looking forward to your first cup of tea. The most stringent checks that your purchase would need to pass are probably your significant other/housemate/parent rolling their eyes at the cost.

In comparison, let’s jump back to the other side of the scale. Perhaps not software for a nuclear power reactor, but I’ve been involved in the technology selection for enormous companies where governance and compliance are critical. When you’re swapping over all of the software supporting key customer interactions and touchpoints for a company whose revenue is around £30 million a year, you don’t want to get that wrong. These kind of decisions take a long time to make, and a long time to roll out. There’s usually a lot of research, a lot of formal documentation, a lot of time in meeting rooms, and sometimes a lot of fear.

Most of my digital transformation work includes some element of technology selection that sits somewhere in the middle of these two extremes. Very often there are older systems or processes that could be doing more, or areas where we can use the power of the web or digital technology to fill in gaps in needs. Choices usually can’t be based solely on personal preference and quick decisions, and need some kind of rationale. This is the sort of area that we’ll be focusing on for the rest of this post, and which the activities will focus on: there’s enough there to get you thinking, but it’s not intended to be the most robust and exhaustive process ever.

Good practice and areas to think about

Before we jump into the process, let’s set out some important themes to keep in mind as we go along.

First, and most important: very often there is no single right answer, just different approaches. If there seems to be more than one way forward they’re probably both right in their own ways.

Decouple dependencies. How easy is this to change in the future? Your expectations around how soon change is ok will depend on the type of tech itself, and your strategy, but generally removing dependencies on other areas as much as possible will make change easier.

Don’t just think about now - how will users and their needs change in the future? Will your decision change once emerging technologies mature? How easy is it to change direction in the future? Be aware that your situation now willchange, and that’s ok. It doesn’t mean your choices now are invalid or failed.

Don’t just do something because others have and expect it to automatically be a perfect fit - you may be in the same industry as someone, or have some similarities, but you’re also going to have your own unique needs.

Think bigger than immediate impacts - an idea that I first heard at UX Brighton in 2017 was that of adding society as a stakeholder in your blueprints. Think about the ethics of this selection, and the wider impact outside of your immediate bubble. Before you go too far, is this even something that you should be doing at all? Do you have a diverse team to support the technology? Are you selecting something to solve problems, or create them?

People you’ll come across within this process may be scared or hesitant; nervous even when they’re not selecting elements that have a life or death impact. Technology selection is an easy thing to use as a scapegoat when things go wrong, and so it can often feel like a very big decision to those whose shoulders it falls on. You may not be scared, but others may have been burnt by previous experiences, be resistant, or throw up blockers. Bear this in mind and try to be kind whilst also understanding their concerns and progressing your selection.

Additionally, as Dean Leigh suggests here, it’s also important to consider that some technology may provoke emotional responses from people that could have an impact on this process. Regardless of whether the tech is outgoing or potentially incoming, this is an important area to bear in mind.

Just a thought - I have realised one of the distractions moving from Wholething CMS to Umbraco is the emotional connection you have to software that we have been building and maintaining for 15 years, it's hard to let go.

— Social Dean's Dancing (@deanleigh) January 17, 2018

Having an outside party involved in the selection process or to validate decisions is often why I’m brought in, and gives people confidence that the choices have been well thought through. If that feels familiar and you’d like some help, please get in touch. However one of my key goals is to share skills and tools with people to help them grow their capabilities, so in line with that the rest of the article will be dedicated to how you can better choose technology if you don’t have an independent advisor to hand.

So finally, outside of seeking neutral advice from a consultant like myself, be sure to maintain a neutral perspective. Take sales pitches with a grain of salt. Consult industry resources like the following in order to get others’ opinions on the technology you’re thinking about. Ask friends, attend local meetups, or conduct some user research. Common areas that people often turn to include the following, but make sure that your reading fits the technology you’re looking to introduce.

• Thoughtworks Technology Radar
• Gartner Magic Quadrants
• stackshare
• Google Trends

A process to follow

The following questions outline a fairly standard process that can work across a range of technology selections. You’ll likely need to tweak each step to your specific needs, but try to maintain the balance of the questions. (A [PDF version](/pdf/RSTS_worksheet_ choosingtech.pdf) of the following is provided within the exercise section).

Set the tone

1. Project vision

Set out the vision for the project. What are you hoping to achieve?

Understand where you are now

2. Role in the ecosystem

Draw your existing ecosystem, including where the new element fits in. Think about the interactions between different elements, including any third parties. Consider whether this sparks any further conversations around dependencies, or even other areas of improvement that could be made. Use this activity as an opportunity to define the scope and boundaries of your technology selection. If you’re starting from scratch, then add in everything that will be introduced alongside the specific bit of tech you’re looking to use.

3. What else do we know?

Choosing digital solutions isn’t just about about adding in a piece of technology. What else within your organisation do you already know currently needs to change to support this? Think about the people and culture, processes, and overall strategy.

4. Gather your requirements

If you’re working from a brownfield perspective, you can use people’s previous experiences and testing of the current system to help with this. For the sake of this exercise I’m not going to dictate how you should do this (requirements gathering is a whole post in itself!), so feel free to use whichever tools or methods you feel most comfortable with.

However, make sure that you’re considering both functional and non-functional requirements, and that you also look for opportunities and innovation as well as just recreating what you have or solving problems. You should also try to capture the source/evidence for the requirement, introduce some kind of categorisation, have a sense of the loose level of complexity/impact, and run a prioritisation exercise (we’ll be looking into prioritising in March).

You’ll need the requirements for the following step, but however you document them please keep in mind that absolutely nobody enjoys reading enormous documents for the sake of it! Please try to keep them as light and to-the-point as possible.

5. Evaluate potential solutions

Here comes the important bit - gathering your options and starting to evaluate them.

Define your options

The options themselves will come from a range of sources. Perhaps there are best practices that you’re looking to consider. People may have made recommendations. There may be some project battles discussions about different approaches. You may have found some nice suggestions from your research or independent input. Gather these thoughts together, and then decide on the 3-5 options that you want to evaluate.

Define your requirement criteria

Alongside these, we also need to decide on how we’re going to assess each option. From your prioritised list of requirements, pull out the ones that are really key.

Define other assessment criteria

In addition, there are some areas that come up again and again in technology selection. Select from the below where relevant to your individual situation:

• Product confidence and vision
• Scalability
• Sustainability
• Costs (direct and indirect - think about licensing, staff costs, support, migration, etc)
• Time to implement
• Licensing
• Compliance with regulations
• Security
• Is it open source or proprietary?
• Does it have a community around it?
• What’s the documentation like?
• Reporting and fixing of issues
• Development impact (including whether you have existing skills, is it easy to hire for, ramp up time)
• User impact (don’t forget that internal users are users too - this is not just customers!)
• Performance
• Accessibility
• Impact on your overall strategy
• Impact on other technology and integrations (including compatibility with what’s there - refer to your output from the first task)
• Impact on your processes
• Impact on your teams and culture
• Impact on society and the wider world/ethical considerations
• Stakeholder preference
• Developer preference
• User preference
• Your preference (be mindful of any pre-existing bias)
• Summary of benefits
• Summary of constraints

6. Putting it all together

Once you have your options, your requirements, and your other factors, it’s time to start matching! Add everything in to a template, and start filling in the gaps.

In general, facts (e.g. annual fee) are best done by individuals, but where opinions are involved (e.g. impact) it’s often better to discuss these areas in a workshop setting where participants are from a range of job roles.

When capturing your assessments, try to note both what the different options do out of the box, and what is possible through customisation (including the impact of this).

7. Make a decision

With a long list of criteria, it can be useful to add a scoring mechanism (potentially with weighting if particular facets are much more important to you). This helps by providing a way to compare the overall results. Consider scoring for:

• does not meet needs
• partially meets needs
• would meet needs with customisation
• meets needs
• exceeds needs

Even if you’re scoring, make sure to capture any contextual comments. Not only are they useful to compare the different options, but they can also provide useful historical context around the decision-making process for future reference.

Take it for a test ride

Once you’ve whittled your options down to one or two, you may decide to undertake a trial, or create an initial prototype to test before making a full commitment. Whilst this can extend costs and timelines, it’s also a great way of ensuring that people will be happy with the selection made - having something tangible to use is much better than working off of descriptions alone.

Exercise: thinking about your situation

Now for the fun part: applying this to your own situation!

Follow the steps in this post by saving the linked worksheet, filling in the activities according to everything that has been discussed above, and once you’ve done that please do get in touch to let me know how your project went. I look forward to hearing all about it!

Download the workbook