IT Project Management | SAP ROI -- Enterprise Architecture & Business Solutions

Where Does Agile Fit in SAP Projects?

November 12th, 2012 by Bill Wood

Agile SAP Success

After offering insight based on my personal experiences around “Agile Project Methods for SAP ERP Projects?” I thought it would be helpful to highlight a couple of areas where Agile does work.

Development efforts (i.e. coding)
Data conversions

Once you begin to move very far beyond these two areas you quickly encounter dependent work streams that need much more coordination. Those additional dependencies make it difficult to apply Agile methods beyond development and data conversions.

While Agile tends to emphasize the 1 week to 1 month “sprint,” I would define a “sprint” in more of a completed requirements and planning package rather than a pure time-box approach.

Applying Agile Methods to ABAP Software Development and SAP Data Conversions

Development (ABAP, Java, or other coding)

Since Agile methods have been used for some time with small, discrete components of software development I won’t spend a lot of time there. On a typical SAP project you will end up with a functional spec which defines the program requirements and a technical spec which informs the development details. Even though the more typical “Agile Manifesto” method would not require the documentation it is well-placed on an SAP project. In fact, it is foolish not to have it for long term support and maintenance.

Development can work well for the Agile stages of build / prototype, demonstrate, gather feedback, adjust, and repeat. The key here is to limit the number of these “Agile” cycles to no more than 3 for software development. By 3 cycles I mean 3 completed cycles too. This is not a demonstration with feedback that is only partially built. If the feedback cycle is not completely implemented then it is not a complete cycle. Even though Agile would consider these “sprints,” I would consider them a FAILED sprint if the requirements of the current plan, or the subsequent plans, are not fully realized in the prototype or demonstration.

SAP Data Conversions using Agile Sprints

With data conversions I suggest at least 3 complete cycles or “sprints” (not including a minimum of 1 mock go-live conversion, probably 2 or more if you can).

Build the initial conversion program to all of the requirements (again, partial requirements do not count as a full cycle).
Pilot a test conversion with all data, no matter how much fails, and capture all necessary changes. This will include data dependencies and sequencing. At this point you will be lucky to achieve a 70% success rate when considering all of the data dependencies. This step is not about getting things perfect but about identifying data and programming issues to resolve.
Implement all SAP data conversion changes the conversion pilot exposes, script every conversion step and rough timings, and aim for a successful test target of at least 90%.
Make additional changes and attempt to follow the scripted conversion, making adjustments to the conversion script where necessary, and achieve a goal of at least 98% conversion completeness and accuracy.

Once you achieve this level of conversion consistency it is ready for a mock-conversion. These Agile “sprints,” or as they are starting to call them now “Scrum-ban” (as a spinoff of Kanban) will help to ensure a successful data conversion.

Conclusion on Agile ABAP Development and Data Conversions

Even with newly packaged Scrum, Agile, or other methods, on an SAP project there are so many moving parts and work streams to coordinate that there is no substitute for a good waterfall project approach. Using “Agile-like” methods for the ABAP development or data conversions is not a substitute for good project management either. Done properly this approach can work well as long as it is carefully managed along with the rest of the work streams.

Agile Project Methods for SAP ERP Projects?

October 29th, 2012 by Bill Wood

SAP Project Guidance

Looking at the “Agile Manifesto” and how Agile methods are applied generally involves small, discrete, “digestible” work and task components.

Trying to juggle the number and complexity of dependencies on a full scale SAP ERP project involves management and coordination efforts which completely go against the idea of Agile methods.

======

ERP projects tend to have too many moving parts for Agile–, there are too many dependencies and Agile provides too little control and coordination. The level of coordination required for a large business package implementation flies in the face of “Agile” methods and techniques. For example, you have to coordinate:

process configuration teams,
custom code development teams,
data conversion,
change management,
training,
testing,
governance,
infrastructure, etc.

On complex projects like this all those “sprints” that are not carefully coordinated and planned (which goes against the “Agile Manifesto” listed below) become completely disjointed disasters. There are too many work streams with dependencies that can not be going in “their own direction” regardless of the impact to other work streams.

Agile Manifesto Activities

The following chart, from the Agile Manifesto, illustrates serious trouble spots for ERP projects like SAP.

Valued	DE-Valued
Individuals and interactions	Processes and tools
Working software	Comprehensive documentation
Customer collaboration	Contract negotiation
Responding to change	Following a plan

Notice, 3 out of 4 of those items on the RIGHT side are often precursors to ERP implementation failures according to the academic literature. Numerous case studies prove Agile “De-Valued” areas are the places ERP projects fail. For example:

Failure to follow good processes and have solid tools.
Failing to have adequate documentation (training materials, help, etc.)
NOT following a well laid out plan (i.e. SAP’s PROVEN ASAP implementation methodology, including sample project plans, templates, etc.).

The only Agile Manifesto item that might have strong need to be followed in the ERP space is the focus on the customer over the system integrator contract.

All of those Competing Stakeholders and Constituents

Not only are the project related dependencies and work streams significant, there are numerous competing constituencies which must also be coordinated:

business stakeholders or organization,
IT,
external business customers,
external vendors,
system integrators (when you use consulting companies),
internal business senior management,
business department heads who don’t always agree with each other, etc.

While Agile methods might work well for small, discrete, component areas of an SAP or other ERP project the academic literature proves it is a disaster for ERP implementations.

Agile is not a waste of time, it must just be understood and used in the PROPER CONTEXT of an overall SAP project. Even the ASAP Methodology includes an “Agile” overlay. This is an overlay of the existing ASAP Methodology–, it does not replace more traditional waterfall methods and does NOT adopt the “de-vauled” Agile Manifesto areas.

Does Agile Have a Place in ERP Projects?

It might.

Agile is not suitable for projects with multiple, overlapping / parallel activities with dependencies between them. The parallel and overlapping dependencies create a requirement that is more suitable to traditional project management methods with:

full project plans,
discretely defined tasks and responsibilities (to avoid “border wars” at transition points),
clearly defined deliverables,
management of parallel work-streams and parallel critical paths, etc.

Applying Agile principles to an overall SAP project creates a high likelihood of blown timelines, blown budgets, and collapsed scope — delivery suffers while stress balloons.

Agile in SAP ERP Project Examples

I know about the struggles, stresses and messes of Agile SAP projects. I’ve been on three of these types of projects and none of them went well.

On one SAP project they tried to manage it with “Agile” and it was a complete mess –, the coordination and responsibility struggles forced a change to the more traditional waterfall approach. Using Agile methods the project had an unsustainable burn rate for the budget, dates were ALWAYS slipping, inter-team coordination and planning were a complete disaster, and before the mid-course correction this project was not going to go live.

Worse still because of the “Agile” methods of only planning small, discrete work components just before they are due, each dependent group tried to minimize their own work and risk by dumping many of their traditional responsibilities and tasks onto any other group. With Agile they were allowed to “self define” much of their own effort and naturally tried to minimize their effort while maximizing their success (at the expense of other project participants and work streams).

I do NOT place this responsibility on the clients who hire outside help, they obviously recognized a capability gap or a need they are willing to pay for. I hold the outside project managers responsible for this and if you ever encounter one of these snake oil salesmen then you should FIRE THEM!

My Conclusion on SAP and Agile Deployments?

Wide application of Agile is a disaster on any major SAP, ERP, or business software implementation project. I can absolutely guarantee you that any Agile SAP project delivery “success” claim violated the Agile Manifesto to get there. There are too many moving parts and too many constituents to use pure Agile on a full blown SAP project.

Why Use the SAP ASAP Methodology?

January 16th, 2012 by Bill Wood

ASAP Methodology Background

In the mid 1990’s SAP had gained a significant amount of bad press and publicity around several high profile project disasters that the company knew were completely avoidable. At that time Oracle, Baan, JD Edwards, and PeopleSoft all had sales people making the case that SAP was too expensive, too complicated, and took too long to implement. In response SAP released the ASAP Methodology in the mid-late 90’s (around 1996 or 1997) because of the number of SAP projects that were going over time, over budget, and were at risk. It has been refined, polished, enhanced, and adjusted with SAP’s supported R&D resources and efforts for about 15 years now.

