Business Solutions with SAP
Storm Clouds pointing to SAP projects over budget and time

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

Reduce SAP Project Stress: Part 2 SAP Project Integration Points

Planning a Smooth SAP Go-Live

Planning For a Smooth SAP Go-Live: Part 1

Planning For a Smooth SAP Go-Live: Part 2

Planning For a Smooth SAP Go-Live: Part 3

Planning For a Smooth SAP 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

Screening Methods to Find the Right Consultant – Part 2

Corporate and Personal Liability for Fake Consultants


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

Related Posts:

One Response to “Some Reasons SAP Projects are Over Budget and Over Time”

  1. Hi Bill,

    Can you please talk more about serialized parts and components used in batch managed finished good? and we are creating subcontract PO for the finished good and issue serialized parts to them….

Leave a Reply