Over the years I've been involved in hundreds of website projects, most of which have been built on some sort of content management system. I’ve used open source software, proprietary software and a fair number of custom built CMS’. Each one has its advantages and disadvantages, but overall CM projects tend to suffer in the same areas.
This post is designed to highlight these areas and help our clients and visitors to our site detect and avoid these situations.
Requirements and planning
Every project should start with a clear set of business requirements. This seems like a completely obvious statement, and yet I deal with prospective clients on a monthly basis who want “something like facebook with youtube” and have no idea why.
Make your business objectives SMART and get them agreed by the stakeholders of the project. See the roles and responsibilities section below for a definition of stakeholders. Get the stakeholders involved in the process early so you don’t miss vital user feedback or insight from the CMS vendor.
Too many times we have been handed a spec produced by a creative/marketing company that doesn’t use the more advanced features of the CMS product like personalisation or behavioural targeting, simply because they are not familiar with it.
Set performance indicators for the goals so you can actively measure how well the site or project is performing. This is often as easy as setting up Google Analytics and some conversion metrics.
A lack of stakeholders or poor business objectives inevitably leads to a skewed information architecture and meta data structure, making it difficult to enter content, find content, cross relate content and generally navigate the site.
Time and costs
Once the requirements have been “captured”, the client is always keen to receive timelines and costs for the project. The danger here is that the project is viewed as a single entity that has a finite cost and time period. This is almost never the case.
Websites are living breathing systems that need constant monitoring and adjustments to get optimal performance. This is true not only when running them but also during the build. It’s all too easy to be drawn into launching 100% of your requirements in one shot. Release a big four month build with a hefty price tag that will solve all your business problems. The problem is, within those four months the requirements will have changed slightly, not only from external sources but from your internal users. As you build a project and the users start to enter content and get trained on the system, there is always a set of requirements that come out of the woodwork that need catering for.
It far better in my experience to launch something smaller as a phase 1, get the core platform and functionality up and running. Bed in the site and the system and gather those initial user features that have been missed and release a small phase 1.1. Then start releasing further functionality in smaller faster phases which can be user centred by using systems like Get Satisfaction or Zendesk.
At the same time, you don’t want to release too little in phase 1 as you need enough basic functionality on the site to attract and retain users.
Another possible pitfall to look out for is having too many companies working on the phase 1 launch of a site. The more companies you have in the mix, the harder it is to communicate, build and test the functionality. In the past we have integrated with up to three separate news feeds from different providers and have had problems with delivery and quality of data. Analysing problems between three of four companies can be painful.
Content
Quite often the client will beat us down on timelines to try and launch a large phase 1 in less time, only to find they don’t have the time themselves to create and enter the content. This tends to be the biggest area of over run on a project. Do not under estimate the amount of time it takes to write good content.
Many clients think they have all the content from their existing site, but haven’t actually checked to see if it meets the new information architecture, or is in line with the new brand or SEO requirements.
Even if the old content is good enough for the new site, its generally quite painful to export the old content into a standard format and import it into the new site.
If you are writing all new content, make sure you have a plan for who is writing it, proofing it, in what tools and format, and by what date. I remember one year we built the annual report site for Amnesty International and the content arrived from all over the world, in different languages, in five different formats, days before the launch. Trying to proof read Arabic content that’s been pasted in from Quark, In Design, Word and PDF at 3am is not amusing.
Also decide on how much power you want to give your users. Too many times we have allowed authors too much creative license and ended up with tacky pages strewn with 20 point pink flashing text.
Lastly authoring content for websites is a specific skill. Your authors need knowledge of SEO in order to write with decent keyword density and link on optimal terms. The content needs to be findable which means the authors need to include the right phrases and tag the content appropriately.
Roles and responsibilities
Quite often we will release a site on time and on budget and the client is very happy, all seems to have gone well. After a few months the content on the site hasn’t been updated and the site starts to nose dive. This is usually due to no-one taking responsibility for the site or content. It is vital to assign a single point of responsibility.
It can also happen because the user responsible wasn’t invited to the initial requirements capture meetings and so once the project is launched, they are presented with an interface which is scary and unfamiliar. People generally don’t like changing their methods of work, so if possible incorporate the stakeholders working methods into the project.
If it helps, design, develop and document a workflow process to ensure the content is maintained and provide additional training as and when needed to get them used to the system and it’s benefits. If the team includes authors from other global locations, it’s even more important to get a workflow agreed as there are often time and language barriers to overcome.
Technical issues
Technology is usually the easiest area to work with, but on occasion we have seen some clients get in a muddle with it.
It’s never a good idea to tie yourself too much to one technology. It makes it difficult to be flexible in the future and can sometimes lead to decisions on software that are motivated more by availability rather than suitability.
Also as I mentioned earlier, be careful about creating a system that is reliant on too many providers. If your news feeds from one company are not available, make sure you have a backup, or at least a failsafe in the code.
Lastly, be careful when choosing your CMS platform. Make sure it supports open data architectures, has no design constraints, is usable, flexible and has good support. 90% of our projects require us to do some sort of customisation, so make sure that’s possible.
If you want to chat about any of these issues, drop me an email, or call me on 020 7613 7221
