ResourcesProcurement readiness
Procure the operating responsibility, not only the software.
A serious system becomes part of the organization’s mandate, its records, its controls and its daily work. The procurement that chooses it should therefore evaluate more than features and a demonstration: it should evaluate who will understand that responsibility, implement it, carry it and evolve it. This reference sets out what to define, document and test before choosing a long-term software partner.
Before the tender
A demonstration is not an operating model.
Most weak procurements are decided before the first bid arrives — in specifications that describe a product instead of an operation, in responsibility left implicit, in migration postponed until after award. The organizations that procure well do the unglamorous work first: they define their mandate, map what already runs, and decide what evidence will convince them.
What follows is jurisdiction-neutral preparation, not legal advice. Applicable law, the procurement notice, the tender dossier and the contracting authority’s instructions control every formal procedure.
The readiness model
Six stages. Confidence accumulates as definition meets evidence.
Read the spine top to bottom. Each stage names what the organization itself defines, and what turns that definition into something an evaluation can actually test. A procurement is ready when every stage holds both.
Define the mandate
A specification can only be as exact as the problem it describes. Before any market contact, the organization itself decides what the system is for — and what it is not.
The organization defines
- The operational problem, in the organization’s own terms
- The legal or organizational mandate the system will serve
- The departments and roles the work touches
- The outcomes that would count as success
- What must remain under the organization’s control
- What is explicitly outside scope
What makes it evidence
A written mandate the affected departments have actually read — vague ambitions produce vague specifications, and vague specifications produce the wrong system.
Map the operating environment
The system will not arrive into an empty room. What already runs, and what must keep running, shapes every serious decision that follows.
The organization defines
- The systems, records and data sources in service today
- The integrations and interfaces that must continue operating
- Identities, permissions and approval chains as they really work
- Locations, infrastructure constraints and security boundaries
- What data must move, and what that migration actually involves
- Dependencies that cannot simply be replaced
What makes it evidence
An environment map the evaluation can test proposals against. Integration and continuity deserve consideration before replacement — what still works is an asset, not an embarrassment.
Allocate responsibility
“The vendor will handle it” is not a responsibility model. Every serious procurement names who owns what — on both sides — before anyone signs.
The organization defines
- Who owns requirements, and who decides when they conflict
- Who owns the data, the migration and its validation
- Who owns testing, acceptance and training
- Who owns security, infrastructure and change control
- Who carries support and long-term ownership after launch
What makes it evidence
A responsibility allocation written down per phase — not implied by the price table. Undefined responsibility is discovered at the worst possible moment.
Build an evidence-based evaluation
Confidence in a presentation is not evidence of capability. A strong evaluation separates what must be proven from what is merely promised.
The organization defines
- Mandatory pass/fail requirements, kept apart from scored preferences
- What counts as demonstrated evidence for each mandatory capability
- Current capability, kept apart from proposed future capability
- The implementation approach, evaluated as seriously as the product
- Reference relevance — similar mandate, similar environment, similar life
- Security and data-control evidence rather than labels
What makes it evidence
An evaluation that can defend its conclusion afterwards: every mandatory requirement traced to something shown, not something said. The right method is the procedure’s own — one formula does not fit every process.
Evaluate implementation, not only selection
Selection ends with a signature; the system begins after it. What happens between award and dependable daily operation deserves evaluation before the award.
The organization defines
- The implementation phases and who owns each decision in them
- Environment readiness — infrastructure, data and people
- How migration will be validated before acceptance
- Acceptance criteria the organization can actually verify
- Training, rollout and the operational transition
- How changes, issues and documentation are handled from day one
What makes it evidence
An implementation plan concrete enough to be evaluated — phases, owners and acceptance criteria, not a mobilization promise.
Protect continuity after award
The procurement is not finished when the system goes live. The organization will depend on this system for years; that dependency should be deliberate, documented and owned.
The organization defines
- Maintenance, updates and who is answerable for them
- Documentation and knowledge continuity as personnel change
- Controlled access and the organization’s continuing ownership
- Data portability and usable exports
- How future integrations and mandate changes will be absorbed
- Exit and transition considerations, where appropriate
What makes it evidence
Continuity terms in the procurement itself — dependable operation, preserved knowledge and organizational ownership are procured, not hoped for.
The evaluator’s register
Seventeen questions worth an honest answer.
Five territories, in the order an evaluation meets them. None of these require a form or a consultant to ask — only the discipline to insist on answers that are shown rather than said.
Operating fit
- Does the proposed system reflect the organization’s actual structure — its units, approval chains and responsibilities — or does it ask the organization to reorganize around the product?
- Which parts of the mandate does the proposal demonstrably carry today, and which does it only describe?
- How does the proposal handle the exceptions and edge cases that make this organization’s work its own?
Technical fit
- Which existing systems, records and interfaces must continue operating during and after transition — and how, exactly, will each connection work?
- What does migration involve for this data, and how will its completeness and correctness be validated before acceptance?
- What evidence supports each mandatory capability — something shown working, or something planned?
Implementation responsibility
- Who owns decisions when requirements conflict — and is that written down?
- What must the organization itself provide, decide and staff for the implementation to succeed?
- What are the acceptance criteria, and can the organization verify them without taking the supplier’s word?
- How are people trained, and how is operational readiness demonstrated rather than assumed?
Security and control
- What remains under the organization’s control — data, infrastructure, access, configuration — and where is that written?
- Who may act in the system, under which roles, and how is every consequential action recorded and reconstructable?
- How is access reviewed, changed and revoked as responsibilities change?
- What security evidence exists beyond labels — and does it cover this deployment, not just the product in general?
Long-term continuity
- How will operational knowledge survive personnel changes — on both the organization’s side and the supplier’s?
- What happens after launch when the mandate, a process or an integration changes?
- If the relationship ends, what does the organization keep — data, documentation, configuration, understanding?
Read the risks early
What weakens a software procurement.
Requirements copied from a brochure
The specification describes a product, not the organization — and every bidder except one is evaluated against someone else’s design.
A demonstration treated as implementation evidence
A polished demo proves the demo. It says nothing about migration, integration or the organization’s own data.
Migration postponed until after award
The hardest, most failure-prone work is priced and planned by nobody — then discovered under contract.
Integration reduced to “API available”
An interface existing is not an integration working. Which systems, which records, which direction, validated how?
Undefined acceptance criteria
Without verifiable criteria, acceptance becomes a negotiation held after the leverage is gone.
Responsibility left implicit
Every gap between client and supplier responsibility is found later — as a dispute instead of a plan.
Security evaluated by label
A certification names a discipline; it does not describe this deployment. Evidence does.
Price compared without lifecycle scope
A lower price with maintenance, training and evolution left out is not a lower price — it is a deferred one.
None of this means existing procedures are poor — most weaknesses here are simply what happens when preparation time runs out. The readiness model above is how an organization buys that time back.
A professional boundary
How CREA-KO engages before a procedure.
Early engagement can include
- Capability briefings and architecture discussions
- Implementation-readiness conversations
- Neutral clarification of what is technically possible
- Participation in public consultations
- Responses to lawful requests for information
- Verified experience, at its approved public level
What CREA-KO does not offer
- Confidential tender information or hidden access
- Influence over procedures or evaluation decisions
- Specifications drafted to exclude competition
- Guarantees of eligibility or award
- Tender-specific legal advice
Applicable law, the procurement notice, the tender dossier and the contracting authority’s instructions control every formal procedure.
Bring the mandate before the tender.
The most useful conversation happens while the operating context, integration reality and responsibility model are still being defined — when clarity is cheap and changes cost nothing.