Simple as it sounds, one thing I’ve learnt in my career as a web designer/developer and project manager is that I always need to think before I act. All too often a project will start being built before a project proposal or definition is set. When it comes to building any type of website that has business intentions, there really are no shortcuts and progress will need to be quick and constructive.

Now don’t expect to pick up a book and follow a methodology word-by-word. Web site development mythologies are relatively new and the project manager will need to adapt, adopt and invent their own way in relation to the projects environment and client. All sounds easy when a methodology is read. But, below are examples of some things that typically go wrong:

• Requirements change, this can be due to client changing their mind or the actual business requirements changes.
• The requirements have been interpreted differently between the client and the development team
• There was a simple underestimation of work required to complete the project
• Client lost interest or had to shift focus onto something else.

Regardless of the reason, the end result was the same: projects that go over-time go over-budget unless the client is willing to pay more. Each late project will also impact team moral and upcoming projects, chance of having these problems can be reduced by executing actions in the following order:

• Initiation
• Requirement Analysis
• Content development
• Design
• Development
• Launch
• Post-launch

Initiation

Before starting a journey you must not only know your destination, but also how you are getting there. This is where the project is defined, the key tool here is a creative brief. It is the document to go back to if you have questions about the goals or requirements of the project

Once a creative brief of the project is signed off and agreed the project can progress into the requirements analysis stage.

Requirements Analysis

Requirements analysis for a website? Bah, go ahead and laugh! So many web projects in the real world skip this stage only for it to come back and bite them in the behind, I’ve been bitten enough times to say that this stage is not worth skipping anymore.

Client: Can we make the site look a little more web 2.0?

You: I’ll add a shiney button

Client: OK!

Would you build a house on sand only to keep filling up every crack would form? No, that’s the same reason why I would not suggest doing the same when building a site by skipping the requirements stage. There is more of a chance of target market analysis applied to copywriting and SEO than there are web site requirements used for guidelines, user and functional testing and making sure business objectives have been met. It’s difficult to convert traffic to sales when even you haven’t figured what a web site is expected to do.

On the other hand, writing documentation , test plans, test cases and tons of hours functional testing is slow process of thinking, planning and visualizing details before any code or design starts adding up. Website projects don’t usually budget enough time for complete and comprehensive testing. You must be able to test a site quickly and constructively in order to provide value to the project.

First: define the business requirements:

I usually start with a “Parent” requirement, “What is the objective of the this website?”. An example might be an Indoor rock climbing wall ecommerce site that wants to promote the wall and activities around it.

Our Parent Business Requirements are:

BR1. Provide information about the company

BR2. Sell climbing merchandise

BR3. Promote Climbing
Other possible business requirements might be “upcoming events”, “provide services”, “get sales leads” and “To inform on [insert topic]”.

Next, place details under each BR (Business Requirement).

BR1. Provide information on our company BR1.0 About the Wall

BR1.0.1 Provide staff bios

BR1.0.2 Provide information on other services used

BR1.0.2.1 Provide information on Gym

BR1.0.2.2 Provide information on Electronic Lockers

BR1.1 Blog

BR1.3 [insert and list the ways you plan to provide information; i.e. testimonials, blog comments, forums, product reviews, press releases, contact page etc.]

This encourages everyone involved in the project to step up and ask questions regarding goals and objectives, as well as determining how to achieve these goals. Once I determine that I need a panoramic 360 degree shot of the climbing wall, someone else can take the lead on researching and recording the requirements for it. Should the panoramic 360 degree shot be Flash or Javascript based? Should it be built in-house? Each of these questions may evolve themselves into a potential system requirement.

BR1. Sell climbing merchandise

BR1.0 Add shopping cart

BR1.1 Marketing (SEO)

BR1.2 [i.e. user generated content, social media, weekly sales, coupons, online accounts, etc.]

Other Types of Requirements

Other requirements might be:

User Interface Requirements (UIR) – I usually use a wireframe to illustrate these pages.

Functional Requirements (FR) – This is where servers, databases, programming language and error message procedures are made

Search Engine Requirements (SER) – There are endless resources online

Search Engine Marketing

Organic Search Engine Optimization

Social Media

Usability Requirement – http://en.wikipedia.org/wiki/Pas_78

Content Development

Is it really possible to demand all content before the site is designed? In my experience it’s not, at least not when I did not have an established working relationship with the client. That is why I usually run the content development and design stages in parallel. When a contract is signed before the client handed over the majority of the content I was eaten up by administration costs trying to fix the changes that later incurred (which should typically take up about 10% of the workflow if managed right).

Content development is probably the riskiest stage, mainly because content resides on the client side. I usually make sure there is a clause in the contract protecting me from delays.

Design

I like to divide the design stage into two sections; Site Information and Interface Design. At this stage it is encouraged to make any changes necessary and get them approved by the client, any changes made after this stage could be time consuming.

Information Architecture

Information Architecture can be considered as the “Blueprint” for the information structure of a website. It defines the website’s page hierarchy, structure and navigation. I usually create a lo-fi prototype in illustrator to illustrate this stage. Read more about Web Information Architecture Deliverables and Diagrams http://www.fatpurple.com/2010/03/01/web-information-architecture-deliverables-and-diagrams/

Visual Design

Once the Information Architecture is approved it is possible to progress to the visual design using the wireframes defined the Requirements Analysis stage. It’s really important to get the design approved before starting the next stage. It’s much easier to do rework in Photoshop than in HTML, so it really saves time to make sure that the development stage just involves building out the site and no designing ‘on-the-fly’.

Development

This stage is about building the generic site template and the detail pages. At this stage I prefer to make template quality checks before propagating the code through the whole site. It’s usual to expect some design changes, some times these can cause delays.

And of course, the template and site in general would need to go through a content quality assurance check.

Launch

In practice, this stage is very simple. I usually run down to the closest bottle shop and get some of their best Champaign. I usually avoid launching on Fridays because I cherish my weekends.

Post Launch

Once the site is live, I set up a maintenance plan with the client. I’ll then do an internal project performance summery among our team, and later on with the client.

It’s really important to do these, so that you can learn from things that went well and things that didn’t.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.