Ways to get client to provide information about prioritization

Question

When gathering requirements often clients are looking to build feature a,b,c,d,f - z. They get almost too excited about features. They almost become feature hoarders.

They want all those features. But it's hard to elicit from them what is of the greatest importance to them. They often seem to communicate this and this is important to them.

Often, a common mistake of ours is that we discover what's important to them only when the project is near mid-phase.

Are there any exercises one could do or techniques of organization to understand prioritization of their requests? Or what ways do you go about to do this before the project gets started?

I'm looking for an answer that can be either beyond what type of project management method: agile, waterfall, etc.

Answer 1

This is a common situation and it is often hard for clients to make a choice on requirements (understandably if someone comes up with requirements, (s)he is unlikely to then say they're not important). I would suggest the following:

• Make prioritization part of requirements definition: When your clients define requirements, get them to also define their business value (e.g. what will this enable? how will it impact our ability to execute a business process?). Focus on tangible benefits rather than loose improvements (eg. "will allow to reduce data entry errors by 90%" vs "better data quality"). By doing this upfront as part of requirements definition, you will have information that will directly support the prioritization process.
• Define a prioritization process and rules (in agreement with your client): this can be a scoring method or a simple grading process (eg. "nice-to-have", "future release", "important", "critical"). Work with your client (with representatives who are empowered to make decisions) and facilitate the evaluation by providing helpful information such as business benefits and estimated effort.
• Guide and support your client in evaluating the importance of requirements: Whilst your client is best placed to understand the impact of a feature on the business, they often need help in putting things in perspective. Business Analysts are typically well-placed to support this process, and the PM can help facilitating the exercise (and should be able to challenge the client when necessary).
• Define your governance model and identify an arbitrator (your ultimate decision-maker): You may end up in situations where you are stuck (no one will give in, too many "critical" items, etc.), so it's important to have one person (from the client) who's empowered to make the last call.
• Remain flexible and offer options: downgrading a requirement doesn't mean that it will never be done, and a way to deal with many nice-to-have features is to look at a potential implementation further down the line (rather than a "now or never" approach). This takes clients' needs into consideration, whilst providing the opportunity to get some lessons learnt with the first set of baseline requirements: this will help the team re-assess these requirements with better hindsight and see how they actually fit into a working solution.
• Get the base requirements list signed-off. This will mitigate the risks of conflicts half-way through the project. Your prioritization process should be used throughout the project and be integrated with your change management process.

Answer 2

Facilitate a prioritization workshop with a small team, around five to eight impacted stakeholders, that represent well the user demographics. Conduct several workshops if the user population is huge.

Design a scoring method with which the workshop attendees agree and a method of capturing the data, e.g., majority, consensus, etc. Present the results and facilitate a promotion/demotion using the same rules. You need to have the stakeholders agree that the results of this exercise become your prioritized requirements baseline.

I have used both a choice analysis, which is not much more than scored six to 10 weighted criteria for each alternative, and a value/cost/risk analysis, with value decomposed to both benefit and penalty. Both methods have worked well and produce a rather credible prioritized list.

Answer 3

It is not often that I will recommend reading a book on eliciting requirement from customers, as it is a task that can only be learned by truly doing. In a little different direction from the other answers have you considered a planning game? They are generally less formalized than something that in title has been called a workshop and you "see" the business value that customers place on features as the game is played vs an arbitrary number that they assigned to feature x & y.

Here is a good summary, but I would also recommend buying and reading the book Innovation Games: Creating Breakthrough Products Through Collaborative Play.