Whenever I leave a job, I worry about projects I led or supported. When you put months or years into something you feel passionately about, it can start to feel like your baby. When you leave for a new position, you have to put that baby’s future into someone else’s hands. Developing a sense of detachment can be difficult.
It is easier to leave a project behind when you know there are people equipped and committed to supporting it. I’ve heard horror stories about libraries that have not been able to maintain technologies—from blogs and Facebook pages to mission-critical, homegrown software—after an employee left.
It’s challenging to think of leaving as part of project planning, but here are some questions to consider that will make your project more likely to survive your exit.
Is this a strategic focus of the library or a pet project? As you’re getting started with planning, consider whether the project is meeting a widely recognized need. How well does it align with the library’s strategic plan or goals? Make sure that you are involving and seeking feedback from your colleagues as you work on the project so that they feel invested in its success.
How easy is the technology to maintain? This seems like it would be the most obvious consideration when planning a technology project, but I’ve heard about so many libraries that have been left with something that they have no staff capacity to maintain.
If you’re choosing subscription-based software, make sure your funding is coming from a stable source. If you’re selecting open source software, make sure it’s a vibrant project with a lot of contributors who continually improve upon the codebase. At my library, we recently moved to LibGuides because the university that developed our open source research guide software had abandoned it.
If the software is homegrown, make sure it is developed based on commonly used standards and programming languages.
Maybe you are amazingly skilled in an unconventional programming language, but how likely is it that the person who replaces you will be too? You can’t assume your replacement will have the same skill set unless it is written into the job requirements.
Who will maintain it when you’re gone? Many of us work in specialized positions in our libraries, but there shouldn’t be an important project that only one individual can keep going. Library job searches take time, and someone needs to be able to quickly pick up the baton. At my last job, I was part of an instructional design team that worked closely together on every project, so I knew that there were others who could take over my work. Cross-training and team-based structures are so critical to ensuring continuity.
How thorough is your documentation? I’ve heard from numerous libraries that were left with social media accounts that they had no control over because an employee left without sharing the login information. Documentation should be kept from the start about how to access, use, and maintain these accounts. If you’re building an application, it’s good practice to develop documentation as you go. You might think everything is intuitive, but that may not be the case for someone brand new to it.
How will you assess it? Nothing is forever, and some projects are not meant to stand the test of time. The needs of our patrons and available technologies are constantly changing, and we must be able to show that our projects are having the needed return on investment. To do this, you should plan from the start for how you will assess the project.
We can’t predict the future, but we can plan for it.