Technology Contracts in ICT Procurement: A Practical Guide for Australian Organisations

(Basic guidelines for non-specialists, informed by David Tollen’s work)

Technology contracts are where many of the most expensive and enduring problems in ICT procurement begin.

Long before a system fails, a vendor relationship deteriorates, or a renewal becomes painful, the underlying causes are often embedded in the contract itself. Scope is unclear, responsibilities are implied rather than defined, exit paths are vague, and risk is allocated without the buyer fully understanding the consequences.

For many Australian organisations, technology contracts are treated as paperwork to be finalised once a solution has been selected. In reality, they are one of the primary tools that determine how cost, risk, accountability, and leverage will play out over the life of a system.

This article is not intended to make readers experts in technology contracting.

Its purpose is simpler and more practical.

It provides a basic mental model and a set of guidelines to help uninformed or under-informed buyers understand what matters, what to question, and where risk commonly hides in technology contracts.

This guide is written for Australian organisations managing ICT procurement, technology sourcing, and vendor contracts across software, systems, and services.

The framework below reflects how experienced procurement and commercial practitioners approach technology contracts, and is informed by the work of David W. Tollen, author of The Tech Contracts Handbook, which clearly articulates why technology contracts fail in real organisations.

Why technology contracts are different in ICT procurement

Technology contracts are not like leases, supply agreements, or standard professional services contracts.

They are different because:

• The solution often evolves after signing
• Success depends on integration, data, and people, not just software
• Failure is usually partial and operational rather than total

A system may technically “work” while still failing to deliver value.

As a result, traditional set-and-forget contracting approaches rarely work well for technology.

Understanding this difference is the first step toward contracting more effectively in ICT procurement.

Guideline 1: If it is not written, it is not agreed

One of the most common misunderstandings in technology deals is assuming something is “obvious”.

In practice:

• Vendors price and deliver what is written
• Customers assume what feels reasonable
• Disputes arise in the gap between the two

This commonly shows up around integrations, data migration, configuration versus customisation, and customer versus vendor responsibilities.

At a minimum, ICT procurement contracts should clearly state:

• What is included
• What is excluded
• Who is responsible for what

If responsibilities are implied rather than explicit, they will almost always be disputed later.

Guideline 2: Assume change will happen

Requirements change. Business priorities shift. Systems integrate differently than expected.

This is normal in technology projects.

Contracts that assume the original scope will remain static are unrealistic and often lead to cost overruns and friction.

At a basic level, technology contracts should:

• Separate base scope from change
• Define how changes are approved
• Define how changes are priced

Change control is not about preventing change.

It is about ensuring change is managed transparently and commercially.

Guideline 3: Liability clauses are about risk, not fairness

Liability clauses are often negotiated without a clear understanding of what they actually do.

Many buyers focus on whether the liability cap “looks big enough”, without considering what types of loss are excluded entirely.

At a basic level, buyers should understand:

• What the liability cap is
• What losses are excluded
• Whether key risks sit outside the cap altogether

A high liability cap is meaningless if it excludes the risks that matter most, such as data breaches, confidentiality failures, or IP infringement.

Liability clauses are not about fairness.

They are about deciding who carries which risks when something goes wrong.

Guideline 4: IP clauses affect whether you can leave later

Intellectual property clauses are often treated as legal detail and ignored by non-specialists.

In reality, they quietly determine:

• Who owns custom work
• Whether configurations can be reused
• Whether documentation can be handed to a new vendor

Poor IP drafting can create long-term vendor lock-in, even where switching appears technically possible.

Many organisations only discover this problem when they try to exit.

Guideline 5: SLAs should reflect business impact, not just uptime

Service level agreements are often heavily focused on system availability.

While uptime matters, it is rarely the only issue that affects the business.

Useful SLAs:

• Address response and resolution times
• Reflect business impact
• Escalate consequences if failures persist

Service credits alone rarely change behaviour.

SLAs are most effective when they are linked to escalation and, ultimately, exit rights.

Guideline 6: Exit planning in ICT procurement contracts

Most organisations focus heavily on getting systems live and give little thought to how they will exit.

That is a mistake.

Even at a basic level, ICT procurement contracts should address:

• Data return formats
• Transition assistance
• Knowledge transfer
• Exit timelines

If exit is vague, difficult, or undefined, switching becomes commercially or operationally unrealistic, regardless of what the contract says elsewhere.

You negotiate your exit on day one, whether you realise it or not.

Guideline 7: Contracts should support governance, not replace it

Contracts do not manage vendors. People do.

Well-designed technology contracts:

• Support day-to-day governance
• Define escalation paths
• Clarify decision-making authority
• Reduce reliance on legal enforcement

Contracts should help the relationship function in reality, not assume perfect delivery.

Common mistakes Tollen repeatedly highlights

Throughout The Tech Contracts Handbook, Tollen returns to a small set of recurring mistakes made by organisations that treat technology contracts as administrative documents rather than operational risk tools.

These are not edge cases.

They are patterns.

Relying on vendor templates without understanding where risk sits
Vendor templates are typically designed to shift operational risk back to the customer, particularly around scope, change, and liability.

Treating legal review as a formality rather than risk analysis
Contracts are often reviewed for legal correctness, but not for how they will operate when things go wrong.

Assuming renewal equals continuity rather than leverage
Renewal is often the only real leverage point in ICT procurement, yet many organisations arrive unprepared and constrained.

Leaving exit and transition until “later”
Exit provisions are routinely vague, creating de facto lock-in regardless of performance.

Over-relying on SLAs and under-investing in governance
SLAs without escalation and governance rarely protect the business in practice.

What this means in practice

These guidelines will not eliminate risk.

They will, however, help uninformed buyers avoid the most common and costly mistakes.

Technology contracts rarely fail because organisations ignore legal advice.

They fail because contracts are treated as paperwork rather than as tools that shape operational reality in ICT procurement.

Need help with ICT procurement?

If you are reviewing technology contracts, preparing for renewal, or inheriting agreements you did not negotiate, an early commercial review can surface issues before leverage is lost.

This is a recurring theme across previous articles in this series on ICT procurement risk management, renewals, and vendor management.

Where a specific procurement or sourcing issue is in play, it is often useful to sense-check assumptions early before positions harden.

Key Takeaway

These guidelines will not eliminate risk.

What they tend to do is reduce the likelihood of avoidable surprises later, particularly in long-running technology relationships where leverage erodes over time.

Technology contracts rarely fail because organisations ignore legal advice. They fail because contracts are treated as administrative paperwork rather than as tools that shape operational reality in ICT procurement.

For anyone involved in technology sourcing, renewals, or vendor management, very little of this will feel theoretical. These patterns appear repeatedly, often not because people are careless, but because contracting decisions are made under time pressure or deferred until after commercial positions have already hardened.

You do not need to be a lawyer to understand where contract risk tends to sit in technology agreements. But you do need enough commercial awareness to recognise when risk is being accepted by default rather than by design.

That is the intent of this article.

This article is provided for general information purposes only and does not constitute legal advice. Technology contracts, legal obligations, and risk considerations vary by jurisdiction and circumstance. Independent legal advice should always be sought before entering into, varying, or relying on any contractual arrangements.