How to sell SOAs and Web services projects using ROI

To get a Web services or ROI project approved, you're most likely going to have to prove it financial benefits. But how can you do that before you've even launched the project? Maja Tibbling, Enterprise Architect with Con-Way Transportation Services, has long experience in getting projects approved, and offers hard-won advice on how to use ROI to make your case.

Long gone are the days when you could walk into the CFO's office and ask for a blank check for your technology projects because everyone knew that technology pays off in the long term. Today, technology has to pay its way, and that's no different for Web services and Service Oriented Architecture (SOA) projects than it is for anything else.

Return on investment (ROI) measurements, common in IT operations circles, have crept into the SOA space. In my last column, I covered where you can expect to find an ROI and give you several examples of projects that have paid off big. In this column, I'll give advice on how to sell your project, using ROI.

Where To Begin

If you want to know how to sell a project using ROI, it's best to turn to the pros – to the people who have actually been in the trenches and had to do it time and time again. So to get advice, I spoke with Maja Tibbling, Enterprise Architect with Con-Way Transportation Services, a $2.6 billion transportation and logistics company operating in the U.S., Canada and Mexico. Ms. Tibbling has been a pioneer in the use of SOA and Web services and is experienced in gauging ROI.

Tibbling says that you can expect two types of ROI from Web services or SOA — IT ROI and business value ROI. IT ROI is a familiar concept. It's the ROI an IT department can expect because of greater productivity thanks to the ability to reuse components and cut down on development overhead. Qualitative ROI comes from the ability to launch services and products not possible before, or to bring them to market more quickly. Typically, qualitative ROI is far greater than IT ROI, she says.

Tibbling warns that initially you most likely won't seen an IT ROI and in fact may even see extra expenses because of the need for new tools, training and staff working with an unfamiliar technology. Over time, the IT ROI can be substantial, but that typically takes years, after a library of reusable components and modules has been built up.

Because of this, she that when presenting ROI estimates for a project beware of promising any IT-side ROI in the early years. In fact, she says, it's best to be honest and to say that IT costs may initially increase, although these will be initially offset by business-side ROI.

"Qualitative benefits are where you need to look for ROI," she says. "If you try to cost-justify it in IT savings, you'll just be making up numbers because SOAs are more costly initially."

What this means, she says, is that you'll need to delve far more deeply into the business side of the house than you might normally — and this may mean a new way of looking at the role of IT staffers.

"It's important that IT staff truly understand the business," she says. "They can't be just versed in technology; they have to know the business as well."

Think Long Term

Tibbling adds that when presenting the project, "You also need to make clear that there will be no surprises. You have to explain that it may cost extra at first, but that it will pay off in the long term."

To do that, she says, you should avoid presenting a short-term business case. Instead present a business case and ROI for the longer term – a minimum of two years, and up to five years. The first year of a project may have a negative ROI because it's only after you have reusable modules that the ROI kicks in. So the longer the term of the plan you can present, the better. This is one more reason why the IT staff needs to understand the business and where it is heading — they'll need to know where the business plans to be in the next two to five years if they are going to present a long-term business plan and ROI.

She also suggests that you look for ways to cut down on development costs, in particular to "beware of over-engineering. Don't think you need to analyze the whole world."

To that end, she recommends that you leverage everything that you can instead of trying to write everything from scratch. You should use existing business logic and legacy systems, and incorporate them as services. Doing this will reduce initial costs and help sell the project. More than that, it will help ensure that you don't make the project so complicated that you never manage to get it off the ground.

The Bottom Line

The bottom line for presenting ROI? Be honest that costs may initially increase rather than decrease. Present a long-term business plan and ROI because the savings add up in the later years of the project, not the initial years. Make sure that your staff is as well-versed in the business as they are in technology so that you can stress the business ROI as well as the IT ROI for a project.

Do all that, Tibbling says, and you'll be well on your way to getting project approval.

About the Author

Preston Gralla is an expert on Web services and the author of more than 30 books, including How the Internet Works. He can be reached at preston@gralla.com.






This was first published in January 2006
This Content Component encountered an error

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide

SearchWinDevelopment

Close