Over the past 15 years we've produced thousands of Participatory Budgeting and Buy a Feature events. In that time we've created a lot of variations of the core theme - and we continue to create more! In this design tip we'd like to share some of the many variations we've used in the hopes that you might find combinations that can help you Collaborate at Scale. Think of this design tip as giving you access to a set of knobs and dials that will enable you to create versions of this framework that meet your needs. I will also cover Zero-Based Budgeting, a very special configuration of these policies that is becoming increasingly important in our Participatory Budgeting projects. A subsequent design tip will give more insight into analyzing results of Buy a Feature frameworks.
The Core Game
If you're a subscriber to this newsletter, chances are pretty good that you know the core
Buy a Feature framework: a list of items are presented to a group of participants who are given a shared budget to fund, or purchase, items of interest.
To create variations on this core structure we will decompose it into its constituent parts. We can then vary these parts in ways that enable us to create new frameworks. This is a process we also teach in our class on
advanced framework design
Let's examine a few of the most important parts: Content, Resources and Policies (or Rules of the Game).
If you're relatively new to
Buy a Feature, don't be alarmed at these policies and their variations! Rest assured that our online platform is pre-configured with a set of default policies to make it easy for you to quickly get started using
Buy a Feature.
The content in the framework consists of the items, their description and their price. Here are two variations on content that we find useful.
Adding New Items: Write-In Candidates
Buy a Feature games are fixed: the list of items can't be extended. However, there are plenty of times when you want participants to add items to the game as a means of identifying fresh ideas or critical content.
We did this for a GE Customer Advisory Board and for several Participatory Budgeting projects in San José, CA.
Be careful about write-in candidates because to add them into a forum means you need to make choices about how they are priced and whether or not adding new items expands the budget. We recommend keeping the budget constant and having a subject matter expert available to help you price the items. If you can't price the items in real-time during the forum, ask participants how much they would be willing to invest in these items. Investment levels will provide a reasonable proxy for the importance of the items.
Each of the items needs a price. There are two common pricing algorithms. The first is to use an estimated price. Our online platform makes this really easy by enabling you to associate a shirt size with the item which the platform then uses to select a random value within a range you define. This is the dominant approach within business, when we're generally using rough estimates of costs ("Project A is a Medium and will cost $350K - $400K; Project B is a Large and will cost $600K - $700K).
The second approach is to use the actual or detailed cost estimate of the item. We use this technique in our philanthropic work when citizens really do need to know the cost of a new street light or a new service program. This variation is also common in portfolio management, when detailed cost estimates are available to business unit leaders.
Most of the time the items in a
Buy a Feature framework are independent. Like a well-structured Agile backlog, this simplifies the framework and enables participants to separately consider the value of each item.
However, just like in Scrum, there are times when items in your forum have natural relationships. We've produced items with the following relationships:
To purchase item B you first purchase item A. Item B is optional - but if you want it, you must purchase A!
You can purchase one and only one of a list of items (keep the list small!).
While we have done this, we generally try to avoid complex relationships. We worked with one client who insisted on creating a pricing model in which groups of items, when purchased together, updated the rest of the items in real-time. It was an epic failure - participants became quite frustrated because they couldn't keep track of their bids and purchases, and changes in just one bid could invalidate previously stable purchases.
The standard and most common bidding policy is that participants can bid any amount of their available funds on an item. This works very well because it is quite simple and direct.
Many Asian cultures prefer to have an "all or nothing" bidding policy, in which the total budget is pooled and participants must agree, as a team, on funding an item. This can be accomplished with a simple Yes/No vote.
Another variation is to require a minimum and/or a maximum bid on an item (e.g., Item A costs $100,000 - you must bid at least $20,000 but not more than $50,000). We're not a fan of minimum / maximum bid policies because they can artificially limit the revelation of the intensity of the participants.
There are three variations on the Budget. The first is to simply use a percentage of the total budget as means to motivate prioritization of the items. We've found that 40% to 60% of the total works best. This approach is common when using our platforms for market research.
The second is to use the actual budget that you've got for the planning cycle. This approach is common when using our platforms for Participatory Budgeting or for portfolio management.
The third approach is to start the forum with zero budget - which means you must provide a means for the participants to acquire funds. In a resource allocation game participants can provide their own budget ("I commit 20 hours of community service" or "I commit $65,000 of my total discretionary budget").
In the Budget Games variation, we provide participants with a list of items that they can
cut in order to secure funds. We call these items the "Red Sheet" items and require that participants reach unanimous agreement on a red sheet item before the budget is dispersed (equally) to the participants.
Combining Policies: Zero-Based Budgeting
A very special version of Buy a Feature is known as
a technique we've been using in San José, CA.
In ZBB we establish several policies that work together to create an amazing experience.
Budget: The total budget is held as constant for the prior year. So, if the City spent $64M on neighborhood services last year then the Budget for the next year is the same - a "Zero" Change.
Item Price: The price of the items, in this case neighborhood service programs, are the amount of money the City spent in the prior year.
Item Funding Policy: Participants, in this case residents of the city, can choose to increase or decrease the amount of funds for a given program. This means that if a program is working well residents can fund more of the program and if it is working poorly residents can fund less of it or recommend that it be eliminated by not funding it at all. All items start out with zero funding - the "Zero Base".
Write-In Candidate: We allow residents to add up to two write-in candidates for new programs and ask them to indicate how much they'd like to invest in these new programs.
We're really excited about Zero-Based Budgeting because it provides residents with a means to shape the programs of the city in a way that better meets their needs over time.
Funded Item Ranking Policy
The standard version of
Buy a Feature uses the time of purchase of items to understand the preferences of the group, as we believe that the faster an item is funded and the more stable it remains during the forum is a solid indication of its priority.
Some facilitators have asked for additional information on the priorities of the funded items, so you can now require that items are rank ordered by the participants after they complete their purchases.
Phew! That's a lot of compelling variations of an incredibly powerful framework. Check in next week on how to post-process the results of these great varations. And do tell: What are some of the variations you've found most effective in your work?