Process Overkill

I just got off the phone with potential new client, the CEO of a pre-Series A startup.  I feel bad for him because the poor guy just wanted to get his financial accounts in order.  So he hired a well known, reputable accounting firm.  60+ billable hours later, his accounts are still not in order.

Instead, it sounds like a great deal of effort has been expended to automate and integrate his accounting, payroll, banking, and payables systems.  It sounds like the accountants burned through some of the 60+ hours trying to set up ACH electronic transfers between vendors and the company and linking in a SaaS bill pay system instead of just posting entries.

All this for a less than five person, pre-revenue bootstrap startup that probably does less than twenty purchasing transactions a month, most of which are on the company credit card.

Another victim of process overkill.

In a different case, one of my current clients, a thriving $20MM+ revenue business, is just now upgrading from Quickbooks to a conventional ERP system.  As part of the implementation, they are putting in place a formal purchasing process.  The process owner has a common sense approach.  For her, the purpose of the process is to contain costs by reducing redundant buying.  She's scoping the process to facilitate the most common buying situations, not to cover every situation.  She wants the process to be easy for people to use; no massive purchase requisition forms.  And most refreshingly, she knows that she will have to handle exceptions to the process.

Part of startup conventional wisdom in Silicon Valley is that one should build ahead of where you plan to be. Planning to be a $100 million revenue company in three years?  Better get that SAP or Oracle ERP system in place now!

But in my experience, to avoid process overkill, startups would be better off if guided by a different principle:  scale appropriate.

Scale appropriate means working with processes set at the level you are currently at.  Still trying to validate your business model and build prototypes?  You don't need an ERP system.  You don't need elaborately defined purchasing requisition and approval processes.  You don't need ISO9001 level ECO (engineering change order) controls.  And while nice, you don't need your online banking system integrated with your accounting software.  Quickbooks plus a bookkeeper doing manual entries with an occasional account review by a CPA should be suitable for financial tracking.

So how do you determine when it is time to upgrade process and infrastructure?

• Routine tasks are increasingly getting dropped
• Increasing error rate on routine tasks
• High personnel cost associated with the people running the processes (either because you need a lot of people or you need highly trained ones who are really expensive)

Process Implementation Guidelines
So how do you go about implementing scale appropriate processes?  Here are a few of my guidelines:

• Know the Objective - It seems obvious, but before implementing any process, be sure you know what the end goal is.  Is is error reduction?  Workflow simplification?  Scope expansion (i.e. enabling less skilled people to perform the task)?  When you document your process, this should be the first thing at the top of the page!  Why?  Because over time, the purpose for the process will be forgotten and the people who put it into place may be gone.  Soon the process takes on a life of its own and you end up with mindless bureaucracy.  Don't believe it?  During my first turnaround, at an ISO9001 certified company, in forcing a review of every ECO process we had, we discovered one that had never been used in the ten years it had existed, but was driving 25% of the data collection fields for the entire ECO process.  Why had it been implemented?  It was a what/if scenario.
• Set the Metric(s) - Once the objective is set, make sure you have a way of measuring whether the process is being effective  This way, you can determine whether future changes to the process are helpful or harmful.  Frequently, this will help prevent process overkill.
• Evaluate Whether Existing Processes Can Be Pushed Harder - Before implementing a new process, see if the existing processes or infrastructure can be pushed harder.  While I know this is going to go against the advice of every business process person out there, don't fall prey to the "blank paper approach" siren.   This especially goes for evaluating  a new ERP system.  You'd be surprised how hard you can push a legacy ERP system.  And while pushing a legacy system can seem like a lot of useless work, be sure to compare it against the disruption of transitioning to a new system.
• Design for the 80/20 Rule - If you do need a new process, design it to handle the 80% most common work outcomes, not the 20% exceptions.  Designing a process to handle 100% of the contingency situations that might arise is the path to process overkill.  It's usually simpler and more effective to let a person handle the 20% exception cases.  Be very careful listening to the "what if?" person in the room!
• Don't Over Automate/Integrate - While it is tempting to want to automate and integrate all your various processes and systems together for push button convenience, there can be a price to pay as well.  Integration to improve data transmission accuracy or eliminate multiple or complex manual steps that can lead to errors may be worthwhile.  However, the more processes are interlinked, the more you may run into unintended consequences particularly if changes to any of the independent processes are made.  This can lead to a situation where one is spending more time troubleshooting and fixing processes than performing a manual step once in awhile.

One of the biggest sources for process overkill that I see comes when someone attempts to design a process to eliminate a human being.  For all except the simplest processes, this rarely works.  In my mind, it's better to design a process to leverage the capability of a human being, not eliminate them.

Establishing highly integrated and automated processes comes with a price.  Where transaction volume is high, complex in nature, or the consequence of output error is high, it may be worth paying that price.  There is a reason that large multinational corporations, financial institutions, and government agencies tend toward these type of processes.  But they also spend hundreds of millions of dollars with fairly large dedicated IT staffs for the privilege.

For small businesses and startups, the focus should be on effectiveness in getting the job done.  Whether it is done by people, processes, or a combination should be secondary.

Related blog post:  Process vs. "Product" People