What’s the plan Stan?

Define your strategic goals (image by evelynishere)

I have often come across organisations that have decided they need a website. When I ask them what functionality they require they will readily reel off a load of internet related buzz-words such as streaming media, personalisation, google maps etc. However, when I ask them what the purpose of the website is and its objectives the answer is often “ummm….”.

This is not surprising really, it’s so easy to get carried away with the thought of new toys to play with and completely overlook the objectives for the site. Indeed, a new website may not be required at all.

Digital media is basically a tool for delivering your business objectives. Your business or organisation will usually have a clearly defined business strategy, so before you even think about your web presence you need to write a web strategy that will help you achieve those goals.

Your web strategy should drive how you use the internet and what tools you use to achieve your goals.

Simply defining your goals is only the first step, your strategy should contain 3 elements…

1. A Goal – What do you want to achieve?
2. A Method – How are you going to achieve your goal?
3. A Measure – How are you going to measure success?

Goal!!

Make sure your goals are technology independent. One of your web strategy goals may be to “increase sales by 10% in a year by improved use of online technology”, it should NOT however be to “create a new website in order to increase sales by 10% in a year”. Your strategy should not mention a particular tool or method, your strategy will determine which tools you use, not the other way around.

If your organisation does not have profit lead goals you can still clearly define what you want to achieve. For example, the NHS may have a goal to “spread information on swine flu to new audiences using digital media”.

Method

Once you have a defined goal or goals you should then be able to work out what methods you will use to achieve those goals. In many cases there will be many digital options open to you. You may decide to use multiple methods or you may decide to focus your efforts on one tool.

So in order to achieve your  goal to “spread information on swine flu to new audiences using digital media”, you may decide to use the following method….

Set up a twitter feed called NHSwineFlu to…

• spread swine flu messages
• highlighting urgent swine flu updates
• respond to events

He shoots, he scores!

Having a strategy is one thing, but how do you know if you have achieved your objectives? With a sales based goal it is relatively easy to measure success, for example by simply seeing whether you have increase sales by 10% in a year after your digital campaign started.

With less tangible goals it is possible to measure success using Key Performance Indicators (KPI). In the case of the NHS the measure of success may be defined in the following KPI’s…

• increase our twitter followers by at least 10% a month (base line this measure)
• achieve an average of 10 click-throughs/messages to any NHS sites the tweets promote.
• Achieve 50 re-tweets a week.

Go for it!

So if you are entering the digital arena for the first time or want to refresh your online prescence think Goal, Method, Measure!

6 steps to a successful web project

Turn your ideas into reality in 6 steps (image by Da Flai)

In this blog I am going to outline the steps I think are required to deliver a successful web project. These steps can be applied to any size of project whether it is simply building a new site or a whole new web platform.

1. Requirements capture and definition. In my opinion this is the most important step of the whole project. Unless you correctly identify the requirements both strategically and functionally, whatever you deliver will ultimately fail and you will have to start again. Techniques such as interviews, workshops, brain storming and brand boards are used to gather requirements. The MoSCoW technique is also very useful for prioritising requirements. I have already blogged about the importance of engaging the end user when requirements gathering, it is also important you work closely with internal stakeholders to draw up a detailed requirements specification.  The requirements specification can then be used to define functional and non-functional requirements. If you are using a technical partner to deliver the platform, you should also specify the performance requirements. It is important that all requirements are clear and unambiguous. Use terms like ’shall’ or ‘will’ rather than ‘may’ or ‘could’. Later you can then use these requirements to help establish Key Performance Indicators (KPI) to measure the success of the delivered website(s).
2. Design - Once requirements have been defined and specified they can then be used to design the new website(s). This phase includes developing the website Information Architecture (IA) and wireframes of the website. If the project involves new Web Content Management System (WCMS) functionality a functional specification will be developed from the requirements and a training specification to identify what needs to be trained.
3. Build – At this stage all the detailed designs, wireframes, etc are passed to the technical team for development of the platform. You must ensure that the technical team are correctly skilled and experienced to deliver the platform to the required specification and performance. At this stage you should start to plan any required website migration and training. This can be a time consuming stage.
4. Testing – Once the platform has been built it must be thoroughly tested to ensure all requirements are met. This testing should include system testing, performance testing, user acceptance testing and any required penetration testing. You should also ensure any new sites are tested for accessibility and usability.
5. Implementation – Once the platform has been thoroughly tested and signed off you must implement the solution. On a small project this stage will simply involve training, creating content and publishing the new website. On a large-scale project however, this stage could be very complicated and involve website migration, training delivery, website build and launch of many websites.
6. Review and Evaluate – When you have launched your new platform don’t consider the project to be over. It is good practice to review the project process and evaluate it. What went well? What didn’t go well? What would you do differently next time?

