Skip to Content

By design we all know that SAP projects follow the standard ASAP methodology, be it a full fledged green field implementation or buliding of a specific enhancement or an upgrade or multi country rollout etc. By average the duration of a medium sized SAP project will vary from six months to 12 months, while multi country roll-out can go upto 2 to 3 years also. So by design SAP projects tend to be lengthy affairs in an ever changing business environment

In all these projects the generic principle is to start with Requirements gathering (BBP), then Freeze the scope. Then follow-up with detailed design, unit testing, intergration testing, user acceptance testing, finally Go-Live and then end with Post Go-Live support and transition to normal maintance of the new system. Experience clearly shows that due to the fairly longer duration of the SAP projects there are inherent weak-links like

1. Scope being frozen so early in the project. If you analyse any SAP projects that seemed to have been not successful, invariably the scope was found to be in-complete or not defined properly or at the worst case a serious mis-understanding between customer team and solution provider team on scope definition itself. Another variation of the scope issue is the underlying business case for the scope itself has changed by the time the solution is realized, so the scope has become obsolete and hence the project itself. 

2. An in-built lack of participation between customer teams and solution provider team during the phase of execution (Design, development & unit test phases) creates a divide, too difficult bridge.

3. The team members becoming mechanical executors of pre-determined activities.

4. Even if customer sign-offs are received through-out the project cycle, it still will not prevent the project being considered a failure if the customer team doesn’t exactly taste & cherish the value brought by the new system or enhancement. So the success of the project becomes notional.

It is these weaklinks that is specifically targetted by the Agile project management methodology as you can see from the Agile manifesto itself

http://agilemanifesto.org/

As you can see the agile manifesto clearly seems to have an answer to the issues I have identified earlier. It talks about individuals there-by fostering creativity, stresses on working software even if it doesn’t cover the whole scope in a single iteration, elicits customer colloboration right through the project there-by enables responding to changes then and there, hence eliminates the chance of scope becoming obsolete.

The whole stress of Agile Project Management methodology is very high colloboration between customer and solution delivery team throughout the project, ever readiness to change and achieve the end product through multiple iterations.

While Agile seems to be valuable, In a follow-up blog I will try to evaluate on the type of SAP projects in which Agile methodology is a good fit.

To report this post you need to login first.

3 Comments

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

  1. Michelle Crapo
    Here are the Twelve Principles of Agile Software
    and my comments:

    1.  “Our highest priority is to satisfy the customer through early and continuous delivery
    of valuable software.”  – YES!  I love that one.  Early and continuous delivery.  That’s basically what happens.

    2. “Welcome changing requirements, even late in
    development. Agile processes harness change for
    the customer’s competitive advantage.”  OK – that has the potential to extend the life of the project.  If I’m working with a fixed bid as a customer I love this.  – Consulting firm hates this.  If I’m working on time and materials, I may run out of budget.  – Consulting firm loves this as it means more revenue.

    3.  “Deliver working software frequently, from a
    couple of weeks to a couple of months, with a
    preference to the shorter timescale.”  – YES!  This would be awesome.  Not only as a customer testing, but as someone who code reviews, and asks for changes.

    4. “Business people and developers must work
    together daily throughout the project.”  This may not be possible.  Our business people have a “real” job too.  It’s hard enough getting feedback periodically.

    5. “Build projects around motivated individuals.
    Give them the environment and support they need,
    and trust them to get the job done.” – OK!  I love this from the standpoint of buy in.   Developing change management training etc.  BUT what if this isn’t a welcome change.  We still need our business input, but they may not be motivated.  And again they have their “real” jobs.

    6. “The most efficient and effective method of
    conveying information to and within a development team is face-to-face conversation.”  Totally agree.  It doesn’t work with off-shore models.  We are using them more and more based upon price.  The off-shore model is getting better and easier to use.  Also some of our consultants are working from home.

    7.  “Working software is the primary measure of progress. ”  – Maybe?  Sometimes it is simply a document.  A requirements document, a testing document.  In pharmaceuticals you would be surprised at the documentation required.

    8. “Agile processes promote sustainable development. The sponsors, developers, and users should be able  to maintain a constant pace indefinitely.” – Oh!  Does that mean no crunch time?  We don’t have to work 12 hours or more at the end of the project?  I love it.  But so far it hadn’t happened.

    9.  “Continuous attention to technical excellence and good design enhances agility.” – Yes couldn’t agree more.

    10. “Simplicity–the art of maximizing the amount of work not done–is essential.”  – Agreed.  Use what is available standard when possible

    11.  “The best architectures, requirements, and designs emerge from self-organizing teams.”  -Self-organizing teams.  The team determines who does what, when, how…  I’m not sure that would work.  We have a lot of rules on who does what.  Sad but true.

    12. “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” -I would agree.

    No summary time:  I think that this is an effective approach.  I also think we would need to take a hybrid approach in our environment.

    Nice thing to think about in the morning!

    Michelle

    (0) 
    1. Ramesh Babu Nagarajan Post author
      Thanks Michelle for such detailed comment.

      As you have pointed out at the outset Agile project management process does have lot of impractical approaches like full-fledged participation from client team which is indeed difficult to achieve etc.

      So the goal is to go for a hybrid approach as you have pointed out. Identify parts of the project deliverables which can go through the normal project management way and parts that are ideal candidates for Agile process. To me the high priority and highly visible functionalities that make or break project are the ones for Agile approach.

      (0) 

Leave a Reply