When a deliverable becomes paperwork, public service becomes a matter of luck
In Greece, public infrastructure rarely fails suddenly.
It fails slowly.
Predictably.
Repeatedly.
And, most importantly, without the kind of consequences that would force the system to learn.
A cable falls.
A road collapses.
A public digital service goes down.
An IT project is delivered on paper, but not in reality.
A critical service remains unavailable.
A citizen waits.
A business waits.
A city waits.
And somewhere inside the machinery of the state, time stops being measured.
That is the real problem.
Not only failure.
But failure without a clock.
Failure without clear ownership.
Without escalation.
Without a measurable obligation to respond, restore, inform, and improve.
In the private sector, we usually call this an SLA — a Service Level Agreement. It defines expectations, response times, restoration times, availability, support obligations, severity levels, escalation paths, penalties, and accountability.
In the Greek public sector, however, the idea of an SLA often becomes something else.
A formal phrase.
A technical appendix.
A contractual decoration.
A text that looks serious enough to be included in a tender or contract, but not strong enough to actually change the behavior of the system.
That is why, in practice, many public sector SLAs mean almost nothing.
Not because Greece has no legal framework for public procurement. It does. Law 4412/2016 is the core framework for public works, supplies and services, aligned with EU Directives 2014/24/EU and 2014/25/EU. Greece also has ESIDIS, the National Electronic Public Procurement System, serving as an online portal for electronic public tenders for supplies, services and public works.
So the problem is not that rules do not exist.
The problem is deeper.
The problem is that formal compliance is often confused with real operational capability.
And those two things are not the same.
Compliance is not performance
A public contract can be legally correct and operationally weak.
A tender can be published correctly.
A contractor can be selected correctly.
A project can be formally delivered.
An acceptance committee can sign off.
A payment can be processed.
A file can be complete.
And still, the citizen may receive little or no real value.
This is the central structural irony of many public projects: the system is often better at proving that a procedure happened than proving that a capability exists.
It can prove that a deliverable was submitted.
But can it prove that the deliverable works?
Can it prove that it works under real conditions?
Can it prove that it continues to work six months later?
Can it prove that someone monitors it?
Can it prove that there is a response time when it fails?
Can it prove that failure has consequences?
That is where the gap begins.
A deliverable is not a PDF.
A deliverable is not a PowerPoint presentation.
A deliverable is not a meeting minute.
A deliverable is not a folder uploaded into a public procurement platform.
A deliverable is not the document that gets accepted.
A deliverable is the capability that is proven to work.
When that is missing, the public contract does not buy an outcome.
It buys an alibi.
This is the point where the public contract loses its essence.
Because the citizen does not care whether the file is complete.
The citizen does not care whether the report is properly formatted.
The citizen does not care whether the acceptance protocol has signatures.
The citizen does not care whether the contractor described its actions convincingly.
The citizen cares whether the service works.
Whether the system responds.
Whether the road is safe.
Whether the failure is restored.
Whether the platform is available.
Whether the infrastructure is maintained.
Whether the project paid for with public money produced real, measurable, and sustainable value.
The legal framework is not, by itself, a guarantee of reality
It would be inaccurate to say that Greece has no legal framework for public contracts, acceptances, controls, committees, penalties, or contractor obligations.
It does.
There are provisions.
There are procedures.
There are bodies.
There are systems.
There are forms.
There are minutes.
There are signatures.
But the existence of a framework does not automatically mean that the framework is always properly designed, properly applied, or capable of producing real public benefit.
Because the legality of a procedure is one thing.
The substantive value of the result is another.
A process can be formally lawful and operationally inadequate at the same time.
An acceptance committee may consist of capable and honest people, but still be asked to evaluate not reality itself, but the narrative of reality as captured in documents.
And that is one of the deepest dysfunctions.
When obligations, controls, and acceptances are exhausted in papers, minutes, reports, declarations of compliance, and descriptions of actions, then the system does not verify whether real value was created.
It verifies whether enough documentation was created to assume that value was created.
And those are two completely different things.
What is the use of a committee made up of decent and competent people if the mechanism given to them leads them to review narratives on paper rather than measure reality?
What is the use of honest intention when the object of control is the description of functionality and not functionality itself?
What is the use of acceptance when public value is not tested under real conditions?
The problem is not only that rules are not always applied.
The problem is that even when they are applied, they are often applied to the paperwork and not to reality.
So it is not enough to have committees.
It is not enough to have deliverables.
It is not enough to have penalties.
It is not enough to have a legal framework.
The critical question is:
What exactly is being checked?
Is the existence of a document being checked, or the operation of a capability?
Is the description of a service being checked, or its real performance?
Is compliance with a file being checked, or value to the citizen?
Is the system checking whether something was delivered, or whether something works?
If the public sector does not shift the weight from formal documentation to real proof of operation, then even the best institutional framework will keep producing the same result:
projects that close administratively,
systems that do not mature operationally,
services that are not truly measured,
and citizens who are left to live with the consequences.
The rules exist. The question is what they actually measure.
The Greek public procurement framework includes mechanisms for acceptance, control, and consequences. In contractual documents and tender specifications, one often finds provisions for acceptance of services or deliverables by committees, control procedures, possible replacement of services or deliverables, and penalty clauses in cases of delay or deviation from contractual terms.
So the issue is not the complete absence of rules.
The issue is whether the rules are designed, written, monitored, and enforced in a way that creates real pressure for performance.
Because a clause that is never activated is not accountability.
A penalty that exists only theoretically is not discipline.
An acceptance process that checks the existence of files but not the operational quality of the outcome is not quality control.
A contract that measures delivery dates but not service behavior after delivery is not a serious contract for critical infrastructure.
And an SLA without monitoring is not an SLA.
It is a promise without a witness.
Public sector SLAs often fail before the project even begins
The failure of public sector SLAs often starts at the design stage.
Before the contractor.
Before the implementation.
Before the first invoice.
Before the first delay.
It starts when the contracting authority does not define what success means in measurable operational terms.
Too many projects are designed around activities instead of outcomes.
“Develop a platform.”
“Deliver a study.”
“Implement a system.”
“Provide support.”
“Ensure availability.”
“Train users.”
“Submit documentation.”
All of these phrases may be necessary.
But they are not sufficient.
What does “availability” mean?
99%?
99.5%?
99.9%?
Measured monthly?
Quarterly?
Annually?
Does it exclude scheduled maintenance or include it?
Who measures it?
With what tool?
Where are the logs?
Who has access to them?
What is the maximum first response time for a critical incident?
What is the maximum restoration time?
What happens if the service remains unavailable?
How are citizens informed?
What is the escalation path?
Who signs off not only that the system was delivered, but that it performed according to the agreed service levels?
If these questions are not answered clearly, then the SLA is already dead.
It may still exist as text.
But it does not exist as an operating mechanism.
The Greek disease: acceptance without proof
One of the most dangerous weaknesses in public projects is the belief that acceptance is mainly an administrative act.
A committee receives.
The contractor submits.
The files exist.
The documents look complete.
The project “closes.”
But what exactly was accepted?
A document?
A version?
An installation?
A pilot environment?
A production service?
A real operational capability?
In technology projects, this distinction is critical.
A platform that opens on a test server is not necessarily a public service.
An API that responds once during a demonstration is not necessarily a reliable integration.
A dashboard with sample data is not necessarily a decision-support system.
A mobile application uploaded to an app store is not necessarily a functioning citizen service.
A database with records is not necessarily trusted data infrastructure.
A report is not necessarily intelligence.
A system is not “delivered” when it appears.
It is delivered when it performs.
And performance must be measured.
The difference between delivery and capability
Public contracts often buy deliverables.
But society needs capabilities.
This is not a semantic detail.
It is the difference between bureaucracy and transformation.
A deliverable says:
“The contractor submitted what was required.”
A capability says:
“The organization can now do something it could not do before.”
A deliverable closes a file.
A capability changes reality.
A deliverable is archived.
A capability operates.
A deliverable is static.
A capability is alive.
This distinction is absolutely critical for every serious public project, especially in infrastructure, digital government, utilities, waste management, transport, energy, health, and municipal services.
If a public body buys software, the deliverable is not the software.
The deliverable is the ability to execute a process better, faster, more safely, and with measurable reliability.
If a public body buys a monitoring system, the deliverable is not the dashboard.
The deliverable is the ability to detect, respond to, and prevent failures.
If a public body buys a maintenance service, the deliverable is not the monthly report.
The deliverable is uptime, response time, restoration time, and documented intervention.
If a public body buys a smart city platform, the deliverable is not a map with icons.
The deliverable is operational intelligence.
And if none of that is measured, then nothing essential has been delivered.
When nobody owns the clock, nobody owns the failure
The most important element of an SLA is not the number.
It is the clock.
The moment an incident begins, time must start counting.
When was the problem detected?
By whom?
Was it detected automatically or through a citizen complaint?
When was the responsible party notified?
When was the first response?
When was the first field action?
When was the problem contained?
When was service restored?
When was the root cause documented?
When was prevention planned?
When was the public informed?
This is how mature systems operate.
They do not simply react.
They record.
They measure.
They learn.
They create institutional memory.
In immature systems, incidents dissolve into fog.
Someone called someone.
A crew went somewhere.
A department was informed.
The contractor was notified.
The problem was “handled.”
No exact timeline.
No public performance indicator.
No open incident report.
No measurable service violation.
No visible consequence.
No institutional learning.
And then everyone waits for the next incident.
This is not an SLA culture.
It is survival through improvisation.
The citizen pays for the absence of consequences
In the private sector, poor service eventually creates pressure.
Customers leave.
Contracts are terminated.
Reputation suffers.
Revenue declines.
Management is questioned.
In the public sector, the citizen often cannot leave.
The citizen cannot choose another electricity distribution network for the sidewalk outside his home.
The citizen cannot choose another municipality for road safety tomorrow morning.
The citizen cannot choose another public administration when a digital service collapses.
The citizen is captive.
And because the citizen is captive, the ethical obligation of the public sector is even greater.
A public SLA should not be weaker than a private SLA.
It should be stronger.
Because the public sector does not simply provide services.
It protects trust.
It protects safety.
It protects equal access.
It protects continuity.
It protects the ordinary citizen who has no alternative provider.
When a public service fails, the damage is not only operational.
It is civic.
It tells the citizen that his time does not matter.
That his risk does not matter.
That his inconvenience does not matter.
That his dignity does not matter.
And in the most serious cases, that his safety does not matter enough until something tragic happens.
The cost excuse
There is always a reason.
Not enough budget.
Not enough staff.
Old infrastructure.
Complex procedures.
Legal constraints.
Fragmented responsibilities.
Lack of coordination.
Procurement delays.
Some of these reasons are real.
But they are not always explanations.
Sometimes they are rituals.
They are repeated so often that they become a national language of resignation.
Of course infrastructure costs money.
Of course prevention costs money.
Of course underground networks, modern monitoring, preventive maintenance, digital incident management, and real accountability frameworks require investment.
But the question is not only:
“How much does prevention cost?”
The question is also:
“How much does failure cost?”
How much does it cost when a road remains dangerous?
How much does it cost when a system is down?
How much does it cost when response to an urgent incident is slow?
How much does it cost when businesses lose hours?
How much does it cost when citizens stop trusting institutions?
How much does it cost when a preventable incident becomes a tragedy?
The absence of investment is not free.
It is simply paid later.
Usually by someone else.
What a serious public sector SLA should include
A serious SLA in a public contract should not be a decorative appendix.
It should be an operational tool.
At minimum, it should clearly define:
First, the exact scope of the service.
What is covered? What is excluded? Which systems, locations, users, environments, and processes are included?
Second, incident severity levels.
Not all problems are the same. A cosmetic error is not the same as a safety-related failure. A slow dashboard is not the same as a critical service being unavailable.
Third, response times.
How quickly must the responsible party acknowledge and take ownership of the incident?
Fourth, restoration times.
How quickly must the service be restored, depending on severity?
Fifth, escalation procedures.
Who is informed? When? At what level? After how much delay?
Sixth, monitoring and evidence.
Who measures the SLA? With what tools? Are the logs reliable? Are reports automatic? Can the public body verify the contractor’s claims?
Seventh, reporting obligations.
What do monthly or quarterly reports include? Incidents, downtime, causes, corrective actions, recurring failures, open risks?
Eighth, penalties and corrective measures.
What happens when the SLA is violated? Are penalties automatic? Are they meaningful? Can repeated failures trigger stronger consequences?
Ninth, acceptance criteria.
How is the deliverable tested before acceptance? Functional tests? Load tests? Security tests? User acceptance tests? Pilot operation? Independent verification?
Tenth, responsibility after delivery.
Who owns the system the next morning? Who maintains it? Who responds? Who updates it? Who is responsible for continuity?
Without these elements, an SLA is not a management tool.
It is a paragraph.
Public dashboards, not private excuses
One of the most powerful reforms Greece could adopt across critical public services is public visibility of performance.
Not for theatrical transparency.
But for discipline.
If public services had dashboards showing availability, response times, incident categories, restoration times, and open issues, the conversation would change.
Not everything should be public, especially where security issues exist.
But aggregated service performance can and should be visible.
Because what is measured privately can be hidden.
What is measured publicly creates pressure.
Imagine a municipality publishing average response time for road damage.
Imagine a utility publishing restoration times by area.
Imagine a public digital platform publishing availability statistics.
Imagine public projects being evaluated not only by fund absorption, but by operational performance six and twelve months after delivery.
That would change the definition of success.
Today, too often, success means:
The project was approved.
The funding was absorbed.
The deliverables were submitted.
The acceptance was signed.
Tomorrow, success should mean:
The capability works.
The service is measured.
The citizen experience improved.
Failures are recorded.
Response times are respected.
Accountability is visible.
The real reform is cultural
Greece does not only need better tender templates.
It needs a different philosophy of public service.
A philosophy where time matters.
Where maintenance matters.
Where prevention matters.
Where a deliverable must prove value.
Where a contract is not a bureaucratic ceremony, but a living obligation.
Where the acceptance committee does not simply ask:
“Was it submitted?”
But asks:
Does it work?
Can it withstand real conditions?
Can it be monitored?
Can it be audited?
Can it be proven?
Who owns it tomorrow morning?
What happens when it fails?
This is the difference between a state that buys things and a state that builds capabilities.
And Greece desperately needs the second.
A country without response time
A country is not modern because it has platforms.
It is modern when those platforms work.
A city is not smart because it has sensors.
It is smart when it can respond.
A public contract is not successful because it was completed.
It is successful when it creates measurable public value.
A deliverable is not real because it was accepted.
It is real when it changes operational reality.
And an SLA does not matter because it appears in a document.
It matters only when someone measures it, someone owns it, and someone pays the price when it fails.
That is why public sector SLAs in Greece often mean almost nothing.
Not because the country has no laws.
Not because there are no procedures.
Not because there are no platforms.
But because the culture of measurable responsibility remains weak.
We have learned to produce files.
We have learned to close projects.
We have learned to sign acceptances.
We have learned to explain delays.
We have learned to normalize dysfunction.
What we have not learned — at least not consistently — is to measure public service as a living obligation toward the citizen.
And until we do, every failure will continue to be described as an unfortunate incident.
A bad moment.
A technical issue.
A delay.
A misunderstanding.
A matter under investigation.
But it is not only that.
It is the predictable result of systems without clocks, contracts without teeth, deliverables without proof, and public responsibility without consequence.
A country does not collapse only when its infrastructure breaks.
It collapses slowly, when nobody is surprised anymore.
And that may be the most dangerous failure of all.
