Submitted by David Hobbs on 16 February 2012 - 5:45pm
The level of standardization you have as well as the level you want has a direct impact on your migration effort.
For example if your content is currently inconsistent, and you don't care about consistency after your transformation, then the migration is easy. For example, if your data tables each are presented entirely different on each page but you don't care, then migrating is easy. On the other hand, of course if you have high consistency now and want high consistency after the transformation then that is easy, even if you want transformations along the way. The hard part (and it is often worth it!) is when you currently have inconsistency but want to have a more standard approach going forward.
This also has an impact on your inventory effort as well, since if you don't care about the resulting consistency then the inventory may not need to be as accurate for your planning.
Of course, there are many nuances to all this (and the Easy/Hard designation is oversimplified), but hopefully this will help your planning in broad strokes.
---------------
So what does standardization mean? Clients of David Hobbs Consulting dive into the many dimensions of standardization when planning website transformations.
Contact us.
Bookmark/Search this post with
Submitted by David Hobbs on 8 February 2012 - 1:42pm
Bill Trevor was the Project Manager who led the Mass.Gov effort to replace the Web Content Management System, visual design and navigation. He is a consultant specializing in Information Architecture, Website Migration and Optimization, Project Management and Social Media Marketing. His views are his own and in no way represent the views of Mass.Gov or the Commonwealth.
You migrated 26 sites and around 700,000 content items into your new CMS, and some of the sites were previously on other platforms. How did you coordinate with all of the stakeholders? What were the initial discussions like, and how did you stay engaged throughout the process?
With any project (especially one of this size) communication is key. We held frequent stakeholder meetings at both the migration coordinator and senior management levels for each of the 26 sites. We formed a "migration liaison team" that included one representative from each site to ensure information was broadly communicated. We also leveraged a wiki so stakeholders could receive notifications if there were any updates related to the migrations.
A primary goal of the project was to maintain one platform that easily presents a single view for web users looking for information on Massachusetts government. Was that goal met? Why was a new platform needed to make that happen? How did you convince people to move to a single platform, and how much variance did you allow between websites?
Since its inception, Mass.Gov has been focused on maintaining a single face of government. The goal of this mantra is to create a state website that constituents feel comfortable navigating around, no matter the agency/department providing the information they seek. Too many state websites have a "single facing" homepage only to disperse into as many different websites as there are agencies. Mass.Gov takes the opposite approach and as far as I can tell, is doing it the best. The new Content Management System (CMS) will enable Mass.Gov to keep that guiding principle true while allowing some flexibility to content authors to slightly alter their web pages without losing that single face. Constituants want to be confident that the site they are visiting is an official state sanctioned site and Mass.Gov makes that happen. The Commonwealth of Massachusetts continues to pursue the goal of IT consolidation. Why not offer a single enterprise level CMS instead of having 160+ different systems, visual designs and site navigation structures. This website consolidation has been in the works for many years (termed Portalization) and the new CMS will allow Mass.Gov to continue the push to bring more sites onboard.
How different is the experience now for web users looking for information from Massachusetts government?
While it may have been an ambitious project, Mass.Gov saw the replacement of the CMS as an opportunity to also update the visual design (4+ years old) and the navigation schema (7+ years old). The prior versions of the Mass.Gov site templates were very rigid, narrow and leveraged the old Yahoo category navigation schema. You know, the one where you saw topics, clicked them, saw sub-topics, clicked them and so on and so forth. Mass.Gov has introduced a modern mega-drop down, in the same style of ESPN or Target, quickly exposing level 2 and 3 topics from the banner on every page. Another addition is a similarly fashioned left navigation that allows users to expand a drop down menu from the left column to get a peak at what content lies beneath that category. These features reduce "number of clicks" and help to flatten the information architecture. We put a new "modern minimalist" design on top which offers more space for agencies to showcase content along with an easy to maintain slideshow template and a wider page layout.
How did you develop content inventories, and what did you discover when you did them?
We used everything we could find. Some agencies kept good inventories of their own and we leveraged those. We also used free tools like Xenu to spider sites and export the findings into excel to obtain a comprehensive view. For better or worse, the old CMS was a very linear tool and so it was a lot of work but attainable to export the navigation structure from the old site and dump that into the new tool to build the underlying folder structure. One thing to note, most agencies saw this as such a large project to simply move their existing content/navigation into the new CMS that few took the opportunity to redo their IA. We did, however, try to get agencies to see the value in a pre-migration ROT (redundant, outdated and trivial) analysis because the less content you migrate, the less you have to QA/tweak.
What simplifications did you make the project a success?
Keeping the scope in focus and using it as the barometer for any requested change. We used our daily scrum (15 minutes) to update each team member on what we accomplished yesterday, tasks for the current day and to discuss any issues blocking progress. These meetings kept team members honest and ensured everyone was on the same page. I also cannot stress the importance of a parking lot page and Executive Sponsorship. We had great support with the upper management circles who really listened when something came up that might derail us and helped to determine an effective resolution without busting scope.
How much of the migration was automated and how much was manual?
We had really great partners from the CMS vendor (Percussion) and a rocket scientist (well he was considering becoming one) who did the automated migration. Again, we did a lot of research and heard the horror stories about how poorly content migrations ended up but I can say that the automated portion of the project *fairly* cleanly migrated 85% of the agency content. This included documents and images. There was some content that may have gotten lost in translation but the vendor did a great job translating the old to the new. It was no small feat and only caused minor delays. We knew the cleaner the content was after it migrated, the less work the agencies would need to do prior to their site going live.
How much was dropped from the old sites?
Because the old tool had a separate navigation component, Mass.Gov knew exactly what was live on the old website when we took our final content snapshot. Mass.Gov migrated every web page that was live at the time of the snapshot and the numbers of pages dropped due to issues was probably less than 2% of 400,000 pages. This was most likely due to malformation in the page code.
How did you track progress as you went forward?
We used every resource we had at our disposal! Scrum was a tremendous help. Our main tracking methods were MS Project, our Wiki and Sharepoint. We leveraged MS Project to track milestones, resources, critical path and high level project points to senior management. Our Wiki was the main communication mechanism for our stakeholders as they were able to comment, ask questions and view schedules/timelines in real time as the project evolved. Internally, we leveraged Sharepoint as a means to track issues / bugs / fixes during the configuration and implementation of the CMS.
The old saying goes something like "You have your choice of schedule, scope, and cost -- pick any two." How did you do against schedule, scope, and cost?
Scope was always a challenge but we kept focus via daily scrum meetings and constant sessions with our stakeholders. The schedule did take some hits to ensure the product was scaled appropriately and that the content was migrated as clean as possible. This did not result in a significant delay and by the time we launched the first websites on the new platform, we were within the margin of error for our original project plan we drafted some two years prior.
If you could do it over again, what would you change?
If time was not a factor (we were dealing with fiscal year funding deadlines at times) I would have preferred to have spent more time analyzing website Information Architecture. Due to the enormity of migrating to a new toolset (fear of the learning curve) we recommended that agency staff focus on QA'ing the content that migrated and getting comfortable with the CMS. I still believe that this was the right decision but some sites are now looking to overhaul their IA.
What were the biggest constraints you had, and how did you overcome them?
I think the biggest challenge is that Mass.Gov is the top level website and maintains the CMS tool but does not control the governance model used by the 26 sites. While not a bad thing, it was challenging to get agreement and consensus on some aspects. In the end, we had a very strong communication model that served us and our stakeholders well. Absent this, we might still be migrating websites.
How is Mass.gov set up for ongoing management of the site? How many sites are still on the horizon to be moved to the new platform?
Mass.Gov took great care to develop authoring documentation and posted it to the Wiki. This way, it is available 24/7 and is continually updated by the team. Gone are the days of printing out a training manual as the minute it is printed, some aspect is out-of-date. Mass.Gov is also working to make short video tutorials that authors can watch to see click by click how different content components are created. Now that the CMS is in production and the original sites have launched, the next phase has commenced and "portalization" of state entities not on the CMS platform has begun. There are several large sites outside the Mass.Gov platform and the hope is to migrate as many as are willing to leverage this enterprise CMS and join their fellow agencies in expanding the single face of government.
--------------------------
Are you a website owner with a migration success (or failure)? HobbsOnTech will be featuring interviews like this one to help provide a repository of experiences that others can draw upon. Please contact us if you would like to participate.
Bookmark/Search this post with
Submitted by David Hobbs on 5 July 2011 - 5:14pm
Any CMS implementation with a large number of stakeholders will generate far more requests than could ever be implemented. So how do you determine what gets onto the work program and then implemented?
There are several streams where potential features could get added to the system:
- User requests (either internal or external)
- Stability / security
- Performance / scalability
- Hardware / infrastructure
- Long range requirements
So even an important user request may not make it onto your near term work program if, for example, there is a severe stability issue that needs to be addressed quickly. So there is something of an air gap between the requests coming in and what winds up on the work program. This is one of the most important roles of the product manager, and the product manager needs to consider the following factors.
Backend needs
As mentioned above, key security, scalability, performance, or manageability issues may trump any other requests. Notably, these may be items that your key stakeholders may not be aware of, much less actually requesting them.
Batching
Your near-term work program needs to be consistent, meaningfully grouping changes. This is both for communications and technical reasons. From a communications perspective, if the items being addressed are consistent then everyone can quickly understand what's happenning. From a technical perspective, if you need to completely rewrite a subsystem to address and issue then it might make sense to address many of the issues with that subsystem at once.
Resource constraints
Obviously you need to have the resources to implement your work program. This is both for a raw number of hours as well as balancing key resources. For instance, if your DBA is required for many requests then you may be able to only do some DBA-limited requests at once.
Popularity
Of course, the popularity of a request is very important, but, again, not the only factor). All other factors being equal, a more popular item should be placed on the work program before others. In practice, it may make sense to delay your top-requested feature in order to address the next three (for instance if the next three could be implemented in the same effort as the first).
Note two factors that are NOT listed as factors:
In the end, the product manager must be able to justify the work progrm to the stakeholders. Although clearly more of an art than a science, the factors (and non-factors) should help in forming that solid work program.
--------------
Need help managing your CMS implementation as a product? Contact David Hobbs Consulting.
Bookmark/Search this post with
Submitted by David Hobbs on 18 May 2011 - 8:30pm
Far too often, teams get so excited about the possibility of automatically-driven topic pages that they wind up with an overly-complicated topic list. It seems so easy, what with the possibility of one template simply being driven by tags to generate lots of topics pages. Why can a complex topics list be a problem?
More difficult to tag well
Unless you are going to have dedicated librarians tagging your content consistently (or librarians managing the rules for doing automated tagging), the more complicated your taxonomy the more difficult it's going to be to tag well.
Less likely to be a good taxonomy
The larger your taxonomy, the less likely it's going to be consistent, correct, and not redundant.
More likely to be bureaucratic or overly-technical
Once you open the floodgates to a large taxonomy, you are far more likely to have it represent internal interests than those of your site visitor.
More difficult to have consistent topic page quality
The worst case is an empty topic page that a site visitor sees, but you can also have pages with such old content that it is less useful.
Harder to migrate
If you're making the topics list more complex in your target site during a migration, then you need to have a way of tagging it to this new list, and a complex list will be more complications for that migration.
As always, what the right level of complexity for your organization may be too complex or too simplified for another. After all, the whole reason for your migration may be more thorough topics pages. That said, keep in mind the downsides of a more complex taxonomy when designing your system to help ensure you don't end up with an unreasonable topics list.
Bookmark/Search this post with
Submitted by David Hobbs on 11 February 2011 - 7:56am
Many sites are largely organized around topics (as oppossed to, say, the org chart or products). But there are plenty of nuances to having successful topics pages, from dealing with political issues (when should a new topic page be created) to functionality options (how should topics pages be managed) to the metadata concerns. If creating automated listings on topics pages, consider this:
You can only have automatically-pulled topics listings if there is a one-to-one or many-to-one relationship from your source metadata tags to your target groupings.
This probably sounds a bit too academic, so let's look at this in concrete terms. Let's consider the case where you have a bunch of articles tagged to either broccoli, apple, or orange. If you wanted to have a vegetable topic page and a fruit topic page, then this would work fine. This is because you have a one-to-one mapping from broccoli to vegetable (broccoli is always a vegetable), and a many-to-one mapping of apple and orange to fruit (both apple and orange always map to fruit and nothing else). That said, you cannot have red and green topic pages based on the existing tagging. Broccoli is always green, so if the only tags you had were to broccoli then you would be fine. But the apple tagging is the problem: an apple can be either green or red. Obviously, you could introduce a new color tag, but if you had a large number of existing pieces of content then you would have a large amount of retagging to do.
This may be obvious when looking at three tags and a handful of possible topics pages. But when looking at larger repositories and the possibility of creating topic pages with some automated pulls, consider the mappings to ensure you end up with relevant topics pages.
--------------------------
Need help setting up or fixing the processes, functionality, metadata, or other aspects of creating topics pages on your site? Contact David Hobbs Consulting.
Bookmark/Search this post with
