Why every tech project is a change project – and how to make that change stick

If you want new technology to be embraced by your organisation, you need an approach that considers people and process, as well as tech. Here’s a framework to help you get there.

Organisations often approach technology adoption as a tech issue. In reality, adopting new technology is about so much more than just software. It affects people’s habits, the skills they need, and how they work and collaborate.

Technology adoption should always be treated as a change management project – it needs to consider people, process and tech equally to succeed.

Below is a 9-step framework that I use in my work as a digital strategy consultant to ensure technology change goes down well with an organisation’s people. It covers the foundations you need for new technology adoption as well as tips on how to design your change plan effectively and how to deliver it.

Taking yourself through the thinking at each of these steps and actioning the parts that work for your organisation will help making your change stick.

Try it – and let me know how you get on!

Change management for technology projects: a 9-step framework

Step 1: Set up roles and establish responsibilities

You need the right people in place from the start. As well as the obvious project roles – sponsors, product owners, project managers, Subject Matter Experts (SMEs), change leads etc – you need to identify internal users who can support the project: your Change Champions. These are people who help answer questions about change and bring concerns and issues back to you so you know what needs addressing or resolving. 

Watch out: Establish which role(s) will be making which decisions on a project, and be clear about the scale of commitment involved. Change work needs time, it can’t be an add-on to someone’s job. 

Step 2: Agree the WHY

Establish what will change and the motivation behind it. Agree within your core team how you will talk about it within the organisation (aim for honesty and transparency) and ensure everyone on the project is aligned, so people hear the same message many times. Create a communications plan to match your project milestones and organisational priorities.

Watch out: Avoid jargon. Your rationale for change must be easy to understand – even if some people may disagree with it. 

Step 3: Map your stakeholders

This will help you understand who your supporters might be and who is likely to need more help before they can support your change. Plot stakeholders on a scale that shows their support and the influence they have within the organisation. Here’s more on understanding and influencing stakeholders during transformation projects. You also need to need to map the stakeholders by the impact the change is making on them.

Watch out: Make sure you speak to high-influence stakeholders with low support for your change early on – don’t avoid it because it’s uncomfortable. 

Step 4: Assess impact 

Your stakeholder mapping helps you assess who will be affected by the technology change so you can anticipate where support will be most needed. The SCARF model is a useful way to understand people’s reactions to change and what they need in response.

Watch out: Steps 3 and 4 will require you to make some assumptions about people’s reactions. This is a useful guide for the first stab at the messaging on why change is happening. But don’t leave it there, keep having conversations, listen deeply, gather data and adapt your plan as you learn more.

Step 5: Group by support needed

Different people will need different kinds of support – workshops, training, buddies etc. Use your Change Champions to help you keep an ear to the ground and work out which business areas need what. Then group them by need or team.

Watch out: Don’t overcomplicate your groupings – keep them simple, then listen and adapt them as needed.

Step 6: Plan the support

Everyone’s learning style is different – so what options should you offer?  Kolb’s Learning Cycle, and learning styles that are derived from it, is a great place to start: 

Honey and Mumford Learning Styles: based on the Kolb learning cycle

Watch out: People have preferences in how they learn - some learn by doing, others need training first. Don’t try to create too many options, so it becomes impossible to deliver them. You only need enough that people with different preferences have different ways into the same content. 

Step 7: Check the load

The “change load” in any organisation is finite – running lots of big projects means lots of big change. Make sure you’re not asking too much from the people at once, e.g. three new tool rollouts that require people to change how they work. Stagger it, or group if there are things that can work for both, e.g. training or participation in a pilot that helps with two of the three changes.

Watch out: Change needs time! It works best when people can engage – and for that they need time away from their day-to-day work. Do managers understand the time needed for their people to deliver this? If not, the time to “do change” will end up de-prioritised over day-to-day tasks. 

Step 8: Deliver change

Implement the plan - communications, training and support! Keep listening and adjusting as the project develops, you learn more, and things change.

Watch out: Check in on a regular basis that everyone has what they need – people on projects can change, and when projects get busy the change work often gets de-prioritised.

Step 9: Track and adjust

Tracking throughout is key. Agree your change KPIs at the start of the project, and keep asking the same questions throughout to track user attitude to change. Your Change Champions will be a big source of feedback, so make sure processes are in place to gather their data throughout the project.

Watch out: Quantitative data (numbers) might be easier to gather and crunch, but you need qualitative (stories) too for a complete picture.

Change is continuous

This is a repeatable process that can be used time and again, and adapted for projects of any size. Not every step will be necessary for every project. But clarifying the WHY of the change and roles and responsibilities on the project always help.

The one non-negotiable is good communication, with users of the new technology at the heart. When you’re clear about what is expected from people and teams, honest about what is changing and what isn't and respect people’s time, skills and different learning style, they’ll be more willing to join the process.

Your tech stack is only ever as good as your people stack – in times of change this is the most important thing to bear in mind.


A good product development process is just the beginning – you need to plan the change alongside it – and ensure your workforce feels involved, heard and prepared.