Randy works here at TTS. Jon Geselle is the Contracts and Procurement Manager at Alaska’s Department of Health & Social Services.

Alaska’s Department of Health & Social Services is working with the Technology Transformation Services’ Office of Acquisition on a new approach to product and acquisition management to develop a modern, integrated eligibility system for their Division of Public Assistance. A major risk that our joint team identified was the need to attract vendors who are experts in working in modern ways to bid on the work. We’re experimenting with a transparent approach so that anyone can see, and provide public feedback on, our progress. We believe this will help to garner the interest of companies that are likewise willing to work in the open — precisely the kind of vendors who we want to work with.

Being open

Turning the tide of all-too-common, problem-plagued government technology procurements requires avoiding doing things the same old way. That’s what the State of Alaska’s Department of Health and Social Services, Division of Public Assistance is doing in its effort to modernize its eligibility systems.

Shrouding the procurement preparation process in secrecy is one of those “same old” ways that we’re working to avoid. From the inception of the project, we’ve been doing our work, communicating with stakeholders, and collaborating with vendors in the open, on GitHub. (GitHub is intended for software developers to collaboratively develop open source software, but we’ve found that it can also be an effective tool for engaging with software consultants in the procurement process.) We intend for the code we produce to be open source, and believe our process should be just as open. This underpins the entire effort that we’ve embarked on together at 18F and the Division of Public Assistance, and we believe that it will ultimately set up Alaska for success.

We’ve been in public procurement for some time, and we’ve experienced the challenges that arise when a solicitation we’ve released or a contract we’ve signed goes awry. This can lead to trying to get everything perfect before releasing anything to the public — working in a vacuum that is actually counterproductive to our aim of collaboratively partnering with vendors. Without that valuable feedback from the vendor community, it can be difficult to construct a solicitation that is as good as it needs to be, instead relying on the misplaced hope that vendors will understand it. Often, this approach forces vendors to make assumptions to fill in the gaps because they lack a clear-enough picture of the project to respond adequately. When the product team and vendor start from a place of fundamental misunderstanding, it can be difficult to recover.

By providing vendors a window into the project from its inception, including the ongoing opportunity to ask questions and offer feedback, we’re inviting them to identify our assumptions and blind spots in a way that can be difficult for internal stakeholders to do. Getting this kind of feedback does two things. First, it helps the product team think more completely about the project. Seeing things through the vendors’ eyes illuminates otherwise-hidden keys to success. Second, it signals to the vendor community that we’re truly invested in an open and transparent project where the vendor and product team form a partnership.

It’s understandable why we don’t normally operate in such an open manner. We’re weighed upon heavily by concerns about providing a vendor with an unfair advantage or disclosing information that could somehow taint the procurement process. As procurement officers, we’re taught to maintain a fair and equitable solicitation process and to avoid anything that would put that at risk. But on closer inspection, these fears can be eased by being more open, not less. By having a public project page housing all project materials, within reason, we’re fostering an environment in which there are few secrets. We’re also increasing the chances that incoming vendors are the right vendors, with the right understanding of the project, which is essential for project success.

Finding the right partners

Our team is working to get the word out about our solicitation to modern software development firms in Alaska and throughout the country. Alaska’s product team laid out their product vision statement, strategy, and roadmap in the project’s README file. We wanted people to have a plain-language view of our goals, and we’ve been adding to this document as we learn from our early prototyping. We think this is a great way to show vendors where we’re headed and help them decide whether this is a project they want to support.

To get vendors’ eyes on this, we decided to communicate with them in three different ways:

We started by publishing a lightweight request for information (RFI). Although this method of market research is nothing new in government procurements, we made sure we weren’t turning off vendors with a massive writing exercise. We’re looking for companies with great teams of developers and asking them to spend resources on long responses would be counterproductive. So we tried a really lightweight RFI, asking for their response to four simple prompts:

• Would you be interested in working with Alaska and 18F on future modules?
• If not, can you tell us why?
• Links to open source code repositories that your team has worked on that might be relevant to the work Alaska will need.
• Questions you have about the project.

We created a “Vendor Info” directory in our GitHub repository, knowing that the Alaska procurement website might have limited reach within the civic tech community. It offers a high-level description of how we want to work with vendors. We emailed some companies directly who we had learned about in prior state-level work, as well as some Alaska firms that specialize in this kind of work. We encouraged vendors to respond to the RFI and to track our progress on the GitHub repository.

We’ve turned questions from vendors into GitHub issues and are responding to them publicly. The RFI responses were better than we could have hoped for. We heard from over 15 companies, many of which are the small, niche businesses that have the focus and expertise to help our team as we move in this new direction. We gathered over 80 questions from the respondents and converted them into GitHub issues. Judging from the software repositories provided in the responses, along with some thoughtful questions that really show that the companies have modern techniques in mind, we believe that this experiment in transparency will help us to get great proposals when we issue our first requests for proposals (RFPs).

What’s next?

We’re going to continue using the GitHub repository to update vendors, stakeholders, and the general public on our progress. We’ve responded to all of the vendor questions via GitHub Issues. We’re going to draft our initial RFP in GitHub, so vendors can see it as it’s being written and submit questions and suggestions as we go. The draft scope document for the first procurement is already published.

Working in the open isn’t the only thing that’s new about the Division of Public Assistance’s approach to legacy system modernization: Alaska is asserting product ownership, adopting a modular procurement strategy, embracing agile delivery, and building out a DevOps pipeline and culture within the department. We plan to share more on these topics in the future.

Moving from transparency to quality

We’re hopeful that our transparent relationship with the vendor community will result in offers from companies that specialize in agile software development. We also hope that these vendors will weigh in on our approach via GitHub Issues. We can’t guarantee a drastic change in strategy, but we want to get continuous feedback so that we can continuously adjust as Alaska begins issuing RFPs. Given the responses we received to the RFI, we believe this experiment in transparency is heading in the right direction, and will result in quality work from quality vendors.