7 deadliest mistakes to be avoided by every SAP consultant

Losing sanity is very easy when you don’t have right attitude and experienced team involved during the initial phase of project & client interaction.

Pre-sales team care about converting RFP to a project & signing off the SOW. And if technical team isn’t kept well informed during this phase, it is obvious that you are going sweat a lot while doing the development. You may end up saying you cannot implement something and need a CR because of tight schedule or even worse, client scrapping the project entirely & for you, it is the loss of credibility!

With countless SAP products, SP release & patches it is getting more and more complex to design a system architecture. However, it is not a rocket science either. In my ~5 years of SAP experience I have understood that all you need a carefully crafted design strategy supported well by proper requirement gathering and blueprinting. This process is quiet a mechanical once you know the variables involved. For e.g. Listing down the system involved, designing the architecture, referring to PAM to get more insights so that you avoid development troubles and choose correct versions etc.

Now, taking this further & from my experience with architecture design & RFPs, I want to list out some of the mistakes that you cannot afford to commit. I hope this helps you when you head start a new project.

Get out of the spoon feeding habit -

Image Courtesy Flickr

This one is annoying! Yes, seriously. Do not rely totally on others to help you always. If you are working on a new technology, then take some initial pains to explore and research of your own. Get a clear picture of what you are going to work on & most important this will help you achieve quality deliverable.

How foolish could it be to rely on SDN for taking decisions and even telling client that we have put a thread on SDN for our query.  No doubt SDN is a great place but you cannot use it especially when you have to take business decision. If you are stuck with compatibility and want to confirm before you start the development, use Product Availability Matrix which you can get from  Service Marketplace. Why not to take some effort to get the required PAM and get your doubts clarified?

If you call yourself a consultant, this habit is not going to serve you any longer. Get out of this! (A worth read here: 7 habits of successful SAP Consultants)

Have you understood it? -

Image Courtesy SixRevisions

This is the most important phase for any project irrespective of the technology. The team that is going to be involved in requirement gathering should be well read & should rely more on sensibility & logic rather than pure technical knowledge. If there are any gaps in your understanding of the requirement, get it clarified upfront. Go to client and ask again. Why to  say we cannot go to client and ask these questions?

You have to remember here that developers are the people who are actually going to work and deliver based on whatever data is gathered during requirement and blueprinting phase. If you miss the mark here, it is obvious that development team is not going to enjoy working with you & neither the client because this might increase the probability of a new change requests & in turn increased cost!

It is really absurd so see that we raise a CR but hesitate to clarify doubts that can save some money for client.

Don’t take decisions by brute force -

To certain extent, developing a small application is required to confirm functionality & possibilities. But this does not mean you should start doing this for every doubt raised by client. Seriosuly! what is the point? Rather get experienced people on boarded onto your project and save the cost of overhead developments.

Business impacting decisions like – Deciding what version of Portal to us or, what SP level to upgrade should never be left on demo application development. And if at all you have to develop such trial applications, there has to be a limit to this.

Don’t commit too early -

Image Courtesy moon-town

You are working on MDM Webdynpro Configurator & client has a requirement to have download to excel functionality. What would you say? Yes! We can implement that without checking that SAP has only provided download to XML feature out-of-the-box. Now you are in fix!

Even if you have implemented this functionality in WDJ applications umpteen number of times, seldom commit right away. Make sure you understand implications and possibilities before you commit anything. In this case SAP has put some restrictions on implementing custom code in MDM WDC components. You have to take a way around and capture event using external button and then use XSLT transform to achieve it. However, it will certainly consume more time.

Fix a sensible schedule -

Even if you’ve to develop a trial application, keep some breathing space just in case you stuck somewhere. Don’t be pushy here. There is only possibility that you will be pushing timeline here is if you have left a major decision on success of this application and its feasibility to satisfy the requirement. So if you have avoided mistake no. 3, you will never commit this mistake. Isn’t it cool

Don’t be impatient -

Image Courtesy Designyoutrust

Say for example. you have three ways to get the data from back-end. First is RFC model, second is a web service and third is APIs. You are comfortable with Adaptive RFC models and start development by importing a model in NWDS. Now, suddenly it dawns onto you that you are not sure if you can implement certain functionality by RFC models. So give it up and spend time in creating web service and even you can execute it from WDJ application. But again, you came to know that working with web services is tricky and hampers performance heavily. You give it up again and start think to achieve the functionality using third way. Never do this! Have some patience and find a workable solution with whatever approach you have selected. I am sure if you’ve avoided mistake no. 2, you will always select best possible way. And if you have avoided mistake no. 5, you will never have to switch between different approaches rapidly.

You too deserve to say NO -

Yes, so what you are a service provider? You have a right to say that it is not possible to provide some functionality in existing framework. Saying Yes might get you a project, but saying No to something upfront will surely save you from development pressure, client dissatisfaction & loss of credibility. Obviously, as you should not commit on the spot, similarly, you shouldn’t also deny on the spot. Take some time to understand the feasibility and then come up with answer with valid proofs.

I am sure if you avoid these mistakes, everybody – your client, development team including management will be happy. You will deliver a quality product & certainly be looked upon as a visionary consultant for any organization.