Bad news for traditional techies: There are no IT projects

A tech initiative can't just deliver software; it needs to improve revenue, cost, or risk for the business -- or there's no point

Bad news: The organization you work for no longer has any IT projects. You can go home now.

It's true, except for the you-can-go-home-now part -- and the bad-news part. You can't go home now, and the fact that more and more companies have figured there are no IT projects is instead very good news.

[ Also on InfoWorld.com: Get Bob Lewis's continuing IT management wisdom in his Advice Line blog and newsletter. | Find out why running IT as a business is a train wreck waiting to happen. ]

There are no IT projects because every project is about improving the business. Otherwise, what's the point? Delivering new software that keeps everything the same simply won't provide much of a return.

IT projects deliver software. Turning it into business benefits is someone else's problem, starting with what constitutes "business benefits." There are only three uses any project can contribute to: revenue, cost, and risk.

Yes, it's that simple. If the sponsor can't explain how revenue will go up, costs will go down, or risks will decrease because of the project, it should go away. There are, after all, plenty of other good ideas floating around that contribute to one or more of the big three, waiting to get the go-ahead.

What's that, you say? How about projects that improve customer service? We all know customer service is a good thing. Shouldn't the company invest in it?

Answer: It depends on the company. Companies don't do good customer service because they're fine, moral, upstanding members of society. Instead, they do it well because customers will come back and perhaps bring their friends. If customers return, the cost of sales will dip because the expense of persuading an existing customer to stay is, according to most estimates, between one-fifth and one-tenth the cost of acquiring a new customer from scratch. If customers bring their friends with them, revenue will increase.

Better customer service can improve the risk picture as well, because every customer who likes you is one fewer user likely to start a your-company-sucks campaign on Facebook.

All of this makes a compelling case for investing in customer service -- for some companies.

But take a company you might have heard of: eBay. From what I hear, eBay makes a tidy profit. It does a lot of business. It has one other fascinating characteristic: No matter how hard you search its website, you won't find a telephone number to call if you're having a problem.

This doesn't make eBay a bad company. Given its success, it's hard to criticize its decision, either. The folks running it have decided the cost of providing that level of customer service would be higher than any benefit it might get from the improved customer retention and referrals.

So there are no IT projects, only projects that in some way, shape, or form are intended to increase revenue, decrease costs, or improve the company's risk profile.

Seems elementary, doesn't it? You'd think the point wouldn't be at all controversial.

But it is. I can prove it. A lot of companies still think they have IT projects, which means a lot of companies have project teams who think their work is done when the software is up and running, satisfies the requirements, and meets the specifications.

Here's another test. Take a look at your company's list of approved projects. If your company is like most, they'll have names like "SAP implementation" or "warehouse management system" or "merchandising system." See the common thread? They're named after the information technology.

Names have enormous power; they shape how people think. Even if the actual purpose of putting in a warehouse management system is to reduce operating costs while increasing shipping accuracy, when time gets tight and the heat is on, the project team is likely to narrow its focus to laserlike intensity, with the goal of installing the software -- plain vanilla, please -- to make the deadline and stay within the budget.

Just one problem: Installing the system plain vanilla might keep IT's operating costs down, but it probably won't do much to help warehouse management in the same regard. But that's OK because the Warehouse Management System project was an IT project, and it succeeded; the information technology got installed, had few defects, and runs efficiently.

How about IT infrastructure upgrades? Glad you asked. They fit this thought process just fine. They're risk mitigation efforts, as everyone in IT knows and hopes everyone else trusts them about, because explaining why obsolete technology that works fine constitutes a business risk is very tedious.

In the face of this logic, some companies will continue to charter IT projects -- those that are finished when the software is done. That's because of the worst problem with IT projects: They're good for the sponsor and good for the developers. No, that isn't a joke.

If you're a canny business executive, there's little more important for advancing your career than promoting bold, important change to lead your organization into the future. It's good for your image in the executive suite, gives you visibility to the board of directors, and looks great on your resume. Actually implementing bold, important change, on the other hand, is seriously risky, because the change you're boldly leading might not pan out as hoped.

So long as it's theoretical, you're OK because nobody will know if you were right or not. But once the change actually happens, that's another story. If it turns out you took the company in a bad direction, your career is toast.

Developers have an entirely different problem. They're pinball players -- they need the free game so that they can keep playing, but in order to do so, they have to deliver software that satisfies the requirements and meets the specifications.

So they do, and they're safe, as long as it doesn't actually get put into production. Putting software into production is risky for the developers because it could turn out something is seriously wrong with it.

Luckily for them, it won't happen. The business executive is more likely to happily declare it to be completely useless. The developers can then happily complain that the spec was wrong. The business analyst, caught like a chestnut in a nutcracker, points out that the business executive had no real idea of what he wanted the software to do.

Thus, the business executive gets to maintain his reputation as a bold, visionary leader, safe in the knowledge that his plans will never be tested, while the developers maintain their reputations as people who can persuade the computer to sing, dance, and play the tuba.

The business analyst? We all know business executives are clueless about technology, so there's no beef in that regard. Ultimately, everyone wins -- except the business, which invested in an IT project and didn't end up with any benefit.

Really, it got what it deserved, because -- all together now -- for enlightened businesses, there are no IT projects.

This story, "Bad news for traditional techies: There are no IT projects," was originally published at InfoWorld.com. Read more of Bob Lewis's Advice Line blog on InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.

Mobile Security Insider: iOS vs. Android vs. BlackBerry vs. Windows Phone
Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies