A look at my prom picture from 1980 provides a wealth of information on how styles change over time, along with significant comic relief. Light brown suits? Fabrics not found in nature? And what’s with that tie? As we leave adolescence and join the workforce we quickly notice that even professional clothing styles seem to rotate through a never-ending series of changes, almost as if a system in New York was sending out random instructions to all clothing sales associates…“Three-button suits were last week, today it’s two-button again.”
Those with enough patience and a large closet can rest easy knowing that everything they have ever purchased will be in style again, if they wait long enough (well maybe not that particular tie.) Of course, this is style obsolescence, a variant of planned obsolescence, and its a big driver of product sales in our culture.
We experience this constant churn of products throughout our lives, from the consumer electronics that seem designed to fail right after the warranty expiration date, to the (some would say planned) inability to construct a road surface that will last more than one winter, thereby guaranteeing more road work for the next summer.
What does this have to do with IT?
As many teams are entering their strategic planning phase for 2010, evaluating and prioritizing the list of proposed investments for next year, I wonder:
- Are we being honest with ourselves in labeling these planned obsolescence events, and
- What percentage of a typical organization’s project portfolio would be more accurately categorized as “no-value-added churn?”
We have become accustomed, perhaps numb to the series of product and version changes from our IT vendors. A new software version is announced, making an old version obsolete, or unsupported in a few months. A merger or acquisition will mean that a critical piece of software is going away in a year. A vendor technology change will require a major re-write of code for your staff.
While in some cases we may benefit from new features found in these upgrades, in many others there is little tangible benefit, the change is unwelcome, and the timing poor. In a world of limited resources the reality is that these obsolescence projects will crowd out other investments that are tied to corporate goals or an important strategy.
For political purposes, it might be tempting to label these efforts as infrastructure or maintenance activities when they are presented to the organization for review, but is that really honest?
Most internal business customers would assume that items labeled infrastructure would be foundational in some sense, and are investments to make now that will materially support other investments in the future – in lower costs, greater efficiency, faster time-to-market, etc. In other cases these efforts are required for compliance, business continuity or security purposes. Does a forced software upgrade with little visible benefit to the organization fit into this category? Seems like a stretch.
Likewise, the label maintenance activity is problematic as well. While I might paint my house every few years to ensure that the siding remains effective against the elements (maintenance), a forced software upgrade by a vendor with little benefit to me seems more akin to a neighbor sand blasting the side of my house for kicks…
Is it honest to categorize obsolescence projects in this manner, if they bring little or no value to the organization? If we look at our project portfolios, what percentage of the total would be in this category?
The creative labeling of obsolescence projects may provide us with some cover from the need to directly confront our vendors, or answer to internal customers who will get much less than they desired from available IT resources. If the categorization was more honest, perhaps a label such as “no-value-added churn”, how would our behaviors change in representing these efforts internally, and how would it impact our vendor relationships?
How much of a factor is the continual upgrade cycle, either forced or voluntary, to your yearly planning process? How much weight does a vendor’s track record in this area play into your RFP process for new investments?
Like this post? Learn more about Scott Booher here.
{ 4 comments… read them below or add one }
Only if you buy into it.
We were on Windows 2000 until this year finally moving to XP for multi-media compatibilty (specifically Flash) reasons.
I’ve been around since dos3.3, looking forward to upgrades went out of the window a long time ago
The only interesting hardware innovation in recent times has been an interest in reduced power consumption / back to passive cooling.
Then again, I’m a guy with a 486 upgraded to P54C with 32Mb RAM as my email server.
This comment was originally posted on Hacker News
Good post, Scott. I wrote a similar piece on “roof projects”, as I call them: projects that are necessary, that consume resources, but provide no obvious direct value. (http://www.peterkretzman.com/2009/07/07/it-the-cio-and-the-business-need-for-roof-projects/)
Your piece delves more specificially into one important aspect of these: forced software upgrades. In the end, the project is either necessary to do (business continuity, avoidance of even wider impact if skipped, etc.) or it’s not. Keeping current on software is a wise thing to do in general (stability and security alone, not even counting new features), of course, within certain bounds of reason. Yet, I certainly wouldn’t label it maintenance, and I’d push back on the vendors hard, letting them know the internal impact of too-frequent upgrades.
And as always, as I contemplate new investments, I try to take into account how deeply I’m baking the potential vendor’s product into everything else–which is what would force my hand into an upgrade on their time schedule more than mine.
Great post on IT waste: http://bit.ly/G5BL7 #cio #it
This comment was originally posted on Twitter
“Those with enough patience and a large closet can rest easy knowing that everything they have ever purchased will be in style again, if they wait long enough (well maybe not that particular tie.) Of course, this is style obsolescence, a variant of planned obsolescence, and its a big driver of product sales in our culture.”
I am humorously reminded of a passage in “How to Survive Without a Salary” where Charles Long talks about wearing the same wool winter coat for many years. Every few years, he would get complimented on his wonderful coat. On the years in between, he was plied with lots of sympathy and hot coffee.
Not exactly IT related. Though I guess I do know some IT types who are generally resistant to the “ooh, shiny” phenomenon and stick with stuff that works reliably, if that makes sense. I suppose both things require the type of personality that cares less about public opinion/trends than functionality.
This comment was originally posted on Hacker News