Functional Choice Modeling: A New Approach to Prioritizing User Requirements

Updated: September 24, 2010

Business analysts typically use systematic approaches to collect, document, and prioritize functional capabilities for new or upgraded IT systems. Despite these methods, failure to fully understand user requirements remains a significant cause of failed, or under-achieving, IT projects.

Traditional methods for gathering business requirements include:

• Stakeholder interviews: The identified stakeholders -- both executive sponsors and users of the proposed system -- are interviewed to get their perspectives on what functionality is needed.
• Joint Requirements Development (JRD) Sessions: Bringing teams together from disparate lines of business is important in order to identify those requirements that have cross-functional implications.
• Contract-style requirement lists: Creating a shopping list of functional requirements. Great because it establishes a service level between the business and engineering teams but weak in that it typically creates hundreds of pages of requirements that are not only difficult to prioritize but loses important context, such as cross-functional implications.
• Prototyping: Mockups enable users to "touch and feel" how the application would perform in their hands but it doesn't address the need to uncover and prioritize the essential elements of a system so that engineers understand which functionality they should focus on.
• Use cases: Similar to Agile-based User Stories, Use cases are detailed scenarios that demonstrate how the system being built would address a potential business need. These are typically authored by both technical and business team members thus eliminating some of the vocabulary issues that crop up when engineers try to communicate with business folk.

There are more arrows in the Analyst's quiver but suffice it to say that these are some of the most common (and useful) techniques to gather end user requirements. However, there is a fundamental weakness in all of them. And that is, what a person says they want in a product or application and the relative importance of that function against another function is never clearly identified. What an end user says they want versus what they actually want in a system and what trade-offs in functionality they are willing to accept is rarely defined. And that my friends is the key to truly effective functional prioritization.

There is something you can do though to mitigate if not eliminate this mismatch between what users say they want vs. what they actually want. And that is to implement Functional Choice Modeling.

Functional Choice modeling, based on traditional Choice Modeling, is the "science of demand." It has been used extensively to align products and services with market desires since the 1960's (beginning with the Bay Area Transit System) but many businesses are just now learning about it and its effectiveness in taking a product to market.

Choice Models are typically used in two ways: (1) to predict demand in the market for a product or service and (2) to understand what features consumers truly care about in a product, service or offer to drive a higher degree of demand for those solutions. Internally, the same approach can and should be used to uncover what your end users truly care about in a system. Functional Choice Modeling enables you to identify and prioritize the critical functional elements that your end users not only require but care about the most. And it will enable you to identify which features should be rolled out when - what do they need immediately, what is important but can wait and what is a nice to have.

Examples of Choice and Functional Choice Modeling. A Choice Model was deployed with consumers in China to understand what features were most important to them when considering the purchase of a home technology product. When consumers were asked directly to rank important product features, they overstated the importance of price. But when they were asked via a choice model, in which they had to trade off price with other product features, the importance of price dropped dramatically and the true features of the product -- namely the brand and a subset of product features rose to the top. In a standard functional ranking survey, 57% had named price as one of the top three reasons to choose this product but when taken through a choice model, price was the least important attribute (click for graphic).

When consumers are forced into a real world situation of balancing trade-off's among product features in a simulated buying exercise, what you get is much more accurate picture of what features a consumer really cares about and what they are willing to pay for.

The same approach can be easily implemented to uncover what your internal end users truly care about in a system.

Functional Choice Modeling is completed in three steps:

1. Survey stakeholders to find out what functional capabilities they care about
2. From this survey one then identifies key functional preferences
3. Based on those preferences, users are then taken thru "what if" scenarios which systematically alter the proposed application functionality and asking the stakeholders to choose which capability set they prefer

In doing so, Functional Choice Modeling predicts actual preferences for system capabilities not stated preferences.

Tools of the Trade: The Choice Card. In Step 3 above you will use a choice card to compare the functional configurations of various systems - these can be actual functional capabilities as well as items such as deployment time or intuitiveness of the interface. The internal end user then selects which feature set they desire - in other words, which configuration of functions and deployment time they prefer.

Let's say that your CIO has decided to develop an HRM solution in-house (not advisable) but an easy example for the sake of argument. In your initial survey your analyst has uncovered that applicant tracking, employee on-boarding, reporting, payroll integration and deployment time were the critical functions required. Obviously there are more but for the sake of this example let's focus on just these features.

Your users will examine the Choice Card closely (click for graphic) and then select which configuration of features they prefer. In this way, they are actually forced to trade off on functionality and your analyst will get an accurate picture of what capabilities they want and in what time frame they want them.

Once the Choice Card exercise is complete, one would then use a conjoint analysis to analyze and make sense of the data. What will emerge are clear preferences in feature sets and individual features that the end user truly wants, enabling your team to clearly and accurately prioritize which functional capabilities to focus on first.