I've just been handed a web project - where do I start? (Pt. 1)

Part 1: Developing the project brief

By Mark McGrath, February 2016

Background

You'd be surprised by the number of clients I've met over the years that have said this to me. They have never managed a web development project before, have no technical expertise, have barely used a Content Management System, and their manager has given them a web development project to manage. So naturally the first question they ask themselves is, "where do I start?"

This article aims to answer that question and provide a useful roadmap for first-time managers on the client-side for a web development project. I've tried to be as detailed as I can to make this article useful for web managers, without writing a book on the subject.

What this article doesn't aim to do is make you an expert on all aspects of web project management. That is something either best left to the experts or formal training if you are keen to learn more about it.

Don't take the easy way out

Because it's so easy, it's tempting in this situation to search for web development agencies and go shopping with a bare bones brief, a draft sitemap and maybe a few design and content ideas.

But this is false economy. It will cost you more in the long run because what you are doing in effect is asking web development agencies to fill in the blanks for you here. This, of course, costs time and therefore, money, plus you may not get what you or your users need as you have ceded the decision-making process on key issues over to an agency that (at this stage) knows nothing about your organisation or your users.

A better way is to take the time to develop a thorough website development brief that includes a detailed scope, budget and timeline for the project. The more work you do here the less work there is to do for your web development agency. Yes, this is the harder road to take and will take more time and effort to complete, but it will save you time and money in the long run and will more likely deliver you a better quality website at the end of the project.

The big 3: understanding scope, budget & timeline

These are the 3 most important aspects of a project:

1. Scope: what work do you want delivered?
2. Budget: how much money have you got to deliver this work?
3. Time: when do you want this work delivered?

It's important to understand that these aspects are related and dependent upon each other.

There is no magic pudding in project management

If you change one of these, then the other two are changed. For example, if you change the scope you inevitably change the budget and timeline. Or if you change the timeline, like shortening it, then you either change the scope (eg reduce the work to be completed) or increase the budget (to get more work done in a shorter amount of time).

I still get surprised by the number of clients who think that you can continually expand the scope of a project without budget or timeline being affected. There is no magic pudding in project management; if you expand the scope it will take longer and cost more to do the work.

How these three aspects are managed will largely determine how successful your project will be. So from the start, it's important to define these three aspects as best you can.

Scope

The purpose of the project scope is to broadly define the boundaries of the project. It's not intended to define every aspect of the website development; that's the purpose of the specifications, which are best done by a professional web consultant in collaboration with yourself.

Your job should be to compose a draft project scope that broadly defines or builds a framework around the following deliverables. Be open to changing this scope though after consulting with your web development agency as they may have some good suggestions on how you could improve your project outcomes.

Research

Are you or your web development agency going to do any research to inform your decision-making on your new website? To reduce your risk of failure you should do as much as this as you can.

This is what is also known as "user needs analysis", as the purpose of this research is to discover what the needs of your users are and address these in the build of your new website. The purpose of doing this research is to:

• Identify issues with your current website.
• Get clues on how these issues would be best addressed.
• Confirm the successful aspects of your current website.
• Understand the content priorities of your users.
• Discover potential new content and services.

Unfortunately, many clients tend to see user needs analysis as a luxury item that they cut from the project scope on the basis of it being unaffordable, thinking they already have a good handle on their users want and can guess what they will want in a new website.

But the less research you use in determining the make-up of your new website means the more you will be guessing about what will and won't work for your users. More guesswork means more risk, which you should be trying to reduce. Research is your insurance policy against web project failure. So it makes sense to do as much research as you can.

If you have the motivation and time, you can do the user needs analysis and user testing yourself. Renowned website usability expert Steve Krug has written a great book that teaches you how to do this yourself, Rocket Surgery Made Easy.

Assessing available research

This would be best done in collaboration with your web development agency. But it would be useful if you could gather up what's available and familiarise yourself with any of this. What you would be looking for here is any:

• Surveys that have been done on the quality of your current website.
• Feedback from your website users.
• Analytics on website usage (eg Google Analytics reports over the last 12 months).
• Website evaluation reports that may have been previously done.

There are two types of research your web development agency could do with members of your target audiences (users):

1. Quantitative research: surveys of your users.
2. Qualitative research: focus group discussions with your users.

Quantitative research

This is best done by your web development agency.

As the name suggests, quantitative research is used to measure attributes of your users. Typical examples of this in a web development user survey about your current website would be:

• Demographics of your users (eg Age, Gender, Education, Occupation, Location).
• Their level of experience using the web.
• How often they visit.
• How desirable they find the design.
• How useful is the content.
• How easy it is to find what they want.
• The 3 best things.
• The 3 biggest frustrations.
• Suggested improvements.

