The Dangers of Over-Processing

When it comes to food we all know that over-processing is pretty bad on the whole and that simple foods are probably better for us than their artificial alternatives.  Funny thing is though, when it comes to setting up organisational processes and even when designing learning solutions it’s all too easy to get carried away with trying to think of every eventuality and plan for it.  For that reason old-fashioned operations manuals were always crammed full of paragraph upon paragraph (upon page upon page) of heavy detail to make sure no stone was ever left unturned.  This is one of those times when taking detail to the nth degree lets in too much of the devil.

The simple reality is that in the world of organisational rules and procedures you really can’t think of everything when you go to great detail.  It’s kind of like getting older and realising that the more you know, the more you realise you don’t know and that knowing everything isn’t possible.  The greater depths we go in to describe a process the more closed off our process becomes to slight changes in details.  For example, if your processes are prescriptive enough to outline 5 different types of form depending upon minute detail changes, there’s a chance that there are more than 5 discrete possibilities for use and by prescribing the 5 you cover less people than if you just had one.  Government agencies seem to be the best at this kind of over-processing forms and the like (seriously anything to do with tax and you’ll know what I’m talking about).  What we really need to do to make these type of systems work is make it much much simpler.  The old adage of keeping it simple pays massive dividends in the area of processes.  The first is by having a simple process for a function you’re far more likely for people to follow it and waste less of everyone’s time.  Think about those old ops manuals stuck on the shelf covered in dust whilst employees did what they always did - now imagine bringing in process 234.23 to replace the now defunct 234.18 and wonder why no-one really cares.

One great way to simplify processes is to remove the reliance on heavily worded processes.  Many orgs have moved to process flow diagrams and this can really help keep them simpler.  Of course, just translating into diagrams without making changes to the processes and simplifying them too just gives you horrible diagrams.  I’m a fan of using swim-lane charts which clearly show who has the responsibility for what actions and some simple traffic light colour coding can help too with colours for manual process, documentation and automated elements.  We did this recently with an organisation and I was stunned by the simple story the picture told.  We used red for paper processes, orange for electronic but manual and green for automated.  If you lived in a city with a lot of traffic lights, the picture would represent grid-lock - and that’s essentially what happens with an organisation with heavy reliance on overly detailed processes that require far too much manual and paper type processes to work effectively.

Thing is when you want to cover every eventuality there are actually two ways to go about it.  One is the afore mentioned document absolute every possible eventuality (and be prepared to add to that list as you go and find out more possibilities) and the other is to keep your processes at a more holistic level.  Take for example if you’ve got a number of processes to follow in order to send someone on a training course.  Let’s say you start with some sort of development planning between a staff member and a manager that means the need is determined to attend some training/professional development.  Using the LMS there are certain courses in there, plus the ability to request new ones.  Using the HR system there are also records of conferences and marketing events being held in each of the regions.  Added to that there’s always the ability to review something new and raise an organisational need through the line management.  This could exist as a number of processes depending upon the activity and where or whether it existed, but in essence you’ve really got just one simple process here.  You can ‘start’ with the development plan and then ask the question if this opportunity exists - if it does, they book on with relevant approval and ‘do it’.  If it doesn’t they request it.  They don’t request it in 5 different places they request it in one.  This one ideally has some automation and can simply make sure the approvals or otherwise sit with the right people.  You then just need a process if not approved and link in to the standard process if it does.  Sure there’s approvals and exceptions and blah de blah, but by making this simple for the individual they are far more likely to actually push their request into the system and take on some new learning (kinda the outcome we were hoping for?).  By making your system cyclic you don’t end up having to have a whole different bunch of outcomes for different things, they all end up in the yes or no track one way or the other and both feed back to development planning too if we’ve done it right.

Of course to achieve this we need our ‘systems’ to have the same sort of approach, that is the ability to help us organise and make decisions.  How much time do you want to waste getting people who are already in your systems to fill in a form with their name, date of birth, place of work, manager etc etc when all that information is probably already held centrally?  You’d be amazed at the number of times I’ve seen a 9 step process with 4 forms all of which requiring predominantly the same information.  These are usually paper or printed off for record keeping…argh!  That’s why modern databases were developed - they have audit trails built in.  If you LMS or learning platforms are recording approvals then they are stored in the system and can be reported upon and reviewed.

The other big pain we often find in process is the ‘now send to the next in command’ step that goes backwards and forwards prior to being able to move to step 57 of the process.  We have to put some reliance on our people being able to do what is required of them.  For example, if you want a manager to get some approval on a budgetary manner before approving his staff’s requests you can just state that without including the process.  For example something like a decision box for manager approval with a caveat that managers should ensure they have cleared approvals over their authority with the relevant channel.  Keep it simple - don’t try and include every budget holder and all eventualities, remember keep it at a higher level and empower your people to make those decisions based upon their professional ability.

I was going to go off a bit more on learning and over-processed learning, but I think I’ll save it for another day as we’re landing soon (as usual on the aircraft and blogging) - but the theory is pretty much the same - keep it simple and don’t try to ‘teach’ every possible outcome.