Business Solutions with SAP
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. 

[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… 


Contact me today through our site contact form ( ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175
Bill Wood contact


Print pagePDF pageEmail page

Popular Searches:


Related Posts:

One Response to “Reduce SAP Project Stress: Part 1”

  1. Supply Chain Management says:

    This is one of the most useful posts I found. Thank You.

Leave a Reply