Skip the Requirements – 10 Problems With Web Development Projects, and How to Solve Them

Did you notice? The world's a different place. Rules for doing business have changed-there's new ways of getting hired, finding employees, reaching new customers, and (shudder) for them to reach you. Economies of scale have flipped-it's getting more expensive to do things on a huge scale, and far cheaper to do them at a micro scale. Mass market items have lost their appeal, and people yearn for authentic, individual connections in a world of franchise same-ness.

As customers, we want it all. We want to know what your products are, how much they cost, and what benefit we get from purchasing them. We want to know what others have experienced, we may go see what people are saying about you on Facebook, Google, or Twitter, or Yelp, or any of a thousand other sites. Oh yeah, and we don't want to pay more, either. Are you listening?

We've been listening to our clients, and have a created a whole new way of helping them succeed on the web. And we've had a bit of an epiphany by doing so-web development has been broken for quite a while! It's a wonder any sites get done at all. Here are 10 problems with the way web projects are typically done. We've experienced all of these problems, but more importantly, we've figured out how to solve them.

Problem 1: Everybody wants to know what it's going to cost.

The way we used to work, we couldn't tell you what any given project would cost. One part of the problem is that we don't know what you want to buy, or how much detail work would be necessary before declaring victory and calling the project complete.

Solution 1: Agree to a budget up front.

We can tell you if a budget is reasonable for what you're trying to accomplish. If it's tight, we can help you prioritize features, and make sure the critical ones are done first before the budget is exhausted.

Problem 2: Requirements aren't clearly defined.

If you've hired a company for web work in the past 15 years, you've probably learned that you need to be extremely specific and detailed about what the finished site needs to look like, and how it needs to operate. The overall cost of the project can change substantially based on seemingly minor requirements that end up making some existing platform a bad choice.

Problem 3: Requirements need to change for business reasons.

You get part way through a new web site project, and realize the requirements overlooked some critical feature you really need, or didn't specify clearly enough something about the source data. Now all work comes screeching to a halt as the developer needs to renegotiate the contract, add a change order. The customer is unhappy because they're paying more, and the project is late. The developer is unhappy about having to stop what he's doing and talk business-so all too often we'd just throw in the work without doing this, and then have trouble paying our bills.

Problem 4: Requirements prevent changing to a more suitable solution.

We get part way through building a site, and realize that if we had chosen a different approach or platform, the end result would work much better for the client. But we're far enough down the path of the current development to back up, and our original approach does fulfill the requirement. We're unhappy delivering a site that could be better, and our customers end up with a clunkier, less than optimal site-but it's easier than going back and renegotiating with the client.

Solution 2, 3, 4: Scrap the requirements.

Requirements serve one purpose: they are a stake in the ground that one side can use to extract more work or more cash out of the other side. This almost always generates resentment, and they're also largely unnecessary for small web projects.

Don't get me wrong-it's important to have a clear agreement about what is being purchased, and what is being delivered. The problem is, there are a ton of variables, and many of them are not discovered until the project is well underway. Doing the groundwork to identify all the possible pitfalls of a project is probably about half the actual work of a project-and in most cases, that's far more of an investment than the client wants to make without an actual result. We've done a number of "discovery projects," of this nature, and almost always put far more into the discovery than we planned-if we don't win the rest of the project, we lose money. Which means we need to charge our paying clients enough to cover that, making it more expensive all around.

Instead of having hard and fast requirements, we help our customers identify goals and rank them by priority. We start with a previously-finished configuration, and use the budget to modify that configuration towards the goals.

Problem 5: It takes FOREVER to launch the new site.

Once you've decided to create a new web site, identified the requirements, gotten the vendor all lined up and started, something funny happens. The developer... disappears. Off the face of the planet. You, as the customer, have no idea what happened. Two or three weeks later, you decide to call, and they've done part of it-but had other clients asking for work and so they haven't gotten to it yet. Two months later, they've gotten close, and there is something to look at, but it still needs a lot of polish. So the hard-core back-and-forth starts happening-and then the requirements document starts getting in the way. Four months down the road, you're starting to work on content. A year down the road, there's a little push of effort, and the site launches-but nobody's really that happy about it. The developers have forgotten about all the cool little tricks they employed to make your site do something slick, and you're tired of thinking about it... it's a relief to launch, but little more.

Leave a Reply

Your email address will not be published. Required fields are marked *