HOW TO MANAGE A WEBSITE REDESIGN

As a marketing manager, you will likely only lead large website redevelopment projects a few times in your career. But, as a website specialist, I have led many. This post contains my best advice for a non-geek leading a website project.

I have been creating websites practically since they were stone tablets, so I have launched quite a few websites for large organizations. These include:

• America's largest log home builder,
• 13 international fishing equipment brands (household names like Shakespeare Fishing and PENN Reels),
• Richland Library - the 2 time National Library of the Year winning library system with 400 employees and 400K citizen/members.

So, I have some valuable advice to give regarding launching a website, especially a really large one.

You might be wondering "does my website project really qualify as a LARGE website?" Here is how I would make that distinction: 

1. Organization size: How many people are going to feel some sort of investment in the finished product? This is a higher percentage of your company's employees than you think. The website touches just about everyone involved in your company in some form or fashion. They won't even realize they care about the website until it changes. Then they will panic and come running to your desk. So assume everyone working in or with your company is part of the organization. If that number is over 50 you are dealing with a large website.
2. Traffic: If your website gets over 100 visits a day or 3,000 visits a month you are dealing with a large website. There are a large number of people interested in your product or service. Take the time to plan your launch carefully so you don't lose your visitors after the launch.
3. Budget: If you are planning to spend over $25K on your new website it should be treated as a large project. For some companies that number sounds gigantic, and for those companies this website should definitely be treated like a large project. And, for other companies that number is pretty pedestrian. In those cases, you are most likely still dealing with a large website because of the organization size or traffic count. So this website redesign should still go through the steps in this guide.

Here is my high-level overview of the 6 steps to a large-scale website launch. ​

In the beginning there is only a vague set of ideas. Your website project may be born out of a list of technical problems that plague the existing site. Or it may be born from the need for a more robust and interactive way to reach customers. Either way, you must first decide who will lead this charge.

Project leadership
Start by deciding which person will be given ultimate decision making  authority regarding your project. This person MAY be the same as the person leading the project (like the Marketing Director or Marketing Manager), or it may be someone else (like the CMO.) It should be someone with authority and with investment in the success of the project. And it MUST be someone with the time and inclination to make the tough decisions. The person with the ultimate power regarding the new website will have to turn down a lot of ideas coming from stakeholders, other employees, and even their own boss or higher. Make sure you choose someone with a vision, and the courage say 'no' (or more diplomatically 'not right now') in order to protect that vision.

Stakeholders
Stakeholders are the parties within your organization who either need something from the site (ex: the marketing team), will be asked for something (ex: IT), or both (ex: customer service.) You will want to have each stake holding team/department appoint a representative to serve as your point of contact. You want to allow all parts of the organization to be heard during planning in order to give their requirements. After planning it is imperative that you keep your stakeholders in the loop through their representatives. Stakeholder buy-in is super important to a successful website launch, and buy-in happens through inclusion.

Requirements Gathering
You might think you know what the website needs to do, but I guarantee you there are other people and teams that have needs you haven't considered. It's only logical that teams with a completely different job than yours will have a completely different perspective.

If you can, try spending a day or more in each department. If you are able, try doing their job for a day. If this isn't a possibility, observe for a day.

Then meet with the representative. I want to make sure you hear me on this - you are meeting with the representative, but you are there to LISTEN, not talk. During requirements gathering, the job of the project lead (and I am assuming that is you) is JUST to listen. Make your stakeholders comfortable and then settle in while they open up. You want to create a list of everything this new website could possibly do for them in an ideal world. Don't worry about what is possible at this point - it isn't your job right now to decide which requirements will work. Just get it all on paper so you have a long list of requirements.

A few years ago I planned, and led the development of RichlandLibrary.com. It was a massive project that actually accomplished some new functionality that other library website teams had been attempting for years.

During requirements gathering I wrote everything on sticky notes. When someone swung by my office and said 'Hey, I was thinking it would be nice if the website did XYZ.' I wrote it on a sticky note and stuck it on the wall behind my desk. When someone mentioned a problem with the current site that needed to be solved in the new site, I wrote a sticky note. If I saw something cool on someone else's site - sticky note.

After more than a year of this I finally took the sticky notes down and grouped them. Not by stakeholder, but by functionality that the new website needed. This gave me the list of requirements.

Your long list of requirements will need to be whittled down. Ultimately, you will end up with a few groups of requirements lists based on priority. Your priority groups are:

1. Imperative (crucial to the success of the project),
2. Need (important but not a project killer),
3. Want (things that one or more stakeholders really wants), and
4. Nice-to-have (great ideas that would enhance the end product.) 

Once you know your project leads, project stakeholders, and priority requirements you have defined the project at hand. Now you can start planning the who, what, where, when for all the different pieces.
​

Now is the right time to give the project some form so we can start discussions about timeline, budget, internal resources, and external vendors.

Planning document
Start by creating a planning document. This can come in a lot of different forms, and the form that is right for you is going to depend on your style. Some people like to make sketches, while others write everything out. I like to make hand-drawn sketches and then write detailed explanations. However you document your vision, you are going to assemble it all into a PDF or presentation that can serve as the starting point for discussions with potential vendors and/or company leaders. This is the document that will help you figure out how much and how long.

By the way, if creating a planning document sounds like your perfect nightmare, don't worry. Under "Discovery Project" I will describe how you can get someone to do it for you.

There are lots of moving parts during this phase and it is the job of project leadership to bring them all together so the project can move forward.

Budget and Timeline
Ideally, you want to have a realistic budget range in mind when you start discussions with potential designers, developers, and other external resources. However, many project leaders choose to open discussions without a clear number because they need to hear from the vendors about what their planned project should cost. Usually the project leader isn't even sure how much of their scope (the list of requirements) can be included because they just have no idea what these things cost.

