Newfangled works with independent agencies to create lead development web platforms for their clients.

Newfangled works with independent agencies to create lead development web platforms for their clients.

An Effective Website Development Methodology

It was Y2K and the computers of the world had not imploded. The web world was going strong. The dot com bubble burst was still in its nascent stages. We had two very large projects which both needed content management capabilities. We decided to invest extra time to build a CMS that would meet the needs of both sites and that we could reuse. This became the NewfangledCMS but that's another story. This story concerns the deep dread I felt at that time, going into these two large complex sites that would be using, by far, the most complex technology we'd attempted up to that time. If what I had experienced to date, using paper documentation, held true in these two complex sites, I would soon be in a world of hurt. Even though our paper prototypes were very detailed and thorough, and though our clients had approved them (many times, over many meetings, lasting many hours) I knew that it was the things they could not see in the paper that would come to light in the beta release. I was prepared, and had even planned for some pain in this regard, but how painful would it be? Sadly, past trends confirmed that the more complex a site the more questions/problems/changes/ideas we would get after the client could click through a programmed beta site.

In anticipation of this reality, after the clients had signed off on the paper prototypes, but before we started coding, I asked one of my developers to re-create the paper document using very generic unformatted web pages. The two documents, one paper, one HTML were basically identical and showed all the same information and all the same pages. We asked each client to review their web based HTML prototypes. And guess what. They had lots of questions/problems/changes/ideas that they did not have even having signed off on the paper. Happily, we had not started coding yet, and we could address these concerns before we began. I sure was glad we did that. What I didn't know was whether or not this would make any difference when it came to the final sites.

There's something you need to know about website project schedules. Every project starts off with an intended start date. Very few hit them, almost always due to content issues so that it's nearly impossible to predict exactly when a site will go live, especially large complex sites whose initial schedules stretch across a six month period. So how was I to predict that both of these large complex sites, using our brand new technology, employing a brand new process would both end up going live on the same week? And how was I to control that this would be the very week I was going on vacation to visit friends on the other side of the globe? I was out of the country on the day these two complex sites went live. That morning, in another country, I woke up with a feeling of dread. I desperately did not want to check my email. When I did, I was certain my vacation would be over. But it had to be done...

Inbox (1), From: Newfangled, To: Eric. "Hi Eric. The client called and just wanted to say how happy they are. The site is doing everything they wanted and more. There were a few minor bugs that have already been fixed. Hope you're enjoying your vacation."

I had to read that again. This wasn't possible. Web projects, certainly not ones this complex worked this way. Maybe this was a joke and the real email was still coming.


↑ top