\documentclass[a4paper,11pt]{article}
\usepackage{ulem}
\usepackage{a4wide}
\usepackage[dvipsnames,svgnames]{xcolor}
\usepackage[pdftex]{graphicx}

\usepackage{hyperref}
% commands generated by html2latex

\begin{document}

Projects are supposed to be time-limited and therefore come to an end. Many digital humanities projects, however, seem designed to never end. Part of the problem is that it isn't clear what ending a project is. \hypertarget{Reasons_to_End_Projects}{}

\subsection{Reasons to End Projects}

Here are some reasons to think about ending projects:
\begin{itemize}
\item  Even if you hope the project will continue, it is useful to think about wrapping up a phase or version of the project. That gives you an opportunity to pause, reflect, document the version, and deposit it.
\item  It is important to have moments when you celebrate what has been achieved in a project. Even if the project will continue, it is useful to mark an anniversary in the project.
\item  It is important to communicate what has been achieved to stakeholders at regular points. That means identifying points in the timeline of a larger project when you have achieved something coherent that can be communicated. For that matter celebrating a finished version and depositing it are forms of communication.
\item  Granting councils like SSHRC typically expect projects they fund to come to an end and be reported. They also have policies about depositing data developed during funded projects. See \href{http://www.sshrc-crsh.gc.ca/funding-financement/policies-politiques/edata-donnees_electroniques-eng.aspx}{http://www.sshrc-crsh.gc.ca/funding-financement/policies-politiques/edata-donnees\_electroniques-eng.aspx}
\end{itemize}\hypertarget{Issues_in_Ending_Projects}{}

\subsection{Issues in Ending Projects}
\begin{itemize}
\item  You need to decide when something is done and what done means early in a project, not in the rush of a messy end. At the same time, you should be willing to redefine the when and what as the project evolves.
\item  Deciding what to do when a project (or phase) is done is not simple. At the very least you should document and deposit the content in such a way that it can be discovered and reused.
\item  It is better to deposit something at some point than to perpetually put it off. Beware of developing the wrapping up process into such an ambitious project that you never finish it.
\item  Think of your project in phases or versions. Imagine what version 1 is and aim for that. Then finish version 1 before moving on to version 2.
\item  It takes significant time and effort to deposit a project. It is not a matter of spending a weekend uploading the XML at hand to a repository.
\item  That which you decide to finish and deposit will change as you depositing it. Be prepared for a long deposit process that will have to deal with a moving target.
\item  For grant-funded projects you should in principle budget and plan a deposit at the end of the funding. This is not, however, practical as most projects are not really finished until the very last moment of the grant, if that. At the end of a grant there is usually a rush to finish what you said you would do and therefore no time to step back, consider what was done, and carefully document and deposit the project. Grant funders should consider small post award deposit funding grants that large projects can apply for once the project has reported the project over, the digital work done and budget spent.
\item  Projects are often associated with individuals who change institutions. Digital humanists and institutions should therefore be willing to take ongoing responsibility even when people move away from institutions where they developed projects. At the very least institutions should be prepared to help document and deposit projects as they were at that institution and individuals should be prepared to finish off projects and deposit them even though they may have gone to different jobs.