Digital Acquisition MVP Release 3 –Classroom Session, Day 3

Digital Acquisition MVP Release 3 –Classroom Session, Day 3
November 2016 Classroom setup notes: Write a note on the whiteboard to ensure that participants are sitting in their live digital assignment teams. Get Lean Canvas posters set up.

Day 3 – Lean Canvas and MAP Case Study
Day 3 Agenda Day 3 – Lean Canvas and MAP Case Study Morning Using the Lean Acquisition Canvas Competing, and WINNING, in the Arena of Ideas Lunch (12:00-1:00 pm) Afternoon Guest Speakers SOOs, SOWs, PWSs…Oh My! Facilitator: Melissa Duration: 10 minutes Timing: 8:00-8:10 am Facilitator Notes : Begin with telling the cohort that today we will dive in to the Lean Canvas and MAP Case Study. We will spend some time this morning talking through using the lean canvas and do an exercise together. Then we will discuss After lunch, we will have two guest speakers 1. Challenge.gov 2. Acuman We will then be joined by guest speakers (we need to add content to this once we know who they are and what they will talk about)

Using the Lean Acquisition Canvas
Facilitator: Traci/USDS/Will Randolph Duration: 2 hours and 15 minutes Timing: 8:15-10:30 am Facilitator Notes : In this session, the LDA teams will compare notes on the lean canvases they completed on their own, discuss tradeoffs, and then come to agreement on a group acquisition strategy. Teams will use USDS’ canvases and/or white boards/sticky pads in the training room to complete this activity. Facilitators will be designated for each group to encourage “outside the box” thinking.

Using the Lean Acquisition Canvas
In Release 3A, you were asked to: Complete the lean acquisition canvas template with the MAP case or with logical extensions of available information to form a vision of what and how this requirement will be acquired. For any section(s) that you are not able to credibly complete, please identify what information is required that would prevent you from completing the strategy. Identify what strategy you would use to secure the outstanding information needed to complete your acquisition strategy. Facilitator: Traci and Facilitators Duration: 5 minutes Timing: 8:15-8:20 am Facilitator Notes : Review what they were supposed to do on their own prior to coming to class. Ask them to pull up their notes and draft acquisition strategy so they can discuss. While they are getting ready, ensure the lean canvas posters are on the wall and sticky notes are ready for the exercise.

Activity Overview The Situation The Challenge
Using the MAP Case Study, in your teams, compare notes on your individual lean canvases. The Challenge Facilitator: Traci and Facilitators Duration: 5 minutes Timing: 8:20-8:25 am Facilitator Notes : Read the slide and then move to the next slide where we have the instructions. As a team, develop one consolidated lean canvas for your MAP Case Study. As part of this process, you will document trade-off decisions, areas where you still need information, and critical decision points.

Part 1: Develop a Team Lean Canvas
Work in your teams to develop a consolidated lean acquisition canvas on paper as a team Two teams will combine to discuss and develop one consolidated lean canvas Structure Work in your teams to develop a lean canvas Prepare a verbal briefing to share what choices you made in combining your strategies and any tradeoffs made in the process Be prepared to share your results with the class Instructions Facilitator: Traci and Facilitators Duration: 1 hour 15 minutes Timing: 8:25-9:40 am Facilitator Notes : Let them know they will have 1 hour to complete this exercise. Leave it on this slide until it is time to move on to part 2. The facilitators will be walking around the room and engaging with the teams, so let them know that in advance. Afterwards, teams will walk around and look at each other's work (part 2). Take 30 minutes to complete your team canvas Take 45 minutes to review other teams’ canvases and develop a joint strategy with sticky notes Time

Team Briefings Part 2: Team Brief Out
What was your team strategy and why? What were your tradeoffs? What changes did you make after reviewing the other lean canvases in the room? Team Briefings Facilitator: Traci and Facilitators Duration: 50 minutes Timing: 9:40-10:30 am Facilitator Notes : Bring the students back into their teams and instruct them to share what they observed. As they share, have them determine if they would like to make updates to their own canvas. Have them document their observations, and changes that they inspired. Give them 10 minutes to do this portion. For the last 40 minutes, they will report out verbally to answer these three questions: What was your team strategy and why? What were your tradeoffs? What changes did you make after reviewing the other lean canvases in the room?

Morning Break Duration: 15 minutes Timing: 10:30-10:45am
Presented by: Melissa Facilitator Notes: Instruct participants to take a 15 minute break. Direct to restrooms and water cooler.

Competing, and WINNING, in the Arena of Ideas
“How do you get people to do what you want?” Duration: 75 minutes Timing: 10:45-12:00 pm Presented by: Will Randolph Facilitator Notes: How do you influence – what is it that makes people make one decision over another? Old model of controlling/mutual collaboration Never abandon your team Tactical convos – empathizing Knowing team & readiness for change

What is Influence? in·flu·ence ˈinflo͝oəns/ noun 1.
the capacity to have an effect on the character, development, or behavior of someone or something, or the effect itself. "the influence of television violence" synonyms: effect, impact verb have an influence on. "social forces influencing criminal behavior" synonyms: affect, have an impact on, impact, determine, guide, control, govern, decide; Duration: 5 minutes Timing: 10:45-10:50 pm Presented by: Will Randolph Facilitator Notes: At a basic level, influence is changing someone else’s behavior. However, in the government, that is not an easy task. It is more of an art form, to be learned over time, and what works in one situation will not work in others. And let’s not forget, that at times, you may not have the appropriate authority to influence your superiors. So how do we become change agents?

The entire world revolves around penalties and rewards?
The World Today The entire world revolves around penalties and rewards? True False Duration: 15 minutes Timing: 10:50-11:05 pm Presented by: Will Randolph Facilitator Notes: IS this true of false? Ask the students to raise their hands. For those who say True, have them share examples of why. Then do the same for those who say false.

New Strategic Mindset Shift
So How Does It Work? So, what makes people decide, to make one choice over another? Today Old School Way New Strategic Mindset Shift “If your ideas aren’t being embraced you haven’t built in, articulated and/or demonstrated enough value.” Controlling, imposing, monitoring, restrictive, managed, authoritarian, autocratic… Duration: 20 minutes Timing: 11:05-11:25 pm Presented by: Will Randolph Facilitator Notes:

Tactical Approaches Empathize Ask the right questions
Know your stuff (do the homework!) Look the part Build the relationships… ahead of time See the outcome yourself Believe in your position Be able to clearly articulate & demonstrate the value Respect others’ decision-making process Visualize and articulate the next step Duration: 20 minutes Timing: 11:25-11:45 pm Presented by: Will Randolph Facilitator Notes: 7/38/55 communications delivery construct

is counting on you to lead…
Final Thought As the Contracting Officer, the entire mission-centric acquisition system is counting on you to lead… Don’t OD on ‘Hopium’! Duration: 10 minutes Timing: 11:45-11:55 pm Presented by: Will Randolph Facilitator Notes:

Questions? Thank you Duration: 5 minutes Timing: 11:55-12:00 pm
Presented by: Will Randolph Facilitator Notes:

Lunch Timing: 1 hour Presented by: Melissa Facilitator Notes:
The lunch break will run from 12-1:00pm.

Guest Speakers Challenge.gov Facilitator: Challenge.gov
Duration: 1 hour Timing: 1:00-2:30 pm Facilitator Notes: Introduce the guest speaker and share any background on them and what they are joining us today to present. (Need Traci to add)

Afternoon Break Duration: 15 minutes Timing: 2:30-2:45am
Presented by: Melissa Facilitator Notes: Instruct participants to take a 15 minute break. Direct to restrooms and water cooler.

SOOs, SOWs, PWSs…Oh My! Facilitator: Traci Duration: 10 minutes
Timing: 2:45-2:50 PM Facilitator Notes: Traci offered to develop this lesson, so we have some starter slides for her.

To SOO or not to SOO…That is the question!
First, lets get calibrated; compare and contrast the three types of requirements documents (SOW, PWS, and SOO). Select the “right” requirements document based on the nature of the work. What other considerations will influence the ultimate selection of the most appropriate requirements document for the specific requirement, within the current and near term organization? Facilitator: Traci Duration: 10 minutes Timing: 2:50-2:55 PM Facilitator Notes : We need to tee up the discussion we’ll be having for the next couple of hours. First, every knows what an SOO, PWS and SOW is, but it’s important to get everyone thinking about the key attributes of each, where they differ, so there can be meaningful discussion about which one is best for which situations. Part of the discussion that follows will address the differences between “Performance Based” and “Traditional” acquisition approaches. Again, everyone in the class will know this, but we need to establish a baseline of understanding to support the discussion and the exercise they’ll do later today. It may be important to note that there are no absolute and definitive “lines of demarcation” between the continuum of SOW – PWS – SOO, and any energy spent trying to clarify this distinction is of little value. Then we’ll talk about how to look at the specific program requirements and determine which requirements document aligns best with the requirements (based either on how they ARE defined, or COULD BE defined, by the requirements owners). While the ultimate selection will depend on a variety of factors, it’s helpful to consider the requirements themselves, in isolation first. (sometimes we have to create an alternate reality to allow us to recognize what may be possible) Finally, the reality is there are many other considerations that will influence the final selection of the most appropriate requirements document. As we look at these other considerations, we’ll see if they are significant enough to move us from the choice we made in isolation. These other considerations have a lot to do with the maturity of the organization. Maturity, as used here, refers to maturity using performance based acquisition, and maturity with the more current and forward thinking concepts of effectively procuring digital services.

How should you start with requirements docs??
Facilitator: Traci Duration: 10 minutes Timing: 2:50-2:55 PM Facilitator Notes : We need to tee up the discussion we’ll be having for the next couple of hours. First, every knows what an SOO, PWS and SOW is, but it’s important to get everyone thinking about the key attributes of each, where they differ, so there can be meaningful discussion about which one is best for which situations. Part of the discussion that follows will address the differences between “Performance Based” and “Traditional” acquisition approaches. Again, everyone in the class will know this, but we need to establish a baseline of understanding to support the discussion and the exercise they’ll do later today. It may be important to note that there are no absolute and definitive “lines of demarcation” between the continuum of SOW – PWS – SOO, and any energy spent trying to clarify this distinction is of little value. Then we’ll talk about how to look at the specific program requirements and determine which requirements document aligns best with the requirements (based either on how they ARE defined, or COULD BE defined, by the requirements owners). While the ultimate selection will depend on a variety of factors, it’s helpful to consider the requirements themselves, in isolation first. (sometimes we have to create an alternate reality to allow us to recognize what may be possible) Finally, the reality is there are many other considerations that will influence the final selection of the most appropriate requirements document. As we look at these other considerations, we’ll see if they are significant enough to move us from the choice we made in isolation. These other considerations have a lot to do with the maturity of the organization. Maturity, as used here, refers to maturity using performance based acquisition, and maturity with the more current and forward thinking concepts of effectively procuring digital services.

Being the Acquisition Product Owner
Use the digital service methods to start the conversation Determine the Problem Statement What is the hypothesis that the outcome of this acquisition going to test? What are the assumptions that exist? How will you know it has succeeded? Use brand strategy to make sure everyone is on the same page for what the acquisition is and what it isn’t Create a Product Vision for your objective/acquisition Facilitator: Traci Duration: 10 minutes Timing: 2:50-2:55 PM Facilitator Notes : We need to tee up the discussion we’ll be having for the next couple of hours. First, every knows what an SOO, PWS and SOW is, but it’s important to get everyone thinking about the key attributes of each, where they differ, so there can be meaningful discussion about which one is best for which situations. Part of the discussion that follows will address the differences between “Performance Based” and “Traditional” acquisition approaches. Again, everyone in the class will know this, but we need to establish a baseline of understanding to support the discussion and the exercise they’ll do later today. It may be important to note that there are no absolute and definitive “lines of demarcation” between the continuum of SOW – PWS – SOO, and any energy spent trying to clarify this distinction is of little value. Then we’ll talk about how to look at the specific program requirements and determine which requirements document aligns best with the requirements (based either on how they ARE defined, or COULD BE defined, by the requirements owners). While the ultimate selection will depend on a variety of factors, it’s helpful to consider the requirements themselves, in isolation first. (sometimes we have to create an alternate reality to allow us to recognize what may be possible) Finally, the reality is there are many other considerations that will influence the final selection of the most appropriate requirements document. As we look at these other considerations, we’ll see if they are significant enough to move us from the choice we made in isolation. These other considerations have a lot to do with the maturity of the organization. Maturity, as used here, refers to maturity using performance based acquisition, and maturity with the more current and forward thinking concepts of effectively procuring digital services.

To SOO or not to SOO…That is the question!
Easy Elements to include in the SOO: Product Vision = Objective “PRODUCT VISION: The purpose of the Customer Relationship Management (CRM) platform will be to maintain a centralized view of all interactions and improve the outreach experience to citizens contacting and engaging with mission-critical efforts” Digital Service Playbook Objectives See Solicitation Builder in TechFAR Hub Have the metrics and Definition of Done proposed by vendors Facilitator: Traci Duration: 10 minutes Timing: 2:50-2:55 PM Facilitator Notes : We need to tee up the discussion we’ll be having for the next couple of hours. First, every knows what an SOO, PWS and SOW is, but it’s important to get everyone thinking about the key attributes of each, where they differ, so there can be meaningful discussion about which one is best for which situations. Part of the discussion that follows will address the differences between “Performance Based” and “Traditional” acquisition approaches. Again, everyone in the class will know this, but we need to establish a baseline of understanding to support the discussion and the exercise they’ll do later today. It may be important to note that there are no absolute and definitive “lines of demarcation” between the continuum of SOW – PWS – SOO, and any energy spent trying to clarify this distinction is of little value. Then we’ll talk about how to look at the specific program requirements and determine which requirements document aligns best with the requirements (based either on how they ARE defined, or COULD BE defined, by the requirements owners). While the ultimate selection will depend on a variety of factors, it’s helpful to consider the requirements themselves, in isolation first. (sometimes we have to create an alternate reality to allow us to recognize what may be possible) Finally, the reality is there are many other considerations that will influence the final selection of the most appropriate requirements document. As we look at these other considerations, we’ll see if they are significant enough to move us from the choice we made in isolation. These other considerations have a lot to do with the maturity of the organization. Maturity, as used here, refers to maturity using performance based acquisition, and maturity with the more current and forward thinking concepts of effectively procuring digital services.

Performance Work Statement (PWS)
More definition in a PWS: Taking more responsibility for the process Defining the type of agile development to be used: Scrum/ Kanban, etc. Maybe defines what metrics or elements of the definition of done will be May provide User Story guidelines, sizing definition, size and composition of team, or length of iteration “Quality assurance (QA) sessions are where requirements turn into detailed design. It is in this phase that the pro- forma workflows will be identified and reviewed. Essentially all information that is necessary to build the product is captured in this phase and it is reflected to the stakeholder team for verification. As part of these QA sessions, each [Stakeholder] will be required to verify and sign-off on the [Project Features] determined in the previous RGSs. The requirements documents will also be verified as part of these sessions.” Facilitator: Traci Duration: 10 minutes Timing: 2:50-2:55 PM Facilitator Notes : We need to tee up the discussion we’ll be having for the next couple of hours. First, every knows what an SOO, PWS and SOW is, but it’s important to get everyone thinking about the key attributes of each, where they differ, so there can be meaningful discussion about which one is best for which situations. Part of the discussion that follows will address the differences between “Performance Based” and “Traditional” acquisition approaches. Again, everyone in the class will know this, but we need to establish a baseline of understanding to support the discussion and the exercise they’ll do later today. It may be important to note that there are no absolute and definitive “lines of demarcation” between the continuum of SOW – PWS – SOO, and any energy spent trying to clarify this distinction is of little value. Then we’ll talk about how to look at the specific program requirements and determine which requirements document aligns best with the requirements (based either on how they ARE defined, or COULD BE defined, by the requirements owners). While the ultimate selection will depend on a variety of factors, it’s helpful to consider the requirements themselves, in isolation first. (sometimes we have to create an alternate reality to allow us to recognize what may be possible) Finally, the reality is there are many other considerations that will influence the final selection of the most appropriate requirements document. As we look at these other considerations, we’ll see if they are significant enough to move us from the choice we made in isolation. These other considerations have a lot to do with the maturity of the organization. Maturity, as used here, refers to maturity using performance based acquisition, and maturity with the more current and forward thinking concepts of effectively procuring digital services.

