Sitecore Road Mapping: 7 Steps for Success

Don’t be the organization that neglects to create and execute on a roadmap and ends up in massive technical debt. These following steps apply to non-Sitecore projects as well as Sitecore and are intended as a starting point to get your organization communicating and executing in a manner that allows for efficiency, collaboration, and staying up to date with technical trends and platform offerings.

Step1: Establish and Maintain a Governance Committee

If no one takes ownership or communicates about your platform, you don’t have a platform to roadmap about. Step 1 is all about establishing and maintaining a governance committee with clearly defined roles and responsibilities. This committee should meet more regularly at first (weekly, if need be, to get started) then settle into a monthly cadence with escalation procedures for issues that come up outside of the meeting cadence.

Specifically, the Governance Committee is responsible for establishing policies, standards and continuous monitoring and management of the Sitecore environment. Roles and responsibilities are as follows, bearing in mind that one individual may have multiple roles, especially in smaller organizations:

Executive Sponsor: Influencer with budget approval or budget submission/advocacy

Business Owner (Committee Lead): Chief organizer. Acts as a Project Manager for the Governance Committee. May be, or work with, the Executive Sponsor on initiatives requiring approval

Sitecore Administrator: In charge of the Sitecore ecosystem. A mix of development and Sitecore architecture/operations/infrastructure experience

Network and Infrastructure: Lead In charge of the infrastructure supporting the Sitecore ecosystem, and any integrations that affect Sitecore (ex. AD Integration). Works closely with the Sitecore Administrator

Sitecore Development Lead: Lead developer. Might also be the Sitecore Architect. Focused to DevOps and Release Management

Sitecore Content Manager: Lead content editor/manager. Works closely with the Marketing Manager and may have Digital Asset Management (DAM) responsibilities

Sitecore Marketing Manager: In charge of Sitecore Marketing Campaigns. Will work closely with the Sitecore Architect, Developer, and Content Manager on campaigns

Internal Communications Lead: Chief communication individual for the organization. May not be the one who actually sends the message, but one who is responsible for crafting and following up on communication campaigns

Step 2: Document Your Current Systems and Integrations

You can’t roadmap if you don’t know what you are driving down the road. In this step, you perform a current state analysis… thoroughly documenting your systems and integrations in a centralized location that is:

• Accessible
• Readable
• Updatable

Once you have your systems documented, you can always update and add to the documentation. This step is often one of the most painful and what organizations tend to avoid. However, those who invest in creating and maintaining systems documentation often find that they:

• Reduce technical debt by identifying and consolidating systems
• Have less “site down” issues as they understand what lives where and what its purpose is
• Enhance cross team collaboration

Step 3: Create and Update Your Governance Policies and Standards

Governance policies and standards are the bread and butter of a successful platform. These clearly define the what and how of everything from installation, DevOps, and communication… to escalations and disaster recovery. Instead of waiting for your new platform, it’s imperative to document how you currently manage your platform, as this will capture the tacit knowledge currently floating around the organization.

Why is this required for road mapping? Without defining how you approach and manage systems today, you will likely miss invaluable information of how to manage what will come tomorrow. Again, this takes work… but is meant to be centrally managed and accessible.

Policies define rules for Sitecore use; standards describe best practices. An example policy is “All users must login to the Sitecore CMS securely” where the standard is “The CMS resides in an application tier where only AD authenticated users must use VPN to access the CMS URL”. It is basically a “what” and “how” breakdown.

Here are some resources to help with your Governance endeavors:

• Sitecore Governance: How To and a Template Too
• CMS Governance Is Scary… And What to Do About It
• Using the R.E.A.C.T. Method for Better Governance Policies
• Sitecore Release Governance for Better Production Stability
• Got Redirects? Successful Redirect Governance in Sitecore

Step 4: Use Business Requirements for any Technical Decisions

Don’t let platforms and new tools determine your requirements! The aforementioned steps lead into establishing actionable business requirements by ensuring you have a group of people who understand and are stewards of your system, documentation of what you have today, and policies for how you manage the platform.

With these in hand, you are far less likely to fall into shiny object syndrome when the salespeople come promising perfect platforms and tools to meet your every desire… because you will know what you need!

Define what your business requirements actually are… keeping in mind that “using all of our platform” or “doing the latest and greatest” is not a requirement. If you happen to “use all of a platform” it should be a byproduct of business requirements that use the entire platform and not vice versa.

Good business requirements should be data driven and focused on improving items such as conversions, user experience, platform security and support, modernizing development standards, or expanding upon your offerings. No matter if you are Non-Profit, Government, or Private Industry… you are offering something whether that is a service, providing information, or selling your products.

Step 5: Document and Update Your Roadmap While Evaluating What Your Platform Vendor Has in their Roadmap.

With your business requirements in hand, you are now ready to roadmap! A good roadmap must be objective, contain reasonable timelines, have resources allocated, and include research into what your platform vendor has coming up. This will allow you to naturally update your roadmap as your platform and requirements evolve. Without this forethought, road mapping is often a hurried process (usually performed by an outside party) that adds to technical debt or provides platforms/tools that do not need meet your business requirements.

If you are using Sitecore, for example, you may find that some of their composable options align to your business requirements and should be added to the roadmap. In other instances, you may have done your “buy vs. build” analysis and discovered that you have more unique needs than a platform or tool can provide. This is why it’s critical to stay lock step with your platform vendor, or evaluate other vendors, to determine if their offerings meet (or exceed) your needs.

Whatever the case, your roadmap is worthless if you can’t execute on it (more on that in the next step), so ensure that you set clear expectations and a “definition of done” for any project you plan to undertake.

This includes resource allocation. If you lack the resources (financial, personnel, or experience) you should not in good faith add a project to your roadmap.

When road mapping, its critical to be conservative… because something will come up to potentially derail projects. Far better to under promise and overdeliver when it comes to projects.

How often to roadmap is a common question, and instead of a rushed end of year effort, you should dedicate time to establish your roadmap once then use your Governance Committee (established in Step 1) to review/remove/add to it each month. This iterative process will ensure a smoother flow, and while choppy at first, you will gain efficiencies with time and collaboration.

Step 6: Execute Using Proven Project Management Practices

Not enough can be said on this on this topic, but here are a few key points:

• Don’t go for straight Agile if you have known variables… rather use “Scrumerfall”
• If you are spending all your time managing your PM tools, processes, and not building… your process is too complex, and you are not getting actual work done
• Constantly communicating inside and outside the team is the key to project success
• Technical debt takes time to pay down
• Don’t skip steps as remediation is often 3.5 times the effort/cost

In essence, you should establish a Project Management Office (PMO) and ensure that your projects follow the same standards, improve upon said standards, and maximize collaboration across teams instead of wasting time rebuilding or creating new processes every project that are unique.

If you want to execute at a high level, its far better for all project teams to follow the same process and “be doing it wrong” then trying to manage all the project teams using inconsistent processes… as once you fix a bad process, it can be applied across all teams. Your teams will also share lessons learned that can be applied cross project in an “all ships rising together” methodology.

Why is all this so important to road mapping? Simply put, if you can’t execute with efficiency and scale… you may see the road in front of you but be stuck idling and never get to your destination.

Step 7: Repeat Steps 4-6

With Step 6 complete, head back to Step 4 and review what data driven business requirements have arisen or changed. Have I mentioned data driven!!!! Don’t base your requirements on things that don’t bring value to your organization. Successful road mapping depends on objective and clear requirements that improve your mission. Technology platforms and tools are just the vehicle your organization drives on its journey.