6 reasons why some websites never go live

Written by: Peter Fisher on November 13, 2016
Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Share on RedditEmail this to someone

Why some project never go live
Today we are going to take a look at why some web development projects never go live. The fault can fall on both the client and developer.  In the end you may not remember when the first crack in the project appeared and when the tipping point occurred.

Websomatic has often been hired to pick up the pieces of a fallen projects. Some projects only need an extra boost of energy to get them past the last hurdle.  Other projects require a more delicate and ground up approach.  Over the years Websomatic has become aware of the common reasons why some projects never go live.

We thought we would share 6 of these reasons with you.

  1. To many cooks in the kitchen
  2. Scope creep, feature creep and requirement creep
  3. Lack of budget
  4. The design was late
  5. The wrong technology was used
  6. Big Bang Builds

1# Too many cooks in the kitchen

Too Many Cooks In The KitchenThis is quite a common issue and it especially happens when the project is managed by a committee.

Lets say it takes 5 people to a decide on the projects spec. The deadline has already been set,  the budget is agreed but the spec is still maturing. Issues often occur when some of the deciding members are away when the spec is still being developed. When these members return they may have other ideas which they wish to add.  Often they will say.  “Whilst I was away, I was thinking about X and I reckon it should be done differently”.

In some cases these changes are valid and should be done.  However the time it takes to have the necessary meetings, change the spec and agree it all with the developer is often never put back into the project. This may result in the project being delayed or dropped if these changes become frequent.

If the developer is not made aware of an imminent change then there is a danger that time is being wasted implementing the previous version of the spec. In some cases the features that have already been developed may need to be unpicked.

Sometimes this can take longer than actually building the new version in the first place and if this happens then time has been wasted on three fronts:

  1. The time taken to develop the first version of that feature
  2. The time spent unpicking that feature
  3. Extra time consumed by adding the change

How to solve this

A small number of committee members should take ownership of the project including its requirements and specifications.  These people need to work closely with the web developer to understand the technical implications and be aware that alterations to development will cost time and money.

The web developer must also understand the projects ‘big picture’. The developer should be aware of future use cases and project requirements.  However any future requirements must be agreed as future web development.  A line must be drawn between new development and current development. This will address what is being developed this week and what is planned for the next.

At the end of the day this boils down to communication and a mutual understanding of where the project is headed.


2# Scope creep, feature creep and requirement creep

Feature CreepA very common reason why websites go over budget and miss their deadline is scope creep. The cause of scope creep is usually due to loose project specifications. If a project spec doesn’t define exactly how the project should perform or how it should be designed then it its features are open for miss interpretation. This doesn’t mean that a project requirement document (PRD) should be the size of a novel but there should be a clear set of rules for the web designer and web developer to follow.

Obviously a project will change change during the development process. Normally the final result isn’t a carbon copy of the original PRD or design. Often certain factors can get in the way such as technical issues, budget restrictions or simply a change of idea. These things can mean that certain parts of the project will be done differently to what was originally outlined.  These changes are often discussed over the phone or via conference.  Sometimes these alterations are never written down or fully defined. If this is the case then the project is in danger of getting even more scope creep as assumptions will be made.

How to solve this

Scope creep is not actually a bad thing. It is a sign that the project is evolving whilst it is being developed. However scope creep will quickly turn into a bad smell if it isn’t managed properly.

The key here is to be aware when scope creep comes into to play and to manage it as soon as it happens.  Developers need to be honest when they feel like new scope is being added to the project. They must communicate their concerns in a professional manner. The best case scenario is to turn scope creep into a future project requirement or future project phase. When a developer spots that the scope is changing they must say how long the change will take, any cost implcations and how it may impact the rest of the project. It is then up to the client to asses the recommendations of the developer and decide if they wish to proceed. Once that happens both the client and the developer will have an agreed understanding of what needs to change.


3# Lack of budget

Lack of budgetA project can run out of budget for a number of reasons. These are just some:

  • The client has external financial requirements
  • Scope creep has caused the project to blow its budget
  • The developer may demand to much for too little
  • Unexpected costs that relate to the project

The worst case scenario is that all communication breaks down due to budget cuts. This leaves the developer or designer unsure of the projects state.

