On Business Priorities

Raise your hand if you've been told "this application is very important and critical to the business and absolutely must work."  Now raise your hand if you've ever called them out on that bunk.  Maybe I'm just a little more cynical or blunt about these things, or maybe I'm a bit of an ass, but I think it's important that business users be made aware of the level of bunk often found in this statement when it comes to their applications.

For all the times I've heard similar statements made, they can all fit neatly into two distinct categories of "highest priority" (notwithstanding the fact that constantly pushing the panic button does not build a constructive sense of urgency):

1. Real business priority
2. "Squeaky wheel" priority

The former is simple.  There are systems that are critical to a business' core functions.  At my company, for example, our core database is of the utmost importance.  Millions of dollars have been spent, teams of people surround and maintain it at all times, there are detailed policies and procedures that have been created by experts and have stood against rigorous testing, etc.  It's a business priority, and the business knows it.

The latter, however, is nonsense.  And it's nonsense that affects the business' bottom line often without the business even knowing it.  It wastes everyone's time and effort (and, ultimately, the business' money) all because someone somewhere is being a "squeaky wheel" and demanding attention.  More often than not, we as support personnel are simply told to just go along with the demands.  That is, after all, part of our job.  (And that's fine, just don't complain to me when the real work suffers as a result.)

But let's talk for a minute on what this "priority" really boils down to.  This business user has an application that was created for a specific business purpose.  For this user (and this user alone) this application is critical.  They need it in order to do their job.  And their job relates to other business functions which are also critical and so on and so on (which this user will gladly explain in an email, since justifying their job is clearly more important than describing the actual problem).

But if this application is so critical to the business, why then was it not given any design or architectural attention?  Well, that's "just how we do things here."  Our development group isn't so much a "team" as it is an assortment of people who work individually on their own projects and support their own projects until they eventually leave and everyone else inherits their mess.  But that's another story for another time.  If the application is important to the business, then why was the business not willing to put any effort into creating it.  It was given to the cheapest "resource" (person) and done as quickly as possible.  That sounds pretty low-priority to me.

But the user thinks otherwise.  The fact that the business as a whole consciously decided that this application was not important enough to merit any effort and that the resulting application was designed to fail doesn't matter.  Evidence and historical data are unimportant if that wheel can get squeaky enough.  Now we're into a political battle, not software support.  Now we get to play a game that managers and children alike play.  Complain loud enough and you will be heard.  (It's amazing what business professionals have in common with my two small children.)

It gets especially interesting when the user begins invoking names and business terms as part of their squeaking.  Toss around the term "HR" or cc: an executive and the squeaking gets louder.  Sorry, but I don't believe in magic.  Stringing together words of power to form an incantation that will rouse and frighten others into doing your bidding is, I'm sorry to say, witchcraft.  Voodoo.  And it has no place in a professional environment.

So what ends up happening?  Amid all my ranting and complaining (sorry about that) it all comes down to one simple truth.  All we're going to do for that user is placate them.  We're going to apply some quick fix to get them up and running again.  Not even get them up and running, but just get them to shut up.  No effort, no thought, no expertise at all.  Just do whatever it takes to stop the wheel from squeaking.  Again, does this sound like a business priority?

So why are we maintaining this charade?  This charade costs money.  It directly affects our bottom line.  We know that user will be back, we know that application will fail again.  It all comes down to a very simple business decision...

Is this application a priority or not?

While this post was a whole lot whinier and rant-ier than my last, the message is essentially the same.  Care about your software.  As a business (either a whole company or just a department or even a single user, whatever entity "owns" a particular application), if a piece of software is critical to your business then put forth the effort required to make sure it meets your needs.

I've said it before and I'll say it again... If the person who actually cares about this application doesn't really care about it, why should we?