Skip to Content

I have never attended an SAP interview in my life where I was not asked about ASAP. I have also never worked with any employer that didn’t use ASAP in some form – usually with some value added changes on top, and with a new name. Funny enough – I have also never been in a project where I and several others have wondered whether ASAP (or its variant) was the best we could have done. In the current economy, where we are all trying to innovate – I think it is high time we take a serious look at whether we can do better.

 

What is the biggest draw back of a linear, water fall type methodology? The most common answer is “Lack of flexibility”. This is true – requirements change all the time. However, good project management includes a good change management process. And I have seen it work with great success – except that occassionally it stresses out every one involved in the process. The prime reason is that end dates in a project plan gets set in stone, and we try to do “nine women have to deliver a baby in one month”, and somehow make it work. When we don’t – we end up getting a bad rap. When we do, we get all stressed out. Damned if you do, Damned if you don’t, huh?

 

Having had hundreds or even thousands of projects go through ASAP process and its pitfalls- why didn’t we change this? That means there are good things associated with ASAP and its variants. What are those?

A few that comes to top of my mind

1. Easier to estimate – PERT,CPM etc can be readily applied, critical paths found, bugets and variances calculated etc

2.  Easier to visualize end to end project ,especially as project proceeds thrugh its life cycle

3. Easier to work with geographically spread teams – Several companies have succesfully established their models based on an onsite team defining specs and remote team working on realization, in a waterfall approach.

 

So, what are our alternatives to ASAP? Some kind of agile methods – most recently scrum, have been tried out succesfully in SAP implementations. So is it time to replace ASAP with more agile methods? I would say “No..Not yet”. So did I just waste your time reading so far? hopefully not 🙂

 

Why am I saying no, then? Well, for a couple of reasons.

 

1. Agile methods have limitations too – for example, it is hard to do something like scrum, when your team is spread across three continents. As time progreeses, we might find better ways to do this. From a personal perspective – I tried scrum twice in a project that I was running from the US, with part of my team in India. First time – I had team members in USA and India. Second time – I asked one of my team leads to do it in India, without any USA team member involved. It worked both times – but the first attempt was very stressful, and I did not have stomach to go through the exact same model twice. The second attempt was a good success, but scope was smaller, and I had an experience scrum master leading it.

 

2. With restrictions in travel becoming the order of the day, it becomes more and more difficult to get people together multiple times. Most clients cannot dedicate business people full time to the project anymore. However, I have had good success in getting some part of blueprinting done involving remote teams with judicious use of technology – but again, these idas need to develop and mature much more.

 

3.The necessity to plan, budget and monitor doesn’t go away, and the tools that help us do that have been built with a waterfall approach in mind. Again, I am not saying that they cannot be adapted – just that adapting them needs time and money, and clients and consultants are both trying to minimize spends.

 

If SOA/BPM caught the fancy in a bigger fashion, ASAP might have evolved faster. There are SOA specific methodologies out there – the one I am familiar with is called SOMA (Service Oriented Modelling and Architecture). You can google or go to IBM’s website to get more information. Unfortunately, SOA did not catch on big time so far in SAP ecosystem, and hence there was no pressing need for ASAP to change or evolve. I firmly believe that once the hype dies down – SOA/BPM will catch on, and then the necessity to change ASAP will again stare us on the face.

 

Nevertheless, I suspect that clients will keep increasing their demands for faster implementations and hence we might not have much time to start adapting ASAP. I would expect that scrum and similar things will start making a stronger presence in realization and initial testing phases where the team is more localized. Eventually, the tools and methods will change to account for iterative and agile methods for parts of the project. I don’t expect the overarching waterfall model to change in big SAP projects – but as I explained above, we might soon see some phases of ASAP to change for good.

 

This is just my view – I would love to hear yours.

To report this post you need to login first.

10 Comments

You must be Logged on to comment or reply to a post.

  1. Twan van den Broek
    Hi Vijay,

    I recognize your experiences with ASAP, even in some company flavored form. I also recognize your limitations or at least the points of attention.

    Personally I believe that it is time for innovation in the ASAP methodology. Very easy, just rename the first word to Agile. 😉
    Agile SAP as the new methodology for successful implementations.

    Sure we have to look at some specific issues as the SAP world differs to the Java or .NET custom built software world. But we have to prevent that SAP consultants live on an island within the IT world. Sure customization of a module is different than coding an application. Sure the data model of SAP already exists. Sure … But does this mean that an agile approach like Scrum doesn’t fit? I don’t think so, that why we are working according to Scrum in my current project: https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/13378. [original link is broken] [original link is broken]

    It is important to realize that the SAP world is changing. The number of green field SAP implementations is decreasing. Customers are extending current implementations, improving user experience, integrating multiple source systems, … Things we didn’t do 10 years ago. So that’s already one reason why we need to innovate our way of working.
    Besides the different nature of our work, customers want to respond to business changes more rapidly than before. Another reason.

    Thinking of the required innovation it is important to consider:
    –     Facilitate in collaboration between business and IT
    –     Be agile, make sure that changes during realization can be applied
    –     Focus on top priority activities
    –     Work in iterations and show increments on a frequent basis to gain trust with the customer/endusers
    –     Use current technology to work with teams that are spread

    Let’s combine advantages and experiences of both the SAP ‘island’ and other parts of the IT world to deliver to the customer what he really needs.

    Kind regards
    Twan

    (0) 
    1. Vijay Vijayasankar Post author
      Twan – thanks for your comments.
      And I like the name change to Agile SAP 🙂

      Quick question for you – is your team using scrum all located in one place, or are they spread over the globe? As I mentioned in the blog – I had great success when I had them all at one location, but not when multiple locations were involved. I wanted to check if you had any best practices to offer for geographically spread teams. Also – the projects that I end up doing due to the group I work for in IBM, are either greenfield or have big transformation in scope. So the question is – does scrum apply equally well to very large (hundreds of people in several countries) projects? I am looking forward to hearing your experiences on this.

      I readily agree that customers are doing things now that they did not attempt in 90s. However, multiple source system integration was something I have experienced right from the time I started. One of my earliest projects had more than 200 or so source systems talking to SAP.

      Cheers
      Vijay

      (0) 
  2. Stephen Johannes
    Vijay,

    The one thing to keep in mind that the whole point with ASAP was to prevent all the failed or too costly SAP implementations that were way too common.  The whole point of ASAP was to provide a standard way of implementing SAP R/3 without costing $100 million or the implementation not working.

    ASAP in general has met these goals, but by no means is the best methodology, and there are probably other alternatives available that can work.  Perhaps after ASAP being around for at least 10+ years, it is time for next-generation revision, and by that I’m not talking about throwing in another software tool to “enhance” the methodology like solution manager.

    IMHO, without ASAP we probably would not be having this conversation about SAP software right now and SAP would have been a much smaller company.

    Take care,

    Stephen

    (0) 
    1. Vijay Vijayasankar Post author
      Good point Stephen – ASAP has been successful in getting us to this point. But just as model T cars once served a purpose, but had to make way for better models – it is probably time for some innovation to come to make it ready for current projects. I wonder whether it will come from SAP themselves or from the partners like SIs?
      (0) 
      1. Krishnakumar Ramamoorthy
        Thanks for bringing this topic up. The short comings of ASAP are well realized and SIs (including the one I work for) have their own frameworks as you have highlighted. Will the SIs be willing to share this with everyone? I am not sure, because we are probably dealing with intellectual property here 🙂
        KK
        (0) 
  3. Bhavesh Kantilal
    Vijay,

    I am not a big fan of the Waterfall model for the exact reasons you summed in the inital discussion in your blog. Too many requirements changes, and a fixed milestone lead to one common issue – Customer’s order a 4 legged table and we (read SAP Consultants )deliver a 3 legged one.
    I definitely think your question is valid and hopefully there is a better way to do it.
    SAP is focusing on RUN SAP for Support models, maybe time to pull out something for implementation one’s as well.

    Regards
    Bhavesh

    (0) 
  4. Witalij Rudnicki
    …and I am surprised there are so few comments so far.

    My major issues with ASAP are:
    – Trying to apply ASAP to BW projects. ASAP is not really for ALL products from SAP, although mentions BW in couple of places. But the truth is that *ASAP does not provide complete methodology for BW projects* and *There are very few accelerators ASAP accelerators (templates) for BW* and *Most of accelerators are outdated*
    – Project Managers like ASAP (or waterfall) because it is … simple. It is much easier to blame delivery people for “not capturing proper and complete requirements right from the beginning”, then for PMs to have “agile future” where all you can say about estimation of resource effort and budget is “it depends” 😉

    Have you tried to use ASAP for BW projects?

    Thanks,
    -Vitaliy

    (0) 
    1. Vijay Vijayasankar Post author
      Good point on BW – in our projects, we have a tailored BW methodology – and I believe other SIs might have one too.

      And since I wear PM and BW hats interchangeably – I feel like kicking myself. As a PM, I am forced to do things that I hate when I am a BW gy reporting to another PM 🙂

      (0) 

Leave a Reply