The ASAP implementation methodology has leveraged the PMI (Project Management Institute) best practices around project delivery and the Carnegie Mellon CMMI (Competency Maturity Management Integration) approach for maturing the delivery process. The ASAP methodology also includes a number of ITIL (Information Technology Infrastructure Library) components in the Phase 6 Run and the ValueSAP portions of the methodology. Agile techniques are an option which can be “turned on” if you like.

The toolset includes an implementation “Roadmap” which is a WBS based project template. It has full explanations, templates, tools, resources, checklists, etc. Together with that the original version also included an MS Access, and then an MS SQL Database application for selecting your solution options which would then generate a list of processes, transactions codes, template BPPs, and a full SAP centered Blueprint document, etc.

Today all of that functionality is still available but it is housed in Solution Manager. The ASAP Roadmap is just ONE component of the entire ASAP Methodology. The Roadmap is focused on effective Program or Project Management for accelerated project delivery with high quality results.

My Experiences with the SAP ASAP Methodology

I was originally certified in the ASAP Methodology in 1998 while at Grant Thornton. In that time I have had the privilege of using ASAP on several projects and as the project manager on a few. One consistent result of using the methodology is that projects are delivered and they are usually delivered on time and on budget (although not always).

Every major SAP system integrator claims some methodology and nearly all of them are similar to, or variations of the SAP ASAP Methodology.

I have only ever seen significant problems with ASAP when a system integrator started to use the methodology and then abandoned it part way through the project. At one recent client I used it as the framework to support a LEAN implementation methodology. That LEAN methodology has served as an ongoing framework to significantly accelerate numerous rollouts at probably 25% of the normal implementation cost of other SAP projects. This was driven by the client project manager and facilitated by using the ASAP tools.

Starting with the ASAP Methodology

Even before the first consultant comes on board the ASAP methodology provides templates and resources to cover key project and program management areas such as

communication planning
decision making
risk management
project management master planning
resource planning
steering committee tools
external links to best practice resources for reference (PMI, ITIL, Internal SAP, etc., etc., etc.).

Why ASAP Instead of a System Integrator Methodology?

First, I have nothing against the system integrator methodologies and some are very good with great resources. Unfortunately my experience has been while they have them, and may start with them, they rarely stick to them throughout the project. Since it is their methodology you have little or no insight to cross-check or validate their methodology use. With ASAP it is yours to use as an SAP customer and you have full insight into it and control over its use.

One of the primary reasons for using the SAP ASAP Methodology is like all things SAP there has been a mountain of R&D spend, development, adjustment, and support. Every SAP client (large or small) who uses the ASAP methodology can avoid the “proprietary methodology lock-in” which the system integrators will walk out the door with. Another important reason is you own it as part of the standard Solution Manager offering.

As you probably know Solution Manager is already a required part of your SAP landscape. The SAP Solution Manager portion of the ASAP Methodology can house key items related to scope, configuration, documentation, the implementation roadmap, and all of the key deliverables. As the system integrator rolls off the project you have a centralized repository which is SAP specific for any future employees, support, upgrades, etc. You do NOT get that with a “custom” system integrator methodology which is probably based significantly on SAP’s ASAP Roadmap to begin with. Using an SI methodology you will NOT get the full configuration and development scope monitoring tools which Solution Manager contains either.

The entire ASAP Methodology is part of your application licensing and support you pay for. Why not at least take it for a test drive and see what it can do.

For more information on the SAP ASAP Methodology for SAP customers use your SAP OSS ID and log onto http://service.sap.com/asap .

SAP ROI — Enterprise Architecture & Business Solutions

Where Does Agile Fit in SAP Projects?

Applying Agile Methods to ABAP Software Development and SAP Data Conversions

Development (ABAP, Java, or other coding)

SAP Data Conversions using Agile Sprints

Conclusion on Agile ABAP Development and Data Conversions

Popular Searches:

Related Posts:

Agile Project Methods for SAP ERP Projects?

Agile Manifesto Activities

All of those Competing Stakeholders and Constituents

Does Agile Have a Place in ERP Projects?

Agile in SAP ERP Project Examples

My Conclusion on SAP and Agile Deployments?

Popular Searches:

Related Posts:

Why Use the SAP ASAP Methodology?

ASAP Methodology Background

My Experiences with the SAP ASAP Methodology

Starting with the ASAP Methodology

Why ASAP Instead of a System Integrator Methodology?

Popular Searches:

Related Posts: