“Could you please stop saying there’s no such thing as an IT project?” a reader politely asked. “When I have switches/routers/servers that are out of support from their vendors and need to be replaced with no business changes I have to call these IT projects.”
I get this a lot, and understand why folks on the IT infrastructure side of things might find the phrase irritating.
And I agree that projects related to IT infrastructure, properly executed, result in no visible business change.
But (you did know “but” was hanging in the air, didn’t you?) … but, these projects actually do result in significant business change.
It’s risk prevention. These projects reduce the likelihood of bad things happening to the business — bad things like not being able to license and run software that’s essential to operating the business; to purchase and use hardware that’s compatible with strategic applications, and so on.
It’s important for business executives to recognize this category of business change project, if for no other reason that none of us want a recurrence of what happened to IT’s reputation following our successful prevention of Y2K fiascoes. Remember? Everyone outside IT decided nothing important or interesting had happened, and that’s if they didn’t conclude we were just making the whole thing up.
Successful prevention is, we discovered, indistinguishable from the absence of risk. So we need to put a spotlight on the business risks we’re preventing so everyone recognizes our successes when we have them.
Not to mention the need for everyone to be willing to fund them.
Which leads to a quick segue to IT architecture, which, depending on the exact framework and source, divides the IT stack into information systems architecture, subdivided into applications and data; and technology architecture, subdivided into platforms, infrastructure, and facilities.
Switches and routers, along with everything else related to networking are infrastructure. With the exception of performance engineering, infrastructure changes ought to be invisible to everyone other than the IT infrastructure team responsible for their care and feeding.
Servers, though, belong to the platform sub-layer, along with operating systems, virtualization technology, development environments, database management systems … all of the stuff needed to build, integrate, and run the applications that are so highly visible to the rest of the business.
The teams responsible for platform updates know from painful experience that while in theory layered architectures insulate business users from platform changes, in fact it often turns out that:
- Code written for one version of a development environment won’t run in the new version.
- The vendors of licensed COTS applications haven’t finished adapting their software to make it compatible with the latest OS or DBMS version.
- Especially in the case of cloud migrations, which frequently lead to platform, infrastructure, and facilities changes, performance engineering becomes a major challenge. And as everyone who has ever worked in IT infrastructure management knows, poor application performance is terribly, terribly visible to the business.
Et cetera.
Not that these platform update challenges are always problems. They can also be opportunities, for clearing out the applications underbrush. Part of the protocol for platform updates is making sure all application “owners” (really, stewards) aren’t just informed of the change but are actively involved in the regression testing and remediation needed to make sure the platform change doesn’t break anything.
The opportunity: If nobody as the steward for a particular application, retiring it shouldn’t be a problem.
On a related topic, regular readers will recall the only IT infrastructure metric that matters is the Invisibility Index. Its logic: Nobody notices the IT infrastructure unless and until something goes wrong.
Invisibility = success. Being noticed = failure.
Something else regular readers will recognize is that Total Cost of Ownership (TCO) is a dreadful metric, violating at least three of the 7 C’s of good metrics. TCO isn’t consistent, complete, or on a continuum: It doesn’t always go one way when things improve and the other when they deteriorate; it measures costs but not benefits; and it has no defined scale, so there’s no way to determine whether a given product’s TCO is good or bad.
But perhaps we should introduce a related metric. Call it TCI — the Total Cost of Invisibility. It’s how much of its operating budget a business needs to devote so those responsible for the IT infrastructure can continue to keep it invisible.
They’ll keep it invisible by running what aren’t IT projects. But are quite technical nonetheless.
Bob,
IT infrastructure “projects” feel like projects to us because:
1) They consume resources
2) They consume budgets
3) They require coordination, testing, contingency plans
4) They exist over an elapsed length of time – usually longer than a week and many times shorter than a year. Although client device/PC refresh projects exceed a year or two.
5) They are usually one-off happenings that can affect the way that systems interact.
6) There is usually documentation to upgrade and old hardware to dispose of.
7) There is usually inter-departmental involvement – Facilities, HR, Accounting, Security, Infection Control, department managers, and business executives plus others.
Sometimes IT Infrastructure Projects are the sacrificial lambs, so that the IT can trim their annual budgets. At one employer, we added several of these that we knew would get pulled out due to the CIO’s “Acceptable Risks” tolerance and the need to start with an inflated budget that could be cut.
Some of these IT Infrastructure Projects could be forecasted and others happened because of vendor’s obsoleting equipment, problems with integrating newer systems or new clients/partners that somehow were not included in due diligence, etc.
I know this is just a rambling post of thoughts that popped up as I read through the article.
Cheers!
Dan J
Not sure where you’re going with this. Of course infrastructure projects are projects. As you say, they have a beginning and an end, and deliver a tangible work product.
My point is that companies shouldn’t think of them as IT projects. They’re business risk-reduction projects.
We are in agreement. Count my meandering reflections as supporting evidence.
My current employer does not put many of the Infrastructure projects on the Company “Project Board”. But the application development projects do go there because of their impact.
I like TCO–Total Cost of Ownership. I feel like it’s a much more accurate economic model of price. Granted, it’s just price, not usefulness, but as long as you know that, then it’s a highly useful metric, much better than manufacturers suggested retail price.
Most folks say their house cost them whatever the amount listed on the closing documents. But that’s not true. The total cost of the house to you is the grand total of all PITI (principal, interest, taxes, insurance) payments for 30 years or until the house is paid off, as well as the down payment. You can subtract taxes and insurance if you want to compute actual price of the house.
Drupal is a “free” (open-source) software to manage library content. It takes a staff of 6-8 people to maintain the “free” software anybody can download and install.
Just because a measurement is used incorrectly by management (are there any measures that cannot be misconstrued?) doesn’t mean it’s a bad measurement. TCO for software includes a lot more than the sales price of the executable.
It appears you apply different criteria when deciding whether a metric is useful or not. I find TCO useless for the reasons stated. To make it concrete: In a given organization, PCs will have a given TCO. Let’s say it’s $6,000. It decides training is a waste of time, staff, and budget, and so educating employees in how to use PCs is cut from the budget. TCO is now $5,000. It’s lower, but not better.
A different organization invests in collaboration tools, and educating employees in their use. TCO is now $7,000. Employee effectiveness is increased by a bunch, but that isn’t measured.
One more company: It buys PropTronic PCs – the injection-molded plastic ones furniture dealers put on the desks they’re selling. TCO is $0.
TCO just doesn’t tell you anything useful.
“Successful prevention is indistinguishable from the absence of risk.”
Gonna cross-stitch that on a pillow.