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.
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:
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.
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.
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
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.
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 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".
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.
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
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.
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.
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
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.
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.
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.
There are several investment choices tools, some of them are
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
4 | |
3 | |
3 | |
2 | |
2 | |
2 | |
2 | |
1 | |
1 | |
1 |