Skip to main content

Log in with RealMe

To access the Procurement online service, you need a RealMe login. If you've used a RealMe login somewhere else, you can use it here too. If you don't already have a username and password, just select "Log in" and choose to create one.

What's RealMe?

To log in to this service you need a RealMe login.

This service uses RealMe login to secure and protect your personal information.

RealMe login is a service from the New Zealand government that includes a single login, letting you use one username and password to access a wide range of services online.

Find out more at www.realme.govt.nz.

Documenting your requirements

​Clear and concise requirements make sure suppliers understand what you need – making it easier for them to respond, and more likely you'll get the right results.​

Use the high-level statement of needs to develop the detailed scope and requirements.

Your requirements can't be structured to avoid the Government Procurement Rules or your agency's procurement requirements.

Government Procurement Rules

Choose a format

Requirements documents come in several formats. The one you choose will depend on your sourcing approach, the level of detail to be specified, and the rules at your agency.

  • Service specification: a very detailed description of the goods or services, often added as an annex to RFx documents and contracts.
  • Description of goods or services: an overview of the goods or services, typically found in documents like a Request for Proposal.
  • Scope of work: a description of the goods or services, specifically identifying what is within scope of the procurement activity and what is out of scope.
  • Statement of work: detailed requirements listed in the contract.
  • Terms of reference: an overview of the purpose and structure of the procurement project, as well as who is involved, their responsibilities and how they'll work together to accomplish a shared goal.

What goes in the requirements document

Your requirements document should be as detailed as possible, but ideally describe the required outcomes, rather than specifying any particular solutions. If you define a solution at this stage, you could miss out on better, more innovative options.

Your agency should have a requirements document template that you can use.

The requirements document should answer:

  • Why are we doing this?
  • What results do we need to achieve?
  • How will the services be delivered?
  • How much – what quantity or volume is required?
  • Where will the services be delivered?
  • How well – what quality and standards apply?
  • When will the services be delivered – timeframes, key deliverable dates and term of contract?
  • Who will be involved in the delivery?

Your requirements should be:

  • complete
  • unambiguous - avoid jargon, acronyms, vague language, negative statements, and state facts rather than opinions
  • consistent
  • current
  • feasible - within budget and timeframes
  • traceable - each requirement can be traced back to a documented need
  • verifiable - through inspection, demonstration, test or analysis
  • ethical.

Identify mandatory requirements

Identify whether there are any mandatory requirements that suppliers or providers must be able to meet.

Mandatory requirements could include:

  • specific accreditation or approvals required under legislation to provide the services
  • qualifications of personnel delivering services, eg hold a current practicing certificate from the relevant professional body, or have a certain accreditation or certification (provided these don't create unnecessary obstacles for potential suppliers)
  • submitting the proposal or response by the specified timeframe.

Document the deliverables

Specifying the requirements will lead to the identification of a deliverable or set of deliverables. A deliverable is a tangible output – something that must be provided under the contract.

Contract deliverables can be tied to milestones. A milestone is a measurement of progress toward an outcome, eg the delivery of a report, or for a social sector project, the implementation of a new training programme, completion of a certain number of courses and follow up with participants at a later date.

If you adopt a milestone approach, payment to the supplier can be tied to the successful completion of each milestone. This allows for implementation to be tracked and monitored against budget.

Technical specifications

Technical specifications should:

  • be specified in terms of performance and functional requirements, rather than design or descriptive characteristics
  • be based on international standards, or national technical regulations, standards or building codes
  • not refer to a trademark, trade name, patent, design or brand – if there’s no other way of describing the requirement, include the words “or equivalent”.

Technical specifications must not be prepared using advice from someone who may have an interest in the procurement.

Sustainability

Specify any sustainability requirements or preferences, including strategies to:

  • avoid unnecessary consumption, improve efficiency and reduce waste
  • minimise environmental impact over whole of life
  • consider suppliers’ sustainability credentials and approach to corporate social responsibility
  • support businesses and industry groups that demonstrate innovation in sustainability.

Identify wider benefits

Government procurement can be used to:

  • reduce negative environmental impacts
  • develop providers
  • improve community, regional, and economic outcomes.

Consider how you could secure secondary or wider benefits as part of your procurement.

Wider benefits don't need to cost more – it's not about requiring additional services, but providing services in a way that produces other social, environmental and economic benefits. For example:

  • if you're procuring training services (the primary objective), you could ask that providers supply information on how they'll contribute to youth skills development (the secondary objective)
  • when you're procuring a solution (the primary objective), you could ask that suppliers provide information on their environmental practices (the secondary objective).

You must follow the Principles of Procurement and avoid creating barriers for international suppliers.

Principles of Procurement

Analyse risks

Formal risk analysis and risk management can help you to assess potential risks and plan what actions to take to minimise disruptions.

Your agency should have its own risk analysis tool.

Health and safety requirements

Understanding and analysing health and safety risks in your procurement informs what to include in RFx documents, how you will evaluate responses, what you will document in any resulting contract, and how you will manage the resulting contract.

In the planning phase, you should:

  • identify risks in the services and the sector
  • identify risks with physical environments and the work to be undertaken
  • consider the likely need for worker participation
  • identify how these health and safety risks are best managed, mitigated or eliminated
  • consider whether health and safety should form part of evaluation criteria for the procurement and whether a health and safety or technical expert should be on the evaluation panel
  • document health and safety in your procurement plan.

Resources

Introduction to the Health and Safety at Work Act 2015 - special guide

Directors' guidelines on their responsibilities

Guidance on Occupational Health and Safety in Government Procurement

Tendering with safety

Commercially sensitive content

This section contains information which may be commercially sensitive and should not be shared publicly.

To view this content, you must be logged in, approved for secure content access, and your agency must be signed up to the contract. 

For assistance, please contact nzgppsystems@mbie.govt.nz 

Log in
Top