Faceted Feature Analysis

Adam Polansky — Tue, 10 Jul 2007 07:25:42 GMT

Everyone has ideas. Many of those ideas are held passionately. Some are brilliant, some are unrealistic and some are down-right stupid.

How can you make sense of ideas from multiple sources—formal requirements, brainstorm sessions, contextual inquiry, and input from the boss’s wife?
How do you entertain all ideas and still weed out the good stuff from the garbage without hurting someone’s feelings—especially when that someone signs your check?
How do you factor in real constraints and capabilities before these ideas become etched in stone?
How do you take in the different points of view that come from a programmers or business owners, not to mention the actual users of your product?
How do you do all these things and define project scope with some level of integrity that’s more than intuition or politics?

This article explains a process called “Faceted Feature Analysis.” It’s an exercise that I’ve been using for nearly 8 years on projects both large and small. The facets refer to three characterizing facets in any project: business value, ease of implementation, and user value.

Faceted Feature Analysis also uses three constraints that govern every project: cost, time, and quality.

By crossing the characterizing facets with constraints, you are combining the subjective needs of the project stakeholders with the objective constraints of the project in a way that ensures all points of view are fairly considered. It also ensures that a project requirement is not included or excluded simply because one person yelled louder than the others.

The process involves six steps:

Rating the Feature List
Creating a Flexibility Matrix
Mapping
Scoring
Sorting
Fine-Tuning

Step 1: Rating the Feature List

Compile a feature list from whatever sources are available. These typically include some sort of requirements documentation created by the business owner but can take in suggestions from a brainstorm session, ideas generated from contextual inquiry, competitive analysis, or other sources, formal or informal. As with brainstorming, there are no “bad” ideas at this point. This is important because, as you’ll see, the process is designed to weed out the impractical or ridiculous without any single person having to directly put it down.

Once the list is compiled, create a spreadsheet with the list of features and three adjoining columns: “Business Value,” “Technical Ease of Implementation,” and “User Value.” Ratings from 1-5 are assigned to each feature (1 being low). However, only the people who own each domain provide the ratings for that column: the business owners rate the Business Value column, the tech team rates the Technical Ease, and the user experience folks rate the User Value.

In this way, everybody is in a position to speak to their own area of expertise. Also, the rating of a particular feature isn’t as subject to the whims of the most charismatic or forceful person at the table, so you get a truer assessment of the general value of a feature.

Figure 1: Preliminary Ratings on a Feature List

Step 2: Creating a Flexibility Matrix

Flexibility matrices have been around for a while. Historically it has been a project management tool used to gain consensus on the constraints that govern a project. Every project is subject to three constraints: cost, time, and quality.

Figure 2: Blank Flexibility Matrix

To create a flexibility matrix, the project team needs to agree on which of the three has the least amount of flexibility associated with it. For example, if there are certain features and functions that absolutely must be developed, then quality is the least flexible constraint. Use an “X” to note it on the matrix.

Figure 3: Developing Flexibility Matrix

That leaves cost (the project has a finite budget of…) and time (the project must be completed by…). The result is a matrix similar to Figure 4.

Figure 4: Completed Flexibility Matrix

This doesn’t mean that cost is not important. It just means that later, if you had to decide whether or not to cut something from the project, the quality or time involved would be considered first.

h3. Step 3: Mapping

The project constraints map loosely to the value columns where:

Cost = Business Value
Time = Technical Ease
Quality = User Value

By making this association you can add weight to the ratings in any column. In this case quality is the least flexible constraint so you multiply by 3 all of the ratings in the User Value column. As time is the next least flexible constraint, the ratings in the Technical Ease column are weighted by a factor of 2 and the ratings in the Business Value column are not weighted, because cost is the most flexible of the three constraints.

Figure 5: Mapping Flexibility Matrix to Ratings

Step 4: Scoring

Simply add up the weighted ratings into the Total column.

Figure 6: Scored Ratings

Step 5: Sorting

This is where the magic happens! Sort the features according to their scores. Invariably, those features with the highest aggregated values rise to the top and those with the lowest values sink to the bottom.

Step 6: Fine-Tuning

What about the stuff in the middle? After you’ve sorted the list, you can usually find some natural cut-off point in the list where everything above the line constitutes a complete solution and everything below the line is either a feature for another day, a variation on a feature that made the cut, or something that might be best forgotten.

The question now is whether or not that natural cut-off point aligns with the constraints. In the case of quality there’s no need for further analysis because you’ve effectively said “regardless of cost or time, we need to have the features we’ve identified here.” In the case of cost or time, it is sometimes necessary to get estimates from the team on the hours needed for each feature. That way you can associate cost or time with each feature to negotiate the cut-off point by “horse-trading” with items of similar value above and below the line.

Figure 7: Effort Estimate

When the negotiating is done, you may discover one of three things: * You have defined the scope within the constraints * The constraints need to be revisited and the cut-off line needs to move * The constraints cannot be revisited and the project should not proceed (an extreme outcome)

The Benefits

Increases objectivity. You are leveraging individual bias to generate unbiased feature rankings. This occurs because participants are limited to rating features only from the perspective of their areas of expertise and using overriding, agreed-upon constraints, rather than personal influence, as the means of emphasis.

Assists in project planning. Scope and estimates provide the basis for a traditional project Gantt chart or the backlog that will feed an Agile iteration plan

Mitigates churn. This process greatly reduces the second-guessing during development that may occur when features have not been pre-qualified. There are fewer surprises downstream.

Minimizes politics. A feature rises or drops in the list on its own merit as it relates to the project constraints, not because anyone knocked it down or ram-rodded it to the top. (This can still happen but it’s harder to do without obviously and publicly disregarding the point of the exercise.)

A Few Thoughts By Way of Addenda

Understand that this process is not the way but simply a way to qualify a project’s scope.

The process is true enough to make sense out of a lot of information but not airtight in its logic because, as I mentioned, the associations between the values and constraints are loose and there is still usually some negotiation involved in the fine tuning phase. This means it is still possible for someone with influence to trump the findings in a particular exercise, based on their own agendas.

That said, by not being too prescriptive, the process allows for a great deal of flexibility. For instance, the checkout process on an e-commerce site is a feature on its own but it also has a number of sub-features like “review your purchase,” “enter shipping information,” or “confirm purchase.” So, while the team agrees that you need a checkout function, by rating the sub-features individually you’ll weed out some things for later development.

In your matrix, you can also include additional columns for more specific descriptions of proposed new features or columns for other metadata such as data source or legal mandate. Such additional information helps characterize the proposed features, making them easier to rate.

In my experience, this process has proven itself over and over as easy to do, easy for everyone to understand. It doesn’t take long and it yields both material and intangible value. However you apply it, you have a way to take a granular look at a lot of information and determine earlier rather than later whether or not something should be built, rather than if it could be built. That will save you and everyone else the downstream heartache that comes in the form of increased cost, increased time, and lack of quality. It also eases that boat ride because everyone participates in a way that brings their needs into the equation, making the outcome much more digestible and less likely to be challenged.

After all, if you can help create great products on time and under budget you’ll be a hit at parties and that’s why we do this sort of work, isn’t it?

Boxes and Arrows: Stories by Adam Polansky