Skip to Content

With a lot of stress on Agile Methodology in Project Management doing the round these days, let us see how this can be of help in Managing fixed cost SAP SCM Implementation Projects.

Definition: Agile software development is a group of software development methods in which solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change (definition from Wikipedia). Below it illustrates how Agile Methodology works while collaborating with customers.

Pretext: A couple of years back while executing a project, the project already went behind schedule by one and a half month in the initial phase itself, i.e Project preparation phase whose main tangible outcome is As-Is document and user requirement specification. To put things in perspective, for a fixed cost project with a planned delivery time of 11 months, It took three and a half month to complete the As-Is against the planned two months. The challenge in front of PMO (Project Management Office) which includes both the implementation partner and the customer was how to meet the Go- live deadline without squeezing phases of the project where business core team and users participate. That roughly translates to shortening the blue print and realization phase of the project.

Challenge: One of the major requirement from URS (User Requirement Specification) was to have a custom Life Cycle Planning tool which should be intuitive and lot of user interaction enabled with some amount of intelligence built in. Obviously those requirements could not have been met by standard Life Cycle Planning tool in SAP APO. The estimated ABAP effort including unit testing for ABAP object was about 120-130 man hours and that nearly consumes major share of budgeted and available hours for ABAP meant for realization phase on account of delay in As-Is phase. Along with this there was one more major enhancement identified as a part of blue print along with a few reports. Planned Integration Testing (IT-1) by the core team was for 6 weeks. Meaning incorporating major changes / bug fixes identified during Integration Testing would obviate any chance of sticking to the planned go-live date.

Project as well as high level solution Approach: Customer was sensitized with shortened delivery phase and risk in terms of identifying major issues once project gets into Integration Testing Phase. System Integrator’s proposal to get business core team’s engagement during the realization / build phase itself was accepted by the customer, particularly for those major enhancements. As like any other major task, we adopted a divide and rule approach here too. Meaning, on completion of every sub module of the enhancement after testing from our side (Integrator’s side) we asked core team to go through and and perform testing what was completed until then. For SCM-APO-DP enthusiasts the approach followed to design this life cycle planning tool was to upload an excel sheet to update a custom table with Phase-in / phase out values in percentages with a number of validations followed by writing the values in live cache. A macro too was used to make the solution complete and fool proof. A separate post, as it deserves, exclusively dealing with design details of this custom life cycle planning module will be taken up in due course. To cut the long story short, end result was by the end of realization phase core team (the team which is supposed to do Integration Testing) was quite comfortable with those enhancements.

During Integration Testing it emerged out that a development that needed 150-160 hours of development (including thorough unit testing) was tested with zero major issues.

In another project we applied Agile methodology in a completely different context, this time for SNP though (basically a planned order download / upload program in ECC which gives production planners ability to reconcile SNP optimizer results involving a number of validations). This example is brought out to drive home the point that Agile methodology equally qualifies for ABAP developments which is slightly complex in nature too [involving integration between multiple systems (ECC & SCM)].

Interesting thing is While implementing this methodology we actually were not aware there was a name to it. Only motivation to adopt this methodology was constraint in terms of time and complexity associated with those developments.

Now for seasoned Agile methodology practitioners, there can be many debates whether what was done in above two cases were really ‘Agile’ or not. Because in one case there was a design Specification functional spec) available including all the validations to be done where as in other case design was not clear at all when the ABAP development was started off. So in case – 1 when ‘Agile’ was used an iterative test approach to mitigate the risk in terms of time constraint, for the second case the very design itself emerged out of iterative approach.


Lessons learnt

Advantages:Of the many a couple we realized are mentioned below.


1) Since onsite-offshore model was followed in both the projects another advantage of ‘Agile Methodology’ came into fore in giving customer with visibility of    progress made in coding at regular intervals which typically takes place in offshore.

2) Mitigating the time challenge.

3) Applied where clarity of design was not there during beginning of the build.

Disadvantages:

1) People involved in development may be worn out because of the sheer number of iterations involved.

2) There may be a tendency to include more requirements in the scope as we progress during the development phase.

To report this post you need to login first.

1 Comment

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

Leave a Reply