Statement of Work (SOW) : Owning the HOW
Allows for no deviation from defined tasks and responsibilities Companies just need to prove they can execute and can hire the appropriate skill sets Not recommended for digital services… unless expert level program office For more information: Facilitator: Traci Duration: 10 minutes Timing: 2:50-2:55 PM Facilitator Notes : We need to tee up the discussion we’ll be having for the next couple of hours. First, every knows what an SOO, PWS and SOW is, but it’s important to get everyone thinking about the key attributes of each, where they differ, so there can be meaningful discussion about which one is best for which situations. Part of the discussion that follows will address the differences between “Performance Based” and “Traditional” acquisition approaches. Again, everyone in the class will know this, but we need to establish a baseline of understanding to support the discussion and the exercise they’ll do later today. It may be important to note that there are no absolute and definitive “lines of demarcation” between the continuum of SOW – PWS – SOO, and any energy spent trying to clarify this distinction is of little value. Then we’ll talk about how to look at the specific program requirements and determine which requirements document aligns best with the requirements (based either on how they ARE defined, or COULD BE defined, by the requirements owners). While the ultimate selection will depend on a variety of factors, it’s helpful to consider the requirements themselves, in isolation first. (sometimes we have to create an alternate reality to allow us to recognize what may be possible) Finally, the reality is there are many other considerations that will influence the final selection of the most appropriate requirements document. As we look at these other considerations, we’ll see if they are significant enough to move us from the choice we made in isolation. These other considerations have a lot to do with the maturity of the organization. Maturity, as used here, refers to maturity using performance based acquisition, and maturity with the more current and forward thinking concepts of effectively procuring digital services.

Tips for Requirements Documents
Make the language simple and easy to understand Avoid repetition and streamline the format Include personas of your end users to bring them to for forefront of the acquisition Add journeymaps, product roadmaps, process flows of the “as is” process, or diagrams depicting current environment to help with scoping efforts Utilize attachments as a way of referencing technical environment, potential user stories, MVP should haves, could haves or must haves instead of hard coding them into the Requirements Document. Facilitator: Traci Duration: 10 minutes Timing: 2:50-2:55 PM Facilitator Notes : We need to tee up the discussion we’ll be having for the next couple of hours. First, every knows what an SOO, PWS and SOW is, but it’s important to get everyone thinking about the key attributes of each, where they differ, so there can be meaningful discussion about which one is best for which situations. Part of the discussion that follows will address the differences between “Performance Based” and “Traditional” acquisition approaches. Again, everyone in the class will know this, but we need to establish a baseline of understanding to support the discussion and the exercise they’ll do later today. It may be important to note that there are no absolute and definitive “lines of demarcation” between the continuum of SOW – PWS – SOO, and any energy spent trying to clarify this distinction is of little value. Then we’ll talk about how to look at the specific program requirements and determine which requirements document aligns best with the requirements (based either on how they ARE defined, or COULD BE defined, by the requirements owners). While the ultimate selection will depend on a variety of factors, it’s helpful to consider the requirements themselves, in isolation first. (sometimes we have to create an alternate reality to allow us to recognize what may be possible) Finally, the reality is there are many other considerations that will influence the final selection of the most appropriate requirements document. As we look at these other considerations, we’ll see if they are significant enough to move us from the choice we made in isolation. These other considerations have a lot to do with the maturity of the organization. Maturity, as used here, refers to maturity using performance based acquisition, and maturity with the more current and forward thinking concepts of effectively procuring digital services.

User Story Examples: Representative

Definition of Done – Example 1

User Story Examples: Actual
As a website user, I need a home button so that I can return to the homepage with a single click or tap Acceptance Criteria: Home button is visible on all pages Clicking the home button returns the user to the homepage Home button is reconizable Facilitator: Traci Duration: 10 minutes Timing: 2:50-2:55 PM Facilitator Notes : We need to tee up the discussion we’ll be having for the next couple of hours. First, every knows what an SOO, PWS and SOW is, but it’s important to get everyone thinking about the key attributes of each, where they differ, so there can be meaningful discussion about which one is best for which situations. Part of the discussion that follows will address the differences between “Performance Based” and “Traditional” acquisition approaches. Again, everyone in the class will know this, but we need to establish a baseline of understanding to support the discussion and the exercise they’ll do later today. It may be important to note that there are no absolute and definitive “lines of demarcation” between the continuum of SOW – PWS – SOO, and any energy spent trying to clarify this distinction is of little value. Then we’ll talk about how to look at the specific program requirements and determine which requirements document aligns best with the requirements (based either on how they ARE defined, or COULD BE defined, by the requirements owners). While the ultimate selection will depend on a variety of factors, it’s helpful to consider the requirements themselves, in isolation first. (sometimes we have to create an alternate reality to allow us to recognize what may be possible) Finally, the reality is there are many other considerations that will influence the final selection of the most appropriate requirements document. As we look at these other considerations, we’ll see if they are significant enough to move us from the choice we made in isolation. These other considerations have a lot to do with the maturity of the organization. Maturity, as used here, refers to maturity using performance based acquisition, and maturity with the more current and forward thinking concepts of effectively procuring digital services.

