Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
Showing results for 
Search instead for 
Did you mean: 

My first SAP implementation as a Project Manager was back in 2002 when I had just 6 years of IT experience. Before that, I had worked as a developer, Oracle DBA, SAP BW Consultant and SAP PP Consultant. Till now, I don't know if that was a fortunate event or an unfortunate one; However, my then Project Manager resigned and my employer forced me to take over as the Project Manager for that implementation. I was happy in my own small world of Production Planning, MRP, Bills of Material and surrounding integrated processes; I was reluctant to take over the role of Project Manager.

As a novice and "forced" PM, I was not very much aware of many aspects of the project management. Even today, I have seen many experienced consultants and senior resources think that, Project Management is just about coordinating timesheet, billing and work as a messenger – passing the information from/to client to/from our team – without adding any value to the message. In any way, at that time I knew few things about Scope Management, Requirement Analysis and have no idea about cost management, resource management, time management and risk management. To date, I firmly believe that Risk management is the most critical part of project management.

To my advantage, I learned that lesson on my first project when I was forced to work as the Project Manager. One fine day, when we were discussing upcoming work, I informed my client that a particular functionality about MRP is not available in the current SAP version. To my surprise (or maybe not), I inherited a commitment that the specific functionality in question is supposedly available in that SAP release. Suddenly, it poses considerable risks to the fate of the project. It not only will affect the scope, timeline, and cost but it also affected the organizational reputation. Personally, my leadership ability was at test in my first project as project manager.

Recently, I attended a discovery session with a prospective client and SAP. The prospective client has an outdated 3rd party ERP system and they want to retire that system to replace with S4HANA on the cloud. One functionality, for discussion purpose, let's say capacity planning, is critical for the client to decide in favor of S4HC. The capacity planning is neither the part of current functionalities nor it is in the S4HC roadmap. It is the exact same situation - I faced in 2002 - I was facing in early 2017. The only difference was, now I know how to handle those situations.

To manage the risk at any project implementation, we need to know

  • The implementation methodology – in our case we will talk about ACTIVATE methodology

  • The tool/software – S4HANA Cloud in our case

  • Business Knowledge – in our example, let us consider the project is to implement "Streamlined Procure to Pay" and "Accelerated Plan to Product".

This article is not focusing on ACTIVATE, S4HANA Cloud or any functional area. It is assumed that you are well aware of these topics. We will focus on managing the risks and the types of risks that we may encounter. The S4HC implementation follows SAP Activate methodology. The methodology has Discover, Prepare, Explore, Realize, Deploy and Run phase. At every phase of the project, a new risk will inject and existing risks will close.

Obviously, this is not new to any of us. Let us start looking into certain risks during a different phase of the project and from a different category.

Phase Risks Risk Category
Discover System Understanding Scope
Infrastructure Requirements Requirement
Prepare Process and fitment with "what we do" Scope
Availability of the given functionalities Scope
Columnar Database related risks Architecture
Deployment over Cloud Architecture
Mobility Related risks Architecture
Explore Best Practice fitment into their current business processes Scope
Data Migration methodology Data Migration
Lack of understanding of ACTIVATE Methodology Implementation
Data Security Security
Ineffective Fit-to-Standard meetings Scope
Ineffective / Lack of participation in Fit-to-Standard Communication
Realize Changes in Scope Scope
Deploy Lack of training, learning or participation from End Users Learning
Run Lack of Continuous Support Reputational


Risk management will start from Discovery phase of the project. Even though we are far from implementation, we need to create the risk register. You may encounter the maximum amount of risks during the Prepare & Explore phase of the project. The risk management will follow the following steps:

  • Risk Planning – During the planning process, you identify

    • Risks,

    • Risk Owners,

    • Risk Tolerances, and

    • Risk Processes

  • Risk Assessment – During the assessment phase of risk management, you will

    • Assign probability, impact, importance & timing,

    • Interdependencies and confidence limits,

    • Prioritize risks, and

    • Analyze risk trends

  • Risk Response – Finally, in this part of risk management, you will

    • Monitor & communicate the status and trends of risks

    • Balance the project, and

    • Manage the investment choices

Risk Planning

It is a process of identifying risks and others factors associated with the risk management. Risk Planning is carried out during the defining phase of the project management. It is during this phase where we create the Risk Management Plan. Here are the four major activities that we perform during Risk Planning.

Identify Risks

Imagine what can happen if you miss identifying a critical risk, positive or negative. It will impact the financial benefits of the project. A strong risk identification process is critical to the success of risk management which in turn, is critical for the successful outcome of the project. During this process, we prepare many documents such as Risk Register, Opportunity/Threat Matrix, Risk Breakdown structure and few others. All the identified risks must be noted down in Risk Register. Here are few of the sources from where we can identify a risk.

  • Look at the Assumptions – We make lots of assumptions while building the project plan, defining the scope, deciding the schedule and milestone, estimating costs, and during several other key process & steps. Assumptions are the first place to start with to identify the risks. It is also important to note that the quality of risks or the number of risks identified from this section is limited and directly proportional to the assumptions listed. During the discovery phase of the ACTIVATE Methodology, many of these risks can be identified. Any sessions, meetings with the prospective client will help you identify a risk.

  • Historical Information – Look at the historical information to identify the type of risks and issues that a similar project faced. There may not be a lot of historical information available. For example, if you are a manufacturing client and in the process of implementing S4HC manufacturing, you will not have any historical information available to you to assess the risks. In this case, SAP and the vendor team will come into play. They can provide you with their experience in implementing S4HC Manufacturing for some other clients, ensuring the confidentiality and other legal agreements are followed.

  • Prior Experience – Organize brainstorming sessions with peer managers and business leads to discuss their prior experience in similar projects. The discussion must remain within the context of risk management. It will give you a good amount of risks, however, as the Project Manager, you must validate those risks in the context of the current project you are working on.

  • Expert Judgement - Include Subject Matter Experts in those brainstorming sessions. It will help you identify risks that are relevant to the functional areas.

  • Use tools such as Checklist, Risk Breakdown Structure – It will also give you a substantial amount of valid risks.

Identify Risks Owners

Every risk must have an owner identified. A risk owner is the team member, responsible for the management, monitoring, and control of an identified risk, including the implementation of the selected responses. A risk owner is identified based on the risks and the knowledge requires carrying out the activities related to that risk. The responsibilities of the risk owner include but not limited to

  • Manage, monitor, and control the risks.

  • Implement the selected response strategy of the risks

  • Share the status updates with risk response board, Project Manager and PMO

  • Owner may provide an input, suggestions for improvement to risk framework

  • Risk Owner may play a decisive role in setting up risk policy, tolerances, and processes

Identify Risk Tolerances

Risk tolerance is the degree of variability in investment returns that an organization is willing to withstand. As a Client Project Manager, it is critical for you to understand the organizational risk tolerance. Furthermore, if the tolerance level at the Project level may different than organizational tolerance then you need to have the buy-in from organization management and executives.

Identify Risk Processes

As a part of Risk Management Planning, it is important for you to know and understand the risk processes. Additionally, not all the processes will be utilized for your project. Identify those processes that you think will need for the Project, ensure that the process work for your organization, have complete documentation and your team is educated about the process.

Risk Assessment

Risk assessment is to analyze a given risk, qualitatively or quantitatively, to estimate the threat related to a well-defined situation. Based on the assessment, a risk can be handled in many possible ways. These are identified in section "Risk Response".

Assign Probability, Impact, Importance & Timing

As an important part of Risk Management, the risk owner assigns the probability of occurrence and the impact of the risk in case the risk does occur.

We all know that for each risk, we identify and assign a category for that risk. The "importance" defines the importance of that category. There are certain categories that are more important for the project than others. One such example is the "Financial Risk". For a certain project, "Financial Risk" will have more importance than "Timeline" related risks. However for a Product launch, competing against a similar launch from a competition, "Timeline" related risks would be more important than "Financial".

Additionally, a scope related risk occurring at the beginning of the implementation will have less impact as compared to the same risk occurring at the middle or end of the implementation. So it is important to identify the timing of the risk. What it also means is that we need to assess the risks at a given frequency and assign the probability, impact, importance, and timing of each risk.

Analyze Interdependencies and identify confidence limits

Interdependency is the relationship between a risk and the type of the risk. Type of risk is also known as risk category. In general, these are the types of risks

  • Strategic Risks

  • Compliance Risks

  • Operational Risks

  • Financial Risks

  • Reputational Risks

Confidence limit is the assurance level of the risk and performance measure.

Prioritize Risk

The risks are recorded in risk register according to their priority. In general, the risks are prioritized within the given category. In some instances, you can also prioritize the risks across the implementation. However, the risks are always prioritized based on the probability of occurrence and the impact of that risk.

Analyze Risk Trends

As a part of the continuous analysis, we analyze the risks at a regular frequency; if needed we re-assign the probability, impact, importance, timing, category, confidence limit, priority or any other parameters.

Risk Response

So far, we have identified and prioritize the risks. However, that's not enough. We need to know exactly what to do in case of the risk being real. We need to detail the response strategies for each risk. There are several ways to respond to a risk. They are

  • Avoidance – is a way to eliminate the activity that can expose the organizational asset to negative impact.

  • Prevention – is to apply the process and techniques that will prevent the risk of

  • Mitigation – involve creating a plan that will help to reduce, eliminate or manage the risk within an acceptable limit.

  • Retention – is a strategy to retain the risk where the cost of the risk is less compared to the cost of mitigating the risk.

  • Transfer – is a strategy to pass the risk to the third party.

The detail for the above-mentioned strategies is beyond the purview of this blog however it is important for you to know the definition of these.

Monitor the status and trends

As a part of risk response strategy, you need to monitor the status and trends of performance data. It compares the data for past performance and current performance, recent trends, and compares recent changes in the project. As a project manager, you need to understand these trends to identify the trigger point for a given implementation. This status and trends must be communicated to risks owners so that they can further the analysis.

Balancing the project

In case of any deviation due to risk management or in any other scenario, rebalancing methods are utilized to bring the project realigned with organizational strategies.

Manage the investment choices

There are several investment choices tools, some of them are

  • Trade-off analysis – will determine the effect of changing one or more parameters of the project.

  • Market-payoff variability – analyzes the effect of a change in pricing & sales forecast on the project itself.

  • Budget variability – analyzes the effect of changing the project itself.

  • Performance variability – analyzes the performance of the project.

  • Market requirement variability – analyzes the change in the market requirement in relation to the project.

  • Time-to-market variability – it determines the effect of project velocity.

Labels in this area