Most people have been exposed to the 80/20 rule at some point in their lives. This is widely used to indicate that with 20% of your effort you can achieve 80% of your desired results. The rule is often referred to in the context of whether it is worth trying to get 100% results the first time.
The 80/20 rule often doesn’t fit well in process-driven environments. In many (if not all) large organizations there is a documented process for accomplishing a particular task. This is especially true in IT departments. There is a process to build a new piece of hardware, to install a piece of software and another and another, to transfer data and the list goes on. Process, process, process!
All of these processes serve a good cause. Firstly, they were developed (hopefully) from bug experience, and thus were tested, evaluated, and considered robust. Second, if followed, they ensure consistency of work for given tasks. Each of these are very good reasons to create, implement and adhere to the process.
The problem with processes is that, for some, they become the bible that people will not deviate from. Furthermore, they provide a barrier behind which people can hide and not take true responsibility for their actions.
Let’s focus on the coach. If the processes are implemented without a feasible/practical exception path, any hope of pragmatism has just disappeared into a black hole. Because of this, the creativity of individuals is stifled at the first hurdle.
Imagine that you are in a situation where you are managing a project. For some reason, you’re late. You cannot delay your delivery date to compensate, so your only route to mitigation is to reduce your delivery time. You may have a number of options regarding parallel work and/or more resources, to name two, another may be to cut corners. Now, before you run off and say “cowboy project manager” under your breath, read on a little further.
There is nothing wrong with taking shortcuts as long as you identify the risks you are taking/creating by doing so, and manage them accordingly. You are taking a pragmatic view of how to meet your time constraints (in this example) and being flexible.
There are some dichotomies here;
1. Almost by definition, processes are not flexible.
2. (Commonly) Organizations that have a large number of processes do not take risks
The negative impact of all this is that there are companies that are inhibiting this creativity, dare I say “think outside the box” because employees must adhere to the process. Also, IT projects take much longer than necessary to deliver.
In closing, I remember having the pleasure of seeing Brent Hoberman speak. He talked about the implementation of Last Minute and how, due to massive media publicity, there was no option not to deliver on the announced date. There were IT problems, bugs everywhere. No problem, live anyway, have developers (probably a lot of them) lined up ready to fix bugs on the fly and put the fixes live and react quickly. Great, I wish I could have been part of the team. Sure there were some “interesting” moments, but also immense satisfaction when success was achieved.
