Error getting theme layout

Website Development Methodology – Part 1

Posted @ 6:41 am by Alex Kaplinsky | Category: Web Development Process | 0 Comments

Why Methodology?

I have seen many methodologies and processes in my years of developing websites. In this article (and, depending on interest, perhaps future articles), I’ll describe what I’ve found to work well, and share some of the tools and deliverables that accompany a good web development process.

So why should you have a process in the first place? Processes keep everyone informed of the progress of the project, what is expected, and what’s coming next. The client (in our case an external client, often a department or group of people at a company,) can gain visibility into how web sites are built; many have limited or no experience with creating a good web site. Once the project has begun, the client should understand what is expected of them and where the points of no return are. A well-articulated methodology and strong project management that tie back to that methodology are key to keeping a client up to speed. Internally, a methodology serves to ensure that the proper thinking is done up front, to prevent wasting time on building the wrong things. It also ensures that the team knows what their deliverables are, along with where they are in the project.

Throughout this article, I will refer back to the metaphor of constructing a building. People often come to me and say “I want a website — how much will that cost?” In our metaphor, this equates to “I want a building — how much will that cost?” The question itself is meaningless; in order to provide a meaningful answer, there are tens of thousands of details that must be supplied. Some obvious ones are:

I can keep going with these silly analogies, but I think you’ve probably had enough. Let’s move on.

Methodology Overview



The first phase of a project should be oriented around understanding what the project is about. Communicate the:

Typically, this information is found through interviews and audits of the current systems, sites, materials, brand guidelines, etc. In the physical world, this would translate to defining what type of building to build, the approximate number and types of room, specifying the need for phone systems, plumbing tie ins, etc.(You thought I was done with the metaphors, didn’t you?) The deliverable is the Requirements Document, which contains the following items:


Now that we know what we’re going to build, it’s time to design how the site will be built. This is equivalent to a blueprint in building a house, through which is determined exactly how those rooms are laid out, what colors to paint, who the subcontractors will be, etc. By the time the design phase is complete, there should be no question as to what is being built, down to the finishing details, and how it will all be put together. The items in a typical design document are:


Knowing both what needs to be built and how, the development phase can begin. During this phase, the site or application will be built out. As in the real world, documents are useful, but daily review by the architect of the progress is crucial. The tasks need to be executed in the right sequence, with an overall vision for the end product. During this phase, the best policy is to maintain focus on the end product and key building blocks. This is typically done by daily scrum meetings, in which each of the developers has tasks reviewed. It’s the job of the project manager and account manager to monitor progress, make adjustments, and keep the project on schedule. Typical tasks during development include creation of:


Once the QA is completed on the development servers, it’s time to get the site live. This involves moving the code, wrapping up all the loose ends on a project, and training the person who will be responsible for maintaining the site. This is the time to sweep out the corners, get all the instructions together, verify all dimensions, etc. Depending on where the site will be hosted (in-house or externally) and who the maintainer will be, the deployment phase can be different in different projects. Sometimes the site is simple and the environment is identical to development, resulting in a fast process. Other times the final deployment can be as difficult as the development; the environment may be very complex, tie-ins to other systems may need to be established, and completely new team members from IT may need to be trained on all the components. The typical deployment tasks are:

By following this methodology, or any other well-thought out approach, your projects have a higher chance of succeeding and resulting in a more useful end product. Try to understand why this is and explain it to all team members, both on your team and in client organizations. Each project will be different, so this methodology should serve as no more than a guide. Don’t think that a website (or, for that matter, a building) can be built without knowing what you’re building, planning how you’re going to build it, and maintaining supervision during the development and deployment process.

Leave a reply

Error getting theme layout