Skip to content
May 30, 2017 / kiranpatils

The Sitecore Basics Test : Symptoms of failing Sitecore Project

I have been fortunate enough to work on Sitecore projects since last 8 years of my overall 10 year’s experience. Throughout 10 years – I have  successful/unsuccessful projects.

I thought to prepare a list which helps you to identify [If you want to ;)] whether your Software project is failing or not and I like this article a lot — – Great test!

Recently I was reading Peopleware — It has the first chapter “Somewhere Today, a Project Is Failing“. – They did research on 500 projects — which they measured on project size, cost, defects, acceleration factors, and success or failure in meeting. Stats are as below:

  • 15 % : Canceled or “postponed” or they delivered products that were never used
  • 25% : For bigger projects, the odds are even worse, they lasted 25 work-years or more failed to complete

In earlier surveys, they discarded these failed data points and analyzed the others. Since 1979, they have been contacting folks who left from projects to find out what went wrong, Most part of the projects they studied, there was not a single technological issue to explain the failure.

I thought to compile similar set of list for Sitecore projects – Because while I’m writing and you are reading – Somewhere Today, a Sitecore Project Is failing.

Before we start would like to mention few things:

  1. Joel’s list is the base class for this list — Because Points which Joel has mentioned applies to any kind of project
  2. Will derive from Joel’s list and jot down my observations specific to Sitecore – It might fit or might not fit for your organization — Please use your own judgement [Listen your team’s views – Analyze – Conclude]. Before you derive something. If you have more better steps — please share

I’m excited to share what I learnt in 8 years, which you might learn in 8 minutes – That’s why I’m born – Born to share – Here we go:

Just a note : These symptoms applies to all kind of projects — Product/New Project/Enhancement and Support Project

  • Tough to onboard new Developer : If on boarding new developer is taking weeks or people say – No, we can’t onboard new developer new Developer in crunch time without logical reasons and gives you a reason that on boarding will take time from project developers or will take weeks. Then this is a sign of failing Sitecore project. This means everything is unmanaged. No one has documented on boarding steps [They are insecure?!] or current developers configured their Development environment anyhow and now they don’t recall what they did. My rule of thumb is — In 4-6 hours [Vary based on project’s external dependencies e.g. Commerce, SOLR, etc] and a document should be more than enough to onboard new developer. If your teams says No — Take a step back, listen their reasons. And analyze it.
  • Sitecore Developers don’t know what they are doing : During demo/in meeting, when you ask in-depth “Why” [Is this the best way to do this in Sitecore? Is there a simplified way to do this?] questions and Sitecore Developers can’t explain you in simplified manner — Something is not right. It’s time to get right partner/developer onboard!

  • Huge Estimates : When you see huge estimates for simple set of tasks, It means that things are not rightly architected If project is new then it’s fine. As building robust framework takes time. But if it is taking longer for later sprints or for support and enhancement – Then you need to talk to your team. Again, It might be a case lead Developer has left and new Developers are trying to understand and implement solution – This is fine to have situation – And each project has a bit of learning curve, As there were no defined Sitecore project architecture standards — It was different company by company or in some cases project by project. And that’s why Sitecore and Sitecore community is excited to learn and implement Helix You should come out of cave, If you don’t know about Helix and read about it!



You might have smart developers onboard on project. But past implementation has been super tightly coupled, One change can break N number of things or ruin someone’s evening plans or weekend 😦

  • Developer spends more time in figuring out “What” And “Why” then “How” : Your requirements are super vague. To work on feature A which is in reality 4 hours task. Developer spends 6 hours figuring out all material and still not clear what exactly needs to be done. As soon as he/she knows they are able to complete work in less than 4 hours. Other symptoms are – Team is more busy in meetings than being in zone – Scrum runs for hours and hours, Sprint planning runs for hours and hours, With whole project team. If you hearing <1 Man day task in next day scrum without any blocker — Then something is not right OR Your team is performing less than their capacity/velocity — Then you should talk to team!. Another sign is — If you ask two team members about Project schedule and you hear different answers — It’s time to talk. [Good read — About Watermelon Culture]
  • Developers don’t have good tools : From my point of view Sitecore Developers must need to have some good tools e.g. Reflector [My personal favorite], TDS Classic, Glass Mapper [If your team is still handy crafting models and not using code generation then they are investing their time in wrong things] etc.
  • Sitecore Items are not version controlled : This is the biggest sin from my point view. Your Sitecore items are as important as your code [In some cases more than code].  Can you imaging Software industry without version control? I know you tried that in college project[.zip of .zip, final .zip, .backup of .backup :)] — That doesn’t work – We are professionals. You are in to serious business — I like this chapter from 97 things every programmer should know book  :

“Professionals do not make a mess. They take pride in their workmanship. They keep their code clean, well structured, and easy to read. They follow agreed upon standards and best practices. They never, ever rush. Imagine that you are having an out-of-body experience watching a doctor perform open-heart surgery on you. This doctor has a deadline (in the literal sense). He must finish before the heart-lung bypass machine damages too many of your blood cells. How do you want him to behave? Do you want him to behave like the typical software developer, rushing and making a mess? Do you want him to say: “I’ll go back and fix this later?” Or do you want him to hold carefully to his disciplines, taking his time, confident that his approach is the best approach he can reasonably take. Do you want a mess, or professionalism? ”

Please read this :

“We have found TDS Classic easily affords an 8%-15% decrease in costs (time) to develop a Sitecore solution regardless of the size of the project. A 10% savings over 30 weeks for a 3 person team is 9 weeks of gained productivity. If the average team member salary is $75k per year this represents approximately $13k in savings.”

If you have budget constraints? Sitecore community folks have done lot of good things – Especially Kamsar‘s Unicorn

I love Sitecore items to be Version controlled because:

  • Developers can have their own Sitecore Database copy
  • Which is blessing when you have Developers who are connecting over VPN to your shared Database — VPN is still not the best solution our industry found
  • They can make Sitecore level changes without breaking anyone’s challenge
  • This is the first step for automatic deployment
  • Everyone is accountable
  • Easy to track, compare and revert!
  • Sitecore Configuration Patching is not used : This is also super important to have. Sitecore configuration patching helps you to keep your Sitecore configuration changes in control for development, deployment, troubleshooting and version upgrade. The day your configurations are out of your control — You are done!
  • Deployment makes your nervous : Obviously, when you say – Live/Production deployment people feel bit nervous. But each time it makes you super nervous and you have a lot of deployment failures/revert – This is sign of some loophole in system. It can be either process, wrong implementation, folks don’t know what they are doing, no/less code reviews, tightly coupled code, QA is not involved in project. Any Developer goes and deploys files in lower environment/in some cases production/live environment. No one takes a lead to take a lead on deployment failure. No one wants to retrospect. I have worked with a team, Where when you say production deployment. They start planning for party — Because they have full confidence on what they have done in their local machine/lower environments, is nothing but a master piece of professional and elegant work! If your deployment is still manual and runs for hours and hours [Think of Web farm with 20+ servers] then you need to stop development and start thinking to automate or semi automate your deployment process OR If you can’t automate please simplify the process. Discourage tame to make last-minute changes or change go live date.
  • No proper handshaking between teams : I always visualize Sitecore Development – Deployment is same as like Assembly line.  If one player/team is slow. It will slow down whole process. [Read The Goal book?]. It’s not because of technology. But no proper team environment. There are teams within teams. UI Developers should always be ahead of Backend developers and QA should be always ahead or aligned with backend developers. QA should be involved in process at right time. I always prefer to have BED and QA work parallelly – Developer writing code and QA writing test cases.

  • Site performs poor without caching :Sitecore being an enterprise level CMS provides state-of-the art Sitecore caching. But lot of bad implementation tries to hide behind Sitecore caching – I always prefer to do load testing without Sitecore caching. If you can meet your thresholds during this then you will be able to beat your competitors when you go live! Also, It’s always good to have time for performance testing and tuning (Another gold mine is your Sitecore log files – Great Sitecore Developers always prefer to check log files before they Go-Live for Project/Product/Sprint). If your team says – We don’t have time for performance tuning — It’s time to talk!
  • Content authors need a lot of hand holding or coming up with lot of questions : This means things are not simplified enough or Sitecore’s OOB features are not used e.g. Add Rendering, Placeholder settings, Data source etc.
  • All plans fail without Content Matrix Plan : If you are ensuring UI, Backend, QA, Servers, DevOps folks, Process everything is good. But in case if you missed to plan, Content management/entry for your huge site — Then your project will get delayed. Because content management is also a critical task. If you have a new site and there is a lot of content your content team should start adding content as soon as they can

Found helpful? I repeat, this is not a fully comprehensive list. I’m sure you will have your learnings which you should share with us — So, you will be able to save that failing project.

Happy Sitecoring! 🙂



Leave a Comment
  1. kiranpatils / May 30 2017 10:48 am

    Image Credits :

  2. Andy Burns / May 30 2017 3:08 pm

    Some of those sentences are a bit hard to parse, but it spurred some thoughts.

    Point 1 is sort of related to Brooke’s Law (, which every dev has experience of; that’s probably why you’ll get negative feedback when trying to add resource to a late project.

    I’ve also yet to see a non-trivial project such that the documentation can ramp me up and get my development environment set up 4-6 hours. Good docs can help – but even then there’s usually more of a cost than that, especially when you include trying to coordinate with the rest of the time.

    But that’s just my experience.

    Your point about requirements is, I think, absolutely key. Too often requirements are very vague, and often nobody reviews them and excludes requirements like “Speech recognition built into the web page”, “Artificial Intelligence to know what I want it to do without my telling it”, “99.99999% up time” and so on. Those are all real example of requirements that have been handed to me as a developer.

    That last one means 3.2 seconds downtime a year, by the way. They didn’t want to pay for 2 content delivery servers, either.

    Wiegers has an informative book about Software requirements, and one of the things I took away is that requirements need to be reviewed and agreed up. Just ‘cos a customer decides a system should fart rainbows too doesn’t mean you have to agree to it.

    That should leave the devs to then focus on “How” rather than “What” and “why”

    I would also take issue with “test without caching turned on” – what if the issue is related to the caching? For example, controls or data being cached that shouldn’t be? You won’t pick that up in testing if all caching is off. (I’ve seen this happen, too). Just a thought.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: