Business Solutions with SAP

Series on SAP ERP Project Success Factors

December 19th, 2011 by
SAP Project Success Criteria

SAP Project Success Criteria


This is a compiled sets of posts related to SAP project success criteria


The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors

SAP Implementation Partner or Company Selection Criteria

SAP Success Factors for Vendor Selection – Responsibility Matrix 1

SAP Success Factors for Vender Selection – Responsibility Matrix 2

SAP System Vendor Project Success Criteria 1

SAP System Vendor Project Success Criteria & Factors 2

SAP System Vendor Project Success Criteria & Factors 3

SAP System Vendor Project Success Criteria & Factors 4

SAP System Vendor Project Success Criteria & Factors 5

Popular Searches:

  • sap projects csf
  • windows 10 screensavers

Related Posts:

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:

Software Consulting Firms and Clients Myths and Half Truths

December 6th, 2010 by

DirectionA recent post from my friend Steve Phillips who runs a great site entitled “Street Smart ERP Blog“.  This is a nice complement to the series I just finished on SAP and ERP critical success factors.


Steve Phillips writes:

Having spent the majority of my career in the shoes of a software consultant or client, I have often wondered why many find it necessary to perpetuate the old myths and half-truths regarding the consultant / client relationship. My feeling is given the track record of ERP we are not doing anyone any favors. In fact, we are causing more harm than good by setting false expectations regarding what consultants are, what they are not, and what the client should be doing.

One answer is …the myths are self-perpetuating. That is, consultants want clients to believe them (more billable hours) and clients desperately hope they are true (even though deep down they know better).

The other answer could be consultants actually believe they are super-human and clients play into this by getting the consultants to assume all the project risks. The real answer is …we are all a lot smarter than that.

In this and the next series of blog entries, I explore this topic by addressing each of the fifteen myths. No doubt, some will not like what I have to say. But if we cannot acknowledge the problems, we certainly cannot address them (and for the sake of everyone involved, let’s face it, they really do need to be addressed). Here is the first one.


TRUTH: Consultants can educate, suggest and coach but cannot make the client do much of anything. In fact, for most ERP “critical success factors” consultants have no direct authority or control over the outcomes.

There might be a few superhuman consultants out there, but 99.9% of them are not.

Only the client can:

  • Own and communicate the business case and drivers for the change.
  • Clearly define and communicate their project objectives.
  • Implement measurements to support the desired behavior and process changes.
  • Approve and contain the project scope.
  • Require (not just sell) the cooperation of employees at all levels of the organization.
  • Assign the right internal employees to the project team.
  • Free-up the required time for those assigned to participate.
  • Expect (not hope) the internal team eventually becomes software experts.
  • Hire employees with the right skills and knowledge when necessary.
  • Manage and utilize outside consultants correctly.
  • Hold functional managers and the team accountable for fulfilling their roles
  • Make necessary changes in operating paradigms and business processes.
  • Limit software mods through justification or changing business processes.
  • Remove the people barriers and naysayers that get in the way.
  • Tackle project issues and decisions in a timely fashion.
  • Take end-user training seriously and require employees to attend.

Again, no matter how great your ERP software or consultants, these are things only the organization can do.

So can your software consultants make you successful?

Related Posts: