Procurement pack
Buying a programme MIS under donor procurement rules
Neutral texts your PMU can adapt for a request for quotations, a work-plan line, a direct-selection justification and an evaluation grid. They name no vendor, so you can use them for any supplier, including us.
Before you start
The rules that apply to your purchase come from your financing agreement, the financier's procurement regulations or policy named in it, and your approved procurement plan. Thresholds, methods and review requirements differ by financier, by country and by project. Nothing on this page replaces them. Ask your procurement specialist to confirm the route before you issue anything.
Check that the purchase is in your procurement plan. If it is not, the plan usually has to be updated, and sometimes cleared by the financier, before you can start.
Typical procurement routes
A software subscription for a project management information system (MIS) is usually treated as goods or non-consulting services. The route depends on the estimated value and on what your procurement plan says.
- Request for quotations (RFQ), sometimes called shopping. Commonly used for readily available, off-the-shelf items of lower value. You invite several suppliers, typically at least three, to quote against a written specification and award to the lowest compliant quotation.
- National or open competitive procurement. Used above the RFQ threshold. It involves a formal bidding document, public advertisement, a bid opening and a written evaluation report. Some financiers require prior review of the documents or of the award.
- Consultant selection. If the software is bundled with substantial advisory services, such as designing your M&E system or redesigning financial procedures, the whole package may be treated as consulting services. That brings a different method, such as quality- and cost-based selection or selection based on consultants' qualifications.
- Direct selection. Allowed only in limited, defined circumstances. It almost always needs a written justification and, in many projects, the financier's prior review or no-objection.
Splitting one requirement into several smaller purchases to stay under a threshold is generally not allowed. Estimate the full contract value, including subscription years, training and support.
(a) Technical specification for an RFQ
Edit the bracketed items. Remove requirements you do not need; every extra requirement narrows competition.
TECHNICAL SPECIFICATION — PROJECT MANAGEMENT INFORMATION SYSTEM (MIS)
Purchaser: [Project name], [Implementing agency / PMU]
Financing: [Financier and financing number]
Period: [number] months from contract signature, with [number] optional renewal(s)
1. FUNCTIONAL REQUIREMENTS
1.1 Annual work plan and budget: activities coded by component, sub-component and activity; quantity x unit cost; quarterly phasing; financing source per line; revision history.
1.2 Approval workflow: configurable steps (prepare, review, approve); each approval records user, date and comment.
1.3 Financial tracking: commitments, expenditure and advances recorded against work-plan lines; advances shown separately from expenditure until liquidated.
1.4 Interim financial reports: sources and uses of funds, uses by component/activity against budget, and designated account activity, in the format required by the financing agreement; each figure traceable to source records.
1.5 Results framework: indicators with baseline, targets and actual values by period; evidence files attached to each reported value.
1.6 Reporting: export of standard reports to spreadsheet and PDF.
1.7 Multi-currency: amounts held in transaction currency with the exchange rate and its date; missing rates flagged, not assumed.
1.8 Missing data: values not yet recorded shown as "not recorded" and not as zero.
2. NON-FUNCTIONAL REQUIREMENTS
2.1 Access: web browser access with no local installation; works on [minimum connection speed] connections.
2.2 Hosting: state hosting location and provider; compliance with [national data protection law / government hosting policy, if any].
2.3 Security: encrypted connections; individual user accounts; password and session controls; regular backups with stated retention.
2.4 Roles and permissions: role-based access (e.g. project coordinator, finance, M&E, procurement, viewer); segregation of duties between preparing and approving.
2.5 Audit trail: every create, change and approval logged with user and timestamp; log cannot be edited by users.
2.6 Data ownership and export: all project data belongs to the Purchaser; full export in an open format (e.g. CSV) at any time and at contract end at no extra cost.
2.7 Languages: user interface in [English / French / Portuguese / other].
2.8 Support: help desk by [email / phone] during [hours, time zone]; stated response times.
2.9 Training: [number] sessions for [number] staff, [remote / on site]; user guide in [language].
2.10 Availability: stated service availability target and maintenance notification.
2.11 Continuity: procedure for data handover if the contract ends.
3. DELIVERABLES
3.1 Configured system with the project's components, activities and indicators loaded.
3.2 Training completed and attendance recorded.
3.3 Monthly or quarterly service report [if required].
(b) Work-plan / TOR budget line
Activity [code]: Project management information system
Description: Annual subscription to a web-based project management information system covering work planning, budget monitoring, advances, interim financial reports, results framework and audit trail, including configuration, user training and support for [number] users.
Unit: subscription-year | Quantity: [1] | Unit cost: [amount, currency] | Total: [amount]
Financing source: [financier / counterpart]
Procurement method: [RFQ / other, as per procurement plan]
Responsible: [Project coordinator / IT focal point]
Linked indicator: [e.g. "IFRs submitted on time" or project management indicator, if any]
(c) Direct-selection justification template
Direct selection must meet the specific conditions in your financier's procurement rules. It usually requires the financier's prior review or no-objection before you sign. Do not use this template unless your procurement specialist confirms a permitted ground applies.
MEMO — JUSTIFICATION FOR DIRECT SELECTION
To: [Procurement committee / Financier task team, as applicable]
From: [PMU procurement officer]
Date: [date]
Project: [name, financing number]
Procurement plan reference: [line number]
1. Description of requirement: [what is being bought, period, estimated value]
2. Ground for direct selection: [cite the exact clause of the applicable procurement regulations/guidelines]
3. Facts supporting the ground: [e.g. continuity with an existing system already procured competitively; urgency arising from a documented emergency; only one source able to meet a stated essential requirement]
4. Market check carried out: [suppliers contacted, dates, outcome]
5. Why competition is not practical: [explain]
6. Price reasonableness: [comparison with market prices, prior contracts or published price lists]
7. Value for money: [explain]
8. Proposed supplier: [name] — no conflict of interest declared: [yes/no, attach declaration]
9. Review requirement: [prior / post review] — no-objection requested on: [date]
Prepared by: [name, signature] Approved by: [name, signature]
(d) Suggested evaluation criteria
For an RFQ, the usual approach is pass/fail on the specification, then lowest price among compliant quotations. If your rules allow a scored evaluation, the table below is a neutral starting point.
| Criterion | How to test it | Type |
|---|
| Covers the functional requirements | Live demonstration using your own sample activities | Pass/fail or scored |
| Traceability of figures | Ask the bidder to open an IFR total down to its source records | Scored |
| Audit trail and roles | Ask to see who changed a figure and when | Pass/fail |
| Data export and ownership | Contract clause plus a sample full export | Pass/fail |
| Hosting and security | Written statement of hosting location and controls | Pass/fail |
| Training and support | Plan, language, response times | Scored |
| Total cost over the contract period | All years, users, training and support included | Price |
Ask every bidder to demonstrate with the same test data. A live test is harder to dress up than a brochure.