Experience Sitecore ! | June 2022

Experience Sitecore !

More than 200 articles about the best DXP by Martin Miles

My learnings from project management and lead experience mistakes I came across

Recently I passed through a series of interviews for almost every of the top 10 Sitecore Platinum partners in the US. That was a wonderful experience, I learned lots about all these companies and their way of doing business. Moreover, I can definitely say now that organizations in their culture and temper are like humans - some are pro-active extroverts, while others are very pedantic process-oriented nerds.

One of the companies made me a set of a few ~1.5 hours-long interviews with a vice president baking me with lots of challenging but interesting questions, mostly management and business-related. As it usually happens, I keep thinking about it well beyond the time in the background, and my thoughts resulted in this post. I compiled that into a single solid dump of my experience, so here we go.


Take it as the rule of thumb: you have to spend resources on presale! The evaluation should be well detailed, not to receive a "negative profit" later. I remember a project when the assessment was done by the architect, who did not allocate enough time to study the Customer's processes in detail. He conducted most of the work "according to the standard", using the "best practices". As a result of poor quality assessment, the project received "negative margin".

At the stage of pre-sales evaluation of the project, it is necessary to provide a list of possible additional works (volume, cost, time). For example, a change in some indicators entails a restructuring of the entire model, which can take a significant amount of time, require the involvement of significant resources and cost decent money.


Integration evaluation also refers to the pre-sales evaluation of an upcoming project, but I emphasized this point intentionally.

First and most, you need to make sure that the systems do integrate with each other. Moreover, at the presale stage, it is crucial to find out as many details about the upcoming integration as possible: what systems, what protocols, buses, etc.

In another projects I took part in, the incompatibility of the external systems was discovered only at the stage of integration after work started. That resulted in the customer being unhappy with and additional labor costs for developing and configuring the alternative. Don't underestimate that!


Probably the most important stage with all the parties to be involved. Mistakes in the agreement may cost a lot!

1. It is crucial to ensure that the terms in the Agreement do match your resource plan. Why? It often happens that even at the presale stage of negotiating with a potential Customer, some additional clauses get added to the Agreement, and these changes get forgotten to be reflected into the resource plan. This is what happened in our project. The PM did not take part in the process of signing up the Agreement, and different participants in the process added each from themselves, but no one checked the compliance of the Agreement with the actual resource plan. As a result, a misalignment between the Agreement and Resource Plan led to time and labor losses that were not taken previously into account. Just doing an extra check would eliminate that loss and could save time and retain customer satisfaction!

2. When it comes to client training it makes sense to describe the learning process well in details in the Agreement. You may include a number of hours, topics, number, and type of users - also specifying business and/or technical users, as well as the list of attached instructions (including number, titles, etc.). No need to be ultra precise here, but the scope should be agreed upon and signed. Once in a time, our contract stated that we would provide instructions and provide training. But it ended up that the list of instructions and the amount of training planned by an Architect (why him, BTW?), mismatched the Client's expectations, and they demanded much more. This case is in fact a subset of the following point.

3. Try to avoid wording that could be interpreted differently. The presence of inaccurate wording may lead to ambiguity when the Customer insists on his understanding of the Agreement inaccuracies. According to the Agreement, during the data collection phase, the team supposed to hold an introductory workshop. However it turned out that no one knew what exactly should be shown. The customer expected that workshop to demonstrate the system in action with their actual data, so that potential users would understand how the system would work. Therefore preparation took a lot of extra time, not included in the initial project estimation. The lesson learned: when there is some uncertain clause in your contract with an unclear meaning or unknown implementation, it is better to immediately clarify what exactly this clause implies.

4. One more point relates to customer data or content. It is wise to specify that the Customer provides data in the required templates and formats in your Agreement. If that is not the case, then formatting/conversion work must be paid additionally. Once ago we had to load a large amount of data into the system. The Customer provided the data in the non-classified loose raw format. As a result, a large amount of labour spent on cleansing the provided data. That wasn't originally included in the estimate calculations and resulted with extra time and cost.

