CX Works

CX Works brings the most relevant leading practices to you.
It is a single portal of curated, field-tested and SAP-verified expertise for SAP Customer Experience solutions

Marketing Technology Project Risk Management and Lessons Learned Planning

10 min read


Manage project risks and plan for lessons learned


Marketing technology projects, like all software projects, have risks that need to be managed in some way.  The tactics used to manage those risks should be documented as lessons learned and used to create and enrich a knowledge database. This article outlines how to plan for and manage risks within the six dimensions of success and failure of marketing cloud implementation projects and provides a framework for lessons learned planning.

Table of Contents

Managing Project Risk

There are hundreds of articles out there that talk about project risk management that have been published since the discipline of project management came to the forefront.  The Project Management Institute (PMI) even has a Standard for Risk Management in Portfolios, Programs, and Projects which outlines the principles of risk management, the risk management life cycle, etc.  To put it simply, project risks are those events that come up in a project that can divert the desired outcomes from the latest plan.  Being prepared for risks and having a plan or process to address them can allow the team to capture opportunities and limit the threats presented by these events.  The purpose of this article isn't to dive into the risk management area per se, but to give some guidance with respect to marketing technology projects.

There are several ways to prepare and plan for risks. Agile methods such as scrum help to reduce the negative impacts when risks present themselves by using feedback loops to improve the deliverables and refine the plan with each iteration thus reducing the risk of delivering content that isn't meeting functional or quality expectations. Traditional projects perform regular risk assessments to have the team build a list of risks that need to be prepared for, usually using a simple risk matrix as in the example below.  The "crawl, walk, run" approach described in the article Master the Challenges of Digital Marketing is another way to address project risk.  By focusing on a Minimal Viable Product (MVP) for the first release and learning to crawl with the new technology being introduced, the project team can set boundaries related to scope, time and cost which can reduce project risk.

Risks are typically classified in terms of their likelihood and their impact along with some key parameters: Who owns the risk response? What is the risk response? What are the deadlines? (or "when will this risk materialize and become an issue to be dealt with by the project team?").  Assuming the risks are threats to the project, the team members have a few options to address the risk:

  • Avoid: Take care of it before it materializes, e.g. move the go-live date 
  • Transfer: Have the risk addressed outside of the project, e.g. a resource manager addresses the lack of team member availability
  • Mitigate: Reduce the probability or impact, e.g. remove the scope item from the project 
  • Escalate: Raise the alarm to the project steering committee for decision, e.g. new legal regulations affecting privacy require additional legal support not available in the project
  • Accept: Essentially, let the risk turn into a project issue and plan no further response, e.g. landline telephone data integrity.
Risk # Risk Title Consequence Owner Probability Impact Risk Score Response Tactic Response Plan
1 Vacation period conflict with go-live business value diminished J. Doe 3 - likely 4 - major 12 Avoid move go-live date
2 John is assigned to training during UAT period test plan not adhered to B. Walters 4 - highly likely 1 - minimal 4 Transfer Action item to resource manager
3 reporting requirements are overly complex requirements cannot be fulfilled in time C. O'Brien 1 - unlikely 3 - moderate 3 Mitigate Scope item to be removed when risk score >16
4 new privacy law coming marketing permission strategy is not compliant A. Simon 5 - confirmed 5 - catastrophic 25 Escalate Action in SG
5 landline phone number format landline phone number may not be passed from CRM system G. Joe 2 - possible 2 - minor 4 Accept n/a


Key Risk Areas in a SAP Marketing Cloud Project 

The six dimensions of success and failure which are described in the article Master the Challenges of Digital Marketing provide a good framework to categorize risks.

  1. Business scenarios: Business scenarios can be thought of campaign briefs.  Accurately describing these key starting points for the project requires the right competence around the (virtual) table, a good understanding of the organizational goals, clear buyer personas and journeys, etc.  Risks related to scope and alignment to the business objectives are typically related to the business scenario area.  A Martech project example could be that through the analysis of the desired business scenarios in the first release of the project one scenario provided less value than expected and put the project resource plan at risk.  The risk can be escalated so that the steering committee can approve the removal of the scope item.

  2. Channels: Identifying the key channels used to drive your marketing efforts are an important component of defining the business value of the marketing technology project.  Reducing the number of channels or prioritizing certain types of channels (push vs pull for example) may be a good way to reduce the impact of certain risks. For example, it was identified that marketing through a particular social media channel is an imperative, but that there were no API agreements with one of the suppliers.  This technology risk can be mitigated by moving that scope item to a later project phase, once the agreements are in place.

  3. Data sources: One of the key risks to be planned for in a marketing technology project is related to the data sources, and more specifically the availability and robustness of the environments. The completeness and quality of the data itself should be monitored and related risks planned for. There are legal or policy risks as well as data ownership to be considered.  A project may for example have a desired go-live date which is in the middle of the quarterly SAP Marketing Cloud software upgrade window. To avoid the risk of technical conflicts, the project go live date can be changed.

  4. Features: Many projects suffer from scope creep - essentially taking on more and more work or deliverables than the team can handle.  This is typically due to risks related to changes in company objectives, interesting functionality, low priority items, etc. Essentially, additional features being added to the project charter without due process often results in a risk related to the schedule and scope of the project.  Focusing on a Minimal Viable Product as described in Learn How to Crawl with a Minimal Viable Product” and highlight the scope/feature creep early on in the project can reduce the probability of these risks materializing.  

  5. Organization: This area deals mainly with the people in the team and organization at large.  Risks in this area are usually related to lack of competence related to marketing business technology, processes, team member availability, project member alignment, stakeholder management, etc.  One key focus area in any risk management plan is the relationship between the marketing team and the technology teams.  It's vitally important to monitor the relationship and raise risks to be addressed as soon as they are identified

  6. Geography: Risks related to the location of data sources or environments, particulars related to the type of marketing tactics to be employed, audiences, etc. can easily put a project off course. It may be an acceptable risk to use a certain geography as the first region to deploy a solution, even though the use of certain marketing tactics, such as text-based marketing are not in wide use.

Giving back 

Documenting lessons learned is a key step in a project life cycle.  It may be during the closure of the project, or as per agile methods, part of the retrospective. Retrospectives are a key ceremony of agile projects where the team reflects on what went well, what the team should stop doing, and what should be started for the next iteration or phase.  This meeting should not be overlooked since it provides the team the opportunity to raise concerns and issues that occurred during the last iteration as well as highlight successes. The team can also vote for the areas they feel are the most impactful, as seen in the example below - "Retrospective Whiteboard with dot-voting".  In the context of risk management it's often the case that concerns raised in a retrospective are actually risks to be planned for in future iterations.  Documenting the lessons learned in the project, including how risks were planned for, managed, and addressed, can be of benefit to future projects which are executed by your team members or your organization, as well as the project management office (PMO).

Templates You Can Download

To further assist with your project, you can download the project risk response matrix as well as a project retrospective templates below.

      







Conclusion

Marketing technology projects are not without risk, but with the right knowledge, skills, and attitude they can be properly managed to ensure success.  The project delivery framework for SAP Marketing Cloud focuses on six key areas where risks can influence the success of your project and provide a good framework to build upon to be prepared for risks as they become apparent.

You can learn more about the SAP Marketing Cloud Project Delivery Framework here


Overlay