Creating a performance work statement
| Module 1 | Planning |
Unit 1
|
Unit 2
|
Unit 3
|
Unit 4
|
Unit 5
| |
|---|---|---|---|---|---|---|---|
| Module 2 | Solicitation |
Unit 1
|
Unit 2
|
Unit 3
|
Unit 4
|
Unit 5
| |
| Module 3 | Contracting |
Unit 1
|
Unit 2
|
Unit 3
|
Unit 4
|
Unit 5
| |
| Module 4 | Additional resources |
Unit 1
|
Unit 2
|
Unit 3
|
Unit 4
|
Unit 5
|
Unit 6
|
| Module 5 | All toolkit downloads |
Unit 1
|
The headings used below are typical of a PWS. For more detail and sample language, see the downloadable template below.
Background and need
This section provides a high-level overview of the context for the procurement, including information on your IIS program. This could include background information such as the goal of the platform, the mission or vision of the IIS, primary functions of IIS, organizational responsibility and reasons for procurement.
Procurement objectives
This section is typically a brief and concrete statement of what you want achieved, including the desired benefits to your program. The objectives should clearly reflect the scope of the procurement, which will be further defined in the next section. At this early point, the objectives do not necessarily need to be time-bound, although you may already have an overall timeline in mind, in which case including some milestone dates can be helpful for the bidders to know as they think about how to resource the project.
Scope of work
The scope of work section gives you the opportunity to describe the product(s) and services you need from the perspective of the bidder; that is, what you need the bidder to deliver or do, both at a fairly high level and in terms of major activities. The scope statement must match the procurement objectives and the requirements as stated later in the PWS and may include specific timeframes and/or specific deliverables. Ensuring internal consistency across sections of the PWS is critical to avoid confusion on the part of bidders.
Technical requirements (primarily for software procurements)
This section will likely be the one requiring the most preparatory work, ideally started in the planning phase. Defining the functional and non-functional (e.g., security, usability, scalability) requirements for the IIS system itself is the primary responsibility of the IIS program in a procurement. It is the one part of a procurement that should not be determined solely by others, such as a central IT office—though they may have their own suggestions, constraints and requirements depending on the IT governance process, IT environment and expected deployment plans.
The requirements define what you need the IIS to do to support the work of the immunization program. Requirements define the “what,” not the “how,” of information system functionality. You can trace back most frustrations with software to a lack of clear requirements or poor execution of those requirements.
Services to be delivered/contractor performance requirements
This section of a PWS specifies the tasks you want the contractor to perform and the services to be delivered. Lack of specificity and clarity in this section is a common cause of later contract disputes. It is critical that you be clear and concrete in writing what it is you want the contractor(s) to do. It can be very easy to make unconscious assumptions in listing desired services/tasks. Have the list reviewed by several immunization program and perhaps procurement staff to ensure completeness and precision: Does everyone interpret the wording in the same way?
How many "nines?"
In stating requirements for system up-time, it is common to use a percentage as a metric for system reliability and accessibility. But what percentage is most appropriate?
“Five-nines” (99.999%) is considered the holy grail of system reliability, which translates to 5 minutes, 15 seconds or less of downtime per year.
“Four-nines” (99.99%) allows for 52 minutes, 32 seconds downtime in a year. And 99.9% means the system could be down up to 8 hours, 46 minutes in a year.
What’s the right number for you? Only you can decide. But know that you will pay more—perhaps much more—for every “nine” you add to the percentage!
A comprehensive listing of typical IT service expectations of a vendor or central IT can be found in the IIS IT Services Worksheet below under Tool Downloads. The sample services provide a starting place for assemblig your own service requirements for your solicitation and/or contract.
Special knowledge, skills and abilities required
This section might include information such as the organization of the IIS and immunization programs (including staffing), central IT, the current hosting situations, the provider/user base, jurisdictional security policies and requirements, or knowledge and skills required by the successful bidder.
Hosting requirements
Hosting of complex information systems outside of the public health agency, either with a software vendor or “in the cloud,” is increasingly being adopted across government, healthcare and other industries. Cloud hosting enables storage and processing power to be scaled up or down based on budget and needs. Hosting of IIS, including any or all of the various instances (development, testing, training, production), can enable an IIS program to operate without central IT limitations that might negatively impact IIS performance, availability or other factors. Note that a decision to host outside of the agency will likely still require participation and often agreement by the central IT organization.
In the planning phase of your procurement process for IIS software, you should have determined whether hosting outside of the jurisdiction is a possibility and, if so, what technical and policy (e.g., security, liability) requirements you and/or the contractor must meet. Cloud security may be a concern, but large cloud service providers such as Amazon Web Services can provide robust state-of-the-art security protections that likely exceed what most units of government could provide.
Schedule and period of performance
The schedule in a PWS provides the timeframes within which the services and deliverables are to be provided. It provides a clear roadmap for the sequencing of deliverables based on the project’s requirements and services throughout the period of performance. As such, it helps bidders know how to resource the different phases of the project in terms of number of staff and skills sets. Remember that your own staffing level and capability can often impact the contractor’s ability to adhere to a schedule since your program’s review and acceptance testing obligation can be a time-consuming activity for your staff.
Place of performance
This section describes the location of the services to be provided.
Reporting
This section specifies how and when you want the successful bidder to report both progress on the requirements or deliverables and on expenditures. You may also include in this section (or elsewhere) a requirement for incident reporting for certain defined severity levels. Ideally, the expenditure reporting is clearly tied to the activities undertaken in the same reporting period. You may specify the report style (e.g., verbal reports allowed initially but written reports within five days, or written reports in a particular format), the schedule (e.g., on the 5th of every month or upon completion of each deliverable), to whom to send reports, and through what means (e.g., via email, or posting to a project wiki).
Other or special considerations
This last section might include information such as the organization of the IIS and immunization programs (including staffing), central IT, the current hosting situations, the provider/user base, jurisdictional security policies and requirements, or knowledge and skills required by the successful bidder.
Attachments/references/appendices
These might include your requirements; a glossary of terms; any third-party modules currently used in conjunction with the IIS (e.g., SmartyStreets, message quality evaluation [MQE] tool, etc.); how the current IIS supports immunization or other program activities (e.g., AFIX, VFC, assessment, surveillance); vital record loads; or other background information that might help the bidder understand the current state you want to functionally maintain into the future.
Your jurisdiction’s PWS (or SOW or SOO) template may have other sections not discussed here. As always, defer to your jurisdiction’s procurement experts.
Tool downloads
Describe functional requirements
Performance Work Statement Template
Identify and document required IT services
This worksheet provides sample information technology (IT) related services that immunization/IIS programs might expect from an IT service provider such as a vendor. A list of “typical” immunization information system (IIS) services is provided, along with a description of each service and possible outputs/deliverables to include in a service level agreement (SLA) or other contractual mechanism.