This process may look daunting to some, but with the right amount of planning and preparation these steps will provide the structure to allow you to deliver a successful web project.

In future blogs I will look at each of these steps in more detail.

Managing content – go with the flow!

Workflow can help you control your content - photo by muha...

When managing many sites and many webmasters it is important to maintain control of your content. At the FCO we have over 250 websites and 300 webmasters. It is impossible to keep track of all these sites and webmasters ourselves but workflow allows us to control access to creating and publishing content.

Wikipedia provides a good definition of workflow – “A workflow is a depiction of a sequence of operations, declared as work of a person, a group of persons, an organization of staff, or one or more simple or complex mechanisms.”

When combined with user access restrictions, workflow can give you peace of mind that content is being created, edited, reviewed and published by the right groups of people.

Here are my golden rules for designing a web workflow…

1. Workflow is an interpretation of the required business processes. You must fully understand the business processes required before you attempt to interpret them into a technical workflow solution.
2. Keep it as simple as possible – editors and managers need to understand how it works.
3. Make it adaptable – a single workflow should be able to adapt to all required editorial processes.

In my experience a simple 4 step workflow can cover almost any combination of business processes

This is a circular workflow from new through to archived and then back to new.

New – This is the status at which content is created and edited. Members of this group are able to create new content and pass to review status.

Review – At this status a manager can review the content and either pass it through to published status or reject it back to the new status.

Published – At this stage content is live on the website. From this status content can be pushed to archived status, this will remove the content from the live site. Alternatively, an editor can move the content back to new status. This means the content will remain live on the site while changes are made.  The page is then passed back through workflow to published therefore replacing the original content.

Archived – Once moved to this stage content is removed from the website. This content can then be edited and pushed back through workflow to published status.

Hopefully this will give you a bit or a head start when planning access to your content.

Comments welcome!

Web Content Management Systems – Do I need one?

Will a WCMS help you manage your content? By Evil Erin.

I have worked with web content management systems (WCMS) for a long time now. To me they are an essential tool for any large organisation wanting to manage lots of websites and content. I have always been surprised by the number of web professionals I have met who either don’t understand what a WCMS is for or cannot see any benefit to using one.

So I thought it might be useful to answer the following questions…

What is a WCMS?

It does exactly what it says on the tin. The purpose of a WCMS is to manage and share content across multiple websites. It’s that simple. A WCMS allows web editors to publish content across multiple sites,  control that content, and control editorial access to it.

So what is it good at then?

• Controlling editorial access – A WCMS is great for controlling access to particular sites, access to part of a particular site, or access to particular types of content. You only want your press office to create press releases? No problemo.
• Controlling publishing – You don’t want your press officer to publish a press release before the Press Office manager has approved it? Easy, WCMS systems use workflow to manage user roles.
• Sharing content – You want to add the same web page to 230 websites? Not a problem with a WCMS.
• Presentation Control – WCMS’s allow you to control how content is used and where it can be displayed with page templates. For example, Press releases can only appear on a newsroom template.
• No techie skills required – A WCMS allows web editors to create content without any web technical expertise whatsoever. HTML? Never heard of it guv’nor.
• Quickly create new sites – Give me the site name, hit a button and ta-da! New site created.
• Improved performance – Most WCMS systems allow techie types to easily optimise performance across your web platform.
• Reusing content – Want an image of a car? The chances are there is already one loaded into the WCMS, just search the repository for the car image rather than having to find a new image.
• Enforcing standards – More control! Your sites need to be W3C AA compliant? Easy, just ensure your WCMS templates and stylesheets comply and all your sites will comply.
• Previewing content – Want to see your content in-context before the rest of the world can see it? Just preview your content before it is published to the rest of the world.

