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.
