Search form

You are here

PLAY 09 - Acquire Needed Resources

Every Information Sharing and Safeguarding (IS&S) Environment project is likely to need some form of procurement to acquire resources, even those being built in house. To improve the chances of success when contracting out development activities, acquiring resources, or acquiring items in the technology stack, we need to work with experienced budgeting and contracting officers. In cases where third parties are used to help build a service or supplement an in-house team, a well-defined contract can facilitate good development practices. Examples of outsourced services can include conducting research, prototyping, refining product requirements, evaluating open source alternatives, testing, and certification. Strong procurement support allows the flexibility to consider alternative solutions such as cloud computing, storage, and design services.

Desired Outcome:Internal staff are on board and contracts are in place with all suppliers required to achieve implementation.

Play Checklist

1. Budget includes research, discovery, and prototyping activities.

2. Process includes preferences for proven solution providers, such as those with product certifications or compliance certification (e.g., Springboard Certification Program).

8. Contract specifies that software and data generated by third parties remains under our control, and can be reused and released to the public as appropriate and in accordance with the law.

9. Contract allows us to use tools, services, and hosting from vendors with a variety of pricing models, including fixed fees and variable models like pay-for-what-you-use services.

10. Contract specifies a warranty period where defects uncovered by the public are addressed by the solution provider at no additional cost to the government.

11. Contract includes testing, or an independent testing contract is created for testing by a different, unrelated provider.

12. Contract includes a transition of services period and transition-out plan.

13. Evaluate hosting providers to ensure they are not simply data centers that market themselves as cloud hosting but require us to manage and maintain hardware directly. This outdated practice wastes time, weakens our disaster recovery plans, and results in significantly higher costs.

14. Resources are provisioned on demand, scale based on user demand, and are provisioned through open standards and the use of common interoperability profiles.

15. Resources are available in multiple regions.

16. Static assets are served through a content delivery network.

17. Application is hosted on commodity hardware.

Play Key Questions

1. What hardware does your service use to run?

2. What happens to your service when it experiences a surge in traffic or load?

3. How much capacity is available in your hosting environment?

4. How long does it take you to provision a new resource, like an application server?

5. How have you designed your service to scale based on demand?

6. How are you paying for your hosting infrastructure (e.g., by the minute, hourly, daily, monthly, fixed)?

7. Is your service hosted in multiple regions, availability zones, or data centers?

8. In the event of a catastrophic disaster to a datacenter, how long will it take to have the service operational?

9. What would be the impact of a prolonged downtime window?

10. How will testing best prove the solution’s ability to meet identified requirements?

11. What are the performance metrics defined in the contract (e.g., deliverable-based milestone, delivery-based payment after each module or capability is delivered)?

TechFAR Handbook, https://playbook.cio.gov/techfar/, (highlights the flexibilities in the Federal Acquisition Regulation that can help agencies implement plays from the Digital Services Playbook – http://playbook.cio.gov/ – that would be accomplished with acquisition support, with a particular focus on how to use contractors to support an iterative, customer-driven software development process)