diff --git a/When_to_use_Discovery.md b/When_to_use_Discovery.md new file mode 100644 index 0000000..04a0852 --- /dev/null +++ b/When_to_use_Discovery.md @@ -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... diff --git a/agile-kickoff-meeting.md b/agile-kickoff-meeting.md new file mode 100644 index 0000000..09fc3c6 --- /dev/null +++ b/agile-kickoff-meeting.md @@ -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. + diff --git a/discovery-sprint.md b/discovery-sprint.md new file mode 100644 index 0000000..ad7ac22 --- /dev/null +++ b/discovery-sprint.md @@ -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) + diff --git a/ghostwriting.md b/ghostwriting.md new file mode 100644 index 0000000..8628b6f --- /dev/null +++ b/ghostwriting.md @@ -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 diff --git a/needs-assessment.md b/needs-assessment.md new file mode 100644 index 0000000..50ea2df --- /dev/null +++ b/needs-assessment.md @@ -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. diff --git a/product-template.md b/product-template.md new file mode 100644 index 0000000..1c8dbb7 --- /dev/null +++ b/product-template.md @@ -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.