Skip to content
This repository has been archived by the owner on Dec 8, 2017. It is now read-only.

New consulting pages #13

Open
wants to merge 7 commits into
base: 18f-pages
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 45 additions & 0 deletions When_to_use_Discovery.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
#Discovery: An Overview

##What is Discovery and when should you use it?
Discovery is a process by which a government agency (you) can work with another government agency (us) to help identify, assess, address and understand a particular challenge you’re dealing with or a new project you are beginning to define.

Discovery can take many different forms depending on the set of tasks it’s trying to help you address, but there are some similar characteristics to most processes. They include:

1. Lowering the risk of identifying the wrong scope for your project or challenge;
2. Addressing stakeholder needs and desires early in the process;
3. Accelerating buy-in by stakeholders throughout the project;
4. Training users on the value of the user research process; and
5. How to avoid planning your project around misaligned assumptions.

Working together as a team, we help you gain insight into the reference point for your project, identifying the “true north” for a particular challenge or set of goals. This in turn helps you make better informed decisions, understand where and when to take calculated risks, and figure out the next, concrete steps towards making your project a success.

Once the next steps have been identified and agreed upon, 18F Consulting will help you figure out the next steps of the engagement and keep the project on-track to maintain the momentum of your new group of project stakeholders.

##Who should participate from my organization, and what will we do?
18FC believes in cross-functional teams. Although design researcher/prod strategists may plan and lead product focused discovery sprints, anyone on a team, as a consultant, should feel confident planning and executing on interview and assessment based discoveries. And if you don’t yet, know that your team supports you getting that experience: through pairing, shadowing, and other activities. Below are a few activities that often make up the discovery process.

###Stakeholder and Program Engagement
Generally consisting of a workshop format held over multiple days, stakeholder and program engagement activities are designed to figure out the situation unique to your organization and project that will help make your outcomes as useful as possible. Activities include identification of all stakeholders that hold influence over a project and gaining insight into what they expect from the project; understanding fears and ideas around what success looks like; current or future policy decisions or laws that may impact certain directions for the project; identification of needs and vehicles for procurement with the acquisitions team; identification of current strengths, weaknesses and aspirations for the project.
###Research
Research occurs throughout the discovery process. Background research provides a window into past success and failures, current systems and architecture, past user research and results, and any other reported findings that help inform the current state and the desired future state. A history of an existing project including past management practices and methodology, assessments, contractor performance indicators, and previously identified metrics for success are helpful in framing a better understanding of the environment the team is working in.
###User Interviews
User interviews are an extremely valuable and reliable part of understanding the needs of your team. Interviews usually take place in pairs. Any more than two interviewers on an interview team tends to make users feel uncomfortable, and having two helps to vet the feedback and reduce risk of misunderstanding the experience. Together the team helps to cross-check each finding and derive the most meaningful insights.

User interviews can also be complemented through direct observation. Direct observation allows the team to shadow users working with a particular project or through a process and record observations about their interactions. This helps inform the team how the current solution is (or isn’t being used), while also identifying opportunities for improving processes.

> “When short on resources in SF, I asked a designer in that office to accompany on a ridealong learning how DOL investigators do their job. My colleagues insight and support where valuable to me and it gave another person inside the larger 18F organization a “high touch, client facing” experience.” - Jesse Taggert, 18F Consulting

##Group Interviews
Description here...

##SWOT Workshop
Description here...

##Journey and Process Mapping Exercises
Description here...

##Heuristic Analysis
Description here...

##Peer Reviews
Description here...
69 changes: 69 additions & 0 deletions agile-kickoff-meeting.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
#Agile Kickoff Meeting

##Overview
The Agile Kickoff Meeting helps you strategize with members of your agency to align new project goals to the best possible outcomes.

##Goals and Outcomes
1. Create Alignment and level set expectations
2. Introduce and model HCD, Lean, Agile questions and attitude
3. We want a project champion or leader

#Duration
1-2 days

###Sample Agenda
Welcome
-Agenda/House Rules
-General Intros/Team

Stakeholder Inquiry
-Who decides
-Who has knowledge
-Who is dependent on this
-“Who is the family?”

Goals/Non-goals
-“Why are we here”// the problem space
-“Elevator Pitch” / Slogan
-“Propose the worst idea”

Users/Needs
-Determine F.O.G.
-Prev research?
-Users present?

High level features/MVP
-Prioritize most valuable workflows if strangler pattern
-$100 comparison exercise

Technical Needs, Constraints, Dependencies, Integrations
-Knowledge
-Empathy

Business Needs
-Security/ATO
-Timelines

Risks
-“What keeps u up at night?
-Prioritize & discuss

Size it up
-Working principles: what is firm, what is flexible

What might this take? Time/resources strawman

Next steps
-Epic Stories if appropriate

Retro (demos retro, helps assess buy in)

###Who the product is for:
First and foremost, the following individuals are critical to the success of the workshop:
1. Project stakeholders
2. Agency developers and designers
3. The procurement lead

##Outcomes
Documentation and findings from the process. Concrete mission statement, epic stories, solicitation guidance.

27 changes: 27 additions & 0 deletions discovery-sprint.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
#Discovery Sprint

##Overview
A discovery sprint provides you with insight into specific needs of your users, and helps you identify solutions that may not
have been readily apparent. The discovery sprint also helps to align your broader agency team around this research, and provides
a roadmap for next steps and overall product direction.

##Duration
One to four weeks.

###What the Discovery Sprint process looks like:
1. User research, including user interviews
2. Contextual inquiry / "ride alongs"
3. Diary / journaling
4. Workshops using card sorting and participatory sketching methods
5. Process assessment, and group journey mapping

###What the Discovery Sprint process delivers:
Synthesis of the process into documented personas, journey maps, scenarios and a product roadmap.


###Who the product is for:
2. The Product Owner
3. The Contracting Officer (CO)
4. Individuals with approval authority (e.g. CIO’s representative)
5. System Users (to the extent they’re available)

41 changes: 41 additions & 0 deletions ghostwriting.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
#Ghostwriting RFP Workshop

##Overview
The (RFP) Ghostwriting Workshop will bring together key stakeholders from your agency and product, technology,
and acquisition specialists from the 18F team over the course of one to three days to facilitate the rapid development
of an acquisition strategy and solicitation documents, as well as associated artifacts.

Traditional RFP development inside government can be a painstaking, laborious process, often dragged out over many months,
innumerable meetings, and multi-threaded email exchanges. The 18F RFP ghostwriting workshop compresses that timeline from
months to days by providing a moderated forum for consulting with program stakeholders to achieve meaningful outcomes in a
rapid fashion. By working collaboratively with a critical mass of decision-makers, all in one room at the same time, we help
you remove barriers to delivering the components essential to a successful RFP.

###The goals of the workshop are to:
1. Define and clarify the product vision and key components of a *Performance Work Statement (PWS)* or *Statement of Objectives (SOO)*
2. Adopt a clear acquisition strategy and/or define requirements/constraints
3. Make decisions about key aspects of solicitation
4. Create artifacts that support all the above goals

###Who should attend from my organization?
1. First and foremost, the following individuals are critical to the success of the workshop:
2. The Product Owner
3. The Contracting Officer (CO)
4. Individuals with approval authority (e.g. CIO’s representative)
5. System Users (to the extent they’re available)

##Sample Agenda
###Day One - Discover
Day One will focus on identifying the product vision, understanding the business processes that inform the product vision, users’ needs, and regulatory and technology constraints that will inform the design and delivery of DIS.

###Day Two - Deliberate
Day Two will focus on refining the goals of the system, identifying opportunities for user delight, clarifying constraints, and defining system boundaries for DIS.

###Day Three - Decide
Day Three will focus on coalescing around strategy, ensuring completeness, developing artifacts for the solicitation package, and identifying next steps/timelines.

##Outcomes
By the end of the workshop, the group will have collectively developed artifacts including an acquisition strategy, vision statement, user stories, and other items as reflected in these two documents:

- Statement of Objectives Document
- Evaluation of Criteria Document
24 changes: 24 additions & 0 deletions needs-assessment.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
#Needs Assessment

##Overview
The needs assessment provides a rapid summary of information following initial contact with a client.

##Duration
1-2 hours

###What the product does:
1. Identifies overall product value
2. Provides UCD awareness to known problems
3. Outlines technical environment and known problems
4. Outlines acquisition / contracting environment and known problems

###Who the product is for:
First and foremost, the following individuals are critical to the success of the workshop:
2. The Product Owner
3. The Contracting Officer (CO)
4. Individuals with approval authority (e.g. CIO’s representative)
5. System Users (to the extent they’re available)

##Outcomes
Outcomes include a report on alignment of client with 18F Consulting offerings, and a summary of openness and preparedness
for change. The report includes the identification of service selection, as appropriate.
20 changes: 20 additions & 0 deletions product-template.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
#Title of Product

##Overview
Product Overview

###What the product does:
1. Define and clarify the product vision and key components of a *Performance Work Statement (PWS)* or *Statement of Objectives (SOO)*
2. Adopt a clear acquisition strategy and/or define requirements/constraints
3. Make decisions about key aspects of solicitation
4. Create artifacts that support all the above goals

###Who the product is for:
1. First and foremost, the following individuals are critical to the success of the workshop:
2. The Product Owner
3. The Contracting Officer (CO)
4. Individuals with approval authority (e.g. CIO’s representative)
5. System Users (to the extent they’re available)

##Outcomes
What the client gets.