IT, the CIO, and the business need for “roof projects”

Have you ever had to replace the roof of your house? It costs lots of money, and there’s no visible or immediate benefit. Metaphorically, that situation comes up astonishingly often in IT organizations that struggle with how to get “roof projects” prioritized and worked on.  “Roof projects” (a term of my coinage, as far as I know, in this respect) in a company consist of facilities or systems that need upgrading or major work to continue functioning, even though that work may not provide immediate business-visible value.  Just like the roof on a house, some systems shouldn’t wait until they experience failure before they are attended to.

Understanding the notion of “roof project” seems obvious, even common sense, yet it proves necessary to “sell” it constantly within an organization, even to people who understand it intellectually.  IT roof projects are often also quite difficult to communicate the value of, since they rest not only on abstract assessments of risk, but also involve technical details that business people find arcane.  The conundrum then becomes how to “sell” such business-lifeblood-affecting projects to a skeptical clientele who mostly just wants new functionality, and who collectively yawn at IT technobabble (to them) like “middleware” and “protocol.” Everything has to be business-driven in the end, I firmly believe, but it’s a catch-22: users tend to drive only what they understand and which benefits them directly. Neglected or grossly deferred maintenance/upkeep (which is what happens if you never prioritize and do the roof projects) mounts up over the years, until eventually a company can be completely paralyzed. Picture a roof that should have been repaired 10 years ago; would you want to live in that house?

Let’s look at a couple of concrete IT examples I’ve had to deal with:

  • I became the first CTO at an internet firm that had grown higgledy-piggledy for a number of years, both organically and through acquisition. As a result, their key product used two different database management systems, requiring administrator expertise and developer finesse in both vendors’ products.  Moreover, support and maintenance had been dropped a couple of years before on one of the DBMS systems, in some odd combination of wishful thinking and hubris. When I came on board, the only person with any knowledge of the nuances of the lesser-used DBMS was the Director of Technical Operations, who served as the de facto DBA when issues arose, and would even call a friend at the DBMS vendor to get back door support from time to time. I kid you not.

Fixing this completely untenable situation required data conversion as well as software development resources, changing the mechanisms used for pulling content from the database.  The project wasn’t enormously difficult from a technical point of view, but it would be time-consuming, and it would of course delay work on new features.  This was a roof project, in other words: the end result wouldn’t change anything that was user-visible, but it would reduce risk and improve overall system maintainability, by quite a bit.

  • I took over as CIO at a company where there was no consistency between development environments, staging, and test. Their processes had been quite weak in terms of code migration from environment to environment, so no one knew for certain exactly what was in a particular environment. In fact, the only viable way to create a new environment was to clone the binaries from the old one, then test, then apply tweaks (but not propagate those tweaks back to the original environment, lest that one break!) Sounds ridiculous, but there it was.  QA in particular was tremendously affected by this situation, since they couldn’t tell if the bugs they were chasing while testing a new release were environment artifacts or actual software errors.

Fixing this fiasco was unquestionably necessary in order to release quality software at all predictably, not to mention in order to expand capabilities by adding new environments. To fix it would take development, architecture, and test resources, but it without doubt had business value. Yet, it was, again, a roof project: it provided no clearly identifiable new capability other than “things will be easier” and “the company will be at much less risk.”

All chosen projects represent opportunity costs: when you do one, it means you no longer have those resources available to work on another at the same time. Internal customers in these two instances had great difficulty accepting the delay of new functionality work, and would have preferred that we had left the old roof in place, so to speak.  My least favorite adage that is often heard at times like this: “if it ain’t broke, don’t fix it.”  To which I have been known to retort, “if the car is still running, why change the oil?”

In other words, roof projects need the business to have (rare) long-term vision to truly SEE the benefits, especially if risk and/or future capability is involved. Business folks, for understandable and solid reasons such as this quarter’s all-important financial results, are typically pressured to favor implementing measures where the short-term revenue is fairly clear. By nature, they aren’t as interested in something that simply promises “easier, better, less risky” work down the road.

In a perfect world, all projects would have agreement from everyone across the organization. But hey, the world’s not perfect, and everyone has their own pet areas.  IT tends to deal with areas that are both  arcane and which involve subjective risk assessments, not certainties. And we in IT circles sometimes tend to imagine a world where everything is of course facts-based, and hence we believe that project selection will be (as one professional recently tweeted to me) “totally simple.”  But in the real world, there are biases and politics, just to name two factors that influence the selection of projects.  It is absolutely critical that the CIO/CTO be the chief voice at the senior management table, when it comes to educating and advocating the judicious undertaking of “roof projects” when necessary. Without that active voice, it’s common to see the roof work continue to be deferred, year after year.

In a future post, I’ll expand further on this topic, talking more about the difficulties of and approaches for project prioritization in general.

Comments

  1. Couldn’t agree more.

    There’s a universal truth that any IT system is a true reflection of the process and organization that built it. Complex process == poor system == complexity and brittleness.

    You might be working on an insurance system where each product has slight, subtle but profound variations on how it processes lapsing, premium calcuations, acceptance rules, etc etc.

    As you point out – only strong leadership to drive simplicity, cohesion and consistency within the business will allow you to build an IT system that exhibits these qualities.

Trackbacks

  1. […] CTO/CIO perspectives Intensely practical tips on information technology, by Peter Kretzman « IT, the CIO, and the business need for “roof projects” […]

  2. […] short-term impact on the business stakeholders of the company, yet are critical to do.  See my recent post on “roof […]

  3. […] IT, the CIO, and the business need for “roof projects” by Peter Kretzman on CTO/CIO perspectives […]

  4. […] up visibly and strongly to ensure that “roof projects” are given appropriate attention and priority. Build for the day after tomorrow rather than just […]

  5. […] spending should fit into one of these key imperatives.  If it does not, it goes in the “Roof Project” category, a termed coined by Peter Kretzman.  Roof projects are just that – projects […]

  6. […] can range from pushing out the latest version of Office, to a “forklift upgrade” or other “roof project”, to even HR events like the company picnic. There are certainly plentiful scenarios where these are […]

  7. […] its overall results. There’s often no immediately obvious payback to this undertaking: it’s a roof project, in essence. To the extent that refactoring isn’t done (no time, no inclination, no recognition […]

Speak Your Mind

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.