The best advice I can give regarding the chicken (budget)/egg (scope) conundrum is that you should have SOME idea - even if it is just a range - of what your company plans to spend. This will help vendors to quote you work that is realistically within that range. The same with timelines - if you know your project has absolutely got to launch by a certain date make sure this is stated clearly EVERYWHERE. It will help everyone move forward with the best plan.

Discovery project
I recommend doing a discovery project with your most promising vendor. It's like a trial run - it's a smaller project related to just planning that you will pay your vendor to complete. Many times you can use creation of the planning document as the discovery project. You can ask them to create your planning document using the requirements you have gathered. The finished product will contain the proposed timeline and budget, and should take a few weeks to complete. This discovery project allows your vendor to really get to know the project. And it allows you to get to know your vendor. If there are any rough areas you will know clearly and quickly.

Resource selection
The planning phase ends when you have identified your budget, timeline, and vendors or internal resources for the following:
 - design (user facing pieces like graphics, color scheme, etc.)
 - development of the backend code that will run the site
 - hosting (usually design, development, and hosting are all taken care of by the same outside vendor)
 - content (planning and creation of the words and graphics for each page of the site.)

Stakeholder transparency and communication
Make sure you share your planning document, budget, and timeline with your stakeholders. It will help them understand the cadence and scope of the project. It also allows them to see where their specific requests/requirements fall in the list of priorities. Now remember, not all stakeholders are going to LIKE their placement within the priority list. But they will at least be informed from the get-go. Keep communication open - VERY open. Use open meetings, closed meetings, even transparent task management to ensure all stakeholders can see your progress. This will save you when it is time to launch - I promise.
​

So - for the sake of making this blog post readable I am going to skip over vendor selection, which can be an entire process of its own. Let's assume you know who is going to be responsible for each piece of the project.

Wireframing and design mock-ups are the first tangible step in creation of the product. The wireframe is created by the developers to show how the information will be organized, and how the customer will move through the website. And the designers create flat graphic files showing how the website will look when it is completed.

Testing
Wireframes and design mockups can be put in front of real users in focus groups, on the street, and in various ways online to discern how they might interact with both the organization of the information, and the design. It is really smart to watch how actual people interact with your content organization and design during the beginning phases so you can catch mistakes before they become usability issues.

Approval
These documents should be reviewed by the project leader, revised as needed, then taken to the project decision makers for final approval. I want to make an important distinction here - I said that the documents go UP the chain for approval. I don't believe in sending these documents to the stakeholders before they have been approved at the highest level. 

If you take the documents to stakeholders before they are approved you will end up in a design-by-committee situation. Your stakeholders are subject matter experts in their fields, not in websites. Don't put yourself in a situation where you are trying to please everyone. You will share the documents after they have been approved in order to stay transparent. Stakeholders may point out omissions or mistakes, but the overall plan or design is not up for discussion.

Phases
This is a good time to talk about phasing. Many times stakeholders may come up with new requests or requirements after planning. It's helpful for them to understand that websites are a living breathing thing. Launch of the website is only phase one - there will be ample opportunity for new tools after the launch. So if an idea didn't make it in to the initial plan there will be another opportunity.

Development is the period of time when the website is being built, and designs are being implemented. During this time it is your job to check in with your development team regularly, plan for your launch, and to guard the scope of the project like a knight guarding a sleeping princess.

Plan for launch
Work closely with marketing and communications during this time to plan messages that will go out in advance, week-of, and after launch. Plan website testing parties with stakeholders to allow them to help with testing while getting to know the new site better.

Guarding against scope-creep
Development is the time when new little 'it's not that big of a deal, is it?' items tend to get slipped in. It throws the development/design team off their game and costs the project valuable time and money. Don't let it happen. When someone comes to you during this time with a possible addition add it to your phase two consideration list.
​

OK so here is the thing I want to say about launch - people are going to panic no matter how you do it. The bigger your organization, the more people will freak out when their old familiar website disappears. You can do presentations, and send emails, and graphics, and meet with departments all day. People will put off looking at it, or act like it doesn't matter to them, or that they don't care about the website. But, there will still be an 'oh shit' moment when they open their browser and something unfamiliar pops up.

I suggest a beta launch program. What I mean is this - two weeks before the website switch over put a link at the top of the homepage that says 'Preview our new website >' in BIG BOLD LETTERS. Allow customers and employees to actually play with and click through the new website. You can even keep a button at the bottom that allows them to give feedback.

This does a few things:
1. It allows them to get familiar with the new website.
2. It gets you extra free testing for the website because they can submit issues when they run across them.

I suggest doing this even if it means delaying launch in order to allow for this time. It prevents a lot of panic at the end.

First - when you launch a large website, you have just run a marathon. Give it a week or so, then peel yourself off the ceiling and take some time off. Go on a hike, re-familiarize yourself with your kids or your dogs, or fly to Fiji and be alone for a while. You deserve a minute.

When you do finally come back to reality be sure to thank and reward your team. Website launches in large organizations are intense and dramatic. Use this opportunity to let everyone know how valuable they are.

Then it's off to phase two. That may mean developing more tools, or it may mean continuing to publish awesome content. 

Don't forget I am here for you. I have done a lot of large website launches, and I know way more about it than I can write here. Leave your questions in the comments or schedule a call with me.

If you have a specific project you want to discuss with me fill out the Project Inquiry form >. I would love to talk to you.

One more thing! If you found this helpful please click 'Like' or 'Tweet' below. Your vote of confidence helps other marketers like you find the valuable information I write in searches and on Facebook/Twitter.