Repository service planning involves taking the necessary steps to ensure the long-term sustainability and stability of the repository. Service planning may address concerns that are both functional and personnel-related, including such tasks as: staffing and resource assessment, role identification, contract renewal and negotiation, and exit planning.
Contents in section
- Needs Assessment
- Staffing and Resource Planning
- Role Identification
- Succession Planning
- Contract Negotiation and Renewal
- Exit Planning
Whether you are starting a repository service from scratch or considering making upgrades to an existing repository service, it is vital to assess the needs of your community. Without knowing what needs the repository service will fill, it will be nearly impossible to design a service model that will prove effective.
If you are already providing repository services, having a clear sense of why you are providing them and how well they are meeting your current goals and expectations may provide insight and direction for resource planning and staffing, future development, and potentially also a sense of the skills and competencies that you need to hire for in the future.
In either case, it is important to look at the existing repository landscape at your organization, and determine whether an independent infrastructure will best fit the service needs of your community, or whether an existing system will be better suited.
The steps of this needs assessment can be found below; we also recommend working through the Repository Scope section of this handbook as part of that analysis. Semi-structured stakeholder interviews may be a good way to collect some of this information.
- Complete the Repository Scope section of this handbook.
- Evaluate whether your audience and content can be served by an existing repository.
- Work with stakeholders to identify functionalities that you would wish for in your ideal repository service.
- Consult with your Preservation Strategist to ensure long-term preservation management. (For more detail on this bullet point, see the section on Preservation.)
- If you're providing repository services already, document what works well with your current repository service and what could work better.
- Perform a needs assessment to determine whether or not your current collection model is serving the needs of your constituents.
- Identify stakeholders that you would like to reach but have not been successful in doing so.
- If you currently have insufficient staffing and resources to complete your work to the highest possible standard, describe additional staffing and resource needs.
- Document both your process and your results. Return to top
Whether you are setting up an entirely new repository, migrating extant content to a new platform, or undergoing efforts to scale up ingest of content within your current platform, it is important to have at least a rudimentary tool or checklist to generate an estimate of your staffing and resource needs.
Given the variances in repository platforms (open-source vs. proprietary), content types, and collection and staffing models, however, it is difficult to design a one-size-fits-all checklist. Instead, here are a few action items that you might consider as you generate a rough estimate of effort (in a 12 month time frame) and also a few actions to consider if you plan to scale up ingest. It is highly recommended that you also consult the section on Defining repository scope, which goes into much greater detail regarding the action items below.
- For purposes of comparison/benchmarking, identify similar efforts that may have taken place within other (Library) units.
- Identify ingest type (e.g. self-deposit, mediated deposit, batches, or individual file uploads). See Defining repository scope section, specifically the "Active and passive content collection" portion.
- Document the number, type, and size of files you or external partners uploaded to your repository in the past 12 months. Extrapolate growth projection of annual additional records and file size.
- Calculate roughly how many hours per week were dedicated to this effort and by whom, including staff assistance from other units. Extrapolate growth projection of annual FTE.
- Consider whether you need to digitize the collection material. See Curation section for more details.
Review new or desirable functionalities gathered from stakeholders during your Needs Assessment, and consider whether these new functionalities will require in-house development. If so, consult with Library IT.
A critical step in planning for a successful and sustainable repository service is developing a shared understanding of the core roles and responsibilities involved in managing your repository service. A clear understanding of who is accountable for which actions (and when) eliminates ambiguity and promotes a sense of shared as well as individual responsibility. It should be noted that roles and responsibilities may differ slightly depending on your platform, collection model, and type of content. Additionally, the degree to which these roles are consolidated or singular may depend on the scale and collection model of the repository. It is also worth noting that many of these roles can and should be filled by experts within the library, rather than in your department and team.
The roles used in this handbook are described in the Introduction. As noted there, once the identities of the Service Sponsor and Repository Service Owner have been determined, they should work together to identify individuals who will fulfill the other roles.
Succession planning, or the preparation for the departure of key personnel with institutional memory, is a multifaceted process critical to the long-term success and sustainability of a repository service. At a minimum, succession planning involves the capture of key institutional knowledge from the departing staff person as well as the identification and grooming of a suitable successor. A more programmatic approach to succession planning, however, may also include developing a clear understanding of how the repository service fits into the broader repository landscape and strategic goals of the institution.
As you prepare for a major change in staffing, then, it may be an opportune time to pause and reflect on the role of your repository service in the context of broader institutional changes and priorities. It might be useful for repository managers to consider the following guiding questions:
- Where have we been?
- Where are we now?
- Where are we going?
Where have we been? Or, what institutional knowledge must be captured as longtime staff depart their roles?
Knowledge management, or the capturing and documentation of institutional knowledge, is a core aspect of succession planning. Here are a few action items to consider as you begin a retrospective look at your repository service and interact with departing staff persons.
- Document the initial impetus for starting the repository service, identifying the initial need that it fulfilled and the intended audience.
- Identify the initial collection focus and whether that focus has changed over time.
- Locate extant workflows, standards, policies, contracts, or other documentation maintained by previous Repository Mangers through time. These may or may not be written down.
- Identify the historical collection model (i.e. active or passive), and whether this has changed over time.
- Identify access credentials that must be passed to future repository managers.
- Document intellectual stewardship of individual collections and plan to (re)assign stewardship as needed through retirements and institutional change. (For more detail on this action item, see the Curation and Rights Management sections.)
Where are we now?
- Consult the sub-section on Needs Assessment of the Service Planning section.
- Consult the sub-section on Staffing and Resource Planning of the Service Planning section.
- Consult the Assessment section.
Where are we going? Or, will the repository continue and, if so, how?
- Consult with the Service Sponsor to determine whether or not the repository will continue. If not, skip to Exit Planning. If so, complete action items below.
- Revisit the job ad or position description for the new Repository Manager. Update the required and preferred skills as needed, accounting for changes in technologies, core competencies, and/or workload.
- Identify aspirational skills or competencies to consider for the successful candidate's growth and development. In other words, make allowances for robust professional development opportunities.
- Identify areas for potential growth and expansion (e.g. new audience(s), expanded content types, etc.) See the sub-section on Staffing and Resource Planning of the Service Planning section.
- If you do not already have one, consider writing an outreach and/or communication plan in order to maintain and build partnerships with key stakeholders. See the Outreach section.
If you're using licensed software for your repository, contract negotiation and renewal will be a key part of ensuring the provision of services. Initial negotiations should involve the Service Sponsor and Repository Service Owner, in consultation with University Counsel and the Copyright Office. Other roles may be consulted as needed, especially the Metadata, Preservation, Rights Management, and UI/UX Strategists.
A helpful way to frame this negotiation is, What roles from the list above will be filled by the software licensor? Most commonly, the licensor will be responsible for the tasks and duties associated with the role of Repository Service Manager, but if this is not the case, those duties will need to be assigned internally and the internal Repository Service Manager will need to able to perform them within the licensed software. In any case, such an arrangement should be reflected in the contract to the satisfaction of all parties. The same is true if there are any other roles that the licensor will be called on to fill.
It is also vital to take into account the policies noted above: can they be fulfilled under the contract as written? For this reason alone, it's a good idea to have those policies in writing before negotiations!
The Service Sponsor and University Counsel will likely have their own concerns about the contract, as well. Only when all of these concerns have been answered should the contract be signed.
All of these issues should be revisited when the time to renew the contract comes around, to see how well the service has fulfilled its requirements to date. Renewals afford us the opportunity to evaluate the system as executed, and thus make necessary improvements. It's a good idea to expand the people involved in the conversation to include other roles, who may have important insights into what improvements can be made, or whether the contract should be renewed at all.
Note that while this section largely deals with licensed repository software, the principles involved can be applied to homegrown or internally managed open source software as well. It's common in such cases that the roles above will be filled by colleagues from different departments, and internal MOUs can help insure sustainable service, even through reorganizations and staff changes.
If working with an external vendor:
- Work with stakeholders above to ensure that the language of the contract meets all repository needs.
- Get sign-off from Service Sponsor, Copyright Office, Budget office, and University Counsel as appropriate for your institution.
- Distribute copies of signed contract to all relevant stakeholders.
- Review contract yearly to see if changes are necessary.
If working with an internal unit:
- Compose a written agreement detailing each unit's responsibilities and obligations.
- Work with stakeholders above to ensure that the language of the agreement meets all repository needs.
- Get sign-off from Service Sponsor, Copyright Office, Budget office, and University Counsel, as well as the leadership of the unit you're working with.
- Distribute copies of signed agreement to all relevant stakeholders.
- Review agreement yearly to see if changes are necessary. Return to top
Exit planning is the preparation to discontinue a repository service and, like succession planning, is not something which should be postponed until circumstances demand its implementation.
It includes the logistical and infrastructural details of shutting down a repository service and migrating historical content from one repository platform to another. While the details of the new repository platform are almost certainly unknowns in the early part of the process, steps can and should be taken in preparation of the inevitable transition. If your repository is built on a licensed platform, succession planning may also include negotiating contract termination: see Contract Negotiation and Renewal above, and consider the elements of your contract in the context of how the relationship it describes will end.
Such preparation is necessary because, while an exit plan may be deployed after a pre-determined trigger (e.g. depletion of absolute funds or foreseen & agreed upon contract terminus), in most situations it will be difficult or impossible to predict when an exit plan will need to be deployed. Sudden mergers and acquisitions among licensed platforms, lack of responsiveness or support from open-source development community, lack of resources or expertise to support in-house development of local open-source installation, or a movement from a single-institution to a shared or multi-institution solution may all put you in a position such that enacting your exit plan is necessary. Better to have it prepared before that moment.
If and when you find yourself in the position of discontinuing a repository service and migrating historical content to a new platform, we recommend that you read through the entirety of this handbook to cover all bases. Much of what has been covered will need to be revisited, if not established for the first time.
At minimum, complete the action items below:
If Exit Planning from Licensed Platform
Exit planning from a licensed platform is more complicated than exit planning from a local, open-source platform for 2 main reasons: (1) data restitution and (2) contract termination.
- Familiarize yourself with the conditions under which a contract can be terminated, with especial notice of the timeframe surrounding notification of parties and the end of services.
- Consult with University Counsel and Service Sponsors to confirm adherence to your contract.
- Ensure complete restitution of data, including both the content itself as well as descriptive metadata.
- Ensure that restituted data is useful (i.e. usable and interoperable).
- Once all data has been successfully migrated (see below), ensure that the original provider destroys every copy of the data on their data centers.
If Exit Planning from a Non-Licensed Platform
While leaving a non-licensed platform should remove the concern around contract termination, other issues remain.
- Ensure that all data in the current system is useful -- usable and interoperable -- in preparation for migration (see below).
- Work with current service providers within your unit to establish procedures for getting that data, and deleting it post-migrations.
For All Exit Planning
- Document institutional knowledge. See the sub-section on Succession Planning, specifically "Where have we been?"
- Identify the new infrastructure by which repository services -- including access to the extant content -- will be provided. This will involve working through this entire section of the handbook, and likely others, completely from scratch.
- Work with Repository Service Owner, Repository Service Manager, Metadata Strategist, Preservation Strategist, and other roles as needed to create a migration plan for extant content.
- Consult with sponsors, content creators, and other stakeholders regarding the change of infrastructure, any differences to the level of service that they may experience, as well as any interruption of service during migration.
- Establish training time for any team members working with the new software.
- Document the entire process; you will need to do this again.