coneblog

Benefits are the reason for any IT project. Too often, a benefits analysis is an important part of getting the money, but is soon forgotten in the day-to-day alligator wrestling that makes up most IT projects.

It would be nice to be able to look up from the mud occasionally, and to see some signposts that keep you pointed in the right direction. That is the ongoing project role of your benefits analysis.

My current project is a content management system and search solution for a medical publishing firm. The content, although currently on-line, is in silos which match the Publisher’s publication lines. The majority of revenue comes from subscriptions, with single issue sales contributing a small share of revenue. The goal of the project is to implement easy and effective cross-silo content search and access. The project is in the early going – requirements collection, scoping, and system-level architecture.

In my last entry, I related the importance that I place on project benefits, my efforts at collecting a comprehensive set of benefits statements, and my use of benefits analysis to smoke out the hot and not-so-hot issues in the organization. I asked the management team to rank the benefits list, and got a 95% response rate, after some cajoling. The results held some relief, and some surprises.

Expected was that three of the highest-rated potential benefits of the system were Client Retention, On-line Ease of Use, and Cross-sell of Subscriptions across publication lines. This confirms my understanding of the business, and that Management basically agrees about what is important.

Not unexpected was the low rating of benefits that were operational improvements, such as Reduction of Customer Support Effort, or Improved Internal Research Productivity. The organization sees this project as improving service and delivery to the Customer, with a subsequent positive impact on Sales. The Organization is not looking for productivity gains; quite the opposite. Personalized service and support are considered both a competitive advantage and a tradition.

I did find some unexpected results. First, the Increase Single Issue Sales benefit was ranked fairly low. I was all ready to justify the whole project on increased single issue sales. Although welcome, what the benefits ranking showed, however, is that single issue is not the main business model. Worse, it might cannibalize the subscription revenue. Second, my suspicions about the need to combine and streamline the several existing membership systems were reinforced by the high ranking of this boring operational benefit. Third, adding security features to content downloads in order to limit pass-on distribution is not a priority, as seen by its low ranking.

A close inspection of the Benefits signposts tells me a lot about what will make the project a success. I can take each of the top-rated benefits, and capture a checklist of three or four features or sub-systems necessary for their delivery. Take, for example the highly-ranked Cross-sell of Subscriptions benefit. To deliver increased cross-publication sales activity, I’d better make sure that the system logs every subscriber that looks at content in a different publication, and forwards that sales lead information to the sales team in the form of reporting. The feature set derived directly from the Benefits Analysis is a good check against the features that come out of use cases and vendor systems checklists.

So, if you are running an IT project, and you are “down in the implementation mud” week after week, make it a point to stick your head up and (re) analyze the proposed benefits of the project. Re-orient the project to the Benefits signposts. Make sure that you are implementing the features and components needed to deliver and document the big benefits.

If you don’t have access to the benefits case, find out who does. If you can’t find a benefits case, better find another project…