Following on from an earlier article relating to selecting a Content Management System, I would like to take the time to describe the steps involved in taking your Content Management System (CMS), and implementing a fully functioning web site that is capable of meeting the demands of local government. I would like to base this on my own experiences of implementing a new web site for East Northamptonshire Council. As the project spanned over twelve months from inception to going live, I won’t give a detailed blow by blow account, as this would be too much information, so I’ll stick to the key points.
Nailing the requirements
You need to have a very clear idea of your requirements. To give you an idea of the sorts of things you may want to consider, please read my article on selecting a Content Management System. This is not exhaustive, but hopefully will get you started considering what you need from your CMS. You may also want to consider whether you want an open source solution. There are many very good open source CMS suppliers offering a wide range of functionality. If you are considering this type of solution, then read my article which describes some of the areas you may need to consider with this type of solution.
It took several weeks before the requirements document was signed off with everyone’s approval. There were many areas that needed to be considered and included in the document, as different people would be involved with the CMS, and from different areas of the organisation.
· ICT would be tasked with administering the CMS (setting up users, tailoring the LGNL, creating appropriate landing pages, creating the necessary work flows, setting image sizes)
· Communications would be tasked with creating news stories and press releases, ensuring the web site followed the corporate style, that it represented the needs of the local citizens by including relevant content
· Content editors would be tasked with creating the content that would be put onto the web site. They come from all areas of the organisation, and are responsible for uploading content for the service area in which they work. For example, a content editor working in the Environmental Health service area, would upload content for that service area.
Everyone needs to be satisfied that their requirements have been fully considered during this process. You will need to get people round the table to discuss their requirements, so that others can give their opinion. We had several requirements that were initially deemed to be important, but during discussions were eventually discarded or amended in the light of input from others.
Never underestimate the value of opinion from a carefully selected group of interested people!
From our requirements, we could then proceed to the next stage of the project, and begin selecting suitable CMS suppliers.
Selecting the CMS supplier
There are many CMS suppliers out there in the market place, and the quality is very high. I used various comparative web sites at first to get a feel for what was on offer. We were looking for a non open source solution. Specifically, we were looking for a Microsoft based solution (SQL Server, Internet Information Services, .NET Framework), as these were the technologies we had in-house to provide local support, as well as to extend and develop the CMS further in line with fluctuating demands. As the primary development resource at the council, it was important that I could use the technologies provided by the CMS. This immediately narrowed the list of candidate CMS suppliers.
Looking through the list of those who were left, we looked to see which of the remaining suppliers had experience of developing web sites for local governments. The requirements of a local government web site are different in many ways to that of other web sites. Local government web sites need to implement a standard taxonomy, or list of services that they offer. What this means is that a service provided by one local authority should be located in the same area of the web site as another local authority. So bin collections will be located in the same area of all local authority web sites. They also need to comply more strictly with standards such as WAI conformance. This allows that web content is accessible to people with disabilities, such as visual impairments. This process also narrowed the list of potential CMS suppliers even further.
Eventually, we had a list of candidate CMS suppliers who offered systems that we could extend in terms of technology, and had experience of the local government sector. That list included:
· Immediacy
· Jadu
· Red Dot
· Goss Interactive
· Contentsis
We arranged demonstrations with each of these suppliers, with an invited audience of people from across the organization. This would give us a good cross section of opinions afterwards. We also had a marking scheme in operation, and marks were awarded by those who would be attending all of the demonstrations. This included myself, the web developer and other key personnel. This would ensure that we were awarding marks against each of the suppliers consistently, as they were being awarded by the same people using the same criteria.
Each of the suppliers were given the same set of scenarios to demonstrate with their products. They were free to deviate from the scenarios to demonstrate other areas of their product, but they each needed to all demonstrate as a bare minimum the set of scenarios that we had given them. This too would allow consistency, as each supplier would have to demonstrate the same elements within their product.
Having a standard set of scenarios, and a standard marking scheme, would bring fairness and consistency to the marking. It would also allow us to demonstrate how and why we had selected the successful candidate if this ever became necessary.
In the end, we selected Jadu as our CMS supplier. There were several reasons for that decision:
· They offered both an open source and a Microsoft based solution, allowing us to leverage the power of either development platform. Additionally, they offered a means of taking native PHP code, and compiling this into .NET Framework code using their own Phalanger compiler. This was a truly unique offering, giving us the best of both worlds.
· They had a deep understanding of the local government web site space, with many of their clients coming from local government, including the award winning Manchester City Council web site.
· From my own perspective, it was clear they understood technology. For any company involved in building systems, you need to have people who are passionate about technology. As a self confessed technologist, it quickly became obvious that the people at Jadu were passionate about technology. This was a crucial factor, as without the drive to move forward technologically, your investment would quickly become obsolete.
· Under the ICT Partnership, East Northamptonshire Council also provide ICT support to Borough Council of Wellingborough. The latter were already using Jadu, and so this would enable the two councils to share skills, and reduce the number of systems in use across both local authorities.
Migrating content
Once we had made our selection, we then met up with the team to go through the project – timescales, milestones, tasks etc. Jadu have a very well documented project management framework which is issued to all their clients to give them a detailed description of what will be involved. Luckily, they go through this with you at the start of the process, and indicate the key milestones along the way.
We now needed to migrate the content out of our current CMS and into the Jadu CMS. We initially investigated the possibility of automating an extraction, so that we could populate the Jadu CMS using content from our current CMS. As the two systems were radically different, it would have taken as long for Jadu to write the necessary scripts, than for us to plough ahead and migrate the content manually. However, as it turns out, the vast majority of clients prefer to migrate their content manually. This gives them the opportunity to clean up the content as part of the migration process – remove unwanted content and update existing content. What we didn’t really want was to blindly migrate our old content over to the new system, so the migration would help act as a housekeeping exercise.
The content editors were all briefed on what was expected of them, as they would be migrating the bulk of the content. It was a large task, as many had vast amounts of content on the web site which would take considerable time to migrate. So the next logical step was to arrange training for them on the new system. There are two levels of training – webmaster and content editor. Myself and several others had the full two day webmaster training. This covered all aspects of the system, including the administration and more technical areas. The content editors would receive the half day training which would cover the necessary steps involved in adding content (documents, downloads, news, events) to the system.
This process was initially estimated to take six weeks, but we soon realised we needed to change the timescales as the work was simply taking longer than estimated (that’s why they’re called estimates).
Testing
Despite several setbacks, problems and issues, we eventually managed to migrate our content over to the new CMS. We arranged internal testing, with staff from one service area testing the content of another service area. We used standard tasks extracted from SOCITM (the Society of Information Technology Management) who produce the excellent Better Connected report each year. This report ranks and assesses local government web sites, and gives advice on how they can improve. So using this as the basis for our testing made sense.
We tested each page also for:
· Spelling and grammar
· Writing for the web (short, punchy sentences and paragraphs, use of bullet points, breaking down a document into multiple pages)
· Broken links
· Use of images
· Use of page supplements
· Use of landing pages
· Layout and overall look / feel of the page
Communication is absolutely critical!
One of the key components along the way was a high level of communication. I arranged and chaired regular meetings with the content editors, to get their feedback on any issues and problems they were experiencing, as well to as to go through the latest project updates with them. With a project of such scope, that affects the entire organisation, and requiring input from all service areas across all levels of seniority, communication was far from easy. Keeping everyone up-to-date was very difficult. Different people wanted different levels of information. Some only required brief updates, some required detailed updates. It really pays dividends to have a formal process of communication in place:
· Who will send out the communications?
· Who will receive the communications?
· How often will they be sent?
· How will they be sent?
Having a process in place whereby these questions are satisfied will be of immense benefit.
Going live
On the day, the process we were to follow would be:
· Jadu perform pre go–live checks in the morning
· Once complete we then change the Domain Name System (DNS) record to point to the new web site and take the current web site offline (and place a suitable offline web page in its place)
· Jadu complete their pre go-live checks and give us access to the site for testing (the general public still see the offline web page)
· Once we have tested the web site to our satisfaction we give Jadu the go ahead to make the web site live to the general public
We had put together a test schedule for the period during which we had access to the web site. This was not to test the content (which we had already done), but to test areas of the site that may have been affected by making the web site live. This would allow us to perform targeted testing when we only had a brief window of time.
Conclusions
There are many areas of the project that I have omitted for brevity, including the integration with the back end office systems, coming up with the look of the new web site, as well as the many issues that were encountered along the way. That aside, the key points made here still apply.
Nailing the requirements
You need to have a very clear idea of your requirements. To give you an idea of the sorts of things you may want to consider, please read my article on selecting a Content Management System. This is not exhaustive, but hopefully will get you started considering what you need from your CMS. You may also want to consider whether you want an open source solution. There are many very good open source CMS suppliers offering a wide range of functionality. If you are considering this type of solution, then read my article which describes some of the areas you may need to consider with this type of solution.
It took several weeks before the requirements document was signed off with everyone’s approval. There were many areas that needed to be considered and included in the document, as different people would be involved with the CMS, and from different areas of the organisation.
· ICT would be tasked with administering the CMS (setting up users, tailoring the LGNL, creating appropriate landing pages, creating the necessary work flows, setting image sizes)
· Communications would be tasked with creating news stories and press releases, ensuring the web site followed the corporate style, that it represented the needs of the local citizens by including relevant content
· Content editors would be tasked with creating the content that would be put onto the web site. They come from all areas of the organisation, and are responsible for uploading content for the service area in which they work. For example, a content editor working in the Environmental Health service area, would upload content for that service area.
Everyone needs to be satisfied that their requirements have been fully considered during this process. You will need to get people round the table to discuss their requirements, so that others can give their opinion. We had several requirements that were initially deemed to be important, but during discussions were eventually discarded or amended in the light of input from others.
Never underestimate the value of opinion from a carefully selected group of interested people!
From our requirements, we could then proceed to the next stage of the project, and begin selecting suitable CMS suppliers.
Selecting the CMS supplier
There are many CMS suppliers out there in the market place, and the quality is very high. I used various comparative web sites at first to get a feel for what was on offer. We were looking for a non open source solution. Specifically, we were looking for a Microsoft based solution (SQL Server, Internet Information Services, .NET Framework), as these were the technologies we had in-house to provide local support, as well as to extend and develop the CMS further in line with fluctuating demands. As the primary development resource at the council, it was important that I could use the technologies provided by the CMS. This immediately narrowed the list of candidate CMS suppliers.
Looking through the list of those who were left, we looked to see which of the remaining suppliers had experience of developing web sites for local governments. The requirements of a local government web site are different in many ways to that of other web sites. Local government web sites need to implement a standard taxonomy, or list of services that they offer. What this means is that a service provided by one local authority should be located in the same area of the web site as another local authority. So bin collections will be located in the same area of all local authority web sites. They also need to comply more strictly with standards such as WAI conformance. This allows that web content is accessible to people with disabilities, such as visual impairments. This process also narrowed the list of potential CMS suppliers even further.
Eventually, we had a list of candidate CMS suppliers who offered systems that we could extend in terms of technology, and had experience of the local government sector. That list included:
· Immediacy
· Jadu
· Red Dot
· Goss Interactive
· Contentsis
We arranged demonstrations with each of these suppliers, with an invited audience of people from across the organization. This would give us a good cross section of opinions afterwards. We also had a marking scheme in operation, and marks were awarded by those who would be attending all of the demonstrations. This included myself, the web developer and other key personnel. This would ensure that we were awarding marks against each of the suppliers consistently, as they were being awarded by the same people using the same criteria.
Each of the suppliers were given the same set of scenarios to demonstrate with their products. They were free to deviate from the scenarios to demonstrate other areas of their product, but they each needed to all demonstrate as a bare minimum the set of scenarios that we had given them. This too would allow consistency, as each supplier would have to demonstrate the same elements within their product.
Having a standard set of scenarios, and a standard marking scheme, would bring fairness and consistency to the marking. It would also allow us to demonstrate how and why we had selected the successful candidate if this ever became necessary.
In the end, we selected Jadu as our CMS supplier. There were several reasons for that decision:
· They offered both an open source and a Microsoft based solution, allowing us to leverage the power of either development platform. Additionally, they offered a means of taking native PHP code, and compiling this into .NET Framework code using their own Phalanger compiler. This was a truly unique offering, giving us the best of both worlds.
· They had a deep understanding of the local government web site space, with many of their clients coming from local government, including the award winning Manchester City Council web site.
· From my own perspective, it was clear they understood technology. For any company involved in building systems, you need to have people who are passionate about technology. As a self confessed technologist, it quickly became obvious that the people at Jadu were passionate about technology. This was a crucial factor, as without the drive to move forward technologically, your investment would quickly become obsolete.
· Under the ICT Partnership, East Northamptonshire Council also provide ICT support to Borough Council of Wellingborough. The latter were already using Jadu, and so this would enable the two councils to share skills, and reduce the number of systems in use across both local authorities.
Migrating content
Once we had made our selection, we then met up with the team to go through the project – timescales, milestones, tasks etc. Jadu have a very well documented project management framework which is issued to all their clients to give them a detailed description of what will be involved. Luckily, they go through this with you at the start of the process, and indicate the key milestones along the way.
We now needed to migrate the content out of our current CMS and into the Jadu CMS. We initially investigated the possibility of automating an extraction, so that we could populate the Jadu CMS using content from our current CMS. As the two systems were radically different, it would have taken as long for Jadu to write the necessary scripts, than for us to plough ahead and migrate the content manually. However, as it turns out, the vast majority of clients prefer to migrate their content manually. This gives them the opportunity to clean up the content as part of the migration process – remove unwanted content and update existing content. What we didn’t really want was to blindly migrate our old content over to the new system, so the migration would help act as a housekeeping exercise.
The content editors were all briefed on what was expected of them, as they would be migrating the bulk of the content. It was a large task, as many had vast amounts of content on the web site which would take considerable time to migrate. So the next logical step was to arrange training for them on the new system. There are two levels of training – webmaster and content editor. Myself and several others had the full two day webmaster training. This covered all aspects of the system, including the administration and more technical areas. The content editors would receive the half day training which would cover the necessary steps involved in adding content (documents, downloads, news, events) to the system.
This process was initially estimated to take six weeks, but we soon realised we needed to change the timescales as the work was simply taking longer than estimated (that’s why they’re called estimates).
Testing
Despite several setbacks, problems and issues, we eventually managed to migrate our content over to the new CMS. We arranged internal testing, with staff from one service area testing the content of another service area. We used standard tasks extracted from SOCITM (the Society of Information Technology Management) who produce the excellent Better Connected report each year. This report ranks and assesses local government web sites, and gives advice on how they can improve. So using this as the basis for our testing made sense.
We tested each page also for:
· Spelling and grammar
· Writing for the web (short, punchy sentences and paragraphs, use of bullet points, breaking down a document into multiple pages)
· Broken links
· Use of images
· Use of page supplements
· Use of landing pages
· Layout and overall look / feel of the page
Communication is absolutely critical!
One of the key components along the way was a high level of communication. I arranged and chaired regular meetings with the content editors, to get their feedback on any issues and problems they were experiencing, as well to as to go through the latest project updates with them. With a project of such scope, that affects the entire organisation, and requiring input from all service areas across all levels of seniority, communication was far from easy. Keeping everyone up-to-date was very difficult. Different people wanted different levels of information. Some only required brief updates, some required detailed updates. It really pays dividends to have a formal process of communication in place:
· Who will send out the communications?
· Who will receive the communications?
· How often will they be sent?
· How will they be sent?
Having a process in place whereby these questions are satisfied will be of immense benefit.
Going live
On the day, the process we were to follow would be:
· Jadu perform pre go–live checks in the morning
· Once complete we then change the Domain Name System (DNS) record to point to the new web site and take the current web site offline (and place a suitable offline web page in its place)
· Jadu complete their pre go-live checks and give us access to the site for testing (the general public still see the offline web page)
· Once we have tested the web site to our satisfaction we give Jadu the go ahead to make the web site live to the general public
We had put together a test schedule for the period during which we had access to the web site. This was not to test the content (which we had already done), but to test areas of the site that may have been affected by making the web site live. This would allow us to perform targeted testing when we only had a brief window of time.
Conclusions
There are many areas of the project that I have omitted for brevity, including the integration with the back end office systems, coming up with the look of the new web site, as well as the many issues that were encountered along the way. That aside, the key points made here still apply.
Make sure you get your requirements signed off with the consensus of a group of interested people who are capable of arriving at the final document.
Spend as much time as you need (or as you can afford) researching the CMS market. Find out what is available, what the differences are between the many products. We sought the opinion of other local authorities to see what CMS they used, and what they thought of it. There is nothing quite like a recommendation!
Ensure you have clear channels of communication. This is vital to the success of the project. With so many different people involved from so many areas of the organisation, you will be quickly swamped without a proper process of communication in place.
Spend as much time as you need (or as you can afford) researching the CMS market. Find out what is available, what the differences are between the many products. We sought the opinion of other local authorities to see what CMS they used, and what they thought of it. There is nothing quite like a recommendation!
Ensure you have clear channels of communication. This is vital to the success of the project. With so many different people involved from so many areas of the organisation, you will be quickly swamped without a proper process of communication in place.
Posts
