Business Solutions with SAP

ERP, SAP, or IT Project Management and Prototyping for Success

March 15th, 2010 by

Project GuidanceOver the years I’ve been on projects where there was great project management and others where the project management really stunk!  The projects with really good project management generally ran smoother, had less stress, and the project team was generally more productive.

A FEW of the Characteristics of a Well Managed ERP Project

There are a few things that I saw which were consistent with projects that were well managed.  In a nutshell they are summed up in the following key points:

  1. The project manager produces a published project plan with tasks, timelines, deliverables, milestones, and checkpoints.
  2. The project plan was at sufficient detail to manage the rolled up tasks, but not so detailed that the individual tasks were micromanaged. 
  3. Team leads had individual responsibility at a deliverables level.
  4. The deliverables were constructed at the detailed task level so that their progress could be reported to the rolled up project task.
  5. The project manager knew ahead of time what was coming in the next major phase and communicated that to the whole project team ahead of time, and at the transition times to the next phase.
  6. The “tools” or deliverables templates, resources, and tracking mechanisms were defined AHEAD of time, and then presented to the whole project team with explanations on what information was needed and how to use them as they were needed (JIT or Just In Time).
  7. Team leads held regular weekly status and progress meetings on deliverables status which was then regularly reported to the project manager and directly tied into the rolled up project tasks.
  8. There were several scheduled proof of concepts / prototypes / demos of functionality long before a solution went to testing.

This list is fairly generic and can be applied to just about any project.  Many, if not all of these items may seem common sense, intuitive, or basic but you would be shocked at how many projects deviate from these basic principles. 

SAP Prototyping, Proof of Concepts, Functionality Demonstrations, or Playback Sessions

And that last item, the numerous proof of concept reviews, prototypes, or functionality demonstrations throughout the project were critical.  These prototyping sessions were valuable because if they were properly scheduled (early and often) they quickly reveal:

  • Consultants who might be better on your competitor’s project(s)
  • Areas for genuine business value-add or ROI that might require a scope adjustment but the benefit far outweighed the cost
  • Capture and correction of process gaps before integration testing
  • Adjustment to process focus through better articulation of business need after “seeing” what functionality is there
  • Identification of gaps and risks in application functionality
  • Indicates whether your outside project manager is able to coordinate the necessary work-streams to accomplish the proof of concept sessions
  • Work through and resolve any early warning signs of performance problems

By insisting that your first proof of concept or prototype session occur right at the end of blueprint you have sufficient time to make any necessary staffing adjustments.  Maybe your competitors need some “help” on their projects :)

Warning Signs to Be Aware of In Prototyping

The first warning sign is if a prototyping session or timeline is missed without a clear justification.  For example, if the system landscape was not set up in a timely manner to construct the demo or prototype.  Unless this was due to procurement, logistics, or security issues outside of the project manager’s control then this should be viewed with suspicion. 

If there are SAP or ERP application problems which cause the delay you may want to take a hard look at any consultants who are responsible for installing and maintaining the various software applications.

Another warning sign is if the prototyping sessions are chaotic, disjointed, and generally fouled up experiences.  Usually this will fall into two categories, either a) the project manager is not as experienced as you might need, and therefore might be better off working for your competitor(s), or b) the project timeline might be too tight and there is not enough time to do the prototyping in a proper manner.  How can you tell the difference? 

There are lots of things to consider, but here are a few:

  • Is the problem because one key process area is not ready
    • Is the dependent process, or process bottleneck too complex for the time frame?
  • Would a few more days make a significant difference in the readiness, coordination, and execution of the prototype / demo?
    • If only a small time adjustment is needed, and there are obvious or clear results from just a few days, the timeline might be a little too tight
    • If a short delay does not produce a significant improvement in the organization of the prototype presentation as well as the fit and finish then you may have a project management or a consultant problem that needs to be addressed

To gain additional insight on this critical stage of the project, especially in the beginning when a properly formed foundation is so critical please see the post entitled “Breakthrough Project Success: Part 4 of 4, Last Low Risk Chance for Results.”

Related Posts:

A Cautionary Tale About SAP Knowledge Transfer

February 3rd, 2009 by

SAP Project Knowledge Transfer of Technical Requirements

The first few years of my SAP career was spent doing SAP training and documentation. That time in front of a classroom doing SAP courses helped me gain an understanding of the user perspective, the client perspective, and the ability to facilitate effective requirements gathering sessions.

Many SAP trainers do not have the “luxury” of specializing in a single module.  Usually you learn the transactional processing of whatever module you end up being responsible for on each project.  As a result, many SAP trainers with a few years and a few project experiences have a fair process understanding of the application.  During my first few years of training I covered most of the major SAP modules [FN1].  This background was an invaluable experience for me.  Because of the results I’ve seen when knowledge transfer is done correctly I’ve become a real fan.

Experienced SAP Consultants and Knowledge Transfer

Genuinely seasoned consultants recognize that the time they have spent “in the trenches” cannot be replaced by one project’s knowledge transfer; therefore, they are not threatened by encouraging your understanding.  Many talented consultants thrive in an environment where they are challenged, and learning, and solving problems.  It is a dimension of a successful consultant’s personality and character.  So transferring knowledge is second nature to a skilled and experienced consultant.

Most often the truly skilled consultants with practical business and work backgrounds are the ones who can speak to issues in plain, understandable terms.  They have been through the go-lives, they have done the production support for the user community, they have had to work through the complex or thorny processing issues, they’ve seen where things were done right (and not so well) and they have gained a solid process understanding.  They do not have to rely on “fast talking techie speak” to keep you confused and in the dark.  And if you’re not clear on what they are saying how are the project team and user community going to understand them?

Having explained my bias, one of the most important things a company can require of their software vendor is knowledge transfer.  Done correctly this leads to operational independence.  Done poorly, or not at all, it leads to perpetual vendor dependence.  Worse still, done poorly the long-term organizational change and acceptance of the new system, new processes, and new way of doing business is much slower and more painful. In some of the worst cases strong enough resistance to the needed business change may lead to resistance and eventual failure of the implementation.

More on SAP Knowledge Transfer and Process Communication Skills

Most consultants come to a project with resumes that claim several years of full life-cycle project experience:

  • leading requirements gathering sessions,
  • developing blueprint documents,
  • producing option assessment whitepapers,
  • logging and troubleshooting complex issues with users,
  • performing actual knowledge transfer,
  • training client-side core team members,
  •  and post-go-live support.

For many companies looking to install SAP or other ERP applications many of the consulting companies deliver “generalists.”  These “generalists” do not have the critical application and process knowledge to ensure that your company will gain the critical “operational independence” you need for long term success.  Ask yourself how you are ever going to acquire the knowledge transfer your organization needs if the consultants who you are paying are also learning “on your dime.”

SAP Knowledge Transfer Requires Good Communication Skills

How can a consultant do any of the communication intensive project requirements without strong native language skills?  Any language barrier is a red flag that you may not receive the critical knowledge transfer you need for operational independence. The lack of ability to do knowledge transfer is a serious red flag which should be a warning that the consultant may not have the level of experience required for results.

I have seen the results of projects where the vendor team would not effectively transfer knowledge, and projects where it was effectively transferred.  While there are lots of reasons, some of the danger and warning signs of a problem vendor and of problem consultants are those who will not, or cannot, share their knowledge and move the dependent organization toward independence.

There are a number of warning signs indicating a serious problem.  For example:

  • Fast talking “jabber” that sounds sophisticated but is difficult to really understand.
  • “Techie” terms and jargon rather than plain native language terms that make sense and even help the uninitiated to understand (frequently this is an indication of a LACK of experience because the exposure the individual has is to the “technical” material they have reviewed or are learning online).
  • Lots of “consultant only” meetings where client counterparts are not invited to participate (some of these, like weekly team lead meetings for consultants only may be needed.  But excessive use of these should be seen as a red flag).
  • Layers of bureaucracy to get answers or to resolve problems from the “keepers of the knowledge” by the active or extended implementation team members (again, some of this is necessary as a practical measure from the extended user community).
  • Frequent failures to communicate changes in direction, or new requirements.
  • Constant refrains like “you don’t need to worry about that now” or “we’re not there yet” or “don’t worry, we’ve got that covered.”  Or worse still, “why do you need that?”  If you’re getting these types of responses without adequate explanations this should be seen as a danger sign.
  • Or, the all time classic “I’m (or we’re) too busy to worry about that now.”  And while many projects are busy, the knowledge transfer can not be neglected.

Effective SAP Knowledge Transfer Requires the Ability to Make the Complex Seem Simple

The important skill in all of this is the ability to take the complex and make it simple.  Anyone can take the complex and keep it that way, or even make it more complex, however those with real talent can help you understand what you need to know for success.  They are often able to do this in terms that you understand, and when the introduction of completely new and foreign concepts are introduced if they have enough experience they will have worked through it enough internally to be able to present understandable explanations.  Often times those fast talking consultants, who are hard to understand and use lots of jargon or technical talk that “sound” so brilliant are most often the fakes.

All of these fakes are more common than many clients realize, and more damaging to your implementation than you can imagine.  Even many vendors are duped and hire these consultants who hide behind their own lack of knowledge or experience by preventing you from gaining knowledge, or the ability to meaningfully challenge or review their work.  By preventing meaningful review of the consulting work you are billed for it is difficult or impossible to recognize the level of competence and skill (or more likely, the lack of it).

Knowledge Transfer Exceptions

There is one other perspective and cause to consider here: there are some projects where the client company (not the vendor) does not provide enough resources for the project, or will not commit enough of their core team member time that makes it very difficult to transfer much knowledge.  To achieve operational independence a company MUST commit their resources to learning the system, and learning it well, for long term health.

Trying to have core client team members do an SAP project while maintaining some additional responsibilities of their other job only hurts you (the client) in the long term.  The reason is that once you go live things will change, SAP will be your new system and the old ways of doing business will not all be supported.  As a result the more knowledgeable and capable your core team is the better and more productive it is for your business.

If you’re one of those clients where you really don’t care, money is virtually limitless, and you just want a warm body, then these types of consultants, their vendors, and the long term dependence on them are ideal for you.  If you’re looking for results and meaningful long term value, run from these consultants and their vendors like the plague.

Operational Independence is the Key Success Criteria or Measure of SAP or ERP Knowledge Transfer

To avoid this problem, your vendor contract might include a provision where you commit to the number of resources and time (client staffing levels) and the vendor is required to reach a point of operational independence within 2 (or 3, or whatever number) months after go-live.

Define operational independence as the client resource’s ability to troubleshoot and resolve transaction problems within the scope (or list) of the transactions that are implemented.  Also, the terms of your agreement might spell out that as of “x” date, the vendor agrees to support all client resources at “y” discounted rate (say 50% or less of the project rate) until operational independence is achieved.  See how your vendor reacts to this.  If they raise concerns, and want some contract language changed or modified to make things fairer and to spread the responsibility more appropriately that is fine.  But if they are resistant to such an arrangement without a clearly compelling reason you may want to reconsider whether they are the right fit for your project.

Combat this throughout the project by building some of these knowledge transfer expectations into other parts or phases of the project.  For example, by the time the project begins integration testing, the client resources should be able to configure or resolve “x” or “y” as part of the knowledge transfer.

How you resolve this is up to you, but let me assure you that knowledge transfer is a key component of every GOOD SAP project.  If your project is lacking in the knowledge transfer and you have provided sufficient resources you may want to take a long, hard look at your vendor and consultants.  You may be headed for more problems and more unnecessary expenses and cost than you know.


[FN1] I had trained classes on various parts of PP (Production Planning), SD (Sales and Distribution), MM (Materials Management), WM (Warehouse Management), FI (AR, AP, GL, and Asset Management)

Popular Searches:

  • yhs-fullyhosted_003

Related Posts:

Planning For a Smooth SAP Go-Live: Part 2

October 25th, 2008 by

SAP go-live steps and processes

2.  SAP Master Data. 

Ideally your master data processing should begin early in the process.  Identification of legacy data sources, and even raw legacy data extracts should begin during the Blueprint phase.  Experienced implementation consultants should be able to ensure that the key data requirements or data settings are also captured during the blueprint process. 

It won’t be perfect, but initial scope should have already been determined and experienced developers should be able to point you to the type of raw data records they will need to begin working with.  When you begin your SAP project you should immediately ask for SAP master data maps, layouts, and conversion information.  If the developers responsible for data conversion seem to “talk around” the issue but can not demonstrate very clear understanding of the details of the SAP master data requirement then you should be very suspicious. By the end of Blueprint legacy system master data requirements (extracts and layouts) won’t be complete but should be well underway. 

It is optimal to plan for Integration Testing to be done with converted data, even if the data is not perfect and not completely ready for prime time

Even though you may have to add a little more time to your initial project plan, it is optimal to plan for Integration Testing to be done with converted data, even if the data is not perfect and not completely ready for prime time.  By doing integration testing with converted data you will discover data gaps, process gaps, and other problems that can be addressed before you convert to a live SAP production system.  “Live testing” of converted data in a production system is the worst time to find out if the system will work.  Not only that, data corrections in SAP can be very involved and difficult because of the integrated nature of the system.

SAP Data Transformation or Data Conversion Methods 

There are four primary methods for data transformation into SAP: 

1)      Do the data transformations outside of SAP and legacy systems then feed pre-formatted data files into the system using standard input programs;

2)      Extract raw legacy data and do all of the transformations in custom programs or conversion tools inside of SAP;

3)      A hybrid that does some conversion outside of SAP and legacy and some at the time of conversion inside SAP;

4)      Or do transformations in legacy extract programs.
I personally prefer methods 1) or 3), if there is one method that I dislike the most it is probably 4).  There are mountains of data transformation tools available.  USE THEM!  I personally prefer MS Access, but that is for one time data conversion and one time “throwaway” transformation rules.  Over the years I have seen that the more cleanup and transformation on the data that is performed outside of SAP and legacy, in an automated and repeatable process, the shorter the development time.  Using that approach my experience is that is easier / less risky it is to resolve and mitigate data conversion problems.  The other side benefit of that approach is that it begins to press legacy employees to move away from the legacy app and begin learning more about the new system.
My personal method is to take unmodified, raw legacy file extracts, use MS Access to do as much data conversion, data cleanup, and data transformation as possible, and then use SAP Legacy System Migration Workbench (LSMW) tools to load the data. Over the years I’ve learned that I do NOT want any legacy data changes made at extract time.  It causes too many problems, and frequently it then leads to managing multiple, sometimes conflicting, transformation rules.  Often times a single change in an extract data set, before an intermediate or final transformation into SAP can completely compromise a data load.  And sadly, those “extract changes” rarely get reported so they are discovered by trial and error at load time.  
A good MS Access power user can do huge amounts of data transformation and file layouts to match SAP input requirements.  Done correctly, this then becomes an easily and quickly repeatable process.  MS Access is a quite capable data transformation tool, on a decent workstation it can manipulate hundreds of thousands, or even a couple million records “relatively” quickly for the lightweight desktop tool it is.  From there, SAP’s LSMW tool is quite powerful and has the ability to directly code individual field level transformation rules right into the program for any final “detailed” requirements. 

Suggestions for SAP data conversion:  

1)  Never leave off doing a “mock conversion” of data and capturing the necessary steps and times to do the real data conversion into your production client. 

2)  If you are doing a rollout of a new facility into an existing SAP instance, make sure you do some type of regression testing before you go into production.

3)  Plan for and be ready to support the master data maintenance efforts after go-live.

4)  Test and check every interface and batch job, both before the go-live and then within 24 hours of the first time they are run at go-live.

5)  Make sure to correct and clean up any master data issues immediately at go-live.  Each time that master data is referenced by a transaction without being corrected compounds the cleanup effort and the problem needing to be corrected.

Four Part Series on SAP Project Planning for a Smooth SAP Go-Live:

Planning For a Smooth SAP Go-Live: Part 1
(introduction, security and authorizations)

Planning For a Smooth SAP Go-Live: Part 2
(master data, data transformation methods)

Planning For a Smooth SAP Go-Live: Part 3
(process issues, blueprinting, testing, and change management)

Planning For a Smooth SAP Go-Live: Part 4
(custom development, costs and consequences of inexperienced developers)

Related Posts: