No, its not the new anti-matter, or maybe it is.
I’ve watched IT organizations now for 26 years. The sadness I feel is that I’ve continuously seen the same downward spiral:
- Failures are reacted to as a only that – failures. And failures cannot be tolerated.
- Someone gets blamed because of course it is always a human error
- Focus is put solely on slowing things down because if we slow down, of course things will get better (right?) More time can be spent on analyzing every action to make sure it never happens again.
- More steps are added to processes to make things less prone to failure – usually manual, because of course humans can imbue greater success and less failure into IT systems (remember the old joke: there are two problems in every computer problem, and the first is blaming the computer)
- Changes, features and maintenance slow down because it requires more manual intervention to get them in place
- Management, sales, and all that revenue focus pushes for those changes, those features, those requirements and usually overrides the slow down – but for features that are not ready, not tested because we’re still working on the old changes from months prior
- The CIO and IT Managers fight with sales and management because they are asking too much
- CIO and IT Managers quit, or are fired because someone always loses that battle.
I dub this cycle anti-velocity. It is the failure of IT organizations to create velocity. Organizations reduce their movement to a crawl – frozen and frustrated, unable to move forward and certainly unable to move back. The freeze themselves in fear, in mis-guided notion of what it takes to correct failures. “Slow things down so we can study them more.” “Find out who did it and fire their *ss!” “We never test this stuff enough – we need weeks to do this right.” “This requires full review of all test documentation during the Change Control Meeting with all documentation brought to the meeting where everyone must attend.” (Yes, the last one is a real procedure for Change Control that I’ve encountered.)
Now, lets talk about what builds velocity, or the ability to move forward at a constant and ever growing speed.
- Find the root cause – the honest the root cause. What really caused the failure, and be honest and open about it. Track the causes and know where they come from. Look for patterns in the analyses.
- Don’t believe that rote assumptions will tell you where to fix it – use the data you collect and the root cause analysis to really identify patterns. I have watched companies assume that certain activities are the reason they have failures because they have been schooled to think this way – without ever questioning, “How would I know if my assumption was wrong, how could I test it?”
- Do not go on witch hunt, and do not go about the task of root causes analysis looking for someone to hang. Remember that failures are where you learn where you need to improve. If you fire someone, who says his replacement is going to be any better?
- Identify ways to prevent the failure that do not slow down the process. Remember the death spiral of anti-velocity above? Remember that you want to do everything to avoid it. Slow downs are the beginning of that death spiral.
- I’ll give one caveat allowing for slow-downs: if your slow down is temporary to get a correction to your process in place that allows you to go faster, be more accurate, and be more resilient, then it is okay…because you are gaining a longer term velocity for the sake of what I would call a hiccup.
- Build solutions that eradicate the faults, the errors and anti-velocity in your environment. You will learn over time how to do this – through a process of continuous improvement.
- We want to eradicate the faults, bad practices and build an environment that can sustain itself through human errors. (Because lets face it, we are the first problem in every computer problem.)
I become quite excited when I see velocity and a process that is fluid and working to speed itself. The greatest excitement is that their change processes improve dramatically. They process more changes, they do so with a higher success rate of implementation, and recover from failed implementations because every process has failures. I have watched four different organizations recover from anti-velocity. I have seen two who knew how to create velocity, and we were able to build powerful sets of controls that did nothing to slow that velocity.
Unfortunately I have seen just as many mired in their anti-velocity and unwilling to emerge. The believe in big-bang changes – long cycles of review, backlogs of changes due to failures, blocking pre-requisite implementations stuck in review, and long cycles to get through a cumbersome process.
But then, from what I’ve heard, companies that have anti-velocity in IT, have this tendency to gather anti-velocity in their business as well….hmmmm…..
