How not to get what you want from IT

As much as any part of your company that supports the key prongs of the corporate mission (deliver product, sell the product, support the product), IT is constantly on the hook to deliver more and more.  As I’ve written before, expectations are deservedly high, and getting higher all the time.  And when expectations are so high, and the stakes for success equally so, the possibilities for disappointment are numerous.

No one wants to be disappointed, and no one wants to disappoint.  Here’s how you, the business stakeholder, can help yourself and the company: don’t fall into the common traps with IT that will likely lead to you not getting what you really want.

Here comes a David Letterman list of these traps, consisting of only three items.  There are, of course, a lot more traps than just three, but in my experience, these are the main ones.

3. Push hard on your IT organization to deliver on “trick plays”. Sorry for the sports metaphor, but it’s applicable.  With respect to IT, “trick plays” mean mission-critical, high-profile projects like constructing new web sites or instituting major new back office systems such as a data warehouse or a new CRM system.

A sports team that concentrates mostly on the razzle-dazzle plays (the flea flickers, the statues of liberty) usually lacks a lot of grounding in the fundamentals, at least eventually.  Sometimes this focus on the “trick plays” also becomes an excuse for the team to run wild and free: lots of “hail Mary” plays, some of which unfortunately sometimes even work, with all of it leading to the near-total abandonment of a disciplined approach.  In this kind of scenario, fundamentals only get some attention when (to continue the metaphor) a missed block ruins a trick play.

I am, you see, talking about blocking and tackling: executing the fundamentals for everyday success.  Recognize that a significant part of success in IT (and of great value to the company as a whole) consists of making sure there’s “no news,” so to speak: seamless upgrades and launches, no outages, no instabilities, no glitches, no long-standing bugs.  That’s what I mean by “no news”: it’s never the subject of corporate press releases, but it does take work; it can’t be taken for granted, and it can’t be allowed to be invisible and/or unvalued when budget and staffing comes under scrutiny.  If the subject of all management scrutiny on IT has to do with “trick plays”, you’ll implicitly push your IT staff to focus mostly on those, to the likely detriment of the everyday “keep the lights on” work.  You’ll run any number of trick plays, and as I said above, some may even work.  Even after the successes, you probably won’t clean up or do the necessary afterwork later, because you’ll have moved on to the next trick.  Eventually, the backlog of work left undone, or work done poorly, will catch up with you, and something, perhaps a lot of things, will come crumbling down.

As in most things, a more balanced approach will reap better and more consistent rewards.  You want to strike that sort of balance in what you shoot for as an organization: equal parts process improvement; bottleneck elimination (long, slogging work with little glamour to it); and methodical, planned, well-executed new systems work.

2. Keep telling IT that they need to be “results-oriented”. The trouble here is that in IT, quick “results” that appear to be good often aren’t.  They often carry with them untold amounts of what industry observers call “technical debt“:  basically, in your haste to deliver, you make decisions, or cut corners, for which you will pay down the road, and in spades.  A system is rolled out on time, but then has months of instability and heartache because, well, it wasn’t really ready.

It’s a well-known fact that any given two developers can differ in productivity by an order of magnitude, and that it’s really hard to tell the difference.  Nearly anyone can churn out a report, for example.  Without solid analysis and careful testing as part of its construction, that report might be missing key ingredients. It’ll produce numbers on a page, but those numbers could lack validity.  The fact that the programmer got it done by Friday is next to useless if the report causes you to make a seriously incorrect business decision.  “Results-oriented” has to be defined with some ingredient of long-term success, not just immediate gratification of the desire.  I’m certainly not arguing against results, but I am quite carefully distinguishing between apparent (and short-term) results and solid, bankable, long-term success.  With IT, it’s admittedly pretty difficult to tell the difference – in fact, telling the difference requires a depth and detail of involvement that business stakeholders are basically never going to have. To work through that dilemma, you’re going to need to find a solid IT executive and senior staff, with a grounded, sober, aggressive-yet-methodical approach towards striking the balance. And you’re going to need to empower and trust them.

Remember, management tends to get the behavior that it rewards. If you reward mostly the trick plays, or if you reward simple speed of delivery in the misguided notion that you’re being “results-oriented”, you’ll probably train the team exactly towards exhibiting those behaviors. What will you be giving up, though, and will you even know it when you see it?  Most importantly, will you know it before there’s a crisis that ensues?

I saw a sign on a roadside billboard once that stuck with me and that I’ve repeated to my staffs since then, because of its stellar applicability to IT strategy and projects: “Discipline is remembering what you really want.” What you really want, of course, is solid, dependable IT systems, run efficiently and reliably, with little fanfare.  You just need to remember that as you’re screaming for results on the latest trick play.  One tell-tale reminder of the need to remember what you really want often comes when a crisis erupts because something got badly botched in delivery (the flubbing of the trick play, so to speak) due to a failure to execute the fundamentals.

Next time, I’ll write about trap #1, the biggest trap of them all, the single most guaranteed way not to get what you want from your IT organization.  This is, in fact, the trap I have seen virtually every entity I’ve ever worked for fall into to some degree, some to the point of actually destroying the company.  Want to guess what it is before I write about it? Post a comment with your idea!

Lagniappe:

• Steve McConnell, “Productivity Variations Among Software Developers and Teams: The Origin of ’10x'”