DPI670 Assignment #2: Hey Mr. Vendor…
Public transit use is all about convenience. If it’s not easy to use, people won’t. Mobile payment apps represent one way of reducing friction facing transit use. These apps will only reduce friction for users if they have an intuitive design, an easy payment syncing mechanism, and infrequent updates to alleviate troubling bugs. Only skilled developers and organizations with sufficient resources and expertise can develop such an app in a timely and efficient manner.
A transit payment app for the Boston-area presents even more difficulties than the average transit app for the selected developers and organization. Consider that the Massachusetts Bay Transit Authority (MBTA) has a history of failed transit initiatives and complex community relations that have made its transit leaders hesitant to take on innovative initiatives.
High ridership, in spite of management setbacks and scandals, presents developers and the organization with another source of complexity — more users leads to more unique user needs to accommodate in the app’s interface.
The weather presents an additional complication. Though Bostonians know cold weather well, the use of a mobile app in frigid temps offers a challenge to even the most dexterous smartphone user (not to mention the challenges posed by cold climates to smartphones themselves).
The individual developer, then, must possess three skills to join the team chosen to build out a payment app for the MBTA. First, they must demonstrate a willingness to work closely with MBTA staff and transit users. Second, they will need to show experience working in a similar setting with a similar goal. Finally, they have to signal an ability to buck institutional and political pressures.
The first requirement comes from the fact that an Agile approach to software development works best with regular engagement with the customer. In this case, two customers come to mind: the MBTA itself and transit users. Several examples, including the failed launch of Healthcare.gov, show that when developers have insufficient communication with the relevant customers things tend to go awry. In an interview with our class, Henry Chao, former Centers for Medicare and Medicaid Services Deputy CIO, made clear that insufficient lines of communication between developers and the customer can foster horrible, unintended outcomes. So the selected developer must embrace the customer-centric and user-centric thinking at the heart of Agile. This requirement aligns with 18F’s own prioritization of vendors that have developers trained in the art of Agile.
The next requirement falls from another best practice: hire someone who knows what they’re doing. Sample questions to pose to applicants include:
- Has this developer worked on mobile apps before?
- Does this developer have a track record of working with transit agencies and the public?
- Is this developer comfortable with taking feedback from a variety of stakeholders?
These questions will help narrow the pool of applicants to find candidates ready to work in a resource-constrained environment while acknowledging the public’s interest in and need for a product that works. As an aside, the selection process should use a tool like Blendoor to identify the best candidates based on capability instead of affinity. The use of such a tool and other objective assessment metrics will also eliminate the likelihood of MBTA project leaders feeling beholden to sticking with “their” choice.
The third requirement similarly aims to reduce the likelihood of human cognitive shortfalls stifling a product’s quality. Like moss on a damp log, groupthink — a byproduct of human’s somewhat limited mental abilities — thrives where passivity exists. The selected developer must understand the sources of groupthink, discuss how they would identify its sources, and outline, in detail, how they would prevent spores of groupthink from becoming an all-encompassing mossy mess.
What’s left is identifying the developer from the right organization. David Moskowitz, in his lecture to class, stressed that procurement officers should select organizations that prioritize excellently bidding on fewer projects. In other words, Moskowitz’s presentation touted the merits of organizations that expertly prepare their bids rather than haphazardly apply to everything under the sun.
He additionally suggested finding organizations that will invest in forming relationships with the leadership of the bidding organization. Greg Gershman, in his presentation to class, echoed Moskowitz’s recommendation. Both presenters indicated that this approach ensures the buy-in from both parties required to make any sort of lasting change possible.
Finally, it’s important to find an organization that has a track record of working with other subcontractors, per Moskowitz. This counterintuitive characterization reflects the importance of working with organizations that demonstrate the intellectual humility necessary to admit when someone else can do it better. Gershman likewise advocated for identifying organizations that have the ability to recruit great talent and work with a variety of stakeholders.
