Website relaunch projects don’t have to take a year (or more). In fact, when executed properly by skilled teams, you can rapidly deploy (or redeploy) a new website. Here’s how I recently relaunched the website for my school, Ultimate Medical Academy:

• PREP PHASE (12 weeks prior to project start; or launch minus 24 weeks)
  My web team (consisting of two employees) tested out some concepts for the new website by piloting the technology and styles on smaller projects ahead of time. We knew we wanted to push the envelope quite a bit with the school’s site, but we didn’t want the site to be the first time we tried all the new bells and whistles. Like any good web team, we have and actively manage a project backlog or road map that goes out about a year. This helps us understand what’s ahead and manage our time effectively. It also enables us to pilot some new techniques ahead of time. So, beginning about six months earlier, we had two very small websites to build for other projects at UMA. In each of those builds, we tried a few new things. Some worked, while other ideas didn’t pan out as we had expected. These sites served as a proving ground for new ideas.
• RESEARCH PHASE (week 1)
  First, we formed a steering committee that included the following members of the marketing team: web manager, web developer, copywriter, brand director, creative manager, search marketer, and me (the VP). That’s it. This group would make all the decisions, with the VP (me), holding veto power and general oversight of scope. The web manager would be the project manager and oversee development and the day-to-day project plan. Next, we asked each member of the steering committee to spend a couple hours looking at and documenting sites they felt were “great.” It didn’t matter what your definition of great was; just that you came back the next day with a good list and could present it to the team. More on that in a moment. The other task we completed early on in the first week was to discuss the results of a brand perception study we had completed months earlier which helped us understand what our customers really wanted out of their experiences. During this phase we met pretty much daily to discuss all the features and aspects we wanted to include in the site. We reviewed everyone’s wish list, sample sites from their research, competitor sites, and so on. The end results was a ranked list of features into a couple of buckets: things our site must do at the launch, and things we wanted the site to do eventually. While we knew that a success project needed to have some elasticity to accommodate unforeseen needs along the way, it was also important that we minimize scope creep to hit the 12 week goal. At this point in the project we did not worry about “how” to do something, just whether we wanted to do it. Later, during the development process, we would tackle how to address items that were excessive in development time and light on ROI. The goal was to come out of the week with a solid list of features. Additionally, during the first week (and carrying into the 2nd week), we identified every major department at our school (about 10) and met with each stakeholder group’s leadership for about 60-90 minutes. During these meetings we explained the project’s goals, set expectations, and solicited feedback/input into the site. The questions we asked were fairly basic:
  • Does the current site meet your needs?
  • Do you use the current site? If no, why not?
  • What would you want out of a new site?
  • What other sites do you like and why?
  • Who can we work with on your team to help update your section’s content/copy?
• DEVELOPMENT & DESIGN (weeks 2-12)
  Now the sprint begins. We kicked off three separate initiatives at once because we knew that if we ran the three parts of the project in serial order, we wouldn’t hit the 12 week goal.
  • Our copywriter began rewriting what would become nearly 200 pages of copy
  • Our designer began mocking up the different templates for various site sections
  • Our developers started work on the templates and sandbox config by having the three teams work in concert, we had to communicate daily to ensure pieces fit together, especially with how copy was to be produced. For example, our copywriter had to work with the other two teams on headlines to ensure there was enough space for various copy elements incorporated into the template designs.The designer had to work closely with the developers to ensure that his designs could be easily reproduced in the code.As the VP of marketing, I had to ensure that project requests outside of the web reboot were minimized in order for the teams to be able to focus primarily on the website project. We set aside 20% of our week (about one day) for other projects, but ultimately were able to reduce that a bit further. We did have to supplement our 12-week schedule with a few late evenings a couple weekends, but nothing too dramatic. We wanted to use the extra time mid-project rather than wait until the end and scramble. This gave us a much more predictable finish date, as we did our “long hours” mid-project and then glided in. Though, I don’t want to underscore how close of a finish it was. But more on that later.
• COMPLIANCE & REVIEW (weeks 4-12)
  The majority of public-facing content marketing produces is reviewed by an independent team to ensure that what we are saying is legal and compliant with a score of very specific regulatory requirements governing advertising and communications within the post-secondary education space. This means that everything we write needs to be reviewed. To ensure the compliance team was up to the task, our steering committee met with their team early on to set expectations. We shared the site concept to generate excitement and provide context. We also checked in regularly and developed a good system for sharing feedback, collaborating and obtaining sign-off efficiently. The web developers used draft copy for development, with little formatting or editing, as much of the content would have to be replaced. In other areas, they simply used lorem ipsum types of placeholders, since we knew the copy was going to change during the review. I also reviewed all the copy to ensure the messaging was consistent with my objectives for the new site. This meant that I had to provide a very fast turnaround on the nearly 200 pages of copy; so scheduling the requisite amount of time and attention to this project was key.
• WEEKLY COLLABORATION (weeks 1-12)
  Early on in the project, the steering committee met almost daily. As week three approached, meetings were scaled back to 2-3 times per week. The meetings were used to:
  • Review progress
  • Allow team members to ask questions about features/specs
  • Address issues in real-time
  • Make on the spot decisions
  • Discuss new findings and limitations
  • Review features and scope to reevaluate the two buckets (must have and nice to have)… ultimately, a few items that were found to be heavy in development time and low on ROI were pushed from must to nice. At this point, we began keeping a list of post-launch features that would go into weekly “agile sprints” where we would release new features over time.It was important to understand that we wanted to launch a core website in 12 weeks, not a site that had 100% of everything everyone wanted. So, working with the web manager, we discussed whether certain features could wait, and adjusted the project scope as necessary.
• LAUNCH PREP (weeks 9-12)
  To set expectations, the actual launch window I provided the school’s leadership was much broader than our target. This would allow me to squeeze a few more weeks of work if needed. So, when communicating out to the organization, I provided a month-long window, with emphasis on the end of the month. However, internally, we were managing to the early-to-mid part of the month.Additionally, I began speaking with members of the leadership team about the site, and even provided “sneak peaks” to a select few individuals, mainly the senior leadership team at the Academy. It was important that I provide them a brief overview of the site so they knew what to expect. I also wanted some feedback, to ensure we were not missing anything critical on the site. During these meetings and demos (about 3-4 took place), we also gauged feedback and excitement to understand where we might want to focus a little extra last minute effort.Since we had planned so well, and sought early input from each department, we found that the site delivered on everyone’s expectations (often exceeding it when it came to look and feel). A couple minor items came out of the demos and the team quickly adjusted what was necessary without losing too much steam.
• QA / TESTING (weeks 10-11)
  While testing was on-going throughout the project, we expanded the testing efforts around week 10 by bringing in a couple of additional team members for a few hours to help test on various devices (tablet, iOS, Android, IE, Chrome, etc…) This helped us find as many issues as possible in the shortest amount of time. Issues were funneled directly back to the development team and tracked accordingly. The copywriter reviewed all copy once again; and I personally tested a wide variety of devices and stepped through the majority of the site.
• GO/NO-GO (week 11)
  With about one week remaining in our sprint, we had a go/no-go meeting with the steering committee to understand what was still remaining on the project list and why so we could work through those last roadblocks efficiently.
• THE LAUNCH (week 12)
  I opted for a soft launch on a Wednesday. This meant that we would coordinate with the information technology team that controls the DNS settings and make the switch in the afternoon after one final go/no-go call between myself and the web manager. Once the switch of the DNS was made, the QA team did another full walk through of the site across their devices and platforms. This revealed a few last minute items that needed to be addressed. Believe it or not, our old site was not heavily used by staff or students (mainly only prospective students), primarily because it was simple and didn’t include a lot of information. So we knew we could do a launch without communicating it widely to everyone at the academy. And, those few extra days of being live and testing; and collecting feedback from the few people that new the site was live, would be extremely valuable. The good news is that there were no major issues. That following Monday, we did the full launch which included an email to all staff, an announcement to our students through the online student portal, posters throughout the building, and information on the staff intranet. We also created a scavenger hunt, with five questions… Staff had to find the URLs for specific items, such as “what page features a picture of an employee dressed as a Rubik’s Cube?” Anyone who answered the questions correctly got a souvenir school pennant and was entered into a raffle for a school sweatshirt. This contest, along with the email announcement helped drive awareness about the site and all the new features.

So what worked and what didn’t?

Overall, the prep and collaboration really proved to be the cornerstone of our success. I cannot underscore how important these processes were. It was equally important to have full buy-in from senior leadership and to protect the team from competing priorities/projects.

Of course the team would have liked more time. That would have yielded minimal differences though. Of course more time would allow for more scope, but we’re releasing new features weekly. It was important to launch a new site quickly with a solid foundation, and then focus on additional features. So more time would not necessarily have yielded a higher quality site – just more features. It may have reduced stress a bit, or eliminated a few of the extra days we spent across a couple late nights and weekends. But I have a feeling we would have used those late nights and weekends even if we had more time.

I owe the success of this project to the steering team (especially John Klingler, the project manager for this endeavor.) It was a lean team, that continues to meet to this day looking at new features and specs to make the site even better. They did the hard work and were successful; I’ll bask in the moment of accomplishing a great feat and then jump into the next project “business as usual.”