SAP ROI — Enterprise Architecture & Business Solutions

SAP Project Blown Budget-Timeline

For years I’ve heard the claims about blown SAP budgets and blown SAP project timelines. Participating in SAP projects since 1994, on over 20 SAP projects, I’ve experienced a few project overruns [FN1] and on a few others, we have come in under budget.  I can’t say any of the projects were ever early. While I believe that coming in under budget is often possible reducing the time frame is much more difficult because of the planning and coordination processes.  Trying to adjust all of the parallel work streams together on a project plan, and getting the coordination and timing correct is much more of a challenge.  In other words there are lots of moving parts that you have to change the timing on.  That is unless you are an SAP “project manager” who has an aversion to using normal WBS, Network, and Activity based project plans.

Aside from 1) scope management, 2) executive buy-in and participation, and 3) using a proven methodology, etc., there are other reasons that cause some SAP or ERP projects to go over budget and over time–, there are basic issues of project coordination and consultant skill.

SAP Project Management Planning and Coordination

After the scope, deliverables list, and a project plan you need good monitoring tools.  A project manager must also consistently communicate the timeline and deliverables ahead of time, throughout the project, to mitigate blown timelines.  They must also provide key templates and the instructions on using them effectively throughout the project, ahead of time.  However there are still other project management planning issues that must be addressed.

A good project plan and methodology will have “tools” and templates that are sophisticated enough to allow time to resolve resource and task leveling constraints.  The deliverables must be designed to support the completion of key milestones and project activities so that they demonstrate not only completion but quality as well.  More than just a “checklist” deliverables should instill some confidence that the project activities they address were done well.

Project plan micromanagement has a way of killing project momentum and destroying project team morale

If deliverables tracking ”tools” are not able to support task and resource completion status of the deliverables then a project manager does not have the correct tools to make critical resource leveling decisions.  Your project and its deliverables will be inconsistent and untimely. And by deliverables tracking “tools” I am NOT referring to the project plan.  Project plan micromanagement has a way of killing project momentum and destroying project team morale.  For more information on this, please see the first section in ERP, SAP, or IT Project Management and Prototyping for Success .

One of the biggest problems I have seen from inexperienced project managers is planning at such a detailed level that they spend all of their time micromanaging individual tasks and miss a lot of the “trains” coming at them further up the project track. They overload a project with the “appearance” of managing it through stupid “trackers” and monitoring tools that are overly complex and add little value to the project.

If you have the wrong consultants on the project you will be forever in design mode throughout the entire project which may blow timelines and budgets.  One of the unfortunate side-effects of this type of consultant is that you generally begin to get that sinking feeling around integration testing time.  And by the time you are at integration testing you have moved so far down the track that it is sometimes too late.  For some ideas on how to prevent this, please see the post on  Breakthrough Project Success: Part 4 of 4, Last Low Risk Chance for Results for some techniques and ideas on reducing this type of consulting mismanagement.

Business Process Chains are Only as Strong as their Weakest Project Link

SAP’s integration between all of the functional modules creates interwoven process chains.  These process chains require complete dependence on each other during an implementation so that the integration touch points between the modules are properly designed. For example, SD (Sales and Distribution) and MM (Materials Management) must tie into FI (Financials) for the posting of Revenue (SD-FI), issuing stock from inventory (SD-MM-FI), scrapping stock (MM-PP-FI), and a whole host of other areas where there are tight process dependencies.

As an SAP project (or any ERP project) progresses, each of those process silos (SD, MM, PP, FI, CO, TR, HR, etc.) has to be coordinated so that they are at roughly the same place at roughly the same time. If you are doing configuration of master data in one area, such as the material master setup, purchasing, sales, production and finance can’t be very far ahead. There is a direct dependency on the material master. And for finance, if you are doing the setup for the sales and invoicing processes it is important to slow down enough to ensure that the accounting for revenue recognition and customer receivables is properly configured. If any module gets too far out in front of other modules it can have devastating impacts on the others. There may be a lot of rework or re-design needed, or, if a dependent area gets too far ahead they may be consuming too much of the other module consultants’ time and attention trying support that modules integration points and their work may suffer unnecessarily.

Keys Why SAP Project Timelines and Budgets are Blown

What are some of the other key problems that cause budgets and timelines to be blown?

The first and most obvious is when the timeline and scope are not realistic.

Beyond this it can also be anything that causes any one project area to get “out of synch” with another project area.  Some of the reasons for projects getting out of synch include when scope is too large in one particular module for the number of resources assigned. It may be that one consultant or module is far behind, or far ahead, of another module for any reason at all.

Other times it may be that the business has not dedicated the right core team members and they do not have sufficient knowledge of the business, or know where to get it.  When the wrong business-side core team members are assigned to a project you can be sure there will be lots of missed items and lots of rework no matter how skilled a consultant or system integrator is.  There is little substitute for the business-side resources and their level of experience within your company and industry.

A consultant’s lack of experience, or exposure, or, if they are a fake (which is VERY common in the SAP world) may contribute to problems.

There are two solutions to many of these issues.

1) The first and most important is to make sure your vendor staffs your project with only the right consultants with verifiable and deep SAP experience (see Screening and Interview Methods to Find the Right SAP Consultant and Screening and Interview Methods to Find the Right Consultant – Part 2).

2)  After that, it is a project manager’s responsibility to ensure that client and consulting resources are leveled and adjusted as necessary throughout the project.  When a project manager tries to manage a project at a too detailed task level they can get “lost in the weeds” and not realize that their project is headed for trouble.  The project manager must have the tools and resources to recognize if the teams are on track, off track, or starting to get out of synch. And the tools to support this must be sufficient enough to allow early enough notice to make the necessary staffing and resource adjustments.

In a nutshell a project manager must have a list of deliverables, and with that list of deliverables a set of mechanisms for tracking the progress on those deliverables which roll into the project plan.

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

[FN1] I attribute that success rate to the two consulting companies that I worked at before going independent. They had philosophies about implementation that helped clients realize success. Both of them had very focused policies about getting experienced consultants who had both SAP and business experience. In all the years since I’ve been independent I have seen few projects with that caliber of consultants. It took me a while to realize that these companies I worked for early on frequently staffed projects with what would be considered today as “Platinum” level resources.

Additional Resources for SAP Projects:

Some methods to reduce SAP or ERP project stress

Reduce SAP Project Stress: Part 1 Setting SAP Project Expectation Setting
http://www.r3now.com/reduce-sap-project-stress-part-1

Reduce SAP Project Stress: Part 2 SAP Project Integration Points
http://www.r3now.com/reduce-sap-project-stress-part-2-integration-points

Planning a Smooth SAP Go-Live

Planning For a Smooth SAP Go-Live: Part 1
http://www.r3now.com/planning-for-a-smooth-go-live-part-1

Planning For a Smooth SAP Go-Live: Part 2
http://www.r3now.com/planning-for-a-smooth-go-live-part-2

Planning For a Smooth SAP Go-Live: Part 3
http://www.r3now.com/planning-for-a-smooth-go-live-part-3

Planning For a Smooth SAP Go-Live: Part 4
http://www.r3now.com/planning-for-a-smooth-go-live-part-4

How to screen for SAP consultants
Avoid fake SAP resumes, fake SAP experience, and get the experience you pay for.

Screening methods to find the right SAP consultant
http://www.r3now.com/screening-methods-to-find-the-right-sap-consultant

Screening Methods to Find the Right Consultant – Part 2
http://www.r3now.com/screening-methods-to-find-the-right-consultant-part-2

Corporate and Personal Liability for Fake Consultants
http://www.r3now.com/corporate-and-personal-liability-for-fake-consultants

Related Posts:

• Planning For a Smooth Go-Live: Part 3
• ERP Project Plan: Getting Real Part 3
• SAP Implementation Projects: Still Crazy After All These Years
• Reduce SAP Project Stress Part 3
• ERP Project Plan: Getting Real (Part 2)

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:

• How the SAP Consulting Peter Principle Works
• Series on SAP ERP Project Success Factors
• SAP System Vendor Project Success Criteria 1
• SAP Success Factors for Vendor Selection – Responsibility Matrix 1
• Toward an SAP Center of Excellence or SAP Competency Center – PART 3