INNOVATE. INTEGRATE. TRANSFORM.

Business Solutions with SAP

Effective Results from SAP Project Managers – SAP Program Managers

July 18th, 2011 by
SAP Project Success

SAP Project Success

In all the years I’ve been involved with SAP I’ve often puzzled about what makes a really good project rather than some of the freak shows they call SAP projects.  After involvement in over 20 SAP projects I’ve seen a few of them go really well, a few that were more like horror shows, but most were mediocre.  I’ve often asked myself “Why?”  What makes the difference between a good project and one that is nothing short of a mess?

One key item that stands out is project management.  Even with the most talented and dedicated resources bad project management can ruin an otherwise great SAP project.

 

I don’t blame client project managers because if they had all of the resources they would not need outside help and guidance.

 

Before I get into this, let me define what I consider a “good” project.  A good project is one where there is a lot to do, but the stress level is not intense.  The timeline may be tight but it is achievable (maybe a little bit of a stretch).  The project is delivered on time, on budget, within scope and the result is high quality (a fairly smooth transition without a chaotic go-live).

Methodology Considerations for a Good SAP Project or SAP Program

The list below is from a synthesis of materials from SAP’s ASAP methodology, the PMI (Project Management Institute), and my personal experience over the years.  Much of this is contained in the SAP ASAP methodology in one form or another so you really have to wonder what any consultant is following if they claim to use it and these items are lacking.  In fact the latest ASAP Methodology version 7.1 includes a project start-up checklist to ensure key components are addressed.

Unlike several years ago when contract project managers had to rely on experience alone – the SAP ASAP Methodology is well-proven and mature today.

There are several key characteristics of a well managed SAP project which includes:

Early SAP Project or Program Management Activities (Before the Overall SAP Project is Fully Underway)

  • Success criteria defined and communicated for the project.
  • One of the first things that is defined for the project are the key roles, responsibilities, and tasks that will be performed by each participant group in the project.
  • A clear, definitive project plan with WBS elements, networks, and activities planned for every major work-stream throughout the entire timeline.
  • A clear list of deliverables, milestones, templates, and instructions on their usage are provided for the entire project.
  • Deliverables are clearly tied to project value rather than useless administrative exercises (value added activities) (see SAP System Vendor Project Success Criteria & Factors 1 scroll down to Sections 8 and 9).
  • Scope, time, issues, risk, cost, communication, and integration management plans, together with additional key components are defined.
  • Various standards for the project are defined and documented, including but not limited to business process, development, configuration, enhancement, transport management, testing, etc.

If you are using outside contract project management resources and  these items are not substantially in place by the time you start your project you will likely have your timeline and budget destroyed.  Along with the blown schedule and budget your project will also be a pressure cooker filled with stress, anxiety, and frustration. These are also characteristics you find when an SAP project manager or SAP program manager is not qualified.  The chaos, tension, stress, and confusion caused by their inability to coordinate the many moving parts of the project are a direct result of their lack of experience and ability.

I don’t blame client project managers because if they had all of the resources they would not need outside help and guidance.

The project should be delivered on time, on budget, within scope and with high quality…

Conclusion on Effective SAP Project or Program Management Practices

You are headed for a project disaster when a contract SAP project manager or SAP program manager fails to ensure the following items are in place early in the project:

  • responsibilities by group and role are defined,
  • deliverables are well laid out,
  • templates are properly prepared,
  • forward looking expectations are set,
  • coordination occurs between all project groups,
  • etc.

I’ve only ever been on a few projects when the SAP project manager or SAP program manager failed to produce a properly detailed project plan.  Every one of those projects had one thing in common, they were absolutely horrendously stressful, difficult, and took more time and cost more than necessary.  Along with the failure to produce a proper project plan the lack of proper deliverables, proper roles and responsibilities, and all of the other things a good project plan would help you define were also missing.  If this happens to you FIRE those contractors, you are being bled dry and are headed for a budget and timeline disaster.

For much more detail on what happens when you have bad contract SAP project managers or SAP program managers see the post Some Reasons SAP Projects are Over Budget and Over Time.




Popular Searches:


  • sap implementation plan
  • sap project manager roles and responsibilities
  • sap deployment plan
  • sap project manager responsibilities
  • sap implement plan
  • JD for SAP Project Manger
  • SAP delivery lead roles and responsibilities
  • sap project manager description and duties

Related Posts:

Using SAP Solution Composer for SAP Scope – Process Alignment

February 28th, 2011 by
SAP Solution Composer

SAP Solution Composer

If you haven’t noticed by now I’ve always been a proponent of using the tools and resources SAP already provides. After all, why should you pay for developing things SAP has already invested in?

Because of SAP’s huge installed base lots of customers before you have tried these tools and SAP has adjusted, changed, corrected, or modified them to improve their use and functionality. On top of that, if you manage to discover a defect or bug, as an SAP customer you can check OSS Notes to see if there is a fix. If a fix doesn’t exist you can open your own note to report the bug and get it fixed. Support for SAP tools is included in your maintenance fees.

One of those early solution prototyping tools I am particularly fond of is the SAP Solution Composer [FN1]. It has a number of benefits and I have defined a number of ways to use it in other posts:

The SAP Solution Composer tool provides a number benefits to help you quickly map processes and solutions:

  • It will map SAP’s software solutions to your business from a business process perspective.
  • It is free to anyone considering an SAP implementation and you do not already have to be an SAP customer.
  • You can publish a “Solution Composer” type PowerPoint scope presentation to mid-level and higher management to ensure their concerns are addressed.
  • It helps with “expectation setting” to reduce surprises that might come up later.
  • Creating process lists for starting some of the critical change management discussions
  • It provides a common language platform for communicating about process options and process change.
  • It comes with several business objectives, metrics, and other information to help you determine which areas of your business to focus on.
  • The SAP Solution Composer tool contains standard and customizable KPIs, business objectives, and other areas of business focus for evaluation.

Together with IDES [FN2] SAP’s Solution Composer provides a great Enterprise Architecture jump start for those who may not have 10, 20, or more years of experience. At least with SAP solutions the complex Enterprise Architecture software options are readily available.

===============

[FN1] Information on the Solution Composer tool, and its use can be found here:
http://www.sap.com/solutions/businessmaps/composer/index.epx

[FN2] See the previous post on:
Global SAP Instance Consolidations
http://www.r3now.com/global-sap-instance-consolidations




Popular Searches:


  • sap solution composer

Related Posts:

SAP Implementation Projects: Still Crazy After All These Years

August 16th, 2010 by

R3 Solution

The following is re-posted with the permission of my friend Michael Doane, see his site at http://sapsearchlight.blogspot.com/

———————————-

Through the good graces of my long-time associate Jon Reed (www.jonerp.com), I recently discovered a blog that covers the life of an SAP project: SAP: Loathe It or Ignore It, You Can’t Like It http://sapmesideways.blogspot.com/.

Shortly thereafter, Dennis Howlett posted about this blog “Your Implementations are Killing Us” http://blogs.zdnet.com/Howlett/?p=1075 and the next morning I received a frantic e-mail from a friend at SAP lamenting its posting. So I guess this blogger is gaining some buzz.

I take exception with the title of the SAP blog as I have seen countless clients who actually do like SAP. All the same, I find it a curious and worthwhile contribution. The writer maintains complete anonymity throughout. No profile or mention of his name, his company’s, the implementation partner’s identity. Mum. While this is largely understandable as a matter of the blogger’s self-protection, it also degrades the effect. All the same, the twenty-seven postings since January, 2009 vividly describe the mind-numbing frustrations, side-shows, and cul-de-sacs that a poorly-run implementation can engender.

The appearance of this blog is in parallel to some serious SAP head scratching on the subject of bad implementations. At the end of the day, when an SAP implementation project goes wrong, it is the joint fault (in varying measures) of the client and the systems integrator but it is usually SAP that gets the PR black eye.

I have been involved in SAP implementation work since 1995 and the balance of my book “The New SAP Blue Book, A Concise Business Guide to the World of SAP” provides guidance for the best practices for implementation. The book first appeared in 1998 and has been revised seven times as better practices continue to emerge. During this same time-period, I have done a considerable amount of primary research with more than 1500 clients reporting upon their SAP experiences and the performance of their SAP systems integrator.

SAP does not deserve the full black-eye for failed implementations. In my esteem, however, SAP does a poor job of policing its SAP partners. The 1500 clients reported upon the field performance of all of the leading integrators (Accenture, IBM, Deloitte, et al) and the following provider failures were chronically noted in regard to deficient project process (in order of importance):

  • Poor scope/resource management
  • Lack of adherence to methodology: all the systems integrators have sophisticated methodologies and tools; they just don’t use them consistently (if at all);
  • Ineffective partner management.

In this research, clients cited who they considered responsible for various issue. They tabbed themselves the guilty party for:

  • Over-engineered and difficult to use results
  • Insufficient post-implementation planning
  • Lack of client ownership.

What SAP Can Do to Address Implementation Issues

All the systems integrators, including SAP Consulting, regularly tout their client satisfaction ratings. When you scratch the surface, these ratings tend to be childish and generalized buckets for entire projects of Very Satisfied, Satisfied, and Not Satisfied. The first reaction is to ask who is satisfied, what are they satisfied with, and when were they satisfied. Many clients I have spoken to who claimed that they were satisfied added that the whole project was a bumpy nerve-wracking mess but they were finally satisfied that it was over.

In this light, SAP needs to finally recognize that implementation services are every bit as much about consulting as about software. While tools such as Solution Manager are excellent for tracking software issues, project issues relative to consulting, governance, etc. are not tracked. SAP should be working more closely with its largest implementation partners to create client-satisfaction tracking that continually addresses these issues from an SI perspective:

  • Business/IT Alignment
  • Governance & Control
  • Human Capital Management
  • Technology, Tools & Process
  • Service Delivery & Operations

Short of this, SAP should create and cultivate a network of objective, third-party quality assurance units (not SAP, not SAP implementation partners) to accomplish this tracking. When such a QA unit exists, life is better for both the client and the systems integrator as in many cases the QA group can point out to clients where they are going wrong. Again, each of the systems integrators have their own internal quality assurance but it is seldom demonstrably objective. By the same token, such QA should not be undertaken by SAP.

Quality assurance can add 1% to 2% to an overall implementation budget while resulting in a 10% to 30% savings in over-all implementation costs (primarily by fending off budget over-runs).

Value to Clients of Third Party Implementation Project Quality Assurance:

  • Cost containment, derived from progress monitoring
  • Time adherence, resulting from continuous (phase to phase) monitoring as well as scope management
  • Vision/benefits realization: assuring that the project will deliver the intended business value
  • Reduced administrative and strategic burden; fewer client/SI meetings for the purpose of progress reporting, issues management, and the like
  • Objective advisory as to what other services or support functions might be appropriate and desirable.
  • Quality assurance reporting would be most effective if it is directed to the client, to SAP, and to the systems integration partner.

In the field, I find that systems integrators initially balk at the inclusion of third party quality assurance on the premise that it will act as an audit of only their performance. Once they understand that the quality assurance role also focuses on client performance and SAP performance, the activity yields positive results.

It should be noted that the SAP/SI partner dynamic is not the same for all partners. Clearly, IBM and Accenture are not as malleable as a small partner such as Capgemini or any number of boutiques. However, it is evident that scrolling a third-party quality assurance activity into any SAP implementation will benefit all three parties (client, SI, and SAP).

It is probably too late for our anonymous blogger. I look forward to when he fills out his satisfaction rating.

—————————-

The original posting for this article can be seen at: http://sapsearchlight.blogspot.com/2009/07/sap-implementation-projects-still-crazy.html




Popular Searches:


  • sap project name ideas
  • Best ERP Project Names
  • best sap project names
  • names of projects for SAP implementations
  • project names for SAP implementations
  • sap implementation project names
  • sap project hindi made
  • sap project na
  • suggestion of sap project

Related Posts: