Yerevan is preparing to develop its YES digital platform, designed to modernise municipal services and automate administrative processes. Two public procurement procedures announced in October 2026 raise a question that extends far beyond one city: how can an organisation prove that a major IT project has genuinely succeeded, rather than simply been delivered and formally accepted?
The Contract Says “Testing.” But What Exactly Are We Testing?
In October 2026, two public procurement procedures were announced in Armenia.
The first concerns the core components and infrastructure of the YES digital platform.
The second focuses on business process automation for Yerevan Municipality.
Both are part of the Fourth Public Sector Modernization Project (PSMP4), financed by the World Bank.
The second procurement notice describes a familiar set of activities: development, supply, installation, configuration, testing, and technical support.
For an IT systems integrator, these terms are standard.
For a public institution investing in a large digital platform, however, they raise a much more important question.
What exactly must happen before a customer can confidently declare that the system works?
Is successful installation sufficient?
Does the ability to log in demonstrate readiness?
Is a presentation of the system's key functions enough to justify acceptance?
Or should the customer require evidence that the platform can reliably execute real municipal operations from beginning to end?
This question extends beyond Yerevan.
Banks, telecommunications operators, manufacturing companies, and public institutions face similar challenges when implementing ERP platforms, CRM systems, digital document management solutions, and other complex enterprise applications.
The acceptance stage often reveals whether an organisation has purchased working software components or a fully functioning business process.
And the difference can be significant.
What We Know About the YES Platform Project
According to the published procurement notices, the development of the YES Electronic Management Platform is intended to support the digitalisation of municipal services in Yerevan.
The broader objectives include making services more accessible, automating administrative procedures, and improving the management of financial obligations owed to the municipality.
One important area is the centralised recording of such obligations and the ability to settle them more conveniently.
Two related procurement procedures have been announced:
PSMP4-GO-RFP-2.3.1 — Procurement of the Core Components and Infrastructure for the YES Platform.
The notice was published on October 15, 2026, with a proposal submission deadline of November 26, 2026.
PSMP4-GO-RFP-2.3.2 — Procurement of the Business Process Automation Systems for the YES Platform for Yerevan Municipality.
The notice was published on October 29, 2026, with a submission deadline of December 14, 2026.
As of November 12, both procurement deadlines are still ahead.
The announcement of these procedures does not mean that the corresponding systems have already been implemented, accepted, or placed into production.
That distinction is important.
The purpose of examining these procurements is not to judge the outcome of a project that is still at the procurement stage.
It is to understand how outcomes should be measured before implementation even begins.
The division of the project into different procurement packages is particularly interesting.
Infrastructure and core platform components represent one part of the future system.
Business process automation represents another.
Even if each component is delivered according to its individual requirements, the overall result will depend on how successfully the components work together.
This is one of the defining challenges of large-scale digital projects.
The Most Expensive Failure May Occur Between Two Systems That Work Perfectly
Consider a hypothetical digital municipal service.
A citizen opens the portal, signs in, and sees an outstanding municipal payment obligation.
The user selects the obligation, proceeds to payment, confirms the transaction, and receives a success notification.
The screen displays:
“Payment completed successfully.”
From the user's perspective, the process is finished.
But from a systems engineering perspective, several important operations may still need to be verified.
Did the payment confirmation reach the relevant municipal system?
Was the corresponding obligation updated correctly?
Was the transaction recorded in the appropriate database?
Can the payment be reconciled with the financial records?
Will the user be prevented from accidentally paying the same obligation twice?
Now consider what happens if the connection between two systems fails immediately after the payment is confirmed.
The financial transaction may have succeeded, but the municipal portal may not have received the confirmation.
The user might see an error.
The obligation might temporarily remain unpaid in the interface.
And the systems may contain different views of the same transaction.
This is an illustrative engineering scenario, not a claim about an existing problem in the YES Platform.
But it demonstrates why testing a payment button is not the same as testing the entire payment process.
The system must be evaluated from beginning to end.
This is known as End-to-End Testing.
It examines not only whether individual components function, but whether the complete service produces the expected result.
A successful test should cover normal operations as well as failures, duplicate requests, interrupted connections, and recovery procedures.
Because in complex digital platforms, the most serious problems do not always occur within individual applications.
Sometimes they emerge between applications that appear to work perfectly on their own.
When Every Supplier Says Their Part Works
Large IT projects frequently involve several contractors.
One team may develop the user interface.
Another may build the integration layer.
A third may provide infrastructure.
A fourth may implement cybersecurity controls.
Each contractor can successfully complete its own contractual scope.
And yet the overall platform may still fail to deliver the expected business outcome.
For example, an API may return technically valid responses.
The database may be available.
Authentication may work correctly.
But a citizen may still be unable to complete a service because information exchanged between two components is interpreted differently.
From the perspective of each individual supplier, its system may be functioning as designed.
From the customer's perspective, the service is unavailable.
Who is responsible?
Who investigates the problem?
Who coordinates the correction?
Who performs the final integration test?
And who determines whether the platform is ready for acceptance?
These questions become especially important when a project is delivered through multiple contracts.
A customer needs clearly assigned responsibility for end-to-end integration, agreed technical interfaces, and an established procedure for resolving defects that cross contractual boundaries.
Otherwise, an organisation may formally accept individual components while discovering that the complete service still requires significant work.
Acceptance Criteria Should Be Written Before Development Begins
One of the most valuable practices in enterprise IT delivery is defining acceptance criteria at the requirements stage.
Not after implementation.
Not during the final demonstration.
And certainly not on the day the acceptance certificate is due to be signed.
The customer and supplier should agree in advance on what constitutes measurable evidence of success.
Consider a requirement such as:
“The system must provide high performance.”
What does that actually mean?
A response time of one second?
Five seconds?
The ability to serve 100 users simultaneously?
Or the ability to handle several thousand transactions during peak demand?
Without measurable conditions, such a requirement leaves too much room for interpretation.
A more reliable approach establishes specific workload assumptions, user volumes, transaction types, performance thresholds, and test environments.
The results can then be measured and compared against agreed expectations.
This approach is consistent with the principles of ISO/IEC 25010:2023, which defines a quality model for software and systems.
The standard considers product quality through multiple characteristics, rather than simply evaluating whether a list of functions has been implemented.
For enterprise customers, the lesson is straightforward.
Software acceptance should not be based exclusively on whether a supplier can demonstrate that the application opens and performs a few successful operations.
It should be based on evidence that the system meets its agreed functional and non-functional requirements.
What Should a Serious Acceptance Test Actually Include?
For a digital platform involving municipal services, financial obligations, and integrations with external systems, several areas deserve particular attention.
Data accuracy and consistency
The system must correctly process and display information.
Where financial obligations are involved, changes in payment status must be recorded accurately.
Financial records should be reconcilable across the relevant systems.
Integration reliability
Testing should include successful data exchange and failure handling.
What happens when an external service becomes unavailable?
Can requests be retried safely?
How are duplicate operations prevented?
How does the system restore data consistency after an interruption?
Performance
A platform should be tested against agreed workloads, not merely under ideal demonstration conditions.
Peak demand, concurrent users, application response times, and transaction success rates should all be considered.
Security
Testing must address authentication, authorisation, API security, access restrictions, and appropriate handling of personal information.
A user should not be able to access data or functions outside their authorised scope.
Recovery
The system must have an appropriate recovery strategy.
Backup procedures, restoration tests, and the handling of incomplete transactions should form part of the assessment.
Usability
A digital service that is technically available but unnecessarily difficult to use may still fail to achieve its intended purpose.
Users need clear instructions, understandable error messages, and a reliable path to completing their tasks.
Each of these areas should be reflected in the project's acceptance plan.
The precise thresholds will depend on the platform's purpose, architecture, and agreed service requirements.
There is no universal performance number that guarantees success for every digital system.
Turning Requirements Into Measurable Evidence
To illustrate the approach, consider the following acceptance-testing framework for a hypothetical municipal payment platform.
This is an editorial example for systems of this type, not a reproduction of the YES Platform's official technical requirements.
| Test Scenario | Expected Evidence |
|---|---|
| Successful payment | The obligation status is correctly updated and the transaction is reflected in the relevant systems |
| Repeated payment request | Duplicate submission does not create an unintended second transaction |
| Integration failure | The system records the failure and supports controlled recovery or reconciliation |
| Performance test | Agreed response-time and transaction-success targets are met under the specified workload |
| Access control | Users cannot access data or functions beyond their permissions |
| Recovery test | Data and service consistency are preserved or restored according to agreed requirements |
A complete acceptance protocol would define the initial conditions, test data, execution steps, expected outcomes, and evidence required for each scenario.
For example, a performance requirement should specify not only the acceptable response time but also the workload under which that response time must be achieved.
A portal serving ten users should not be evaluated under the same assumptions as one expected to support thousands of simultaneous transactions.
The purpose of acceptance testing is not to generate a large quantity of documentation.
It is to establish objective evidence that the system behaves as required.
Financial Transactions Require Particular Attention
When digital platforms handle financial obligations, even small inconsistencies can create significant operational consequences.
An incorrectly displayed label may confuse a user.
An incorrectly recorded payment can create a dispute.
And an inconsistency between financial records may require a complex reconciliation process.
One important technical concept in this context is idempotency.
In API design, idempotency allows repeated execution of an operation to avoid unintended additional effects.
For example, if a payment-related request is submitted again because the original response was lost, the system should have safeguards against creating an unintended duplicate transaction.
This cannot reliably be achieved through interface design alone.
It requires appropriate server-side logic and coordination with payment-processing components.
Financial reconciliation is equally important.
The platform should be capable of identifying discrepancies between payment confirmations and the recorded status of obligations.
These controls are not minor implementation details.
They are essential to maintaining confidence in a digital service.
And because financial operations involve multiple components, they must be tested across the complete transaction lifecycle.
Security Is Part of Functionality, Not an Optional Final Stage
Another common weakness in enterprise projects is treating cybersecurity as a separate activity performed shortly before launch.
In reality, security should be incorporated into architecture, development, integration, and testing from the beginning.
This is especially important when a platform handles personal information, financial records, or access to public services.
The OWASP Application Security Verification Standard (ASVS) provides a useful framework for evaluating application security requirements.
It addresses areas such as authentication, authorisation, data handling, API security, and related controls.
However, vulnerability testing alone is not sufficient.
An application may be resistant to SQL injection while still containing weaknesses in its business logic.
For example, a user may be able to access another person's records because object-level permissions have not been implemented correctly.
Or an operation may be repeated in a way that produces an unintended financial result.
These problems may not be identified by basic infrastructure checks.
They require testing based on the actual business processes that the application supports.
For digital public services, technical security and functional correctness are closely connected.
A service cannot be considered reliable if its functions work but its access controls do not.
What Happens After the Acceptance Certificate Is Signed?
Software does not stop requiring maintenance when development is complete.
Operating environments change.
External integrations evolve.
New security vulnerabilities are discovered.
Business processes are modified.
Regulatory requirements may also change.
Therefore, a successful project needs more than a formal acceptance procedure.
It needs an operational model for what happens afterwards.
Before contract completion, customers should understand which technical documents will be delivered, who will control administrative access, and what rights the organisation has to use, maintain, and modify the software.
Source-code ownership and licensing rights should be clearly addressed where relevant.
The contract should also distinguish between three different types of work.
Warranty remediation covers the correction of defects according to the agreed warranty terms.
Technical support covers the ongoing services and response obligations defined in the support agreement.
Future development includes new features, additional integrations, and changes outside the original project scope.
These are not automatically interchangeable.
If the contract does not clearly define them, disputes may arise after deployment about which activities are included in the original price.
For public-sector platforms, another consideration is particularly important: the customer's ability to continue operating and developing the system without becoming completely dependent on a single supplier.
That requires appropriate documentation, access arrangements, deployment procedures, and contractual rights.
These matters are easiest to resolve before a contract is awarded, rather than after a supplier relationship has become difficult.
Why Projects With Multiple Contractors Need Stronger Integration Governance
The YES procurement structure also raises a useful architectural question.
One procurement package concerns infrastructure and core platform components.
Another concerns business process automation.
Separating these workstreams can be entirely reasonable.
It may allow specialised suppliers to participate and enable more focused technical requirements.
But multiple contracts also create dependencies.
Suppose one contractor delivers core infrastructure and another builds the application layer.
The parties must agree on interfaces, authentication mechanisms, data formats, error handling, availability assumptions, and deployment responsibilities.
If these decisions are postponed, integration problems may appear late in the project.
Each contractor may have fulfilled its individual obligations while the complete platform still requires additional work.
A strong governance model therefore needs a clearly defined integration architecture, shared testing procedures, and responsibility for resolving issues affecting multiple components.
This is not a claim that such problems exist in the YES project.
It is a general engineering consideration relevant to large, multi-stage technology programmes.
And it deserves attention whenever the success of one contract depends on the successful completion of another.
What Private Businesses Can Learn From Public Digital Projects
Although YES is associated with municipal administration, the engineering questions raised by such projects are equally relevant to the private sector.
An ERP implementation may be technically completed while inventory and financial records remain inconsistent.
A CRM platform may function correctly on its own but fail to transfer customer requests between departments.
A banking platform may pass individual application tests while certain integrated transaction scenarios remain unresolved.
These problems do not always indicate that the software itself is defective.
Sometimes they arise from incomplete requirements.
Sometimes from poorly defined interfaces.
And sometimes from acceptance criteria that focus on software delivery rather than measurable business outcomes.
For organisations planning major IT investments, three questions should guide the process.
What exactly should improve?
The answer should describe a measurable business process, not merely a list of equipment or software components.
How will we prove that the improvement has been delivered?
The answer should include agreed tests, measurable results, and documented evidence.
Who will keep the system operating after launch?
The answer should establish maintenance, support, responsibility, and long-term operational arrangements.
These questions are relevant whether the project involves a municipal service, banking infrastructure, an enterprise application, or a corporate data platform.
Digital Transformation Is Not the Same as Software Installation
Technology projects are frequently described through visible milestones.
A platform has been launched.
A database has been created.
A portal has gone live.
An administrative process has been automated.
These developments may represent genuine progress.
But the existence of a new system is not, by itself, proof that digital transformation has succeeded.
For a citizen, success means being able to access a service reliably and conveniently.
For a public institution, it means more effective and transparent operations.
For an IT department, it means a platform that is secure, maintainable, and technically reliable.
And for the organisation funding the project, success means receiving measurable value from the investment.
This is why acceptance criteria matter so much.
Software can be installed.
Documentation can be transferred.
An acceptance certificate can be signed.
But demonstrating that a system genuinely performs its intended function requires more than completing those formalities.
It requires evidence.
Yerevan's YES Platform and the Question Every IT Customer Should Ask
The procurement procedures announced in October 2026 provide a timely opportunity to discuss the quality of large digital projects before their implementation results become available.
At this stage, requirements can still define how future success will be evaluated.
Which operations must work without error?
How will financial records be reconciled?
What happens when an external integration becomes unavailable?
Who is responsible for security and long-term support?
And what evidence will demonstrate that the platform is ready for production?
These questions matter far more than the appearance of an interface or the number of functions included in a project description.
Because the success of digital transformation should not be measured simply by whether a new platform exists.
It should be measured by how reliably and effectively the services built around that platform actually work.
And when the next major IT project approaches completion, the customer should ask more than the familiar question:
“Has everything specified in the contract been delivered?”
There is a more important one:
“Can we prove that the system actually does what we paid for?”
Ultimately, the answer determines the real value of a technology investment.