coneblog

For those of you just tuning in, I’m the PM for a project to install a content management system for a medical publisher. The Client has a number of different publications that have transitioned from paper to electronic over the past five years. It has become increasingly clear that customers want the ability to search electronically across several or all of the publications. The goal of the project is to make this not merely possible, but effective, and to turn content access into a competitive advantage.

Well, that seems pretty clear. So why am I spending so much time up front trying to nail down the benefits?

This is a relatively small project, so I’m where I like to be - in the thick of user and customer interviews, capturing requirements. I think I have a feel for the “real” needs of a business, and I enjoy helping to capture and document those needs. I’ve done 15+ interviews, with an ear for three things:

· Use cases – I ask for details of the “typical” user, their job title, their business situation, the query they would run, and the information they would want to retrieve. I think we are all clear that successful systems start with understanding the use cases – whether it’s A/R or fly-by-wire.

· Issues – a catch-all term for stuff – important or no. Here is where I carefully capture and document everyone’s pet peeve, favorite feature, annoyance, or beef. Why? The stakeholders need to feel like they have been heard. That favorite feature may not make it into release 1 or even release 21, but if they look they see it on the Issues list. This gains me credibility and builds trust.

· Benefits – I listen for potential benefits at every turn, and carefully capture and collate them. I’ve got eighteen on the list, so far. I’ve published the Benefits List back to the Users, and asked them to rank them in order of importance to them.

Why do I spend so much time on benefits? I’ve crafted many a cost-justification model in my time, and I must confess that most were exercises in backing into the needed Internal Rate of Return while maintaining as much dignity as possible. Benefits are very tough to quantify in many cases, even when they are clear to everyone. Is that why I am insisting that each interviewee review and rank the Benefits items by the middle of next week?

No, it’s because I use the proposed benefits list to smoke out hot issues as early as possible. Is there a creaky user registration process that frustrates everyone? A high ranking for improving the process tells me this. Who other than the VP Sales thinks that the real point of the system is to increase cross-sells across publications? How many think that the most important outcome is to reduce training and support costs? How highly does protection of intellectual property rank?

Because discussion of Benefits is “safe” (who doesn’t want benefits?), I can identify the hot issues without polarizing the group. I can then make sure that the issues are addressed as requirements, or explicitly ranked low, and not handled in the first release.

So, I use Benefits analysis to map the minefield, and avoid rolling out a Release One that doesn’t address the hidden, but key issue. But I will also do a quantified benefits model to make the Benefits as real as possible, and as a check against the very quantifiable costs of the system