This realistic Sitecore implementation timeline can keep you out of trouble.

Jan 8, 2017 | MVP, Sitecore | 0 comments

Let’s be honest – website re-designs on any CMS platform are complex projects. Brands start off these projects with enthusiasm and energy, excited to launch a new online presence, but as the timelines drag on, that energy (and support for the project) wanes. Here’s a more realistic view of what a Sitecore implementation timeline actually looks like.

Make-Believe Sitecore Deployment Timeline

This graphic is meant to represent a common over-simplified Sitecore implementation timeline. This may be the perspective senior leadership or those outside of the organization have for your website re-design.

As a marketing technologist, I know it’s important to help others, both inside and external to your team to understand what’s involved in a website launch project. This post seeks to aid you in your task of educating and managing expectations of your organization.

First: The Over-Simplified Sitecore Implementation Timeline

I don’t expect others to be experts in the Sitecore CMS or technical projects like CMS builds. As a marketing technologist, that’s my job. It’s also my job to inform my organization and manage expectations, and that can be a very tricky and complicated proposition for a website re-launch project.

Over-simplification of projects aren’t necessarily bad for those on the outside of the project. They have their jobs and responsibilities, and if their core skill sets don’t include marketing technology, then the details of a project will just be “noise” to them. However, a correct and realistic view of the project is important to its success.

Overly simplified projects often have three key phases. Those three phases are described below, from the perspective of project outsiders, executives and non-technical team members.

Phase 1: Design

Website launches can be incredibly exciting for a company. They don’t happen very often – usually only once every few years, but when they do, they’re a big deal. A lot is riding on a website launch. After all, the website is the front door to your company in many cases. It’s important that you get this project right.

Design is one of the most exciting phases of a website project because you get to see something tangible begin to form for your new site. The “business” wants to rush to this stage because, in their minds, the project is a black box until they can see something.

In a simplified timeline, what’s designed is often a unicorn version of the site. It’s a site design not grounded in any reality. It’s a design that isn’t informed by content, data, user experience or editor experience. Prematurely rushing to the design phase causes all kinds of issues later on, and those issues can be quite costly in time, resources and budget.

Phase 2: Build, Deploy, Launch

The build, deploy and launch phase is really just a black box to those outside of a Sitecore build project. This is especially true if you’re working with an agency.

Once the design is finalized, you had it off to “the developers”, they do their thing, and magically a few weeks or months later the site is delivered, ready to go live.

In reality there’s a ton of work that goes into these phases of the project. Oh, and don’t forget about content, right?

Phase 2: Socialization

In my experience, the socialization phase is often at the tail end of a project in the over-simplified project plan. The site is live and it’s time to inform everyone (internal and the public), “oh, by the way, we launched a new website“.

For large website implementations, the light switch approach to deploying your new site can be especially problematic for end-user website visitors. If they became accustomed to using your site in a certain way, any change may be frustratingly disruptive to them. With large deploys, I like a public beta phase so that your customers and end-users have an opportunity to see what’s coming and get used to it before you “flip the switch”.

Your co-workers and other teams within your organization will also feel frustration if they’re not involved or aware of the project until near the end or after a launch. They’ll feel like they were left out of the process and their needs won’t be addressed. Even if not intentional, their exclusion from the project and lack of awareness is sure to create a lot of extra work after launch in order to mend fences and plug functional and content holes.

An Introduction to my Sitecore Module & Product Idea.

I created this project to act as the "hub" for all posts related to my Sitecore MVP pursuit and my Sitecore product idea. My first post is an introduction to the series and is titled, "Pursuing Sitecore MVP - My Sitecore Product Idea". As I post more segments to this project, they will all be included here. You can follow along on my Sitecore MVP journey from start to finish.

A More Realistic Sitecore Implementation Timeline

Reality Check: A More Real-World Sitecore Implementation Timeline

Reality will eventually set in on your project. Sure, you can launch a new Sitecore site in just a few weeks. You can launch your projects on or under budget. It can happen – but it’s not the norm, and the most frequent cause is unrealistic expectations at the beginning of the project.

Failure to plan is planning to fail.

Infrastructure Planning

Planning for your new Sitecore CMS’s infrastructure is one of the first areas inexperienced teams overlook. Sitecore requires a number of infrastructure components to operate:

Sitecore Licensing – It’s best to understand how licensing for Sitecore works as early as possible before your begin your site build. Will you be utilizing perpetual or consumption-based licensing? How many concurrent editor licenses will you require? How many database and content delivery servers are needed – for production and non-live environments? Oh, and don’t forget about licensing for add-on’s like Sitecore XP, Sitecore Experience Accelerator (SXA), Federated Experience Manager and other elements you may assume are accounted for or included.

