Slide 1 – Cover slide
Welcome to the Integrated Award Environment Industry Day 11
November 15, 2016
From 10 to 1 - Illustrated
Slide 2 – Agenda
What does it look like when we take 10 websites, break them apart, and put them back
together as one system??? We are an Agile development team, which means that question will
be answered iteratively. The system will unfold one quarterly release at a time.
The intent here today is share what our proof-of-concept wireframes look like. These
wireframes illustrate the direction we are going and what our overall vision for SAM.gov is. The
details today will be less important than understanding at a high level
1) How the new SAM.gov website will be laid out
2) What the main features will be and how they fit together, and
3) How the legacy systems will be mapped into this new blueprint.
Before we get to the wireframes, we are going to spend a little bit of time setting them up and
explaining our thought process behind the design you will see.
Slide 3 – What is IAE
Many of you have likely seen this picture our of legacy systems before. The Integrated Award
Environment (our office name) manages 10 award systems including the current SAM.gov
which now supports entity registration and exclusions.
It also includes FBO, where federal business opportunities are published; FPDS, where
procurement awards are published; CFDA, which describes federal assistance programs; WDOL,
a look-up for federal labor categories and wage rates under the Davis-Bacon and Service
Contract Acts; 2 systems for reporting sub-awards; and 3 systems for past performance.
When we are finished all 10 of these systems will be integrated into a single system – a single
website – the new SAM.gov.
This is a modernization effort as well. We are not lifting and shifting these systems into a new
environment. We are moving them into a cloud environment using Amazon Web Services. We
are also looking carefully at policy and business processes
1) what we can further automate
2) what data we can connect between the systems, and
3) how we can create a consistent, seamless experience.
Slide 4 – Who We Talked To
How did we get here? First of all to understand how people need to enter in and use the data
in our different systems we have held a series of focus groups over the last year and a half,
reaching out and trying to connect with a broad representation of our user community. It is a
large community. And it is diverse. It includes federal contracting officials, large and small
businesses, state and local governments, non-profit organizations and universities,
congressional staff members, and many others…
Also, we have validated our user analysis by looking at through our data, and conducted followup interviews, digging deeper into some of the more complex areas of our systems.
Slide 5 – What we heard
As we talked to people, and analyzed the features of these systems, and looked at the data –
patterns emerged. The main take away for this slide is the point at the bottom left – “No
matter the system or data set, people want the same things.”
We heard a lot of similar feedback from focus groups for the different systems. If you look at
the list on the right hand side of this slide – we heard these types of requests for all of the
systems.
This was good news for us because it has allowed us to look across all of these systems, see the
common issues, and create common solutions for them.
Slide 6 – A One Stop Shop
This has led us to see this 10 to 1 integration as truly a single application – a one stop shop with
one workspace for accessing all of the tasks you have in the system, one summary view for an
object where you have a snapshot of everything we have on that object – everything we have
about a particular entity, everything we have about an award, everything we have about an
agency, … You will have single sign-on with one user profile showing what you have access to
across the system; and for administration centralized control over who has access across your
organization. There will be one search solution across all award data. And one reporting center
centralizing reports on our data.
Slide 7 – Migration and Modernization
If we look at how that translates into a conceptual blueprint for modernizing and integrating
these systems, we have a picture that looks like this. This picture aligns with what you will see
in the wireframes in a few minutes.
The new SAM.gov website has sections or spaces that correspond to what you see here.
1) Application content includes all of the “non-data driven” pages – the home page and
all of the online help (featured articles, online user guides, and resource pages).
2) Search and display includes a simple keyword search, advanced filtering, and drilling
down into the details of a record.
3) Data entry will correspond to what we are calling a workspace where you can track
all of the records you are responsible for – so it’s a little more than just entering data,
it’s where records can be approved, submit for publishing to the site, and other
workflow activities.
4) The reporting center provides a directory of all of the reports in the system and is
the entry point into our 3rd party reporting tool.
5) There is a single consolidated administrative area for managing your organizations
and users.
6) And then there is an area for supporting system integration.
Slide 8 – Core Business Capabilities
If we simplify this picture even further, we can divide these capabilities into core business
capabilities and support capabilities. The core capabilities, in simplest terms, come down to
“data-in” and “data-out.” You see examples here of information/records being produced and
then examples of information being used or consumed.
Slide 9 – Supporting Business Capabilities
The supporting capabilities are no less important – I’d like to emphasize that although these
aren’t our business capabilities, they are just as critical to making the system work. For
example, administration is a critical part of managing these systems. Because we are stewards
of the data and it is owned by federal and non-federal organizations who enter in federal
acquisition information, managing who can see and do what in the system is central to almost
everything we do.
Slide 10 – Design Framework
There’s a few reasons we believe this break down of capabilities works. It’s a fairly simple
break down and translates to a pretty small number of spaces within the website. So we
believe it will make navigation of the website straightforward.
This simple functional breakdown also allows us to build the system more efficiently, solving
design and technical problems once (one search solution, one reporting solution, one data
entry solution, etc).
We’ve also noticed that for the most part the legacy systems are broken out using a similar
pattern – with a search space, a data entry space, a reporting space, etc.
And the break-down seems to be aligned with user tasks as we understand them. We have
users, for example, who spend a lot of their time just doing entity registrations or just
uploading sub-awards. We have others who mostly do market research. So we believe this
approach lends itself to supporting the discrete tasks people come to our systems to perform.
However, we are also cognizant of other factors. For example, the system supports the
procurement and federal assistance communities (oversimplified as contracts and grants).
These communities have distinct differences in policy and requirements and so we have to help
people understand what functionality applies to them.
We also have a lot of users that aren’t familiar with all of our applications – they typically only
work with a few of the applications or maybe primarily with just one. We have to make sure
what they need to do doesn’t get lost in the midst of everything else.
Some of our user tend to focus on pre-award activities while others only do post-award – this is
another important distinction.
And we also have personas and user journeys that aggregate the typical tasks different kinds of
users might do to help us look at what feature might go together best.
Slide 11 – Mapping the systems
This next slide illustrates what we were just talking about – how the legacy systems have
common patterns in how they are laid out. We’ve leveraged those patterns because they are
familiar but simplified them also and worked out some of the awkwardness of the old systems.
For example, in some cases you would have functionality when you are not signed in that would
disappear when you signed in.
So from a design perspective – you might not recognize it looking at the wireframes, but we
kept we thought worked about how the systems were laid out, consolidated things that are
alike (search goes with search), and smoothed out what used to be clunky.
Slide 12 – Simplify, Then Enhance
Looking at the order in which we are doing things, again from a design perspective, the first job
was to simplify across all of the systems. Simplifying will continue to always be a design priority.
We can’t always simplify as much as we would like, because we have policy to consider – and
for good reason. But our goal is to not introduce complexity with design.
As much as possible we are creating a common experience, so that there isn’t a lot to learn
about how the system works and you can focus on the data – what you really care about. Once
we have the basics in place, we look at how we can leverage having all of this data in the same
place.
We have done a lot of analysis and will continue to look at what stories people need to tell with
this information and how we can exploit the relationships between data elements to support
them.
Slide 13 – Strategic Themes
Before we move on to the wireframes I have a couple more slides I like to show – this is an old
slide that came out of our earliest focus groups and it still helps keep me grounded in what our
mission is. We can’t do everything for everyone, so if we could only do 5 things what would
they be. That’s the question this slide answers that helps keep us focused.
1) What are we doing to make sure this website works for the people who need to use it?
2) How are we making sure the capabilities of this site have a clear sense of purpose and
that we convey that purpose to everyone?
3) What are we doing to improve data quality?
4) What are we doing to make it easier to find information on the website?
5) What are we doing to make reporting simple and flexible?
Slide 14 – Designing for the Consumer
This slide came out of focus group comments also. Something we heard a lot was that the old
systems feel administrative – that we are required to enter data in to them, but not enough
thought has been given to how people need to use that information once it’s there.
The shift that has been on-going has been to look at how the information is used – how do we
make it more useful and let’s let that drive how we build the system.
Slide 15 – Perspective of the wireframes
The wire frames we are showing today are mostly from the perspective of non-federal users.
They are the culmination of analysis of the data, of the applications, and of our user input.
The wire frames deliberately oversimplify things to highlight the overall direction and approach
we are taking and to give shape to the website. It’s a picture of the forest, and not the trees.
The wireframes represent some work that has already been implemented, some capabilities
that are currently in development, and others that are still in design.
We focused on solving the hard problems first and iterating over smaller issues like cleaning up
words on the page or upgrading the graphics.
Our design tool also deliberately over-simplifies the look and feel, allowing us to focus on
functionality, data, navigation, and the overall flow between sections of the site. So colors,
fonts, and graphics don’t represent what the look and feel will be. These wireframes are a
communication tool that has helped us align our team to a common mission and to
communicate our approach to our stakeholders.