How Much (work) is a Website? A lot!

This month, I'd like to review the steps involved in a web development project, paying particular attention to processes that are often overlooked or underfunded.

Before you continue reading, it might be helpful to take a look at our Project Anatomy document, which specifies all the steps and roles involved in a typical web development project. We use it to properly plan all of our projects at the outset, making sure we've allocated the appropriate time and resources in order to meet everyone's expectations, as well as to track the progress of a project along the way.

Every project should be preceded by strategic planning; think of it as similar to drawing up your shopping list. However, determining the scope of a web development project is not really as simple as drawing up a bulleted list of wants (Video? Check. Ecommerce? Check. Blog? Check.). What's missing from this list is a guiding strategy. So far, I've been using a grocery store analogy, but my next point is best made from the wood shop.

That was one of Bob Villa's (of This Old House fame) mottos, which was printed on a mug my step-father used to hold pencils in his garage woodshop. Whenever I think of him, I think of that motto and appreciate the value of carefully considering something before you do it. Villa held to this motto because lumber can't be un-cut; once you've started sawing through wood, there's no turning back- that is unless you have an endless supply of wood. In the same way, once you start the development phase of a website, it's very difficult to start over without significant schedule and budget losses.

This is why we hold firmly to the belief that beginning any project with a strategic phase will ensure that realistic goals are set, a manageable scope, budget and timeline are established and an appropriate content strategy is planned. Without taking the initial time to do this, it's likely that some aspect of the project will not go according to the expectations of those involved. In fact, we would confidently affirm that spending time on strategic planning will actually save time and money in general by preventing unnecessary revisions and potential road blocks.

Our approach to a strategic planning phase takes three particular steps: The first involves an interview, during which we spend time with our clients asking lots of questions. The information we receive in this interview helps us to be aware of expectations, fears, limitations and other factors that often do not present themselves until much later. It's not an interrogation, but a thorough diagnostic of business, marketing and technological factors. After we've gathered the information we need, we prepare a written report which covers positioning, goals, current perceptions of strengths and weaknesses, functionality recommendations, search engine optimization, and content strategy. Once this report has been completed, we regroup with the client to review it in detail and take questions. This is often the most productive portion of the strategic phase as a greater sense of goal-oriented unity surfaces and the team gets excited about the project they are about to begin. Additionally, it's at this point that we can most accurately establish a budget and schedule for a project.

To be clear, not every project we're involved with needs a "Newfangled" strategic planning phase. Some of our best projects have begun right out of the gate because our clients have already planned extensively before we became involved. In these cases, it's not that strategic planning isn't needed, it's that one has already been done, just not by us. However, if, during our sales process, we sense that an internal planning phase has not occurred, we will enthusiastically make our case for a "Newfangled" strategic phase.

Once a strategy has been developed, we can begin prototyping.

In case you haven't noticed, we talk about prototyping a lot. We do this because we believe it is the most important production phase of a well-planned web development project. We feel so strongly about it that, in addition to making it the subject of many past newsletters ( Web Development Fallacies, Part 1 and Part 2, Grayscreen/Whitescreen Process Applied, Why We Prototype, and How We Prototype), we've also written a book, Client vs. Developer Wars, about how we discovered our unique prototyping process. Back in 2007, Eric highlighted the importance of prototyping over even our CMS when he wrote that "without grayscreen prototyping we would have gone out of business well before our CMS ever had the chance to mature."

We obviously have no shortage of information on why and how we prototype throughout our site, so I won't repeat it all here. What's more important to our clients is that prototyping requires a lot of involvement from them. For some projects, this might even mean daily reviews, frequent detailed discussions, and answering many questions. This rigorous process can take anywhere from a couple of of weeks to several months, depending upon the scale of the project. By the time the prototype is close to being approved, it's likely that everyone will be wiped out, but it's important that we don't rush it. Prototype approval is our first major benchmark; once it's been reached, it's very difficult to go back. Regardless of the length of this phase, we make sure that it is productive and efficient, producing a comprehensive, clear and detailed specification for our developers to use during the actual development phase.

Like prototyping, we've written about designing for the web before (Web Design Tips for the Print Designer, Part 1 and Part 2). Without going into much detail on how design works, I do want to focus in on a couple of key points.

Design is a subjective process, which means it is difficult to know at the outset how long it will take to be completed. Depending upon how close the first layouts come to your client's expectations, subsequent rounds of revisions could go on as long as, if not longer than, the prototyping phase. When we do the visual design for a web development project, we try to follow a "narrowing funnel" approach by making the big decisions first, then proceeding to refine details until the design is resolved. This helps to keep the design phase in budget, as starting over from scratch several weeks in could be cost prohibitive.

Like prototyping, this process requires a lot of involvement from our clients. However, we find that the more information we can get our designers at the start, the more effective and efficient our design process is, not to mention the better the final design itself is.

Once the prototype has been approved, our developers can go to work on building the actual website. This means a bit of a break for our clients in terms of day to day involvement with us, which means it's a great time to start gathering and creating content in anticipation for content entry.

Last month, I wrote about how important it is to dedicate time and resources to website content creation. This true for websites in development just as it is for ones that are already live. Because we have already gone through the prototyping phase, our clients should have a very good idea as to the kinds and volume of content that needs to be created. However, chances are that the time needed to do this work has been vastly underestimated. While using a content management system, like our NewfangledCMS, makes content entry easier, it does little to simplify content creation. It takes good old-fashioned hard work, plenty of strategic thought, and probably more than one person to create content. Take my word for it- this always takes longer than anyone thinks.

Internally, we call content entry "integration." This term works on a number of levels- the integration of content in to a functional system, as well as the integration of our clients into the working process in more significant and real way.

While we have several specific Quality Assurance (QA) steps in our process, as any development company should, I believe that content entry is one of the most effective and important QA efforts for any project. Typically, this is the point in the process when our clients are able to fully experience the reality of their site for the first time. While they have worked closely with our team on prototyping and designing the site, the process of actually creating content and then using the content management system to enter it is when all the "dots" are connected and made real, and often the first point at which expectations are clarified. You see, no matter how thorough a prototype is, sometimes there are concepts or needs that cannot be communicated until you are immersed in an actual working and producing environment.

This is similar to the "blank-slate-shopper" phenomenon: Have you ever seen a review of a book and thought that you'd like to purchase it, only to find that the next time you are actually in a bookstore you have no idea what you want or where to start? This is because we tend towards reactive rather than proactive thinking. We hear about something and react to it with, "Yes, I'd like to read that," yet when we get to the store and are surrounded by thousands of books, we react to them all by loosing focus. (Of course, if we had drawn up a list in advance, we'd be in good shape!) While we find the prototyping phase, being a proactive step, to be extremely effective and critical to our process, we use subsequent rounds of QA to catch any results of reactive thinking during a project and know that the process of content entry will also do the same.

QA does not ensure that a project will be 100% bug free. While some bugs are due to sloppiness or haste and can be prevented by thorough QA steps, others are the result of unforeseen functionality conflicts that may not become evident until a site is being used, despite the best intentions and foresight of the programmers. As with any development project, bugs like these should be expected and encountered with patience (this goes for us just as much as our clients). While we hope that our many stages of QA will mitigate the frequency of any bugs occurring, we are definitely not surprised when they show up.

Once we've gotten to a point of resolution with integration and QA, we can finally reach the finish line and go live!

In my first newsletter, You're Using RSS Now...Right?, I concluded by saying that "Though this all may seem very daunting, it's also going to be fun." I was talking specifically about keeping up with information overload using RSS, but I think I could make the same conclusion here, too.

A huge amount of work goes in to a web-development project, but not in vain! Aside from the return our clients expect on their investment, a well conceived and successful project will instill a sense of accomplishment and satisfaction in all those who are involved. It will also be a learning process, involving getting up to speed on business, technical and relational issues for everyone involved. In fact, our experience has been that during this intensive process, we also get to know and form bonds with our clients that lead to strong, productive and successful working relationships for a long time to come after the initial project is complete.