Over the last seven years, I have been involved in hundreds of website projects.
I've worked with a ton of different clients on various types and sizes. From design/branding projects all the way to sophisticated web applications. From a couple of thousand dollars to hundreds of thousands of dollars.
While working on these projects, I noticed that whenever a project started to go sideways, I can trace back the timeline to a single point, or a single reason, where the pain began to manifest.
So, here are the top 3 reasons (in my opinion) that will cause a website project to fall apart.
3. Confusion Around Responsibilities
Now, this may sound vague, and you can probably assign all these reasons below to this category - but - let me lay out some sub-reasons that will break this down a little better.
Technical Misunderstandings
Who owns the domain? Who owns the hosting? Where is the email managed? Which company (yours or mine) pays the hosting bill? How do updates work? What about maintenance?
All these questions fall under this sub-reason of responsibilities. These are vital points that need to be answered before a project starts. In my experience, these issues tend to arise when you have a client that has no experience with online projects or lacks a general understanding of how a website hierarchy works. They probably don't understand how a domain works or how their email is setup.
These are usually non-issues if you are working with a client that has a technical team in place for any existing web properties.
For me, these issues tend to become quite a pain as hosting can stop a project in its tracks. Without a place to put the site, we cannot finish. Same rules apply to a domain. Without one, we cannot continue.
For email, it is typical for a website to have a contact form of some sort or maybe they have a public email listed in the footer or on a contact page. Finding out that the email doesn't exist or that the access to that email is lost, will crush a client and make you seem completely incompetent.
Finding out that the email doesn't exist or that the access to that email is lost, will crush a client and make you seem completely incompetent.
You may say that you "don't control the email" or "it is managed with the hosting company". You can even say "they already had a hosting company when they came to us".
The problem is that the client doesn't usually care about the reason why the problem occurred. Even if you can say, it is their fault. They care that you let it slip by and the fact that it became an issue at all. It means you missed something.
Assumptions
A lot of project managers will encounter this one.
The client believes that there are a certain number of things that "should just be included". They will never vocalise or acknowledge these things until they come up. I call these "Oh, By The Way" moments. Mainly, they will say they forgot something, or they will slide something in last minute under the veil of it being obvious or assumed it would be included.
One of the most common ones that I have seen fall under this umbrella would be things like setting up email for a new domain, providing hosting (for free or not), and on-going support.
You should make a list of items that you find people believe will be included and make those deliverables explicitly included or not.
I suggest having a section in your scope of work (S.O.W) for "included items" and "excluded items". Be sure to walk through these things with the client. If they point out something that they don't agree with, then that is the perfect time to discuss it. Don't assume anything.
Be sure to walk through these things with the client. If they point out something that they don't agree with, then that is the perfect time to discuss it
The includes/excludes discussion can sometimes be painful and even uncomfortable. Especially if you have a client that is already sensitive to budget. You are pointing out all the things they are not getting. Depending on the size of the list, it can easily be longer than the list of deliverables.
2. Arbitrary deadlines
This one kills me. Always question deadlines. A time limit must be tied to a real-world (physical event or the business opening) reason. Do not make deadlines because you think you will be done at a particular time or just because someone asks you to set a date for when it will be done.
Also, be wary of a deadline that is tied to an item that can be easily moved. I once had a client who wanted their website done in time for a newsletter. Just a newsletter. It wasn't an annual report or anything, just a general newsletter. And guess what? They moved the date back at least three times.
Also, be wary of a deadline that is tied to an item that can be easily moved.
We rushed to get it done for the initial date, but the date passed, and there were no consequences. Instead, we just waited and waited to go live. Eventually, they managed to get their newsletter done, and we went live. But it was three weeks later. We could have used that time for something else other than just waiting.
When a future date becomes established, the pressure is on. It can be a great milestone moment when you hit a deadline (early or right on). But it can become a real challenge when the client cannot hold up their end of the deal. Whether that is paying on time, providing information (logins, hosting access, domain details, etc.) or attending important meetings/status updates. The project requires both parties to be on the ball and bringing their A-game all the time.
The project requires both parties to be on the ball and bringing their A-game all the time.
The only caveat here is if you charge for time. Then you have to set a deadline or discuss the monthly/hourly cost. But in the billable-time scenario, the only person that is watching and monitoring time is the client. They become the advocate for speed and efficiency. You just work away until the budget runs out or the project becomes finalised.
Everyone understands that concept of cutting corners. When you promised to get something done at a particular time and things didn't quite move as quickly as you would have hoped, or you encountered some friction with a piece of the project, you rush. You reduce certain things to their bare essentials or you slash hours in one area to compensate in another. You miss things (remember the email section?), and then you fall behind.
Another downside to this is that if there are delays for either party or just general hiccups, the problem becomes compounded. Now both sides are rushing since one side held up the other. This is not a great place to be.
A general rule to follow is to establish the deadline on when the client will be satisfied with the project and within a timeframe that you know you can deliver. That could mean 100%, or that could mean 75%. Either way, do it right and don't rush because of some misplaced trust in "setting deadlines" or having an obvious "finish" date in mind.
1. Content
Content is by far the biggest culprit for project failures. Who is generating the content? Who enters the content? What happens if it is missing or incomplete? What if the content isn't ready in time? How does the blog look if we have no posts? When are we replacing the placeholder images?
All these questions should, again, be answered before the project starts. I have never encountered so much anxiety and frustration when talking to a client about content. These feelings come from both sides.
Often, they believe they can write the content themselves. That can sometimes be the case. But it is a lot more complicated than people understand. Unless you have a marketing team or have an experienced copy writer, do not rely on the word of the client that the content will be done on time and in perfect format.
Imagine the first thing a potential client sees on your site is mistakes, placeholder copy, or missing/broken links. That would not be a great first impression.
Another concern when it comes to content is that there are a lot of people out there that do not want to pay someone to write their content. I have no idea where this mindset comes from. But you can see it in the result. When people describe their own business, it is often too verbose, too deep, and littered with industry speak. Sometimes that is great (looking at you, lawyers!) but it usually makes the site difficult to read and will affect the performance of the site in search rankings.
The solution is to hire a copy writer or at least hire someone to run through the content after you believe it to be complete. Not only will you have the peace of mind that it is correct (both grammatically and in the communication sense) but you can publish it without getting an email the day of the launch where someone points out errors in your site.
Imagine the first thing a potential client sees on your site is mistakes, placeholder copy, or missing/broken links. That would not be a great first impression.
Conclusion
The pattern here is that discovery is your friend. What is a discovery? Discovery is a service (paid or included/unpaid) that will take an inventory and assessment of the client, the project, the business, the competitors, and the target industry for that project.
Even a simple checklist or survey can act as a project discovery. You can ask the questions about email and hosting, content, timelines or deadlines, and the holy grail: budget.
I don’t know how many times I have said, "we should have found this in discovery" when lamenting the fact that we rushed to start a project and skipped some of the upfront due diligence.
If you are a client, and you are reading this to educate yourself, then hear this: a discovery will save you money. Why? Well, you can reduce timeline (get ahead of problems), understand your role and the required tasks for you and your team, and accept or deny any recommendations from the service provider before its too late.
How about just generally auditing the competence of the people who are about to become entangled with you and your business for months or possibly years?
If that doesn't sound like a good idea, then I don’t know what is.
