Business Solutions with SAP

SAP Project Manager – SAP Program Manager, Lessons from the Trenches

July 25th, 2011 by
SAP Project Insight

SAP Project Insight

This is a continuation of the previous post which addressed early requirements for good SAP project management (see Effective Results from SAP Project Managers – SAP Program Managers).

SAP Project Management Responsibility

A manager’s primary responsibility, above all else, is to ensure the success of those they are responsible for managing.  Overall success of any initiative is directly tied to the success of those responsible for delivery of that initiative.  This is especially true in fast paced, moderate to large scale SAP projects.  If your reports succeed then you as a manager automatically succeed.

An SAP project manager or SAP program manager must focus aggressively on removing obstacles, encouraging success, and fighting against those things that would impede momentum.

Once again, I will re-emphasize:

I don’t blame client project managers because if they had all of the resources, skills, and experience, they would not need outside help.  These posts are focused on contracted help who are supposed to ensure your success.

What can SAP Project Managers or SAP Program Managers Do to Help Ensure Success?

One of the first requirements of a contract SAP project manager is to build momentum.  Once momentum is built that contract SAP project manager or program manager must do everything possible to sustain that momentum.  Some of the things which help to build, sustain, and then manage momentum include:

  • An articulated obsession with building and maintaining momentum.
  • Activities, tasks, responsibilities, and value added tools are defined ahead of time and not made up in real time.
    • People must understand what is expected of them – project requirements in the form of deliverables, tasks, and timelines are communicated early in the project and reinforced *before* transition points throughout the project.
    • These “expectations” must be laid out early in the project, throughout the entire project lifecycle (beginning to end) and have proper transitions built into the planning.
  • Tracking mechanisms must be simple, easy to understand, and easy to manage.  Overly complex or involved tracking mechanisms destroy momentum and “cloud” visibility into progress.
  • During blueprint emphasis is focused on design that will enable execution, if it doesn’t enable execution (or Realization) it is a waste of time (see  How “As-Is” Process Mapping Can Damage Your SAP Project).
    • Project emphasis must be on execution – execution builds momentum.
    • There is an emphasis on coordinating activities rather than administrative overhead–, some administrative overhead is necessary but only to the extent that it directly supports execution).
    • Project management is actively and directly engaged in coordinating execution activities beyond checking off spreadsheets.
  • After blueprint emphasis moves to execution over design.  Areas where design continues to be evident must be aggressively managed so that design only supports directly executable activities that are in scope.
  • Risks to success are identified and mitigated throughout the project.
    • Issues, risks, decisions, or other obstacles to project success are regularly captured and worked to resolution.
    • Periodic QA reviews at appropriate milestones or intervals.
    • Obstacles to activity or execution are aggressively managed (with few exceptions there is no “we can’t do ‘x’ until ‘y’ is perfect)

Do You Have a “Slick Politician” or a Real SAP Project / Program Manager?

There are unfortunately too many politicians in the project manager ranks and too few “straight shooters.”  Project manager politicians are destructive to morale, on-time delivery, and are dangerous to budgets.  However there is a measure of diplomacy that is required so how do you know when you have a political SAP project manager or SAP program manager rather than a skilled and talented one?

A manager’s primary responsibility, above all else, is to ensure the success of those they are responsible for managing.

Think about that a minute.  If a manager’s primary responsibility is to ensure the success of those they are responsible for then what would be a sign they are not a good contract project manager?

If your reports succeed then you as a manager automatically succeed.

The worst kind of project manager is the one who will “throw others under the bus” to deflect from their own shortcomings.  They demoralize and discourage project team cohesiveness while crushing momentum.  They create an environment where people do not want to do anything at all for fear of becoming the next scapegoat.  When things go well they are the first in line to take credit for what went well (even when they weren’t involved).  They lack integrity and character.  They spend more time and effort trying to cover their own back side than on trying to ensure the project is delivered successfully.  If you see these signs in your contract project manager you should seriously consider firing them.

Popular Searches:

  • explain the economic hardware and software factors for vendor selection

Related Posts:

SAP Success Factors for Vendor Selection – Responsibility Matrix 1

October 11th, 2010 by
ROI, TCO and Business Benefit from SAP - critical success factors
SAP ROI Success Factors

Recently I was reviewing another of many papers I often read on various business and IT topics.  A paper from a graduate student recently caught my attention and while it lacked some of the insight from personal experience, it made up for it in the substance of the material. 

After a short look at the peer-reviewed academic literature, Anil Bhagwani, did a brief case-study on 10 failed SAP implementations and 10 successful SAP implementations.  From these he continued to distill SAP critical success factors.



For more vendor selection background, before or after reading this post, please refer to another study that was reviewed on the topic of vendor seleciton–, SAP Implementation Partner or Company Selection Criteria.

Common SAP Critical Success Factors (CSF’s) identified for successful ERP implementations

The study author’s perspective and summary of the key success criteria from the Executive Summary, pg. 5, is reproduced here (altered and reformatted for easy reading):

  • Sustained executive management support and their ownership of the implementation.
  • Project team composition.
  • Good project management (especially pertaining to process design).
  • System testing.
  • Training of the end users.

These are the most important factors contributing to the success of SAP implementations in most organizations.  The lack of sustained management support / contribution and user involvement / training and testing seems to be the most important factors contributing to the failure of SAP implementations in most organizations. [FN1]

These conclusions are consistent with my experience and tend to be mostly in line with the academic literature.

Why do so many SAP projects come in over budget and over time?

One important feature of this paper is the notation about project management and its relationship to project failure.

30% of projects were perceived to have failed because of a lack of effective project planning, while 10% were perceived to have failed because of technology-driven causes[FN1]

This, in my opinion, can be laid at the feet of the implementation vendor and the project management they provide.  More often than not it is the implementation vendor who is tasked with providing the experienced consultants and project management team.  And in the SAP world nearly every SAP system integrator pitches the SAP ASAP implementation methodology but few of them bother to actually follow it after the sale.

Companies pay dearly for “experienced” resources who claim to follow a proven methodology to steer a customer correctly through their SAP business software system implementation.  But in most cases a good system integrator, with seasoned project management is critical to your implementation success.

Although the literature suggests that 10% of the ERP project failures were related to technology, with SAP in particular I would challenge that as masking the real underlying cause.  Let’s put the claim of SAP technology limitations into perspective.  As of October 6, 2010,

  • SAP has over 100,000 customers in more than 120 countries [FN3],
  • nearly 50,000 employees [FN2] (with approximately 15,000 of those employees being developers [FN3]),
  • about 15% of total revenue dedicated to R&D. [FN2],
  • and more than 24 global industry segments. [FN3]

Plainly the SAP solution has been proven in nearly every environment imaginable. In spite of some of the headlines about failed projects, the application itself is so widely used, adopted, supported, and developed it can not be the problem.  In my opinion the blame for failed implementations, blown budgets, and blown project timelines is frequently the fault of the guidance many companies receive from their hired help.  That does not mean that customers do not contribute to this in many cases, only that the system integrators are the ones that should “know better.”  When an ERP implementation project is headed toward the rocks the system integrator should have enough experience and integrity to raise the risk issues and help to avoid disaster.  After all, during all of the sales pitches they are the ones that tout how much experience they have and you hire them based on that supposed experience to help ensure you do not crash on the rocks.

This does not mean that SAP does not have its technology limitations.  After participating in SAP projects since 1994 I have rarely encountered SAP software limitations where the standard application was not able to deliver 90 – 95% of the business requirement without any custom coding.  Where that 5 – 10% of custom coding was required SAP has provided both user exits (prior to version 5.0) and enhancement points (versions ≥ 5.0) to modify the data processing within the transaction stream.  And unlike other consultants, my experience has taught me that there is a standard solution there somewhere so I will look for the standard functionality before trying to undertake custom “software engineering” efforts.

As a result I would attribute that 10% “technology-driven” failure rate to other ERP applications, or more likely improper requirements, poor project management, or bad consulting.  Although I have not had the direct application exposure to SAP’s competitive products, I would guess they are fairly well developed in their focus areas as well.  And over the years I have had a LOT of SAP client counterparts wanting what I call mutually exclusive requirements.  Or, as an analogy, they wanted to have their cake undisturbed while still eating it too. 

Defining SAP Success Criteria (Lacking these can cause ERP Project Failure)

The academic study’s author offers an ERP success definition which notes projects are “done within budget and time with meeting all the preset implementation goals as measured by ROI, etc.” [FN1, pg. 8].  The author then notes a 2007 Gartner study showed only 60% of the projects achieve this success definition. 

In my next post I have reproduced the list of critical success factors (CSFs) and added a responsibility matrix.  Those critical success factors come from a combination of this study, done in 2009, combined with a prior peer-reviewed study I wrote on previously ( The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors ) and my own personal experience.

The responsibility matrix I developed defines major project success criteria and who is (or at least should be) responsible for ensuring the successful delivery of those key components. 

More of this is explained in my next post which looks at some of the key areas for project success, who should manage those success factors, and how so many consulting firms avoid responsibility.  After that we will review details on steps and strategies to ensure ERP system integrator accountability for managing those success factors to ensure you don’t get robbed in your SAP business software system project.

Tune in over the next few weeks for more details and insight on this topic.  I’ll be exploring why so many SAP system integrators and ERP vendors are able to avoid accountability for these SAP critical success factors and how you can work to ensure your ERP system vendor covers these factors.


[FN1]  Bhagwani, A. (2009). Critical Success Factors In Implementing SAP ERP Software, University of Kansas Graduate School.

[FN2]  SAP Inventor Relations, Business in Brief, (retrieved 5/10/2010)

[FN3] Deutsche Bank European TMT Conference 2010, London, September 10, 2010 (retrieved 10/04/2010

Related Posts:

Toward an SAP Center of Excellence or SAP Competency Center – PART 3

July 28th, 2010 by

SAP Production Support 3Part 3 of 3

Stages and Components of the SAP Center of Excellence

To wrap up this series we will take a brief look at the post go-live or the production support environment.  One academic study I reviewed on ERP project success factors defined the three production stages of Acceptance, Routinization, and Infusion (see The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors).

These three terms fit the requirements for SAP production system stages as you move toward an SAP Center of Excellence so I’ll use them for reference rather than inventing new terms just to be different.  However, I have defined them in my own way below which may, or may not be 100% consistent with the academic literature.

The ultimate goal of an SAP Center of Excellence is Business Transformation.

SAP Center of Excellence Model for Business Transformation

I’m less concerned about terms and phrases here than I am about the focus and objectives of the effort.  So if you want to call your department an SAP Center of Excellence, or an SAP Business Transformation Center, or an SAP Business Support organization, or whatever please feel free. 

Your SAP staff must be proactively engaged with the business community.

Here is a high level SAP Center of Excellence Model for Business Transformation after you are live in your SAP environment:

Acceptance – go-live and productive business use of the system (heavy change management).

  • Training
  • Process Documentation
  • Help Desk
  • Internal Collaboration (structured Instant Messaging, Forums, and other structured as well as unstructured information capture)

Routinization – the overall acceptance and sustained productive use of the system (system stabilization).

  • Knowledge capture (Wiki and Forums)
  • Troubleshooting methods and Company Best practices
  • Process overviews, refinement, and business / system adjustment
  • External Collaboration (Forums, Customer Channel feedback, marketplace intelligence, vendor collaboration, collaborative product or service development, etc.)

Infusion – long term acceptance and use of the system as well as additional functionality additions (re-focusing on business and SAP to business alignment, i.e. strategic direction).

  • Rotating IT staff assignment into business organization (throughout the process chain)
  • At least once a month work in the department business process area of responsibility
  • FAQ Development (Wiki and Forums)
  • Enhanced or new system functionality
  • System and Process Change Risk Management

SAP Competency Center or SAP Center of Excellence Conclusion

Enterprise applications like SAP are more important than ever in today’s globally competitive and economically sensitive era.  It is simply not enough for IT departments to serve in a more passive support role.  In today’s global economy your SAP and IT support staff can not wait for the business requirements to come rolling in.  For the health and welfare of your business and your SAP or IT organization it is more important than ever to ensure that your SAP staff is proactively engaged with the business community.  That engagement must take the form of an active partnership in looking for new and better ways to use technology for competitive advantage and process improvements.

As for the future, this type of alignment between all of the IT functions, under the banner of the CIO is beginning to take place [FN1].  While SAP Competency Center management and development can focus on the operational excellence business proposition (better, faster, cheaper, more automation) the SAP Center of Excellence framework is more closely aligned to the innovation and customer focus value propositions.


[FN1]  A four part series on the current and future technology leadership landscape, this includes the direction of technology and the pressures CIOs face now and in the future.

Part 1:  What is the Proper Relationship for the CIO, CEO, and CFO?

What the changing business and IT landscape means to the CIO, IT Director, IT Manager, or other key technology decision makers.

Part 2:  CIO, CFO, and CEO Alignment – Why ROI is Lacking from Today’s System Landscape

This post provides an overview of the current system landscape and the focus on business processes and contrasts that with the emerging trend of the customer focus value proposition.  This piece also looked at the future business landscape and how the technology focus and direction will be permanently changed no matter what happens with the economy and global competition.

Part 3:  Changing the Direction of SAP, ERP, and IT Applications to Focus on the Customer and Innovation

A brief review of the supply side and the demand side of business shows that unless you have lots of customers (demand) to fill a bigger and bigger pipeline (supply) then an operational excellence business model collapses.  While it is hidden during good economic climates, any disruption in those economic conditions which fails to fill the capacity pipeline points out the glaring insufficiency of the “operational focus” to technology.

Part 4:  Future Technology Landscape Alignment for the CIO, IT Director, or Key IT Decision Maker

The final part of the series looks at the emerging technology landscape and what the future holds.  It lays out an emerging technology landscape model which has some re-alignment and some components already in use by some of the world’s most successful companies.  A new alignment of technology with the customer facing processes, and the use of social or collaboration tools across the enterprise with a clear business objective is explored.  The driver for the future change will be because the business does not see the revenue generation prospects of technology–, they fail to see the possibilities of promoting customer retention, customer acquisition, innovation, and marketplace analytics.  The new technology model looks to change that dynamic.


Toward an SAP Center of Excellence or SAP Competency Center – PART 1

Explaining the differences between an SAP Competency Center or sometimes referred to as an SAP Center of Expertise and an SAP Center of Excellence.  As Peter Drucker wrote either Do Things Right or Do the Right Things.

Toward an SAP Center of Excellence or SAP Competency Center – PART 2

A more complete and thorough explanation of the differences between the SAP Competency Center (or Expertise Center) and the SAP Center of Excellence (or the Business Transformation Center).  An understanding the operating differences and how the Competency Center is focused on reactive processing of things like help desk tickets, problem resolution, data correction, and knowledge transfer.

Toward an SAP Center of Excellence or SAP Competency Center – PART 3

Business model application of steps, techniques, and methods to produce an SAP Center of Expertise or an SAP Business Transformation Center.  The major business transformation steps on moving from an SAP Competency Center to an SAP Center of Excellence.

Related Posts: