Problem solve Get help with specific problems with your technologies, process and projects.

The 10 Worst Practices of SAP Development Projects

The ten biggest mistakes companies make in project deployment

Why do unsuccessful SAP projects fail? In the following excerpt from the article "Avoiding the 10 Worst Practices of SAP Development Projects," which appeared in the September/October 2001 issue of SAP Professional Journal, ClearReason's Amy Stapleton discusses the 10 most common mistakes companies make during development initiatives.

Worst Practice #1: Proceeding Without Clear Project Objectives

The worst practice (but unfortunately not an uncommon one) is to initiate the development effort without heeding the principles of good project management. Industry best practices tell us to start every project by documenting its objectives in a project proposal (or project charter), yet we all know how bothersome this effort can be. Especially in today's slowing economy, it would be unwise to begin any mid-sized or large development effort without first stabling the right foundation by understanding the basic objectives of the endeavor.

Worst Practice #2: Believing in the Existence of "As-Is" Process Definitions

One of the most common causes of failure for SAP development projects is that the IT team is forced to aim at an unclear and moving target. The current business process that the team is trying to replace, improve, or interface with was never well documented. As a result, the way the business works "now" only begins to come into focus as the development effort proceeds. The way the process is supposed to work upon project completion is even more tenuously defined. The more business processes that are being affected by the project, the more compounded the problem becomes, so the development effort inevitably stalls, waits for the picture to clear up, moves forward again, stalls, and sometimes is ultimately canceled altogether.

Worst Practice #3: Not Following a Best Practices Process

Technical managers, and especially systems analysts and programmers, tend to feel that methodologies get in their way. For a development project, the methodology may consist of a change and/or configuration management procedure, or some other process derived from industry best practices. For a full-blown software implementation, the methodology may be as all-encompassing as SAP's ASAP methodology. In either case, following these guidelines can often seem cumbersome and a waste of valuable time. For example, everyone knows how annoying it is to fill out 5 documents and get 10 signatures just to implement a small code fix.

On the other hand, when you could really use some direction, such as when you start a complex development effort, you often struggle to find a methodology that can really help. Where is the ready-made process that gives you advice on when and why you need to create a project proposal, or that tells you what the proposal needs to look like, and what steps should follow it?

Worst Practice #4: Paying for Consultants, Not Your Own People, to Get Smarter

Augmenting your in-house development staff with experienced consultants can be a good way to help your SAP project team achieve its critical project goals. And working side-by-side with more experienced individuals should, in theory, help to narrow the knowledge gap between the consultants and the staffers. But it often strikes me that the way many companies do business actually widens this gap. Practices that make consultants smarter at the expense of the home team include:

  • Giving consultants more exposure to the new systems and technologies
  • Teaching consultants, not your own people, how to leverage methodologies
  • Making it difficult for consultants to share the knowledge they already have, and the knowledge they acquire during the project

Worst Practice #5: Making It Difficult to Retain Project Knowledge

Unfortunately, organizations often do not place much emphasis on the need to retain project knowledge. Instead, they focus on successfully navigating through one project at a time, and reaping the immediate rewards of its completion. It is almost as if they view each new development effort as its own animal, with no relation to anything that preceded it. As a result, the IT organization becomes very reactive, instead of continually building the skills that could make it more resilient and proactive.

Worst Practice #6: Underestimating the Importance of Communicating with End Users

I know of at least a few high-budget development initiatives that ultimately failed because the majority of users who were expected to work with the new system rejected it. The development team had completed its work on time and within budget, but the end-user community felt broadsided when they were finally exposed to the new application. This seemingly improbable occurrence is, in fact, not at all rare, as a result of:

  • The departmental structure of many corporations
  • Lack of time on both the part of the IT team and the end users
  • Inability of IT people and end users to talk to each other effectively

Worst Practice #7: Failing to Secure and Maintain Executive Buy-In

The ultimate success of a project might be based on whether the end user is happy with the final product. However, if you fail to maintain executive support, you may never even have the opportunity to complete your project. Without executive buy-in, the project has a good chance of being canceled or deferred, regardless of how important it may be for the organization.

Worst Practice #8: Poorly Documenting and Tracking Code Modifications

Packaged software has an annoying characteristic of not always doing exactly what your business needs it to do. As a result, you sometimes have no choice but to tweak the standard software. There are many schools of though on if, when, and how SAP code should be modified, and I know it is a touchy subject with many corporations. The bottom line is that I have seen a significant number of follow-on projects fail as a direct result of code modifications that were made during prior development initiatives.

Worst Practice #9: Inability to See and Understand the Entire Project Portfolio

Most organizations have a host of SAP-related and other IT projects under way at any given point in time. Many of these projects affect the IT team directly, others indirectly, and some not at all. But the ability to effectively manage the enterprise-wide project portfolio can bring tremendous advantages. At a minimum, being able to understand how projects interrelate can save time and money, while averting potential risks.

Worst Practice #10: Not Learning from Your Mistakes

Learning from your mistakes, especially on an organizational level, is admittedly difficult. At the very least, learning from past projects requires both a time commitment and a willingness to enhance the project expertise of the project manager and key project members. In some cases, the ability to learn as an organization may actually require a reevaluation of the existing corporate culture. As an example, instead of rewarding people for tasks they have accomplished, you may need to reward team members for the quantity and quality of the knowledge they capture and make available to others.

To read more about the 10 worst practices of SAP development projects, including what Stapleton suggests companies do to avoid them, pick up the September/October 2001 issue of SAP Professional Journal, or visit SAP Professional Journal to subscribe.

Dig Deeper on SAP implementation

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.