How to solve this

Sometimes unexpected things happen which impact the budget and thus prevent the website from being completed. Sometimes these cannot be avoided. However it is possible to keep on top of a projects budget and web developers time. The web developer must be honest and as accurate as they can when quoting. They must also keep the client informed when changes to the project impact delivery time and cost.  Again this boils down to communication for both parties. Tools such as Trello, Google Sheets or Jira can be used to allow the developer and client to see the state of the project.


4# The design was late

The design was lateOften Websomatic is given a design to implement. This could be anything from a WordPress website that is to be converted into a WordPress theme. A mockup of a mobile application. Or a story board of a brochure website. Normally Websomatic is involved from the start of the design process and can feed in technical knowledge when needed. After the graphic designers have finished with the design it is then given to Websomatic to develop. In some cases the development process is rushed as not enough time has been given to the design process. This can also lead to hardly any time for testing or alterations.

How to solve this

Websomatic has found that the best approach is to develop the website at the same time as it is being designed.  A few development quick wins can be achieved in the early stages of the design process.

These are just some of the things Websomatic can do while the websites design is being finalised:

  • Hosting environment is setup
  • Email is setup
  • Testing, QA, UAT staging environments are setup
  • Development workflow and phasing is agreed
  • Website domain is registered
  • Database is setup
  • Basic website structure is setup
  • Prototyping and mockups can be built

By working on the above items during the design stage the web developer can get a better understanding of how the data hangs together before actually using the agreed design. This has worked very well in the past as it helps to get the website up and running quickly.


5# The wrong technology was used

The wrong technology stackThis is a very common issue that Websomatic has faced.  We have often gone into places were the technology used is actually becoming detrimental to the build process. The developers cringe when new features are required as the technology stack that is used is totally wrong.  Its like trying to turn a car into bus. They can both be used on the road but a car cannot scale to the size of a bus.

Usually the conversations start like this. “We hired a developer who was certified in X so they developed it in X”

Examples of the wrong technology could be the framework that used to build the website or the services that are used to implement certain features.

How to solve this

Unfortunately there no easy solution to this one. Both the client and developer need to accept that the technology stack is wrong and start planning to migrate to a better alternative. Depending on the size of the project this can be tricky. Tough decisions need to be made by the project manager which will affect future development. However continuing to develop on the wrong technology stack will make the problem worse.

Websomatic has knowledge in many frameworks and web technologies. Yes, we have our preferences but we will not push a technology onto a client unless we feel that it is correct for your project. For example if your project only requires a blog or brochure website then there is no point using a framework specifically tailored for e-Commerce.


6# Big Bang Builds

Projects sometimes never go live due to Big Bang Builds This is when a client only wants to push the project live when everything is completed. Every last detail must be finished, every feature must be implemented and no bugs (No matter how trivial) are found in the system.  Usually a client will say ‘Just one more alteration’ serval times and in the end the project never goes live. When this happens days can quickly turn into weeks and budgets can be easily blown. Ultimately the project will never go live until the client is happy and in this case the client is never happy.  Big Bang Builds and scope creep often go hand in hand which can lead to frustration.

How to solve this

This is relatively easy to keep on top of. All the client and developer need to do is agree on phased development apparoch. The client must understand that a website is never finished and can always be improved upon. The developer and the client must agree on a minimum set of requirements for launch.  In the web development world we term this as ‘Just Enough’ development for each phase.

A backlog of issues can be used to store ‘nice to have’ future features and trivial issues which are not show stoppers. After launch these issues can be assessed and split into phases of future development.

Websomatic can turn a dead website into a live business plan.

Sometimes all it takes in a neutral and external source to come in a see what can be done to fix the website and get it to an acceptable state. Websomatic can consult on how best to get you web or mobile application back on track.

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Share on RedditEmail this to someone

Peter Fisher is a UK based freelance web developer and cross platform mobile applications developer. He has a degree in E-Commerce and Multimedia and has worked for many web design agencies and hosting companies.

Peter has his own web and mobile development blog and is the host of the HowToCodeWell YouTube channel.

Read more about Peter Fisher

  • Related Articles

  • Ready to start your project?