On the shop floor, not all software is created equal
A tale of two projects: Project 'Blue Sky' and Project 'Yellow Submarine'
We first wanted to extend a sincere thank you for being part of our IT/OT Insider Community, which is growing week after week :) Your engagement and interest make our shared exploration of these topics truly valuable.
If you've found our content insightful, consider sharing it with your network. Your support in spreading “The Word” helps us reach a wider audience.
Additionally, linking to us on your own website or blog can contribute to improving our SEO, which is always appreciated.
Feel free to subscribe if you'd like to stay updated on our future insights.
Thank you for being an essential part of our community and enjoy this new story !
Willem & David.
Why is it that some projects are simpler to execute than others? With some projects you can't move fast enough, while with others the excuses not to adopt a new tool are endless.
Before you start blaming yourself (or even worse, your team 🙃), consider that it might have more to do with the type of problem you are trying to solve.
Let's explore this idea with two hypothetical projects :
Blue Sky and Yellow Submarine
Project Blue Sky:
You are solving a problem that the end users are suffering from
It is directly linked to the job that the end user performs
Facilitates and even promotes experimentation. Doing something weird or wrong is perfectly safe, easy to correct and has 0 side effects.
Results can easily be shared with others who will also benefit from this in a direct manner.
Project Yellow Submarine:
Solves a problem for somebody else, oftentimes that’s management or other groups end users don’t know or see.
Is not linked to the end user’s job and hence, is perceived as overhead.
Errors or ‘undesired results’ are dangerous . They are hard to fix, or initiate an investigation into the root cause bringing in even more work.
Results are not shared. The information and its conclusions are closely guarded and considered too sensitive.
Now tell me, which project would you give a higher chance of success?
Unfortunately, experience shows that too often this aspect is (conveniently) forgotten. Sometimes it’s easier to start a project instead of doing proper change management up front.
But by acknowledging these differences we can do something about them. So here are some tips and ideas on how to handle each type.
Project Blue Sky :
Easy doesn’t mean no effort. If your solution falls under this group your challenge might even be how to scale up fast enough!
Have on-site contacts who can support you : Key users, central specialists that travel to all production sites.
Good e-learning resources can save you a lot of work while delighting users. Think how people want to ingest information, make it relevant, bite sized and interesting. Avoid boring corporate style ‘we do this because legal asked us to’ trainings, slide decks and this type of tutorial
Try to create a community around the product. It might feel artificial at first but that doesn't mean they can not be effective.
A successful implementation is more than happy users. You also need to get the sponsors on board. They need to know and feel that the money they are spending is actually benefiting their goals.
Get Metrics : Management loves KPI’s. So find a relevant one that is linked to their objectives! If for example your project’s aim is to increase productivity, try to measure how much money you saved or generated. If that’s too hard, find a proxy metric that correlates strongly with your key objective. Feel free to go a bit deeper, instead of active users for example, you could measure users who accessed the tool at least 3 times a week.
Bonus points if you use the same metrics to steer your team’s work
(caveat: do not try to measure developer productivity, it does not work)Show, don’t tell. Show the accomplishments that are possible now, show the use and business cases that have been realized and get your users to give their feedback too. And try to get testimonials from your biggest supporters.
Project Yellow Submarine:
As we all know, bringing additional applications to the shop floor without any benefit for them is as easy as saying : ‘just do as I tell you’. Right?
Seriously, you’ll need to be more creative here. It doesn’t matter how good the idea is, if users don't want to use it, it probably won’t be used the moment nobody is looking at it. Here are some things you might want to consider
User adoption:
Look at it from their perspective: What’s in it for me? If there is nothing there, could you extend the scope so that they also have something to gain from it?
Can you remove inconveniences ? Because every small inconvenience can grow to a source of frustration.
Control mechanisms : If the carrot doesn’t work you’ll need a stick. How will it work? Who will follow it up and in what way? What happens if it isn’t used?
We hope this gives yet another perspective to look at projects.
If you like this, also check out the other posts we made on ITOTInsider.com or drop a message to David or Willem