What happens when tech transformations lack joined up thinking

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

1. It improves operational efficiency
2. 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
3. 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

Training

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

1. 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
2. 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
3. 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
4. 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

Iterate

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
• Training
• Check in
• Iterate

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!