Abstract: This blog post provides a concise summary of the most important project management processes for scope, problem/risk, and decision management in SAP projects and provides helpful tips on how to implement these processes pragmatically.
Scope Change Management / Decision Making Process
First a conceptual clarification: Change management is often understood to mean two different things. On the one hand change management to bring changes to the organisation, which I call OCM (Organizational Change Management – what it is all about can be found in the corresponding description in BLOG article 12); on the other hand the Scope-Change-Management, which is about the management of the adjustments of the defined project scope. I am talking about the latter here (Scope Change) and would extend this to the management of the adjustments in the delivered S/4HANA system, i.e. the WRICEF and the configurations deviating from the agreed project specifications (if there are e.g. if, for example, it is not allowed to set up a new material type, a corresponding request must go through this process).
The objective of this process is to make decisions consciously and against the background of the evaluation of all possible alternatives and, in particular, of economic efficiency.
How is a Change Request defined?
As a rule, each requested scope change is dealt with in its own Change Request (CR). The following things should be clearly defined:
– Who owns the CR and who are the stakeholders?
– Why is CR necessary (possible categories would be…)? Legal requirement, corporate requirement, profitability or comfort)? Legal or corporate requirements usually have to be implemented and do not require further discussion.
– What are the alternatives (e.g. organizational or use of another SAP process in the standard system)? These and the CR requirements should each be compared within the framework of a SWOT analysi. Costs and benefits of the individual alternatives should also be QUANTIFIED (this is always possible!).
Such a CR should go through a defined and documented evaluation and release process, which usually ends in a final decision in the steering committee. This can happen in the SAP Solution Manager, for example, or simply be managed in an Excel table by the PMO. In addition, this process should be used largely analogously to the documented decision making in important questions in the project. Here it should be extended by the documented recording of the requirements of all participants (see exemplary decision paper template (Decision_Paper EN.PDF). Our MS Word template of the “Decision Paper” for the documented recording of all requirements in the decision-making process can be purchased and downloaded via this link in Digistore24.
Risk management
Definition and demarcation: A problem or issue is a circumstance that currently prevents the team or parts of the team from working as planned. A risk is a circumstance that can lead to having a problem or issue in the future. This must be averted. While for problems or issues actions must be defined in order to eliminate them as quickly as possible so that work can resume as planned, for risks it is a matter of taking measures to avert the future problem or issue or to reduce its probability of occurrence, so-called mitigation actions.
See our Explainer Video on “Risk Management” here on YouTube!
If you deal offensively with risk management, carry out an initial risk analysis (see template Risk_Analysis_EN.PDF). Have the teams report and log the discernible risks regularly within the framework of the status and evaluate them in a risk log (see exemplary Risk_Log_Sample.pdf) and define and monitor the mitigation actions. Make the reporting of the most important project risks an integral part of the report to the steering committee. The 16-page risk analysis can be purchased and downloaded via this link as a Word template in Digistore24. The Risk Log for reporting of risks in MS Excel can be found here.
Issue and Decision Management
In my experience, problem or issue management is a waste of time. Problems have to be solved and therefore actions have to be defined and their completion has to be tracked. I have already mentioned the decision making process above. The aim here is to communicate decisions made in the project to all stakeholders of the project and then to close them so that they are not reopened in the future.
I have been successfully using the following components and procedures in projects for many years:
1. A central meeting protocol is kept for all meetings held within the framework of the project.
2. there are the following categories for entries in the meeting log
– P: Participants (all participants of the meeting are entered here)
– A: Agenda (here the meeting agenda is recorded)
– D: for decisions (all decisions made are recorded here)
– T: Task: here, all agreed tasks are recorded with the specification of A RESPONSIBLE person in charge, the target date and the status (open, wip, closed).
– I: for important information that should be shared and documented
3. for the same meetings always the same meeting name is used
An exemplary specification can be found here (Meeting_Minutes.PDF). The Meeting Minutes – the central meeting protocol in MS Excel – can be purchased and downloaded via this link in Digistore24
This procedure makes it possible:
1. that in a follow-up meeting the open tasks and decisions of the previous meetings can be filtered very easily, instead of searching in various Word protocols as usual.
2. for the PMO to regularly track open and overdue tasks.
3. that everyone in the team can find their tasks easily and work through them regularly.
4. last but not least, that the decisions are periodically recorded in a decision log and can be distributed to all stakeholders of the project with a deadline for objection for information and for asking possible questions for clarification and can be lured into the decision log after this deadline has expired. An example of a decision log can be found here as PDF. You can purchase and download the Decision Log as MS Excel template in Digistore24 via this link.
Here are some examples of the regulations on the fourth aspect:
– Decisions from team meetings, SteCo, Manager Board or project management are collected in a central file (Decision Log).
– The decisions are translated into English and German.
– The project management checks the decisions for plausibility.
– Once a month, the new decisions are distributed to all participants.
– The participants have a review window of four weeks to give feedback on the decisions.
– After the four weeks, the decisions are blocked and published.
In my opinion, this fourth aspect is particularly important, because this procedure can on the one hand prevent the accusation that decisions are made in the private isolation and on the other hand, in my experience, it can effectively prevent the “reopening” of already decided points. The latter is one of the biggest problems in many companies.
Find our explainer video on Meeting Minutes and Decision Log on Youtube!
And here you will find an overview of our tools, which you can purchase and download at Digistore24 and use for your project.