It sounds great, what’s the catch?

• Flexibility – A press release can only be displayed on a newsroom, remember? Want a press release on the homepage? That’ll be an update to the page template then. If you need lots of  quick tweeks to design and functionality a WCMS will really slow this down.
• Frustrating for editors – If your editors are used to editing HTML directly using dreamweaver they will find a WCMS very frustrating because of the limitations it places on them. They cannot edit HTML like they used to.
• It takes time to implement – Implementing a WCMS in a large organisation can be a very time consuming business.
• Slows progress – The internet is a very fast moving environment these days. New technology and innovations arrive all the time. A WCMS does not lend itself well to keeping pace with these new developments.
• Can be slow to add content – Most WCMS systems treat every web page element as a separate bit of content. Your page contains 5 images and 10 links? You had better create 5 image content types and 5 links in the WCMS then!
• Training – Got 200 editors across the globe? Someone will rack up the airmiles to train them. That’ll cost you!
• Lose the WCMS, lose all your sites! – If the WCMS fails or the database behind it fails you could potentially lose all your sites.
• Is it overkill? – If you only have 5 small sites and 10 HTML editors there is little point implementing a WCMS. A WCMS works best when you have many sites and editors and lots of content.
• Not great for SEO – Generally WCMS systems are not great at search engine optimisation.
• Cost – I am sure I have mentioned cost before?! Ouch, they can cost a lot!

Have I missed anything? Let me know!

You may have noticed that I used the word “control” several times in the “good at” area. That word really sums up what a WCMS offers organisations.  Editorial, presentation and publishing control of web content. Combine that with the lack of technical expertise required and the ability to easily share and reuse content across many sites and you have a powerful tool that will be invaluable to many large organisation.

If however, your company requires maximum flexibility and costs are an issue, think long and hard before investing in a WCMS.

Migrating websites – top tips

Wildebeest migration by daretothink

As Transition manager for the FCOWeb project at the Foreign Office I was responsible for migrating and re-launching over 230 websites from our old CMS web platform to the new CMS platform. These websites were distributed globally and there were over 200 webmasters spread across the globe.

This was a complicated, painful, and time consuming process for all involved.

During this process I learnt several valuable lessons I think are useful to pass on….

Migrate as little as possible – In any migration the approach should always be to migrate the minimum amount of content possible. Why migrate content that is not required? When talking to content owners or webmasters always question why content should be migrated. Editors tend to assume all of their content is vital and therefore should be migrated. Website migration is an opportunity to streamline content and tidy up bloated websites.

If a site is small or out of date, do not migrate it at all. Don’t assume all sites need to be migrated, it will often be a longer, more painful process to map, migrate, and tidy up a site for re-launch than it would be to just build the site from scratch on the new platform. Create a list of sites and content within scope and stick to it.

It’s not just content – Migrating websites is not just about the content. If you have subscribers to your sites you need to consider whether you need to migrate these subscribers to the new platform and how. If you have CMS user accounts consider whether they need to be migrated too (I would advise against that!)

Make the process repeatable – Design the migration process so that it is repeatable. Ideally the extract – transform – load process should be repeatable so that is can be applied to any given site.

Make webmasters part of the process – Website migration is reliant on many stakeholders. Of those, site webmasters are the most important because you are reliant on them to identify content to be migrated, map old content to the new information architecture, and tidy up the migrated site for launch. You must involve these stakeholders in the migration process as early as possible and keep them engaged throughout the process. Let them know what is required from them, the timetable, and make them feel ownership for the migration of their website. Without these people on your side you stand little chance of hitting your migration deadlines.

