Why bad web projects happen to good people


It starts off wonderfully. Everyone’s excited about the new website, and eager to get the project started. Meetings are full of big dreams, friendly banter, intense brainstorming, and poking fun at the old site. The client shares their vision, the design team brings their experience in, and it all seems like it’s going to go great.

And then it doesn’t.

We frequently hear the horror stories from clients who come to us to rescue their project, and we’ve certainly had a few failed projects ourselves. So we wrote this for anyone considering taking on a new web design or development project, to help you spot some of the most common pitfalls before you, well, fall into the pits.

1. Inadequate budget.

A few years ago, we bid on a project with a set budget. We didn’t win the job. A couple years later, the same client came back to us unhappy with how that project had turned out. The site launched, but there were still a lot of problems—elements missing, broken, not working quite right. They hired us to audit the site and try to help them figure out what had gone wrong, and whether the code base was stable and maintainable.

Once we took in the sheer complexity of the site’s functionality, and reminded ourselves what the initial budget had been, we quickly figured out that it just wasn’t enough. We know the firm who worked on the project to be talented developers, and the code base reflected that. But we also know what happens when the budget is too tight—agencies look for ways to cut corners and get things done “just well enough” so that they don’t hemorrhage money or neglect other clients.

How to prevent

Sharing a budget can be helpful for the firms you’re talking to, so they can have a sense of whether it’s in their range or not. But when sharing an intended budget, also invite feedback about whether it’s realistic. If enough firms say no, that means you should revisit it. Is there functionality you could cut or defer for now? Can you get more funds?

If it happens to you

On any project, it’s natural for unforeseen needs to arise that affect the project scope. If you ask for a feature (that’s not explicitly stated in the proposal) and your developer says they can’t do it within budget, believe them. Work together to find an alternative. It’s not in your best interest to insist on the work being done no matter what. You don’t want your development firm to even think about where they might skimp. It's better to get less done, but get it done right.

We are totally taking this down if Fox sends us a cease and desist notice.

2. Lack of clear specifications

You wouldn’t start building a house without some blueprints, and the same is true of a website. In our case, “blueprints” can be a lot of different things—they can include a site map, wireframe diagrams, an interactive prototype, use cases, a list of technical specifications, business requirements, or typically some combination. In short, the agency should be able to give you some written evidence that says, “we understand what you need.” If the blueprints don’t look right to you, they should be revised until they do.

How to prevent

Before hiring a firm, ask what the blueprints look like for them, given their project methodology of choice. Have them tell you about their process, and share a few deliverables from past projects. If there’s any part of their process you don’t understand, ask questions until you do.

If it happens to you

During the project, look for these blueprints. If you don’t get them and aren’t sure that the team fully grasps your needs, or if you’re wondering when or how a need will be addressed, ask. If the answer is something vague, like “Oh, don’t worry about that now, we’ll figure that out along the way,” be nervous. If vagueness persists, you might be best off cutting your losses rather than continuing to invest in the process.

3. A point person with no real authority.

We’ve had a few cases where a project didn’t go as smoothly as it could, and took longer to launch than expected, just because our point person on the client side didn’t have any real decision-making authority. Instead of being able to say yes or no to our proposed solutions, they always had to run back to their web committee, or their executive director, or their VP of Communications, or whoever, to get approval. Web design by committee can be done, but it slows things down. A lot.

All in favor of beveled buttons?

How to prevent

Choose a point person to manage the project on your side who has real authority to make decisions. This person is responsible for collecting feedback from various stakeholders and making sure everyone is heard, but at the end of the day s/he is going to have to make judgment calls about what’s best for the project, for your users, and for your stated goals. Make sure everybody trusts that person to make good decisions. Then trust that person.

We’ve also seen the process go fine with 2 or even 3 project managers. The key is that they work well together and present a unified front to the agency.

If it happens to you

If you’re the person who doesn’t have enough authority, ask for it and try to get it. If you see that the project manager for your project doesn’t have the trust of all stakeholders, try to find somebody who does. Or, be content to get your project done more slowly.

4. Administering the site is an afterthought.

A few years ago, we had a client come to us after their Drupal site was built by another firm. They loved the design and how the site worked, but it was a nightmare for their staff to manage. They had to use tools that they called “The Yellow Screen of Death,” and “The Scary Blue Screen.” When we saw what they were referring to, we were aghast too. There are inner workings of Drupal that no content manager should be subjected to.

What your website’s administrative interface should NOT look like.

To make matters worse, they hadn’t received any documentation or a formal training session. So even though their site was outwardly a success, the burden it added to people's day-to-day work made it a failure.

How to prevent

Ask for a demo of the back-end interface of some sites the firm has built. If it looks hard to use, it probably is. Ask for some sample documentation and whether training is included. Ask what happens if you forget how to do something or need help—is there support time built in?

If it happens to you

Like our client did, get a second opinion before you decide Drupal (or whatever platform you're using) is just “too hard” and you should scrap it. There’s a lot that can be done to customize the user interface of an otherwise well-built site—in fact, we wrote an article on making Drupal user-friendly. At other times, a little training or documentation is all you need.

Remember, you are not alone.

Web projects are expensive and time-consuming. They require a big investment from everybody on your team, and the stakes are high. We hope your organization never experiences a major web disaster, but if you’ve had one, or fear you’re in the middle of one, reach out to us. We may be able to help salvage the investment you’ve already made through a site audit, user testing, documentation, training, fixing up your Drupal interface, or some combination thereof. Or maybe you just need a second opinion on how the project is going, and some ideas about how to get it back on track.

Share the Love