How can a development team explain how its new app streamlines security paperwork?

---

---

The prototype of the new app includes simple forms and a dashboard to show how much of the SSP is complete.

Project Summary

For this project with the Center for Medicare and Medicaid Services, our team was developing a software system to simplify security compliance paperwork for new technology. The team brought me in near the end of a contract to help summarize its accomplishments and present a compelling vision of the new product. In just one month, I helped the team reconcile conflicting views by building a service blueprint that detailed the current state of the product as well as its future potential.  

As a result, everyone involved in the project—developers, designers, CMS product owners, and executive leadership— could clearly understand where the project was at, how it worked behind the scenes, and where to go next. 

What I did

• Synthesized existing user research
• Facilitated collaborative blueprinting sessions
• Built team consensus
• Crafted a current-state service blueprint
• Developed service design recommendations
• Presented findings to executive leadership 

Background

New technology systems for the federal government have to meet stringent security requirements before government agencies can use them. This is called getting the Authority to Operate, or ATO. The cornerstone of an ATO is a long document called the System Security Plan (SSP), which explains how the new system complies with a long list of rules. Completing an SSP comes with a host of challenges:

• The documentation can be hundreds of pages long and take more than six months to complete. 
• The rules, called controls, are hard for non-experts to understand.
• Development teams have to write their answers from scratch every time – even when other teams have faced the same questions about the same building blocks many times before. 

As a result, the ATO process is really expensive. The Center for Medicare and Medicaid Services says it takes fully 500 hours of work for one ATO. Development teams can spend up to 15 months and over a million dollars in staff time to complete an ATO. CMS alone has hundreds of systems and spends tens of millions of dollars every year just dealing with ATOs.

In short, the SSP is the kind of onerous paperwork that sucks time, money, and energy from both development teams and the federal agencies who are buying the technology. 

Challenges

The designers on the team were creating prototypes that were months ahead of what the developers were currently building. The product owners from CMS were even further beyond the designers, dreaming up new features and integrations that couldn’t be built for months or years. 

This made it hard for the team to communicate, to prioritize work, or even to understand the current state of the product. To top it off, they were scheduled to deliver a presentation to executive leadership in three weeks. Everyone was eager to show progress and how this product would benefit CMS. This was the moment when the  team brought me in.

My task: map the product’s current reality and identify future service improvements. 

My approach

1. Research

I dove in to learn all I could about the project, the people who would use the new software, and the security compliance process at CMS.

• Research review: I did a deep dive into the user research the UX team had conducted during the discovery phase, learning about the ATO process at the agency and the pain points and workarounds with existing systems. 
  
• Interviews with team members: I spent hours talking to the team’s developers, designers, product owners, and security subject matter experts to understand how the app worked, and how it would integrate with the rest of the security compliance ecosystem. 
  
• Usability testing: I assisted with the UX’s team’s usability testing with CMS security officers in order to hear firsthand about users’ work and how the app would integrate into their daily processes. 

One thing I heard in these sessions was that our app prototype was working great— it was the rest of the compliance process that users struggled with. It was clear that in order to really make a difference, the new product  would need to integrate fully with existing security systems and processes at the agency. 

2. Service blueprint

I created a service blueprint of the new product, working iteratively in collaboration with team members. The diagram captured the process a CMS security officer would use to create and submit an SSP with the new system.

• Which version? Because there were big gaps between the demo version of the product, the actual code, and the product owners’ visions, my first challenge was to figure out which version to map in the service blueprint. After some discussion with product leadership, we decided  to blueprint the demo version of the product, which had been tested with users and was slated for development. 
  
• Communication: Early drafts of the blueprint captured everyone’s ideas, questions and problems. Walking through these together helped team members understand each other’s perspectives and come to a consensus on how the system worked at a high level. 

3. Presentation to leadership

The final service blueprint became the centerpiece of a team presentation to the Chief Technology Officer and other CMS security leaders about the state of the product. 

• Service design 101: I gave a brief overview of the field and how to read a service blueprint.
  
• Walkthrough: I detailed key steps in the process and explained the vision for how the new app could grow.
   
• Recommendations: I summarized the key issues I had uncovered during my research and made recommendations on how service design could improve the broader security compliance processes at the agency. These included creating an ecosystem map to encompass all new and existing technology products at CMS, using a zoomed-out service blueprint to ground roadmapping discussions, and conducting discovery research with CMS staff to create a seamless experience as they adopted the new products and processes the security team was developing. 

The project team was excited and proud to present this picture of the product they’d been working so hard on, and the product owners were thrilled to communicate their vision visually. Everyone felt the presentation successfully conveyed the essence of their work in a compelling way.  

Results

The project team embraced the service blueprint as a way of understanding how the UX designs and technical infrastructure fit together. They went from not really knowing what service design was, to wanting to include it in all their work. 

We had laid out a plan to regularly update the blueprint and use it for planning discussions. Unfortunately, the project was discontinued for unrelated reasons, and the team went its separate ways. I took comfort in knowing that they would bring their new knowledge of service design to their next projects. 

I went on to work on another project focused on security compliance and ATOs, where I benefited from both the subject area knowledge I gained at CMS and the experience of rapid service blueprinting of a complex digital system.