Common Risks in Sitecore Projects

Sitecore Project Risks

Project risks are common in the IT industry, and they should be an important part of project planning. Project teams need to identify possible issues before they happen so that they can address them as early as possible. This blog describes some common types of risks that a project team might encounter working on a Sitecore project.

There is a number of risks common to any type of technology project. These include:

• Lack of planning and clarity/Poor communication: Poor planning at the beginning of a project can lead to vague goals, requirements, and scope, unclear and ambiguous communication surrounding deadlines and milestones, and unclear budgeting needs.
• Scope creep: Scope creep is one of the most common risks on any type of project. It happens when the initial project objectives are not well-defined. It is the unexpected addition of additional features, cost overruns or schedule delays to a project.
• High/unexpected costs: Cost risk is when a project goes over the budget initially set and agreed upon. It's usually caused by the previous 2 risks mentioned earlier. Unrealistic or lack of detailed budgeting in the project planning phase, and/or scope creep during the project's lifecycle.
• Scheduling risks: Cost and scheduling/timeline risks usually go hand in hand. Teams oftentimes, during the planning phase, underestimate the work they need to deliver, due to various reasons, and as a result the estimated timeline does not properly reflect the work that needs to be delivered within the agreed upon time frame.
• Operational changes: Operational risks are any changes or disruptions in a company's or a client's business environment. These changes can often bring new system processes, personnel or role changes, or company policy changes that the project team must adapt to.

Other than these common risks we usually see some other more specific risks to Sitecore projects:

Content Authoring and Content Migration

Many clients underestimate the effort required to move, create, or curate content when developing a new website, or when re-designing/re-developing a website. So it comes as a surprise to them when they realize that content authoring and migration can very quickly become the biggest risk in their web development project. In most cases content migration needs to be done manually and requires a lot of planning and people power to move or author content.

At Fishtank, we help our clients by providing the necessary tools and resources to help them successfully author or move content to their new website. We take a goal-driven approach to ensure our recommendations are rooted in achieving realistic results.

Knowledge Transfer and Engagement of the Project Team

In many technology projects there is a lot of upfront work done before the project work begins. This includes sales meetings with the client, initial estimates, writing of the Statement of Work, and other activities which are not visible to all project team members. It is very important for a Sitecore project then that the project team is updated with all known information at the very beginning of the project.

At Fishtank we hold internal kick-off meetings for the project team as soon as the Statement of Work is signed to set expectations and ensure that the project team fully understands the project scope, deliverables, timeline, and our delivery approach. It's also important to discuss and agree on everyone's roles and responsibilities in the project. In Agile projects the client project sponsors and project team is also an integral part of the overall project. We ensure that there is a proper client kick-off meeting where we discuss and confirm the scope of work and the roles and responsibilities of all team members so that everyone is clear on what is expected of them during the life of the project.

Integrations With Third-Party Applications and Concurrent Internal Client Projects

Oftentimes project teams are engaged in projects where the overall project or program landscape is not clearly understood early on in the project, and sometimes unexpected integrations with other applications are uncovered during the discovery phase. The client team may also be working on other projects at the same time which may be competing for resources and their attention. All this pose significant risks to any technology project including scheduling, cost and security risks.

At Fishtank we work closely with our clients to identify and understand their technology landscape, and all the potential integration points. In our experience it's much easier to manage these dependencies if they're identified as early as possible during the project lifecycle. It's critically important for all parties involved in a project to see the bigger picture, assess deadlines of other projects external to the Sitecore project that need to be taken into consideration, and plan appropriately not only for the Sitecore implementation itself but also for all other technology projects running concurrently which may be affecting the Sitecore implementation.

UX Design Decisions

User Experience (UX) design is the process of enhancing the usability and accessibility of a website or web application by applying human-centred design to the development process. Oftentimes stakeholders have strong opinions about a website's design based on their personal preferences and experiences with digital products, and also based on their business priorities. It's a common risk then for many stakeholders to unconsciously push their website's design towards their preferences and needs, instead of what their customers or users needs.

UX design decisions go hand in hand with content strategy. An integral part of our process at Fishtank is to review and analyze our clients' website data in order to understand challenges and uncover opportunities for improvement. We also perform usability tests to understand how users interact with the website. We finally hold discovery meetings, collaborative sessions with our client's stakeholders which help us understand their business needs and priorities. With the help of storyboards, user journeys, sitemaps, and wireframes/prototypes we then guide our clients to make informed decisions about their UX design.

Adoption of the Solution

Project stakeholders and content authors are the people who will inherit the solution after the project goes live. It's of critical importance then that the project team will have their buy-in early on during the project so that the transition will be smooth and all involved parties will be pleased with the final solution.

At Fishtank we encourage our clients to involve their stakeholders and content authors in various stages of the project so that they're informed of the progress, and provide their feedback where needed so that the final solution addresses their needs. Project stakeholders and content authors can and should be involved in wireframes and design presentations, sprint demos, and receive Sitecore content authoring training before the project is completed so that they feel comfortable using the platform.

Ongoing Support

After the project goes live the final solution needs to be supported. This can include infrastructure support (no matter if the solution is hosted in-house or in the cloud), support for the content authors for ongoing improvements etc.

Fishtank will help your team determine their support needs and we'll help you put together a support plan which can include a Service Level Agreement (SLA) and ongoing support from the Fishtank team if needed.

Final Thoughts

The final Sitecore implementation is unique to your organization as it will be tailored to your organization's specific needs and requirements. Every project is different in one way or another, but many risks are the same from project to project. Project risk management is a continuous process that requires ongoing attention from the whole project team to ensure project success. It involves the identification, assessment, and mitigation of potential risks that could negatively impact the project outcome.

In many cases it's challenging putting together a risk log at the beginning of a project, but the list provided in this post will at the very least get a project team started with thinking about all these potential risks early on in the project. They can then decide whether some or all of these can become valid risks during the life of their project which should then be mentioned in the initial risk log, and prioritized and addressed as early as possible.