Steampunk for USDA NASS
Embracing Complexity
Mapping and modernizing USDA NASS's survey operations
- siloed departments mapped
- 12
- stakeholder interviews, ~90 min each
- 28
- JIRA user stories written
- 176
- multimillion-dollar contract awarded
- $M+
USDA NASS hired Steampunk to understand the end-to-end flow of their survey creation, distribution, data collection, and dissemination processes. A team was assembled to conduct research into the USDA NASS organization, which consisted of 12 siloed departments. The research began with secondary sources, aimed at gaining a surface-level understanding of the ecosystem in which NASS operates. Insights from this phase informed a semi-structured interview guide, which was used to conduct one-on-one interviews with 28 key participants. The information gathered from these interviews was codified and used to shape the overall strategy. The work below represents the outputs I generated during this research process.
Mapping the software landscape
The image above represents early work aimed at identifying systems. During the secondary research phase, it became clear that each silo within the organization was organized around specific software. As I gathered insights into the various types of software in use, I mapped them on a Miro board, illustrating how they connected to one another, along with the flow of information—both intake and output.
Seeing the whole ecosystem
As more of the software ecosystem is identified, a clearer picture of the NASS ecosystem begins to emerge. The method used to arrive at this understanding is both beneficial and effective in several ways. First, at any point, a team member can look at a specific software category and follow the information flow that each software facilitates. Secondly, each blank sticky note serves as a call to action for team members to fill in with relevant information about that category, effectively distributing the workload of understanding this complex system.
Stakeholder interviews
Conducting the secondary research enabled the interviewer to be at least somewhat informed about each interviewee’s responsibilities in relation to the software they operated. A total of 28 interviews were conducted, each lasting approximately an hour and a half. The first part of the interview was structured, featuring questions designed to gather a quantitative understanding of commonalities across all participants. These structured questions specifically targeted pain points within the ecosystem from the participant’s perspective.
Clustering the insights
The insights gathered through the interview process were broken down into individual points and then codified into organic clusters. This means that data points with similar themes were grouped together. The mechanics of this clustering process were as follows: If a data point was an original thought, a new organic category was created. If a single category exceeded eight data points, deeper meaning was sought, and the data points were recategorized accordingly. This method of synthesis allowed the team to navigate through a large volume of data and begin to make sense of it.
Furthermore, many of the themes that emerged had specific targets, whether related to organizational inefficiencies within NASS, software pain points, gaps in human resources in certain functions, or other areas of dissatisfaction. While these themes are qualitative in nature, once analyzed, we can apply quantitative methods to prioritize solutions. This approach helps to identify strategies that deliver the most impact for the least effort and resources—effectively achieving a "bang for the buck" solution strategy that benefits the most people.
The Human-Technical System Diagram
After codifying the data, I took the initiative to synthesize it into a single cohesive document, which I titled the Human-Technical System Diagram. The diagram was organized according to the timeline used in survey creation, broken down into individual stages. For each stage, it outlined what occurs, the divisions responsible, and the pain points experienced by those doing the work. This diagram became the highlight of the project, crafted through a collaborative process of vetting each stage with the corresponding subject matter experts. While the primary goal was to represent the current state of NASS, an emergent benefit was its ability to quickly onboard new team members—programmers, data architects, designers, and others—by offering a comprehensive view of the system.
Designing the future state
With a clear understanding of the current state, the team was now able to strategize on the future state. Using the Human-Technical System Diagram as a template, we incorporated the proposed changes to the NASS ecosystem. Salesforce, selected by the client as their SaaS solution, was integrated into the new strategy. This approach allowed the client to easily reference the current state alongside the proposed future state, facilitating a smoother transition and clearer understanding of the changes ahead.
The work shown here does not encapsulate the amount of trust building and relationship management that took place. After presenting all the work conducted steampunk was awarded a multimillion dollar contract to move forward with the proposed future state.
Writing the stories
Once the decision was made to move forward with the proposed future state, I was tasked with writing the stories for JIRA, given my role as both the voice and in-house technical expert on NASS. In total, I wrote 176 stories, each detailing the necessary steps for the implementation of the future state.
Incident tracking system
One of the future state solutions was an Incident Tracking System, designed to allow NASS to track any incidents arising from business operations. In addition to providing user stories for the software development team, I included workflow diagrams to help developers understand the flow and inform them of the logic and decision trees embedded in the design. Since the system was being developed in Salesforce, highly visual low-, mid-, or high-fidelity XD prototypes were not necessary.
Once the developers completed their work, I captured screenshots of the newly developed software and created training materials to assist with the validation process. These resources helped ensure that the software met the required specifications and facilitated a smoother handoff to users for testing and feedback.
Conclusion
In summary, my work with USDA NASS involved a comprehensive approach to understanding and transforming their data and survey systems. From conducting in-depth research, codifying insights, and creating the Human-Technical System Diagram, to strategizing the future state and developing detailed user stories, I played a key role in guiding the organization through critical transitions. By providing actionable insights, workflow diagrams, and training materials, I ensured that the proposed solutions, such as the Incident Tracking System, were effectively implemented and well-understood by both developers and end users. This project not only helped NASS modernize its ecosystem but also provided a strategic framework for future improvements, setting the organization on a path toward greater efficiency and innovation.