SAP project expectations

 

Expectation Setting

As one of the most overlooked consulting and management skills, expectation setting can make the difference between a good job and a mess. Expectation setting is vital for both 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).

During an SAP implementation, project-related expectation setting comes at many points and phases of the project. The team needs to set expectations ranging 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 the team will and will not address (see ERP Project Plan: Getting Real (Part 2)). [FN1]
  • Use the blueprint to set expectations for how the team will set up or implement the scope.
  • Define key milestones to ensure a timely project within budget.
  • Define key deliverables, which allow for a key proof of task completion. This way, you can 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.
  • Establish internal employee working hours and time commitment.
  • Define expense and time submission requirements.
  • Publish any rates, preferred vendors, and expense limits, such as hotels, rental cars, etc.
  • Publish company policies that consultants must adhere to.
  • Disclose any special parking requirements, building access, or system access requirements.
  • Provide 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

From my experience, a consultant handbook that lays out expectations for the project significantly reduces the time and frustration of bringing on new consultants. 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 the list above should be included, as well as other important information.

For example, you should discuss dress code, working hours, facility access, security contact information, how to find 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 serve as a tool for cost control as well. When you specify conditions such as rental car rates and approved hotel rate limits, you limit employee spending and set expectations up front.

One funny example came up when I was on a project. One of the consultants got a speeding ticket. The consultant tried to put the fine for the ticket on their expense report, which was promptly denied. With a decent, well-defined expense policy in advance, that consultant would have avoided any confusion.

One suggestion, however, is to limit any consultant handbook to ten pages. A few more won’t hurt, but if the handbook gets bogged down in too much detail, the team members will not retain the information. This handbook 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 controllable stress levels. Add to that clearly set expectations for the working environment (working hours, etc.), and the team has a good foundation.

One of the major risks of improper 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 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 the team has unspoken expectations about working hours, or about client employee time commitment and effort, the project can have trouble spots.

SAP Scoping and Blueprinting

Think of your project as an orchestra. Different instrument sections serve different purposes and make entirely different sounds. Under the hand of a good conductor with talented, coordinated players, the orchestra 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 an orchestra with the brass playing on one line of music, the strings on another, the percussion still somewhere else– and the woodwinds on a completely different piece. Even if each section performs well individually, the entire piece remains uncoordinated and therefore poorly done. Keep everyone in sync, and the tensions will remain manageable.

After having scope defined (see FN1), the next step in SAP is requirements gathering or blueprinting. If you have properly gathered the initial requirements, then the stage is set for success. However, if the blueprint is not well defined, or the blueprint is ambiguous and does not lend itself well to setting up the system, the team will face problems. 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.

With a good SAP blueprint, as soon as SAP realization (i.e. system setup) begins, the team mainly focuses on 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. 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 the details needed for actual system setup; a poor blueprint describes processes rather than actual design. Nice process flows are helpful, but nothing more than enhanced scope if they do not describe the details for setting up the system itself.

To further illustrate, if an architect draft plans for your house and it contains 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 build on the fly?

To ensure a quality SAP blueprint, a complete list of SAP transaction codes should be defined and every process mapped, with its key master data requirements defined. All legacy (current and retired) systems should be identified. All Forms, Reports, Interfaces, Conversions, and Enhancements (FRICE) should be detailed. Finally, 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.

Additionally, 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 provide a less than optimal blueprint, expect a less than optimal implementation and solution.

If you start to discover significant 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.

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 four or five key phases of an SAP project: Prep, Blueprint, Realization, Final Prep, and then Go-Live. However, other key milestones within the project are important as well. Some midpoints that the team needs to properly manage include data migration checkpoints, technical development milestones, unit and integration testing, training material prep, training delivery, and a host of other checkpoints.

Deliverables are tools that provide results-oriented content at key checkpoints. Well-defined deliverables also ensure expectations are met. Deliverables include 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 deliverables are key to keeping everyone on the same page. With adequate tracking, you can monitor and adjust workloads as 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 who does not have clear examples of proper 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 successful method 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 can overwhelm the project team.

SAP Project Work-Life Balance and Project Schedules

On nearly every SAP project I have participated in, the consultants would travel and have about four to twelve hours of travel time on each end of their schedule. They are away from home, cannot take care of 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 four days a week on site. Any seasoned consultant understands that at some points in the project, they will have to make adjustments to the schedule. For example, the project timeline may be starting to slip, or the project may have a cutover (which will require weekend work). Beyond this, the consultant needs to balance work and life. Attempting to require a five-day work week without a 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 the home and family is knowing that I have Fridays to catch up on what I missed during the week and to try to reconnect.

In the end, a well-run project needs many components to keep your SAP implementation under control. These components start with expectation setting, which is essential to a successful SAP / ERP implementation.

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

[FN1] See the article entitled: How to scope your SAP implementation or upgrade. This article provides practical considerations and specific tools to 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 allow the consulting companies to bid on and do the components of projects, such as a blueprint. Only upon receiving a well-prepared blueprint will they give the consultants the rest of the contract. 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 missed during scoping, which may require some of the underlying time, effort, and skills assumptions to be adjusted. This will affect the proposed budget. If a consulting firm comes to you suggesting that some adjustments may be necessary after blueprint, they are not necessarily 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 the scope issue human error, or does it look like the vendor intentionally underbid the project by minimizing scope, and then will overcharge for the project? If the vendor appears to be trying to overcharge, stop business with them immediately.

Related Posts: