This is the second in a series of blog posts where 18F checks in with our partners throughout the government. Previously in this series: 18F Checks In With Jerome Lee and the eAPD Project.

USGS hydrologic technician Travis Gibson confirms Great Salt Lake water levels at the SaltAire gauge. USGS hydrologic technician Travis Gibson confirms Great Salt Lake water levels at the SaltAire gauge. Source: USGS Multimedia Gallery

18F partnered with the U.S. Geological Survey (USGS) on a few different projects from March 2020 to June 2022. We worked on a wide variety of projects together, including: Water Resources Mission Area Platform Modernization Path Analysis, Experiment & Iterate, and Acquisition Consulting; National Groundwater Monitoring Network Path Analysis; and National Water Information System Data Delivery Strategy.

A terminology note: a Path Analysis is an 18F offering that helps identify the right problems that need to be solved through user research and analysis, and an Experiment & Iterate is a follow-on offering after completing a Path Analysis to work on a solution to the identified problem together. This can focus on building a working product, preparing a procurement package, or training a team to take over development. An Acquisition Consulting is an offering in Acquisitions Services that coaches a partner’s team through the procurement process with their own contracting officer.

We had a conversation with Emily Read, Chief for the Web Communications Branch at USGS Water Resources Mission Area, to see how their agency is continuing with the work.

What has been going on with this work since 18F rolled off?

Here at the USGS, we’re still focused on making high quality water information discoverable, accessible, and usable for the public. 18F helped accelerate modernization of waterdata.usgs.gov, which has been serving real-time water data since 1995! The techniques we learned from 18F have become embedded in our software development approach. For example, see our ‘How We Work’ blog from last year. When we first started working with 18F, I didn’t realize how profound the impact would be on our team. I thought we just needed some knowledge transfer. We now run Path Analyses in-house with our own teams. We’ve embedded these methods into our software development to reduce the risk of IT investment and learn more about users and technology. You can see just how much we’ve integrated methods we learned from 18F by reading this blog about the user-centered design methods we employ at USGS Water.

We typically do 8-week Path Analyses (PAs), and some shorter PAs, when the topic is of smaller scope or complexity, if there’s an urgent need, or if the resources aren’t available for a full blown PA. We continue to engage stakeholders in the PA process, and learn from users. We took the method that is quite standard at 18F, and adapted the size and need depending on questions and challenges. We regularly have team members and stakeholders say, “We need a Path Analysis on this or that.” That shows how beneficial our stakeholders consider PAs to be, because we involve them in the process, trained them up on it, and they are bought in on the value.

We also partnered to improve our IT acquisitions methods. We partnered with 18F on this to decrease the amount of time required to acquire IT services, and to increase the quality and fit of the IT services we acquired. We largely worked according to the 18F De-risking Guide. This new approach was successful. Over a series of a few months, we developed a strategy around the branch workforce, wrote a statement of objectives for a new contract, and got the request for proposals lined up. We made an award within just four months of the request for proposals being released. The awardee lined up a highly productive agile team, and they’ve been great to work with so far. This new way of contracting is a nice complement to the way we work. It is more modular and changes what we are doing in federal hiring. It helps with how we staff up with changing budgets and evolving priorities.

Working with 18F has left an imprint on our team by bringing modern methods to government IT. This has been key to retaining a talented workforce and makes USGS a better place to work. Here are a few of our recent releases – a subscription-based notification service real-time water conditions (Water Alert) and Water Monitoring Location pages – that use the best available tools and tech including login.gov and the US Web Design System.

What makes you most proud about this work?

I’m proud that we are the first group in our agency to work with 18F, and through the partnership, we broke away from software development and acquisitions approaches that haven’t worked well in the past. I am very proud that the results have provided value to our agency. Our team has really internalized the learnings in our own process. The partnership with 18F lives on through our ongoing work.

What are some recent challenges or interesting problems that you have been working on?

Historically, we’ve had a large number of water information services and websites, which has required a lot of product owners operating mostly independently. That resulted in poor experience for users because the information was disconnected and hard to find. We are intentionally narrowing the portfolio down to deliver the same data through fewer endpoints, to improve users’ experience and ability to access data. As we narrow the portfolio, it raises the question of how ongoing product management will need to shift and adapt as our products become more interconnected, interdependent, and less duplicative. Following the findings from user research and tech analysis, we know we also need to make the products we do develop more adaptable to new data types that become available. So instead of developing a new web app for every new data type — which is really confusing for a user — we need to work carefully and thoughtfully to understand how new data can be served through existing endpoints when possible to meet user needs. We don’t have a playbook for this but recognize it as a challenge we need to address.

We are also starting to think about what it looks like when these products are modernized — that is, how much does continuous development on a modernized data product cost? What does ongoing product management look like? We have more questions and exploration we need to do here, but have so much more confidence in doing so knowing that we’re not alone in it. Maybe this will be a topic of future partnership!