Website Planning - Part 1 - Radiant

The Radiant Blog

Website Planning - Part 1

Posted by Andrew VanderPloeg

One of the things that I've come to appreciate in my time managing website development projects is that most people don't naturally have an appreciation for planning. Most programmers love to just dive into the code without doing any up-front planning which is an incredibly inefficient thing to do, and many people looking to build a website seem to think that a website doesn't require much thought and can be developed in a month.

Over a couple posts, I wanted to share a bit about our journey on project planning. I'm hoping that if your organization is looking to develop a new website, that our experience in this area will help you all avoid some pitfalls and go into a web project better equipped to tackle what typically is a much bigger project than expected.

When I first came on board here, we didn't do a lot of planning around websites. In fact, we'd typically do a free proposal/quote in which we would essentially guess at the details of what our clients needed and then send back a loose specifications doc with a flowchart and a dollar value associated for the client to sign off on. This allowed us to move pretty quickly as far as getting a quote to our clients and once a work agreement was signed, we could dive right into design, where we'd labour over JPG images with the client to work out the finer details. Clients loved the speed of this process...at first.

The challenge with this approach was that although our experience in the area of web development allowed us to make educated guesses in the proposal and we'd typically get a large part of the specifications right in our quote, the specifications were pretty light given that we weren't getting paid for our time to write them out and assumptions were still made and budgets were established on those assumptions. So while our clients were happy with the speed of the project up to that point, typically, once they started to see the pages and technology take shape, both parties would realize that they didn't really have the clearest understanding of what was needed in the project. The practical outcome was that timelines were extended as we had to redefine and rework the designs and code mid-project, and budgets increased as we had to either redo completed work or the scope of the project had grown. So a process that started out as fast-paced and happy, unravelled near the end to leave both parties frustrated.

That's the pitfall of very little planning, and it's at that point that we started to ask some hard questions about how we could change our process to set up all parties with a better view of the scope of the project so that accurate budgets and timelines could be established and adhered to, meaning everyone left the project happier.

I'll break down a couple of the approaches we've taken since then to answer this in a couple subsequent posts next week. I'd be interested to see what thoughts you all have as we go through these posts.