Methodology

Business Analyst / Project Manager in Orange County, California

I wrote this document to help my potential clients understand my typical approach to dealing with any website development project. I have found through experience of building both static and database-driven websites sites over the years, that following these basic steps assures a greater chance of overall project success.

The One Liner

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

Brainstorming

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

Wish List

After a 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.

Pairing Down

This is a reality check step 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 omitted without a significant impact upon the overall goals of the project.

Written Project Specifications

Project specifications are usually written prior to beginning any development work. Essentially, they are the blueprint of the website structure which can be broken down into individual tasks and they are the basis of an accurate written estimate. Time involved in creating Project Specifications varies based upon the complexity of the project, but as an example, it should take no more than a few days to week to plan out a typical online store.

Screenflows
In this step, I create a series of non-functional screen flows that represent the Project Specification. The purpose of this exercise is to work out any last minute misunderstandings of the specifications prior to beginning any significant work on the website.

Functional Structure

Once we have all agreed that the Project Specifications are solid and that they initial concept represented by the screen flows is accurate, I then create the functional skeleton of the application. In this stage, graphics are usually not introduced into the application until this phase is complete. To use another analogy, we build the framework of the car, put in the engine and make it drive-able but leave off the side panels until we are satisfied with how the car works.

The Façade

Once the basic functionality of the system is in place and working, I then integrate the graphics into the website.

Final Review / Bug Fixing

During the debugging phase, we examine the website’s structure to make sure that everything that was planned was accomplished. I then correct any problems that are associated with functionality specifically noted in the specifications or provide estimates for further development work that was not considered in the original specifications.

Open House

The site is moved to its final location, tested again, and deployed. The website is now ready to be marketed.