Make the mapping process as simple as possible – Website migration usually involves mapping content from the old website onto the new IA to be used by the new site. This process can be confusing for webmasters and content owners. Make the mapping process simple by using a familiar application such as MS Excel and macros to automate the process as much as possible. If you can pre-populate any of the mapping then all the better.

It is likely to be far easier and quicker to migrate pages into “buckets” of pages on the destination server than try and fully build the new website structure automatically as part of the migration. It is then a simple task for webmasters to rebuild the site structure and move pages to the correct attach points.

Get the right team - Website migration boils down to a complicated technical task of transferring data between databases. Ensure you have a strong technical team that understand your content at a technical level, understand the destination content structure, and have experience of migrating content from one platform to another.

It is also vital you have good communicators who can keep key individuals informed and maintain the flow of information back to you in the centre.

Minimise parallel running – Once a website is migrated from one platform to another there will be a period of parallel running before the new site is launched. During this period a webmaster needs to check and tidy up the migrated site before launch and maintain the old website which is still live. This period is resource intensive and should be kept to a minimum.

Be strong with the timetable – It is vital that you stick to the timetable as closely as possible. It can take weeks or months to tidy up and launch migrated websites, if you let your timetable slip at an early stage you will never make up the lost time and a domino effect will cause further delays. If those involved meet their deadlines you have a good chance of meeting yours. As well as working with content owners, it is important to identify a senior responsible owner (SRO) for each site you are migrating. If deadlines are missed or work not completed the issues can be escalated to the SRO who can then put pressure on their own staff.

Migrating multiple sites is a complicated and time consuming business. Careful planning, the right people, and a realistic timetable can minimise the pain for all involved.

Good luck!

Requirements gathering – engage the end user!

First of all, let me explain what I intend to do with my blog. My main aim is to share my experiences with you. Some of you may agree with what I am saying and find it useful in your own jobs, others may not. Even if you don’t find it useful or you disagree with what I say, I am hoping you will comment and share your own experiences with readers. Between us hopefully we can solve some problems and prevent others occurring!

Requirements gathering, not as simple as it sounds!

My first blog is about something that can easily occur on web projects.
It sounds obvious I know, but in many large scale web projects it is all too easy to forget about the end user when gathering requirements.

The internal demands can dictate the agenda

Particularly in large organisations or large projects, all too often it is the many internal stakeholders that drive web project requirements and not the end user. Time can become a big issue, there simply may not be the time to gather requirements from all stakeholders so requirements are prioritised to those with a bigger say.

On several projects I have seen elements of the final solution be completely specified from within the organisation based on perceived best practice and internal demands. Although this means the final solution may be delivered in time and meet the basic requirements, it rarely leads to a good user experience. In fact, in my experience this approach leads to further work down the line to correct issues resulting from usability testing and user feedback.

To some degree it is inevitable that internal requirements may drive the agenda.  Internal management usually decide a project is required and control the purse strings. Project owners will inevitably try to engage with these internal stakeholders to satisfy their requirements and therefore further their own careers.

After all, if a project owner delivers a project that meets all internal stakeholder requirements it is likely the project will be deemed a success and everyone will be happy. Everyone that is, except the end user!

Don’t be scared to engage end users

To make matters worse many organisations are often scared to ask end users opinions for fear of negative feedback and raised expectations. Given these scenarios it is easy to see how the end user can be forgotten or ignored.

If you find yourself capturing requirements for a web project, my advice is to not fear the end users, but engage them as early as you can. More and more these days end users want to engage in a constructive way with companies to improve their own experience. With social media now the staple diet of the web, users expect and indeed demand interaction with each other and the websites they use.

Companies should embrace their audience, encourage feedback and use this information to help inform internal stakeholders who can then tailor their demands accordingly. After all, without happy end users your websites will soon perish!

Gathering user feedback does not have to be a time consuming or expensive process either. Tools such as SurveyMonkey make online surveys incredibly easy to create and good value.
Engaging end users early in the process will save you time and effort in the long term and ensure a better end product.

The end user is King!

So in conclusion, it may seem silly, but in the thick of a project, with tight deadlines and many internal stakeholders wanting a say, it is easy to forget the end user.

Remember, the end user is king, engage or die!