Contract styles for services

Different types of contracts for services are typically available in a jurisdiction depending on the needs of the government agency and the project. Typically, services contracts are one of several styles:

Deliverables-based: In this style of contract, the agency defines a set of clearly articulated tasks and contracts for their completion by the contractor who is paid a fixed price regardless of the level of effort required. Sometimes the fixed price is paid in phases if a deliverable is large or takes time to complete (e.g., a certain portion is paid after a particular milestone is reached as negotiated). While this style of engagement ensures that the agency knows exactly what it is getting for exactly what price, if the tasks are new, different or ill-defined, the contractor is forced to increase the price for deliverables to account for the risk it must bear in agreeing to a fixed price. Sometimes the level of effort – even the tasks themselves – simply cannot be accurately determined ahead of time (e.g., development of a new feature whose requirements and specifications do not yet exist), and a deliverables-based contract may not be appropriate for those settings.

Hourly services/time and materials: In this style of contract, the agency defines a set of tasks but pays the contractor on an hourly basis for work performed to complete those tasks. Sometimes those tasks are defined quite broadly (e.g., “support the production operations of the IIS 24/7”). Usually, the agency and the contractor agree to smaller budgets for specific tasks and agree to closely monitor the progress and level of effort to ensure that resources are consumed within the overall budget scope and within the priorities of the agency. Often these types of contracts have a ceiling for a specified period of time, after which the agency and contractor assess the effectiveness of the work. This type of contract is good when the requirements and specifications of projects are less well-defined and when priorities of the agency are prone to shift and change, and also may be beneficial when an agile method of application development is being conducted. But this style of contract also requires careful management and cooperation by both the agency and the contractor to ensure effective use of resources.

“By the piece”: Some activities are so routinized that pricing for their completion can be effectively estimated “by the piece.” For example, a contract to perform on-boarding services for HL7 interoperability for provider sites may be a good candidate for “by the piece” pricing, where the contractor agrees to provide a standard set of services per practice for a standard price. Assuming an agency can determine how many iterations of the activity are required or can set a ceiling on the number of iterations, this can be an effective way of managing costs for certain aspects of a project.

Considerations

• If any of the template provisions of the contract seem inappropriate or unnecessarily onerous for the bidders given the nature of the contract, discuss your concerns early with procurement staff to either come to understand why the provision(s) is important to leave as-is or to come to agreement on an alternative.
• It does you no good to have a detailed PWS in the solicitation, only to craft a “loose” and vague contract. The contract is what you have to live with and what will govern decisions and actions, including resolving disputes. Your contract should have at least the same level of specificity, concreteness and precision as your solicitation documents.
• When crafting your contract, keep in mind the “the four corners doctrine” which says that all relevant terms and conditions for the contract should be included within the “four corners” of one document. This might also include service level agreements (SLA) for application hosting.
• In inserting provisions related to penalties, avoid including penalties you aren’t really willing to stand behind, or which would cost you more to enforce than you might save.
• For contracts that include application hosting by the contractor, make sure you and the contractor understand any insurance or other requirements required by your jurisdiction. These are likely boilerplate requirements for your jurisdiction that may need to be negotiated given the small size of IIS vendor companies.
• For a full list of application hosting and other typical IT services you might include in a contract, see the IIS IT Services Worksheet in the Tool Download section below.
• If you are procuring a new IIS platform, allow for a transition period. Seldom is a “clean cut” ideal since the old system has to be decommissioned after the data is cleansed and migrated, and the data in the old system properly dispositioned.
• If you are including the possibility or renewals or “option years,” be sure to create your own tickler system for when to begin the renewal process. Do not count on procurement, central IT or even the vendor to remind you when to begin the process. Failing to begin the process on time can result in lapse in service and support.
• Regular meetings with leadership on both the program and vendor side can be extremely beneficial to discuss progress, risks, what is going well, what could be improved, etc. You want to get out in front of any dissatisfactions or disagreements, and avoid the situation of jumping too quickly to penalties. The contractor will want to know if they are not meeting your expectations prior to financial penalties being levied.