The vexing thing about the obvious is that it tends to be invisible and painfully visible when you cross it. Like skipping coffee in the morning or not watering your plant every month. Or forgeting the software development maxim: a process which cannot be repeated consistently is better left unautomated.

On pain of this post being considered a total bore, it must be stated explicitly: until there is consensus in your organization about how a process is to be handled and the chain of activities¬†is repeatable consistently, you are toying with project failure should you try to automate it. Instead of commissioning software developers to build you a tool to automate your process along with its healthy peppering of exceptions, you’re better off bringing in a process engineer.

There is also a different view of the same problem. We understand implictly that failed software projects tend to have a lot to do with not understanding the workflow in question or not gathering the breadth and depth of requirements correctly. But another obvious thing we tend to overlook is: if it’s indeed that hard to gather requirements for a particular workflow, it may be that the workflow isn’t all that defined in the first place.

As a business executive that may be in charge of approving a software project, it is advisable to get your team together and see if they can, unerringly and consistently, walk you through the process you are seeking to automate. As a CEO or CIO, it is too tempting to assume that your birds-eye view of a process that shows no blemishes is indeed so.