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 endeavour.
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 cancelled altogether.
Worst Practice #3: Not Following a Best Practices Process
Technical managers, and especially Basis & BI Developers, 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 SAP 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 cancelled 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 thought 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 revaluation 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.
Comments
Post a Comment