Chaos Theory

Where I work, Chaos isn’t a theory.  It’s a goddamn methodology.

What do I mean by that?

Look, if you’re going to change something, chances are there’s a Change Advisory Board (if you’re following something that resembles a lie about ITIL) and you should have given them the heads up.

Every company has an IT Support center or a Service Desk.  Something’s broken, you call some 20 something year old and ask “Yo, what the hell?”.  This division is the ass end of pain.  Inevitably, the company evolves their processes to the point that they’re thinking “Well, we did our best.  If anything goes wrong, Service Center or IT support will get this.”

What’s wrong with that?

Your company bought a bunch of software, usually Microsoft Windows, and these IT Support services were created in case this didn’t work out so well.  Maybe windows doesn’t boot or their login doesn’t work.  So, the powers that be, hired the workforce to cover that.  Every now and then, something unexpected happens and they dig in deep and absorb the difference by staying late or working fast/harder.

Here’s where it gores wrong.  They’re already giving 100% for first level support, then something unexpected happens and they give 110%.  Now some fool built this project where he promised (lied) to deliver something, but it’s not perfect and those little mistakes will have to be cleaned up as we go.  The problem here is that they’re already giving 110% too often for operational hiccups before this new thing was introduced.  Some nutcase signed off on being ok with this, but no extra staff were put on and, in most cases, the change hasn’t eased the load anywhere but changed the flavour of how you’d like to be fucked today.

I literally cannot count the number of times someone has tried to sneak their project delivery failure though on OPEX like this.  No, seriously.  Try to complain about it and someone will ask you to quantify it. At this point someone has to be pissed off enough or have enough free time to navigate the 20 crappy systems designed to measure this before they can even explain.

How Does This Happen?

Have you caught the lift to ground floor recently?  That guy making the change in the office over there…is there no one better who can help to make sure…did they engage the key stake holders (for the love of god, the damn IT support team is a key stake holder)?

I would love to operate the way my employer does.  “Yeah we upgraded all your computers to Debian Linux overnight.  Works fine.  If you don’t know how to mount a drive, that aint my problem, call IT Support.  See you next month, I’m on leave.”  Fuck everything about that.

The Short Version?

When something is changed, your support should not be absorbing extra work.  You should have consulted them before deciding what the best idea to go ahead with was.  Your change was supposed to leave no footprint and improve things.  Your overhead from the change should NEVER be more than the support cost.  If you’re running out of budget on your project, stop calling it a success then writing off the failure costs to support.  Subscription pain is for chumps and failures, you project manager wannabe.

0 comments on “Chaos TheoryAdd yours →

Leave a Reply

Your email address will not be published. Required fields are marked *