Part II Preparation and vendor selection
The brief, the RFP, vendor selection, the pricing model, and a contract that makes the software truly yours.
Chapter 6: Before you approach the market: brief, people, data
A vendor can only take your organization’s needs into account if you can describe them. Before you approach the market, you need a short brief (problem, goals, users, data, integrations, constraints, deadline, budget), a named product owner with time set aside for the project, and a sample of your own data. You then prepare the detailed specification with the selected vendor.
A brief for vendor selection describes the problem, not the solution
In a PMI survey, 37% of organizations named inaccurate requirements as the main cause of project failure PMI, 2014. For government projects, the Supreme Audit Office (NKÚ) describes underestimated business analysis as the common denominator of failures NKÚ, 2026. Time spent on the brief is therefore not a delay. It is the cheapest insurance you have.
For vendor selection, however, you do not need hundreds of pages of documentation. 3–6 pages are enough, answering these questions:
- What problem are we solving, and what does it cost us today?
- Which 2–4 measurable goals will tell us we have succeeded?
- Who will use the system, how many users will it have, and what tasks will they handle in it most often?
- What data do we have, where is it, and what must the system integrate with?
- What constraints do we have (security, accessibility, hosting, legislation), and what are the deadline and the budget range?
Screen designs and the choice of technology do not belong in the brief as a binding solution. List only the technical constraints that follow from your existing environment, such as required integrations with an accounting or warehouse system. If you prescribe a solution instead of describing the problem, you leave less room for better ideas and may get proposals that are hard to compare. A detailed specification with acceptance criteria is only created during analysis with the selected vendor (chapter 14).
Who will make decisions on your side?
The product owner should be your employee, not someone supplied by the vendor Česko.Digital, 2022. They decide on priorities, answer questions, and accept finished parts. The most common thing that holds a project back is a customer with no time for it.
As a rough guide, assume that the product owner needs 50–100% FTE during analysis, and practically full time during development with a team of 5–9 people. On top of that, you need 3–8 key users who devote 20–30% of their time to analysis. Name them before you issue the RFP, and confirm their involvement and reserved time in writing. A product owner who is just a name in a document but does not actively spend time on the project is like a captain who never boarded the ship.
Know your data before the vendor does
Data migration from the old system is the most commonly underestimated part of a project. A vendor who has not seen the data will either price the risk in as a buffer or underestimate it and ask for add-ons later. In the tender for the digital building permit system, seven vendors wrote to the Office for the Protection of Competition (ÚOHS) that the migration could not be reliably priced without further information ÚOHS, S0321/2023 (more in chapter 12).
So attach an anonymized data sample to your RFP, along with a description of the source systems, record counts, and known data quality problems (duplicates, missing data).
A clickable prototype can illustrate a written brief even better. Your analyst or product owner can build one with an AI tool or in low-code in a few days and try it out with colleagues (chapter 3). This narrows the cone of uncertainty (chapter 1) even before the tender. But the prototype is an illustration of the need for the vendor, not a prescribed solution or a production system.
What gets cut when the money runs out?
Give every requirement a MoSCoW priority:
- Must: without it, the system makes no sense,
- Should: important, but you can work around it for a while,
- Could: we add it if time and money are left,
- Won't: not this time.
Must should be a minority. If everything is “necessary,” you will not know what you can postpone when complications arise. The Digital and Information Agency (DIA) evaluation cards divide requirements in a similar way: mandatory ones are a condition, optional ones are scored DIA, Optional requirements card.
Are you ready to approach the market? Before you send out your first RFP, answer yes or no:
- Can we describe the problem in one sentence and put a number on what it costs us?
- Do we have 2–4 measurable goals with a baseline?
- Is there a named product owner with a mandate and time freed up?
- Do we know who the users are, how many there are, and what the key scenarios are?
- Do we know the data sources, volumes, and quality, and do we have an anonymized sample?
- Do we have a list of systems to integrate with and MoSCoW priorities?
- Do we have a budget range including 5 years of operations (chapter 4), and have we verified that an off-the-shelf solution is not enough (chapter 2)?
As a first rule of thumb: if you answer yes to everything, you can start requesting proposals. If two or three answers are missing, fill them in first, or order a discovery phase. With more unanswered questions, start with discovery or an internal prototype.
A specification written by one vendor
The most expensive shortcut: a vendor writes your specification “for free” and then enters the tender. The brief then fits that vendor’s solution, and the others either do not submit a proposal or raise their price. Pay for discovery as a separate small engagement and secure the right to share its outputs with other bidders (chapter 8).
| How it goes wrong | How to do it right |
|---|---|
| How it goes wrong“We want a system like our competitors have, send us a proposal.” | How to do it rightThe problem, goals with numbers, users, and key scenarios on a few pages. |
| How it goes wrongThe brief prescribes screens and technologies. | How to do it rightThe brief describes the problem and scenarios; the vendor proposes the solution. |
| How it goes wrongIT runs the project alongside its regular work; the business only shows up at testing. | How to do it rightA product owner from the business with a mandate and time freed up. |
| How it goes wrong“We will send you the data once we sign.” | How to do it rightAn anonymized data sample and a description of its quality are attached to the RFP. |
| How it goes wrongEverything is a “Must.” | How to do it rightMoSCoW priorities: Must is a minority, and you know what you are sacrificing. |
| How it goes wrongA fixed price for an idea. | How to do it rightFirst narrow the uncertainty with a prototype, data, and analysis, then compete on price. |
- The brief must be consistent with the authority’s information strategy (informační koncepce) Decree No. 360/2023 Coll.. For a designated information system, you need an opinion from the Office of the Chief Architect of eGovernment (OHA) before the procurement procedure (chapter 12).
- Goals must be measurable. NKÚ criticizes phrasing such as “creating conditions” because the benefit then cannot be verified NKÚ, 2026.
- Plan the budget for the whole lifecycle, as the 3E principle requires (from January 1, 2027, in Act No. 231/2025 Coll. Act No. 231/2025 Coll.).
- You must make the outputs of discovery and the data sample available to all bidders in the tender documentation.