Imagine this. You have been asked to identify the requirements for the next major release of your healthcare IT product. So you spend the next month visiting customers, squeezing in cell phone conversations with product specialists and salespeople on the road during their brief layovers at airports, tearing technical support staff away from their phones for the low-down, and cornering executives in their offices for some fast paced banter. You begin to acquire nicnames around the office like "stalker" (as you hover outside their office) and begin hearing adjectives such as "relentless" and "pesky" mentioned in the context of your name. Basically, you end up talking with anyone and everyone about what they have heard, seen, smelled, or imagined as a problem that needs to be solved by your product - or even a brand new product.
After all this is through you get to sit down at your desk for awhile, let your frequent flyer accounts rest for a bit, and you begin writing these down as requirements. You end up with literally volumes of ideas, some good, some fair, and some out of the question. It's pretty easy to extract a set of valid requirements from this superset and eliminate the duds. But then that's where the hard choices begin. You have limited time, resources, and monesy so how do you decide which requirements to include in the first release and which to defer? You are scratching your head, because every contributor has said that their idea, problem, or requirment is important.
That's exactly where a technique called "Cost-Value Analysis" comes into play.
First, try to group your requirements into a limited number of higher level "themes" meaningful to all stakeholders. Try and keep the list down to no more than 10 themes, otherwise the task becomes too tedious and time consuming. Then do a pairwise comparison of both the value of each "theme" versus all the others and the cost of developing each "theme" versus all others.
The audience for the value comparison may be a group of sales people and product specialists or customers. I prefer to use internal folks for this since they have been exposed to many different customer situations and will therefore have more of a global view of the most valuable features. On the other hand, individual customers will focus on what is valuable for them specifically. You may want to use value comparison with customers as a validation step rather than a discovery step.
The audience for the cost comparison should include managers and team leads from the Product Development group including hardware and softwre development, QA, and Technical Writing. Optionally, leadership from other departments may be included as necessary. These folks should be able to provide rough estimates of the cost of developing each product "theme".
Stay tuned for Part II where I will discuss the actual method of the cost-value analysis and provide examples.
