SAP Program Director

  • Did you know ?
    Former SAP America & Big 4 Leaders and Executives

    All SAP project advisors and program managers in our SAP advisory practice are former SAP America or Big 4 consulting leaders and executives.

  • Did you know ?
    Rates: 40% lower than Big 4

    Our rates for SAP project advisor and program manager are 30-40% lower than those charged by Big 4 and other major firms in the SAP industry. Why pay $300+ per hour when you get much better senior leaders for your SAP implementation at significantly lower cost.

  • Did you know ?
    Our Client Engagement Model

    For all our projects in the US and Canada, we travel onsite at client location between Monday and Thursday and dedicate at least 40 hours to the project every week. Engagement on international projects are handled on a case by case basis. We provide remote SAP advisory services to our international client ranging from 8-40 hours commitment based on customer needs.

  • Did you know ?
    100% No-Charge Guarantee

    We take the utmost pride in the level of expertise we provide on every SAP implementation. We demonstrate very high standard of ethics and integrity. Should you be unsatisfied with the value we bring to your project, we will not charge or provide 100% refund of all professional fees we have charged during first 3 weeks of the engagement.

Effective Management of RICEF Development on SAP Projects

Share with your peers, friends or project leaders
RICEF objects stand at the core of any SAP implementation. RICEF is an acronym for Reports (R), Interfaces (I), Conversions (C), Enhancements (E) and Forms (F) which for the most part represent development objects in SAP that need to be designed and developed to fulfill the software gaps and ancillary business requirements. RICEF is also referred to as RICEFW (with W representing workflows) or FRICE.
SAP RICEF
We are not going to discuss how RICEF development should be done, but rather focus on measures every SAP project leadership and executive sponsor should take to ensure high quality RICEF design and development. If these measures are adopted correctly then it should help your project leadership to identify and mitigate any project risks that could potentially jeopardize a successful go-live.
As a SAP Project Executive Advisor (QA, Validation and Verification), one of the key aspect I closely monitor is execution, governance and delivery of RICEF objects. I will cover all these three areas as we discuss various steps along the lifecycle of the SAP implementation that involves or directly impacts RICEF development.
Video: RICEF Development Management Advisory Services for SAP Projects

High Quality Blueprint

Providing clarity and depth into your business requirements

Detailed Business Requirements

Emphasize on "what" your company needs to run your business operations in SAP and not "how" these needs will be realized in SAP. "What" precisely refers to your business requirements and "how" is how these requirements will be configured or designed and built in SAP during realization phase. Very often business teams raise a pain point in realization phase complaining about the quality of functional specifications indicating the designs are inaccurate or business requirement interpretation is incomplete in the functional designs. This situation arises when business requirements are not at a sufficient level of detail that SAP functional consultants can clearly understand and interpret your business needs. From my perspective, detailed business requirements are absolutely a must on every SAP implementation which holds the key to go-live success. Remember that RICEF design and build on most SAP projects are done by offshore teams located in countries like India, Philippines, Europe, etc. So it is important that each business requirement document in blueprint should be at a very detailed level that any person who is not part of your project or business can read and explain the business need back to you without anything lost in translation. Day in life examples with business scenarios should be included when explaining complex business requirements.
Classic example
If your business requirement says "I need to build a new custom mid size car to deliver pizza.". If we design based on this incomplete requirement lacking details, you could get a MERCEDES or FORD designed and built that could meet this vague requirement.
The company chief executive must be looking for low cost and fuel efficient cars to deliver pizzas. Now a good business requirement could look like this. "New mid size fuel efficient and economical car need to be built to deliver pizza. The car gas mileage should be in 25-40 mpg range. Low cost interior and no air conditioning needed. Car needs to be 4-door to accomodate pizza delivery bags for 3-5 customers at a time. Cost of car should not exceed $15000.". Now you know that the car being designed will be low cost fuel efficient car that can accomodate enough pizza delivery bags per your company needs. That is why for a good RICEF design and build quality, it is very important to have detailed business requirements with business examples where required for more clarity.

Good SAP Software Fit-Gap Analysis

RICEFs are technical objects that need to be designed and built to address the "gaps" in the SAP software. These gaps may represent SAP functionality that needs to be modified or custom. So what constitutes a good fit-gap analysis? Well! There is a twofold perspective. First of all a good fit gap analysis can only be done by an SAP techno-functional expert in the modules that are being used on the project. This resource must be at the level of an SAP solution architect who also possesses an in-depth expertise about specific SAP modules and all the functionality that has been added in later releases. SAP customers often ignore this fact and you tend to trust that the resource performing fit-gap has the required expertise.

Next thing that should be emphasized is how the fit gap analysis is carried out. Fit-gap should be done on each detailed level business requirement (L3 requirements) and also at the "L2" and "L3" business process steps. Why on process steps? Just because SAP may have an enhanced or alternate solution to execute the same process step that may meet all underlying business requirements in a slightly different manner but still meeting essential needs of the core business process. If your project has a independent advisor, I recommend that you verify the quality of fit gap analysis and resulting RICEF inventory.

On large or complex (w/significant custom development) SAP projects that I have overseen, I have always recommended to the CIOs that fit gap analysis be reviewed by IBU (Industry Business Unit) or IS (Industry Solution) experts from SAP America or SAP AG that are not typically part of professional consulting services but who work in the product development and field services departments at SAP.


RICEF Estimations

