April 10, 2015
After more than 500 web projects, we've learned a lot, including common spots where you may have project risks. These are the top 6 to consider if you're launching a new web project soon:
So you're about to embark on a web design project; do you have a risk mitigation strategy in place? Do you know what you will do about migrating your content, enabling search or scaling the end result? The following risks and suggested mitigation strategies are some of the most common ones that we encounter in our work with clients.
1. Multi-year, multi-phase project
Embarking on a multi-year project requires that all stakeholders have a unified vision of what the solution/site looks like at the end of each phase. Your project discovery process needs to achieve this consensus. Incorporating exercises like journey mapping and discussions around applications lifecycle management and continuous deployment will help in ensuring that your entire team is on the same page from the get-go.
2. Scope and scale of content migration
Content migration is often underestimated. Once the information architecture is complete, we recommend that you begin the planning for the migration exercise. As a rule of thumb one person can manually migrate 20 – 30 pages of pre-existing content per day. Curious about how best to start planning for content migration? We've put together a helpful checklist to help you sure that you've got all your bases covered.
If you are fortunate enough to have your existing content stored in a structured way, automated migration may be a possibility, just keep in mind that will often require that the information architecture be similar.
3. Integration with cloud and on-premise applications
Early in a project the location of all the integration points may not be known – or may be in flux. This can often hide some of the larger technical, security and performance related risks. Our advice: nail this down as quickly as possible. If systems are in flux due to parallel projects, you may need to consider alternatives if the other projects’ timelines slip. Working on a Sitecore project? You're likely weighing your options of hosting the xDB on premises or in the cloud. While decisions on that front are always changing given the evolution of the product, we've written a post to help you make an informed xDB decision (or check out our xDB webinar)
4. New approach to regions/languages
The potential change of the regional/language approach from the current state may require significant change management. There is also a possibility that existing systems make assumptions about regional content that will require them to be updated if the approach changes. A lot of the work we've done in incorporating new regions or languages has been using Sitecore, which has developed great multilingual capabilities.
5. Lack of enterprise search product with content faceting
As user expectations of search continue to increase, the need for a true search product becomes more necessary. Thankfully something like Coveo for Sitecore is free to use, just make sure you set aside the time and money for the deployment, infrastructure and configuration. Training for search administrators would also be highly recommended. We're big fans of Coveo and tend to recommend it to most of our clients.
6. Loss of traffic, SEO impact
In order to ensure the new site does not drop the level of traffic, we would recommend that you inventory current incoming URLs and include in the content migration plan time to create redirects that map the old URLs to new URLs. We've worked with clients who've experienced serious search traffic decline and can tell you, it's not fun. We put together a 2-part blog series on our best practices for fixing the problem- how to identify the search traffic decline and how to recover from a post-launch search decline.
