April 8, 2010
Priority & Feasibility Plot
Overview
This is a fast and simple technique for developing agreement around organizational priorities. It was adapted from a technique presented by Adaptive Path’s Henning Fischer at UX Intensive.
Materials & Requirements
- Pre-printed worksheets listing items under consideration and two blanks next to each item, one labeled priority and one labeled feasibility.
- Pens and/or pencils.
Steps
- In advance, prepare the worksheets. Be sure to put in the instructions that the total for each column must equal the number of items multiplied by 3, for example if there are 5 items, the total of each column should be 15.
- Hand out the worksheets.
- Instruct meeting attendees to circle the number between 1 and 5 for each item that represents their perceived priority for that item, and the their opinion on the feasibility for that item. Make it clear that the total for each column, the total must be 3 multiplied by the number of items.Some participants may feel like they are technically unqualified to evaluate feasibility; tell them to circle what feels right based on how complex they feel it would be to do: how much staff or budget it would require, for example.
- Collect the worksheets and enter them into a spreadsheet.
Analysis
Plot individual, sub group, and full group averages on charts where the Y axis represents the priority, and the X axis represents the feasibility. The items in the upper right are more “must haves” and/or problems that would be easy to solve quickly. The items in the middle area are things that are either more difficult or less of a priority, and may be good longer term goals. Items in the lower left are things that are good candidates for reevaluation or reconsideration. Compare variations in different sub-groups or between different individuals to identify topics for additional focus and further discussion.
7 Comments
August 5, 2010
Only people developing the functionality should be estimating or commenting on feasibility. Not business people or designers that are not au fait with technology. Otherwise the data you’re collecting is skewed from the start.
August 5, 2010
I should point out that I only mean feasibility in the “can it be built” way. If it’s feasibility in the “do we have enough resources” or “do we have enough money to tool up to this level of complexity” then non-developers chip in
August 5, 2010
Agreed. The point of the exercise is to look at feasibility from many perspectives – development difficulty, costs, resources, content creation. Whatever the perspective of the participant is, that’s how they should evaluate it. The combined value of those perspectives is more valuable than one particular practice, especially for stimulating discussion when two perspectives are at odds (e.g. it’s hard to build, but we do have the resources to do it, etc.)
August 5, 2010
This is an interesting exercise, but I’m having trouble thinking of ways to incorporate it. At our agency we usually work like this:
-Account manager has initial meetings with client. They set a scope for the project together.
-A quote is offered to the client (based on their needed features, and the time needed is est. by the team)
-The client accepts the quote
-Project manager meets with client, and goes through the scope deeper and more thorough
-Project manager presents thorough brief to team
-Team finds solutions and build the website
The priority is something the client should set (and to a degree in consultation with the agency), but the feasability can only be set by us, not the client. So who are participating in this?
It’s usable for internal projects, but I can’t really place it in our workflow :/
August 5, 2010
Hi Adam. In my experience this has been beneficial in larger organizations with multiple departments, where the resolution of competing priorities is part of the scope/process. At our agency, the pitch and hire process is roughly similar to what you describe, but when we work with larger web sites, it’s often part of the scope of work to determine a road map for the client that may extend well beyond our involvement. Using this methodology helps us to design that road map.
August 24, 2010
We use a variation of this exercise and it works really well when getting people to reach agreement on priorities. As an aside, I find that it really helps to elicit the differences in perceived priority / feasibility, especially when people have very different views of the same idea.
Understanding the thinking behind the answer reduces conflict later on (more so than the end decision I think). This exercise can also help to show where there are multiple ways of executing the same idea which are worth exploring.
August 24, 2010
To your point about perceived differences, I wonder if a simple comparison of averages by departmental association, or if you were a math whiz, looking at the standard deviation of the average to say “this is how much people have different perceptions,” would be an interesting way to measure differentiation. Thanks for your comment, Paul!
Leave a comment