Business Solutions with SAP

SAP ERP Project Failures Lessons Learned and Mini Case Studies 2

December 20th, 2010 by
SAP ERP Project Failures

SAP ERP Project Failures

The following SAP ERP project failures cover the importance of testing, change management, training, senior management involvement, scope management, and quality of the consultants provided by ERP implementation vendors.

With the exception of the inept, incompetent, or otherwise unqualified “con”sultants provided by some system integrators it is important to note that these failure overviews illustrate many of the points made by Steve Phillips in the post on Software Consulting Firms and Clients Myths and Half Truths .

There Mr. Phillips lays out pretty significant areas where the business must chart and then control their own project destiny.

For a table of the primary areas of responsibility for end customers to ensure project success please see SAP Success Factors for Vender Selection – Responsibility Matrix 2 .  The table developed there is derived from the academic literature and my own experience.  I have added my opinion on how the responsibility for those success factors is divided between the customer and the SAP implementation partner or vendor.

Continuing on the series of SAP ERP project failure overviews, here are three more.

SAP ERP Implementation Failure Overviews – part 2

Levi Strauss & Company – SAP Failure? (2008)

  • After go-live shipping was prevented for one week and there were legacy system integration issues.  Levi was an interesting case study because many industry experts believe the SAP implementation was used as an excuse for broader economic issues affecting Levi.
    • One week of delayed deliveries was insufficient to explain the overall drop in financial performance (approximately 98% decrease in revenue could not be sufficiently tied back to the SAP implementation).
  • Levi Strauss has since worked through and resolved the implementation issues and SAP is running smoothly.

Lessons Learned: Ensure that all legacy system interfaces are carefully tested before going live. Don’t use SAP or enterprise application implementations as an excuse for poor economic or poor overall market conditions.

Waste Management Incorporated – SAP ERP Failure Overview (2008)

  • Waste Management claimed in its lawsuit that they “wanted an ERP package that could meet its business requirements without large amounts of custom development…” They also claimed “SAP used a ‘fake’ product demonstration” and “SAP’s technical team had ‘recommended that SAP deliver to Waste Management a later version of the software than the version SAP in fact delivered’.” They also claimed SAP knew the software was “unstable and lacking key functionality…” [FN1]
  • SAP claimed that its application could meet the company’s needs without modification.
  • SAP claimed in its legal counterclaims that “Waste Management didn’t ‘timely and accurately define its business requirements’ nor provide ‘sufficient, knowledgeable, decision-empowered users and managers’ to work on the project.” [FN1]

Lessons Learned: First and foremost any organization or company who implements SAP, ERP, or other enterprise software applications must ensure they are in control of their own project. This would generally fall under numerous critical success factors: business process engineering / change management, scope management, senior management support, formal project plan and schedule, consultant experience, implementation strategy, and amount of custom coding.  Delivering a project with standard system functionality, and on time / on budget requires strong leadership from both the customer and the integrator.  For additional insight and a somewhat different perspective please see the post where SAP and Waste Management Finally Settle .

Los Angeles Unified School District – SAP ERP-HR Failure Overview (2007)

  • Fake Consultants / Trainees / unqualified consulting resources on the project
    • “[I]t appears Deloitte (the implementation partner) brought unqualified resources (i.e., personnel) to the project.” [FN2, pg. 28].
    • I personally encountered one of these fakes as a project manager for another company looking for a workflow resource.  Their ABAP and SAP skills were horrible but they got a great reference from LAUSD.
  • Lack of cooperation with the Teacher’s Union and no user buy in.
    • This is a project planning and change management issue; the company and the integrator bear this responsibility.
  • Has since worked through and resolved the implementation issues and SAP is running smoothly.

Lessons Learned: SAP implementation vendors and partners may allow margin desires to override quality to the point of presenting significant project risks.  It is critical to evaluate every consultant any integrator brings onto your project.  There are just too many fakes in the marketplace that do not have proper background checks.


[FN1]  SAP, Waste Management settle lawsuit.  Business Week. May 3, 2010. (retrieved 5/11/2010)

[FN2]  Bhagwani, A. (2009). Critical Success Factors In Implementing SAP ERP Software, University of Kansas Graduate School.

Popular Searches:

  • sap implementation failures
  • waste management erp sap case study first publication in 2008

Related Posts:

SAP System Vendor Project Success Criteria & Factors 5

November 29th, 2010 by

High Performance SAP ProjectThis is the final post in the series on SAP project shared success criteria.  Doing this entire topic justice has been more of a challenge than I had originally anticipated and at some point I will put it all together in a PDF e-book. 

This series leaves you with a lot to digest but over the years these items generally make up the foundations for a very successful project that is able to transform your business.  This series has been challenging but interesting and I am glad it is complete. 

In a few more weeks I will be coming back around to try to wrap up my series on SAP reimplementation for little more cost than a technical upgrade.  That one turned out to be more challenging than I had originally expected.  Until then, here is the final installment in this series on project success criteria.

No. SAP or ERP Critical Success Factor Company Integrator
5 Experienced SAP consultants   A
7 SAP implementation strategy z A
8 SAP project management A z
9 SAP tools, templates, and resources   A
10 SAP scope development z A
11 SAP scope management A z
12 Strong SAP project and business communication (inward and outward) A z
13 SAP change management A z
15 Sufficient SAP training (user and project team training) A A
16 SAP system vendor and customer trust   A
17 SAP system design decisions z A
18 Amount of custom ABAP or other SAP coding z A
19 Appropriate SAP software configuration (system settings) z A
20 SAP system change control process   A
21 SAP data analysis and conversion A z
22 SAP test planning A z
23 SAP test development z A


A = Primary Responsibility for the success factor
z = Shared but secondary responsibility for success

21.  SAP Data Analysis and Conversion

One of the major activities of an SAP project is the data analysis and conversion. On many projects there are too many new data requirements or data changes needed after the system goes live.  One way to avoid so many of the data correction in a live production system is to ensure that you have sufficient integration and cutover testing.  We will look at testing in a moment.

The primary responsibility for data conversion is generally on the customer.  Customer primary responsibilities include:

  • Identifying legacy and other data sources
  • Cleaning or scrubbing the data
  • Ensuring the converted data meets business processing requirements
  • Defining sufficient test plans to validate data is properly converted
  • Provide sufficiently skilled employees to work the data
  • Make as many data corrections as possible in legacy systems before conversion
  • Ensure there are sufficient hardware resources available for meaningful data conversion tests

I’ve developed a short list of the common data conversion risks as adapted from the SAP ASAP 7.0 Data Migration and Risk Assessment Template.  That template, provided by SAP, contains a sample issue and risk log, and includes some suggestions on how to manage the following common data conversion risks:

SAP Data Conversion Project Management Risks

  • Improper estimates of data migration effort and activities
  • Client side skills gaps on data migration
  • Deferring data corrections until after go-live
  • Knowledge of and access to data sources
  • Insufficient or incorrect change control processes
  • Insufficient participation from key functional project team members (client and consulting)
  • Improper management of dependencies between functional areas or modules. 

SAP Data Technical Conversion Risks

  • Lack of agreement on system of record, data definitions, standards, transformations, conversion methods, etc.
  • Data migration tool(s) not well defined or settled
  • Hardware sizing and data volume are inconsistent
  • Requiring historical data conversion (rather than using legacy systems for historical purposes)
  • Multiple legacy sources of data for single master record loads in SAP.
  • Data gaps – no corresponding data record for SAP conversion
  • Different data structures between legacy systems and SAP.  For example SAP may have structured hierarchies and the source data may not.
  • Poor data quality – errors, duplicates, inconsistent use of fields

Preparing conversion programs, or more specifically, using SAP’s variety of conversion tools and resources is a vendor responsibility.  Together with that the vendor, who has set up the system with the master data requirements is also responsible for providing data load templates as well.  Further the vendor’s functional consultants must participate in the data conversion design and development activities because they are the ones that set up the system and know the master data requirements better than anyone.  The only exception to this is if you decide to bring in consultants who do knowledge transfer to your implementation team and your own internal team does all of the system setup.

For an overview of the various data transformation methods in an SAP project please see the following post:

Planning For a Smooth SAP Go-Live: Part 2

SAP Blueprint Master Data Requirements

As a final note, a system integrator should be able to provide a first pass at basic master data requirements by the end of the Blueprint phase.  In fact your SAP Blueprint should contain a technical blueprint section with significant amounts of detail. 

  • It should include each master data type (Material Master, Vendor, Customer, Routing, Sales or Production BOM, Work Center, Chart of Accounts, Profit Centers, Cost Centers, etc., etc., etc.)
  • And it should include each master data SUB type, using just the Customer Master as an example it should contain the requirements of sub-data types, for example you may need Ship-To Customers, Sold-To Customers, Bill-To Customers, Payers, Agents, Freight Forwarders, Carriers, one-time customers, web shop or online customers, etc.  This type of breakdown and segmentation should be done for every data type so that you know what data conversions are necessary.  And this level of detail MUST be contained in a sufficient blueprint.
  • At the end of the blueprint, to ensure that you have all of the master data requirements covered as well, your system integrator SAP blueprint document should contain the specific details of every transaction data type.  That transactional data requirement will be a key part of the data conversion.  For example using the Material Master and inventory movements SAP provides the blueprint document should contain the specific types of inventory movement transactions you perform.  Simple goods receipts, goods issues to production, goods receipt from consignment stocks, issues to consignment stocks, scrapping, shipping / distribution goods issues, receipt into restricted / quality hold, move into unrestricted from quality hold, transfer from plant to plant, transfer from storage location to storage location, etc., etc., etc.

 If your SAP system integrator Blueprint does NOT have this level of detail then it is not sufficient to set up the system and perform the necessary master data conversion.  Further, if it lacks this level of detail you may want to fire your system integrator and demand a refund of at least part of what they bill.

By having this level of detail at the end of SAP blueprinting (process details, master data details, interface requirements, forms, reports, etc.) you can immediately move into setting up the system. If you lack this level of detail you may find yourself forever in design mode (revisiting normal blueprint requirements) and blowing both the budget and the timeline.

I suggest you add this summary of the type of detail you want by the end of the blueprint phase to your contract.

22.  SAP Test Planning

You will have to determine who needs to perform what testing, when, and where.  Together with that you will also want to use this as an opportunity to get both “power users” and non power users involved in the testing.  This becomes the early part of knowledge transfer as well as user acceptance testing.  Inevitably the additional resources from outside of the project team will discover gaps or items that might need to be addressed. 

The Test Planning responsibility is primarily on you as the SAP customer.  Your primary goal here is to ensure that every process you put in scope is represented in some type of testing script. For example, in your order to cash process you might want test scenarios that include credit processing with and without product returns; third party drop shipping to the customer direct from the vendor; pro-forma invoice processing and then follow-up commercial invoice processing; interfaces to and from various external systems; online order entry processing with and without manual intervention; backorder processing and sourcing from other facilities, etc.  At a high level you will be responsible for ensuring that you cover all of the key processes that need to be tested.

SAP Test Strategy and Testing Approach

  • SAP Test Management
    • Test planning, scheduling, and logistics / coordination
      • Identify users to perform testing
      • Identify who will coordinate testing activities
      • Location and equipment logistics for testing
      • Method for communicating test schedule to participants
      • Test data – common master “data sets” to use for testing.  This is different than the converted data testing.
  • Types of SAP Testing and Methods for Testing (whether manual or automated)
    • Unit testing (single transaction)
    • Business Process testing (unit test strings within the same functional module like SD, MM, PP, FI, CO, etc.)
    • Integration testing (Business Process testing including the integration points with other functional modules)
    • Interface testing
    • Data conversion testing (test the data load programs)
    • Converted data testing (test the converted data at performing various functions)
    • User Acceptance Testing
    • Regression Test
    • Batch Job testing (test batch programs, timing, and sequence)
    • Security Test
    • Performance / volume testing
    • Any positive and negative testing requirements for security or transactions
    • Ad hoc testing of unplanned variations and variants
  • Testing Toolset (various spreadsheets, or automation tools for building and managing the testing process).
  • SAP Test Reporting and Analysis
    • Test Metrics
    • Defect Management

Change Control Process (for an overview and details of the SAP change control process see SAP System Integrator Shared Success Criteria Evaluation 4 which focuses critical success factor on #20 on this list of “System Change Control Process”). 

As for a test script, I have included an example one which is a modified version of the standard options SAP provides as part of the older ASAP methodology.

EXAMPLE SAP TEST SCRIPT with Ad Hoc or Variant Section information.

23.  SAP Test Development

As for test development this is clearly a vendor primary responsibility.  Unless you use SAP’s integrated Solution Manager resources for testing this is probably one of the areas where you will have to rely heavily on your SAP partner. The reason this is primarily a vendor responsibility is that as an SAP customer “you don’t know what you don’t know.” 

Unless you have adopted an approach where you require the implementation vendor to act as pure consultants, where your own project team does all of the system setup, you will not know the detailed testing requirements.  As a result a vendor must be able to walk you through the transaction strings and dependencies.  They must be able to take the entire process-related solution they blueprinted from master data creation through cash processing and any interfaces or manual steps in between. 

Because of time, budget, and limitless possibilities there is only so much testing in a project.  These limitations create a requirement that only a “limited universe” of testing can be accomplished and SAP system integrators will usually require someone to sign off on those limited tests. 

There are a few things to beware of here:

1) When the tests have been “gamed” to support only a successful outcome and not to actually test the solution.

2) When a system integrator pushes back on testing variations that they may not have documented in the “formal” test scripts.

3)  Any vendors who engage in hard push back against additional ad hoc, variant, or converted data testing.  Unfortunately I have seen a couple of the major SAP system integrators KNOWINGLY push trash on their customers.

For a thorough testing program you should always ensure your tests include any of the custom development objects as well as manual processing steps.  For example, a thorough test process must include testing of any outputs (forms), interfaces, enhancements, and reports.  Data conversions should also be tested but may be done separately.  However, one strong word of caution here, once converted data is available, even if you do not do formal testing, be absolutely certain to do as much process testing as possible with the converted data.  Testing with converted data will reveal a number of potential problems that can be corrected or resolved before you go live.

Popular Searches:

  • sap uat testing template
  • sap user acceptance testing template
  • sap uat test plan
  • UAT scripts for SAP successfactors
  • crm uat template
  • user acceptance testing project plan for sap implementation
  • Uat testing on live and dead meter in sap
  • uat sap template
  • uat sap
  • SAP user acceptance training
  • SAP user acceptance testing
  • SAP UAT Template pdf
  • erp uat
  • user acceptance testing steps project plan for sap implementation

Related Posts:

ERP Project Plan: Getting Real (Part 2)

April 16th, 2010 by

SAP Project DimensionsThirteen Dimensions of Project Scope

In many cases the ERP project plan is not worth the paper on which it is printed. Worse yet, many project managers shoot themselves in the foot by prematurely committing to a project schedule and budget that sets unrealistic management expectations. The problem is once cast, expectations will not go away and only come back to haunt you later.  Could this be one reason why many ERP projects “fail”?

Even when the schedule and budget are “formally” published, inadequate definition of project scope (and boundaries) is a major reason the plans are invalid and quickly tossed out the window. In other words, we need a project scope, schedule and budget that closes expectation gaps. A project plan people can believe and use to actually manage the project. What a crazy idea!

Project scope not only drives baseline project schedule and budget; but it also sets user expectations regarding what they will get (and not get) within the software functionality. When users are later told something is out-of-scope they really need, the project is in for many unhappy users or scope creep that results in surprise cost and schedule overruns. Take your pick.

Finally, a good scope document represents a major tool for the project manager to control the project. Like a referee in a football game the project manager needs the ability to throw the yellow flag. However, it is always best when all parties involved understand the rules of the game before the ball is put into play.

Purpose of this Project Scope Article

The purpose of this article is not to imply good or bad scoping decisions. The goal is to assist the practitioner in understanding the key elements of scope, potential implications, and set the right expectations. Next this enables the practitioner to develop a schedule and budget that is real and people can support. After all, it is people that must make this plan a reality.

I make reference to the “dimensions” of project scope. This is because scope and boundaries do have dimensions in terms of different views of the project, level of detail and other twist that warrant a separate and distinct perspective on scope. With regard to the actual deliverable, most of the dimensions below should contain a list of items, and each with a “degree of complexity or effort” (high, medium or low).  In the next blog entries, we discuss how this information is used to develop a project schedule and budget.

The Thirteen Dimensions of ERP Project Scope and Boundaries

1) Align scope with project objectives

The fact is most organizations implement ERP for business reasons. Therefore, project objectives (what you want to accomplish) must initially drive project scope, not the other way around. It is never a good idea to proclaim the project will solve all the world’s problems, and at the same time, limit scope to the bare bone necessities to get the software running on the computer. This is where “rapid deployment” strategies get into trouble since they are  designed to limit scope for the sake of time and cost (though outcomes are far from guaranteed).

Furthermore, last minute acts of desperation to cut scope to get back on schedule are usually done without a full understanding of the original objectives that are now compromised. Therefore, if scope is to be cut half-way through the project, objectives and expectations must be realigned with the new reality.

On the other hand, too much scope beyond what is required to achieve objectives (and for the software to function effectively) is not a good thing either. This is usually not a popular philosophy among users, but a necessary one since “scope creep” is inevitable to some degree on any project. Therefore, early on it is important to “condition” managers and users that the system is not intended to be “all things to all people” and expanding scope will not be easy. In fact, once approved, any proposed changes must be business justified and approved by senior management.

2) The Number of “Sites” involved

For the purpose of this discussion, a site is defined as: 1) a physical location, or 2) a logical site. For example, there could be more than one “business unit” at a location, each having its own customer service group using the same software. In “multi-site” scenarios, the scope issues are three fold.

First is the coordination and communication effort required to get and keep all team members, key managers, and users at each site on the same page. Not to mention, I have yet to see any multi-site implementation where a certain amount of politics and finger-pointing between sites did not slow progress. This does impact project effort and how quickly things move along.

It gets worse when the same software module is to be installed in more than one site. In this case, decisions regarding “common” versus “unique” requirements at each site are necessary; and this takes time. This also plays into the decision to treat a given business process at each site, as a single or separate process from a design and set-up perspective. In any event, if the plan is to “reinvent” the wheel for each site, this will increase complexity, schedule, and cost (scope).

Finally, each scope dimension below should be defined at the site level (if the goal is to get a good picture of what the project truly entails).

3) Software Modules

The modules to include in scope drives the overall footprint of project. No doubt, this is one of the first steps in addressing scope. The bad news is when some put a project plan together, the software modules in-scope are one of only a few things considered.

The problem is without further definition, it is difficult to understand what “modules” mean from the standpoint of establishing expectations with users and estimating project duration and budget.

Beyond the fact that modules lack sufficient detail, some modules are more involved than others. For example, anything with the word “advanced” in front of it usually means more complexity, more risk, more time, and more money.

In addition, whether a module implies advanced or not, some modules are  inherently more difficult to implement for most organizations. As an example, the Purchasing module in most packages is usually less of an issue than the Sales Order module. This of course is not universally the case; but level of complexity should not be ignored.

4) Key Features and Functions within each Software Module

This is a lower level of software detail often over looked. Each module has features, functions, and capabilities. It is always best to consider  the capabilities to be utilized right up-front. Otherwise, consultants and the team will waste time and money setting up software functionality that client management has no intention of implementing (or adds little value to the overall objectives). Granted, some discovery may be required to understand the applicability of features and this is never a perfect process. However, this is different then going far down the road spending time on features of marginal value (and no one cares about).

5) Business Processes

The client must identify the business processes to automate. In doing so, one must get into the “sub-process” level. For example, “Procure-To-Pay” is a major business process; but this alone does not tell the story. When we go to the next level, it starts to have meaning.

For example, within this major process, some of the “sub-processes” include: 1) Quotation process, 2) Requisition / Approval process, 3) PO process, 4) PO Receipt process, 5) Invoice / Voucher match process, and 6) Payment process.

6) Business Process “Variants”

All too often people assume a particular “sub-process” (examples above) represent a single workflow. However, in many cases nothing could be further from the truth. A simple example is “receipt of a purchase order”. In most companies, there are many types of purchase orders that are received and transacted very differently (and for good reasons).

As a result, from a scope standpoint each may require unique analysis, system set-up, and testing to the point they should be treated as separate sub-processes (or perhaps children of a sub-process). No matter what we call them, when included they expand scope and must be recognized.

7) Degree of Business Process Redesign anticipated

It is one thing to say a business process is in-scope; but again this is only half the story. This is similar to the complexity factor, but I like to highlight it separately because it can have huge project implications.

For each business process, it begs the following questions:  How convoluted is the current business process? Does it need significant reengineering? Are you planning to implement an entirely new operating philosophy? On the other hand, are you attempting to automate a current process that is well defined and works well today?

