The flip side of common myths: how some are perpetuated by IT

As promised, I’m going to follow up on my last post (“Optimism, resilience, stamina: the make-up of the CTO/CIO“), covering the myths IT deals with on a regular basis, by talking about its flip side: the ways that IT itself can unfortunately perpetuate or contribute to some of the myths I’ve been discussing.

Here’s a point-by-point discussion of some of the things I talked about last time, the discouraging statements you frequently hear from stakeholders.

• what have you (IT) done for us lately;

Well, what’s your communication plan? What do people hear about? Not only do you need to explicitly declare victory on major projects to a broad audience, but you need to collect and publish metrics, as a service organization, that show a) how and what you’re doing; and b) that you care how you’re doing, and are constantly scrubbing it all for continuous improvement. I recommend surveying your internal customers at least twice a year, but I’ll have more to say on that in a later post.

• what do you (IT as a whole) do all day;

Hearing this one often indicates a lack of understanding about the maintenance substrata of keeping systems going, “keeping the lights on,” as it were. It’s critical, and actually a bit rare, to have (especially) senior management understand that a reasonable percentage of your staff and time goes toward supporting and maintaining systems that are already built and operating. It’s equally critical that you initiate (and tout) projects that are designed to lowering the level of effort required to support that burden; i.e., you’ve got to be constantly challenging yourselves to automate, eliminate, and streamline, because more gets added to that maintenance pile each and every year.

IT contributes to this lack of understanding, often, by not visibly and purposefully separating out sustainment activity from new project work. If you don’t do that, it all blurs together, and then you get hit on both ends: new project work seems to take way too long (in part because of the hidden burden of ongoing sustainment of other systems, pulling your people away), and maintenance is regarded as spotty (because of your people going into crisis “must deliver” mode at sporadic intervals on new project work).

• we’ve been asking for that system for years now and not gotten it;

This one can be especially rankling, because of course stakeholders can and do ask for far more things (systems, improvements, features, fixes) than could ever be done. Again, hearing this complaint often indicates a breakdown in what needs to be a regular, ingrained process and communication pattern. How does IT contribute to causing the complaint? If you don’t have a clear work initiation process, or a crystal-clear, public prioritization mechanism with regularly published results, you will always be subject to hearing this complaint. The only way really to combat it is to make sure that stakeholders, not you, are the principal decision-makers behind what gets worked on. You have to steer them into grappling with the thorny issues of “too many demands, not enough resources, hence we need to choose.” Then, if they haven’t gotten something, it’s generally because they themselves haven’t prioritized working on it to the top of the heap.

• how can that be so hard? Why can’t you just …

This is a complaint that erupts out of the dangerous mixture of lack of knowledge and high need/frustration. How does IT contribute to its prevalence? Well, do you have a Software Development Lifecycle (SDLC) in place that you can point to? Is it a hopelessly opaque and voluminous set of documents, or is there a business-level management summary of what IT does, how it does it, and why that defined approach leads to better long-term results all around? Combating this frequent complaint can only happen through that kind of ongoing education, at all levels. Don’t assume anyone “gets it”, even if they “got it” last time. You have to keep delivering the message.

• “at my last company we did that in just [names an absurdly short amount of time] and it worked really well”

This one sometimes feels almost impossible to combat. Nostalgia and selective memory appear to be common. Yet, when you drill into these anecdotal gardens of Eden, it’s almost invariably true that the claim of “we did that” doesn’t actually come close to what you need to do here and now, and almost always was done (in order to accomplish the whole job, anyway) over a much longer time frame than what’s being touted, and/or with vastly greater resources. I know; I’ve actually made phone calls delving into these claims, and I’ve never had a single one pan out to be close to what was idealistically described or remembered.

Again, the take-away point here: turning around some of these perceptions is forever bound to be an ongoing struggle, and may take years of trust building if the starting environment has badly deteriorated. But it can, and must, be done, if you wish to achieve true success as well as perceived success.