In this series I take a look at a number of pitfalls that the best of us tumble into when implementing process (workflow) and document solutions, and how these can be avoided (at all cost!).

Many tools make it easy to design workflows quickly, but while you might think you are dragging and dropping your way to a quick win, you may be in for a surprise as you discover your 3 step process to approving that expense report may be falling short of others’ expectations of perfection. 

Once you start showing your creation to your peers and management you might find yourself caught in long arguments about all the reasons why the rules you are designing are too simple and not entirely accurate. One by one, unwritten rules and exceptions to your rules will be explained to you, and guess what? They are all correct. 

You’ve heard of “death by a thousand cuts”? I call it “death by a thousand exceptions”. Let me give you an example relating to expense reports, a process we commonly automate for our clients

Approving employee expenses involves cash outlays, therefore usually a manager needs to approve it. Which manager? In a simple scenario, it’s the manager of the person making the request. But it’s not always quite that easy.

Maybe it needs to be approved by the manager of the department whose budget will actually pay the expense. This is common in cases where you have cross-departmental collaboration for a project. You don’t work for that person but she is paying for your expenses – for this project at least, not another one.

But what if the person making the request is that departmental manager in question? For the sake of accountability someone else must approve it. In this case, maybe it should be their own manager – unless of course that expense relates to the project of another department, in which case it should be that department head who should approve it.  

And what if department head in question is on vacation and it’s a high priority expense that needs immediate approval to move on a key to-do (since that happens often), we might then need to re-route the approval to the next manager on the list. And in the event that it routes up all the way to the CEO and well, there is nobody assigned as the CEO’s manager, then let’s say it’s the CFO who takes care of it – unless of course, they happen to be unavailable that week. What should we do then? 

Not only have we not answered all the questions (which are rapidly becoming mind-boggling), we have already identified out of the gate that to process a request we will need to navigate through a complex cross-functional or cross-project organizational chart. Oh yes, and everyone’s calendar, too. Do those things even exist in a database?

Plus nobody has yet mentioned the accounting concept of materiality – how will the CEO feel about getting a request for the approval of a $79 expense just because by fluke a few people are out for summer holidays and someone’s Amex bill is overdue? Do you think that event might trigger a few harsh meetings?

Although this example appears exaggerated, I promise you it is quite real. What I described is the difference between a “quick and easy” 3-step process and one that can take over your life for weeks or months with debates and tricky configurations and programming.

Enter my all-time favorite: the Pareto principle, better known as the 80/20 rule: although originally intended as a financial measure this rule is easily applied to many business cases such as this: 80 percent of the difficulty in configuring the workflow will arise from 20% of the requirement. It is therefore incumbent upon us to brutally analyze what is essential, and what is not absolutely essential for success.

Consider at all times where you are coming from when implementing something new, because creating Agile business processes follow a concept of “versioning” – it’s better to do something today that works, than something perfect that never gets implemented. You can always create a version 2.0 (if Microsoft can do it, you can too!). You can afford to be “good enough” to start, especially when you are new to process changes. Let me state it more definitively: you can’t afford NOT to.

So where are you coming from? Strictly e-mail communication possibly, maybe a basic spreadsheet? If so, today everyone selects their manager… manually! If this is the case, why would you now need to build a monster matrix org chart with calendars and exceptions upon exceptions, when in fact the biggest reason to automate may not be the routing, but the transparency and service levels ensured by the workflow tool?

Simplify, and follow the pareto rule: save yourself from death by a thousand exceptions.