There is no right or wrong answer here, but the more one must redesign a process, the more decisions to be made (usually the longest pole in the tent), the more design work to be done, the more emotional it gets, the more issues and unknowns, and the more testing required. There is nothing unusual about any of this, but there is no way around it. When significant process changes are needed, schedule and budget for it accordingly.

8 ) The Number and Complexity of Data Conversions

In scoping conversions, get to the level of understanding the key files in the new software (target system), where the data is coming from (source system or otherwise) and how it is going to get there (manual or automated). Also, do not forget how history records are to be addressed (if at all).

The level of effort comes into play with the following considerations: 1) Source data clean up required prior to converting, 2) The format of key fields in the existing system and the need to get the data into the format of the new software. This includes not only field sizes, etc for important data items, but also how the data is used within the business. 3) The anticipated complexity of the conversion process, program logic required and level of effort to test. 4) Keep in mind, it could be much less time consuming to load data manually versus the alternative of writing conversion programs.

9) The Number and Complexity of Interfaces

This includes interfaces between “other” systems and the new ERP system. The time and cost to design, develop, test and maintain interfaces are almost universally under-estimated. The cost issue includes design and mapping of interfaces, third-party developers or additional “middleware” required (software and hardware). From a quality standpoint, even when thoroughly tested, no interface is fail proof (expect problems at some point).

Therefore, ideally one wants to replace as many legacy systems as possible within each project phase to minimize or eliminate temporary interfaces (that exist only during the transition) and permanent interfaces (to legacy systems deemed outside the final project scope). This tends to be the case even when a few modifications to the new software are required to replace the legacy system.

Expanding the number of modules (to eliminate interfaces) is a trade-off between interface scope and additional module scope. From a user perspective, interfaces are usually assumed the path of least resistance, but often times they later find out this is not the case.

Each interface and the level of complexity should be documented in the project scope. When identifying interfaces, realize there may be more than one interface between two systems (and some going in opposite directions). Therefore, what may initially appear on the surface as a single interface may actually be two or more interfaces.

Do not forget “one-off” databases in the user area that are out-of-scope but linked with the legacy system. They may or may not be supported by the IT department, but nevertheless, can be critical to the business. Also, interfaces to other new third-party software or hardware included in scope must be acknowledged.

It can get worse. Interfaces may force customization to the target or source system to add additional fields and screens to either system (to support the data needs of the other system).

Finally, the complexity issue includes (but not limited to) the frequency of the interface, real-time or batch updates, sequencing and dependencies of data transmissions and data format issues that impact the complexity of interface program logic (similar to data conversions). The question from a user standpoint: Must the users work in both systems (instead of one today)? If so, for how long?

10) The Number of Reports

The number of reports should be estimated since the accumulation of all reports can represent a significant effort. First, get a complete list of reports (from ALL current systems to replace), the distribution list for each, and frequency of usage.

Ask the users to review the list and comment on what reports they “must have” within the new system (wrong, right or indifferent – at this point we are trying to estimate. It is OK if the revised list from the users is full of assumptions) However, this will eliminate many reports that exist today.

Next analyze the list to see if the “must have” reports can be combined, eliminate by standard reports from the new system (or with slight modifications) or the availability of data on-line (or via spreadsheet user downloads) from the new system eliminates the need to write reports. Once this is accomplished the list should be more manageable.

Finally, add a contingency of about 15% to 20% to cover new reports the team or users will eventually asked for once they figure out the additional information available in the system.

11) The Number of End-Users

Whether there are twenty end-users or a thousand end-users, the team still must do all the process and software work for implementation. However, the number of end-users impacts the number of “key users” (subset of the entire population) to be heavily involved. Of course, the more people involved, again, the greater the scope. Not a bad thing, just reality.

The number of end-users also affects the end-user training timeline and resources. During the planning phase, it is necessary to get a handle on training time and resources requirements. Think of this as a rough-cut end-user training plan (not a detail training schedule). Do not wait two months before training to start this planning.

The project team must train end-users as close to go-live as possible. Training more than three or four weeks prior to go-live is a problem since users will not retain what was learned. The more one compresses the timeline to meet this objective the more resources typically required.

This time constraint could drive the need for more trainers since some training sessions may run concurrently. It can also impact the number of facilities, equipment and other resources that otherwise could become bottlenecks. Therefore, one must consider the trainers and resources now in order to get the right people involved early on, estimate a duration for end-user training in the schedule and to properly budget for it.

12) Software Customizations or Enhancements

Most know by now software “mods” (customizations or enhancements) increase risk, time, cost, and can negatively impact software quality. Therefore, eliminating or keeping them to an absolute minimum is always recommended. However, in the real world organizations make mods and often for very good reasons. The question is: How do you handle them during the scoping and planning phase of the project?

Here is the answer. After evaluating software, when there are strong perceptions mods are required, do NOT automatically include them in the project scope unless ALL of the following apply:

A.    Software limitation is verified

Early testing / verification (immediately after the software evalution) has been performed to confirm the software limitations exposed during the evaluation.

B.    Functionality is linked to key project objectives

The proposed mod is deemed by management as critical to the success of the project.

C.  It is understood what is required and how the mod is to be made.

The mod is defined in terms of specific functionality, external design attributes(screens and logic) and how the mod will be accomplished from an internal design standpoint. Internal design means: Are we proposing outright “customizations” to existing programs and tables? Or changes through more external “enhancements” that integrate with the system while attempting to minimize the impact on existing programs and tables? (for the sake of future upgrades).

D.   The Mod is “pre-approved” for scope planning purposes only    

Management has “pre-approved” the mod with a full understanding of alternative solutions and project impact (extra time and cost). Pre-approval means the mod is recognized as “in-scope” and included in the schedule and budget, but NO coding is allowed to proceed as this point.

E.    There really are no other viable solutions

The need for the mod is tested and verified again during the prototyping phased (usually following project team training and runs currently with current process analysis). The reason is, regardless of the original perceptions, once the team learns more about the software and looks closer at different ways of doing business, a proposed mod may not be required after all.

F.  Final Approval

After prototyping, if a mod is still deemed necessary, estimates are revised and present to management for a final approval. Afterwards,  the scope, schedule and budget are revised accordingly and the modifications can now proceed.

Get a Jump Start on Modifications Discovered Early On – They are on the Critical Path

Disposition of proposed modifications discovered during the software evaluation process must occur before the “official” design phase of the project . This allows for an “early start” in programming the modifications. The balancing act to consider is while any proposed mod must be understood and justified (with due diligence), waiting too long to start coding can put the schedule at risk. Always remember, most mods are on the “critical path” within the project schedule.

Other Potential Modification Scenarios

In the situation where some mods are expected, but none are yet defined or approved, it is a good idea to build some reasonable “contingency” in the schedule for good measure(even though senior management must later approve any mod and the project schedule is revised accordingly).

When there is a “no modifications allowed” policy proclaimed by senior management, do not plan for any. If mods are later proposed, they must be approved by senior management. In this case, the decision to expand scope rest with senior management, not the project manager.

13) Boundaries (what is out-of-scope?)

For all dimensions of scope discussed above, it is always best to go back and document what is “out-of-scope”. This more clearly establishes the project boundaries. The reason is people sometimes “hear what they want to hear”, and make assumptions on their own about what “in-scope” means.

We have all been there before when the manufacturing manager says (for example): “Steve, I thought shop floor control included wireless data collection!”  Response: “Sorry Joe, that is not what we meant.”  The point is, “in-scope” states what is included, but it only implies what is not include.  Why not state the out-of-scope items up-front to avoid confusion or prevent someone from attempting to slide it in the back door later?

The problem is even though the project manager may “win” this particular scope issue, he or she may actually lose in the long run when Joe no longer supports the project. It is better to get Joe on board with the decision early on or recognize it as in-scope before we put the ball into play.


The “Scope and Boundaries” document is a key deliverable within the “scoping and planning” phase and is completed before the project schedule and budget are finalized and the project is officially launched.

The scope document is the responsibility of internal project manager, with the help and guidance of the consulting project manager. It requires the participation of the executive steering team, executive sponsor,  project team, application consultants, key managers (process owners) and some knowledgeable and influential end-users. Though many are involved and provide valuable input, scope must be managed very closely, and tough decisions are usually required by the project manager and senior management.

The final version of the scope deliverable is next presented to all the above as a last review. Depending on how formal the organization, it is  signed-off by the executive steering team. Now, as a project manager, you have something valid to serve as input into scheduling, budgeting and later controlling  the project.

Popular Searches:

  • how might the project team recommending an erp design strategy justify its recommendation as compared with other types of design strategies?

Related Posts: