More about Deepak R M
Deepak is an SAP Program Management Leader and a Senior IT Executive with a solid 16+ years track record of leading some of the largest and most complex SAP transformation programs in the world. Often dubbed as "Mr. SAP" he has rescued FOUR large troubled SAP projects that were on the verge of failure. Over these years he has served his clients in the roles of SAP Program Manager, Trusted Advisor, Head of SAP Transformation for North America and also Head of IT which include Fortune 500 clients. He is the Managing Partner of iii Technologies and dedicates 100% of his time in heading SAP program for one of our signature clients. He has held several executive and leadership positions including 8 years with SAP America. He has two national awards for contributions in science and technology industry. He received a Master of Science degree in engineering from Purdue University.

Engage our
To learn more about our practice and services please provide your contact information and we will call you within the next 24 hours.
Services Offered
Primary Services
  • SAP Program Management
  • Independent Quality Validation & Verification
  • Project Execution & Governance Advisory Services
  • Realization Design & Build Quality Advisors
  • Project Leadership Advisor

Short Term Advisory & QA Reviews
  • Project Audit & QA Reviews
    • Blueprint Phase Audit
    • Solution Review
    • RICEFW Audit
    • Realization Phase Audit Audit
    • Overall Project Health Check
  • Initial Project Setup Advisors
  • Remote Advisory Services (Europe & Asia Pacific)
  • SAP Project Failure Review & Revival
SAP Program Manager
Deepak M
Senior SAP Program Management Leader & IT Executive
Now available for new engagement
Call (609) 901-8000
email: advisor[AT]
SAP Project Manager Resume

Business Requirements Traceability : Holding Your SAP Project Together End-to-End

Share with your peers, friends or project leaders

People on the projects I undertake often hear one thing from me, "If any piece of business process, functional/tech design or build needs to be done on a project, there better be a business requirement that explains the need for that functionality. Otherwise there is no need wasting time on a piece without any supporting business need.". On the other hand, I expect that the SAP system should be designed, enhanced and tested to meet each and every business requirement so that there aren't any unexpected problems during go-live. Requirements Traceability is what we need to address this aspect which to me is very crucial for success of any SAP project and at least I try to enforce this on the projects that I engage. Project leadership and business stakeholders often take proactive measures to ensure that all future state business requirements with correct level of details are defined during blueprint that correctly reflect the business processes, system needs and operating procedures within the company. Now you need to make sure during the functional design and realization (design, build & test) phase that each requirement was addressed with a SAP functionality (design, build & test) or a non-functional aspect. Before we get any deeper, you need to understand that business requirement can be related to a business process, system feature, security, network or performance of an fully integrated SAP system.

Business Requirements Traceability in SAP: Planning Phase

The business requirements traceability often starts right from the project planning phase on a SAP project. It is during this phase that your business team needs to come up with a list of high level requirements to define the scope of your project. These requirements can slighly change in early blueprint when better clarity is available, but during planning phase it is helpful for all business stakeholders to understand common goals and vision the project is trying to accomplish. High Level Requirements (HLR) is the first step of establishing an end-to-end business requirement traceability matrix on an SAP project.

SAP Business Requirements Traceability

Fig:End-to-End Business Requirement Traceability on an SAP Project

SAP Blueprint - Connecting Requirements, Process Design & Solution

Here we should focus on the output during the blueprint phase to establish business requirement traceability and not on the process of gathering business requirements. For more information on business requirement gathering process, please click here. First set of work sessions in blueprint is to define the highest level business processes (Level 1) based on the high level requirements. These are followed by detailed requirements gathering work sessions for each of these business processes. The high level requirements are mapped to level 1 business process. Using these detailed requirements, level 2 and level 3 business processes are defined. Each business requirements will be mapped at either L1, L2 or L3 level with the exception of non-functional requirements. At this point, you have a clear picture of your future business process and the supporting business requirements that drives each process step. A fit-gap analysis is performed against the standard delivered SAP solution. Each business requirement and process step is either categorized as a "fit" or "gap". Each item that is a fit should be identified with a standard SAP functionality or a configuration object that is needed to meet the business need. Each gap will be addressed with an RICEFW object.

Realization - Link Design & Build Objects to Business Requirements and Test Scenarios

Each RICEFW object will have at least one business requirement that is fulfilled by a particular report, interface, conversion, enhancement, form or a workflow object in SAP. During the realization, the functional designs are created first and then followed by technical design specification. Development is performed when the designs are approved which is the end product "solution" in the SAP system. In parallel, during realization phase the business and QA (testing) team created test cases to cover each business process (L1/L2/L3) and business scenarios to support all variations. The test cases and scenarios are validated to have 100% coverage of all business requirements associated with the business process. At the end you have test cases that tests the RICEFW build objects and business processes that cover all your business requirements.