During UAT or post go-live, your organization realizes that SAP system is working correctly for certain business scenarios but produced inaccurate results for business scenarios with few deviations. You may also see unexpected behavior of the system such as inability to execute end-to-end business process or cause systems short dump. This risk is common on SAP projects where business requirements have not been captured in detail or poor quality system design during realization phase. Ideally this may also mean inadequate testing of your business scenarios.

Risk #1 Mitigation

• Ensure that business requirements gathered during blueprint phase are at sufficient level of detail that clearly describes your business process with examples. Verify that all business requirements are reviewed by the subject matter experts (SME) and approved by the business lead and/or business process owner.
• Ensure end-to-end business process in clearly documented in BPRD documents and process flows covering the most common business scenario as well as all the process variants. Verify that each BPRD document is reviewed and accepted by the SME(s).
• Validate that proper SAP software fit-gap analysis is performed on each and every business requirement. Each business requirement that is classified as “fit” should have corresponding SAP standard functionality covering the requirement or “gap” should have a RICEF object that needs to be developed to address the gap in the SAP standard functionality. This will mean that you have 100% coverage of business requirements with either a standard SAP solution or a RICEF object.
• Integration and User Acceptance Testing (UAT) should be very thorough to cover all end-to-end business processes. Each test case should be driven based on business requirements and business process. In other words, each business requirement should be tested with at least one test case. Most projects have test cases that only test most common business scenarios which leads to system malfunction when there are variations in business process inputs or process step. It is very important that the test cases cover most common business scenarios and all its variations that represent your day to day business operations.
• Every SAP project should have a high quality requirements traceability matrix (RTM) that will ensure that your RICEFW functional designs and technical designs trace back to meet all business requirements associated with a specific software gap. RTM will also assure the business that each business requirements has a SAP standard solution, RICEF and further on a test case to test each of these requirements.

“Is your project experiencing severe delays with deliverables taking longer than expected?. Are project deliverables submitted as complete not being truly finished and lacking details?.” One common risk on SAP implementations is that your Systems Integrator (SI) may take longer than anticipated to complete project activities and deliverables there by missing your project deadlines. If this happens, it can delay your project phase completion and also result in cost overruns. We have noticed that this risk mostly occurs when the project work effort is incorrectly estimated or SAP skilled resources from your systems integrator are inadequate and does not possess required solution expertise or experience. From program governance perspective, this risk can be accurately monitored by having a good project plan with well-defined work breakdown structure that will provide visibility into key activities associated with production of essential project deliverables.

Risk #2 Mitigation

• First and foremost, I would recommend that your SAP project leadership and PMO should have a clear visibility to the progress of every key activity and deliverable completion on the project. In order to achieve this, it is important to have a project plan with a good work breakdown structure. This project plan should also be adequately resource leveled to ensure that SAP skilled, SME and project architects are not over-allocated.Example: Blueprint phase work breakdown structure for a sample business process XYZ may look like the following:
  XYZ Business Process
  I. Requirement gathering work sessions
  II. To-be L2-L3 business process design
  III. XYZ BPRD (Business Process Requirements & Design Doc)
  IV. Fit Gap Analysis
  V. High level SAP solution definition
  VI. BPRD & requirements review and approval by business
• PMO and program managers should review the weekly progress and identify any work streams that are facing delays and likely to be bottleneck to overall project progress. Attempt to resolve the delays by hopefully increasing participation of SME or project architects. It may also be helpful if any outstanding unresolved items can be de-prioritized if these are not critical to business operations.
• Projects may also have SAP skilled consultants that lack required experience with a specific SAP module that is being implemented. In both these situations SAP customer leadership is unable to identify these kind of issues because the leadership assumes that your SAP systems integrator is bringing the best and brightest SAP consultants to the project. To mitigate this risk, it is extremely important that your project leadership with the help of your SAP project advisor (third party SAP project leadership expert) interviews all systems integrator resources especially the business leads, solution architects, SAP consultants and team leads provided by SI.
• Most often the delays in SAP implementations are caused by under allocation of SAP skilled resources on the project. Ensure that your project has well balanced teams of SME (subject matter experts) from your business and SAP solution experts. Try to keep the resources from your SI like business analysts or systems integration analysts to minimum that do not have any prior SAP implementation experience. You are better off investing this money to have additional SAP skilled resources on project work streams to produce deliverables quicker.

Most SAP modules and industry solutions have proven to meet 60-90% of business requirements within a specific industry. This percentage of standard SAP package fit is higher with products that have gone through multiple release cycles compared to those that are just launched. We have seen projects where systems integrators lack in-depth expertise of the modules that are being implemented. This result in poor quality SAP software fit gap analysis during blueprint there by resulting in higher RICEFW objects especially with enhancements. A few large enhancements can easily transform into custom development projects thereby blowing your project budget out of the roof. I strongly recommend having a project solution architect with in-depth module knowledge or having a senior expert consultant from SAP America/AG or your local division of SAP to assure that your project is leveraging maximum standard delivered functionality.

Risk #3 Mitigation
The best way to mitigate this risk is to have representation of at least one senior consultant with product expertise from SAP America or AG. I usually recommend this on most projects I serve as advisor especially where customer is implementing relatively new or industry solutions of SAP. If your project does not allow extra budget for this resource, then one thing every SAP customer should do is to review the fit gap analysis output with SAP and solicit their feedback. This will help your project eliminate RICEFW objects where SAP might have standard alternative solutions.

Business team members from the company implementing SAP play a very crucial role on the project. Each major business process or operational area should be represented by at least one subject matter expert who understands how the end-to-end business process is handled today and also how this process needs to work in the future. Inadequate business SME can directly impact quality and progress of requirements gathering, review and approval of to-be business process designs and verification of project deliverables. It is very important to ensure that your business provides required number of SMEs without jeopardizing you current daily production operations.

Risk #4 Mitigation

• In project planning or blueprint phase, meet with business stakeholders to ensure that each business process or operational area is represented with experienced SME. If required numbers of resources are not available, then it may be wise to split the project into multiple releases.
• Do not supplement your business SME needs with business analysts from your SAP systems integrator. Only your SMEs and business process owners understand business requirements. It may not be effective for an external consultant to fulfill this role without understanding your internal business operations.

To me this is one risk that every executive and project sponsor of a SAP project should pay close attention. The ultimate goal of any SAP implementation is to transform current business operations into the new SAP system. It is very important that business subject matter experts, analysts and process owners understand the future state business requirements, new to-be business process flows, solution design in SAP and functional documents. If the business team is not onboard with requirements that are gathered during blueprint and solution design in SAP then your project is running a very high risk of business operations not working as anticipated upon go-live. I recommend that every SAP project leadership especially the executive project sponsor and overall project business lead to verify that business requirements, blueprint documents (process flows, BPRD documents, solution design and solution architecture) is reviewed and approved by SMEs, process owners and the business lead. This will ensure a high quality blueprint and realization of blueprint in design & build phase. Ultimately I also suggest that test cases cover all of your business processes and its variations.

Risk #5 Mitigation

• Key business team members especially SMEs should be part of business requirements gathering work sessions. SME should have clear understanding of to-be detailed business requirements, business process design and solution design in SAP.
• SMEs should review and approve each business requirement associated with their business process.
• SME and business process owners should review and approve process flows, business process requirements and design document (BPRD) and high level solution design created during the blueprint phase
• Client Solution Architect (not from your SI) should review, validate and approve the SAP software fit gap analysis and overall solution architecture. This task can be accomplished together by Client Solution Architect and your leadership QA advisor if you have one on the project.
• DO NOT approve any blueprint document or deliverable which is not 100% complete. Do not let your systems integrator invent the definition of “Complete” in order to meet project deadlines. Complete means the document is fully finished and needs no re-work unless there is a change request.
• Business team and stakeholders should have a full buy-in of the solution that is being designed and developed. All the steps above will ensure that you are heading towards a successful path rather than a mysterious avenue of uncertainties during realization and go-live.

On a very large undertaking like an SAP implementation, the project leadership plays a crucial role in the success of your project. It is not uncommon to see corporate executives (level of vice presidents and senior directors) in the project leadership who are slow decision makers, enforcing cumbersome decision making process when not needed and creating unnecessary political environment there by causing bottlenecks and impeding project progress. I treat an SAP transformation initiative as a fast moving train and every project leader should adjust and cope with the pace of this train rather than slowing it. What I precisely mean is that lot of decision on an SAP project need to be made very quickly and issues should be resolved in an expedited manner. This will help tasks and deliverables on critical path completed in a timely manner without affecting dependent activities. I use this train example very often and suggest that every leader in a SAP project should be flexible, adaptive and work collaboratively with project leadership to meet one common goal of the project i.e. “Successful on-time and on-budget go live”. -individual decision making authority -always have leadership backup to expedite decision making -leadership and steering committee escalations if bottlenecks are causing project delays. -engage an independent leadership QA advisor to monitor, resolve and escalate these issues without any influence of project or corporate environment

Risk #6 Mitigation

• Select project leadership (executive sponsor, business lead, IT lead, change/training lead and project management lead) from your internal organization that have proven track record of successful IT transformation implementation. Make sure these executives are flexible, capable of handling complex project challenges and able to make decision without causing bottlenecks on the project.
• One ineffective and political leader can bring the whole project down. Make sure that you have leaders that are excellent team workers and not the ones that are eager to demonstrate power and authority.
• Decision making on a SAP project (whether a business decision, deliverable approval or issue resolution) should not be solely in the hands of one leader. Depending on the work load, a project leader may have backlog of several key project decisions that need to be made which can ultimately become show stopper on the whole project. Project leadership decision makers should have backup individuals who can evaluate situations and make decisions in scenarios where primary decision maker is not available or lacks bandwidth.
• Critical project risks and issues should be proactively escalated to the project sponsor and the steering committee. Steering committee should also be presented with analysis, alternatives and possible solutions to risks and issues that are escalated.
• Communication is the key between the project leadership and it is important that there is full transparency about project key decisions, risks, issues and status between these leaders. On large SAP projects, I recommend that project leadership should meet at least once every week.
• Project Leadership should keep a “Anonymous Project Feedback & Suggestion Box” for project team members to provide project feedback, express concerns, raise potential problems and suggest avenues of improvement. This will ensure that major unforeseen project issues and challenges are reviewed and addressed in a timely manner. This gives every project team member irrespective of their role and title to voice their concerns or suggest improvements on the project .

Offshore development centers of big 5 and other SAP systems integrators have proven to be cost effective option to lower the cost of overall SAP implementation. The same SAP skilled resources that cost between $200-300 per hour onsite in the US can be available offshore in countries such as India, Philippines, Europe, etc for $30-70 per hour. This is a no brainer cost saving initiative for any SAP project. But offshoring your SAP project work comes with its own set of risks and challenges that clients in the US are not aware or often hidden due to lack of visibility thousands of miles away. Some of the major risks with offshore development centers are the following:

• Under-qualified resources in design and build teams
• Major discrepancies between actual deliverable progress versus the one reported in weekly project leadership meetings
• Lack of key senior SAP functional and technical key members on the offshore team which leads to critical solution quality risk.
• Language and cultural barriers leading to project work ethics being compromised which can lead major project delivery issues to go unreported and escalated till the very last minute
• Incorrect project progress reporting by offshore leadership to alleviate concerns and anxiety of project leadership.
• “Lost in translation” � often business requirements are missed or misinterpreted and similarly functional designs and so on.

SAP customers such as your company does not have visibility and leadership control on what happens in the offshore development center for your project. We realized this as a huge risk on many SAP implementations. Recently our company launched a new practice of “Offshore SAP QA & Advisory Leadership” which allows one of our experienced SAP senior executive to be your exclusive independent QA representative and work onsite at the project offshore delivery center. This is not the focus here so if you need more information then you can reach our company.

Risk #7 Mitigation
The best way to make sure your project offshore team is transparent, effective and well qualified to deliver your project on time is to engage a third party SAP project QA advisor (one of our offering) that will allow a senior SAP industry leader to serve as your exclusive representative at the offshore location closely working with the offshore leadership, entire offshore project team and collaborating with your internal US project leadership. Remember that this resource does not work for your SAP systems integrator but for the SAP customer leadership. An Offshore SAP QA Project Advisor will mitigate all the risks mentioned above by doing the following:

• Interview and select each offshore project leader and team member by conducting project management, SAP functional and technical interviews.
• Ensure balanced SAP design and build teams with adequate number of architects, senior designers, developers with some room for junior SAP resources.
• Review project and deliverables progress with offshore SAP project manager and also conducting independent verification of these project deliverables.
• Ensure end to end SAP solution integration with collaboration between project teams across various work streams.
• Independently report project progress to project sponsor and leadership. Also proactively report offshore project risks, issues and recommend areas of improvements to deliver high quality SAP solution.
• Ensure that level of communication between business SME and onsite team members is appropriate so that business and SAP functional requirements are clearly understood.

Several projects fail or end up being prolonged due to cost overruns as a result of work effort being inaccurately or incompletely estimated. SAP projects have been no exception to this situation. Work estimations should be done at various points on a SAP implementation. Blueprint work estimation should be done during project planning phase. After SAP software fit gap is complete and RICEF inventory is finalized, the work effort should be estimated for design, build, testing and deployment of your SAP system. So from where do these estimation risks surface ? Often project estimators from the systems integrator do not include the client employees (SME, analysts, etc) that are required to be consulted or complete the deliverable. Estimates in producing a deliverable should include time required from SI as well as client resources. The work effort for SAP solution related items should directly be tied to a RICEFW object or SAP configuration object. Legacy or external systems remediation effort to integrate these systems with SAP should be added to the above estimates. Sometimes work effort associated with mandatory SAP work streams such as hardware setup, security, systems administration (SAP BASIS) and network administration is often missed. Note: Re-estimations should be done in early realization phase if you realize that RICEFW objects are taking longer than expected due to project cultural or operative barriers. This should ideally be resolved by project leadership and if not addressed can delay the entire project. There may be some RICEFW objects especially a select few Enhancements that are super complex and as such these should be estimated separately. Because these super complex objects may take much longer to be designed and developed.

Risk #8 Mitigation

• Make sure each RICEFW, configuration and other work object is classified as “High”, “Medium” or “Low” and work effort includes design, build and testing effort from system integrator as well as client resources.
• It may be a good idea to do parallel prototype of 2-3 RICEFW objects to convince the project leadership that RICEFW development can be optimistically delivered as per the estimates.
• Verify that project estimates include hardware setup, network administration , security and SAP systems administration effort.
• Estimates should also include duration based work effort components such as PMO, OCM/Training and testing.
• It is very important that “super complex” enhancements are estimated separately and not by the SI estimation tool. This will allow for accurate reflection of work effort for completion of these complex enhancements on the project plan.

This is one risk that can be avoided if you follow the principles on which I basically operate on any SAP project. During early blueprint and there on your project leadership may realize that you have not chosen the best SAP systems integrator for variety of reasons. These reasons may include poor quality resources that lack proper SAP knowledge, project delays, poor project execution and so on. It can be very painful and cost prohibitive to change your SAP systems integrator at the end of a phase and more so in the middle of a project phase. As such it is very important to carefully evaluate, verify and strategically engage a SAP systems integrator for your project during project pre-planning phase. We have specialized in this advisory service over the years, but here we want all companies to be smart and proactive about choosing the right qualified systems integrator.

Risk #9 Mitigation

• Verify that SAP systems integrators (vendors) bidding for your SAP implementation have implemented specific SAP solutions at two or more customers in your specific industry.
• Conduct reference calls with these customers. Check how these vendors have performed on these other SAP projects. Was the delivery in line with original project budget and timeline ?
• Ensure that SI or vendor partner and senior executives that will be part of your project also have been part of at least one of these prior SAP implementations. It is important that senior executives and client partners have successful track record in delivering SAP transformation projects in your industry.
• Include financial and corrective penalties in the Statement of Work (SOW) in case the project milestones or Q-gates are delayed.
• It is absolutely crucial to include clear and detailed scope of work in the SOW. SOW should not have any ambiguities that can compromise the successful delivery of project.
• Engage an independent SAP project advisors (similar to ours) right from the beginning of the project if your project budget allows.

This is one area where I have hardly compromised when setting my expectations from the PMO of the SAP projects that I served. PMO is the backbone of any IT transformation project and most of what is mentioned here about PMO applies to SAP as well as non-SAP projects. PMO should serve as the source of truth to project an accurate project status at any point in time. It should provide full visibility to project status by presenting the clear picture of work activities, tasks and deliverables progress. I expect the SAP project manager and PMO team to work with individual business, IT and other teams and their underlying workstreams to gather correct work progress and reflect the same in the project management tool such as MS Project. A highly effective PMO is the one that deploys, monitors and enforces the proper usage of tools and methods and properly manage time spent by project resources to deliver the tasks as per plan. PMO should ascertain that all project risks and issues are entered into risks and issues management tools and ensure resolution of these items in a timely manner as set in the project charters.

Risk #10 Mitigation

• Verify that PMO is working with good project plan with well defined work breakdown structure that depict accurate progress of tasks and deliverables.
• Every week PMO team should work with team leads and update the project plan. Any delays in completion of tasks and deliverables should be reflected in the team leads weekly report and also highlighted in the weekly PMO meeting.
• SAP Project Manager (or also referred to as PMO Lead) should work with the program manager, project sponsor and independent project advisors to discuss project progress and also seek recommendations to bring project back on track in case of delays.
• In blueprint, PMO must ensure that all business requirements, BPRD documents, SAP solution design, SAP solution architecture, organization change management strategy, etc are reviewed and approved by the business or IT lead and other corporate stakeholders.
• In realization, PMO must ensure that each RICEFW functional and technical design, unit tests and UAT are approved by the customer business and IT teams.
• No deliverable should be set as “complete” in the project plan unless it is reviewed and fully accepted by the business leads.
• Project capital and expenses should be accurately tracked as per guidelines from leadership and CFO (Chief Financial Officer). Total project costs incurred should be reported on a weekly basis in the project leadership meeting.