INNOVATE. INTEGRATE. TRANSFORM.

Business Solutions with SAP

Reduce SAP Project Stress: Part 1

August 25th, 2008 by
SAP project stress signposts and solutions

SAP Project Expectations

 

Expectation Setting

Probably one of the most overlooked consulting and management skills is expectation setting. More often than not, the difference between a good job and a mess is the understanding of what was expected.  This is true both from the person who is supposed to meet the expectation (the consultant or implementation vendor) as well as those setting expectations (the customer or project manager).

In SAP or ERP projects this can make the difference between a very successful project and one that is a disaster.

Project related expectation setting during an SAP implementation comes at many points and phases of the project.  There are several types of expectation setting, from the business reason for the project, to the goals, deliverables, tasks, responsibilities, and integration points.  Here are some examples that relate to project expectations and the working environment:

Expectation Setting for the SAP Project Environment

  • Use the project charter and project prep activities to define project goals, success criteria, and direction for the project based on the business reason or business case for the project. 
  • Use the scope document to set expectations for processes that will be addressed (and those that will not) (see ERP Project Plan: Getting Real (Part 2)). [FN1]
  • Use the blueprint to set expectations for details on how the scope will be set up or implemented.
  • Project plan key milestones defines dates to ensures a timely project within budget and the ability to make the necessary adjustments.
  • Key deliverables define key proof of task completion to ensure that the work is getting done, and that the teams are moving along together.

SAP Project Prep: Expectation Setting for the SAP Working Environment

  • Establish consultant or project working hours.
  • Internal employee working hours and time commitment.
  • Define expense and time submission requirements.
  • Publish any preferred vendors, rates, and expense limits, such as hotels, rental cars, etc.
  • Company policies that consultants must adhere to.
  • Any special parking requirements, building access, or system access requirements.
  • Key SAP project contacts and their information.

Much more can be added to the list, however these examples may give you some ideas and help as a baseline.

SAP Consulting Handbook: Working Environment

Probably one of the best tools I have seen to help reduce the time and frustration of bringing on new consultants is a “consultant handbook” that lays out the primary criteria and expectations for working on the project. This advance preparation pays dividends whenever new consultants or others come into the SAP project. Defining this type of a handbook up front also serves to gather key information from those on the project.   All of the working environment information from above should be included as well as other important information.

Things like dress code, working hours, facility access, security contact information, how to go about getting technical help, key project contacts, preferred hotels and rates, preferred rental car companies and rates, and a host of other key information. 

A good handbook can also be used as a tool for cost control as well. Things like rental car rates, approved hotel rate limits, etc., help to manage and control costs. Spell these items out in advance and they can help to avoid misunderstandings during the course of the projects related to expenses. One funny example came up when I was on a project and one of the consultants got a speeding ticket.  They tried to put the fine for the ticket on their expense report–, DENIED!  In other words, define a decent expense policy in advance to help avoid some of the confusion. 

One suggestion however is to try to keep any consultant handbook to a reasonably “short” 10 pages.  A few more won’t hurt, but if it gets bogged down in too much detail it will never be remembered and then becomes counterproductive.  It needs to be an easy reference guide, not a book!

SAP Blueprint and Realization: Putting SAP Project Expectations into Place

A solid scope document, good blueprint, decent milestones and deliverables with realistic deadlines will go a long way toward ensuring a successful project with stress levels that do not get out of control.  Add to that clearly set expectations for the working environment (working hours, etc.) and that makes for a good foundation.

One of the major risks of improper (or a lack of) expectation setting is demoralizing and frustrating seasoned consultants. A seasoned professional will do what they can to ensure success.  If they have real experience they also understand how to raise and mitigate risks to that success. When expectations are improper, such as when they unnecessarily impact family life of a traveling consultant, they can cause tremendous stress and aggravation.  Or when there are unspoken expectations about working hours, or about client employee time commitment and effort on a project these can be trouble spots.

SAP Scoping and Blueprinting

Think of your project like an orchestra.  There are different instrument sections that serve different purposes and make entirely different sounds.  Played together, under the hand of a good conductor / coach, with talented players (not novices), and you can create a masterpiece.  Neglect that coordination, or bring in novices for key positions and you have a mess.

Scoping and Blueprinting are two early key points to coordinate a successful project.  If you are successful at this early development of the “sheet music” then the different parts of the “orchestra” can play together on the same sheet of music and on the same line. Think about that orchestra with the brass playing on one sheet of music, the strings on another, and the percussion still somewhere else, and woodwinds decide they are going to paly a different song altogether. Get and keep everyone in synch and the tensions will remain manageable.

After having scope defined (see FN1) the next step in SAP is requirements gathering or Blueprinting.  If a good job is done of gathering the initial requirements then the stage is set for success. However, if the requirements or Blueprint is not well defined, or the blueprint is ambiguous and does not lend itself well to setting up the system, there will be trouble.  A good blueprint must have enough detail to immediately start setting up the system.  All of the organization structure issues should be nailed down solid, and all of the business processes (and their details) should be at least 85 – 90% complete.

A good SAP blueprint means that as soon as SAP realization (i.e. system setup) is started the bulk of the work will be spent making the detailed settings and refining more subtle requirements into a productive solution. Done correctly, you can achieve a smooth go-live and transition to a productive system. The characteristics of a good blueprint will contain enough detail to actually make SAP settings. However, a disguised blueprint may contain only lofty and generalized process descriptions. A good SAP blueprint will have details needed for actual system setup, a poor blueprint is more like a scope document that describes processes rather than actual design. Think about it, if you have an architect draft plans for a house and you get very attractive elevations, but no foundation, framing, wiring, HVAC, plumbing, or roofing diagrams, that would not be a blueprint. And if you try to “build” that house based on nothing but an elevation how much time, energy, resources, and materials do you think would be wasted trying to get it all figured out on the fly?

Set the expectation going into the blueprint that it is going to be used to capture the detailed SAP settings needed for the system. Nice process flows are helpful but are nothing more than enhanced “scope” if they are not accompanied with the details for setting up the system itself. 

A complete list of SAP transactoin codes should be defined, every process mapped, with its key master data requirements defined.  All legacy systems that will remain and those retired should be identified.  All Forms, Reports, Interfaces, Conversions, and Enhancements (FRICE) should be detailed.  Legacy systems that need interfaces, any additional software such as fax, EDI, etc., should be defined.  Additional hardware requirements such as updating PC’s, bar-code scanners, label printers, display screens, or other new hardware requirements should at least have an initial pass.

Blueprinting is the first opportunity you have to determine whether your consulting partner company, or the consultants they have provided really have any idea of what they are doing. USE THAT OPPORTUNITY WISELY! [FN2]  If they do a less than optimal blueprint, expect a less than optimal implementation and solution. 

If you start to discover a lot of gaps between the blueprint and the realization (i.e. system setup) then you should have serious concerns.  However, keep in mind, that even the most careful and conscientious consultants will occasionally miss something, or, as commonly happens, will ask and be told “we don’t do that” and later it is discovered you do.

SAP Project Milestones and Deliverables

A list of milestones, checkpoints, and deliverables is critical to managing a successful SAP project and managing stress.

Most SAP veterans are familiar with the 4 or 5 key phases of an SAP project: Prep, Blueprint, Realization, Final Prep, and then Go-Live–, however there are other key milestones within the project that are important as well. It will be critical to manage some of the midpoints, like data migration checkpoints, technical development milestones, unit and integration testing, training material prep, training delivery, and a host of other checkpoints that make good milestones. 

Deliverables are tools to set expectations by providing results oriented content at key checkpoints. Well-defined deliverables help ensure expectations are met. These can be items such as development lists, transaction lists, status sheets with progress tracking for development or transactions (identifying the specific development object or t-code progress), training logistics plans, training documentation tracking by transaction, training schedules, test scripts, testing logistics, test scheduling, etc.

All of these important deliverables are key to keeping everyone on the same page, playing on the same sheet of music, at the same time. With adequate tracking, workloads can be monitored and adjusted where necessary.  In other words, the correct deliverables and tracking tools allow for staff and resource leveling as necessary throughout the project.  Beware of an implementation partner that does not have clear examples of these types of deliverables and tracking tools.

The key here, and the difficulty, is in separating the level of detail and control from the need to track requirements. If the level of control is too detailed, or tracked in such a way as to be perceived as micromanaging, it can be counterproductive.

One of the successful methods I’ve used over the years is to keep the project plan at a reasonably high level, and use the deliverables and tracking tools for more detail.  A project plan with too much detail can quickly become a nightmare to manage and has a tendency to overwhelm the project team.

SAP Project Work-Life Balance and Project Schedules

For example, on nearly every SAP project I have participated in since 1994 the consultants generally travel and have about 4-12 hours of travel time on each end of their schedule.  They are away from home, can not take care of the normal day to day activities, and often times have families who they do not see through the week.  As a result the work week for a traveling consultant is generally 4 days a week on site.  Any seasoned consultant understands that there are times in the project when they will have to make adjustments to the schedule, like when the project timeline is starting to slip, or at cutover it is well known and well understood that there will be weekend work.  Beyond this there is some need to try to balance work and life.  Attempting to require a 5 day work week when there is no critical reason will quickly erode project morale and may put the entire project at risk.  For me personally (and many consultants I know) part of the tradeoff for being away from wife, children, home, and family is knowing that I have Fridays to try to catch up on what I missed during the week and to try to re-connect to my wife and children. 

In the end, there are many components to a well run project that helps to keep your SAP implementation under control. There are many things you can do to ensure that your relationship with your consulting partner does not deteriorate.

Expectation setting in all of its various forms is a key component to a successful SAP / ERP implementation.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[FN1] See the article entitled: How to scope your SAP implementation or upgrade. The article provides practical considerations and specific tools to help ensure scoping is done correctly from the RFP process onward. http://www.r3now.com/effectively-scope-your-sap-project 

[FN2] More and more companies are wising up to some of the bait and switch tactics of inexperienced consultants and consulting firms. Frequently SAP customers are allowing the consulting companies to bid on and do the components of projects, like a blueprint, and will only give them the rest of the contract after a well-prepared blueprint. You may wish to craft a contingency clause into your agreement with the consulting firm clearly stating that the quality of the blueprint will dictate whether they continue on the project as the prime integrator. One other critical consideration here is that a good consulting company will often discover items that may have been honestly missed during scoping which may require some of the underlying time, effort, and skills assumptions to be adjusted.  This will obviously affect the proposed budget.  If a consulting firm comes to you suggesting that some adjustments may be necessary after blueprint it does not mean they are trying to find ways to “stick it to you.”  Just evaluate any suggestions in project changes carefully, could this have easily been foreseen?  Should it have been a standard scope item? 

Is it limited human error / oversight or does it look like the vendor intentionally underbid the project by minimizing scope, and then will “change order” you to death for the project?  RUN from those vendors, don’t walk, RUN as fast as you can… 




Popular Searches:


  • HOW TO CORRECT OVER STRESS ON SAP
  • OVER STRESS ON SAP SOFTWRE WHAT IS MISSED
  • sap manage expectation

Related Posts:

Reduce SAP, ERP, or Technology Project Stress: Part 2

August 20th, 2008 by
Reducing SAP project stress

Reduce SAP Project Stress

A good SAP project with solid performance requirements will often be a stressful experience.  Anyone who has been through an ERP implementation has experienced this stress.  And although this may sound counter-intuitive, if you’ve chosen the right people for the project during the course of the implementation tempers will flare.

Why do tempers flare with the right people?  They are usually the people who care the most about the business and are passionate about their responsibilities.

If the employees assigned to the project are not used to the grueling hours, 10, 12, 15, or more hours a day, they may find themselves in difficult situations.  Some projects have taken significant tolls on project member families, even causing divorces and physical or emotional problems.

There are however a few ways to significantly reduce that SAP project stress and ensure the temper flare-ups are kept to a minimum.

What causes many of the SAP project stress problems?

  • Direct competition from other business areas or processes, often occurring at what SAP refers to as module “integration” touch points.
  • Improperly set expectations (or the lack of setting expectations at all).
  • Few or no objective metrics to ensure that all teams and key project components come up to the same place together (think of an orchestra with the percussion, brass, and string sections all playing different parts of a song–, what a mess!).
  • Little or no recognition for the hard work.
  • Unrealistic scope and time pressures.
  • Consulting resources without the necessary experience to know how to set proper expectations and mitigate risks (see Screening and Interview Methods to Find the Right Consultant – Part 2 and A Cautionary Tale About SAP Knowledge Transfer for more information on the critical need for the right consultants).

Knowing about some of these stresses, and keeping a watchful eye for them during a project can really help to reduce some of the pressures.

How to Address these Project Stress Factors

Direct competition between departments, business areas, or department “touch points” will happen during an SAP project.  Likewise, these same competitive pressures are translated into setting up the SAP application, especially at the integration “touch points.”  This friction usually occurs at a point where clear ownership of responsibility exists or at the point of ambiguity. This area of integration touch points is referred to as “interdepartmental cooperation” in the academic literature on ERP success factors (see The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors).

When you have a process “handoff” to another area or department, the lack of knowing who owns a process area, or decision point, is usually what creates the tension.  One critical factor to reducing these stress points is to communicate expectations early on in the project about capturing these integration touch points.  A good mechanism is whatever issue logging tool you use.  Once it is captured, the key is to work that touch point just as you would any other issue.  Assign a responsible party and be sure to follow-up.  A crucial issue here is that whoever is ultimately assigned as the “owner” is accountable for the completion of the task but may not be the one who ultimately does the work.  In some cases the “owner” of that touch point may not even have any responsibility for the area(s) covered.

Some of the integration “touch points” where I have seen this are in trying to figure out:  

  • Does Finance own the customer and vendor master or does Sales and Distribution (SD) or Materials Management (MM)?
  • Does Production Planning (PP) or Materials Management own the Material Master?
  • How are the Material Master “views” divided up between modules, who owns the various views and how will they be responsible for ensuring they are complete?
  • Who owns master data maintenance after go-live and what process will be used to coordinate the cross-functional maintenance of the data?
  • Who owns cross-company supply (the sales between company codes), is this in Materials Management or in Sales and Distribution, or how are the hand-offs between the modules handled?
  • Who owns month-end close processes and how will they be tested during the project?
  • Who will do the month-end production order settlement, is that in Planning or in Finance?
  • Who will close the current period and open the next period for material movement postings, is that in Finance or Materials Management?
  • During the Integration testing portion of the project, for cross-functional tests, who will “own” what tests, even if there are significant portions of each test which must be conducted by other areas?
  • During realization and implementation, who will own the Revenue Account Determination, will that be in Finance (FI) or in Sales and Distribution (SD)?
  • During realization and implementation, who will own Material Account Determination, will that be in Finance or in Materials Management?
  • Who will own the Product Costing, will this be in Production Planning or will it be done separately with a Controlling (CO) / Product Costing person, or in Finance (FI)?
  • With order related costing, will this be done in Sales and Distribution (SD) or in Finance (FI) or in a separate Controlling (CO) function.

You get the idea.  The list of integration touch points, and of ownership and responsibility creates “flash points” during the project if these issues are not defined and assigned quickly.  This also moves into the live production environment after go-live if the business processes are not sufficiently defined.  If ownership for integration touch points and for process development is lacking during the project it is not likely that it will suddenly work once you go live.

What experience has shown me:  If you have trouble with ownership or resolution for a process or business area during the project, expect trouble with that same process or business area once you go live.

Fake SAP Consultants or those with Exaggerated Experience Cause Significant SAP Project Stress

For me, as an SAP consultant, doing the system setup is relatively “easy.”  It is not even that bad for some of the more difficult and complex areas.  What creates headaches for me, and what causes project stress is when integration testing begins and the business is still struggling with these responsibilities.  Any decent consultant can “push through” the testing process and ensure that things work the way they should but this is another indicator of upcoming problems when you go live.

Unfortunately, by the time integration testing starts is when you will likely begin to discover the consultants with fake resumes or dramatically exaggerated experience.  Testing will reveal high levels of defects, gaps in processes, or they just won’t be ready for testing when other teams are.  This is another of those areas where tensions will also rise from the experienced consultants because of how their fake or inexperienced counterparts made poor decisions which negatively affect other areas.  This is also where you, as a client, will begin to get that sinking feeling that the project timeline and budget are going to get blown. This can also be a direct result of a fake or incompetent SAP “project manager” who might have good people skills but no clue how to run an SAP project.

Avoid getting ripped off by so many of these fake consultants by protecting yourself with an engagement contract that defines some specific level of skill, experience, and consultant requirements.  And be sure to at least screen some of the vendor’s consultants (see Screening Methods to Find the Right SAP Consultant).  You would NEVER hire a senior level manager or executive without due diligence, why are you going to pay an integrator WELL into 6 figures for each of their fakes?

Real Life Example of the Damage Done by Fake Consultants

For example a chemical company had a requirement to sell the exact same products under different names and at different prices with different product labeling.  The product construction and the manufacture was identical in every way.  The right solution was for the Materials Management Consultant and the Production Planning Consultant to work together to create a new Material BOM and Routings for Production Planning.  This would allow for 100% consumption of the underlying “common” finished product.  However, the MM and PP consultant were not as experienced as they led everyone to believe and it became a near war over the issue.  At that point I had a difficult decision to make as the SD consultant.  The worst part is that the MM consultant was a “climber” up the  consulting ladder who actively worked to throw anyone under the bus that might even minimally disrupt her plans.

Unfortunately, rather than throwing it back at them and pressing them to address the issue I accepted the “responsibility” to allow for pricing to be done based on product DESCRIPTION.  This was not the best solution and although it worked I would never do that to a client again. The maintenance was an absolute headache and this was not the best solution.

Unfortunately, to keep the project moving, some of your experienced consultants end up giving less than optimal solutions because of the mess that is created by having inexperienced consultants who have “great” resumes.

The costs of all of those “cheap” inexperienced consultants and all of the H1Bs are far higher than you might think.  But they are enticing because someone “works” the numbers to make them fit.  But there are many more hidden costs you never see.  And some of those costs may be many multiples, or orders of magnitude higher than you anticipate over the application life-cycle.

Conclusion on Reducing SAP, ERP, or Technology Project Stress

One of the biggest problems I see repeated on projects is improperly set expectations.  Combine that with junior level consultants that are “sold” by consulting companies as senior resources and you have a recipe for a less than optimal implementation.  Don’t just accept every consultant that a consulting company places on your project, and definitely take the time to define responsibilities for these integration touch points as quickly as possible.

When you begin to experience project stresses and tempers start to flare look for the culprits, it will usually be related to some of these integration touch points or junior resources that someone has to cover for.  Sometimes it is just plain personality differences.  Either way, watching for and mitigating these project stresses when the symptoms begin to show up will help to give a better final result for the project.

Related Posts: