Top 10 Risks on SAP Project - Avoid or Manage Them Before They Turn Into

Issues
Share with your peers, friends or project leaders

inShare

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

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

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

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

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

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.

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

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.

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

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 .

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:

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.

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

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.

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

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.

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

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.