What happens when tech transformations lack joined up thinking
Bringing your team on your technology journey
So you know you have a bit of a gap with some of your technical landscape, you’ve researched what you need, got some funding – you just need to implement it right? Not quite, if only it were that simple. This article doesn’t cover how best to implement a new system/tool – that’s one for another day. This focusses more on the key relationships between technology, people and successful technology implementations.
Technology is just part of the equation of successful tech delivery. Forget about the humans and you are likely to arrive at an incorrect solution. The charity sector in particular has broad differences in the technical skills and technical willingness in its workforce. Layer in the use of volunteers that float in and out of your organisation and you have probably one of the most diverse groups of people all trying to use the same systems in the same way. Layer over again the fact that most of these people do not work full time hours and you can soon start to see how complex it is to introduce new tooling and ways of working into an organisation and ensure they are embedded into the fabric of how you work.
The tools that charities use serve a few main purposes
- Simplify and make processes more patternable
- Collect information and data in way that it can be used to gather intelligence on how you work and who you work with
- Provide a secure way to hold information
Why is this relevant in the context of this article? Because, if you can’t ensure your team is engaged, trained and championing the systems you use they will likely not use them in the way you intended and that’s when we start to see
- Divergent processes in teams
- Inconsistent data collection
- Data loss (through not using systems as designed, or at all!)
- Frustration, irritation and silos (and declarations that “things” don’t work as they should)
- New tools being introduced to solve perceived issues in existing tooling, leading to an overly complex and disjointed landscape
So how do we fix this?
Ideally we start at the beginning – as tools are introduced. However if you are reading this and thinking – yeah that’s great but we already have all of those problems so it’s a bit late to say “start at the beginning” – don’t worry I’m going to cover that too a bit later. Keep reading
Tool selection and getting your team to love it
Appoint an owner for the project.
It is important that someone owns this delivery and engages all key stakeholders for the duration. Without clear ownership there can be a quick lack of direction and clarity.
Engage your team
Talk with your team at the earliest possible point and don’t assume that a few people understand how everyone else is working. Garnering information on people’s current ways of working provides invaluable intelligence on how you need to model and implement your new tool. One of the best ways to do this is by engaging teams in workshops and discussions about current working practices.
Don’t mirror existing lengthy (often manual) processes into a system
Identify your current processes and work with your team and your implementer directly to understand the challenges and issues the team are struggling with and work to find solutions within the tooling to help alleviate these issues. This offers a few benefits
- It improves operational efficiency
- Your team have an opportunity to discuss current issues and pain points, be heard and start to understand the real tangible benefits of the new tooling
- The organisation benefits from the deep knowledge of the team members handling the day to day operations
When I have run these types of engagements the knowledge gained by the organisation about the specifics of each team and how they work has been staggering. Often everyone is so busy trying to do the best for the end service users that how hard they are having to peddle to work around/with/against technology is often invisible.
Engaging your teams before the system is set up allows them to see how the system can help them, understand better why it is important to the organisation as a whole and start to feel more comfortable with something that may initially be quite daunting
This is so important I feel its needs reemphasising. Training, training, training. Don’t expect people to “learn on the job”. Remember at the beginning of this piece I talked about the complexities of workforces in the charity sector. Many often have a real lack of confidence alongside potentially lack of current technical skills. Skills can be taught easily enough but lack of confidence can be crippling to a person and an organisation. In my opinion the best way to combat this is with training. Work with your systems implementer to
- Identify super users – find at least a couple of people who can be the “champions” for this system. They are likely to a) understand the real benefits and b) already have reasonable technical confidence. Provide these people with additional in depth training so that they are able to support those who lack some confidence
- Run small focussed training sessions with users that use real world scenarios. The training needs to make sense to how people work – it can’t be conceptual or show the “art of the possible” it needs to relate to how they really work
- Record the sessions (with permission of course) so people have something to refer back to – particularly useful for those who need to see things a few times to gain confidence
- Create short how-to video’s/articles covering the most common scenarios
Check in regularly
After training the biggest mistake I see time and time again is the assumption that you got it right first time. This never happens. It never happens as no matter how much preparation you do, how much testing you do as you can’t test for real life. You’ll get a good percentage of the way there, but you won’t capture everything or have remembered all the scenarios. The best way to combat this is to perform formal regular check ins with the teams using the systems. There are a variety of techniques for doing this and you could use one or more of the following
- A forum for people to raise questions/issues/ideas
- A regular drop in surgery where people can pop into to ask anything they want
- Formal reviews with key team members – run scheduled sessions to reflect on what is working well, what is not and any ideas for how things might be improved.
In my opinion the check in frequency need to be super frequent in month one (and even more so in weeks one and two), regular but less frequent in months 2 -3 but continued until at least month 6.
The point of these feedback loops is to identify bugs and genuine usability issues with the implementation that may either require immediate attention or to be put on a backlog of ideas to be addressed less urgently
The point of the check ins is to build a list of fixes and feature requests based on real world use. It’s important to make impactful changes regularly for a number of reasons
- Improve operational efficiency
- Adapt to the changing needs of your team and your service users
- Keep the team engaged by delivering regular increments of useful changes from the backlog they created
- Avoid delayed big bang changes – when you leave a system so long that you realise it is not fit for purpose and needs a wholesale rework
So what about if the system is already in place and you have the issues I mentioned at the start – how do you fix it?
This is more tricky as you might expect. If you are experiencing some of the issues I mentioned at the beginning then it is possible that you have a disengaged or disillusioned team with regards to your systems. The reality is that this will be the first issue to address - until a team is fully engaged and on board you will find it really challenging to fix any genuine technical issues.
There are many experts out there that can offer real guidance on organisation coaching that are much more skilled in this area then I. My thoughts are this
- Create opportunities for open and honest conversations
- Really listen to each other. Not a vanity listen a real hearing of concerns and challenges
- Be prepared for some uncomfortable conversations and some internal reflection
- Identify and acknowledge the issues and truly work to understand how they have occurred and how to avoid them in the future
- Ensure the organisation is truly united on their goals and that the work your team is doing has clarity on how it enables those goals
I am sure an expert in this area will have differing thoughts to this - this is purely my view of the world having worked with many organisations already in this position
Once this work has been done you can then set about rebuilding the trust and confidence in systems. At this point you can almost follow the pattern described previously – just don’t try and do it before you have addressed the genuine issues that have caused frustration. So:
- Appoint an owner
- Review processes with those performing those processes most and using the systems
- Identify opportunities for improving the implementation and training
- Check in
People are just a hugely vital part of any technology change and ignoring the need to engage and bring them on the journey with you will not lead to a happy ending. Do everything you can to support those using the systems that power your organisation but also remember that there may be times that some people can't embrace the changing technology landscape. Do what you can and work hard to resolve issues but also know when its time to have another of those difficult honest conversations that we often try to avoid!