All of us learned early in our driving experience that guardrails are a tool to prevent us from leaving the road at the wrong time. Over the decades they have come to save an untold number of lives worldwide. But they also provide us a visual guide before the negative opportunity presents itself. This ideally results in us driving right by the guardrails and not actually using them – and avoiding the subsequent physical or monetary pain that can come from testing them.
A good solution can take on the role of guardrails in an organization. Those solution guardrails often incorporate a set of tools to prevent the mistakes that have consequences – or push back when you’re heading in that direction.
Defining what guardrails are needed and where start with reviewing the “what ifs” in your processes – and continue throughout solution project. It begins in the solution design, continues through development, eventual implementation and then training the User or solution “driver”. It takes time and effort to do this right, but it is a critical investment in creating a successful solution.
My partner has stated many times, “You never have time to do it right, but always have time to do it over.” The cost of not identifying the “what ifs” (and creating guardrails) can be high. Rework alone is a major contributor to cost overruns and frustration with staff. So what if you could prevent it?
In our work with automating fixed asset inventory activities, the majority of our users are moving from a “pen and paper” world. While a manual approach like that can work, it is prone to many issues like:
- Incomplete data
- Incorrect data
- Unreadable data
- Untimely data
You get the picture. The reason for all of these issues isn’t that our folks are intentionally looking to sabotage this activity (that can be managed also). It’s that we’re having them perform the tasks without the benefit of stronger direction on their activities (guiding them) and guardrails (prevention) when they are approaching problems. These are the capabilities that make software into a solution.
We’ve also had the opposite experience where the guidance and restrictions are so tight (bubble parents), that the results are poor and even worse than previous before the solution was implemented. We all need to be aware that “Users” can always find creative ways to create challenges for an automation project. Usually these arise when they solution is unnecessarily cumbersome. We had a situation with government client were they had us build over 50 screen possibilities in just Receiving, using automation to control – versus support good procedures and training. The good news is that shortly after implementing they allow us to create the right type of user interface that corrected all the issues and they then became successful.
Guardrails are viewed by some as unnecessary and a waste of expense and control. In the software world we know, that is not the case but is actually a necessity. No organization has the luxury of being there to answer every User question or correct all the issues after the fact. The “guardrails” offered by a software solution aren’t a luxury. When used properly, they are a key component to maximizing both the return the solution was created for and the User’s ability to get us there.