Definition of Done – Example 2
Acceptance criteria met Code is reviewed by another development team member Test cases are written Unit tests and UI automation tasks are written Feature is tested for accessibility Feature is tagged for analytics Facilitator: Traci Duration: 10 minutes Timing: 2:50-2:55 PM Facilitator Notes : We need to tee up the discussion we’ll be having for the next couple of hours. First, every knows what an SOO, PWS and SOW is, but it’s important to get everyone thinking about the key attributes of each, where they differ, so there can be meaningful discussion about which one is best for which situations. Part of the discussion that follows will address the differences between “Performance Based” and “Traditional” acquisition approaches. Again, everyone in the class will know this, but we need to establish a baseline of understanding to support the discussion and the exercise they’ll do later today. It may be important to note that there are no absolute and definitive “lines of demarcation” between the continuum of SOW – PWS – SOO, and any energy spent trying to clarify this distinction is of little value. Then we’ll talk about how to look at the specific program requirements and determine which requirements document aligns best with the requirements (based either on how they ARE defined, or COULD BE defined, by the requirements owners). While the ultimate selection will depend on a variety of factors, it’s helpful to consider the requirements themselves, in isolation first. (sometimes we have to create an alternate reality to allow us to recognize what may be possible) Finally, the reality is there are many other considerations that will influence the final selection of the most appropriate requirements document. As we look at these other considerations, we’ll see if they are significant enough to move us from the choice we made in isolation. These other considerations have a lot to do with the maturity of the organization. Maturity, as used here, refers to maturity using performance based acquisition, and maturity with the more current and forward thinking concepts of effectively procuring digital services.

SOO Selection Activity: A Quick Poll
In Iteration 3.B self-directed learning, you were asked to select one of three SOOs that would be the best fit for your acquisition strategy for the MASP Case Study. Which did you choose? SOO #1: Learn the Process SOO #2: Select Your Technology SOO #3: Digital Minimum Viable Product (MVP) Facilitator: Traci Duration: Timing: Facilitator Notes : Based on the poll results, have the cohort move into table based upon their SOO selection. Then begin the exercise in the next section.

Summary & Preview of Tomorrow
Facilitator: Melissa Duration: 5 minutes Timing: 3:55-4:00 pm Notes: Explain that you want to end with a brief wrap-up and reminders about tomorrow.

Special Brown Bag Session
Day 4 Agenda Day 4 Morning MAP Case Study: SOO Selection Putting It All Together Security Considerations LUNCH Special Brown Bag Session Afternoon Acquisition Package Vendor Roundtable Facilitator: Melissa Duration: 5 minutes Timing: 3:55-4:00 pm Notes: Explain that we’ll be reviewing the process of building the key elements of the RFQ and putting everything together. There is a special “brown-bag” lunch if you would like to have lunch in the classroom and ask any questions you have to the USDS team and facilitators. Then, in the afternoon, we’ll be joined by a guest panel for a round table. Any questions/concerns? Feedback about what you liked about today? Expectations: There is a special “brown-bag” lunch if you would like to have lunch in the classroom and ask any questions you have to the USDS team and facilitators.

Digital Acquisition MVP Release 3 –Classroom Session, Day 3

Similar presentations

Presentation on theme: "Digital Acquisition MVP Release 3 –Classroom Session, Day 3"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Digital Acquisition MVP Release 3 –Classroom Session, Day 3

Similar presentations

Presentation on theme: "Digital Acquisition MVP Release 3 –Classroom Session, Day 3"— Presentation transcript:

Similar presentations

About project

Feedback