Governance in Sitecore Projects
What is governance?
An action consisting of standard establishment and compliance auditing.
What is a governance team?
Traditionally a governance team is a group of people chosen by a business, usually including subject matter experts, to be an authority within its defined scope; such teams define rules and standards around the area of their assignment in accordance with business objectives and audit for compliance of other participating stakeholders.
The word “team” is frequently used with governance, as the practice is usually formally introduced only in larger organizations, where there is a need for more bandwidth than that of a single person to provide proper level of service. A governance team would be better thought of as a governing body, an entity, which may not necessarily be a team, which is the term I will use in the rest of this blog. Thinking of it that way makes many of the answers below easier to comprehend.
What is the purpose of a governing entity?
It is important to remember that the ultimate goal of such entities should be reducing the cost of building and maintaining one or more web presences hosted on Sitecore. Other goals stem from the cost savings – ensuring the implementations and processes around them are done in alignment with Sitecore and industry best practices and business objectives.
When do we need to create a governing entity?
Ideally prior to any work on Sitecore! Remember that the main goal of a governing entity is ensuring the development is done in accordance with the industry and Sitecore best practices, as well as aligning with business goals, ultimately aiming at cost savings. This role is required no matter the size, or number of Sitecore implementations. Whether it’s a single project or a Sitecore shared environment with multiple development teams supporting their assigned websites, a governing body is required. Therefore, for a single project it would likely be a single person, usually, an Architect, while in a shared environment scenario with multiple development teams – a team sized accordingly.
How big should the governing entity be?
This would depend on the number of Sitecore implementations and their complexity. On a single average Sitecore project an Architect or a Technical Lead would have enough bandwidth to play that role. I would estimate 10-20% of allocation per developer on a project for governing tasks. Thus a team of 4-8 developers would max out the daily bandwidth of a governing individual (assuming 80% efficiency in daily hours). These numbers would be lower for established Sitecore development teams and vendors that already have established standards and trainer personnel. Remember that governing isn’t training. It is standardization and audit. In a situation with multiple teams, some of the governance can be offloaded to resources internal to the teams, reducing the allocation per developer. The exact number here would depend on circumstances: number of standards, risk assessment, risk tolerance, cost savings…etc.. Remember that it does not make business sense to have a governance team that costs more than it saves, thus, the potential savings need to be calculated before forming the team and recalculated periodically, usually based on budgeting cycles.
How do we scale the governance body?
By delegating tasks to team leads and adding resources to the governing body. It’s best to recruit leads, or experts from the teams being governed to offload the work and reduce the governance cost. Often times that does not cause additional overhead on the leads, so the total cost will not go up as a result. Delegating governance tasks to teams that are being governed also promotes a bigger sense of internal responsibility, adds an advocate on the inside and encourages open and direct communication.
When adding resources their allocation should correspond to the estimated need based on calculations. The cost calculation answer below provides two ways of going about such estimations.
How to calculate potential savings of a governing entity?
Governing entity savings are hard to calculate, as their job is to eliminate problems and save cost as a result. What works well with any type of estimation and value calculation based on probability is multiplying the cost by its probability. In out case – predicting the cost of noncompliance to a single rule or a standard established by the governing body multiplied by the probability of it happening in a period of time with the sum of all these costs reflecting the potential savings. For instance, let’s take a look at the following standard that a governing body may choose to implement –
“Define standard project naming and namespace conventions and use them for all project, library and configuration file names, as well as root project folders in the file system.”
Noncompliance to this rule will result in a difficulty funding project-related code and configuration. This usually becomes a problem in troubleshooting scenarios, upgrades, and cleanups. Best case scenario – this would result in orphan front-end files, worst – unexpected behavior caused by a missed configuration file, which could result in up to 16 hours of troubleshooting by a Sitecore expert (add other overhead, if applicable based on business rules). The probability of performing an upgrade, troubleshooting or cleanup in environment X this month is 30%, as we expect to have a few relatively significant Sitecore deployments by a relatively new team (this can be ball-parked based on the backlog). Therefore, given a hypothetical hourly rate of a contracted Sitecore development resource of $165 an hour multiplied by 16 hours with an 30% chance for this month results in a potential cost savings of $792. This exercise should be done ideally for each requirement that would be established and audited for a time scale that makes budgeting sense. The sum of all the calculated cost savings would result in the budget that cannot be exceeded by the cost of a governing body. A short-hand educated estimation can also be performed based on the 10-20% allocation on a single project, scaled to a large team with other variables in mind. Although, the short-hand will not be as accurate, it may just be good enough when performed without bias.
What should be included in scope of a governing body?
- Coding standards
- General standards
- Frontend and backend
- Solution structure
- Application architecture
- Sitecore Content
- Disaster Recovery
- Sitecore shared configuration (shared environment)
- Network logging and monitoring
- Related processes (tickets, requests, escalations, conflict resolutions, reviews…etc.)
A governing body should select rules and consideration for a shared environment mentioned in one of the previous posts – Sitecore Shared Environment “Good Neighbor” Rules.
The exact rules to be included in scope of each topic should be evaluated based on potential noncompliance cost for a period of time. Remember, it all comes down to cost savings. Come up with a list of applicable standards, then trim it based on the calculation methods above.
Who should be included in the governing entity?
Needless to say that Sitecore expertise should be included in the entity. Ideally an experienced Architect or an MVP. Additionally, there should be business knowledge presence as well in order for the entity to act in the interests of the business and be self-governing.
The governing entity can be dedicated – an Architect on a project, or a team of dedicated experts, or decentralized – comprised of representatives or Subject Matter Experts from the governed teams. There must be representation of expertise for all governed topics mentioned above, or at least the expertise must participate in the rule creation and can be brought in on-demand. Relatively large governing bodies would ideally be hybrids – including members from all teams and business.
What if we put wrong people in charge?
It is important to have a closed feedback loop. One of the pit falls of governing bodies is that they tend to become “untouchable” over time. This is a precursor to bloat and bureaucracy. All governed resources should be in a position to provide structured feedback, challenge and overrule a standard imposed by the governing body, if their specific circumstances justify the cost benefit balance, or if they can prove imbalance in the cost-benefit ratio. Therefore, periodic retrospectives involving team members based in individual and optionally anonymous feedback is strongly encouraged.
The governing body should play the role of leadership, not management. Other teams ideally should be willing to follow the governing body based on their expertise, expertise and business domain knowledge, rather than blindly following the rules. All resources should be able to challenge and may ask for a justification behind requirement. At the same time, the governing body should respect such challenges, as there is always an element of human error present and the ultimate goal should be getting to the truth, not being right. This is especially important if the governing body consists of a small number of resources, which may instill a strong bias and illusion of knowledge that’s difficult to challenge. Governing bodies should always be open to challenges and feedback.
Final thoughts on governance in Sitecore and in general
The most important take away from this should be that governing bodies are needed to save on long-term cost of running a Sitecore website and everything should stem from that. One factor that is hard to account for in cost savings calculation is progress momentum and agility. Rigid and complex rules, just like bureaucracy, slow down progress. The hidden cost of such delays is hard to recognize in day to day business, however, it frequently exceeds the cost of making an occasional error by noncompliance. There is an entire industry created to speed up progress – DevOps, so it’s a big deal.
To solve this, once the list of standards is created, before it is finalized, gauge the amount of drag it would create on developers being governed and sanity check it periodically.
Once the governing body has been created there are generally a few way in which things can evolve – the team remains balanced and the value to the business is preserved, the body grows and creates unnecessary bureaucracy, or the team promotes governance delegation and self-governance, reducing the governance allocation per developer. The third should be the goal of each governing body – encouraging self-governance with periodic reviews, however, too often the second one takes over, especially when IT has too much influence in a company. The business paying the bill should be diligent and provide proper cost-related audit to ensure the governing body is not bloated and does not create unnecessary drag.