Managing technology risk

In the fast-moving world of digital product, there’s always a shiny new tool, technology or framework to consider. Managing technology risk to decide if, and when, you should implement them is an ongoing battle for developers.

How do you know when to embrace the new thing, and when to stick with what’s tried and tested? And if you do decide to go with the new technology, what’s the best way to implement it?

Should you use a new technology?

It’s easy to get caught up in “shiny new thing” syndrome and assume that new = better, but that’s not always the case. When new tools or frameworks are released, it’s important to research how that technology is better than the solution you already have in place.

The big question to ask when managing technology risk is, does this tool solve enough problems, or provide more flexibility, to make it worth implementation? Or are you just chasing the latest trend?

If you suspect it’s the latter, it may be best to put it to one side. You can always revisit this decision in the future, if the new technology becomes more widely adopted, for example, or your current technology becomes deprecated.

Writing up a business case which considers the financial implications of implementing a new solution against the potential benefits it will provide is a good way to structure your thoughts and understand the risks involved.

Remember, it’s not just the cost of the tool itself; alongside subscriptions and licenses, there’s likely to be investment required for setup, configuration and maintenance, as well as training and upskilling the team.

It’s also worth considering not just how this technology addresses your current needs, but how it might support your team in the future. That doesn’t just mean how it scales, although that’s obviously key; it’s also about how the technology will develop, what additional features or services it might provide, and how well it will fit into your overall tech stack.

‍

"How easily can the solution evolve as your organisation and your requirements evolve? Try to picture five years from now. Is the technology propelling new ideas and ways of working or is it struggling to keep up as the organisation changes and matures?"

Vera Solutions

‍

How to implement new technology

If you decide to implement a new technology, there’s a few things to consider.

1: When to implement

If your team is currently dealing with a problem that this new technology could solve easily, then it may be worth implementing it straight away. However, you should also think about where you are in the project timeline – it makes more sense to try something new at the start of a project than towards the end.

2: Upskilling the team

What training or additional support will the team need to get comfortable with the new technology? Having a development team with a wider skillset broadens the capabilities of the whole company and expands the types of new work they can take on, but that additional investment can affect timelines and costs on your project.

3: Scaling up

When the project or team scales up, the new technology needs to be able to scale with them. You should also consider the rollout plan for this solution once your trial is complete.

‍
‍

4: Cut off point

When managing technology risk, it’s important to define the cut off point. How much time and resource are you comfortable investing in trialling a new technology and ironing out the wrinkles before deciding if it’s worth continuing with?

5: Back up plan

After implementation, you might find that the new solution just doesn’t work for your project or business. If that’s the case, there’s no shame in rolling back to your previous setup, but you’ll need to understand the implications of reversing your decision. Will it affect other projects? Does there need to be a transition period between new and old?

—

Overall, the decision of when to implement new technology comes down to whether the effort for your team is worth the benefit of using the technology. From there it’s all about putting in a process for how to trial out the implementation and broaden the skills of the team. There’s no harm in trying out something and finding it doesn’t suit as long as you’ve planned for that scenario.