MANAGEMENTSPEAK: Give the users exactly what they ask for.
TRANSLATION: Don't think. Just code.
-- IS Survivalist David Cohen gave us exactly what we asked for: an excellent and very useful translation.
AS I MATURE (or maybe just age) I increasingly divide the world into things-that-are-my-problem and things-that-aren't-my-problem.
Earning enough to pay my share of the mortgage and groceries is my problem. Figuring out how other people should live their
lives isn't my problem.
Keeping close track of what isn't my problem has proved to be a wonderful stress reducer. Sadly, while this has worked very
well for me personally, it isn't an attitude that scales very well. Whether the subject is foreign policy or running an IT
organization, any number of not-my-problem subjects turn into my-problem subjects with distressing but predictable frequency.
Foreign policy I generally leave to others, at least until a round or two of some other conversational lubricant increases
my perspicuity and persuasiveness. How to run IT is another matter.
And when you run IT, trying to make anything that happens in the enterprise not-your-problem is suicidal. One way or another,
it all ends up on your desk.
Boiled down to its essentials, traditional IT is composed of operations, which runs the applications already in place; and
programming, which develops, installs, customizes, integrates, and maintains business applications. IT operations is, of course,
entirely about supporting the rest of the business. As for programming ...
If there ever was such a thing as a programming project, there isn't anymore. Projects are always about business change.
And while business change requires information technology, it's merely a necessary condition for success, not a sufficient
one. If nobody thinks through how the business should operate differently, new technology just won't accomplish very much.
Which leaves IT with two choices: Include how the business should operate differently among the things-that-are-my-problem,
or become a disinterested supplier to the rest of the business, content to deliver software that on paper adheres to the specifications
regardless of whether it actually does something important.
Just an opinion: You're better off choosing the former, largely because if you don't, business change won't happen and you'll
get the blame no matter what really went wrong. And you should. "The software worked. It isn't our fault if they didn't use
it" is, after all, a pretty flaccid excuse.
Business change only happens is if someone is responsible for making it happen. IT is where the entire company's operations
meet in one place.
So if IT doesn't take responsibility for business change, who will?
E-mail
Printer Friendly
Reprints
(InfoWorld) - In the litigious world we live in, deploying a unified communications platform in your enterprise could...