If you are an organisation that already has a list of emails of your website users (for example members, supporters or users of your services), then an online survey can be a relatively easy, inexpensive and useful initiative to do.

Qualitative research

This is best done by your web development agency.

Issues that aren't easily discovered or measured are best left to be understood via qualitative research. Typically this is done by facilitating focus group discussions or one on one interviews with members of your target audiences.

For web development projects, they are best used to discover the reasons behind particular problems or issues your users may have with your current website and particular services your users would want from your new website. 

User stories

The services your users want can be distilled into user stories. These are scenarios that describe the user, their motivation and the particular service they want from your website. They can act as an effective check that your new website will satisfy your users needs.

Below are some examples of user stories:

• Janelle is not a member of the organisation and would like to join online.
• Hugh is a member of the organisation whose membership level has changed, he wants to renew his membership online at the new, appropriate rate.
• Lyn is in the market to but a rainwater tank, but is unsure of what type and size of tank to buy, she would like to find out what tank would best suit her needs.

Sourcing user stories from qualitative research is a good tactic. When authoring user stories you need to cover every possible scenario that your users may have in accessing your website, to make these an effective checklist you can use against your website specifications.

Card sorting

This is best done by a web usability consultant.

If you are planning to build a website that is not small or simple, and are unsure about what will be the best way to organise your content, then card sorting is a good technique to discover the content structure your users would find most useful.

Card sorting is a series of one on one tests where a sample of your users sort and label a set of cards, representing your website content, into groupings that make most sense to them.

Design

Design brief

This will be worked up by your web development agency in collaboration with you. But it is useful to develop a draft design brief that broadly states the parameters and desired goals of the website design work. This will make it easier for your web development agency to finalise a design brief and reduce the likelihood of your original design costs increasing.

Your draft design brief should state:

• Background about your organisation.
• Target audiences the website is intended to service.
• Objectives you want your website to achieve.
• Draft sitemap that displays the content structure down to 3 levels.
• Branding to be included in the design (eg organisation logo, title, tagline, colours).
• Tone and personality you want the design to project.
• Website designs (or particular aspects of them) you like and why.
• Website designs (or particular aspects of them) you don't like and why.
• Content to be featured on the homepage.
• Compliance with any particular standards (eg Vision Australia's accessibility standards, W3C, any government standards).

Design parameters

Within the design phase, there are a number of parameters that you will need to decide on upfront. These parameters can initially be decided in the design brief.

• Minimum number of design concepts to be developed.
• Types of pages to be designed, for example:
  • Homepage.
  • Sample sub-page.
  • Landing pages for major (eg 1st level) content areas.
  • Any special pages or subsites that require a unique identity.
• Minimum number of edit cycles to be performed on the preferred design concept.
• Responsive designs requirements.
• Usability testing design requirements.
• Scope of post-testing design rework.

Number of design concepts

The big picture here is:

• More design concepts = more likely you will be satisfied with the design + higher costs.
• Less design concepts = less likely you will be satisfied with the design + lower costs.

If you have a large budget and have the goal of building the best website possible, then you probably don't need to specify this aspect of the design phase. Your selected web development agency should be able to produce as many design concepts as needed to come up with a concept you are satisfied with.

But if your web development budget is limited (and if you are trying to squeeze as much development into your budget as you can) then you may like to consider limiting the number of design concepts to be produced for the project.

I like to have a minimum of 3 design concepts for web projects, even those on a limited budget. This allows you to produce 2 concepts that satisfies the design brief plus room for a third concept that can be left open to the web development agency to create something of their choice.

But if your budget is tight then you can compromise by limiting the number of design concepts to 2. If you do this though, then you need to make sure your design brief is as detailed and specific as it can be, to make sure you are getting what you want.

I wouldn't recommend only commissioning 1 design concept as that creates too much risk of your designers not getting it right with only one go at creating a design concept.

Types of pages

As a minimum, you will always need to have concepts designed for the homepage and a sample sub-page. But you also may need pages designed for:

• Subsites.
• Landing pages for major content areas that you first arrive at after clicking the menu item.
• Special pages that require a different identity to the overall design theme.

These special pages are usually sections of a site that address a particular user group (eg members), issue (eg a major campaign) or content collection (eg an organisation's publication).

You need to identify these design requirements in your draft scope and determine if they will be either a completely unique design or a variation of the finished design as this will affect your design budget and timeline.

Usability Testing

Usability testing allows you to discover and resolve the issues your users have with your website before it goes live. It's your insurance policy to minimise the risk of your users becoming dissatisfied and not returning to your website. So it makes sense to do this if you can.

Usability testing can be done on design concepts, prototype websites or fully completed websites. Testing can be done remotely or in person.

The most effective form of usability testing is on fully completed websites in person. This is because it's the most authentic test and the tester can better understand the issues users may encounter than what remote testing may record.

But if budget is an issue then testing a web prototype (a website with dummy content using finished design for all the major content areas) remotely can still give you valuable test results for a lower cost.

Design amendments

It follows that if you are going to undertake usability testing then you will be using the findings from this testing to amend and hopefully improve the design and layout of your website.

You may like to draw some boundaries around this work by defining the:

• Maximum number of hours to be spent on this work and/or:
• Number of edit cycles to be applied to this work.

Sitemap

A final sitemap that details content types, landing pages, site functions and all content levels will need to be developed by your web agency, but for the project brief it is useful for you to develop a basic sitemap.

This basic sitemap can simply display the parent (1st level) content areas and their children (2nd and 3rd level). The labels you use for these content areas do not have to be the final version and can be working titles. The purpose of the basic sitemap is to give your web development agency a rough idea of the range of content collections you are wanting to publish and the relationships between them.

Gliffy Diagrams is a good and very easy to use tool to develop sitemaps. It's also free. Attached below is a sample sitemap diagram in the Gliffy file format that you could use in developing a draft sitemap.

Try to indicate on your sitemap whether each content area will either be a single page or a collection of pages. This is important from a development point of view. Making available a single page is easy. But a collection of pages usually means that an automated and formatted view or listing of these pages will be required to be configured by the web developer.

Be open though to changing the naming and structure of content items in this basic sitemap as the scoping and specification development process may suggest changes to the sitemap that will improve your website.

Content Management System

Not many clients realise that when you select a web development agency you are by default, also selecting a Content Management System (CMS) product as well because agencies tend to prefer developing and supporting one CMS technology. Some larger agencies may support 2 or 3 CMS products but this is rare because the more CMS technologies you support the greater your overhead is in doing this and as a result, the less efficient you are as an organisation.

You can take the approach here of going through a separate CMS selection process before you finalise your web development project brief and start requesting proposals from web development agencies. But given the large number of good CMS products on the market and how most of these would service either most or all of your needs, I think the better approach is to list the particular features or functionality you want in a CMS and then make sure that candidate web agencies can meet all of these CMS requirements.

User groups

At a minimum, your website will require the following user groups:

• Website administrators (to manage content via your CMS).
• Public (unregistered) users.

But you may need to create extra user groups to manage access to website content and functions for members of these groups. Some examples of extra user groups are:

• Members (who can access a restricted members area).
• Stakeholders (trusted organisation outsiders who are granted access to restricted content).
• Content editors (who can edit and publish submitted draft content for the website).
• Content publishers (who can submit draft website content for review by Content editors).
• Registered public users (to post in web forums or use services such as e-commerce).

In your project brief, you should list what user groups you will need set-up and what access to website content and functions they will require.

Website functions

Your web development agency should produce a functional specification document that details what website functions will be required to be built.

Before we go any further here I should say what I mean when I use the term website functions. A website function is any process within a website where public (non-CMS) users enter data (eg text, selecting list items, uploading images - usually via a webform) and the website responds with a service based on that data. I've excluded CMS functions in the first instance here because they are part of a product that the public won't normally be using and so do not need to be defined.

Typical examples of website functions include:

• Search (including advanced search that enables you to search on specific criteria and/or specific content areas)
• Subscribe (eg email lists)
• Webforms (eg feedback, surveys, service requests etc.)
• E-commerce
• Calculators

If you are using standard functions "out of the box" from your web developer's product set then these don't have to be specified, although you should check that you are getting the functionality you want here.

But if you are requiring functionality that is beyond the standard functions of your web developers product set then these need to be specified by your web developer in consultation with you.

For the purposes of your project brief though you should just list what functions you require in your new website with a draft list of inputs and outputs for each function.

Content publishing & migration

For the project brief you should specify:

• What content you will want migrated from your current website.
• Who will do this.
• Any new content that will need to be published.
• Who will do this.

I would recommend you get your web development agency to migrate your selected content. A competent web agency will be able to quickly customise the bulk content migration scripts to move content en masse from your old website to your new website. This work will be done in a fraction of the time it would take you to manually republish your content from old site to new.

Content authoring

You should consider reviewing and rewriting your existing content you wish to migrate as well as authoring any new content. I say this because in all likelihood, the existing content was not written for the web (being copied and pasted from previous print publications) and could be vastly improved.

Many clients see this as a luxury item that can be avoided or try to do some of this themselves with mixed results. 

My advice to clients is to either learn how to do this yourself with some professional training or hire a professional web copywriter to author and rewrite your content. Not doing either of these will cost you more in the long run with content your users will not want to read.

Training

You should specify that you want training and support documentation on how to manage your website using the CMS.

At a minimum, a half day training workshop plus a 1 hr refresher say 1-2 weeks after go-live should be considered.

If you are planning to build a large and complex website that is going to be administered by a team of content managers then you should consider holding separate training sessions for each role within your team, such as:

• web administrators
• content editors
• content publishers

Maintenance

When you host CMS-enabled websites for clients, time needs to be spent by system administrators maintaining the server environment and CMS software that runs their websites. One way or another, most web agencies charge for this time, whether it be as a specific line item (eg server & software maintenance) in a hosting invoice or absorbed into (a higher) hosting cost.

Some web agencies though will not charge for this maintenance as a regular costs and will instead charge it to client on an as used basis, but these would be in the minority.

Whatever the case, you need to ascertain from candidate web agencies to clearly define what is maintenance and what is support and how they charge for these services.

Maintenance is usually:

• Monitoring server performance.
• Regularly checking errors.
• Keeping software up to date.
• Addressing any issues that may affect performance.

Support is usually implementing the following types of requests by clients:

• Website enhancements or additions.
• Advice or training on website management
• Assistance with content publishing.

Support

Each agency will do support in their own way and are unlikely to change their support service just for one client. So rather than specify what you want in terms of support, you are better of requesting the following support data from web development agencies so a meaningful comparison can be made between them:

• The base hourly rate of support.
• Discounts for bulk purchase of support hrs in advance.
• Whether pre-paid support hours expire at the end of a time preiod or whether they can be rolled over into a new support period.
• How different service levels are defined (eg how is an emergency different from a regular issue?).
• Response times for different service levels.
• Any rate factors that apply to service levels (eg an emergency issue being charged at 2x the base hourly rate).
• Minimum hourly charge for support requests.

Budget

There are two approaches you can take when determining a budget for your web development project:

1. Setting a budget limit.
2. Estimating a budget based on the expected size and complexity of your website.

In option 1, you will essentially be asking web development agencies to try and fit in as much development as they can within the allocated budget (unless your fixed budget is extraordinarily large, which tends not to be the case when you are setting a budget limit). This is not the best approach because you are not making any value for money decisions here on what to include or exclude in your development budget and are effectively forcing potential web developers to compromise on their approach (in order to squeeze more into your limited budget).

The better approach is option 2, where you estimate the cost of the website based on the size and complexity of your website. Unless you have worked for a web development agency then you are unlikely to know this as hardly any agencies publish their delivery costs online.

Our agency, Social Change Media, is a bit different. We believe in being upfront with potential clients and so have no hesitation in publishing costs for our services. Our reasoning is that we think our costs are not too high, but if potential clients do find these costs too high, then it is better for all concerned if they know about this as soon as possible.

Below are typical costs for web development projects of different size and complexity.

These are based on an hourly charge out rate of $120.00 AU per hr ex-GST. Some agencies will charge more, some less. The costs estimated for each type have been made on a "middle of the road" basis; midway between a minimalist approach to save costs and a best-practice approach where cost is not a barrier.

Each web agency has their own development methods and overheads, so naturally quoted costs will vary for each type. But these costs can be a reasonable guide to set a budget total for a web development project.

For the purposes of interpreting  the above table, here are some guidelines to differentiate between simple and complex websites.

Simple: a simple website is one that:

• has a content structure that is not wide or deep
• uses one standard format for listing of content on landing pages.
• makes minimal use of standard site functions (eg search, forms, email subscribe)
• has no customisation applied to site functions or content presentation.

Complex: a complex website would include a range of the following features:

• Different formats applied to content listings on landing pages
• Customised site functions such as advanced search, content filters, multi-page forms.
• E-commerce services.
• Web services integrated into back-end client databases (eg authenticating members and looking up subscription rates from the client's CRM).
• Specific access and content views for different classes of users.
• Workflow management for tiered content publishing teams.
• Subsites.

The above cost estimates don't include any research or usability testing. Below are typical costs for these services.

* Excludes any recruitment or marketing costs.

Timeline

Web development agencies quoting on your project will include a draft timeline in their proposals. But it is useful to know how long various web development activities take, particularly if you are going to set a timeline in your project brief.

Below is a table showing typical time requirements for each activity for a web development project. It is possible to complete these activities quicker, but this would require web agencies to dedicate a higher proportion of time and resources to your project.

Conclusion

The more work you are prepared to put into your web project brief the greater your return will be in terms of quality, time and cost of your project. But remember to treat your web project brief as a draft set of requirements (rather than a set a specifications set in concrete) and be prepared to change these when considering research findings and professional advice.

In part 2 of this article, I'll focus on managing a web project from client-side during the project itself.

Mark McGrath is a Web Consultant and Director of Social Change Media.

Download