The Project Portfolio Approach to SOA ROI

Erich Roch proposed an interesting approach to calculating SOA ROI, which he called the ‘portfolio based ROI calculation’. This approach “analyzes a set of candidate projects for ROI project by project and adds up the cumulative value of SOA across these projects.”I think approach is a great idea and I’d be keen to hear from anyone that has used this approach in practice – especially if you can help answer some of the questions below.

I recently read an excellent post by Erich Roch entitled SOA Costs and ROI. He proposed a very interesting method of calculating ROI which he called the “Portfolio Based ROI Calculation”. Actually he proposed a few interesting methods (so please read the whole post) but this one grabbed by attention.In a nutshell this approach:

“analyzes a set of candidate projects for ROI project by project and adds up the cumulative value of SOA across these projects. Part of IT’s strategic plan is often a project portfolio that has cleared corporate ROI hurdles and been approved by the organization. These projects are ideal candidates to analyze SOA ROI potential.”

Intuitively, this seems like a great approach to calculating ROI but I think a few questions need answering.

1.Is this approach still feasible if a portfolio of projects DOES NOT exist?
In my mind, the ideal scenario for employing this approach is when a portfolio of approved projects already exists. This is because:

  • Someone has already done the ‘leg work’ in terms of analysis, planning and costing. All that is left to do is evaluate how the use of SOA will improve the project ROI. This should be relatively easy to do. And quick.
  • You will in effect be proposing to take existing projects which are already attractive to the business (since they were approved) and demonstrate how they can be improved even more. More benefits. Same (or less) cost. Better ROI. This is as close to a ‘free lunch’ as you’re ever likely to get.

However, I think this approach loses its appeal when a portfolio does not exist. Sure we can create one, as Erich suggests, but creating an entire project portfolio just to calculate ROI seems like a lot of unnecessary work. It probably makes more sense to look at the key business drivers and strategic plans and propose ONE project that has an acceptable ROI, and concentrate on planning/costing that one.

2. Is this approach just for the “big boys”?
The vast majority of organisations only have one or two projects in the pipeline – probably not enough to calculate a compelling ROI. Strategic plans or roadmaps will exist but the candidate projects listed in these probably won’t be costed until just prior to them starting. So this approach probably only applies to very large organisations – who probably have a portfolio of fully planned/costed projects large enough to make a meaningful ROI calculation.

3. How are you going to convince project sponsors to alter their already approved plans?
If you want to revisit/alter projects have been approved and have “cleared corporate ROI hurdles” it may be difficult to answer the question foremost on the minds of project sponsors: “what’s in it for me?”. The project funding is available and the sponsor has publicly committed themselves to delivering the specified project outcomes by the completion date. They might be reluctant to tinker with something they have already committed to and the organisation is happy with.

4. How do you reconcile the uneven distribution of costs/benefits of the projects within the portfolio?
By taking a portfolio view you will be faced with an unequal distribution of costs/benefits for each project within the portfolio. For example, one project might benefit greatly from adopting an SOA approach and another one might suffer slightly. The cumulative effect to the organisation will be positive but how do you convince the sponsor of the second project to ‘suffer slightly’?

5. In practice how would you go about plugging the gaps in the portfolio?
Erich says:

“In addition, given key business drivers, there are often gaps in the project portfolio where a business need is not or can not be addressed due to technology barriers. These barriers may be eliminated using SOA. Such new projects that address strategic goals can be calculated for ROI based on corporate metrics and added to the SOA project portfolio for a total ROI calculation.”

So you might have a situation like this:

Project Gap

Depending on how big the gap is, you could have a situation where a project devised solely to fill the gap is not worthwhile. However, there may be a potential project that fills the gap and offers excellent ROI – but it may overlap other projects:

Project Gap Filled

As the diagram shows, the overlap might be minor in one project but significant in another. Either way, you would again have to alter existing/approved projects.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: