Business Solutions with SAP

Where Does Agile Fit in SAP Projects?

November 12th, 2012 by
Agile on SAP projects

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.

  • Design sessions
  • Development efforts (i.e. coding)
  • Data conversions

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

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). 

  1. Build the initial conversion program to all of the requirements (again, partial requirements do not count as a full cycle).
  2. 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.
  3. 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%.
  4. 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.

Agile Design

Agile processes or sprints, are effective for design sessions.  Done correctly, this allows a customer to be exposed to the system earlier, provide better insights and results, and generally improve overall solution fit.  

One of the major differences with Agile Design vs. the traditional SAP Blueprint is the timeline.  An Agile Design approach requires more time because there is an element of system setup and solution discovery.  In the traditional Blueprint approach, everything is done on paper and many details are often missed.

When you combine an Agile Design approach with Lean principles, you can see overall project benefits in quality, cost, and overall solution stability at go live.  What this means is that during the design you are actually doing small “sprint” type activities to build out key areas of the solution.  Design sessions become playback and adjustment.  One key consideration with this approach is that you will not have 100% of the integration areas, or solution areas completely set up and defined.  This is important to understand.  If a customer expects to see perfection during Agile Design then a more structured waterfall approach, with a formal paper Blueprint would be required before any system solution activities are performed.

Conclusion on Agile in SAP or other ERP Projects

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.

The Agile approach that works for an SAP deployment is one with a mix of both Agile for discrete task areas combined with a waterfall overlay.

Popular Searches:

  • erp prototype

Related Posts:

SAP Project Implementation Strategies and Approaches

October 25th, 2010 by

SAP project successFor a brief intermission before I make the final posts on managing the shared responsibilities for SAP project success I thought I would offer this explanation of the different strategies and approaches for an SAP project.

 There are three key dimensions to an implementation strategy–, they are: 1) the vendor type; 2) the methodology-tools-templates-resources for a project, and; 3) the implementation approach.  The decisions you make around these three areas generally make up the implementation strategy for your SAP project.

SAP Implementation Methodology

For the methodology approach I will assume you are using the SAP ASAP methodology.  As a result other than mentioning it here I won’t spend a lot of time on this one.  With only a few exceptions, nearly every SAP system integrator claims they follow the SAP ASAP methodology.  As an ASAP certified consultant since the late 90’s I can assure you that few SAP system integrator project managers actually follow much of the ASAP methodology no matter what claims they make during the sales cycle.

The SAP ASAP methodology will help to ensure you are doing the right things in the right way

I’ve written on the ASAP methodology in A New SAP Implementation Methodology and Implementation Steps and for more background on the different vendor or project approaches see Breakthrough Project Success: 2 of 4, IT Vendor Proposal RFP .  And let’s put this in context, the SAP ASAP methodology has been used literally tens of thousands of times.  It is tested, proven, and it plain works!

The SAP ASAP Methodology is tested, proven, and it plain works!

As a parting note I would strongly encourage any SAP customer to get their own copy of the ASAP methodology.  No matter what stage of your SAP project the SAP ASAP methodology will help to ensure you are doing the right things in the right way. 

For more information on acquiring your own copy of the SAP ASAP methodology, see the 10 steps I previously outlined under the section “Where to start with developing a solid SAP business case based on business and IT strategy” in the post ERP and SAP Business Case for ROI, Business Benefit, and Success.  During the sales cycle (or during your project if you are past that) ask your SAP system integrator to show you the SAP ASAP methodology.  There are two identical versions, one is an HTML web server version and the other is integrated into Solution Manager.  Both are free, and the HTML version is available to any customer or vendor free of charge who wants to download it directly from SAP.  There really is no reason they can not make it available.  Because of its wide availability you should beware of any vendor who pitches the SAP ASAP methodology and can not make it available to you! 

If you are an end SAP customer contact me and I will arrange for you to get your own copy!

SAP System Integrator or Implementation Vendor Type

This topic is a little different because there are several possibilities for how you approach your vendor selection or project staffing.  Each of them has their benefits and drawbacks and some of them can be substantially different in cost and results.  The type of implementation vendor and consultants you use will also affect your implementation strategy.

You may wish to employ a well established system integrator; a “boutique” consulting firm; or completely manage the project with your own selected staff of contractors; or you may want to consider a hybrid approach.  If you are considering the contractor route, of staffing a project yourself, you might wish to review the screening methods to find the right consultant Part 1 and Part 2.

You will also need to determine your project implementation model.  Will you do a pure time and materials approach, or fixed fee, or time and materials with penalties for under-delivery (over budget, over time) and rewards for over delivery (under budget, early), or time and materials with cost controls, or a blend of some of the approaches.

Breakthrough Project Success: 2 of 4, IT Vendor Proposal RFP

If you choose the large integrator be prepared for the full sales pitch about their “special” methodology (whether it actually exists or not).  This is one of the classic approaches the larger consulting firms use to try to differentiate themselves.  However the SAP ASAP Methodology has been tested and proven so many thousands of times that any other approach actually introduces risk into the project.  That does not mean that there aren’t ways to supplement that methodology — there are a few gaps — but the ASAP methodology is very solid, reliable, proven and consistent.

The boutique firm may work well for many companies, but they have the drawback of being focused on a narrow niche area. 

The company run implementation with outside contractors (rather than a system integrator) requires a very experienced, very skilled SAP project manager.  I have participated on two of these projects that were very successful and their rates were about 35 – 50% less expensive than other consulting options.  One significant caution here is this type of approach can be a disaster without the means to carefully screen consultants and without a very seasoned SAP project manager.  The other problem is that many (though not all) of the staffing and recruiting firms are so “sleazy” that you are better off putting in the effort to screen yourself.  Back to the chicken or the egg problem, this requires someone who has the capability to do the screening.  This approach has probably the highest reward and the greatest risks associated with it. 

SAP Project Implementation Approach

Over the years I’ve only ever seen two key approaches to SAP implementation projects–, Big Bang or Rollout projects.  Within these two methods you can do a Phased Approach as well, but that is more of an issue of functionality scope rather than organizational scope.

Organizational scope would cover the “Big Bang” SAP implementation approach and the “Rollout” SAP implementation approach.  It affects the amount of the company or organization that is affected by the project. 

Functional scope would address the amount of the SAP business software that you plan on bringing into your organization(s).  This would generally be a “Phase” of the project.  For example you might bring in Financials and Supply Chain functionality in Phase 1, and then CRM or online ordering or BI / BW (reporting) in Phase 2, etc.

ERP Big Bang

The “Big Bang” SAP approach is probably the most common and generally involves a single major functional event.  It usually affects all “legal companies” where financial reporting is required for taxes or regulatory requirements.  This can be a large implementation across multiple countries, multiple business divisions or product lines, and generally affects the whole of the organization.

The “Big Bang” approach may be easier from a single “change event” or “change shock” to the company and organization but it has a number of drawbacks as well.  For example with any ERP application some of the potential design, data, and knowledge transfer problems are only discovered after the system is live.  So if your SAP system integrator or vendor is not as skilled as their sales presentation might have indicated you could end up with serious long-term difficulties, cleanup, and ongoing maintenance headaches.

ERP Rollout

The Rollout approach is fairly popular among a number of larger SAP customers with several legal companies, several locations, or multi-nationals that do business in several countries. 

Advantages of this approach includes the ability to “learn” from each rollout and improve subsequent operational rollouts.  Rollout risk can be more carefully managed because data and configuration inconsistencies can be discovered, remedied, and resolved while the subsequent rollout is occurring.  Change is better absorbed over a longer period of time in the company and knowledge transfer is generally better handled if the customer insists their resources are involved (done correctly this can actually reduce overall implementation costs).

Disadvantages of this approach are that it generally costs more because cumulatively it takes more time and effort to manage the ongoing operations while also bringing on new operations.  Also the blueprint will need to be re-visited for each rollout location because no matter what ANY integrator says (or what the SAP documentation purports) there always seems to be some legitimate differences between each rollout location.  Failure to re-visit the blueprint for each rollout, no matter what the integrator or SAP might say, can cause more difficulties than it is worth.  However, these later stage blueprint reviews and adjustments are not as intense or time consuming.

ERP Phased Approach

Because of the many variations and options we will re-visit the Phased Approach at a later date with more details.

Popular Searches:

  • SAP Implementation strategy

Related Posts:

ERP Project Plan: Getting Real (Part 4)

June 17th, 2010 by

ERP Project Planning Lighthouse


Twelve Tips to Avoid an ERP Schedule Disaster

In my previous blog entries, we established the need to develop a valid ERP project schedule to serve as a tool to manage the project and set the right expectations (in terms of time and budget). The point is ERP planning is not about throwing darts to come up with dates or forcing a schedule to say what we want it to say. We can wish all we want, but a schedule should reflect project realities, and agreed upon planning assumptions.

In addition, we previously emphasized there are several key inputs into the project scheduling process. Two of them often destroy the validity of the schedule before we even get started:

1) Token client input, involvement, and no ownership of the plan,

2) Glossing over the important project scope details.

Project Plan Training

The goal of this article is not to get into a laborious discussion of cranking a project schedule. The discussion will focus on what the practitioner can do, when constructing the plan, to make sure it is a good predictor of the future. The assumption is the reader has a basic understanding of project planning concepts such as “work breakdown structures”, tasks, task durations, task dependencies, deliverables, and resources assignments. If not, take a basic project-scheduling course, and get any other assistance required.

Project Planning Software

It goes without saying some type of project scheduling software is necessary and a basic understanding of how to use it. However, contrary to popular wisdom, a mastery of Microsoft Projects, or any sophisticated project-scheduling tool, is not a prerequisite for constructing a valid schedule.

ERP Project Plan Templates

Furthermore, it is OK to use a schedule “template” as a starting point, particularly if one has questions about project phases, deliverables, and basic task dependencies as they relate to ERP. Templates, deliverables, and other information are readily available on the internet, and from software consultants and software vendors. However, templates are no substitute for getting educated, planning the project details, or, for that matter, getting the help to develop the schedule when needed.

The Sales Proposal is not “The” Project Schedule

In addition, it does not hurt to reference the sales proposals from consulting firms that may have quoted the project, but do not take them too seriously. Why? Sales proposals are just that… a sales pitch, not the real project schedule.

Sometimes it is very difficult to get this concept across to management since many want to hold the consultants accountable for unrealistic schedules (and budgets). What they fail to realize is the schedule is not the consultants, but rather the clients. Furthermore, when the schedule in the sales proposal is wrong (and they usually are) the client pays the price down the road, and the consultants are the beneficiaries of schedule and cost overruns.

The schedule used to manage the project is produced after consultants are selected (when using them), and as mentioned before, after the project scope and client project planning responsibilities are clarified. In addition, prior to publishing any schedule, specific project objectives, the project organization, roles and responsibilities, and time commitments of the team, are finalized and approved by senior management. A decent estimate of the budget is also an input, though the approved schedule is used to finalize it.

In all fairness to consultants, when developing a sales proposal there is simply not enough time, or justification of consulting resources, to get into the details required to flush out a valid schedule. Remember, vendors do not make money on proposals unless they are accepted. Therefore, they spend most of their time getting the client to accept it, and less time making sure it is right.

Avoid the Subtle Pitfalls

Some of the items listed below many not appear on the surface as a big problem. However, the devil is in the details and when one considers the cumulative affects, the results can be a project that ends up hopelessly behind schedule.

#1: Methodology Matters: Understand the ERP Deliverables

Most ERP projects use the “traditional” implementation approach, rapid deployment, or somewhere in between. Whatever methodology you intend to use, get into the specifics of the implementation process, and understand what it truly entails. This is because methodology affects activities, what is delivered, and content of each deliverable. In other words, it will have a huge impact on the work performed (among many other things).

For example, some rapid deployment strategies (wrong, right, or indifferent) skip the formal project team-training step and do it on the fly during the project. Another example is “current process analysis”. The traditional approach treats this as a distinct phase with “current process map” deliverables. On the other hand, rapid deployment may involve informal current environment overviews, discussions, and more or less jump right into prototyping. The point is not to get into the pros and cons of any particular methodology. Nevertheless, in this example, both have a “current process analysis” line item in the methodology, but the level of detail, the type of work, and the physical deliverables can be very different.

#2: Organize the work breakdown structure around business processes

ERP software is implemented around business processes. So why not organization the schedule the same way? This approach also makes the schedule easier to develop and understand. Whether we are talking about team training, current processes, “to be” processes, design, configuration, testing, or end-user training, the common thread is the focus on business processes. Granted, not all project tasks are easily organized in this manner, but most are.

#3: Allow reasonable time to define the unknowns


Any project task with the word “define” or “design” in front of it usually implies more unknowns, more issues, and more decisions. When you stop and think about it, an ERP implementation is about making decisions. In fact, deciding something can take longer than the execution of the decisions.

Therefore, unreasonable timelines to understand the issues, gain consensus, and make decisions can kill a planned go-live date in two ways. First, the schedule is not real to begin with. Secondly, when we rush to complete analysis and design because of unrealistic timeframes to make informed decisions, rework is enviable.

#4: Recognize the project tasks between phases

For example, it is not realistic to assume one will complete the first round of Conference Room Pilot Testing on Friday and immediately jump into round two testing on Monday. The point is there are “wrap up”, “transition”, and “preparation” tasks required to complete one phase and start executing the next.

In the testing example above, the team must wrap up documentation of round one test results, discuss new issues identified, make more software set-up changes to address the issues, prepare additional test cases, and perhaps set up additional data for round two testing.

In this example (like others), some of this can be accomplished concurrently within the round one testing timeline, but certainly not all of it. Considering there are dozens of phase transition points on any project, this can add up to one big schedule mistake.

#5: “Decomposed” project tasks

There is a human tendency to generalize any topic and not consider all the details and implications involved. The sum of all generalizations over the course of a project can be significant.

The best way to help avoid this is to break down tasks into their components and estimate the duration of each component separately. One should decompose each task to the level where the logical steps required to complete it are revealed. One does not have to take this concept to extremes. However, in the end, an effort to do this will result in a much better picture of the project and timeline.

#6: Take advantage of “earliest possible” and “latest possible” starts

Most know project tasks have “dependencies” that must be acknowledge in the schedule. In other words, one cannot start Task B until Task A (predecessor) is first completed.

However, many tasks (as initially defined) are not truly serial in nature, particularly at the highest level of the work breakdown structure. That is, tasks within a given phase can run concurrently with the previous phase to a certain degree. By recognizing this, one can construct a plan to take full advantage of “earliest possible start dates” and “latest possible starts dates” for specific activities.

Again, first decompose each task into logical components. Then take the resulting tasks and link them to their true predecessor task. This allows for the earliest possible start for project activities, which is particularly important for those on the critical path. However, there are a few exceptions where a latest possible start makes the most sense. For example:

A) It is usually best to schedule most training as close as possible to the time of need (as late as possible). But also remember, the task of developing a training schedule can start as early as possible

B) Tasks that share resources with those on the critical path could start as late as possible to smooth resource loads when necessary. In this case, the task does not start immediately after the completion of its predecessor. This is called using the “slack time” associated with non-critical task. The idea is to focus resources on the critical path until the latest possible start date of the non-critical items.

#7: Consider the “estimated level of effort”

As discussed in my previous blog, when defining project scope also define the “level of effort” (and complexity) required for each scope item. This comes into play when estimating task durations.

With regard to “level of effort”, the time to define, design, build, and test, system interfaces and software customizations / enhancements are almost universally under-estimated. The obvious goal is to minimize any type of custom program development when it is feasible to do so. This is because when it gets out of hand, custom development will end up on the critical path.

#8: “Theoretical” vs. “actual” resource capacity

One cannot assume because an individual is committed to working on project 32 hours per week for example, all this time is spent on tasks appearing in the schedule. There is a concept of “theoretical” capacity versus “actual or observed” capacity that should not be ignored.

For example, when planning the capacity of a machine in a manufacturing plant, the capacity used for scheduling usually excludes changeover times, average downtime, etc. This same logic holds true for project scheduling. One way or another, actual resource capacity should be reflected in task durations.

This resource consideration may seem trivial at first, but do the math and assume a twelve-month schedule where four people are spending three hours per week on activities not in the formal schedule. In this case, the schedule assumes it has these 624 hours, but the truth is it does not.

#9: Include quality checkpoints & follow-up activities (plan for rework)

These type of activities are not necessarily formal events, but normally include things like “design reviews”, presentations for approval or feedback, etc. These, and the associated follow-up tasks, are important to include in the plan not only for quality purposes, but also because “changes” normally result.

Feedback and change for the better are good things, but even small changes, can cause rework. This is called “planned rework” since it should be expected and already in the schedule.

#10: Protect the Schedule

We all know everything does not always happen according to plan. Nevertheless, there is such a thing as being proactive to increase the likelihood that it does.

In terms of scheduling, the question is: “what can we do in advance to make sure Task B happens according to plan”. The other angle is “what can go wrong with Task B, and how can we prevent it from going wrong”. This thought process is particular important for activities on the critical path since slippage here means slippage in the go-live date.

The following is a very simple example of “protecting the plan”. How many times have you scheduled an end-user training class and only half the people show up? A simple way to help prevent this is a letter or email (actually created by the project manager) from the highest-level manager at the facility. It communicates the training schedule, who is to attend, and attendance is expected. This letter goes to all attendees plus their managers. Do you think attendance will be better the next time around?

However, why put this simple item in the schedule? One reason is by the time the letter is created and sent, several weeks could go by in most organizations. Secondly, this communication is very important for the success of training, so enter a task for it.

#11: Verify the structural integrity and sanity check dates


Project schedules are usually developed “top down and then bottom up”. This means start with the top of the work breakdown structure, define and decompose tasks, link dependencies, add resources, durations, and then move back up the structure to clarify and validate.

After several iterations, check for structural integrity of task dependencies and relationships since this is where most errors occur. The integrity of the tasks on the critical path must be 100% correct and durations validated and validated again. The project planning software tool can usually help with some integrity checks.

#12: Document and communicate assumptions

When presenting the proposed schedule include project objectives, scope, resources, and time commitment assumptions. Also, document and communicate all other assumptions that surface from all parties involved when building the schedule. Be diligent about this. The reason is people tend to forget the assumptions baked into the plan. This is particular true if the project falls behind schedule.

Conclusion on ERP Project Planning

Again, the scheduling process is not performed in a vacuum. It requires the involvement of all key client stakeholders along the way. Senior management approves the final version. When the schedule is not acceptable, there are only a few choices. Change project objectives (lower expectations), apply more resources to the critical path, or reduce scope. Anything else is wishful thinking.


Editor’s commentary – Steve Phillips runs a great blog which is linked here:

Be sure to visit his site and support his efforts!

Related Posts: