Skip to Content

What happens if you don’t follow the ASAP methodology in a SAP implementation?

What happens if you don’t follow the ASAP methodology in a SAP implementation?

“There is no worse blind man as that who will not want to see”

— Mexican folk saying —

I always say to my clients: — If you follow the methodology, maybe you can have a successful project…, but if you don’t follow it, the disaster is guaranteed –.

Once upon a time I was very close on a project, — not mine –, where precisely this happens, the orthodoxy is not followed in a SAP implementation. I want to share this experience with you and I hope that will be useful and please “don’t try this at home” is an a very bad idea — Don’t pretend to invent what already has been invented and just follow the recipe –.

Well, in matter, in my experience, I learned that the SAP implementations are very different to others IT projects and as you know, SAP has it own methodology: ASAP or Accelerated SAP. This methodology is not a bundle of task with no sense, this methodology is the accumulated knowledge of many years of experience of many experts in IT and SAP, as well in successful and failed projects. In this methodology each task depends on other tasks and each task have an special purpose, a reason and a time, but obviously, you need to adapt this methodology for your own project, in the understanding or that not means that you must cut activities, skip them or doing this tasks in either order.

The main facts in the project. SAP FI implementation. Planned for ending in 9 months:

  • The CEO had not commitment, he gave the responsibility to the IT Direction.
  • The CEO don’t gave the empowerment to the leader of k-users.
  • The IT Director took the management of the project and their decisions were above on the experts or users who truly knows the business.
  • The IT Director don’t know nothing about SAP.
  • The IT Director don’t know about of the business process. — But he believe that he knows –.
  • The IT Director micro-management stopping the business process definitions.
  • The IT Director instructs at the team to do developments and configurations with no documentation to “save time” (No architecture, No Functional and Technical Especs, etc.).
  • The IT Director instructs at the development team to do short cycles and then testings in a pseudo AGILE/SCRUM approach, with a team not trained in it.
  • The IT Director instructs at the team to do Integrated Testing with very poor or null Unit Testing.
  • The IT Director believed blindly in the reported progress by the leader of the Consulting House that he hired for the implementation.
  • There was no scope agreements.
  • There was no closure acceptance letters of phase and carry on to next phase with no closure of the previous.
  • Were not made detailed plans of activities and milestones. The plans were displayed in a dozen of big activities and as lines of global time without sequence or clear dependencies.
  • There wasn’t a project organization chart.
  • There wasn’t risk and issue management, all became in problems.
  • There was no defect management.
  • There was not a strategy of environments or servers, the programming was transferred by hand and re-configuring at the same way.
  • They didn’t use Solution Manager. Only installed because so stipulated in the service contract provider.

    … and many others facts I would take long to spell.

The results at 5 weeks before the Go Live:

  • They began to take desperate actions and many more Bad Practices, such as modifying the standard SAP code and other things, to try to get out in time, but only to make the things more worse.
  • The IT Director recognize too late that something is wrong with the project, but they still blinded and with confident that the company that he hired will resolve the problem, because he didn’t really knows the serious of the situation.
  • The IT Director hides the true status with the CEO.
  • More than 230 defects found with only 20% of the Test Cases performed and only the 60% of the defects solved, for a total over 400 Test Cases. What a fear!.
  • There wasn’t a Cut Over Plan.
  • The team began to feel fear and doubts, their bosses never explain nothing, all is chaos and confusion, the disaster….

The end of the project:

Well, I lost the end, I had to attend other things, but is really easy to guess how it will be or how it ended.

I appreciate any comments that you will want to make…

You must be Logged on to comment or reply to a post.
  • I am a big supporter of ASAP. I always have been. Too many projects CLAIM to be following ASAP when, in fact, they're mostly just flying by the seat of their pants and doing what they've done before.

    In this case, however, the failure wasn't so much of not following ASAP, but rather not following any implementation methodology whatsoever. There are many implementation strategies which can be successful for implementing SAP projects. ASAP is a good one. Many of the large implementation firms have their own flavor of ASAP, but even following a completely vanilla Project Management Institute methodology, or SCRUM, or AGILE plan would have been vastly more successful than what you described.

    I do want to thank you for sharing your friend's experience. It does illustrate several common faults that can be seen to varying degrees on many large IT projects, but SAP projects in particular. The reverse of what you observed could be codified as Best Practice:

    • Support and active participation of top management is essential to success
    • Education of the team is critical to prevent them from blindly following the implementor without the ability to sanity check. This includes training in implementation technology and training on the product being implemented.
    • Proper project management practices are key (ASAP, PMI, or others)
      • Documentation
      • Scope and requirement definition
      • Testing
      • Risk, issue, and defect management
      • Use tools (Solution Manager or others) to facilitate all of the above
      • etc
    • And for SAP projects: only modify in extreme cases. Most companies can get by with only Configuration and Enhancement (via BADIs/BAPIs/User Exits).

    Thank you for sharing your friend's experiences. It definitely serves as an valuable object lesson for others hoping to implement SAP smoothly.

    Best regards,


    • Hi Tom, really, I appreciate your comments. I am totally agree with you. I want to share this experience, mostly, with younger Project Managers, because when we are inexperienced usually we make foolish practices and experiments to find shortcuts that don't bring you to anywhere, only to let the things to much worse.

      Of course, eventually, we need to innovate and try new formulas, but before that, first, we must to learn well what already exists and already is know.