The challenge
The Consell Comarcal d’Osona needed to prepare the tender for its new county-wide service covering source-separated waste collection, street cleaning and recycling centres, in a context where management models were being transformed.
The complexity didn’t come only from the contract’s scale. The 37 participating municipalities had different needs, collection models, services and paces of change — some already had door-to-door systems, others were still running container-based models.
The challenge was turning that diversity into a tender that was coherent, technically sound and economically structured, while flexible enough to let municipalities evolve over the life of the contract.
In Vic’s case especially, the high-efficiency model to be rolled out across the whole city hadn’t been defined yet. So it was important that the specifications didn’t lock in today a decision that still needed to be made tomorrow.
The question wasn’t just how to tender the current service. It was how to build a contract able to accompany the territory’s future transformation.
Project development
The work combined the technical definition of the service with building the economic and contractual structure needed to take it to tender.
We worked on:
- Analysis of each municipality’s starting situation.
- Gathering and structuring municipal needs.
- Defining the services to be delegated to the Consell Comarcal.
- Defining the services planned for each municipality.
- Sizing the door-to-door and container-based collection services.
- Defining frequencies, shifts, teams, vehicles and resources.
- Incorporating fixed and mobile recycling-centre services.
- Defining commercial and reinforcement services.
- Incorporating technology, identification and monitoring systems.
- Defining communication and rollout services.
- Structuring cleaning, maintenance and replacement services.
- Defining variable and occasional services.
- Drafting the Technical Specifications.
- Supporting the drafting of the Administrative Clauses.
- Defining technical and automatic scoring criteria.
- Building the contract’s cost structure.
- Defining fixed, rollout and variable costs.
- Defining unit prices for services and resources.
- Preparing the documentation needed for the tender.
A tender designed to evolve
One of the project’s most innovative elements was not locking a single snapshot of the future service into the specifications.
The contract was structured with different phases for the municipalities that needed to transform their model. This let the service evolve within the same contract as new systems were rolled out. In Vic’s case, this structure ran to four phases.
Vic’s Phase 4 was deliberately framed as an open phase: the city’s final model still had to be determined, and the specifications had to allow it to be added later.
To make that possible, we worked with unit prices tied to different resources and service configurations. That way, the contract had an economic base for costing the future model without having to fully define it at the point of tendering.
The innovation wasn’t just introducing contractual flexibility. It was using the contract’s economic structure as a tool to preserve future decision-making capacity.
A flexible contract
Technical flexibility needed an economic structure to make it possible.
So the contract was structured by separating out:
- Fixed costs. The resources needed to guarantee the services planned for each municipality.
- Rollout costs. The investments tied to changing systems, including containers, technology and campaigns.
- Variable costs. Services that could be activated according to real needs during the life of the contract.
This structure made it possible to adapt the service without having to contractually rebuild the whole tender every time something changed.
Results
- Drafting of the Technical Specifications for the new county service.
- Support drafting the Administrative Clauses.
- Defining the service structure for the 37 municipalities.
- Sizing collection services and associated resources.
- Incorporating door-to-door models, containers and identification systems.
- Defining recycling-centre, cleaning, maintenance and complementary services.
- Incorporating technology, monitoring and information management.
- Defining rollout and communication campaigns.
- Defining criteria for scoring bids.
- Building the contract’s cost structure.
- Defining fixed, rollout and variable costs.
- Creating a unit-price system to adapt services to real needs.
- Structuring the rollout in phases for municipalities undergoing transformation.
- Designing a specific flexibility mechanism for Vic’s future transformation.
Conclusions
The project showed that a tender can also be a tool for planning the future.
In a service meant to run for years and absorb major transformations, locking in every decision at the point of drafting the specifications would have meant committing today to decisions the territory still needed to test.
That’s why we worked on a contractual architecture able to combine definition, control and flexibility: precisely defining the known services, establishing a solid economic base, and leaving room to evolve once the future model was defined.
In Vic’s case, this approach went one step further: the tender had to allow the city to decide on its best model without the contract itself standing in the way of implementing it.
Lessons learned
Specifications shouldn’t freeze the future. When a territory is in the middle of transformation, the contract needs to leave room for decisions that haven’t been made yet.
Flexibility has to be designed too. Leaving doors open isn’t enough — flexibility has to be translated into concrete phases, service units, prices and contractual mechanisms.
Unit prices can be a planning tool. They let you build a shared economic base while still allowing the service to be adapted later to whatever configuration is finally chosen.
Rollout can be part of the contract’s own design. Planning different phases allows for gradual progress, absorbing lessons learned, and reducing the risk of irreversible decisions.
Good specifications don’t just describe what the service will look like. They need to let the service evolve.