Effective Management of RICEF Development on SAP

Projects
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.

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.

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 indepth 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 fitgap 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 BADIs /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
Signof
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, lets 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.