Some Reasons SAP Projects are Over Budget and Over Time

[Former Member]

For years I’ve heard the claims about blown budgets and blown timelines.  And I’ve been on a couple projects that went over budget and over time.  But in over fifteen years of doing SAP, on over twenty SAP projects, that has happened on only a few projects I participated in. [FN1]  In fact, on a few of the projects I’ve participated in we have come in under budget, but I can’t say it was ever early.

Aside from scope management, executive buy-in and participation, using a proven methodology, etc., there are other reasons that cause some projects to go over budget and over time--, the basic issues of coordination and consultant skill.

Good monitoring tools and consistently communicating the timeline and deliverables ahead of time, throughout the project, mitigates a lot of this.  But there are still project management issues that must be addressed.  Project tools must be sophisticated enough to allow time to resolve resource and task leveling constraints.  If they are not able to support task and resource leveling your project and its deliverables will be inconsistent and untimely.  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.

An Integrated Chain is Only as Strong as its Weakest 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.  

So, 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.  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.  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 to ensure a lot of rework.  A consultant’s lack of experience, or exposure, or, if they are a fake (which is VERY common in the SAP world).  It may be that one consultant or module is far behind, or far ahead, of another module for any reason at all.  
 
There are two solutions to these issues.  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.  

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.  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.

Who is the Optimal SAP Consultant who can Develop Great Solutions? 

Please keep in mind this is just my opinion, but experience has shown me it is the consultant with several small and mid-sized projects under their belt.  The consultants with a significant amount of Small and Midsized business implementations have substantial skill at delivering SAP solutions.  This is true even if the solution includes significant portions of functionality and even if the integration crosses several modules. 
 
Because the small and midsize business segment of R3 implementations by nature uses smaller teams, smaller implementation budgets, and tighter timelines, the consultant must know their area of responsibility well.  They don’t have someone else on their team to fall back on.  They are the go to person for the whole module they are covering, often times including the integration touch points with other modules.
 
Consultants who have worked in the small and mid-sized space don’t have the luxury of the big consulting firms, on their mega projects, where they can specialize in one little component of a module at a time.  On top of this, small and midsized SAP implementations often don’t have the resources or the budget for large change management and training staffing for the project.  The consultants on these projects often end up supporting both change efforts and training.
 
These consultants, the ones with many years of small and mid-sized business exposure are able to do in a few hours, or possibly a few days, what takes consultants with less exposure weeks to figure out.  Even if it is a bit of a stretch, they have enough background, enough exposure, and enough experience to be able to start immediately with 80% or more of the solution.  From there it is just detailed testing of different settings to be sure you have just the right combination and the process or transaction behaves exactly like you planned. 
 
These small and midsized market consultants are less likely to need lots of custom coded solutions because they can either figure how to do it with standard functionality, or figure out how to “repurpose” other functionality for your company’s particular need.

A Couple Examples from the Trenches 

Cross-Company Supply 

I’ll give you just a couple of examples from my own experience.  On the first, I was on a very large project that had cross-company supply issues that no one had been able to resolve for about two months.  There were weekly meetings, and weekly arguments, and no one could agree on the solution.  And it wasn’t simple either.  There was third party cross-company supply where one company code would take the order, transfer the requirements to a separate company code who would actually carry out the delivery but they would bill the other company who in turn billed the end customer and collected the payment.  Then there was also cross-company supply where there were goods being exchanged back and forth between not just different company codes / legal entities but also between countries requiring foreign trade functionality.  After several weeks of this dragging on, I got into a “heated discussion” (read argument) with an MM consultant on how to do this.  Whether it was a language barrier, a difference of experience, or whatever it was I don’t know.  But he and several other of the “experienced” consultants insisted that SAP couldn’t handle the functionality without tons of custom ABAP coding.
 
I’d wasted enough time; the client's time, the other consultant's time, my time, and everyone was frustrated. Blueprint was over and we were still in design on a key set of processes.  This prompted me to take 2 days to set up a prototype solution, with all of the functionality, and get off the crazy meeting merry-go-round.  The standard SAP functionality did over 90% of everything that was needed for every process and transaction they needed to do.  To ensure there were no more arguments over this issue, after the prototype was set up, and without telling the other consultants who insisted it wouldn’t work and they wouldn’t support it anyway, I just set up a meeting with all of the key stakeholders, and with the client project manager to demo the new functionality to see if it met their needs.  They were thrilled.  The meetings and arguing were over and no more time on these ridiculous discussions to flow out processes for unneeded custom ABAP solutions.  It was nearly finished with standard functionality. [FN2]

Serialization 

Another client had serialized parts and components they used in their production process.  However they needed the ability to do repair and recovery work from serialized components that were added to completed sub-assemblies and completed, serialized finished goods.  They also wanted to track warranty requirements.
 
Another heated discussion occurred between the experienced consultants and myself.  The MM consultant insisted that the only possible way to do what they wanted was to use SAP serialization, and I insisted that a better, more productive fit would be batch management.  The SAP serialization functionality is very, very restrictive and difficult to do any sort of rework, repair work, etc.  It does integrate nicely with warranty processing however. 
 
In the end there were a number of limitations with serial numbers that batches worked perfectly for.  SAP serial numbers can not be “consumed” during the production process.  So while you can put the materials in a BOM and plan them, you must manually assign serial numbers to components after production is completed and through a separate set of transactions. Batches on the other hand can be consumed in the production process, search strategies can be set up to automatically pick batches (that can be manually changed later), batches can be “merged” or “split” and they can have characteristics attached to them.  These characteristics can be manually or automatically entered as well depending on the data.  Also, SAP supports “batch genealogy” so that you can see the batch data that went into the end product.  If the batch number itself is not long enough, you can create a characteristic with the “serial number” to record as well.  
 
In the end, batch functionality was the perfect fit.  The batch number could be unique just like a serial number and equipment records are able to be created to tie back to the batch for warranty purposes.  “Recovering” batch components from repair or rework is fairly straightforward, batch search strategies can be used to automatically propose “batches” (i.e. serialized components) for production consumption.  Batch search strategies can be used to automatically propose them for picking at sales related delivery time, any warranty related information can be tracked in the characteristics of the item and those characteristics can be used to track some of the warranty related information.  There are standard SAP reports for batches and batch usage (as there are also for serial numbers) and the SAP batch functionality is robust, mature, and reasonably well known by experienced consultants in the marketplace.  One other advantage of the batch functionality is that if the proposed batch (i.e. serial number) for consumption on the production order is different than the one you want to consume, it can still be manually changed. 
 
In the end the client went with SAP serial number functionality, even with its gaps in relation to their needs, because the MM consultant had a tantrum and said that they wanted serial numbers and that was the only thing he would do or support. Unfortunately, even when you try to do what is truly in a customer’s best interests, and provide them with the best possible solution, it is not always possible depending on the skills and understanding of the consultants on the project.  This particular consultant I know actually has several years experience and his refusal to do batch management may have had more to do with the amount of setup effort on his part, but it was the right solution for this client.

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

[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 frequently staffed projects with what would be considered today as "Platinum" level resources.

[FN2]  In fairness to the other consultants who thought this could only be done through ABAP custom coding, it does require a major amount of setup in SD, MM, FI, and EDI to work correctly.  While it is all standard functionality, consultants with experience on very large projects have limited exposure to even their own module of expertise.  As a result it is unlikely that the full breadth of this and other functionality has been seen outside of the small and midsized business space.  In the small and midsized business space the consulting teams are smaller, and out of necessity are more knowledgeable within their module area, work more closely together with other module consultants and tend to gain greater application exposure to standard functionality options.

Additional Resources: 

Screening methods to find the right SAP consultant
http://www.r3now.com/modules.php?name=news&file=article&sid=2

Reducing SAP Project Stresses Part 1: Expectation Setting
http://www.r3now.com/modules.php?name=news&file=article&sid=9

Reducing Implementation Project Stress, Part 2
http://www.r3now.com/modules.php?name=news&file=article&sid=8

Planning for a smooth Go-Live: 4 Part Series
http://www.r3now.com/modules.php?name=news&file=article&sid=13

Planning for a smooth Go-Live: Part 2 of 4
http://www.r3now.com/modules.php?name=news&file=article&sid=12  

Planning for a smooth Go-Live: Part 3 of 4
http://www.r3now.com/modules.php?name=news&file=article&sid=11  

Planning for a smooth Go-Live: Part 4 of 4
http://www.r3now.com/modules.php?name=news&file=article&sid=10

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