5. This clause is likely be found in the most of contract templates, however few people pay attention to it, sometimes delaying the deadlines. It pays to specify the deadlines or the amount of iterations for the approval. Any approval delays cause by the Customer should be recorded. By fixing these delays, you can win some extra time to adjust the deadlines if needed.

6. When it comes to change requests it helps to cap your maximum efforts in the Agreement. For example, stating that changes that require adjusting the architecture say more than 10% are provided for an additional fee. Most of the Agreement templates have this clause stated out in this or that way, though.

7. It goes without saying, however I spell it just in case. You must keep all communiaction with the Customer until the project completion and beyond a warranty period. Always note and take a record of any additional work outside of Agreement terms to be done to complete the project - at least time spent, reason, resources taken, etc.

Testing and Acceptance

1. All the acceptance criteria should be clear and known well in advance. 

2. When it comes to testing, the amount of effort should also be defined and signed well in advance. At least, types of tests, their order, and required resources from both sides.

3. It is often a case, when testing is due to start however the required access is missing or the testing environment is not ready, or not even provided (I am now writing about things to be provided by a Client) - this is to be recorder as mentioned before.

4. There might be more unpredicted cases like once the Client demanded most of their staff to take part in the delivery testing and the Agreement did not cover that case. The issue for us was that Client employees were in totally different time zones, which made us to adjust. Would that be predicted in the Agreement - there'd be a possible solution negotiated rather than getting this unpredicted at a cost of overtime for our Dev and Ops teams.

The above is just few of project issues I remembered but was still good to share.

My speech proposal for SUGCON ANZ: Developers' guide to XM Cloud

Developers' guide to XM Cloud

Over the last months, we've heard lots of insights about the newest cloud product from Sitecore - XM Cloud. Many developers have wondered about what would be their changes of scope and responsibilities, how would they work with this new SaaS solution, or whether would they even become redundant. 

There is nothing to worry about! This session is answering most of these questions and in fact comes as the most crucial developers' guide to XM Cloud, as for now. It explains the caveats of changes in the content lifecycle and local development routine, introduced new Headless SXA for XM Cloud, and new options for personalization. It will also highlight changes in the security model, and site search and give the best advice on legacy strategies and content migration. Finally, some practical experience with Headstart for XM Cloud and utilizing the new deployment model, so that it becomes live!

Getting started
  •     why SaaS cloud? what is the change?
  •     a brief overview of XM Cloud for developers    
Familiar tools that remain with you
  •     review of the process and deployment tools available to a developer
  •     local development for XM Cloud in containers
  •     customizing pipelines with XM Cloud
  •     leveraging SPE functions
  •     Sitecore CLI becomes "The Tool"
Editing Experience and Content Considerations:
  •     using Site Builder
  •     dealing with Pages & Components
  •     extensions catalog
  •     diversity of datasources: where can my content reside?
  •     migrating content from legacy Sitecore platforms
Changes in the security model
  •     Sitecore Unified Identity
  •     integrating 3-rd party services
Changes in search
  • where's my Solr?
  • what are the options?
  • plugging an external search technology
Dealing with the legacy
  •     are my legacy sites still compatible with XM Cloud?
  •     migrating headless site from XP to XM Cloud guidance
  •     EDGE considerations
  •     is my legacy module for XP compatible with XM Cloud?

SXA for XM Cloud
  •     new old Headless SXA - what's the difference
  •     new old rendering variants
  •     can we use headless forms on XM Cloud?
  •     a bare minimum to build Headless SXA site for Next.js
  •     starter kits available for you straight away
  •     leveraging Headstart basic starter kit foundation built for XM Cloud
  •     make your own module compatible with XM Cloud
  •     are the built-in rules enough to go?
  •     two ways of leveraging CDP/Personalize for a better experience
Deploying into XM Cloud
  •     Single-location? Will that affect my GEO-distributed authors team?
  •     Understanding terminology: deployment, project, environment
  •     Understanding Build and Deployment Service (how to trigger and its lifecycle)
  •     CLI along with DevEx plugins
  •     GUI-powered Deploy App tool and 
  •     auto deployments from connected GitHub
It looks to me like an excellent topic exposing a spotlight on the new Sitecore SaaS-based platform. Keep fingers crossed!