Federal Cloud Services Acquisition Hackathon
•Descargar como PPTX, PDF•
3 recomendaciones•3,350 vistas
This is the participant guide for Thursday, June 26's Cloud Computing Hackathon, an ASI Government Learning Path: Cloud event. Still time to register! http://aws.amazon.com/events/wwps/symposia/washington/ Let's learn & earn together.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (7)
Destacado
Destacado (20)
Similar a Federal Cloud Services Acquisition Hackathon
Similar a Federal Cloud Services Acquisition Hackathon (20)
Último
Último (20)
Federal Cloud Services Acquisition Hackathon
- 1. Federal Procurement of Cloud Services An Acquisition Hackathon June 2014
- 2. Page 2© 2014 ASI Government, Inc. An acquisition hackathon brings practitioners from both sides of the transaction (government and industry) into a problem solving environment to develop solutions that are shared with the broader community. What is an “Acquisition Hackathon”?
- 3. Page 3© 2014 ASI Government, Inc. Let’s Hack the Cloud!
- 4. Page 4© 2014 ASI Government, Inc. Solve Challenges, Earn Points, Advance Capabilities Challenge 1 Challenge 2 Challenge 3 The Cloud Acquisition Dictionary Describe the Customer’s Need Create an Acquisition Strategy Challenge 4 Challenge 5 Challenge 6 Identify Risks Create SLAs or a QAP Develop an Evaluation Methodology
- 5. Page 5© 2014 ASI Government, Inc. Challenge 1: Breaking Down Communication Barriers Rules of Game Play: • Multiple definitions for a term will be accepted • 1 point per definition • Lorem ipsum dolor sit amet, consectetur adipiscing elit. • Quisque lacus nibh, molestie vitae leo elementum, ultricies lacinia ante. • Fusce sagittis mauris ac semper venenatis. • In hac habitasse platea dictumst. • Donec justo mauris, accumsan ullamcorper ligula quis, ultrices volutpat risus. • Ut id scelerisque nulla. • We need to store non- sensitive public data • Providers must have a FedRAMP ATO • Customers will order services from a catalogue Plain Language Please!!
- 6. Page 6© 2014 ASI Government, Inc. Challenge 2: Describing Customer Need FUNCTION: PERFORMANCE: CHARACTERISTICS: What is performed or fulfilled? What problem is solved? What does it look like, how does it work, to what is it connected, etc? Defining the customer’s need is crucial to a successful acquisition. What are you buying, who is it for, and how will they use it?
- 7. Page 7© 2014 ASI Government, Inc. Challenge 2: Describing Customer Need Rules of Play • Review your group’s scope statement • Simplify it by describing the need in terms of its function, performance, and essential characteristics • 3 points available for completing the challenge IaaS PaaS SaaS +1 +1 +1
- 8. Page 8© 2014 ASI Government, Inc. Challenge 3: Acquisition Strategy Rules of Play • Select a contract type and method of procurement for your team’s scope statement • 3 points available • Earn 3 bonus points if you defend your selection with a logical argument EPA Incentive Price Redetermination LoE Term Award Fee Fixed Fee Incentive Fee Time & Materials Labor Hour
- 9. Page 9© 2014 ASI Government, Inc. Challenge 4: Populate the Open Risk Registry Rules of Play • Identify risks inherent to your acquisition strategy from Challenge 3. • Assign an impact and likelihood rating to each risk and plot them on a risk matrix • 1 point for each entry, 1 bonus point for crafting a mitigation strategy Fixed Price Contractor bears maximum risk & responsibility for costs Cost Government & contractor share the cost & technical risk Program and performance risk… …is everyone’s responsibility.
- 10. Page 10© 2014 ASI Government, Inc. Challenge 5: Your Choice! SLA Registry or QAP Rules of Play: Service Level Agreement Registry • Using the same acquisition strategy you selected in Challenge 4, identify the SLA’s that would maximize the effectiveness of your cloud contract • One point for each SLA Rules of Play: Quality Assurance Plan • Using the same acquisition strategy you selected in Challenge 4, identify the work that will require surveillance and the method used for surveillance • One point for each entry
- 11. Page 11© 2014 ASI Government, Inc. Challenge 6: Evaluation Strategy Rules of Play • Building on your previous efforts for your customer’s need and acquisition strategy, create an evaluation plan for a best value- tradeoff source selection • One point for each evaluation factor your team creates • 5 point bonus for devising a rating system addressing each of your evaluation factors Offer 1 Offer 2 Offer 3 Offer 4
- 12. Page 12© 2014 ASI Government, Inc. Let’s get to WORK
Notas del editor
- Purpose & Outcomes
- Make some joke about how this slide could get me arrested. Sorry NSA! Not that kind of hack!
- Encourage people to send in sample scope statements or solicitations for case study materials – if a group of practitioners wants to hack through a requirement they are working on, we will make that opportunity available to them. Ie, bring your own team! Come as a team! Quick fire presentations – 5 minutes per team [create a summary slide template for each group], held after challenge 1-3, 4-5, and then 6. This is the way that points get awarded. Conclude with a takeaway session – either a round the room or open sharing (depending on pace & number of participants)
- This will be a continuous challenge – terms & definitions will be posted to our “sticky wall” sandbox. Start this off during the team review of the sample scope statements. Two ways to play: identify terms you don’t understand, submit your understanding of the word / or your proposed definition. (Don’t worry if its wrong – we encourage everyone to continue posting definitions throughout the day – anytime something comes up, post it to the wall!!). Need to have some terms pre-populated – for example, SLAs. This is done while the teams review their scope statement Terms of art don’t make business easier. They can be misused and lead to confusion, or wielded for intimidation and deceit. Plus they annoy me sometimes. So NYU’s Governance Lab (@TheGovLab) created the Tech-Policy Dictionary, a project to “break down the barriers between tech and policy so we can all better understand each other.” It crowdsources shared knowledge to build consensus on technical terms and jargon. Words like “RFP” and “solicitation.” I loved the idea so much, I posted a companion Cloud Acquisition Dictionary. Anyone may contribute definitions for cloud-related terms to this worksheet I put on Google Drive. If we get enough interest, we can move this from a Drive document to a real product. In fact, the Gov Lab put their code on GitHub and are encouraging that others use it to build-out the Tech-Policy Dictionary. If you are a CLP-earner, I’ll award half a CLP for every 5 contributions you make.
- Cloud elevator speech? From the Agile class – for whom, what & why - better The Federal Acquisition Regulation (FAR) emphasizes three primary characteristics for writing requirements documents (FAR 11.002): Full and open competition to the maximum extent practicable Limited use of restrictive provisions Description in terms of function, performance, and essential physical characteristics Preference for commercial items Consistent with part 12 procedures as well.
- For the peer vote, each team will read / present their Function, Performance, Characteristic description for each type of service model. The audience (including the other teams) will have an opportunity to “upvote” the definition; 1 point for each upvote Here are some helpful hints:
- Syllogism part is going to be tricky…
- (c) Appropriate techniques should be applied to manage and mitigate risk during the acquisition of information technology. Techniques include, but are not limited to: prudent project management; use of modular contracting; thorough acquisition planning tied to budget planning by the program, finance and contracting offices; continuous collection and evaluation of risk-based assessment data; prototyping prior to implementation; post implementation reviews to determine actual project cost, benefits and returns; and focusing on risks and returns using quantifiable measures. But is that always the case? Could discuss the risk of overpaying for software or development projects, given the perverse outcomes created by misapplication of fixed price from Pat Shields to Everyone: FFP shifts all of FINANCIAL risk to contractor - but ONLY financial risk. Due to the contractor having assumed the financial risk, the risk to BOTH parties of a failure increases. The risk of devoting government expending additional resources to remedying issues increases. Risk of not getting the desired ourcome/need met at all increases.
- Once you understand your risks (technical, schedule, cost), you can create performance measures and other incentives that describe to the CSP what is most important about your service level. However, you must keep in mind that SLA’s are not free!
- Evaluating proposals is never an easy task, and it is perhaps more complicated when evaluating IT service proposals due to the variance of vendor solutions. This challenge will