Sitecore Server Infrastructure – This goes hand-in-hand with your licensing needs. You’re going to need somewhere to run your Sitecore environments (yes, plural). Will you go with on-premise or cloud hosting? If you’re launching with Sitecore 8.2.1, you may want to consider Microsoft Azure hosting. You’re going to need a MongoDB server for all of that XP data as well. You should have this all planned out before you get too deep into your project.

Requirements Gathering

Whether your Sitecore project will be agile or closer to waterfall delivery, you still should take the time to think about and document requirements. What must your new Sitecore site be able to do? What would you like it to do? What are your stretch goals and features? It’s a bit more effort than just jumping right into design, but it will be worth it in the end, because UX doesn’t always produce the necessary functionality without guidance from strategy, first.

Minimum Viable Product (MVP) Definition

I’m a huge fan of defining what your minimum viable product (MVP) would look like. This is especially useful when you’re looking at tight timelines and large Sitecore builds. If you need to get something out the door quickly, define your minimum launch criteria before you begin your build. Work toward that initial product launch before starting any major work on your “stretch” features to ensure your timeline is met.

Specifications & Documentation

I spent a good portion of my career focusing on technical documentation and specification writing. It’s not glamorous work and is often one of the first elements of a project to be skipped. Specifications and documentation about how or why something is done a certain way takes time and therefore, money.

Not having functional or technical specifications may not doom your project launch, but you may feel the pain after launch. What happens if your product manager or lead developer decide to leave? All that knowledge goes with them, if functionality and technical build aspects of your Sitecore project were never documented.

The Story Behind the Photo

Sunrise over Las Vegas, NV

The featured image on this post was taken at sunrise from the balcony of my room at The Cosmopolitan of Las Vegas, NV. I had a view of the mountains west of the city and couldn’t help but notice my “tunnel vision” view between these two glass buildings.

The Cosmopolitan of Las Vegas

UX & Design Iteration

  1. Design
  2. Build
  3. Test
  4. Deploy

This is the over-simplified, 30,000 foot view of a project, but I’ve never been part of a Sitecore project that followed this path. The projects that I’ve been involved in looked more like this:

  1. Design
  2. Review
  3. Re-design
  4. Tweak that design
  5. Build
  6. Oops, found a problem, so another tweak to design
  7. Finish the build
  8. Test
  9. Missed a design element, so add that to phase 2
  10. Test some more
  11. Deploy

My point is that design iteration is necessary and should be accounted for early on in a Sitecore build project. You won’t get it (all) right the first time. You will have to go back to the drawing board – maybe even a few times. It takes more time to be thorough, but it’s always easier to account for a missing feature while you’re still pre-build than once you’ve already started.

Socialization

Socialization of a technical project like a Sitecore website build is related to, but separate from, engaging with other key stakeholders in your organization. Stakeholder meetings and brainstorm sessions seek to inform how the site will behave, how it will look and the goals it needs to assist in accomplishing. Socialization is more about awareness and acceptance than functional definition or design influence.

In my experience, it’s a lot easier to socialize something that you can visually present, but you shouldn’t wait until alpha, beta or launch before you begin the socialization process. I accept feedback during the socialization process, but I’m also careful to set expectations of change with those providing feedback during my socialization efforts.

Marketing’s Role in the Build, QA, Stage UAT & Deploy Phases

To marketers, these phases may still be a bit of a black box portion of your Sitecore project. If you’ve created, reviewed and approved specifications, there should be more insight into how your site is being built, but these phases are typically handled by “the techies” or your agency.

As a marketer, you play the role of the Sitecore product owner, so it’s important that you also participate in the build and QA phases. In the end, if the site doesn’t do what you need it to do, it’s on you just as much as it’s on the developers or agency that built it for you.

Launch Planning & Go-Live

There are more moving parts that go into a launch than you may realize, especially if you haven’t done a major website re-launch before. Here are just a few examples of areas you may not be considering:

  • Do you have a 301 redirect strategy?
  • Does your new site have an XML sitemap?
  • Don’t forget to submit your new sitemap to search engines!
  • Are your robots.txt instructions properly defined?
  • Did you remember your Google Analytics, Google Tag Manager, retargeting tags and other key migration elements?
  • Do you need to re-distribute your RSS feeds anywhere?
  • Have you speed tested your new site to make sure it’s optimized?
  • Your stage environment is set to “noindex”, right?
  • You’ve hardened your Sitecore environment for security, right?

Post-Launch Remediation

I’ve been on Sitecore projects that were very well planned, superbly designs, expertly built and deployed – and they still required remediation of issues after the launch. In my experience, it’s a good idea to have a bit of a gap between your deploys. This gap can be as little as a day or two or as much as a full sprint cycle (2-4 weeks). This will allow you to handle any major or minor issues that inevitably surface after your site has launched.

What do you think?

I’d love to hear your thoughts on this article about Sitecore project planning and timelines. A Sitecore build can be a very complex process. What insight can you add to help our next deploy go smoothly? Please leave a comment below or feel free to contact me with your thoughts.