Most people have been exposed to the 80/20 rule at some point in their lives. This is widely used to indicate that for 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 attempting to get 100% results, first time. The 80/20 rule often does not sit well within process driven environments. In many (if not all) large organisations there is a documented process for achieving a particular task. This is especially true within IT departments. There is a process for building a new piece of hardware, for installing a piece of software & another & another, for transferring data and the list goes on. Process, Process, Process! All of these processes serve a good cause. Firstly, they were (hopefully) developed from mistakes experience and so are tried, tested and deemed to be robust. Secondly, if they are followed, they ensure consistency of work for given tasks. Each of these are very good reasons for authoring, implementing and adhering to process. The trouble with processes is that, to some, they become the bible from which people will not deviate. Additionally, they provide a barrier behind which people can hide and not take true accountability for their actions. Let's focus on the former. If processes are implemented with no achievable/practical exception route then any hope of pragmatism has just been swept away into a black hole. Because of this the creativity of individuals is stifled at the first hurdle. Imagine your in a situation where you are managing a project. For whatever reason, you are behind schedule. You cannot move your delivery date back to compensate and so your only route to mitigation is by reducing your delivery time. You may have a number of options with regard to parallel working and/or more resources to name two, another may be to cut some corners. Now before you run off uttering "cowboy project manager" under your breath read on a little more. There's nothing wrong with cutting corners as long as you identify the risks that you are taking/creating in doing so, and you manage these accordingly. You are taking a pragmatic view of how to deliver to your time constraints (in this example) and being flexible. There are some dichotomies here;
1. Almost by definition, processes are not flexible.
2. (commonly) Organisations that have an abundance of processes do not take risks The negative impact of all of this is that there are companies that are inhibiting this creativity, dare I say "thinking outside of the box" because employees must adhere to process. Furthermore, IT projects take far longer than they need to to be delivered. To end, I am reminded of having the pleasure of seeing Brent Hoberman speak. He spoke about the implementation of Last Minute and how, due to the massive media hype, there was no option of not delivering on the publicised date. There were IT problems, bugs everywhere. No problem, go live anyway, have developers (probably lots of them) lined up ready to fix bugs on the fly and put the fixes live and react swiftly. Great, I wish I could have been part of the team. There must have been some "interesting" times for sure, but also immense satisfaction when success was realised. |
