How We Launched Our Web Site Redesign Project

by Robert Kraai 12/16/2011

When a client is thinking about their site, they think about the look and feel of it first. A client might have a nebulous idea of the features they want (like articles and news pages, a career page, events, blogs, maybe forums or micro blogs, etc...), but they don't really know how it's going to fit together until they see a visual representation of the page. Written descriptions seem like they might capture the idea and bring everyone to agreement, but once the visual features are laid out that agreement can disintegrate. It's not real until there is something to see. The challenge is that you need the information first before you can come up with a final picture. The functional specifications have to be there to validate the visual design, but many times the visual design has to be in place to get budget approval. We find the most successful project launches have the rough functional requirements documented, a rough site topology laid out, a WCM/Portal/Community technology choice made, and mockups of the templates done as a pre-project launch (or strategy) process. This collected information provides a basis for scope, budget, and project planning the deliverables.

Many organizations approach a web site redesign by coming up with budget figures first. They may try to provide estimates based on full color drawings of the page that make folks drool over the new potential, but leave the details of the technical implementation for later. This can lead to heading down paths that are difficult to achieve once the technical implementation and real timelines are dealt with. The hole to get trapped in is estimating a project based on the PowerPoint presentation that lacks a technical review or even an outline of the functional requirements. This is not to say that a budget can't be set in advance with the use of change control to adjusted to fit within those boundaries. Simply creating an accurate expectation for the project with proper scope and budget is difficult without some prep work, and proper attention to that prep work is money well spent saving sometimes thousands of man hours later in the game. Every project has this challenge to some degree, and I have witnessed a lot of Interactive Agencies fail miserably because they wing it and hope for the best.

This article describes how AceCP approached the prep work to get to a state where the scope and budget decisions are set in such a way that many project pitfalls may be avoided.

The first step we took was deciding that we needed something new. AceCP (and Kraai Consulting before it), has never spent real dollars on a web site. Being a Content Management services company, they (oddly) have never had a real content driven site of their own. AceCP, made the decision to proceed with a Social Media Marketing campaign, and made a commitment to building a community, but had nothing in the current site infrastructure to support it. That meant a complete redesign from the network and hardware to the content infrastructure (WCM), to the look and feel of the site. The decision was made to start from scratch.

The budget process started with a number. AceCP didn't need to start there (as I mentioned above), but having a new initiative meant lots of questions about what it might cost and whether the cost was too high to even approach the project. This number was a guesstimate that was based on previous projects of this magnitude, but not an accepted final number (and everyone understood that). The initial number was only for getting the collective stake holders to wrap their brains around the monetary commitment the project entailed. Apart from the hardware, software, services, and time commitments, the number also included thoughts towards added head count needed to manage the new marketing campaign. The budget number and time commitments were discussed with a 50% margin of error.

After the budget litmus test passed, AceCP laid out an approach to the features we wanted. We created an AceCP.com project document that described what it was we wanted to do. We started with a description of the marketing campaign, and how the new Social Community applications would fit into it. Next we laid out what kind of content we wanted on the site and how it might be organized to make things easy to find. We documented our thoughts on the community and how it would interact with our members, and how we would innovate maintaining the community to allow us to minimize cost of operation. This document became the basis for our functional requirements.

The topology of the site, or information architecture, was the next thing that we addressed. The topology is the navigation of the site, or the way pages are interrelated. This traditionally looks like the roots of a tree extending down from a Home page or several landing pages. This is a key component to how the site provides information and brings in visitors. In Visio, we laid out a hierarchy of information that the site will provide, indicating the major sections of the site and connecting them up like a traditional navigation structure. Then we stepped back from that and determined that a traditional navigation was not good enough. We want people to find pages that are related to other pages in a semantic Web 3.0 way. Semantic Web design is based on how the content of one page or site is related to another page or site rather than on hard coded links between the pages. Some people call this Semantic Navigation or Contextual navigation. We drew possible dynamic contextual links as arrows from one section to another leaving the basic traditional topology visible. This is easier to visualize than thinking of the site as a blob of interrelated nodes that it actually will become. The resulting AceCP.com document was a fairly nice set of functional requirements along with a proposed information architecture for the site and a proposed budget.

The next step was to identify the number of templates, the features, the infrastructure options, and maybe even choose a WCM. It is hard for organizational stake holders to fully buy in to a Web or Marketing solution when they can't visualize what they are getting. The ultimate users of the site must also know what they are getting. Listing out descriptions of features is not the same as drawing them or providing a prototype, however it necessary to avoid reworking the look and feel (or prototypes). There are several quick prototyping tools for getting basic template structure, but we typically rely on a simple Visio diagram of the template page. In this case, we laid out all the features of each template type from Home Page to various detail pages in Visio, adjusted them to meet our desired functions and content layout, and validated them against the functional specifications.

