Hello community,
this is my first blog post overall and also my first blog post relating the transformation to SAP S/4HANA. Today I want to show you the findings of my master thesis research on how to accomplish accurate effort estimation. I want to show it using the custom code migration as an example.
Moving to SAP S/4HANA towards digital transformation is still one of the major challenges. One of the major challenges that accompanies the SAP S/4HANA migration is providing an accurate effort estimation. The effort estimation is required by different stakeholders for example customers, solution architects and project managers. It’s a key point in every transformation.
Have you ever asked yourself how you can properly perform an effort estimation for SAP S/4HANA migration especially the custom code migration?
In the publication of SAP – Custom Extensions in SAP S/4HANA Implementations A Practical Guide for Senior IT Leadership – (Page 34) you can find the following passage:
Of course, the custom code adaptation in a transformation project does not happen on its own. Moreover, the complete transformation project must be considered in the effort estimation. But how can you perform an accurate effort estimation? I want to show you my approach.
I’ve based my research on practice/experience and on the experience of SAP (for example Custom Extensions in SAP S/4HANA Implementations A Practical Guide for Senior IT Leadership).
Instead, SAP suggest asking your team members to study the SAP notes describing the custom code impact (the list can be found in the SAP Readiness Check tool) and letting them spend a week or two working through some of the findings in the code. After that, ask them for a range estimate. The answer you receive will be much more accurate than the result of the most sophisticated estimation model. Also, SAP has some practical advice. First, it is helpful to distinguish between the purely technical code corrections and the ones that require application knowledge. The former can be done by a generalist ABAP developer, while the latter requires your functional architects to look into the matter first and might lead to new development requests. Second, development teams of any size can become much more efficient if the individual members specialize in particular code changes (that is, a set of SAP notes).
Based on the suggest of SAP and exchange with different ABAP-Developers & SAP Consultants I’ve created a model/method to meet the requirement of an accurate effort estimation. I would like to use custom code migration (CCM) as an example to explain how it works.
The consideration level is the CCM simplification elements determined in the preparation phase and not the individual findings or ABAP objects (as suggested by SAP). In addition to the simplification-item, there are other tasks that are not described by a simplification item. Therefore, the grouping of the simplification item (SAP notes) and additional tasks is fundamentally based on the aspect of the task to be performed.
At this level, the tasks are processed by the responsible persons. The detailed analysis clarifies the scope of the task and the activities required for it. The number of findings per task is also identified, which makes it possible to assess the necessary changes (criteria).
A mix of methods should be used in order to use an iterative process to approach a cost estimate that is as realistic as possible. Based on the findings of the person responsible for the task, an estimate of the time and resources required to correct the findings is made. This process can be repeated any number of times by different experts for each task, provided that the estimate needs to be more precise (see delphi method). This prevents a large variance in the estimate. Aspects that may not have been considered or only insufficiently considered are also discussed again. The methodology can be supplemented by various empirical values, such as those of SAP or experts (see analogy method). For example, if there is not enough experience in the internal development team.
For example, SAP estimates that for the system conversion, with a total of more than 3,000 manual custom code adjustments, an extra month can be expected for each additional 1,000 manual adjustments. If there are more than 70 functional simplification-item in total, then an additional month must be calculated for every 20 simplification-item. A study by IDC from 2020 on the influence of training shows that well-trained project teams and administrators require up to 15% less implementation time. For the new implementation, SAP estimates, for example that in the functional framework seven months are needed for implementation if fewer than three modules are used. If more than eight modules are in use, the introduction is extended by one month per module. If the SAP Best Practices or SAP Model Company are the basis of the introduction, then the introduction time is reduced by at least 25%. (Mapping Your Journey to SAP S/4HANA A Practical Guide for Senior IT Leadership, p. 66)
The starting point of the methodology for effort estimation is the task, e.g. a simplification-item. This task is processed iteratively by one or more responsible persons using the methods and criteria. The result of the cycle, the estimated effort of the task, is transferred to the CCM effort estimate, e.g. a matrix. Ideally, the cycle is repeated several times for each task in order to obtain the most accurate and normalized effort estimate possible. The tasks, their description, the criteria and the effort estimate can be recorded in several ways. One possibility is the recording in a matrix (e.g. excel). The levels within the matrix are the tasks at sub-project level. In addition, the other modules and their simplification-item of the SAP S/4HANA project can be displayed as sub-projects and tasks.
For the respective tasks, such as simplification-item, the effort is determined iteratively by one or more people using methods and criteria. Iterative means that the effort estimation is ideally repeated by one or different people until the estimated effort is considered plausible.
The tasks (e.g. simplification-item) are determined within the CCM discovery phase by the SI check or the SAP readiness check. Other tasks (e.g. package harmonization or modification testing) are determined either directly in the discovery phase or ultimately from the analysis phase. Criteria are necessary in order to be able to carry out a correct individual effort estimation. The criteria must be defined individually before the effort is determined. They result from the individual requirements of the discovery, scoping and analysis phase. The values for the defined criteria result from the phases ibid.
Since the methodology is used in the context of CCM, it can be easily integrated into the CCM process model and thus SAP Activate. All relevant information such as criteria, tasks, people and methods flow from the discovery, scoping and analysis phases. The effort estimation is carried out within the first three phases. When the analysis is completed, the calculated effort is available. The first tasks are processed when the technical adaptation is carried out. The processing of the tasks by people (e.g. developers) also generates empirical values. The empirical values gained and the feedback flow into the cost estimate and improve the cost estimate. Through the loopback from practice, an iterative optimization is possible. The empirical values and the optimized effort estimate improve the feasibility of the functional adjustment within the implementation phase.
However, the methodology can also be easily applied to all other migration scenarios, as long as the starting point for each estimate is a task such as a S-item. The task is the starting point for valid results. If the number and complexity of the findings as well as the developer skills are the starting point, valid results are not possible.
Since the starting point of the methodology is always the task, the methodology can also be used to estimate the effort in other sub-projects such as FI/CO/MM and thus for the entire SAP S/4HANA project. S-item can also be found and processed in these modules.
The most important part is that you take the transformation project related task as base for your effort estimation. (There are different tasks, it makes no sense to list them here). But take the tasks as the base for the effort estimation and don't go down on object level.
If you use the method as you should you are able to receive an accurate effort estimation.
A method is only good as long as it can be used in practice and particularly is practicable.
This also applies to this method. Therefore, in practice, i.e. in SAP S/4HANA transformation projects as well as in sub-projects such as custom code migration, this method must be applied, evaluated and improved (PDCA-cycle).
Since I am not currently facing any transformation project, I would be interested to know to what extent the method is practicable in practice and what the experience with the application and functionality is.
I am looking forward to your feedback.
Best regards,
Norman Glenk
this is my first blog post overall and also my first blog post relating the transformation to SAP S/4HANA. Today I want to show you the findings of my master thesis research on how to accomplish accurate effort estimation. I want to show it using the custom code migration as an example.
Introduction
Moving to SAP S/4HANA towards digital transformation is still one of the major challenges. One of the major challenges that accompanies the SAP S/4HANA migration is providing an accurate effort estimation. The effort estimation is required by different stakeholders for example customers, solution architects and project managers. It’s a key point in every transformation.
Major challenge
Have you ever asked yourself how you can properly perform an effort estimation for SAP S/4HANA migration especially the custom code migration?
In the publication of SAP – Custom Extensions in SAP S/4HANA Implementations A Practical Guide for Senior IT Leadership – (Page 34) you can find the following passage:
“No conversion project escapes the debate on the effort estimation for custom code adaption, which, of course has to be as accurate as possible” (Page 34)
Of course, the custom code adaptation in a transformation project does not happen on its own. Moreover, the complete transformation project must be considered in the effort estimation. But how can you perform an accurate effort estimation? I want to show you my approach.
How you shouldn’t do it
I’ve based my research on practice/experience and on the experience of SAP (for example Custom Extensions in SAP S/4HANA Implementations A Practical Guide for Senior IT Leadership).
SAP notes that the most sophisticated effort estimation models that factored in the amount and variability of findings, complexity of the code, and developers skills – and still got it wrong.
Instead, SAP suggest asking your team members to study the SAP notes describing the custom code impact (the list can be found in the SAP Readiness Check tool) and letting them spend a week or two working through some of the findings in the code. After that, ask them for a range estimate. The answer you receive will be much more accurate than the result of the most sophisticated estimation model. Also, SAP has some practical advice. First, it is helpful to distinguish between the purely technical code corrections and the ones that require application knowledge. The former can be done by a generalist ABAP developer, while the latter requires your functional architects to look into the matter first and might lead to new development requests. Second, development teams of any size can become much more efficient if the individual members specialize in particular code changes (that is, a set of SAP notes).
How you should do it
Based on the suggest of SAP and exchange with different ABAP-Developers & SAP Consultants I’ve created a model/method to meet the requirement of an accurate effort estimation. I would like to use custom code migration (CCM) as an example to explain how it works.
SAP S/4HANA Transformation project - effort estimation methodology
The consideration level is the CCM simplification elements determined in the preparation phase and not the individual findings or ABAP objects (as suggested by SAP). In addition to the simplification-item, there are other tasks that are not described by a simplification item. Therefore, the grouping of the simplification item (SAP notes) and additional tasks is fundamentally based on the aspect of the task to be performed.
At this level, the tasks are processed by the responsible persons. The detailed analysis clarifies the scope of the task and the activities required for it. The number of findings per task is also identified, which makes it possible to assess the necessary changes (criteria).
A mix of methods should be used in order to use an iterative process to approach a cost estimate that is as realistic as possible. Based on the findings of the person responsible for the task, an estimate of the time and resources required to correct the findings is made. This process can be repeated any number of times by different experts for each task, provided that the estimate needs to be more precise (see delphi method). This prevents a large variance in the estimate. Aspects that may not have been considered or only insufficiently considered are also discussed again. The methodology can be supplemented by various empirical values, such as those of SAP or experts (see analogy method). For example, if there is not enough experience in the internal development team.
For example, SAP estimates that for the system conversion, with a total of more than 3,000 manual custom code adjustments, an extra month can be expected for each additional 1,000 manual adjustments. If there are more than 70 functional simplification-item in total, then an additional month must be calculated for every 20 simplification-item. A study by IDC from 2020 on the influence of training shows that well-trained project teams and administrators require up to 15% less implementation time. For the new implementation, SAP estimates, for example that in the functional framework seven months are needed for implementation if fewer than three modules are used. If more than eight modules are in use, the introduction is extended by one month per module. If the SAP Best Practices or SAP Model Company are the basis of the introduction, then the introduction time is reduced by at least 25%. (Mapping Your Journey to SAP S/4HANA A Practical Guide for Senior IT Leadership, p. 66)
Further explanation
The starting point of the methodology for effort estimation is the task, e.g. a simplification-item. This task is processed iteratively by one or more responsible persons using the methods and criteria. The result of the cycle, the estimated effort of the task, is transferred to the CCM effort estimate, e.g. a matrix. Ideally, the cycle is repeated several times for each task in order to obtain the most accurate and normalized effort estimate possible. The tasks, their description, the criteria and the effort estimate can be recorded in several ways. One possibility is the recording in a matrix (e.g. excel). The levels within the matrix are the tasks at sub-project level. In addition, the other modules and their simplification-item of the SAP S/4HANA project can be displayed as sub-projects and tasks.
Excel matrix to keep the effort estimation (you can also use other tools)
More details
For the respective tasks, such as simplification-item, the effort is determined iteratively by one or more people using methods and criteria. Iterative means that the effort estimation is ideally repeated by one or different people until the estimated effort is considered plausible.
The tasks (e.g. simplification-item) are determined within the CCM discovery phase by the SI check or the SAP readiness check. Other tasks (e.g. package harmonization or modification testing) are determined either directly in the discovery phase or ultimately from the analysis phase. Criteria are necessary in order to be able to carry out a correct individual effort estimation. The criteria must be defined individually before the effort is determined. They result from the individual requirements of the discovery, scoping and analysis phase. The values for the defined criteria result from the phases ibid.
Integration with SAP Activate
Since the methodology is used in the context of CCM, it can be easily integrated into the CCM process model and thus SAP Activate. All relevant information such as criteria, tasks, people and methods flow from the discovery, scoping and analysis phases. The effort estimation is carried out within the first three phases. When the analysis is completed, the calculated effort is available. The first tasks are processed when the technical adaptation is carried out. The processing of the tasks by people (e.g. developers) also generates empirical values. The empirical values gained and the feedback flow into the cost estimate and improve the cost estimate. Through the loopback from practice, an iterative optimization is possible. The empirical values and the optimized effort estimate improve the feasibility of the functional adjustment within the implementation phase.
effort estimation integrated in SAP Activate
Usable with all migration scenarios
However, the methodology can also be easily applied to all other migration scenarios, as long as the starting point for each estimate is a task such as a S-item. The task is the starting point for valid results. If the number and complexity of the findings as well as the developer skills are the starting point, valid results are not possible.
Usable for the entire SAP S/4HANA project
Since the starting point of the methodology is always the task, the methodology can also be used to estimate the effort in other sub-projects such as FI/CO/MM and thus for the entire SAP S/4HANA project. S-item can also be found and processed in these modules.
Key-Points
- Take the task as base/basis for an effort estimation
- Define a person responsible for the task and estimation
- Use different methods (e.g. top-down, bottom-up, delphi, analogie) to get different estimate and thus make the estimate as accurate as possible.
- Use criteria to specify the quantity to be more accurate while using different methods.
- Collect and merge your effort estimation within some matrix oder project management tool
- Integrate the effort estimation in the SAP Activate / SAP S/4HANA project
- Method is usable for all migration scenarios and for S/4HANA sub-projects
Summary / Conclusion
The most important part is that you take the transformation project related task as base for your effort estimation. (There are different tasks, it makes no sense to list them here). But take the tasks as the base for the effort estimation and don't go down on object level.
If you use the method as you should you are able to receive an accurate effort estimation.
Outlook
A method is only good as long as it can be used in practice and particularly is practicable.
This also applies to this method. Therefore, in practice, i.e. in SAP S/4HANA transformation projects as well as in sub-projects such as custom code migration, this method must be applied, evaluated and improved (PDCA-cycle).
Since I am not currently facing any transformation project, I would be interested to know to what extent the method is practicable in practice and what the experience with the application and functionality is.
- How well is the method working?
- Is it practicable?
- What needs to be improved?
- Is the seamless integration with SAP Activate possible?
- How well does the method work with other migration scenarios and SAP S/4HANA sub-projects?
I am looking forward to your feedback.
Best regards,
Norman Glenk
- SAP Managed Tags:
2 Comments
