How should we 'Elicit Customer Needs?'

The CMMI asks us to "elicit needs." Can you give some examples of how to perform this practice?

Sometimes customers believe they are giving you their "requirements" when if fact they are presenting you with a list of needs. A requirement is a specific thing (clear, traceable, testable, etc....) and often the "requirements spec" we received has few of these things. RD.SP1.1 starts with "Elicit Needs" and asks us to perform a process to identify the needs from which the requirements are developed.

There are as many ways to "elicit" a customer need as there are companies. Each one I've worked with has their own approach and style, but there are some similar threads out there that I can offer as examples.

- Facilitated sessions with the customers and engineering/requirements folks where the needs are mapped out and debated using a simple white board approach. Make sure to bring your camera! And yes, photos can be placed under configuration control (and can "count" towards evidence, if managed and used appropriately).

- Brain storming sessions that are structured using a mind-mapping" approach and a tool like MindJet's MindManager (a personal favorite). Assign different "branches" of the map to appropriate stakeholders in breakout sessions and then have an integration party at the end! It helps to have someone adept at the tool "play it" in real-time as people are debating.- Graphical approaches using white boards, swim lanes, or graphical tools like iRise (a great tool for this by the way). Different colored pens and someone who can draw helps here - the high-end consultancies use real artists for this (as opposed to those of us who are not!)

- Prioritization workshops where the customer relates to the engineering staff what is most important to them. What can they live without? This subtractive approach is good for reducing scope.

- A detailed requirements spec sent from customer to supplier in a bidding process. This is very common in the manufacturing world, and is almost always incomplete. But, it's the way of the world for thousands of engineers. The thing to remember here is, your work is not done just because they send you a 400 page document - it may not have a single "need" in it!

- In an agile setting, prototypes, sample screens and reports, or "Spikes," an early working model of the most important features requested, so the customer can agree on what they want. This method is iterative of course, because the customer rarely knows how to articulate what they really want.All of these, and others, can (and should) be iterative. In other words, it's more than one session, or spike, and is a back and forth negotiation with the client.

Interpreted literally, the CMMI tells us to "elicit needs" (as if you can just go off and do some elicitin') but remember that the actual effort could be days, weeks, or months in duration, and could happen repeatedly throughout the lifecycle of an overall program - resulting in many releases of the system.

Have fun!

www.broadswordsolutions.com