Foreword

I first met Martin when we asked him to review our Search and Redact product, which was then ‘nascent’ at best. It was an interesting meeting: we had not met previously, I had not arranged the meeting and my expectations were not particularly high. Martin told me at a later meeting that his expectations were similarly modest! Jaded, in both our cases, may have been the apposite word. Of course the meeting turned out to be excellent, we hit it off personally and professionally and since then over the years Martin has been of great help to us with his combination of expert knowledge, affability and approachability. Those words also apply to this book: it is full of real expertise, it is an enjoyable read and it is highly readable.

I have not read this book from an academic viewpoint, probably because I am not an academic. I am what might be termed a ‘practitioner’; I am never quite sure if that isn’t a euphemism for something less complimentary, but never mind.

I have been both a creator of and a victim of workarounds in their various forms throughout my career. In the early days of my career I worked for Digital Equipment Corporation, which sadly no longer exists but was then second only to IBM. As a young IT gun I came up with a new way of performing the Material Requirements Planning calculation. This was the heart of what we then called the ‘MRP’ (aka ERP) system. It was taking 14 hours to complete this calculation. My solution, which was largely based on using memory (yes we did have memory back then!) instead of disk I/O reduced this to 40 minutes. This was then used with success in the plant where I was based, but we could not persuade any other DEC plants to use it. I assumed then that this was due to a ‘not invented here’ attitude, but in fact it was more down to the fact that using this software also entailed a customisation of the standard MRP package that all the plants were using, and thus constituted …… a workaround! The truth of the matter was that almost every DEC plant was customising this system in its own way – creating its own workarounds – which inevitably led to all sorts of issues when a new standard version of the corporate package was released.

The term workaround was not used at the time, we referred to it as customisation, but in fact we were dealing with workarounds.

So many of the concepts contained within this book applied to that situation, and could have been of real help in getting the situation under control:

• This was a large scale case of Shadow IT
• From a management point of view a classification of workarounds would have helped enormously
• Technical debt was being incurred at a massive rate. Each plant essentially had its own bespoke system; upgrading to the latest version of the corporate MRP system was virtually impossible
• As described in the book, managers were faced with often competing factors when deciding whether to accept customisations, in particular the balance between compliance risk and the expected gain in efficiency from the workaround. This was even more insidious because the decision in many plants was in truth the other way round: whether to accept the latest ‘standard’ corporate version.

For me, the value of this book is its clear and precise definition of the home truths regarding workarounds, and its invaluable advice as to how to address workarounds, which is largely a question being aware of them in the first place; once identified they can be managed.A great value of the book is its mapping of what could be considered ‘academic’ theory to recognisable real life business processes and systems. The book is by no means a negative prescription for the avoidance of workarounds: it is a prescription for the management of workarounds, leading hopefully to the extraction of meaningful added value to business processes and solutions.

Tim Barrett, CTO, Nalanda Technology