Change Documentation: Keeping Track of What’s Different

In preparing a request for proposals (RFP) and a project scope, it may seem as though half the work of developing a new website is creating documents. These documents are essential in ensuring the project stays on time, on scope, and on budget.

Documentation does not end once your site is launched. It is essential that you maintain documentation of changes and updates. This mostly applies to the structure and design of the site itself, as well as any features, applications and plug-ins that may be installed after launch.

Change and update documentation becomes critical when there is a problem with your site, or when it’s time for more design and development work. You should be able to show what is different from the original scope to facilitate easier discovery and diagnosis of problems, as well as demonstrating needs for new features.

This documentation can be as simple as maintaining an open web updates project within your project management system. When any significant change or update is made, the person responsible should document it in the project. That way they are stored and available for all to see should they be needed.

Sites using a content management system (CMS) will usually feature version control, meaning that previous iterations of content are saved in the CMS. If changes are made to the content that are wrong or problematic, rather than recreating previous work you can “roll back” that page to the previous version. Therefore change documentation for content itself isn’t really necessary.