Have you ever experienced a website development project that never seems to end? And I’m not talking about never ending because you are continually iterating in an agile manner. I’m talking about a project that never ends because of constant delays. How do we fix this? How do we take the ‘small’ project that takes over a year to go live and transform it so we can launch them within a timely manner?

The importance of following a process

A process, is a blueprint that details the steps that need to be taken to complete a specific objective. If you find that the websites you build for yourself or for your clients take forever to complete it is highly likely that your process (or lack of) is the problem.

Processes are important because they not only outline the steps that need to be taken, but clearly explain the most efficient way to complete a task. Your process for website development should be a living document in that you review it after each project to see how you could improve.

What process should I follow?

I’m going to run through the process I follow for building a website for a client. I have found that, when followed the website is completed in a fraction of the time compared to when it isn’t.

Process outline

1. Site map
2. Shared folder set up
3. Receive Content and other assets
4. Design
5. Development

Process breakdown

1. Site map

Create the site map for the website that outlines the structure of the build and all the content, pages and templates that are required.

2. Shared folder set up

Create a folder that matches the site map that’s been created and share this with the client.

3. Receive content and other assets

The clients fills the folder with the content for the website including any assets, adding them to the appropriate sub-folders.

It is agreed with the client that no other work will be completed until confirmation that all content has been added and approved is received.

Mutually agree a date when all content will be delivered and ensure both parties understand the impact of missing the deadline. Once approved the client agrees that the content will not change until the site is live.

4. Design

Design the pages using the assets and content that have been received for the site. This is much better than using Lorem Ipsum because you know that the content fits the design.

5. Development

The design is approved by the client, export any further design related assets and add them to the shared folder and complete the development of the site.

Each item is completed in order

This is a pretty standard outline of how a website build works what’s different is that I don’t mix the different steps in the process and I won’t move onto the next task until the previous one is complete. This is important because when you start muddying the waters by mixing the different elements of the process together it leads to confusion and rework.

If I build the design based on Lipsum and then receive content from the client that goes against the design then the design needs to be recreated to fit the new content. Yes you could ask your client to make sure that the content matches the design but that rarely works. Clients don’t necessarily understand why giving 500 words instead of 100 means the design won’t work. Not only that but content is the most important part of any website so it shouldn’t be restricted based on the design.

What about Agile?

Ahh yes agile, following an agile approach is great and being open to change is great. However, there is a mentality associated with agile that the ones building the thing understand. We know how change affects a project and often what will work and what won’t. Clients don’t often share this mentality and often don’t care about taking the time to learn and why should they? That’s the reason they’re paying someone else to build their a website.

The cost of change

Whether it’s the client that’s making changes or someone internally there is always a cost associated with change. There’s an overhead both in physical terms, e.g updating, redesigning, rebuilding but also in mental terms.

When change happens we have to keep track of what changes have happened and what the current version is. This is why developers use source control so they can remember not only what has changed but why. This mental overhead of having to track where you are up to is error prone and often leads to mistakes.

A lot of the time when I’m building a site I will add the initial set of content for the client to make sure everything is set up properly, can you imagine the amount of confusion involved when half the content changes one day, the other half changes the next and these changes are all shared via email. It’s a nightmare!

So yes I’m open to change, but change at logical points during the development process.

Communicate with clients

If a client wants to make a change outside of what has been pre-agreed then they can (again it’s their website) but clients need to understands the additional work that is involved and why this means delays and additional cost to them. This falls into the category of educating your clients so that they understand the parameters of the project, what is acceptable and what is not. If you don’t explain any of this to your client how can you expect them to follow the process? Or be accepting when you try to charge them more because they ‘made some final tweaks’ to the content the day before launch?

Summary

The approach I’ve outlined above is the approach I take to build any website and it works really well for me. Hopefully, it’ll work for you too. If not then tweak the process until you find what works for you. Make sure when you commit to a process you trust the process and stick with it for the duration of the project. Remember this, if you change your process half way through a project your not following the process at all!