For years, I have argued there is no such thing as an IT project. Instead, I contend all projects are "business projects" that may or may not involve information technology. (Though these days, in almost every enterprise and organization you would be hard-pressed to find a project that does not include a technology component.)

Before I state my case, let me acknowledge that this has not always been the case. I started working in IT over 30 years ago, before many companies even had IT organizations, or computers for that matter. When information technology was first introduced there was a chasm between the business and "those computer guys."  There was no confusion as to what constituted a business project and what constituted a data processing (remember that term?) project.

I am certain I don't have to convince you things are much different today. Technology has become ubiquitous if not unavoidable. And though it permeates every aspect of our lives, I still encounter organization after organization insisting there is a line or demarcation between IT and the business.

This issue is raised almost every time I deliver my Project and Portfolio Management presentation. I describe the most fundamental criteria for project selection and prioritization - its connection and contribution to business strategy. I tell my audiences if the project or investment request is not directly linked to strategy, don't do it! Somebody in the audience inevitably raises their hand and asks, "What about IT projects." I then tell them there is no such thing because all projects are business projects. The person will almost always immediately counter, "What about IT infrastructure projects?" They mention how their IT organizations find it near impossible to convince the business units they serve to undertake this upgrade or that conversion in the interest of staying current or avoiding obsolescence.  Even when faced with the loss of vendor support or spare parts availability they can't get the business to invest in the required upgrade or replacement.

This is my favorite example, because it gets to the heart of my contention. The "fault" in this example does not lie with the business' inability to understand and realize the need. That fault lies with IT's inability or neglect in regard to describing the need for and value of technology in business terms. Many if not most IT organizations cannot draw direct correlations between the technology they deploy and support and the business need it serves as well as the business value it delivers. To make matters even worse, many IT organizations can't adequately describe the lifecycle cost of their technologies, which make the latter problem practically impossible to solve.

Let's walk through a hypothetical scenario (that I would bet is not hypothetical at all):

IT is operating and maintaining hardware components that are about to become manufacturer discontinued.  The vendor has notified IT and given them their "drop-dead" date for support. (Let's set aside the fact that IT should have seen this coming and solved it before this circumstance arose. We will leave that to another post.) Almost every IT organization I know would either fund the required hardware migration with "IT dollars/budget" or attempt to get the business to fund the "IT infrastructure upgrade." Instead, the following should occur:

IT, understanding the correlation between the antiquated hardware and the services said technology provides to the business, identifies all affected Service Level Agreements (SLAs). IT then conducts the analysis to enable the following conversation with each of the affected business units/users:

"Here is your current SLA and associated service cost. If you don't invest in upgrade X, here is a timeline describing the degradation of your service, or, here is how much your service cost will increase over time to maintain your current SLA."

IT would then present the alternative to the inevitable service degradation or increase in service cost:

"Here is the cost of the new technology (implementation as well as full lifecycle) and the resulting new SLA(s)."

Now the ball is in the business' court and they have a business decision in regard to whether or not they should invest in new technology. They simply need to determine the business value of staying on the antiquated technology infrastructure or investing in the upgrade to maintain and in some cases improve their SLA. This is a business decision, ergo business project.

So why doesn't this type of conversation take place? Because very few IT organizations have the capability to put these technology discussions into business terms. They lack the systematic processes in place to collect, integrate, analyze and disseminate the data required to make these business decisions.

Now if every enterprise had sound IT Investment Governance and the associated IT Investment Portfolio Management, they would be able to obtain the decision-making data from their:

• IT Asset Portfolio
• IT Application Portfolio
• IT Resource Portfolio
• IT Demand Portfolio
• Enterprise Project and Program Portfolio
• IT Service Portfolio and associated SLAs
• IT Configuration Management Database

It is these governance mechanisms and constructs that enable enterprises to make direct and accurate correlations and associations between the technology they deploy and the business capability it enables, as well as the business value it provides. Until this in place, technology is left to dangle off to the side of the business because the data is not available to create the direct linkage to enable reasoned and rational decision-making in the use of said technology - business decisions. Without this governance and the data it provides, IT organizations will continue the struggle to acquire the funding required to do what they intuitively know is right because they can't produce the information to enable the business to make the right decision - for themselves.

So what do you think? Can you come up with an example of something that is truly an "IT project?"

Steve Romero, IT Governance Evangelist