Wednesday, February 25, 2009

Solving Tomorrow's Problems


In the I.T. world, we're all about customer service. Our goal is to solve problems quickly. Wade through those helpdesk tickets. Get people back on track and productive again.

Sometimes we lose sight of the real goal - avoiding the situations that cause the problems in the first place.

The Toyota Production System, teaches getting to the source of a problem by asking "Why?" five times. The thought is, that by following this chain of logic (how did we ever get to this point?) backwards, one can identify the source of the problem and remedy it.

For too long, some I.T. departments have been the "whipping boy" of their organizations - bearing the brunt of crappy Microsoft applications, victims of their own programming shortcomings and slaves to short term infrastructure decisions.

Truth is, for the most part, I.T. departments are playing defense. They act like the little boy who plugged the dyke with his fingers.

I think that realization hit some of my guys yesterday as we discussed a framework for administering reporting security. It became evident that in the course of quickly trying to
appease the security needs of individuals, we were undermining our ability to manage security "as a whole".

We were unnecessarily complicating our daily processes to serve the needs of a few.

And so, we tried a different tact.

Let's play offense.

Why don't we educate our management team on how we manage security and why it makes sense to do it that way. Let's involve our customers up front, in a decision making effort to develop a framework in which we can balance the need for information security with the level of effort to administer it.

Some I.T. folks undermine their own effectiveness by not even trying to engage their customers. "They'll never go for that!" or "There's always an exception to the rule." And so the status quo perpetuates the "cycle of doom".

I have the benefit of perspective. I don't have Helpdesk tickets assigned to me. I'm not neck deep solving time critical problems. So it's incumbent upon me to lead the charge with our user community to shed some light on how we do things and why and to invite them to participate in future policy and infrastructure framework decisions.

I call it solving tomorrow's problems.

If we spend one meeting per week talking and thinking strategically, we'll have a very successful department.