Last week we elaborated on the different phases we need for a successful automation project. Today we explore the phase of standardisation in more depth.
A nice side effect of the standardisation is that we get a more consistent output. Instead of the many different ways of doing things, we end up with a single approach and that by itself will reduce the inconsistencies.
Narrow the scope
The scope is one of the most important parts for the standardisation in the context of automation. We do not want to standardise the entire world. We want to focus on the process or the application in which we do some automation work.
Start with a narrow scope and then look where it goes. It may be helpful to use the same kind of standardisation with the next process we automate. Or it may be a thing that at the end can be applied to all the work a team does. Grow the scope as long as you get a positive return.
However, going with one way for the whole company of thousands of workers may not bring us any benefits. Not because the approach would not work, but because there will be so much bureaucracy that all the effort will be suffocated by the sheer number of forms to fill.
Find one way to do a certain thing
The key effort in the standardisation phase is to identify the different ways we currently use to do the same work and to define one way, and one way only, that we want to use from now on.
Example A: standardise a process
For process automation the scope is the process that we should automate. Here we look at the different people who currently do the work manually. We explore the tools they use, look at the steps they do, and in which order they do the work. There may be parts of the process where the order matters, while in other parts it does not.
If we come up with a canonical list of steps that are done by everyone, we need to look at the steps that are only done by some. Maybe those are optional steps, maybe they are extra work we can get rid of.
If the process is in use for a longer time, we usually do not find missing steps. However, the exceptions may proof the rule. Especially when it comes to processes that go over boundaries in a company, we still may find steps that are missing because they are used by another team and so far, no one understood that they could let the work be done by those people who already have all the data. Therefore, keep your eyes open and follow along to all stakeholders that do something with the results of that process.
Example B: standardise the user interface
When it comes to user interfaces, there are many things on which we can focus. Especially with web applications we often find an inconsistent behaviour when it comes to forms. The input types may differ from one form to another, even when the data that goes into that fields is the same. Another hiding place for inconsistencies is the validation handling. Do we show errors as a summary or by each field? Is the summary on top or below the form? Do we use the same shade of red to show missing fields?
Since there are many code pieces that need to work together, we often end up in the situation that the developers copy and paste code from one form to another. While they may copy most of the code, they may not always do that. Within a few repetitions our forms may start to diverge in subtle ways.
Those inconsistencies are not limited to the user interface. Everywhere where we use multiple lines of code to produce an output will we find the same problem. It is therefore paramount to define one way that our application should follow and then make sure that we use this way everywhere in the application.
Who should decide what way to follow?
Whenever possible, let the people with the most experience of doing the work decide on what way to go. They are in a much better position to make a trade-off than someone who just started understanding what is going on.
What is the right way?
It may be a surprise, but to be right is less important than to be consistent. The longer we are in a project, the clearer we can see what the right way is. It would be great if we only then would start doing the standardisation work. Unfortunately, that is a bit too late for most projects.
The second best we can do is to settle with one way and get the consistency. If we now find something better, we know exactly how we can go from the consistent way we have to the one we should do. It is extra work, but it is significant less extra work than if we would need to handle all the inconsistencies at the same time.
Next
Keep the scope as narrow as possible when it comes to standardisation. This will not only make your work simpler, but it will also increase your chances of a successful automation project. The main point is that you know the variations that currently exist and end up with one single way to do things to go forward.
Next week we look at ways to simplify that newly standardised way.
2 thoughts on “Consistency Through Standardisation”