Requirements gathering is one of those steps in any project that can't be missed. Whether it's conducted vigorously and methodically, haphazardly and unconscious, it's done.
It doesn't matter whether you're ordering a hamburger at Harvey's or a web site build: the person taking your order needs to gather your requirements.
When you go to Harvey's, you don't just say you want a hamburger; the person taking your order will want to know if you want a classic or whatever, the person making your burger will want to know what kind of toppings you want. You could be remiss and say "just give me the toppings most people get"; not a problem, unless you really detest ketchup, which is what most people get on their burger.
Recently, I was discussing with a colleague the issue of requirements gathering methologies. In our experience, SMB's and micro-businesses, in particular, tend to work within very short temporal cycles. They can also have pretty short fuses and regard methodical questioning and any information probing to be, at best, extemporizing tactics and, at worst, unresponsiveness. How often have you been challenged with, "Why do you need to know so much? Why are you asking all these questions? I just want a ballpark, an estimate. I'm just a small business and don't have the time to be talking about this. I just need to get it done."
So we came to the tentative conclusion that enterprise-level business methologies don't necessarily scale down to the micro-business and even SMB (small to medium businesses) level. Is this really true? Do we need to develop a completely different style of requirements gathering for different classes of clients?
This question is asked so often and by so many, there should be a Wikipedia entry for it. And it should be tagged as an "Existential Question," along with other questions of similar ilk: How long is a piece of string? How much does a car cost? How much does it cost to build a house?
You get the drift, I hope.
The fact is, the only way to truly capture and contain your web development cost is to quantify your project accurately by determining its business requirements. This is the most important phase of your project – a fact that most people fail to realize.
The implication of an incomplete scope definition goes right to the bottom line: project costs that spiral out of control, paying too much for features and functionalities that serve no business purpose, allocating inadequate funds to properly build a functional site, etc.
Caveat emptor: if a web firm blazes in with a cost estimate that doesn't include a scoping phase, RUN. How could they possibly provide realistic pricing for a project about which they know next to nothing?
If you're thinking about building a web site or making a change to your current site, this post's for you.
Please, please don't be tempted to start your project with pretty pictures and a snow storm of words. Unless your site consists of 3 pages of text and images that don't link to one another, please take the time to think about how the site should work before you fantasize about how it should look. Along the way, you'll be tempted: stay the course, don't fall off the wagon.
Let's get started.
What follows is a highly simplified overview of what's involved with developing a web site. Depending on how much content there is and what you wish to accomplish with the site, development could be a fairly straightforward task that you could undertake in part or completely; or it might be a beast that's best left to the professional.
Who is the web site for?
Sometimes we think we know, but more often than not, we say we do but really, we don't. Ask yourself the hard questions:
- why do you think you need a site?
- who are you building it for?
- what are these visitors' needs: are they all pretty web savvy or will they likely get confused by newfangled technology?
By not asking yourself these basic questions, you risk spending effort, time, money, and emotions on something that either isn't necessary or that you'll end up abandoning.
What's going on the site?
First, consider the content that's going to be on your site. How should it be organized? How you organize this content depends entirely on those who will want access to it. On the flip side of this, ask yourself if anyone would be interested in some of the content you're thinking of putting on your web site.
Updating the site: who, what, when, how?
Consider who will be updating the site's content: is it the marketing coordinator who doesn't know what html is or even stands for, or do you have a team of computer science grads who can code and program an entire web site from scratch? Which sections of the site will most often need updates? How often will these updates be available or required? how do you plan on getting this content updated (…a question that's related to the first one about who will do this work)?
OK, what's next?
Only when you have thought through these question is it even time to start worrying about how your web site should look. In fact, after you've worked through these questions, it's still not time to start getting excited about how your web site should look. The next thing you should be thinking about is how your web site should work.
Be nice to your site visitors
Ever been frustrated by a web experience? Ever felt like you have no idea where you are on the site? Ever felt confused by what exactly the site expects you to do in order for you to get to what you want? If you've ever felt any of these things, you've been the victim of poorly designed navigation and site flow. Don't be part of that crime ring: be good to your site visitors; after all, they made a decision to spend some hard-won time on your web site – the very least you could do is not tick them off.
Once you've done the leg work to working out a navigation scheme and how your visitor should go from one screen to the next, then and only then should you start thinking about how pretty (or not) your site should look.
Budget: time & cost
Some basic guidelines: If you had 100 hours to spend on your web development project, asking yourself and answering those questions I posed above should take about 25 hours. The next most important chunk of time should be devoted to designing the navigation and site flow: plan to spend another 25 hours working on this part. You're now in a position to start thinking about colours and fonts and other eye candy: spend 15 hours on this. Finally, remember: you don't have a site until you hand the work you've done over to the developers who will actually code the graphical user interface and program the working components of the site (e.g. just typing "click here" will not make it click: someone has to turn that switch on). Be good to yourself and your site visitors: make sure you allocate 35 hours to make all those great ideas actually come to life.
Garbage in…garbage out
Every project is different: some need more time with content and structure, others need more time on the programming end. It all depends on what the site's purpose is and who the visitors will be. Just be sure to remember that the way a site looks is the very last thing you do before the site is coded, rather the first. Think of it this way: if you were building a robot but spent most of your time working out how the robot will look first and only think about how it will work afterwards, you'll likely have a great looking bimbo.