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