One of my first projects at Mastercard was the roll-out of new Mastercard. com properties. We had to move over 80 country-specific sites off of multiple different CMS’s into one universal design, built in Adobe Experience Manager, modify the content to match the updated information architecture and image specs, ensure we were not interrupting any continuing promotion, and in the middle of this comply with the new European GDPR standard set in place to protect consumers privacy. Nothing like a trial-by-fire to welcome you to a company.
I was one of the leads for a team that included 4 project managers, and about 15 or so contracted workers both here in the US and abroad in Pune, India. We delegated the work based on two factors; location to avoid 11pm meetings as much as possible, and by size of sites. We had two IA templates; a normal site, and a skinny version. More than likely if the country was small, the business owner just wanted a smaller version of the site, not much custom content except for translations. For the larger regions with their own marketing team behind them, we either had a large template, or a start from scratch build. We were able to move a lot of the replicable, smaller builds out of the PM’s hands in order to save time.
The builds were phased out so that we could stay on a schedule for instals and launches. The first phase was copy. We allowed the business owners to translate and edit our stock copy decks (built in excel), while we enabled their access to AEM (which took a while, as any financial company will have stringent security guidelines). After that, the offshore team took the deck and moved it into the webpages. We then went into a review period with the site owners, tracking issues in our ALM application. After content approval, our team tested the sites based on about 30 qualifying features per page, and after all approvals were met, we launched.
There were two main points where we made massive improvements in the process. The first was tracking. We originally tracked issues in excel, as it allowed the business and our teams to work off the same sheet. But that can get really messy after a while, especially with the 100+ page sites.
We moved it to a submittal process. The business submitted an issue, we logged in ALM, and the business could check on the status there. Eventually, this was build out to full on dashboards, tracking burndown processes and timing of fixes.
Finally, we were able to semi-automate much of the testing. Using a few internal automation tools, we were able to analyze the raw HTML output of the site to automatically close test cases. For example, we had a rule of no more than three YouTube videos on a page for speed/load purposes, and had that test ran for every page. Using an automation script, we eliminated any pages without any YouTube links, and turned 100+ tests into maybe 5 manual checks per site.
I came in right when the roll out phase started, and from what I’ve heard, I missed rough design and development phase before that. A lot of issues and infighting since the CMS was new and the tools were being built from the ground up. My team was able to take all that work, and implemented it in a way that really helped put a good ending to the project. Like any new-tool roll out, you have to play the part of “technical therapist”, letting the users know their tools are still there and that the site is being built to help them, not cause more work. Making this process as smooth as possible helped ensure future use and updates of their web presence.