The hour-long online “zero-based” budgeting sessions will provide residents with an opportunity to get involved in their government and community and impact the city budget.
How to participate
Residents may participate in collaborative forums with their neighbors from a laptop or desktop computer, by logging into a forum at time that works for them. To find available times (from 8AM to 8PM, February 22-26, 2016) and participate, go to http://everyvoiceengaged.org/sanjose-zerob/.
Starting with a budget of $63,600,000, residents will be able to collaboratively reallocate funding for 30 city programs, including such line items as graffiti abatement, parks and urban renewal and more. Residents may also preview the 30 city programs and their current funding level here: 2016-2017 Budget Engagement Exercise (PDF Download).
I’m pleased to announce that based on our past succes producing Participatory Budgeting events for San José, CA, in 2011, 2012, 2013 and 2014, Conteneo and the Every Voice Engaged Foundation have been selected to lead two Participatory Budgeting programs for the city of San José in 2016. Both programs will leverage Conteneo’s online and in-person collaboration frameworks to provide a combination of intimacy and scale, along with other tools to help make these programs a success.
In this inaugural post, I’ll share an overview of the programs, along with details about how we’re partnering with Nearsoft to implement them using Agile methods! I’ll be sharing more details each week and letting you know our progress on the technical, social, content, marketing and other fronts. Keep reading, as we want you to get involved!
We have two participatory budgeting programs planned for the City of San José in 2016 [Note: These dates have been updated since the original post as the city changed the date]:
District 3 Participatory Budgeting (#d3decides): Nov. 2015 to Apr. 2016
This project will emphasize citizen input, soliciting ideas from residents using an open-source mapping application for crowdsourced info-gathering, “Shareabouts“, shaping these ideas into projects, and then using Decision Engine to allow residents to directly prioritize how the city will spend $100K.
Citywide Budget Engagement: Feb. 20, 2016 and the week of Feb 22, 2016
This project will emphasize scale and building for the future by using Decision Engine to engage residents in prioritizing how the city should invest the revenue from a ¼ cent sales tax that is projected to raise approximately $36M. We’re targeting a whopping 1,000 people for three in-person sessions on Feb. 20, 2016 and an incredible 50,000 people to participate online the week of Feb 22nd, 2016.
It’s heartening to see how San José is committed to building and expanding on the prior successes of our joint work on participatory budgeting. For example, the District 3 program extends San José’s previous work through the inclusion of Shareabouts (very nice!) and the second program gives Conteneo a chance to flex our scalable systems’ muscles by targeting the largest online Participatory Budgeting program ever tackled!
Collaboration at Scale Means Many Small Groups
All of Conteneo’s technologies are based on the fact that humans collaborate in small groups of 2 – 8 people. So, when we say that we’re targeting 1,000 people in-person and another 50,000 people online, what we’re really saying is that we’re targeting 125 – 140 groups of people collaborating in-person and 6,250 – 10,000 groups of people collaborating online.
Direct and Indirect Participatory Budgeting
An especially nice feature of these programs is that collectively they meet the narrow and broad definitions of Participatory Budgeting.
The District 3 project meets the narrow definition of Participatory Budgeting, which requires residents to directly control how resources (mostly financial budgets) are allocated to projects.
The Citywide Budget Engagement project meets the broader version of the United Nations definition of Participatory Budgeting: “a mechanism (or process) through which the population decides on, or contributes to, decisions made on the destination of all or part of the available public resources.”
I’m rather conflicted about the need to make these distinctions. My colleagues at the Participatory Budgeting Project appear to be quite adamant that the only valid definition of Participatory Budgeting is the first. Unfortunately, my experience is that most “direct control” programs are dealing with relatively small amounts of money, typically a few hundred thousand to a few million dollars, given the total size of budget in question. This is not a methodological flaw, but instead reflective of the novelty of Participatory Budgeting. Still, it has me concerned that this could restrict the impact of Participatory Budgeting through an illusory form of engagement: direct control of inconsequential sums of money, instead of substantial influence on highly impactful sums of money.
We can contrast this with our experience in San José, in which residents have routinely grappled with choices of much larger magnitude. For example, in 2014 residents considered initiatives such as 120 Sworn Police Officers for $25M or Expanding Branch Library Hours for $4.6M with budgets of as much as $64M. Not only are these amounts are often 10 times larger than those in direct control programs, our results have shown that San José has indeed made final budget choices in accordance with residents feedback. I attribute this to superior data: Like the senior executives of our corporate customers, when elected officials are provided with actionable data, they take action.
These distinctions, which seem so important now, might not matter at all over time. As residents and elected officials become more comfortable with Participatory Budgeting, the amounts of money put under direct control appears to be increasing. This is a good thing, provided that we continue to put equal emphasis on involving a broad cross-section of the population (more on this later).
For now, we prefer the United Nation’s more inclusive definition of Participatory Budgeting as this is more congruent with our values and the values of the Agile community.
Kicking off a project is a misleading team: It implies that there is a single meeting that represents the magical kickoff. In reality, most project kickoff meetings are the result of several smaller threads being woven together into a rope: a few emails here and there and some phone calls exploring options and building on prior results that come together for the kickoff.
Our project was no different: We started exploring options with City staff in October 2015. After several emails, a few meetings, and some phone calls, we reached an understanding of the City’s goals and confirmation that our team would be the right team to deliver them. We formalized key parameters of the project in a letter of agreement. I was especially impressed with the Agile contracting on the part of the City and how readily they’ve embraced the notion that Agile contracts are for establishing goals and agreeing on processes and how a backlog is the better place to manage work.
In parallel, Conteneo engaged with Nearsoft, a partner we’ve used in the past for development. We developed a series of one-week Sprint themes and deliverables based on clearly defined “chunks of value”. We didn’t waste our time with points-based estimating, because we had zero experience with some of the tools we knew we wanted to use. (See my presentation on the Shapes of Projects to understand chunks).
For example, none of us had any experience using Shareabouts, and given that the tool is no longer being actively supported by OpenPlans, we had no other plan other than asking the development team to just jump in and see what they could do. As it turned out, Shareabouts was in really good shape, and the team had it up and running in a few days on Heroku. This has allowed us to move forward items in our project plan, deliver working software right from the very first Sprint, without fretting about estimates that would not provide any value or materially change our intentions. It also helped that the team was not pressured to do something unnatural, like make an estimate on technology they’ve never used!
We’ve also enjoyed sharing Agile practices with the City. For example, last Friday I sat down with two city leaders on adjusting and improving the content and flow of the website. When I explained that we were going to work together and make the changes live, on the website in tiny steps, in a process that agilists like to call “pairing”, they were genuinely excited about getting to work. And yes, except for a few of the more complex changes, we just made the changes that we needed to make in real time.
At Conteneo, we believe in multidimensional collaboration. Whether you’re producing online forums using our cloud-based collaboration engines, or in-person forums using pictures of trees, boats and Stattys, we provide the best collection of frameworks for tackling technical and wicked problems. For both projects, San José will be leveraging Conteneo’s online and in-person frameworks, and in future posts I’ll outline our plans and results.
However, multidimensional engagement means more than just providing structures and processes. It means developing an understanding of the participants and making sure your team is meeting their needs, including the languages used in forums.
A significant percentage of San José’s population speaks Spanish or Vietnamese as a primary language. To support these people, we’re going to be developing multilingual materials and leveraging and expanding our global network of Certified Collaboration Architects. As it turns out, we have a fairly sizable number of Spanish-speaking facilitators. We’re going to need to recruit more actively for Vietnamese-speaking facilitators. Click here to join the facilitation team.
Lessons Learned and Next Steps
Here are some of the lessons that we’ve learned in our first two Sprints.
You need developers. At present, there are no really solid, off-the-shelf solutions for implementing Participatory Budgeting programs. If you’re going to tackle a sophisticated project, you’re going to need developers.
You need project / program managers. I don’t really care what you call them, but you’re going to need a person who is driving the project. I think of these people as providing positive energy to a system that needs it.
Use Agile. We’ve known for decades of the positive emotional power that working software, delivered in chunks, has on all stakeholders, the development team included. We proved it again: In collaboration with San José’s IT Staff, Nearsoft and our team, we had working software and our first resident-submitted idea in just 9 days!
Collaborate. That word is everywhere for a reason: You will not be able to get a project of this magnitude done this quickly on your own. In addition to San José, Nearsoft, Every Voice Engaged and Conteneo, we’ll be leveraging our global network of Certified Collaboration Architects and The Kettering Foundation. We are are in discussions with people like Jason Putorti. I’ll explore the collective that is creating this awesome initiative and how you can join us in my next post.
Big Goals Inspire! I don’t know of any program that has established the goal of engaging 50,000 residents in one week in collaborative forums. It is inspiring because we know it will be hard!
As some of you may recall, that at Agile 2015 I talked about engaging 20 million facilitators to engage 200 million people. Our 2016 project with San José will help us jump that curve! Stay Tuned!
A little more than five years ago, Conteneo introduced the first scalable platform for visual collaboration, now called Idea Engine. Since then, we’ve built two other products, Strategy Engine and Alignment Engine, made drastic improvements to Decision Engine, launched a nonprofit to bring our techniques to the public sector and a whole bunch of other cool stuff! Unfortunately, along the way, Idea Engine received less love than it deserved and become a little stale. So stale, in fact, that we’ve decided to redesign and rethink the platform, reset our technology stack and create some powerful new capabilities that promote even more scalable collaboration and innovation. This is Idea Engine 2.0, and this is the first of several stories we’ll share about its creation. Our hope is that you’ll find techniques that you can leverage for your own products and services.
We kicked off Idea Engine 2.0 by “Drinking Our Own Champagne” and holding a Design Jam with our customers, strategic partners and advisors. A Design Jam is a special kind of Customer Advisory Board meeting in which we use collaboration frameworks like Prune the Product Tree to explore the next generation of our platform.
It’s critical to define your desired outcomes when planning an event, whether it’s in-person or online. Our desired outcomes for the Design Jam were:
[unordered_list style=’circle’ animate=’no’]
Develop a shared understanding of required/desired functionality for Idea Engine 2.0.
Review and improve design prototypes.
Develop a milestone-driven release plan to make sure we have reasonable agreement on what we need to deliver first based on customer needs.
Develop a set of boundary situations; for example, what did we agree to do that we’re not doing?
The milestone-driven release plan is a really important distinction between Agile planning and traditional planning. In a traditional process, we’d try to estimate the actual delivery dates, making premature and incorrect commitments to stakeholders. In a milestone-driven plan, supported through the collaboration framework Prune the Product Tree, we can confirm the sequence of value that our stakeholders need, safe in the knowledge that our development team will be working as fast as they possibly can.
Helping Stakeholders Help You
Because our customers and partners believe in our larger mission of using collaboration to solve technical and wicked social problems (see my Agile 2015 keynote for more on this), they regularly ask me how they can help. So, we asked our customers to prepare for the Design Jam by:
[unordered_list style=’circle’ animate=’no’]
Bringing an example of how they’ve been using Idea Engine 1.0.
Bring an example of a framework or interaction model that you’d like to use but can’t.
I want to build a document-centric collaborative framework. Instead of “icons” like apples, I want “sticky notes” that look and act like notes.
Adjusting on the Fly
We also shared our agenda for the two days ahead of time (see right).
As common in these settings, we made a few adjustments. One worked poorly, four worked very well. Let’s start with my mistake.
I had intended to start the first session with the Innovation Game®Show and Tell, in which participants would show us positive uses of Idea Engine 1.0 and tell us what they wanted in Idea Engine 2.0. When we started though, we veered off track. What I should have done was facilitate the session more vigorously! Specifically, I should have pulled the room back into the game.
Unfortunately, I didn’t. I was working with an experienced team of facilitators, and I thought the “energy” of the room was such that they wanted to have a more open-ended discussion. I made a mistake, and we lost a bit of time.
Fortunately, after the session corrected itself during the initial design review, our customers provided a lot of terrific feedback on our new designs. I’m lad we did this, because we learned right away that one of our choices was incorrect. Somewhat surprisingly for me, the design review evolved into a discussion that included a review of our gaps. So, we had unexpected time in our agenda.
The first adjustment that worked well was adding a Cover Story/On the Cover activity to help us better understand how to communicate Idea Engine 2.0 to the market. We got a lot of terrific insights — some applicable right away and some applicable when we release some of the super cool ideas in Idea Engine 2.0.
The second adjustment was adding two Prune the Product Tree sessions. This activity not only helped us understand evolution, it resulted in a mutually agreed upon milestone-driven release plan.
The third adjustment was adding a super fun Magic Wand game in which stakeholders grabbed an imaginary wand and started submitting magic ideas for Idea Engine in the future. Surprisingly, some of these magic ideas turned out to be pretty feasible, and we’re adding them to our roadmap.
The most important adjustment was turning over the facilitation of a few activities to Deb Colden and Peter Green, two of our most senior and skilled facilitators.
8:30 AM Assemble as a team and get to know each other
9:30 AM Review existing uses of the platforms: What works.
11:30 AM Break
11:45 AM Review our understanding of key requirements for Idea Engine 2.0
12:30 PM Lunch
13:30 PM Overview of our proposed designs for Idea Engine 2.0
15:30 PM Break
16:00 PM Compare “desired uses of the platform” with our proposed designs to identify gaps
18:00 PM Dinner as a team
[separator type=’normal’ color=” thickness=” up=” down=”]
8:30 AM Assemble as a team
9:00 AM Update/review designs and build a milestone-driven plan for implementing new functionality
12:00 PM Design Jam ends
12:30 PM Optional Lunch
13:30 PM Continued work with the Conteneo team to enhance and extend our designs for those available.
Deb helped us dig through a technique to challenge orthodoxies I learned from Scott Gilbert (presently working for the Salesforce Ignite team) and Peter guided us through a technique the Agile4All team uses to help Product Managers/Product Owners slice stories. Both proved tremendously valuable.
I also feel compelled to mention that Fallon Murray from Transamerica using the Idea Engine during our Design Jam to collaborate with her colleagues and provide real-time feedback from a lot of the Transamerica team. It was clever and something I’ll borrow in future sessions.
Key Themes And Results
Two days with customers generates a tremendous amount of data, and we’re still working on making sense of the results. However, we can report a few key themes: Job #1 is to make the current platform beautiful. Our stakeholders asked us to defer dramatic improvements in functionality and instead focus on a sleek, modern user interface.
However, there are a few key improvements in functionality that we need to address sooner, rather than later, and we’ll be implementing these in Idea Engine 2.0:
[unordered_list style=’circle’ animate=’no’]
Adding the “Central Question” to the game board.
Providing better “onboarding” for new users.
Keep the count of items, but pave the way for more flexibly adding items.
Build in-place and then extend.
Our stakeholders asked us to be as agile as possible, ideally building in-place on the existing stack. This is like replacing the engine of the car while you’re driving, which we’re able to do because our dev team is so awesome. We’ve also integrated these results into our market-driven roadmap, and we’re looking forward to the next several months of hard work.
There is no settling of the dust, because we moved right from the Design Jam into a series of sprints to implement Idea Engine 2.0. We’re building and releasing in chunks of business value, and the dev team already has working software. Let me know if you’d like to join our Sprint/Design Review meeting: We’re eager to collaborate with all of our customers!