Methodology

This document outlines how I typically approach a website development project. In my experience, following these steps assures a greater chance of overall project success.

Development Process Methodology

I. The Mission Statement

Writing a plan for a web site is much like writing a business plan. It is important that my clients be able to elaborate in a single sentence (or very short paragraph) the point of their project.

II. Brainstorming

During a brainstorming session, we discuss the mission statement, the goals of the project, and all tangents that could possibly be involved in reaching those goals.

III. Wish List

After the brainstorming session, I draft a list of top-level features. We then prioritize the features and, if necessary, divide them out into phases. Phasing a project provides you with the opportunity to budget your project over a longer period of time.

IV. Reality Check

This is where I come up with some very rough estimates to make sure you understand the time involved in taking on the project. I discuss which features take up the most time, which features are mission critical, and which, if any, bells and whistles can be removed without a significant impact upon the overall goals of the project.

V. Functional Specifications

Functional specifications MUST be created prior to developing any code at all. To use the analogy of building a house, you would never build a house without a blueprint, nor should you ever build a site without a plan. Specifications are time consuming, and therefore must be paid for by the client. Based upon the information I have collected in meetings with you up to this point, I can assess approximately how long the specifications will take to develop and agree to a fixed bid for the development of the specifications.

The process of documenting continues until you are satisfied that the written specification matches your present needs exactly. Once you agree that the specification is correct, I then provide you with an exact bid for the project.

I will also create a project schedule detailing the tasks involved in the project.

VI. Functional Structure

Once you have signed off on the functional specifications, I then create the functional skeleton of the application. There are no graphics introduced into the application until this phase is complete and you have signed off on the functionality of the site.

VII. Look and Feel

Once the functional structure is complete and you have signed off on it, the look and feel, layout, graphics, etc. can be integrated into the functionality to complete the site.

IIX. Final Review / Bug Fixing

During the debugging phase, I develop a plan to test the site against all aspects of the functional specification. You will also be responsible for testing and will then sign a final document indicating that the site is complete according to your expectations. I will correct any problems that are associated with functionality specifically noted in the specifications. I would also notify you of any changes which are beyond the scope of work, what impact those changes would have upon the system, and approximately how much additional time would be required to incorporate those changes. It is important to remember that changes are something we both want to avoid. I will generally recommend that changes should occur within a second work phase rather than causing a delay in launch to incorporate the changes. However, you are the client and I respect your wishes.

IX. Launch

The site is moved to its final location, tested again and deployed.