By this point, we had talked around the whole concept of the site, and what it would do for AceCP. This involved a lot of discussion around features and pages and information that had to happen before we could get a feel for what pages and templates needed to be created. With Since we were going the route of a WCM, we know that topology doesn't matter, and we don't need to draw out every single page. We only need to create 1 of each type of page as a template that can be applied to the nodes in the topology where that template is needed to display the content and applications.

To save time and dollars before the scope and budgets are set, we started this with a mockup done in Visio that shows where each element goes in relation to the page. This is not the pretty and flashy ending look and feel that you see from a graphic artist. This is a black and white line drawing with balloon comments showing what goes onto the template, and how the resulting page is arranged. A User Experience expert has worked through all the functional discussions and the vision that the stake holds have for the result, and lays it all out for discussion. Changes to this are simple and quick, and mostly done live during meetings until the result is agreed upon. The resulting set of diagrams goes into the functional requirements, and now we have a good picture of the scope off what we are building.

The final piece of budgetary concern is the choice of a Web Content Management system (WCM) and any other software and hardware needed to support the project. AceCP already had several choices of WCM in mind when the project was conceived. However, most organizations may not have that decision in hand until the options have been reviewed. This review process can take days or months, depending on how thorough the reviews need to be. Ironically, it is just this phase that we hope to support with the new community in providing deep dive reviews and comparisons. Since that information still resides in our brains and not on our site, we had relied on discussion to drive the choice. Knowing what we were getting into with most options, we ended up quickly narrowing it down to two WCMs: The Open Source low cost high time commitment option of Alfresco/Liferay, and the Commercial upper tier low time commitment Open Text Web Experience Management. Due to our great relationship with Open Text, we ended up with the Cadillac option of Open Text Web Experience Management. This choice provides the lowest time to deployment and the most flexibility for features. It allows us to showcase a product we would recommend to anyone while building a community around the options for all WCMs. Given the deep dive we are taking into the feature pool of Social Media options, OT WEM provides the best possible ROI.

Determining a general hardware cost came down to past experience alone. We did not need to do an in-depth analysis for servers and hardware, but instead looked at prior work to determine what we needed to budget to get from our current infrastructure to a stack of hardware that would support Open Text WEM. We laid out the network diagram of virtual machines in Visio, and found that we had enough servers to handle the potential load our expected site traffic needed.

Once all the placement of content and features is done, the number and complexity of templates is agreed to, the topology is sketched out, the functional requirements are mapped, and the software and hardware choices are made, the last step we made was a final sweep through the documents to eliminate inconsistencies and make necessary clarifications for scope. The resulting set of documents is not the final design, but contains enough detail to lay out a project plan, lay out the resource allocation, and estimate the project to a fairly accurate degree.

Our approach to the project from this point forward is to iterate through deliverables that can go live and bring in small victories on the way to the final victory of meeting all the project goals. A web site is never done, so this iterative approach can also be flexible enough through change control to adjust to the current market along the way. The project plan has dates and roll outs of pieces of the site that begin to massage the existing site into the new templates, rather than waterfall the whole project for x number of months into one deliverable.

The Web does not work well with long term roll outs. Web Site Owners and Visitors alike want to see constant changes and updates to provide value to their experience that matches the available technology of the day. Delivering a cutting edge function after a year of development may mean it is no longer cutting edge. Our approach to the market is supposed to be cutting edge, but in a year everyone might be doing it (assuming it works). Thus, that observation alone means the iterative approach is a necessity to success.

This entire process I've described fits the bill for an ideal approach to any web redesign project with time and details adjusted as needed. In the ideal project, there are actually two kickoff moments: the initial meetings to start the analysis for what the project is going to do, and the kickoff of the design. The initial analysis is typically a micro project of its own that is budgeted and scoped and rolled into the overall Web Site Redesign. The complexity of the AceCP site falls in line with much bigger companies, but our approach shortens the time to delivery considerably. In our case, the time period from decision to a project plan point was roughly 2 months. The only hiccup came at the actual project kickoff, which suffered from a delay in acquiring the WCM that was outside of our control. However, the iterative changes allowed for some pieces to be folded into the existing site to take up the time lost waiting for a final WCM decision. We recommend this overall approach to every client and organization engaged in a web site redesign.

Tags:Web Content Management, WCM, Web Content, Project, Best Practice, AceCP Case Study