Monday, March 1, 2010

Failure Induced Change

I’ve started a few discussions on the concept – Built for Change, and although I've promised myself to be more positive, I can’t help but to share the following observations and comments.

When the organization is ruled by “Failure Induced Change”, the situation perpetuates like a bad case of dermatitis. For example, during a failure; catastrophic or otherwise the organization will be hard pressed for system up time. The solution will more than likely be a hack job/workaround versus a well designed and tested solution.

However, there’s just insufficient time, too much stress and too many customers to keep happy – excuses that deafens the voice of logic.

Hence we wait and pray that the duck tape and glue-ons last long enough until the actual solution comes in. Now comes the moment of truth; this is where THE BUSINESS should have no hesitation in putting in place the intended solution scheduled 3-4 weeks prior. The question is – Do you have the guts to go through with it?

Imagine that you have to make this decision when another highly sensitive production system now tethers at oblivion but IT comes to you and requests, “We seriously need some if not all of the parts in flight to solve this new disaster because the previous system is already “stabilized”.

What’s the solution to this?

With all sincerity – BITE THE BULLET! There’s really no two ways about it.
Without which the subsequent downtime ricochets like aftershocks of the recent Chilean quake creating just as much damage if not more than the first outage. The organization just cannot afford another hack job.

I am not purporting that the team takes its own sweet time designing and carving out reams of architectural documentation and philosophical debates between options 1 through 13. There’s really:-

  1. Option A) - The best solution that’ll last 3 years at least (barring more sticky situations like an impending upgrade – usually politically motivated)
  2. Option B) - The second best option; what are the business compromising on and can we afford these compromises.

Work around the clock if you have to, because the sleep time invested here will be well worth it. I like to end with a quote from Dean Smith, a consultant that I had the privilege to work with despite his hard ass approach to implementation ~ paraphrased.

“When I do build a system, I want to make sure that I am not phoned in the middle of my sleep for the next 3 years at least...”

p/s: The quote may sound contradictory, but I’ll explain next time. Cheers.

No comments:

Post a Comment