← All insights
PROCUREMENT PRACTICE

Writing an ICT managed-services tender spec that gets good bids.

Procurement officers writing ICT managed-services tender specifications often start from a previous tender, edit the dates, and publish. The result is a specification that attracted the wrong suppliers last time, did not produce the service quality the entity needed, and is now being repeated. Good specifications are not harder to write than bad ones. They are written with a different set of priorities. Five practices separate the two.

1. Define outcomes, not activities

The worst ICT tender specifications describe what the supplier will do every day. Replace this many laptops a year. Run this many service-desk shifts. Patch servers on this schedule. The result is a specification that suppliers price as a body-count exercise, and a contract that pays for activity regardless of outcome.

The better approach is outcome-based. State the service-level performance the entity needs: first-time resolution rate on the service desk, mean time to recover for incidents, system availability targets per business priority, end-user satisfaction scores. Then let the supplier propose the activities and resourcing they think will achieve the outcomes, and price accordingly.

This shift changes the bidding population. Body-shop suppliers can't bid an outcome-based specification because they don't have a delivery model that connects activity to outcome. Quality suppliers can.

2. Right-size the technical evaluation matrix

Many ICT specs allocate too many points to technical capability and too few to commercial. The result is score inflation: every credible bidder scores 85+ on technical and the difference is decided by a thin commercial margin, often by a supplier who priced for the bid rather than for the delivery.

Cap technical scoring at 60 percent unless the procurement is genuinely capability-dependent (specialised cybersecurity, niche cloud workloads). Allocate the remaining 40 percent to commercial credibility: financial stability, delivery references with named contactable contacts, organisational capacity, and B-BBEE recognition. The framework still rewards capability but stops rewarding bidders who pad capability statements.

3. Specify SLA penalties that survive negotiation

SLA penalties exist on every ICT services contract and almost never get applied. The penalty is too small to matter, too administratively complex to invoke, or sits in a contractual provision that gives the supplier the right to remediate before the penalty triggers. The supplier knows this. The entity often doesn't.

Write penalties as service credits rather than as deductions. Credits attach to the next invoice automatically when a service-level target is breached. The supplier doesn't get the option to remediate first. The credits compound for repeat breaches in the same quarter. The penalty cap is around 15 percent of the monthly service fee.

State the dispute resolution clause clearly. When the supplier and the entity disagree on whether a credit applies, an independent reviewer is appointed within a defined window. Specify in the procurement that the reviewer's cost is for the loser of the dispute. The supplier price-includes the dispute-resolution exposure and prices accordingly.

4. Avoid sole-source language by accident

A common Section 32 procurement finding is specifications that effectively restrict competition without the entity meaning to. Brand-specific requirements (the cloud-provider name in the spec), product-specific certifications (a particular vendor's partner level), or service-model requirements that only one supplier can meet, all create a Section 32 problem even when the entity had no intent to favour a specific bidder.

Test every requirement against the question: could a credible alternative supplier meet this requirement using a different brand or model? If the answer is no, the requirement either needs to be re-written generically or removed. If a specific brand is genuinely required (interoperability with existing infrastructure, for example), the spec should call for the brand with a clearly documented justification that survives audit.

A specification that only one supplier can answer is not a tender. It is a deviation request with a longer cover page.

5. Build in supplier-management cadence

The strongest predictor of contract performance is the cadence of supplier management on the client side. Yet most specs are silent on what the entity will do to manage the supplier after award. The result is a contract that runs without governance, drifts off scope, and surprises the entity at renewal time.

The spec should require: monthly service reports with a published format, quarterly steering committee meetings with named attendees on both sides, annual partnership reviews chaired by an executive sponsor, and a documented escalation path to the supplier's managing director when service-level breaches recur. Suppliers who can't accept this governance often don't bid. Suppliers who can are the ones the entity wants.

Common specification failures

A short list of patterns that almost always produce poor procurement outcomes: rate-card pricing without volume commitment (suppliers low-ball rates to win, then route work to higher-rate categories); fixed-term contracts longer than 36 months without break clauses (the entity loses the ability to respond to market changes); evaluation criteria that aggregate to a single score without per-category minimums (a bidder can score zero on one important area and still win); and unpriced renewal options that the supplier can refuse (the entity gets stuck in re-procurement at exactly the wrong moment). Each is fixable with one paragraph in the specification.

The discipline of the procurement officer's notebook

A practice that distinguishes experienced procurement officers from new ones: a private notebook of what went wrong on previous tenders. Specifications that attracted bad bidders. Contractual clauses that turned out to be unenforceable. Evaluation matrices that produced surprising winners. The notebook becomes the basis for the next specification. Three years of disciplined notebook-keeping produces an entity-specific spec template that beats anything purchased from a consulting firm.

This piece distils practice notes from procurement reviews Sgananda Group has conducted for public-sector clients. Specific situations vary; the patterns above are intended as a starting checklist, not a substitute for procurement counsel on a specific bid.

PROCUREMENT ADVISORY

Want a second pair of eyes on a tender spec?

Sgananda Group reviews ICT tender specifications for public-sector clients before publication. We mark up the spec, flag the evaluation traps, and suggest the changes that produce stronger bids. Three-day turnaround.

Request a meeting →