Spend it to save it, or: do it right the first time

When performing a task, one will often be in the position to choose either doing something quickly, or doing something right. In many cases, either example is fine, as the job gets done satisfactorily. Still, I believe that you are better off with doing it right each and every time. Now, before you think I am preaching about my own level of perfection, know that this is not the case, and that I fail to do this more often than I would like to admit. This is not an admonishment; it is a level to which I aspire.

What, then, do I mean? What I mean is that, by spending a little more time in doing something initially, I prevent having to rework the same thing later on. This in turn prevents wasted effort, improves customer service level, and reduces WIP (work in progress, a term stemming from the theory of constraints). Paradoxically, the end customer may not even be aware of the fact that you have done something other than what you may have done, but will not have cause to return for issue remediation.

Let’s look at a few real-life examples of this, to see what was done, and the cost associated.

• A car is in for service, and the mechanic removes the steering wheel to gain access to the steering column. They replace the steering wheel quickly, and return the car to the customer. The customer finds that the steering wheel is misaligned. In the end, the car has to go back into the shop for service, and the customer is annoyed by the added trip to the shop.
  • The cost is twofold. First, the shop has to assign resources to the car a second time. Because it is remediation of an issue they introduced, the time spent is not billable. Second, the customer is annoyed, and tries to find other shops for the next appointment, costing the shop business.
• A user requests access to a shared mailbox in Outlook. The access is granted, and the user is notified of this, without being informed how to access the mailbox. The ticket is reopened, and the user requests information by the service desk, who provide the documentation to them.
  • Again, the cost is twofold. Like before, rework costs time. Second, the perceived service level is less than the user might expect, and may – in conjunction with other such failures – lessen the perceived competence level of the service desk.
• A user reports a software problem. Support concludes that resolving the issue requires the operating system to be reinstalled, and reinstalls it without coordinating with the customer beforehand. Because the user has not been given time to prepare, they lose locally stored files.
  • Though policies may be in place that data is to be stored on network drives, the fact remains that users often ignore these policies. While they do so at their peril, ensuring that they have the option to back up information when possible before commencing work is always a good idea, and reinforces the policy.

Though each individual instance of rework may seem insignificant, the effort involved with remediating such issues compound over time. For an outfit where output is near, or at, capacity, identifying these instances and addressing them will both free up resources to perform other tasks, and may also well serve to improve the quality of work delivered. Both of these are highly desirable outcomes for any organisation.

Whether you call this CSI (Continual Service Improvement, as known in ITIL), or take a broader view and call it the Improvement Kata of TPS and DevOps fame is frankly irrelevant. The important thing is internalising that the improvement is important, why the improvement is important, and to clearly communicate the improvement throughout the organisation.