10 Reasons Why Web Projects Fail

by Freelance, Web Design

I often wonder why so many of our clients come to us after their Web Projects fail. About 75% of our business comes from projects where someone else couldn’t get the job done. The most common situation is what I call the “Money Pit”. That’s where the developer keeps telling the client its almost done and they never get there.

Today every project uses some sort of Content Management System framework. Instead of painting a canvas in the old days of HTML, we are building software applications that need to follow more traditional development approaches. If the project is coded improperly, then often times you have to throw it away and start over. The cost to fix all of these problems can be significant.

I thought I would share the most common reasons we have seen throughout the years that make so many projects fail.

1. The “Freelance Syndrome”: Unqualified developers; using your marketing firm, friend/neighbor, hiring your own or going offshore

You want to build this incredible website that will automate your business and benefit from the wonderful opportunities the Internet provides. Everyone is telling you they can do it for you and they all sound the same. The problem is most of the people you are talking to aren’t qualified to do the job. Most Marketing Agencies are incredible at building your brand, but do they have the people in-house to build your web application?

Make sure they’re not outsourcing your project to freelancers or even worse, overseas. Visit or speak with the actual people building your website and look at their work. Speak with references. Look out for the bait and switch. Have they done projects of similar complexity? Doing business with friends and neighbors doesn’t make sense. Hiring developers in-house could get you a jack-of-all-trades and a master-of-none. Multiple people with specialization of different disciplines is required to build today’s websites. In-house resources are better suited once the project is launched. Your developer can then support in-house resources on an as needed basis saving you money.

2. Jumping the Gun: Lack of a clear definition of the scope and requirements

Everyone is so anxious to get going and they think they know where they are going. But they don’t think about how it’s going to work and what happens under different scenarios. This is especially true when a company puts their business online. How will this new process affect your business? Most clients think they know what they want, but the devil is in the details. I can’t tell you how many clients we meet with that when pressed to detail their process, haven’t thought through all of the ramifications. Make sure you go through a detailed planning exercise before you start building. Make sure building something that your customers want and need, not just what you want. Get input from customers.

3. Lost Leadership. Lack of Stakeholder buy in and involvement

Management wants a new website to meet corporate objectives and to increase its ROI. Then management doesn’t take the time to get involved when key decisions are being made. Huge problems can arise when management tests the Beta version and finds it’s not what they originally wanted. Some of the best projects we have developed are those in which executive management was actively involved from the beginning. Changes can be very expensive in time and money if made at the end of a project instead of the beginning.

4. The “Facebook Syndrome” Biting off more than you can chew

Be careful not to bite off more than you can chew. Rome wasn’t built in a day. If you have a really complex project, do it in phases. You don’t have to publish it all on the web at once. There is nothing wrong with replacing your existing website after three or four phases are completed.

5. Putting the Design First: Designing without purpose or function

We have seen some absolutely beautiful designs for new projects that just cannot be built or would be too expensive to build. It’s best to wireframe out all of the functionality taking into account the platform you’re using before the design is done. Then have your development team work with the designer, so together they come up with something that is beautiful and functional. Otherwise you could come up with a Frankenstein site that is neither.

6. Uncontrolled Code: Not using a Version Control Program

It’s unfathomable today to build a new website without some sort of source code control system. We use GIT or SVN. When developers create, support, and update source code files for a large application, the coordination can be complex. Source-control systems record all file changes, with comments, in a project. You need to have the ability to roll back functionality, merge work together and work off line. Proper source code control is vital for any project.

7. Uncontrolled Developers: Lack of good Project Management

The Project Manager (PM) is the Quarterback of your football team. The PM is responsible for the successful planning, execution, monitoring, control and closure of a project. The PM needs to understand the client’s needs and provide communication to and from the developers. Without a proficient PM, the project will get off track and become a run away train that ends up in disaster. A good PM will publish weekly progress reports keeping everything on track.

8. Trying to Reinvent the Wheel: Hacking Core or Source Code

Hacking is changing the source code structure. We always believe in K.I.S.S, Keep it short and simple. When an unqualified developer doesn’t know how to do something, they tend to hack the code to make it do it. This causes a number of problems and greatly affects quality. If your developer fixes one problem and another arises, it may be the result of a lot of hacks.

Doing so will make it near impossible for site updates due to Security and bug fixes. It also makes it difficult for those that come in after to maintain the site and could possibly leave your site vulnerable to exploits. We have a tool we run that uncovers all of the Hacks for our customers who come to us in trouble. Then we show them the results and why their website doesn’t work.

9. Getting Off Track: Scope Creep

This happens a lot. A good PM’s main job is to keep things on track. It’s natural as you go through the development, to come up with new ideas and things you want. You need to realize that every time you make a change, it adds to the time and cost of your project. Changes late within the process have large affects. If a website is built and tested, you will have to retest after the change. Some changes are beneficial, especially if they make the website better for your users. But lots of indecision and changing can derail a project. Scope Creep happens when decision makers aren’t involved early on or the project didn’t go through proper planning.

10. No Functionality Testing: Lack of cohesive Quality Assurance

It’s important to unit test each piece of functionality and then do regression testing on the final product. All projects have bugs, so it’s better to have the developers find the problems instead of your users. We usually set aside 20% to 25% of the development time to perform proper QA. Make sure there is a comprehensive QA Plan, otherwise you could get a website that has a lot of issues. Developers need to be thinking about quality from day one and be responsible to fix their problems. Otherwise it could get very sloppy.

Conclusion

Building a successful website requires all ten of these areas to be properly addressed. Failure to perform any of these tasks could derail a project which ends up being completely wasted money in the budget. When you select a developer make sure they can address all of these before you start. Properly done projects can be a tremendous asset to the wellbeing of your company.

You may also like…

Ode To a Wooden Spoon – How The Right Tool Can Help You Design Better →
10 Things Designers Can Learn From Pastry Chefs →
Apple Pie Appeal: How Simple, Classic Design Works →
Repeat Work and the Search For The Holy Grail →
Thoughts and Considerations for Freelancing on a Part-Time Basis →
Is Working Freelance Really Worth It? Pros and Cons →
Tips for Converting Your Freelance Operation into a Business →
Thoughts on why Spec Work is Bad and Why You Shouldn’t Do It →
Technostress – The Freelancers Disease? →

Author: (1 Posts)

Ben Bassi, founder and CEO of CommonPlaces, is a seasoned Internet veteran and marketing executive. CommonPlaces an NH based web developer and digital marketing agency has also been listed on the Inc 500. It is responsible for large scale sites such as Waste Management's Greenopolis, as well as being involved in SixDegrees.com, a precursor to LinkedIn.com.

  • Sarah Bauer

    I like the second and third points here because these are areas of dysfunction that can be detected pretty early on in the development process, if you’re aware of them. Planning/strategizing in complete agreement of what is expected from both sides ( client and designer) is key before going ahead with production.

    Cheers!
    Sarah Bauer
    Navigator Multimedia

  • haze

    Nice view on recognizable matters!

    That tool for checking for custom hacks… is it a specific third party tool or is it something you developed yourself?

  • http://twitter.com/robinow Robin Wong

    Interesting article, I would also build on a few ideas

    3. Team cohesion and trust are key to making good decisions. Ensuring that your team agree on a common set of objectives is vital if you all want to pull in the same direction. Having a good producer/project manager to coach people to do the right thing is important, as is having regular discussions to review your common goals, how you work together and the actions you need to take to get the work done and also work more effectively together

    10. QA is something that can’t be underestimated, but ALWAYS is. Fight hard for this time, and make sure that you build acceptance testing plans into your thinking form the start. Otherwise how do you know when you’re finished. I’ve found a good technique here is to plan acceptance tests around End User behaviours. If the majority of people can do something with your system and have a positive experience, it doesn’t matter how they’ve done it or what platform or technology or social network they’ve used. The job has been done.

    but I think I disagree at least in part with a few of your comments
    1. Whilst there are some out there who have clearly earned the title of “Dirty Freelancer”, there are many that are fantastic, and I would even go so far as to say that most of the very best and professional designers and developers in the world are freelancers or work for themselves. I’ve been lucky enough to work with a lot of proactive and talented people who are freelancers. The key here is to get good references from people you know. Word of mouth beats CVs any day
    2. Scope can often be confused with the idea of coming up with what seems like a brilliant idea and then creating and sticking to a plan formulated 6 months before a project is completed where half the problems you end up encountering are not foreseen. Scope should not necessarily cover features, but it should try and explain the behaviours and activities you want to be able to perform at the end of the project. This then means that you have scope to be flexible with how you interpret how those behaviours can be designed and developed for, which you touch on in point 5
    7. A Good PM is important, but there are lots of ways for a PM to work depending on a project. In some cases, especially ones where complex and creative ideas need to be balanced, I’ve found a producer – who gets more hands on with the work rather than just producing reports and checking spreadsheets – can add a lot into a project because they feel they own the work as much as any creatives, designers and developers.
    But overall, a good thought provoking article, thanks.

  • Inspektr

    Great points Ben. I think that what most clients underestimate the amount of effort their projects require. This leads to bargain shopping for the best “deals” on builds. What clients don’t understand is that a great developer is not going to give them a “deal” because they know their skills are worth more than the client is comfortable paying. Cheap developers are generally cheap because they lack motivation, confidence and skills. Another point is that a good developer who ends up settling for a low balling client is going to end up doing a half-ass job. They’ll take on additional clients to support themselves and have constant complaints about their unfinished/unsatisfactory work.

    Anyways, thats my 2 cents.

    Thanks for the great post!