IT tender technical proposal in Lithuania: a CVP IS guide

The technical part of an IT tender in Lithuania is the document that proves, requirement by requirement, that you can deliver what the contracting authority specified. In CVP IS it is evaluated first for compliance and then, if the award is on price-quality ratio, for quality. A good one has five parts: a compliance table, the architecture, a delivery plan, defensible estimates and a risk register.

This guide explains how we structure that document when we write the technical half of a bid, and what the procurement rules mean for each part.

How an IT tender is evaluated in Lithuania

An IT tender is evaluated in two passes. First the contracting authority checks that the proposal meets every mandatory requirement in the procurement documents and the technical specification; a proposal that fails a mandatory requirement is not acceptable. Then it ranks acceptable proposals by the award criteria it published in advance.

Technical specification (techninė specifikacija) is the part of the procurement documents that describes what is being bought: functions, standards, performance and constraints.

Most economically advantageous tender (ekonomiškai naudingiausias pasiūlymas) is the winning bid under the published criteria. Under the Law on Public Procurement and Directive 2014/24/EU, the authority chooses it by price, by cost, or by the ratio of price or cost to quality. Quality criteria can include technical merit and the organisation, qualification and experience of the staff assigned to the contract.

VPT's own evaluation guidelines warn authorities not to name a winner and only afterwards discover that the offer does not meet the specification or contains calculation errors. In practice this means evaluators read the technical part closely. Write it for a careful reader with a checklist.

CVP IS: what changed for suppliers

CVP IS is the Central Public Procurement Information System, the platform where Lithuanian contracting authorities publish procurements and suppliers submit proposals. From 1 December 2024 all procurements moved to a new version of CVP IS, and VPT states that suppliers must register in it before they can take part.

For a bid team, the practical consequences are:

• Register the company and the users who will prepare and submit bids well before a deadline, and check who holds the right to submit.
• Read the procurement's own instructions on file formats, signatures and whether parts of the proposal (for example the price) are submitted separately or encrypted.
• Send questions about the specification through the channel the procurement documents name, before the deadline they set. Answers are shared with all suppliers.
• Upload a final version. After the deadline, the substance of the proposal is fixed.

VPT publishes instructions for suppliers and a regularly updated FAQ on the new system; check them before your first submission rather than on the last evening.

The five parts of a strong technical proposal

A strong technical proposal answers the specification in its own order, then adds the evidence evaluators need to score quality. We use five parts. Their order in your document should follow whatever the procurement documents require; where they are silent, lead with compliance, because that is what is checked first.

1. The requirement-by-requirement compliance table

A compliance table lists every requirement from the technical specification, in the specification's own numbering, with your answer and a pointer to where the detail sits. It is the single most useful page in an IT bid, because it lets the evaluator tick through the specification without hunting.

Use these columns: requirement ID, requirement text (quoted, not paraphrased), compliance (complies / complies with an equivalent / partial), how it is met in one or two sentences, and the section or annex reference. Mark "equivalent" answers explicitly. Where a specification names a product or standard and you propose an equivalent, procurement rules allow it, but the proposal must show the equivalence with evidence. Do not leave it to the evaluator to infer.

Build the table first. It becomes the index for everything else, and it exposes gaps while you still have time to ask a clarifying question.

2. Architecture that answers the specification

The architecture section describes how the proposed system is built and how it fits the authority's environment: components, data flows, integrations, hosting, security, and how data is backed up and restored. Write it against the specification. If the specification requires integration with a national registry, a single sign-on, or data kept in the EU, name each one and show where it sits in the design.

One diagram with a short explanation of each component is worth more than pages of general description. Name the standards you follow and state what the authority will own at the end: source code, documentation, access credentials.

3. A delivery plan with acceptance built in

A delivery plan shows the phases, the milestones, what the authority must provide at each step, and how each deliverable is accepted. Evaluators look for dependencies: data you need from them, environments, decisions only they can make. Name them. A plan that assumes everything arrives on time is not a plan.

Put the team here too: the roles, what each person is responsible for, and how their qualifications match what the procurement documents require. If staff experience is an award criterion, map each person to it explicitly.

4. Estimates you can defend

An estimate is the effort, broken down by deliverable, that justifies your price. Break it down to a level where each line can be explained: module, integration, migration, testing, documentation, training, warranty support. Keep the breakdown consistent with the delivery plan and the compliance table.

This matters for two reasons. First, clarification questions often target estimates. Second, if a price looks abnormally low, EU and Lithuanian rules require the authority to ask the supplier to explain it before rejecting the bid. A line-by-line estimate is the explanation, already written.

5. A risk register with owners

A risk register is a table of what could delay or damage delivery, how likely and serious each risk is, who owns it and what you will do about it. Typical IT tender risks: late access to legacy data, unclear ownership of integrations, changes in the authority's requirements during delivery, security review lead times, and staff availability.

Keep it specific to this procurement. Evaluators can tell a register written for their project from one copied across bids.

A checklist before you upload

Before submitting in CVP IS, run the proposal against the specification one final time. We use this list:

1. Every requirement ID in the specification appears in the compliance table.
2. Every "equivalent" answer has evidence attached or referenced.
3. The estimate totals match the price in the price form.
4. Names, roles and CVs match the team requirements in the procurement documents.
5. Every document the procurement asks for is present, in the requested format and signed as required.
6. Answers to clarification questions published by the authority are reflected in the proposal.
7. Someone who did not write the proposal has read it against the specification.

How we help, and where Tendris fits

We write the technical half of IT bids: the compliance table, architecture, delivery plan, estimates and risk register, in Lithuanian or English. Prices start from €1,200, with a fixed price agreed in writing before work starts.

We also build and run Tendris, our public-procurement intelligence product. Tendris monitors Lithuanian procurements, sends alerts and uses AI to analyse tender documents, so a team can decide early which tenders are worth a bid.

• The service: RFP and tender responses
• What we build in this area: RFPs, proposals and estimates and public-sector platforms
• All prices: pricing
• Have a tender open now? Book a free 30-minute call and bring the technical specification.