Shared ILS, Separate Governance: Making Consortium Tech Work

I've watched consortia succeed and fail based entirely on governance structure.

Not because the technology was bad. Not because the members didn't want to cooperate. They failed because nobody put in writing who decides what, and when the first serious conflict happened, the system collapsed.

I know governance sounds boring. I know it does. You want to talk about technology. You want to implement something clever. You want to show your board you're doing something.

But I watched a 12-library consortium fall apart because the largest library got 40% of the vote but wanted to run 70% of the upgrade decisions. I watched staff people get caught between conflicting member demands with no authority to resolve it. I watched a director resign because she was taking heat from her board for decisions made by committee vote that she had no control over.

So let me tell you what actually works, because I've seen it fail a dozen ways first.

Why This Matters: What I've Actually Seen Go Wrong

Shared ILS consortia are economically brilliant. One system instead of 25. One vendor contract instead of 25. One IT director managing shared infrastructure instead of 25 directors managing separate systems. The economics are undeniable.

The politics are a minefield.

I saw a consortium where the governance structure said "majority vote on system upgrades." The six large urban libraries outvoted the five rural libraries. The rural libraries wanted stability. The urban libraries wanted features. Every upgrade cycle became a battle that left the rural directors feeling steamrolled and the urban directors frustrated about not being able to modernize.

Two years in, one rural library left. Its exit cost was $80,000. The remaining libraries absorbed the cost increase. The consortium was smaller, less sustainable, and more resentful.

I saw another consortium where nobody wrote down who could request custom features or what that would cost. One library asked for a custom report. Nobody knew if it should be free, $2,000, or $20,000. The IT director estimated one number. The requesting library expected half that. The consortium board got mad at the IT director. The IT director left. The consortium hired a new one and started over.

I saw a 14-library Evergreen consortium where the biggest library\'s tech director got voted off the IT Steering Committee after pushing for an upgrade the others didn\'t want. That library stayed for two more years, then left. They're now running their own Koha instance. The consortium lost 20% of its patron base and 25% of its circulation. The per-library costs for everyone else went up.

The common thread: No written governance. Or written governance that nobody enforced. Or governance that didn't account for power imbalances.

The Central Challenge: One System, Many Masters

Here\'s what you're actually dealing with:

Technical Challenge (Real Consequence: Your System Can't Scale)

You need one system. Shared bibliographic records. Shared patron authority. But Library A (urban, 500,000 patrons, tech-forward) wants 3-week checkouts and full mobile app integration. Library B (rural, 50,000 patrons) wants 2-week checkouts and doesn't have staff to support mobile features.

Can the system support both? Sometimes. But it costs. Multi-tenancy. Custom configuration. Separate data structures. $50,000-$150,000 in extra implementation costs, plus ongoing maintenance complexity.

Without governance, nobody owns the decision about what gets customized and what gets standardized. So you end up with both. The system becomes bloated, expensive, and fragile.

Political Challenge (Real Consequence: Staff Gets Destroyed)

You just told your IT director that Library A wants an upgrade and Library B doesn\'t. The Board can\'t agree. So the IT director is caught between two libraries with conflicting demands and zero authority to resolve it.

I watched an IT director spend six months mediating a dispute about circulation policies. It wasn't her job. It paid the same salary either way. She was miserable. She left. The consortium hired a replacement and started over.

Without clear governance, every conflict lands on the IT director. The calls to libraries saying "Sorry, that\'s not supported." The explanations for why a budget recommendation got cut. The frustration from directors who have nowhere else to direct it. That\'s a governance gap, not a personnel problem.

Financial Challenge (Real Consequence: Members Leave)

Let's say you decided to split costs equally. All members pay $50,000/year for a $500,000 system.

Then a member leaves and costs go up. Suddenly everyone else pays $56,250.

The library that was already questioning membership just got a 12.5% increase for reasons completely outside its control. It leaves too.

Now you have 8 members instead of 10. Per-library cost is $62,500. That's a 25% increase from your starting point, all because two members left.

Without clear, documented cost allocation and member exit procedures, this happens silently. Your margins disappear. Your members get angry. Your consortium shrinks.

Technical Realities of Shared ILS

Evergreen: Built for Consortia

Evergreen is the gold standard. It was designed for consortia.

Architecture: Multiple libraries can run on a single Evergreen instance with complete separation. Different circulation policies. Different item types. Different patron categories. Different staff accounts and permissions.

Drawback: You need strong local IT. Evergreen is open-source. You\'re not buying support from a vendor. You\'re hiring developers or paying support companies.

Cost: Depends on your IT expertise. $50,000-$200,000 to implement, $50,000-$100,000 per year for ongoing support.

Consortia using Evergreen: Georgia PINES (50+ libraries), Jersey (New Jersey academic libraries), Sitka (British Columbia).

Koha: Can Work, With More Work

Koha is also open-source. It supports multi-tenant configurations, but not as cleanly as Evergreen.

You can run separate instances of Koha for each library and federate searches. Works, but operationally more complex.

Cost: Similar to Evergreen. Maybe slightly lower because Koha community support is more accessible.

Proprietary Systems: Expensive Multi-Tenancy

If you're using Ex Libris Alma, Follett, or other proprietary systems, they usually have a "multi-tenant" mode.

Translation: You pay extra. Sometimes way extra.

Some vendors charge 30-50% premium for consortial configurations. Your $40,000 per library now becomes $55,000-$60,000.

The Autonomy Trade-Off

The trade-off is real: Shared ILS saves money but reduces local autonomy.

A single library implementing an ILS can configure it exactly how they want. Consortium members cannot.

You need policies. Unified policies. And some members will want to violate those policies.

Governance Structure That Actually Works (I Know This Because I've Seen The Broken Versions)

Three tiers. Not more. More tiers and you're running a corporation instead of a consortium.

Here\'s the structure I\'ve seen work consistently: Clear authority at each level, written decision authority matrix, and ruthless clarity about who decides what.

Tier 1: Consortium Board (The People Who Fire The Vendor)

Directors (or deputy directors, or whoever your members say represents them). One per member library, plus the consortium IT director. That's your board.

The board decides:

• Vendor selection or renewal (in writing, with clear evaluation criteria)
• Major system upgrades (versions, go-live dates, no exceptions)
• New member admission (evaluate fit, discuss governance, get consensus)
• Member termination (when someone wants to leave without following exit procedures)
• Annual budget (approve total spend, delegate allocation to IT Steering)
• Governance changes (voting procedures, cost models, conflict resolution processes)

Board meets quarterly. No exceptions. Consistency matters more than agenda.

Here's the critical part: The board needs voting rules. Not "consensus," which means one difficult library can block everything. Real voting rules.

I recommend: Majority vote (>50%) on routine decisions. Super-majority (66%) on vendor renewal or major process changes. This prevents one large library from dominating, but also prevents one rural library from blocking progress.

Tier 2: IT Steering Committee (The People Who Actually Run The System)

IT directors from each member library, plus the consortium IT director. This committee is where technical reality happens.

IT Steering decides:

• Configuration standards (what\'s standardized, what\'s locally configurable)
• Data quality policies (how do we maintain records together)
• Upgrade schedules and testing protocols (who tests what, by when)
• Member-requested custom features (estimate cost, decide if it's worth it, vote)
• SLA monitoring (track uptime, response times, hold vendors accountable)

IT Steering meets monthly. Decisions are documented in writing and reported to the Board.

The key: IT Steering has a $5,000-$25,000 budget for low-impact custom work. Anything under $5,000 they can approve. $5,000-$25,000 needs consensus. Over $25,000 goes to the Board and the requesting library funds it themselves.

This prevents death-by-a-thousand-customizations. It also prevents any single member from getting special treatment.

Tier 3: Member Libraries (You Manage Your People, Not The System)

Individual libraries do their jobs within the policies set by Tiers 1 and 2.

Member libraries control:

• Local circulation policy parameters (you set checkout periods within approved templates)
• Staff accounts and permissions (you manage your own access control)
• Day-to-day operations (shelving, weeding, acquisitions decisions)
• Local branch/location configuration (how many branches, how they're organized)

Member libraries do NOT control:

• System upgrades (Board decides, IT Steering implements, all members move together)
• Core database structure (shared bibliographic records, shared authority, no local variations)
• Vendor relationships (the consortium negotiates, not individual libraries)

Decision Authority Matrix (The One Document That Prevents Fights)

This needs to be written. Not just in your head. Written. Laminated. Distributed to every member.

Notice: The Board approves what matters (vendor, major upgrades, exits). IT Steering decides operational details. Members execute within boundaries. Clear authority prevents overlap and conflicts.

Documentation: Have a Written Governance Charter

Your governance structure must be documented. Not suggested. Documented.

A governance charter should include:

1. Board structure and voting rules
2. IT Steering Committee composition and authority
3. Member rights and responsibilities
4. Decision-making processes (majority vote? Consensus? Super-majority?)
5. Conflict resolution procedure
6. Amendment process
7. Member admission and exit procedures
8. Cost allocation methodology
9. SLA standards
10. Confidentiality and non-disclosure agreements
11. Termination conditions

This becomes your operational constitution. When disputes arise, you have written policy to refer to.

Service Level Agreements (SLAs): Your Accountability Mechanism

An SLA is your contract with members about what they can expect.

System Uptime Target (SLA)

Template: "Consortium will maintain system uptime of 99.5%, measured monthly. Scheduled maintenance downtime (announced 7 days in advance) does not count against this metric."

Why 99.5%? That's roughly 3.6 hours of unplanned downtime per month. Reasonable for a shared system.

Measurement: Public-facing dashboard showing real-time system status. No hidden downtime.

Support Response Times

Template:

• Critical (system down, patron access blocked): 4-hour initial response, updated every 2 hours until resolved
• High (major functionality impaired): 8-hour response
• Medium (workaround available): 24-hour response
• Low (request, no current impact): 5-business-day response

Upgrade Notice

Template: "Consortium will provide 90 days notice for major system upgrades. Member libraries must complete testing in the provided sandbox environment at least 30 days before go-live. Last-minute testing objections do not warrant delaying consortium-wide deployments."

This is how you handle the member who waits until the last minute to test something and says "We need to delay the upgrade because we found a problem."

Training Availability

Template: "Consortium provides monthly webinar training on system features and new functionality. Custom training for individual libraries available at $1,000 per day."

What Happens If You Miss an SLA?

Options:

• Automatic credit to the member (e.g., 1% fee credit for each month SLA is missed)
• Priority for the next upgrade or enhancement
• Reduction in support fees for next year

Pick one. Document it. Execute it consistently.

Cost Allocation Models

This is the decision that will haunt you. Choose carefully.

Per-Capita Model

Cost per library = (Total Consortium Cost) / (Sum of all patron counts)

Example: $2 million annual cost ÷ 5 million patrons = $0.40 per patron per year. Large library with 500,000 patrons pays $200,000. Small library with 50,000 patrons pays $20,000.

Pro: Feels fair. Large libraries can afford more and pay more.

Con: Incentivizes gaming (libraries report lower patron counts). Rural libraries can't grow service without proportional cost increases.

Circulation-Based Model

Cost per library = (Total Consortium Cost) × (Library's circulation ÷ Total consortium circulation)

Example: Library A has 10% of consortium circulation, pays 10% of costs.

Pro: Usage-based, incentivizes system adoption.

Con: High-traffic libraries subsidize low-traffic libraries. Rural libraries stay rural because they don't want to pay more.

Hybrid Model (Best Practice)

Base fee + transaction fee.

Example: 60% of costs split evenly among all members (base). 40% of costs split by circulation volume (usage).

Pro: Balances predictability (base fee doesn't change) with usage sensitivity (grow circulation, pay slightly more).

Con: More complex accounting.

Cost Modeling at Different Scales

Here's a realistic example of how costs change:

Notice: Total cost increases, but per-library cost decreases. That's the consortial economy of scale. Everyone benefits from growth (up to a point).

Member Library Autonomy: What\'s Standardized, What\'s Local?

What Members Can Customize Locally

• Circulation policies: Loan periods, fines, renewal limits (within approved templates)
• Item types and statuses: Create local item types if needed for local practices
• Staff accounts and permissions: Each library manages its own staff access
• Branch/location configuration: Which locations does your library operate?
• Local holds rules: How do you manage inter-library loan requests?

What Must Be Standardized

• MARC record format: Everyone uses MARC21. Not just libraries' variations of MARC.
• Authority control setup: Use shared LC/Library of Congress authorities. Not local authority files.
• Patron type definitions: Some consistency needed (e.g., all libraries define "student" the same way so shared catalogs work)
• Core database structure: Bibliographic records, authority records, holdings records follow the same structure
• System upgrade schedule: All libraries move to the same version at the same time

Policy: Feature Requests and Custom Development

When a member requests a feature that doesn't exist:

1. Member submits request to IT Steering Committee with business case
2. IT Steering assesses technical feasibility and cost
3. If cost is under $5,000: IT Steering can approve (funded from shared budget)
4. If cost is $5,000-$25,000: IT Steering recommends to Board with cost-benefit analysis
5. If cost exceeds $25,000: Request is rejected unless requesting member funds it themselves

This prevents frivolous requests and ensures custom work is proportional to its benefit.

Conflict Resolution: When Members Want Different Things

Scenario

Library A wants 3-week checkout periods. Library B wants 2-week checkout periods. They\'re in the same consortium using the same system. They can\'t both be right.

Resolution Process

1. Present to IT Steering Committee: "We have a conflict. Library A wants X, Library B wants Y."
2. Technical impact assessment: Can the system support both? (Maybe. With different configurations for different libraries.)
3. Cost analysis: How much extra work to support both policies?
4. Vote: IT Steering votes. Majority wins. Document the dissent.
5. If Library A/B seriously objects: Offer a compromise. "You can use your preferred policy, at a $5,000 annual premium for custom configuration."

Most members will accept the consortium default once they understand the cost of customization.

Template: Conflict Resolution Flowchart

Document this in your governance charter so everyone knows how disputes are handled.

Handling Member Exits (The Conversation That Makes Or Breaks Consortia)

I watched a 10-library consortium fall apart because nobody had an exit policy. One rural library wanted to leave. They didn\'t know the cost. The consortium didn\'t have a procedure. The negotiation became ugly.

By the time it was resolved, three more libraries started questioning membership. Two of them left too. The consortium didn't recover.

So: Write your exit policy before anyone wants to leave. Make it clear. Make it published. Make it fair but not soft.

Can a Member Leave Mid-Contract? (Yes, And Here's What It Costs)

Your contract with members needs to say: yes, you can leave, but there are penalties.

Example:

• After 3 years of service: Member may exit with 6 months notice. Pays 50% of remaining contract value to the consortium.
• After 1-3 years: Member may exit with 12 months notice. Pays 75% of remaining contract value.
• Year 1 (if member chooses to leave): Member pays 100% of remaining contract.

This is fair. It protects the consortium from member whiplash, but it doesn't trap anyone who genuinely needs to leave.

What Does Exiting Actually Cost? (The Real Numbers)

Talk to the exiting member about these costs upfront. Don't surprise them.

Data Export and Migration (The Exiting Member Pays This)

Getting their data out of the shared ILS and into whatever new system they're moving to: $30,000-$60,000. More if their data is messy or the new system is different.

This is the exiting member's cost. They chose to leave. They handle the migration expense.

Lost Bulk Discount (Remaining Members Feel This)

Your vendor quoted you $40,000 per library for 50 libraries. Total: $2,000,000.

One member leaves. You now have 49 libraries and the same $2,000,000 cost. Suddenly it's $40,816 per library.

Every remaining library\'s costs went up 2%, and they didn\'t choose that. This is why you need exit penalties - to protect the remaining members.

Transition Support (Split Cost)

Your IT director spends three months supporting the exiting member's migration: technical documentation, data cleanup, staff calls, validation testing.

That's roughly $15,000-$30,000 of IT director salary time, depending on complexity.

Who pays this? I recommend: Consortium covers half (from shared budget), exiting member covers half (they initiated the exit). This shares the pain fairly.

Exit Policy: What Works In Practice

Document this clearly in your member agreement before anyone signs up:

• The exiting member pays: Data migration costs ($30K-$60K) + 50% of transition support costs
• The exiting member receives credit: The exit penalty you charged them covers the transition support and some of the bulk discount impact
• The remaining members absorb: The vendor repricing that happens after someone leaves (usually $500-$1,000 per library total impact, spread over 1-3 years as vendor reprices)

Is this perfect? No. But it\'s clear, defensible, and it doesn\'t put the entire burden on remaining members or make exit penalties so harsh that members feel trapped.

Technical Debt and System Upgrades

Shared systems accumulate technical debt faster than independent systems.

Who Decides When to Upgrade?

Board makes the call, on IT Steering's recommendation.

Typical policy: "All member libraries upgrade to the latest stable version within 12 months of its release. Emergency security patches apply immediately."

Who Pays for It?

Shared budget. But sometimes there are retrofit costs. If Library A was running a custom configuration on the old version, Library A pays for retrofitting to the new version.

The Forced Upgrade Problem

In most shared systems, you can\'t opt out of upgrades. Once the consortium moves to version X, you're on version X.

This is necessary for operational consistency. But members need to accept it as part of consortium membership.

Some member wants to stay on the old version forever? Not possible in a shared system. Either accept the upgrade or leave the consortium.

Budget for Upgrades

Build an annual upgrade reserve (2-3% of annual budget) so you're not surprised when major upgrades are needed.

Real-World Example: How Governance Saved An 8-Library Consortium

Eight academic libraries implemented Evergreen in 2015 without formal governance. By 2019, they were fighting.

Two large universities wanted cutting-edge features (full API access, advanced analytics). Three smaller colleges wanted stability and simplicity (basic circulation, nothing fancy). One library was barely participating but paying full dues.

The large universities pushed for an upgrade. The smaller colleges said no. The IT director was caught in the middle. Meetings were tense.

In 2020, they finally wrote governance. Here's what changed:

The Structure They Put In Place:

• Consortium Board: 1 director from each library + consortium IT director (voting: simple majority)
• IT Steering Committee: 1 IT person from each library + consortium IT director (voting: consensus, with Board escalation if consensus fails)
• Quarterly Board meetings, monthly IT Steering meetings
• Written decision authority matrix (who decides what)
• Written cost model: 60% equal split, 40% by circulation volume
• Written exit policy: 3-year commitment, 50% exit penalty after year 3

What This Meant Financially:

• Total annual cost: $560,000 (software support, development, infrastructure)
• Per-library cost (with cost model): $48,000-$75,000 depending on size
• Proprietary alternative: $95,000-$110,000 per library
• Real savings: $200,000-$320,000 per year that the consortium could prove

What Governance Actually Prevented:

• Conflict 1: Upgrade schedule. Board voted (majority rule) on the upgrade. Large universities won. Small colleges lost, but knew why - they could see the vote, they understood the procedure, they accepted the decision. Governance made it legitimate instead of arbitrary.
• Conflict 2: Custom features. One large university wanted advanced analytics. IT Steering estimated $22,000. Under the governance rules, this required Board approval (costs over $5K). The requesting library decided it wasn't worth it at that price. Decision made, no resentment. Everyone understood the budget boundary.
• Conflict 3: Cost fairness. Small colleges worried they were subsidizing large universities. The hybrid cost model proved they weren't - they were paying less because they had less circulation. Transparency fixed the problem.

Actual Outcomes:

• All 8 libraries renewed through 2028
• One library actually left in 2023, but for budget reasons (not governance), and the exit procedure worked smoothly
• Annual member satisfaction (measured in 2024): 8.2/10
• Zero escalations to Board in last 12 months (IT Steering handles everything)

The actual lesson: Before you had governance, conflict was personal. Decisions felt arbitrary. Now that governance is written, conflict is procedural. Same disagreements, but everyone accepts the process, even when they lose.

What You Actually Need To Do Next (Not Just Templates)

You've read this. Now here are the specific governance decisions you need to make:

Decision 1: Voting Structure (This Cannot Be Vague)

Write this down: How many votes does each library get? Are all votes equal weight? Are votes by library size or by patron population?

Example: Equal votes for Board (one library = one vote). Majority rule on routine decisions, super-majority (66%) on vendor renewal.

This prevents one library from dominating and prevents deadlock.

Decision 2: Cost Model (Model It, Then Document It)

Don't guess. Spreadsheet your actual costs:

• Total annual cost (vendor, IT director, infrastructure, training)
• How much each member would pay under: (a) equal split, (b) per-capita, (c) hybrid (60% equal, 40% by circulation)
• What happens to costs if one member leaves
• What happens if you add a new member

Pick one model and lock it for 3 years. Consistency matters.

Decision 3: What\'s Standardized, What\'s Local (Draw The Line Clearly)

Make a table. Left column: system configurations. Right column: must be standardized or can be local?

Example:

• MARC record format → Standardized (LC MARC21, no exceptions)
• Circulation policies → Local (within templates)
• System upgrades → Standardized (all members move together)
• Item types → Local (each library can define their own)
• Authority control → Standardized (shared LC authorities only)
• Patron types → Standardized (limited set so searches work across consortia)

This prevents infinite arguments about what "flexibility" means.

Decision 4: Custom Feature Budget (Set the Limits Now)

Your IT Steering Committee needs budget authority. Write this down:

• Under $5,000 per year: IT Steering can approve from shared budget
• $5,000-$25,000: IT Steering votes (needs consensus or majority, your choice), funded from shared budget if approved
• Over $25,000: Board decides, and requesting library funds it themselves OR everyone votes to fund it together

This prevents frivolous requests and keeps the consortium from becoming a custom development shop.

Decision 5: Exit Policy (Write It Before Anyone Leaves)

Your member agreement needs to say:

• Standard commitment: 3 years minimum
• Exit after year 3: 50% of remaining contract penalty + notice period
• Exit before year 3: 75-100% of remaining contract penalty
• Exiting member pays: Data migration costs + 50% of transition support
• Timeline: Minimum 6 months notice, may be longer depending on contract

This protects remaining members and gives exiting members a clear picture of what they owe.

Decision 6: SLAs (Write Them, Then Track Them)

Your vendor needs to know what you expect. Put this in your contract:

• System uptime: 99.5% monthly (roughly 3.6 hours unplanned downtime allowed)
• Critical support: 4-hour initial response, updated every 2 hours until resolved
• Upgrade notice: 90 days for major versions
• What happens if you miss: Automatic credit to members (1% per month, your choice)

Then actually track this. Monthly. Show the metrics to the Board. Hold the vendor accountable.

Decision 7: Conflict Resolution Process (Who Decides When People Disagree?)

Write this flowchart:

1. Conflict identified (two libraries want different configurations)
2. IT Steering presents options and costs
3. IT Steering votes or seeks consensus
4. If consensus fails: escalate to Board
5. Board votes (majority rule) and documents dissent
6. Decision made. Implementation happens. No re-litigating.

This is how you prevent fights from festering.

What You Actually Do This Week

Not next month. This week.

1. Monday: Gather your Board. Tell them you're writing governance. Ask for 2 hours of their time to align on voting structure and costs.
2. Tuesday: Draft the decision authority matrix. Email it to Board and IT Steering for feedback.
3. Wednesday: Build the cost model spreadsheet. Show three scenarios (your current setup, plus two alternatives).
4. Thursday: Draft the governance charter outline (voting rules, cost model, SLAs, exit policy). Five pages. Not a novel.
5. Friday: Board meeting (30 minutes). Approve the outline. Assign someone to write the full charter (should take 2-3 weeks).

Once it\'s written, vote on it. Then make it binding. No "we\'ll revisit this later." Governance that nobody enforces is just a document.

References and Further Reading

• Evergreen Community. (2025). "Multi-Organization Implementation Guide." Available at evergreen-ils.org. Detailed technical documentation for consortial Evergreen deployments.

This article draws on the author's professional experience in library consortium governance. Where specific claims reference external sources, links are provided inline.

See Also:

• Consortium Power Plays: Negotiating as a Bloc — Vendor leverage and contract strategy
• Contract Red Flags Checklist — Contract language and red flags
• Case Studies — Real examples of successful governance implementations
• The Beginning of the End: Why Library Consortia Must Go Open Source — Strategic context and alternatives