Top 10 Risks on SAP Project - Avoid or Manage Them Before They Turn Into Issues
Share with your peers, friends or project leaders
Author: Deepak Mandrekar,Senior SAP Program & IT Transformation Leader, iii Technologies
Risks and issues are part of any and every major IT transformation project. When we put this in perspective of large transformation projects like SAP or Oracle these risks and issues can be huge which can collapse the entire project if not managed and mitigated in a timely manner. Most of these risks and issues discussed here are applicable to any IT implementation project. However, this article is based on my several years of experience in leading and overseeing large SAP projects and also based on some of the projects that have failed.
SAP systems have been implemented successfully at 40000+ customers in the world and most project failures are not related to the product or software but mostly tied to project execution and your software implementation partner. This will maximize your chances of a successful SAP implementation and you are more than welcome to discuss with me any specific questions you may have about managing risks on your SAP project.
Common Risks on SAP Projects
These risks listed below are the ones that occur very frequently on a challenged or failed SAP project. I will refrain from mentioning any client names throughout this article and suggest that you assess the importance of managing each of these risks as it pertains to your specific project.
Risk #1: SAP System not producing correct output or not working properly during UAT or post go-live
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
Risk #2: Project experiencing frequent delays in deliverable completions and slippage of deadlines by the Systems Integrator (SI)
"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
Risk #3: Ineffective use of standard delivered SAP functionality due to lack to knowledge within consulting organizations
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.
Risk #4: Lack of business subject matter experts causing project delays
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
Risk #5: Lack of confidence of business team in understanding and acceptance of blueprint and overall solution in SAP system
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
Risk #6: Ineffective, rigid and political project leadership
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
Risk #7: Offshoring SAP design and build effort: Is it cost saving or risk doubling? – Tighter control on resource skills, work quality and on-time delivery capability
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:
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:
Risk #8: Inaccurate or incomplete work estimation on SAP projects resulting in cost overruns and schedule delays
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
Risk #9: Choosing an incorrect Systems Integrator with limited track record of successful SAP systems delivery in "specific SAP industry solution" can lead to project failure on multiple fronts
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
Risk #10: Inefficient Project Management Office (PMO) with poor project visibility, deliverable tracking, issues/risks management and communication shortfalls
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