We talk a lot about what we do before and during projects: how research, design, and planning (RDP) activities can shape a well-informed project plan, how we can manage a project’s scope to meet a budget, and how we can make delivery to production work for our clients. But what about when that’s all done? What’s important when a project is over? Below are a few tasks that should be considered as a project wraps up.
### Document anything the team should address the next time work is done on the app.
The end of a project is a good time to look into the future and help yourself with planning. Teams continually balance work that needs to be done now vs. work that probably should be done at some point but doesn’t need to happen right this minute. Documenting those future needs is a great way to ensure that they get the attention they deserve in the future.
Things a team might want to address in the future include:
* Libraries that should be updated
* Areas of the app that could use more tests
* Code that would benefit from refactoring to improve performance or clarity
* Infrastructure or monitoring updates
* Elements of the design that have grown warts as they evolved
### Set reminders for important expiration dates.
Software frequently involves components with a limited shelf life. Some services will remind you of their expiration, but not all of them do.
Set reminders to make sure these important dates aren’t forgotten:
* SSL certificate expiration date
* Domain registration expiration date
* Apple iOS distribution certificate or developer program expiration date
* Service subscription expiration dates
* Credit card expiration dates for cards used to subscribe to important services
### Scale back or shut down services needed for active development.
Take the time to consider what you really need to have around in order to support the application. If services are easy to restart, shutting them down entirely may be an option.
Here are some services to evaluate:
* Continuous integration (we like to run our test suites on a regular basis even if active development isn’t being done to catch date-related problems, as long as it isn’t prohibitively expensive)
* Hosting for non-production environments
* Monitoring services for non-production environments
* S3 buckets holding stale test data
### Double-check that the application has adequate capacity.
During development and early production use of an application, it’s easy to get by with smaller amounts of storage and less expensive service plans. And if people are actively monitoring the application, it can be fairly easy to respond to changing needs. Depending on the application, looking forward to the next 12 or 24 months is a reasonable starting point.
Ask yourself whether the application will have:
* Enough disk space
* High enough limits on database rows
* Sufficiently robust subscriptions to other services
### Document any useful work-in-progress.
Have you left any interesting, un-released work sitting on a random branch? What is it, and why is it potentially useful?
### Clean up your branches.
The end of a project is a good time to clean up any temporary branches or old feature branches, and generally get things into a good state for the next person who works on the software.
### Ensure that “getting started” documentation is up to date.
Can a developer still follow the documentation in the project README or Wiki to bootstrap their development environment? It’s easy for this information to grow stale as libraries and tools are added to a project. Take time to revisit this process at the end of a project rather than forcing the next person who touches the project to solve a potentially frustrating puzzle.
### And more…
These were just a few items from my list—there are many more worth considering. I’d love to hear your comments about things you do at the end of a project.