18F/18f.gsa.gov

---
title: "How Alaska is using transparency to attract modern software vendors"
date: 2017-09-12
authors:
- randy-hart
- jon-geselle
tags:
- acquisition services
- alaska
- health and human services
- state and local practice
excerpt: "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. We’re experimenting with a transparent approach so that anyone can see, and
provide public feedback on, our progress."
image:
---

*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](http://www.dhss.alaska.gov/Pages/default.aspx) 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](http://dhss.alaska.gov/dpa/Pages/default.aspx). 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](https://github.com/AlaskaDHSS/acq-alaska-dhss-modernization). (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](https://github.com/18F/acq-alaska-dhss-modernization/blob/master/README.md)
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**](https://github.com/18F/acq-alaska-dhss-modernization/tree/master/vendor-info)**,**
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](https://github.com/18F/acq-alaska-dhss-modernization/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](https://github.com/18F/acq-alaska-dhss-modernization/pull/118)
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.