From Requirements to Production

Reviewing the process which takes place from requirements gathering all the way up to production.

Every small web development agency is unique in some way, this is usually what gives them some kind of competitive advantage. Part of that uniqueness is the process they use to convert what a client wants into reality (e.g. a website). This article discusses that process in a big picture kind way, the main focus is on roles - or who does what.

I've seen a few versions of this process at different companies I've worked at, but they mostly involve the same players each time (e.g. a sales rep, a project manager, etc).

Most small web agencies could say their work is divided into two arenas: small web projects and custom development. Small web projects would be basic websites such a business web presence. A custom software build covers all other scenarios (e.g. where a lot of code is written to account for the client’s unique business rules).

The processes described in this article are most relevant to the small web projects stream, mainly because this kind of work is generally the same thing over and over again (e.g. client: "I would like an about us page, and a contact page...").

The players – before we begin the discussion in earnest, we should establish the roles in the process, or 'who does what'. Job responsibilities often go hand-in-hand with a job title, but not always. So, lets introduce the players:



In the first approach, which I like to call the split-role approach, the process unfolds as follows:

1. BDM sells web solution to client.


2. Business Analyst contacts the client to take-down their requirements (and then hands that over to the Project Manager)


3. The Project Manager organises production resources.

The alternative method is called the dual-role approach, which looks like this:

1. BDM sells web solution to client.


2. BDM gathers requirements from client and hands it over to the Project Manager.


3. PM/BA reviews requirements (and often asks BDM to gather a few more details).


4. PM organises resources and ensures delivery

I should mention that I specifically haven’t represented the iterative nature of development in either diagram (for the sake of simplifying the diagram).

Each approach has certain strengths and weaknesses. The most obvious difference between the two structures is that the dual-role approach combines the jobs of a Business Analyst and PM into one individual. The benefit of this is it cuts out one communication channel. The downside is it can be hard to find an employee with evenly matched business analysis and project management skills.

The dual-role approach also requires that the BDM have business analyst-like abilities, not as refined as a true business Analyst, but pretty savvy none-the-less. The fact that the BDM is capturing basic requirements takes a load off the PM/BA combined role, allowing them to effectively manage more concurrent projects.

Since the BDM is acting as a watered-down Business Analyst, its likely that the Project Manager/Business Analyst will often need to get clarifications on the requirements which have been gathered. For instance, the BDM may write down: "the client wants to put their products online", to which the PM/BA may say "does the client want to sell their products online, or do they just want an online product catalogue?"

The biggest concern for the BDM/BA combined role is that the skills needed to be a good BDM and a good Business Analyst aren't the same. Most BDMs aren't as structured in their thinking (which is needed to gather solid requirements), but then again most BAs don’t have the soft-skills a BDM generally has.

Pricing considerations - since we are dealing with basic website builds here, it is fine for a BDM to provide a client with a ball-park estimate at the initial client meeting. The final pricing does need to be settled by a proper Business Analyst though, they are the only ones that can cost the project with the least amount of risk.

There is also the issue of up-selling and business re-engineering. On the one-hand, a Business Analyst consulting directly with a client may improve the technology solution by making useful suggestions (split-role approach). The flip side would be a BDM is more likely to get a greater budgetary commitment from the client, due to their selling expertise (the dual-role solution).



Personally I prefer the duel-role approach since it reduces the number of communication channels (or 'integration points'). The more communication channels, the greater the risk of losing information or misinterpretations. In addition, small companies generally can't afford to hire specialists (i.e. a specific person for a Business Analyst role, another person for the PM role). I can however appreciate that the split-role approach offers some degree of scalability since there is more division of labour.

Special thanks to members of the Stack Overflow community for their contributions towards this article.

Subscribe to RSS Feed.

Needs Analysis for Business Websites

Questions to ask your client before building their website.

This article is most relevant to people who develop standard websites (e.g. a business’ web presence). If your main focus is web-based applications, this paper may have limited appeal.

Client input is the foundation upon which successful web sites are built. It’s absolutely vital that you get your client to articulate their goals in order for you to successfully deliver their project . To help facilitate this process, a number of questions can be asked relating to areas such as target audience, desired look and feel, and what interactive functionality is required.

A good way to tease out your client’s requirements is to use a Needs Analysis document. This is basically a 2-3 page fill in form, full of questions which prompt the client to think about not just the visual elements of their site, but what they are trying to achieve in concrete business terms.

Using a Needs Analysis form provides many benefits. It often acts as the basis for developing a fee proposal or tender (see Writing Fee Proposals). Unless you know what it is your client wants, you wont be able to cost it with any degree of accuracy. Another advantage of a Needs Analysis form is it can present ideas to the client which they hadn’t previously thought of. This isn’t just a boon in terms of up-selling, it also means features aren’t added mid-way or at the end of a project (e.g. client: “I know you’ve finished my website, but can you just quickly add a photo gallery page?”).

The Needs Analysis form I use is broken up into five sections; Company Details, Graphic Design, Business Related, Technical Requirements, and Programmed Features. I will cover some of the questions contained in each section along with the over-all structure of the form.

I always start documents with a short description of what the document is. This is for the benefit of anyone seeing it for the first time (e.g. Document Purpose: this form is used to gather client requirements...).

Company Details – this section is pretty straight-forward, you record information such as the company name, who the main contact is, address, phone numbers, the client’s position within the organisation, etc. It’s also a good idea to note down any other stake-holders that will be involved in the project, and if the primary contact is able to give approval for the work to begin.

The information gathered in the Company Details section will most likely be needed for producing a quote. It will be especially useful if a sales consultant or business development manager is gathering requirements to hand over to a project manager. From this, the project manager will be able to figure out who's who on a project.

Graphic Design – this section is meant to capture details relating to the website’s visual appearance. It is not so much concerned with layout and colour, but rather communication. The information gathered in this section will be most useful to a graphic designer. Good questions to ask the client include; ‘what image are you trying to portray?’ (e.g. friendly, corporate, innovative, etc), ‘what phrase would best describe your website once it’s launched?’ (e.g. ‘these guys look really professional’), ‘what’s the main goal of your website?’ (e.g. sell products online), ‘what else are you trying to achieve with your website?’ (e.g. promote skin cancer awareness amongst young people), ‘what would you like users to do at your website?’ (e.g. register, buy products, etc).

You also want to ask if the client’s logo and branding material is ready. Your graphic designer will want to get his hands on any digital files as soon as possible (e.g. logos, product photographs, etc). Connected to this, you may want to ask the client if they have a style guide. The topic of Flash vs. static HTML also needs to be discussed since there may be SEO and cost implications.

Another important subject is the intended audience of the website. Questions you could ask include; who is your intended audience? what’s their typical occupation?, what is their age range?, is it mostly male or female?, how often do they use the Internet?

You can ask the client to show you some websites they like and have them explain what it is about each site that appeals to them (e.g. client: “I like the clean layout of the site”, “the animated banner is really cool”, etc). If you know that your client likes a particular style of navigation, it makes sense to use that style for their website.

Notice that none of these questions have to do with layout or color schemes (e.g. where the navigation should be, what font should be use, etc). These considerations should be left to the graphic designer, after-all, they are the expert.

Business Related – these questions aren’t directly connected to the visual appearance or functionality of the website, but they may have an impact on the project itself. For instance, you would want to ask questions like: is your content ready?, how are you planning to market your website once it launches?, are you open to developing in stages to manage costs?, do you require an SEO strategy?, are there time constraints (e.g. client: “we need it ready before we go to a trade show in November”, or “we are printing a brochure next month and want to refer to the website”)?

You may wish to ask a few questions about the client’s competitors, such as; do your competitors have websites? what do you like about your competitor’s websites?, what do you dislike about your competitor’s website? Sometimes finding out what someone doesn’t like can be a great help in determining what they do want.

Probably the most significant of the business related questions is about content. Lack of content can be a real killer. A wonderful website may be developed, but if the content isn’t ready, the site is effectively in limbo. One way to help reduce the risk of this happening is to recommend early on that the client engage a content publisher.

Technical Requirements – these questions are mostly system administration related. For instance; you want to find out if the client already has a hosting provider organised. You also need to know if the client has registered their domain name or if they want you to register additional web addresses on their behalf.

Programmed Features – this section covers the interactive elements of the website. Probably the most important goal of this section is to establish the information architecture of the site. This can be done by asking the client what sections their website should have (e.g. press releases, our work, testimonials, etc). The client may also have a need for interactive pages which require custom coding (e.g. sign-up form, news articles, member’s login, photo gallery, etc).

Other significant questions would include; are you planning to sell anything online?, do you require a CMS?, does your site need to work with an existing database?



You’ll generally find that only about 80% of the form’s questions are relevant to any particular project. That being the case, it makes sense to remove or cross-out irrelevant questions before meeting with your client (e.g. you would probably know before-hand if any e-commerce facilities are needed).

Another idea is to pre-fill as much of the form as possible. Besides the obvious benefit of saving time in the face-to-face meeting, it demonstrates you’ve paid attention to verbal requirements which may have already been discussed.