Signs that Your Sitecore Implementation Project is in Trouble

Marco Tana Marco Tana
February 22, 2013
Sitecore , Web Development

I have to warn you now that this first part is going to be a bit "salesy" and self-indulgent. The thought is that if the signs I mention below exist within your Sitecore implementation, you may want to call us. There, I'm done with my plug and on to the real story. Remember, this post is really meant for implementation teams to catch issues early and mitigate them before they get worse.

In the past few years, with Sitecore's growing customer base, we've had a tremendous increase in Sitecore implementations. Unfortunately, some of these projects were rescue missions. We've heard stories of Sitecore clients not liking the CMS anymore because it's so hard to use, it's not flexible enough or it's unreliable. Well, all I can say is that if you first install Sitecore out of the box, the software is definitely easy, flexible, and reliable. So, what's missing?

With Sitecore's open architecture, it provides powerful ways of achieving your goals. But with great power comes great responsibility (hmmmm...I've heard that before). Notice that I said "goals" in general and not just technical ones. With Sitecore, you address not just your technical infrastructure but also your business objectives for marketing purposes as well as process-oriented operations like support and recruitment. You need to think beyond just your current site project if you wish to fully realize your investment. In addition to inexperience of implementation teams, not planning for what the CMS can do for your company can spell trouble. Here are some of the signs to look for to know if your Sitecore implementation project is about to go haywire (I'm not going to mention typical project management issues such as budget and scope creep, as those are meant for a different blog post).

Forgetting to Support Page Editor Mode

Page Editor is one of Sitecore's selling points and Sitecore sales always demo it. Therefore, your stakeholders are looking forward to use this. Make sure that your components are flexible. Even your HTML/JS/CSS needs to be aware of Page Editor. Page Editor is so extensible that you can even create your own dialogs to make the authoring experience better. You may not need to get that far in most cases, but it's something to consider when figuring out how much you need to make a particular component easy to work with.

Not planning for an additional website on the same Sitecore instance

Sitecore is capable of managing more than one website. I think we all know that. When you are building the first site in a new instance of Sitecore, make sure you consider that another site may be implemented. This means you need to ensure that your assets (both files and Sitecore) are logically structured to make support and future enhancements a lot easier. I've seen implementations where multiple components have been defined even though they do the same thing.

A simple page (mostly text) takes too long to load

If you're loading a page that's mostly text such as a Privacy Policy Page and it takes forever to load, then you know there's a more substantial problem with performance. It could be a simple tree traversal that takes too long because now there's more content in the site. Or, you're looking for the closest store even when you don't have any location information about the user. Just remember that any "global" components like the header and footer are normally the culprit (outside of your layouts).

You're coding without knowing what the deployment scenario looks like

You might wonder why this matters. For example, if you are asking for comments on articles, it’s easy if you have a one server deployment scenario. However, if you separate the authoring and the deliverythen that makes it a bit more complicated, especially if you have a firewall in between. Not too complex, but if you didn't know about it ahead of time, then a re-code may be necessary.

Design is still in flux while in development

Sometimes this happens because the project is either behind or it just wasn't planned right. You must be aware that the design of the site puts a bunch of items in your requirements list outside of the just technical part. Some of those design requirements are implemented through Sitecore data templates and when those change, a lot of other things change (i.e. renderings). You can still accomplish simultaneous design and development (like we do in sprint-based projects), just make sure they're in a stable state.

What about content migration?

Yeah, what about it? Are your authors manually re-entering all the content? Are you creating a migration tool? Is a tool possible? Is it more expensive to develop a tool than to do it manually? Does the existing content need to be modified/checked? URL redirects? So many questions...so little time because at this point (if you didn't plan for this), launch is around the corner. Speaking of content migration, you may want to check out Aaron’s detailed post regarding the topic.

Authors are entering content without training

I think this is obvious. If you plan for a one hour knowledge transfer, then you might be in trouble. It's true that your authors can learn Sitecore by reading a book or taking a class but what they can't learn is how you used Sitecore to implement their website. Generic Sitecore training teaches them how to use the Content Editor, Page Editor, and other UIs. But it won't teach them about how to enter a FAQ page. That's up to you to show them.

Authors think there are too many steps just to post a news story

Although Sitecore is arguably easy to use because it mimics the typical Windows environment, it still adds a level of technical knowledge to fully use it. If you are implementing a news story and your author has to remember too many content rules such as where to put it, to create a new folder for related videos and images, to put a style class of "quote" to highlight a sentence, and so on,you may want to rethink your content architecture. The CMS is meant to be easy to use, don't complicate it by over thinking the content structure.

Finding content is not intuitive

This is somewhat similar to the previous point but is focused more on your content organization. Organizing content can have a huge impact on the flexibility of your Sitecore instance, performance of traversals, ease-of-use in the perspective of an author, and complexity of your code. You might mention Item Buckets because they introduced "searching" for content. But, Item Buckets are meant for large repositories that are normally not hierarchical; instead you use tags (even though you can use the search mechanism on any part of the content tree).

You seem to be coding every requirement

Stop and think if you've coded every business rule that you've encountered. If that's the case, you may be over-customizing Sitecore to a point that upgrades and other enhancements become difficult if not impossible. You may need some convincing to use Sitecore's native capabilities. If you do have to code them, make sure you look at best-practices on how to add new features. Look into pipelines, extensions, providers, and others. Sitecore utilizes these techniques and if you follow them, you're customizations should be compatible (maybe with some tweaking or just re-compilation).

I'm sure there are other red flags to keep an eye out for, but I think this is good start to see how you're Sitecore implementation project is going. Make sure to watch out for these before your project gets the axe.

comments powered by Disqus

STRATEGIC PARTNERS