(3 Minute read)
One of the first problems that we ran into with the new website was that there were a lot more people that would have the ability to make changes live in production. We had multiple departments that were all touching the same pages and making changes without having any oversight or clear delineation of who owned what changes. Marketing, Merchandising, and IT all had people that had roles in changing and maintaining the new CMS (content management system) data. The secondary problem that we had was there was no quality control on the changes that were being published. There were several broken links and errors that would pop up and would have to be corrected later.
When we were first learning the new CMS and setting it up, there were only four people that were making changes and maintaining the new content that was being added. There was an initial agreement who handled which changes and since there was a limited number of people and we were able to keep each other in the loop. As we continued growing and adding more content, the number of people that were accessing and updating the pages went up and the communication about what was being changed went down.
As an ecommerce team we decided who should be in charge of which specific tasks. We discussed all the responsibilities that I used to be in charge of that no longer made sense now that I was transitioning to my Product Owner role, as well as additional tasks that others were doing that had not been done before. I organized all the responsibilities into a chart that clearly displayed which department was in charge of what responsibilities. This chart was not a hard line that meant that only these certain people could make these changes but rather a guideline for who needed to be consulted when these changes were made. One of the continuous problems that we ran into was people were so focused on getting their work done that there was little communication between departments to make sure that we were highlighting the right information. This chart also demonstrated that there was a lot of overlap between departments and where it might be a good idea to reach out and facilitate discussion between what were traditionally siloed departments.
The second piece of this was to roll out a new plan to ensure quality control on the changes that were being published. The way that our CMS was initially set up, there was no way to see who had published changes to production. We decided that too many typos and other errors were making their way to production, so we changed the permissions on the accounts so that everyone could make changes but the changes needed to be reviewed before being published to production. Initially, I was finding a lot of errors and sending them back to be fixed before publication, but within a few weeks the number of errors went down dramatically. This also allowed me to be able to track the changes in the web backlog so that we had a record of what was being changed so that we would be able to go back to those changes if something started to look different in the data. This way we are able to pinpoint where some of the issues or good things are happening.