This post originally appeared on the Code for America blog during my time as a 2015 Fellow.
My teammate Ben hears from a purchaser in the Pittsburgh Fire Bureau.
After a month of building prototypes and soliciting feedback from our city partners in Pittsburgh, we’ve started to narrow the scope of what we want to build to help change the outdated ways the city buys everything from software to paperclips. Explicitly choosing not just what to work on, but what to stop actively developing is a difficult part of the user-centered design process. It’s also one of the reasons Code for America encourages fellowship teams to start building early, to get testable prototypes in front of users as soon as possible so that the hard work of scoping can happen sooner rather than later.
At the end of Ben’s post outlining the principles behind how we build, he listed five things we’ve built since arriving in January. Since that post was written, we went back to Pittsburgh and put some of those wireframes and early-stage applications in front of city staff, and the feedback was overwhelmingly positive. While this is great news, it also means we had to come up with another filter to help us make some tough decisions.
Breadth, Depth, & Lift
To guide our thinking, we adapted a set of metrics we learned from the Code for America health team:
- Breadth: how many people are impacted by a given problem?
- Depth: how deeply is the problem is felt?
- Lift: how technically or politically difficult is the fix?
Thinking in these terms helps us prioritize, particularly given the relatively narrow window we have in a fellowship year. Inverting lift into a positive metric, we were able to start thinking in terms of feasibility, looking to the likelihood of a successful deployment given both the technical demands as well as the surrounding organizational context. We then took our four major projects (a marketing/outreach site, Wexplorer, Template Maker, and the Pittsburgh Procurement Explorer) and gave them a high, medium, or low value for each category:
Our decision-making metrics and projects, in one chart.
With this line of thinking, we opened up a conversation about Template Maker.
Rethinking Our Focus on Documents
After our initial conversations in February, we saw a huge need for common “templating” for all kinds of procurement documents. So we built a prototype:
The functionality of Template Maker in action.
With Template Maker, our city partners in the legal department could create a central database of internal procurement documents, which had the potential to transform the entire process. Standardized document templates would become forms, which could remove a lot of the confusion departments face while drafting requests for proposals (RFP), resulting in better documents and less legal back and forth during the final contracting process.
But after looking at our projects using our decision-making categories, we decided to stop actively developing Template Maker. Here’s why:
The lift required to bring Template Maker across the finish line is such that we would have to dedicate a majority if not 100 percent of our team’s focus to this single product. Making a WYSIWYG editor for procurement documents that doesn’t just work, but is also enjoyable to use is no small feat and ends up replicating much of the same features many of our users already have access to in Microsoft Word or Google Docs. Template Maker also only addresses documents, just one part of the extremely lengthy and involved procurement process. In short, Template Maker would be a large investment for a relatively narrow outcome. By moving our focus off of documents, we can focus on the entire process.
We think we can have a larger impact for a lower lift by focusing more of our technical efforts in and around city purchasing. Here’s where we’re going:
- Expand Wexplorer into a searchable, categorizable, and regularly updated library of current contracts that department purchasers can use as part of their daily workflow.
- Build a central Office of Management & Budget (OMB) site for marketing upcoming contracting opportunities using a combination of data from Wexplorer as well as department-generated content. A current site for professional service opportunities exists, but we think having commodity opportunities more actively marketed would deliver value for city departments.
- Implement a data update workflow that not only helps OMB with shepherding contracts through the extremely complex purchasing process, but also keeps city apps up to date.
- Move away from document-based solutions and explore alternative ways to guide city departments through the process.
- Work with the legal team to help craft templates in tools city departments are already using.
We are really excited to see where this readjustment of focus takes us. Stay tuned.