TABLE OF CONTENTS:
Today it seems that everyone has an idea for a monster web site or product that will be “the next big thing.” Many of those that don’t are in the business of developing sites for those who do. In today’s economy more people than ever are entrepreneurs of all sorts, whether envisioning web sites, starting or expanding businesses, or any of thousands of other things. What they have in common is that they are in fact (perhaps unbeknownst to themselves) project managers. Bill Gates wasn’t too far off the mark when decades ago he predicted that one day grandmothers would often be software developers or at least hire them.
Proven time and again, their projects, like all projects in organizations of every size, often end in failure. A project that initially seems to have a clear path to success turns out, amazingly, to be a twisted road with ice and ravines at every turn. In business, lose-lose propositions, though all too common, can be disastrous for all involved. Failure can be in totally wasted funds and even total business failure. In short, these failures can end in lost dreams.
Here are two examples that shed light on the problem.
“You’ll never do business in this town again!”
Just recently a web developer related this (very true) horror story to me. He had agreed to meet a client in the coffee area of his apartment complex.
The developer bid the job for two iterations of the customer’s site. Complaints from the customer abounded. This color was wrong. That item needed to be on the help page. She didn’t like the navigation. After four iterations of the site, the developer had, in truth, been quite generous, he told her on their final meeting “I can’t do any more without more money.” Furious, and in front of his apartment neighbors she storms out of the building angrily and loudly pointing her finger at him and screaming at the top of her lungs “I’ll ruin you. You’ll NEVER to business in this town again!!! I’m reporting you to the Better Business Bureau and smearing your reputation online.”
What was the root of the problem? This sad but familiar story plays out over and over and over again. The customer says “Bring me a rock!” The developer answers “What kind of rock?” The customer says “I don’t know, but I’ll know it when I see it.” The customer was confident because she had a vague notion of what the site should be and had the subconscious notion that the end product is fairly obvious.
After all, to make an analogy, potato salad is potato salad, no? Not exactly, Aunt Bertha’s potato salad is fairly sweet while Uncle Harry’s potato salad is quite vinegary and contains carrots. Some people hate carrots. Some want just a little bit more sugar.
Four times, he had brought her a rock. Every time it did what she asked for, since she was not at all specific. Four times it wasn’t the one she vaguely envisioned in her mind. He lost money and might have to sue her if he wants to get paid. She didn’t get what she wanted. It was a “lose-lose” result.
He gave her what she asked for. And now it’s everybody’s problem.
More than you might imagine, businesses of all sizes have the same problem. It’s just that often the larger organizations settle their differences with their contractors with (slightly) greater decorum in court or arbitration rather than in an apartment lobby.
“Sorry, the site will be delayed six months”
I regularly read the blog of an online vendor who hired a developer to produce his next blog/sales site. It was gorgeous! He was ecstatic. He bragged to his readers for days how excited he was about it. He couldn’t wait to show it to the world next Tuesday after the long-awaited launch. He was, that is, until he tried to use the site, and found that the simplest things he wanted to do on that eye-candy site were maddeningly difficult. The site was appropriate and easy to use for what it was intended for in its prior incarnation when selling some other type of product. Unfortunately, that was NOT a good fit with what he needed. What was his next step? He started over. Here, the developer got paid. But the vendor wasted money, wasted time, wasted business opportunity and wound up with egg on his face.
Shouldn’t he have known about the problem sooner? Sure, but his requirements for navigability and user experience were absolutely unstated. They gave him what he asked for, and now it’s his problem.
It really doesn’t have to be that way.
Having no use for these type results, let’s talk about “requirements” and approaches to implementing them. No serious venture can safely ignore or give short shrift to requirements. Well, more properly, what we’re talking about here are meaningful, clear, appropriate requirements. They’re easier talked about and imagined than done. Let’s take a closer look. It might just save your next “project” from disaster.
But of course, this type of work is hard for lots of people and perhaps boring work for many if not most people. (When you find yourself getting discouraged about doing requirements, please re-read the previous paragraphs.) Success demands good requirements, and especially so if you haven’t worked with your developer or project manager for years and years so as to be “of one mind.”
This is information you can just put to use immediately. It all boils down to clearly stating just enough information up front, then monitoring the work as it evolves, rather than at the end.
Developing Your Requirements.
There was a time when even the smartest developers thought that you could design a system in excruciating detail before even beginning to build it. The Department of Defense did it. That sounded perfectly logical, but turned out to be terribly wrong for most systems. It turns out that you have to see some sort of implementation first in order to really start the creative juices flowing. If not, you spend great time and money developing system portions that are subsequently thrown out and are far more likely to have to build a second and third generation operational system before you get what you want.
So the trick is to develop only the barebones skeleton system, see how you like it, modify it, and then gradually add features as you go. A side benefit is that you can quit adding bells and whistles when you approach the limit of your funding or available time.
What Makes Good Requirements?
Nothing crystalizes thinking more than having to commit words to paper. However, writer’s block can set in, and you need to get a flow of words going. There’s much, much more to requirements writing, but if this is your first try, here are some tips. You can find many great books on requirements that take you further.
- Although it’s not easy, try to focus on what you want to do rather than how to do it. This leaves everything open to better ways to do things. That is, you may say you want customers to be able to cancel an order, but you don’t want to specify what buttons they’ll click. Your developers may know a much simpler (and easily implemented) solution than you have in mind initially.
- Start simple, and refine and add more features and capabilities and detail later. You will likely go through many versions before you’re done even though you may start development with earlier versions of your requirements.
- What do you want the users to do with the system? If you must, just start with the simplest thing. It’s important to get started. In requirements lingo, these parts of your requirements are often called “use cases” that describe step by step how the system performs from a given user’s viewpoint.
- Having written a basic set of requirements, discuss with someone other than the developer what they mean. You may be surprised at the different ways your words can be interpreted.
- For each requirement, ask yourself the following questions:
- Is it clear?
- Is it complete enough for now without getting too detailed? Remember, you’ll include more features later, but for now you’ve focused on the basics.
- Is it ambiguous in any way?
- Does any requirement contradict or conflict with any other requirement?
- If the delivered site or product does what it says, will you probably be happy?
- Would you like your site or product to be similar to, without copying, some other product or site?
- Have you made it clear what is part of your system and what is part of (or done by) an external system such as Amazon (and thus you shouldn’t pay for)?
Iterative Development.
Because you developed your requirements incrementally, you’ll find out very early how much that rock satisfies your basic vision, and differences can be easily and economically corrected in future tries.