Business Solutions with SAP

Some Reasons SAP Projects are Over Budget and Over Time

July 11th, 2009 by
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

Popular Searches:

  • A project that cannot go over budget is considered

Related Posts:

Why SAP Projects Fail to Deliver ROI and How to Change IT

July 8th, 2009 by

Why SAP Projects Fail to Deliver ROI and How to Change IT

Part of the frustration with the failure of results in SAP implementations is the “hangover” from the Y2K effect.  At that time businesses everywhere simply wanted to install ERP systems to take care of the looming potential “crisis” over the millennial changeover.  The real promise of SAP was lost in the Y2K chaos.  After Y2K, the brief downturn in demand for ERP systems along with the tech bubble burst in the stock market created additional pressure.  The idea of delivering SAP implementations “better, faster, and cheaper” together with business benefit was lost in the confusion.  

Because so many custom systems had been developed from the era when disk space and memory were incredibly expensive, nearly all programs were written with 2 digit designations for the year.  The fear was that as we approached the year 2000, those same systems might read that date as 1900, have a different day of the week assigned, or not know how to handle the 2 digit date at all.  As a result there was a massive rush to implement ERP systems to manage this issue and to replace legacy systems with “off the shelf” software.  

ERP and SAP, Better, Faster, Cheaper but What About Business Benefit and Business Focus?

Leading up to Y2K the demand for replacement of these legacy systems with new ERP systems was so strong it lead to an almost exclusive focus on implementing SAP projects “better, faster, and cheaper.”  Certainly this is not a bad thing, but business alignment and business drivers got lost in the fog of technical system replacements.  Rather than doing system implementations that were focused on genuine business drivers nearly all ERP systems were installed as technical system replacements rather than being implemented for business benefit.

After Y2K, there was a continued emphasis by vendors and companies everywhere to implement and automate current business processes because that is the sales model (and competency) they had developed.  That sales model worked, presentations, approaches, methodologies, implementation tools, consulting training and prep, everything was centered around the Y2K “get it in” model. Projects focused only on existing business operations and on replacing existing IT systems.  Implementation methodologies and techniques for “better, faster, cheaper” implementations were developed to support these “quick hit” IT system replacements.

While every project should be delivered on time and on budget, the focus on only current business processes fails to address the forward looking nature of business.  Even to this day businesses implementing SAP still fail to see the system as any other kind of a capital asset where you build a business case with both a current state justification and a future state justification as well.  The current state is nothing more than the “on time, on budget” back office operational project requirements while the future state looks at business strategy and builds those into the application as well.  What do you want SAP to help you with in the future?

ERP Technicians Replace Systems – Consultants Use ERP to Transform Business

SAP projects fail to deliver for a number of reasons that have nothing to do with the software itself.  SAP projects that focus almost exclusively on “back office” processes or “operational excellence” find that they use lagging indicators.  These are important for evaluating current company health, and today’s (or yesterday’s, last months, etc.) indicators of marketplace performance, but these lagging indicators will not produce world class results most C-level executives are now looking for from SAP. [FN1] 

Today the marketplace still wants the “better, faster, cheaper” model of delivery, but now CEOs, CIOs, and CFOs are insisting that the application software must do more.  It must deliver something more meaningful. It must deliver strategy and forward looking business benefit.

Leading or Lagging Indicators? 

SAP projects, whether they are new implementations, upgrades, or re-implementations should begin with strategy, goals, and KPIs. In developing goals, KPIs (Key Performance Indicators) and performance metrics there are generally two types of measurement categories–, leading indicators and lagging indicators.  Leading and lagging indicators refer to “timing of cash flows within a corporation.”  [FN2] 

In the past, lagging and leading indicators have been applied almost exclusively to economic output, not necessarily to that of business, but the impact of business on economies. 

Recently, with the rise of the use of KPIs as a method to help drive business goals and strategy, the idea of leading and lagging indicators has been applied to business. In the context of economics, Wikipedia defines these indicators as:

Lagging Indicator  

A lagging indicator is an economic indicator that reacts slowly to economic changes, and therefore has little predictive value. Generally these types of indicators follow an event; they are historical in nature. For example, in a performance measuring system, profit earned by a business is a lagging indicator as it reflects a historical performance; similarly, improved customer satisfaction is the result of initiatives taken in the past. [FN3]

Leading Indicator 

[L]eading indicators are key economic variables… used to predict a new phase of the business cycle. A leading indicator is one that changes before the economy does. [FN4]

The Future of SAP – Strategic Implementation 

To finally realize business benefit from SAP, to achieve that elusive ROI and begin to make a difference in the way your company works, you must change the way you approach your implementation.  [FN5]

The Y2K days of any consultant who could learn to make system settings on the fly to support all those implementations are over.  With them, the thousands upon thousands of application “technicians” who got their start in SAP when the demand was so high may not be able to deliver in today’s tremendously competitive market. After all, now that the Y2K scare is long past, businesses everywhere are beginning to ask the really important questions of “how do we make this huge investment actually provide a return?”

The type of vendor and consultant you employ must have business and application experience.  Today more than ever it is critical to ensure you find the right resources and then do some up front planning and prep work yourself. 

Long before your implementation or upgrade project starts the implementation focus must change. 

While it is great to focus on process improvement, and that is critical in today’s market, it is no longer enough to win in today’s marketplace.  All of your competitors are working process improvement so it will not differentiate you in today’s market.  Does that mean you can ignore it?  Of course not, it still has to be done, but it must be done together with a serious strategy focus to your SAP implementation or upgrade.

Start by looking out at your competitive landscape, where are your company’s strengths and weaknesses in comparison to your competitors?  Are there areas in comparison to them that you are not executing particularly well?  Should you then focus on those processes to improve your competitive position?  In the areas you are doing well against your competition, should you emphasize those?  Are there market opportunities you are missing, or are there gaps in your product portfolio that partnering with another firm might help to fill the gap in?  Is your company large enough that you can change the vendor dynamic for certain key products or services by outright purchasing, or possibly underwriting new competitive vendors to ensure better products and services at better prices?

How do you use SAP to enable all of these processes you’ve just answered these questions to?  How do you develop the key goals and KPIs to meet the new market challenges out there in today’s competitive landscape?  What SAP reports or tools will be needed to support your leading indicators?  What KPIs should you focus on first?

There are many more mountains of additional things you can do to use SAP to achieve genuine business benefit, find that “elusive” ROI and make a real difference in the marketplace.  But to get there take the first step to changing your implementation approach–, start by defining the business reason for your implementation or upgrade before you even begin. [FN6]

[FN1]  Using SAP to improve Revenue and Profitability

[FN2] Bloomberg Glossary, (retrieved 9/21/2009)

[FN3] Wikipedia, (retrieved 9/21/2009)

[FN4] Wikipedia, (retrieved 9/21/2009)

[FN5] SAP as a Change Enabler

[FN6]  Change How You Look at SAP to create ROI

Popular Searches:

  • why sap projects fail
  • reasons why SAP failed in Nigeria

Related Posts: