Here's the situation: You've documented some of your current processes, created your organisation chart, got a small team together to define your future state and now you're pushing them to finish this because you have an ERP solution waiting to be implemented with your processes. Congratulations you've fallen into the trap of "Pay me now, Pay me more later". This trap occurs when you try to short-cut the whole process definition stage. You'll recognise this when you hear phrases such as "Why do we need a current state?", or "Let's define what we want our organisation to look like then define the processes"This won't work and will cause issues later on. These issues will cost far more to fix than they would have cost to do right in the first place. If you’re in an organisation that works on the basis of “We don’t have time to do it right just now, but we will have time to fix it all later” then you’ve probably fallen into this trap already.
Luckily this is not a unique situation. Many companies do this driven by the fact that the longer they spend on process work the longer the project will take (although that's not true)
How to escape this trap!
1) Recognise that time spent now will be time saved later.
If you can stop yourself getting too far down this path, it is always easier to understand that time spent getting things right now will dramatically cut your implementation schedule later in the project. Imagine you had defined and recruited people into an organisation chart that had been created prior to defining your process. What then happens when your process definition effectively redefines your organisation chart? Apart from the inconvenience of having to potentially retrain and re-assign your workforce, what are the legal implications of defining and recruiting for a specific structure only to change it once the employees have been engaged?
2) Stop work and go back and do it right - use the right tools, use the right sequence.
This is probably the hardest thing to do, but it is also the best thing to do. In a project which has gone down this path it is always going to be easier to continue as you are - the project will appear to be moving forward and progress will be being made. The difficult part is trying to convince your project lead to, effectively, stop what they are doing and go back to re-work things. The ROI at this stage will appear to be minimal and you will get push-back from everyone. But just remember the mantra "Pay me now or pay me much more later". If your project is willing to make that risk and has consciously made the decision to continue then there is nothing that can be done except stand back and watch the carnage develop
So now you know what to do if you find yourself trying to short cut the process. Remember it is ALWAYS a case of "Pay me now, or pay me much more later"
How can you stop yourself going there again?
I’ve written elsewhere that one of the most important factors in the success of a project is the people and change side of things. Falling into the ‘pay me now or pay me much more later’ trap is a symptom of this kind of issue. Generally a project which is under time pressure (or budgetary pressure) will start to cut corners to make deadlines or budgets. One of the first things that will go is the people side of change. Look out for the following symptoms of ‘Pay me now or Pay me much more later’ thinking.
• Folks will be ‘told’ what needs to be done rather than encouraged to engage in a change (regardless of whether it is mandatory or not).
• The second thing to go is appropriate process definition. As-is states will be bypassed, work will be done quickly without the underlying process infrastructure to make it work correctly (Organisations charts will be created based on what the senior management think things should look like rather than on the structure that will best support the process, for example)
• Progress will seem to be being made but on a very shaky foundation.
If you see any of these symptoms in your project it would make sense to stop and ask yourself “Are we putting the cart before the horse and trying to do work which will, ultimately need to be redone?” If this is the case than you probably need to stop and think about the impact of this.
Summary
It seems to be quite prevalent in process-based projects, but no doubt it happens in other projects as well. The cult of doing things which show progress on a project plan rather than doing the right foundational things to facilitate a sturdy project is causing issues across the whole of the IT world (and, no doubt, across the non-IT world too). A few observations and some focused thinking will right that particular ship and head-off some serious costs later on in your project
Reminder: 'The Perfect Process Project' is still available. Don't miss the chance to get this valuable insight into how to make business processes work for you.
Click this link and follow the instructions to get this book.
All information is Copyright (C) G Comerford
See related info below
