The QITC framework
In August 2017, the Queensland State Government introduced the new Queensland Information Technology Contracting (QITC) framework for procurement of information and communications technology (ICT) products and services by Queensland Government.
In this QWIK QITC Series, we are providing general information in respect of how the framework operates.
In the previous edition of QWIK QITC Series, we considered the key differences between the QITC framework and the previous GITC framework, including that suppliers no longer need to be accredited under QAssure under QITC, and certain high-level differences in terminology and risk profile. We also considered whether parties to existing GITC contracts should seek to contract under their existing terms, or the new QITC contracts.
In this edition of the QWIK QITC Series, we will consider the manner in which Government organisation requirements and specifications are dealt with in key QITC contract documents.
ICT contracts often set out the specifications and requirements for the goods and services in the contract to provide some certainty to the buyer and supplier regarding the contract’s deliverables. There are also usually contractual mechanisms for the parties to agree changes to the requirements as goal posts move over the life of the contract. Sometimes, parties even adopt an “agile” approach which keeps the requirements and specifications fluid and able to rapidly and flexibly respond to change.
When determining the specifications for an ICT contract, it is important for the business and technical teams of both parties to work together to draft realistic requirements that can achieve the buyer’s desired outcomes. Without this coordination, there is a risk that the business teams can agree to over-ambitious targets and leave the technical teams to find a way to get a square peg into a round hole. Conversely, the technical teams may not have sufficient oversight of the desired business outcomes to provide a solution that meets all the business teams’ preconceived goals.
Where the parties have drafted and agreed requirements and specifications for their ICT project, there are a number of ways that these, and other supporting documentation, can be incorporated into a QITC contract.
Determining 'Requirements' and 'Specifications'
The QITC framework utilises two key 'terms' to describe the nature of the products and services – 'Requirements' and 'Specifications'. Each of these terms are used in the General Contract and the Comprehensive Contract (for a refresher on these documents, please see the first edition of the QWIK QITC Series.
Requirements is an overarching term - generally, the Requirements mean the standards, specifications and other requirements for any deliverables and performance of the supplier’s obligations under the QITC contract. The Requirements include the Specifications.
Specifications (which form part of the Requirements) are more narrowly defined – generally, the Specifications mean the specific requirements which are set out and described more fully in the Contract Details and/or the Module Order Forms. In respect of any licensed software, hardware and as-a-service contracts, Queensland Government guidance notes indicate that the position by Government entities using the QITC may be that the Requirements are taken to incorporate by reference any published specifications for the products, including those that are available on a supplier’s/manufacturer’s website and not annexed to or otherwise expressly identified in the contract of itself.
Incorporating Requirements and Specifications
The Requirements and Specifications will be recorded, as appropriate in:
- the Contract Details;
- the Module Order Forms; and/or
- as annexures which are referred to in the Contract Details and/or Module Order Form.
The third option may be more appropriate where the parties have agreed Requirements and Specifications contained in external documents, for example in an agreed statement of work or proposal.
The parties may also specifically incorporate other external documents into the QITC contract by listing them in the Contract Details (section 5 in the Contract Details for both QITC contracts). Such documents may include additional terms and conditions, such as a supplier’s standard end user licence terms and conditions for its commercial off-the-shelf (COTS) software, or any specific government policies the customer wants the supplier to comply with, such as policies regarding data security.
Where any external documents have been incorporated, the parties should consider the precedence of those documents with respect to the other documents comprising the QITC contract. It is important to note that, as a base position, clause 1.3 of both the General Contract and Comprehensive Contract contemplates that the Contract Conditions (and Modules, as applicable) will take precedence over all other documents in the QITC contract, including any annexed or incorporated documents.
It is important to note that where the Requirements and Specifications are incorporated in the QITC contract can make big difference in terms of ranking for precedence of documents. For example, if any Requirements or Specifications are incorporated in a Module Order Form in the Comprehensive Contract, the hierarchy in clause 1.3 gives those Requirements and Specifications priority over any Requirements and Specifications included in section 5 of the Contract Details.
Where the parties require further terms and conditions to accurately address their agreed contractual positions, the parties may also include Additional Provisions in the Contract Details.
However, by operation of clause 1.3 the Contract Conditions take precedence over any Additional Provisions. Additionally, clause 1.4 of both QITC contracts specifies that Additional Provisions will only take effect to the extent that they are additional to, and do not detract from, the parties’ rights and obligations under the QITC contract. This is consistent with the position adopted under the previous Government Information Technology Contracting (GITC) framework. This approach appears to have been adopted with the intention that the standard terms of the Contract Conditions are the terms under which the parties are contracting.
If the parties intend to incorporate specific terms that otherwise derogate from the Contract Conditions, the better approach is to include these in the relevant sections of the Contract Details or the Module Order Forms. For example, in the Contract Details for the General Contract, any specific licence terms for a supplier’s COTS software should be included in section 4 for licensed software.
What about the Entire Agreement clause?
As under the GITC Customer Contract, both QITC contracts have an entire agreement clause, which specifies that the documents listed in clause 1.3 form the entire agreement and supersede all past negotiations and representations. This means that the parties must ensure that all relevant terms, Requirements and Specifications that the parties have agreed will form part of the QITC contract (such as any additional terms agreed over email) are included in the Contract Details or Module Order Forms in one way or another.
For Government organisations
- Where contracting for licensed software, hardware or as-a-service products, ensure any existing published specifications are annexed to the QITC contract, and the date of the published specifications is specified, in order to have certainty of applicable terms, as published specifications can change over time.
- Where multiple documents are included to define the Requirements and Specifications, the precedence of those documents may need to be addressed in the Contract Details/Module Order Form in the event of any inconsistency between them.
- Take care to consider all the documents that form part of the overall QITC contract (including any external published specifications of the Supplier) – for clarity, it is best practice to annex all relevant documents to the QITC contract in order that the applicable terms, Requirements and Specifications are clear to anyone who picks up the contract now, or in the future.
- If you are supplying licensed software, hardware, or as-a-service products, your, or your third party manufacturer’s, existing published specifications for the product may be incorporated into the QITC contract. You will may want to consider the extent to which the “published materials” in respect of a product (including on your website) include marketing material as opposed to formal, technical specifications. Disclaimers may be required to the extent that the information published on your website (particular in respect of marketing) is general information only and is not intended to be incorporated into contracts as specifications unless expressly agreed (or words to a similar extent). You may also want to consider in detail the precedence of such published specifications having regard to the terms and conditions contained in the Contract Details/Module Order Form of the QITC contract.
- If you are incorporating your specifications as a separate document, you should think carefully about where the document is incorporated, as it may be better to be included the Module Order Form rather than the Contract Details.
- Additional Provisions are not akin to special conditions, and cannot be used as a catch-all to amend the QITC Contract Conditions. It is better practice to specify any derogations in the relevant sections of the Contract Details or Module Order Form.
In the next edition
We will consider in more detail how intellectual property rights are dealt with under the QITC framework.
Authors: Trent Taylor & Barton Donaldson
Trent Taylor, Partner
T: +61 7 3135 0668
Paul Venus, Partner
T: +61 7 3135 0613
Dan Pearce, Partner
T: +61 3 9321 9840
Angela Flannery, Partner
T: +61 2 8083 0448
The information in this publication is of a general nature and is not intended to address the circumstances of any particular individual or entity. Although we endeavour to provide accurate and timely information, we do not guarantee that the information in this publication is accurate at the date it is received or that it will continue to be accurate in the future. We are not responsible for the information of any source to which a link is provided or reference is made and exclude all liability in connection with use of these sources.