Work effort associated with RICEF design, build and testing usually account for 50-70% of project budget during the realization phase. So it is very important that objects in the RICEF inventory are classified correctly to represent correct work effort. System integrators often only include effort required from their own resources to design and build the RICEF objects. I suggest that you ask the project manager and SI delivery lead to verify that effort includes hours required from business team SME and other project team members to complete the work. Also estimates for each RICEF object should include functional requirements (if not done in blueprint), technical design, development and unit testing. Allow 15-20% of total effort for each RICEF object for performing modifications and fixes based on business, technical and advisory QA reviews. All "very large" RICEF objects especially enhancement which could also be classified as custom development are estimated separately and not using the SI estimation tools. Because very large enhancements could men 200 hours or also 1000+ hours depending on the scope and complexity and later could blow the project budget out of bounds.

For conversions, ensure that estimations include effort required for cleansing and extraction from legacy systems, transformation and loading of data into SAP. Effort for cleansing the legacy system data can be overwhelming if the quality of data is not as clean as you hoped. If your project believes that your organization will require extra effort then ensure you adjust the work effort for each "high/medium/low" conversion object. Make sure you are not double counting for technical development that is needed to support conversions which may also be included in other enhancements and ABAP reports.

Most RICEF "interfaces" can also be used for loading the data from legacy systems and hence the conversion effort should not be duplicated. In this case conversion (if any) estimates should only include effort required to clean and extract data.


Realization Phase Staffing Model (for RICEF)

Balance between onsite and offshore Balance within technical team Ė architect, senior developers, developers and junior dev Architects should know in-depth technical know how of all development classes, available BADIís /user exits, DDIC and other technical objects that are available in standard SAP solution Senior developers should be experts in ABAP/ABAP OO along with tools and solutions along with good understanding of standard functionality. Developers should be able to take directions from architects and senior developers. Implement the code independently. Junior developers and technical analysts can be fresh out of college or less than 2 years of experience with SAP ABAP, PI, etc. Junior developers should not exceed 15% of your total technical team composition. Having junior team members above 20% could wreck the quality and delivery of your RICEF development.


Project Management of RICEF Development

Project Plan and RICEF WBS

I expect to see two project plans with different level of granularity to provide me with 100% transparency into the actual progress. One at the PMO, with WBS showing each RICEF object and underlying tasks one each for functional specification, technical design and development. The project plan also have a milestone for each RICEF signifying approval by business lead upon review from SMEs. This will provide a good insight for the project leadership showing the RICEF objects that are complete have also been checked and verified by the business thereby acknowledging the development.

Example WBS in PMO project plan
Application development(RICEF)team leads on the project should have a more granular project plan for each RICEF objects. Sample work breakdown structure (WBS) for a typical object may include: RICEF E278: [name of enhancement]
Functional specification
Technical design
Build and unit test
Business review
Signoff

Project plan should include dependencies on other related RICEF objects and it is important to especially show the progress of RICEF objects on critical path to your project sponsor and advisors.

Tracking RICEF Design and Development

First, letís discuss about what need to be designed and built first. Make sure RICEF objects that are driving the core business process and SAP functionality be done in first cycle followed by the ones that have lesser business critical significance. Keep the report, forms and enhancements to the last that have lesser business impact if project decided to go-live without these objects in place. Please refer to our recommendations on "Sequencing RICEF development in realization phase" for more information.


Reporting Accurate Progress to Project Leadership

SAP transformation projects are usually quite large enterprise wide undertaking and hence it is important all parts and pieces of the project are completed in a timely fashion to deliver the overall project in time and within budget. RICEF development is one of these critical part and all pieces i.e. key RICEF objects that are in project critical path be completed on time. I often see system integrators that show the project in "GREEN" status during early to mid realization phase where in reality it should be at least "YELLOW" because of delays. Here is what I like to see in terms of weekly status reporting about RICEF objects in the project leadership meetings. Your SAP project manager should have a few slides in the weekly PMO deck that shows the RICEF progress dashboard.
First set of slides should show the total number of reports, forms, interfaces and enhancements that were supposed to be completed till date as per original plan and showing the actual completion count till date. All the RICEF objects that are delayed should be listed in the following deck one by one with reason for delay, extra effort required and target completion date. All risks and issues around any RICEF delays that could potentially impact the project should be logged in issues and risk management tool. Next set of slides should show the status of in-progress RICEF objects with just the list of objects and target completion date. Any change requests, issues or risks around the RICEF objects that could potentially impact the project budget and timeline should be in the final concluding slides that show RICEF development status.
As a project advisor, I expect a little more detailed weekly report on the RICEF development and this be reviewed with me prior to preparing the above project leadership status report. I ask the project manager (periodically include project sponsor) to walk through the project plan. For each RICEF object that is completed, I like to see that the design has been verified and approved by the business before marking the same as complete. If the development (build) has been complete, I like to see that senior technical team members have done QA review on the implementation. I may pick a few key objects to conduct design and code review with the technical team.
For RICEF objects that are delayed, I would like to see the detailed explanation on what has caused the delays in the completion of design and build. I investigate some of these items further with the SAP project manager and team members to ensure that delays are not caused by lack of SAP expertise or unnecessary bottlenecks being caused by business teams. Ensure that there is a collective (or well grouped) weekly change requests that reflect the delays or extra effort required to complete the RICEF objects. I might conduct one-on-one meetings with the RICEF development teams and leads to identify and mitigate any risks that affecting completion of certain RICEF objects.
If the project has outsourced the RICEF development then I expect to meet with the offshore delivery lead and the project manager on a weekly basis to discuss status and some of the above points. I suggest that your IT lead or advisor visit the offshore development center whether it be in India or Philippines if there are major delivery issues. Historically I have travelled to India on some projects and also made some tactical and personnel changes to bring the project back on track with minimal possible impact on delivery time and budget.

One thing that I often see on projects is that systems integrator begin the realization by focusing on simple and low effort RICEF objects first in order to report "GREEN" status in project leadership meetings. This results in more business critical RICEF development that is in critical path to be delayed there by causing overall project delays.
DN: