“Hot stove” lessons in IT, part I

Regular readers here have certainly noticed the recurring nature of many of my posts: “things about IT that should be obvious, but clearly aren’t.”  Each week, as I set about writing on my chosen topic, it often strikes me that what I have to say is anything but new or radical; rather, it seems to embody fundamental, well-known practices and underpinnings that should be, if not incredibly obvious, at least quite familiar to anyone who’s spent much time in or around IT.  Yet, as I reflect on my actual experiences, I realize anew that I’ve spent much of my career working up and down the executive and worker chain to absorb and impart these basic principles again and again.

So here comes more of the same.  In fact, this dual post encapsulates a lot of what I’ve written about on this blog for the last year: lessons learned and lessons still learnable about IT for the people who work in it and the people who have to deal with it.  In other words, I should hasten to say, these are not only IT management lessons, but lessons related to development, operations, QA, and project management: in other words, the whole spectrum. 

As I’ve observed before, IT is hard. In fact, it’s so hard that it seems most people have to learn certain core lessons by themselves.  It seems like everyone needs to burn his or her own hand on the hot stove.  So here are some of the glowing redhot stove elements that I’ve watched make fingers (including mine, for I’m not immune either from learning some things the hard way) sizzle over the years.  I’ll start here in part I with lessons particular to management, and next time will cover similar lessons/myths relating to other IT areas.

Management “hot stove” lessons/myths:

• If the project is late, can’t we put more people on it. I’m compelled to put this old chestnut first, since it’s (ironically) both the most discussed AND the most frequently still observed meme out there of this nature.  Fred Brooks wrote a whole book on it, The Mythical Man-Month, which should be required (and recurring) reading for every executive who deals with technology.  The same mindset that gravitates towards putting more people on a late project often proves to be equally seducible by the luster of offshoring, or by the notion that simply doubling the number of people will be able to turn out a product in half the time originally estimated.  Everyone in the trenches of IT, at nearly any level, intuitively recognizes the folly and futility of what essentially amounts here to equating software development with ditch digging. The very suggestion (i.e., that elapsed time will simply equal the total level of effort divided by any arbitrary number of resources, where having more resources automatically results in faster product delivery) is, these days, at about the same level of thinking as an executive wondering about the efficiency of double-entry bookkeeping (what a waste of time to enter everything twice, eh?).
• If we outsource a lot of things, then we can do a lot more as an organization. However, people embracing this myth seldom show a good understanding of what it takes (resource-wise, as well as the hit to organizational focus) to select and manage all this outsourced work, much less integrate its results.  Many IT organizations don’t even have the necessary technical foundation/infrastructure in place to allow outsourcing to happen effectively at all.  Outsourcing is indeed a worthy goal and a fine choice, when chosen and planned for prudently, but it doesn’t come for free, and tradeoffs must be discussed and understood up front when these choices are made.
• If there are bugs in the software, it’s because QA didn’t do their job well.  Bugs, however, are a fact of life in software development.  Mitigating them (in quantity and impact and risk) is the issue, not eliminating them.  Almost always, it tends to be schedule pressure and/or resource constraints (both caused, typically, by management impatience and/or inadequate understanding of cause and effect) that have facilitated the inclusion of an unacceptable level of bugs in the released product.
• IT should work on everything that the users say they need; the truly necessary stuff will sift to the top. There’s no real need for messy and time-consuming prioritization efforts. This may be the most dangerous myth and need-to-learn-lesson of all these management-related items.  Prioritization needs to happen on purpose, not by accident or by mere dint of IT championship.  It’s the most important thing that an organization does, at least the organizations that manage to avoid hopeless fragmentation of resources and effort.  Purposeful portfolio management, with heavy stakeholder participation and sponsorship, is the only really effective way of dealing with the firehose that is constantly trained at IT’s eyeball.  Tying this to the items at the top: consider that if you want to do more, one very viable approach is to take on less, and to make sure that what you actually take on are truly the top priorities (the “vital few”) for the company.

One tiny anecdote to frame this discussion: I saw one company where literally dozens of IT contractors were brought in at short notice and with little planning, due to the unfortunately entrenched belief that adding more resources would of course result in faster delivery of badly needed product.  After only a month or two of having these workers on board, the short-term operational results of the company caused budgets to suddenly tighten, and all the contractors were let go.  Due to ramp-up and inadequate knowledge transfer, almost no value was gained to the company from what equated to several person-years of cost/effort.  See the first two lessons/myths above.  People’s fingers came away badly burned on that one, you can be sure.

So again, I’m not just bashing management here as I discuss these “hot stove” lessons.  Stay tuned for next time, when I talk about the myths and lessons-always-needing-relearning that I’ve seen within the IT ranks themselves.