INNOVATE. INTEGRATE. TRANSFORM.

Strategic SAP Solutions for Measurable Business Value

Agile Project Methods for SAP ERP Projects?

October 29th, 2012 by
Agile or Waterfall on SAP ERP projects?

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.




Popular Searches:


  • sap roi powerpoint
  • sap pp roi
  • agile development with ERP
  • success rate of agile development erp projects
  • south carolina north carolina change management for erp implementation engineering
  • sap agile projekt management
  • sap agile methodology
  • project plan activity for agile methodology
  • agile project management with SAP
  • agile project implementation
  • agile methodology erp implementation example
  • What is MOST important according to the Agile Manifesto?

Related Posts:

Achieve Business Benefit Through SAP Prototype Demonstrations

July 16th, 2012 by
Imagine what is possible by showing what is achievable

Functionality Prototype and Demonstration

SAP Conference Room Proof of Concept Pilots

Proof of Concepts with frequent early prototyping drive project costs down.  It is like the old saying that “an ounce of prevention can avoid a pound of cure.”  Proof of concept pilots during the project is one of the rarely mentioned SAP critical success factors. 

Early in my SAP career I used to get a little frustrated by the disruption these prototype sessions, conference room pilots, or whatever you want to call them would cause.  My thought was I had a job to do and didn’t have time for this.  No one ever stopped to help me understand WHY these pilots and prototypes are important.

Before I get into the substance of this let me first be very clear about what I am referring to–, a prototype, pilot, or demonstration is ACTUAL system functionality set up in the application to demonstrate transactional business processing.  I have heard of some system integrators who call PowerPoint process flows these types of “pilots” and that is completely ridiculous.  That is just regurgitating SAP Blueprint process flows and is NOT a prototype, pilot, or system demonstration at all.

Stop the SAP Consulting Merry Go Round – Real Life Experiences

Nothing is more frustrating than trying to work through a complex issue and going around and around with meetings, discussions, process flows, etc.  At one client we had a very complex third party process which involved one foreign company code doing sales deliveries for a domestic company code, but the domestic company would bill the customer and collect the cash, the foreign company would do inter-company billing, etc.  There was not only third party processing involved, there was also foreign trade, batch, and serial number tracking required (YUCK!).

After getting a large and very expensive group of consultants together with key client resources we hammered the first pass out.  Then we did it again a few days later, and then again a few days later.  After about 4 or 5 weeks of this madness it turns out the consultants were the problem more than the client.  Several of the consultants essentially said this couldn’t be done.

To stop the complete waste of time I left the last meeting and spent 3 days setting up a prototype the consultants said couldn’t be done.  Now, in their defense it is complicated and it DOES involve setup in SD, MM, PP, FI, and EDI.  Very FEW consultants have ever done this type of integrated setup.  I scheduled a DEMONSTRATION with all of the key stakeholders and project leadership to put this issue to rest.  The SAP standard functionality covered approximately 90% of the overall requirement and we were now discussing small tweaks or changes that were required rather than trying to over engineer a customized process mess!

Reduce SAP Implementation Cost, Improve SAP Quality, and Manage SAP Scope More Effectively

Using Conference Room Pilots, or Functionality Playbacks is effective for difficult to understand processes system demonstrations.  This technique can significantly reduce meeting times and increase customer satisfaction.

Stanford professors Carleton and Cokayne spent seven years studying the user of physical prototypes in “foresight engineering” which is the ongoing development of products or services that are three or more product cycles in the future.  They studied the use of prototypes for “capturing and communicating a team’s opportunities inside the organization, connecting the company’s vision and strategy with… day-to-day [engineering design work], and helping teams to connect vision to research to engineering design.”  Carleton, T., and Cockayne, W., (2009) The Power of Prototypes in Foresight Engineering.  International Conference on Engineering Design, ICED’09/493, Stanford University, August 24-27 2009, page 1.

The use of prototypes has been found to “make ideas tangible, iterate quickly at a low cost, and develop a shared language” (ibid.).  These demonstrations are part of the change management process and can help to bring the broader organization along in the process. In the second half of the post on ERP, SAP, or IT Project Management and Prototyping for Success more detail is provided for the following items:

  • System demonstrations focus on delivering what is important while allowing for early adjustments.
  • Complex or difficult functionality demonstrations help reduce the overall amount of meeting time.
  • System demonstrations identify gaps and problems earlier reducing the number of testing defects and rework time.
  • Early demonstrations help ensure scope is properly accounted for and last minute process surprises are reduced.
  • Some performance problems are exposed.
  • Possible schedule and work completion issues may be exposed while they might still be manageable.

By doing a LOT of prototypes early in a project you also quickly separate the good IT resources from those who are not so talented or even those who are complete fakes.

Conclusion on Using SAP Prototypes, Functionality Demonstrations or Conference Room Pilots for Project Success

Just as the real world example I noted above shows, by using prototypes or demonstrations to understand where the real business requirement gaps are you may be able to avoid a major investment in custom development work.  And by avoiding that development you reduce ongoing maintenance headaches.

As for dealing with scheduling and work completion I have been on many projects where some of the consultants or team leads would simply lie about their status and completion.  By having a clearly defined pilot and playback schedule throughout the project for certain key functionality you help to ensure that what is committed is actually delivered.  Too many times the real status does not show up until testing starts, or worse still, items get taken out of scope because of misleading status.  By then it is too late.




Popular Searches:


  • success factor sap
  • SAP Business One solution blueprint
  • sap customer master blueprint membership
  • sap sd blueprint deliverable
  • successfactors ppt

Related Posts:

There is Life after the SAP Go Live

June 25th, 2012 by
SAP Support

SAP Support

One of the areas rarely addressed in the academic literature, by consulting firms, or by many of the system integrators is the organizational acceptance, and finally full use and assimilation of the SAP package. To the extent the system integrators or consulting firms do mention post production support it is generally in the context of managed services or outsourcing. Little is done to help companies develop a thriving production environment with your own resources.

One of the biggest problems I see anywhere is a failure to blueprint and ultimately design and then deliver SAP for usability. There are several hurdles which make this difficult, some of them include:

  • The SAP User Experience is one area which is overdue for attention.
  • A lack of in depth change management including training at the business process level.
  • Very few SAP consultants have much (if any) SAP support experience and have no idea about how their design and blueprint decisions will affect end users.
  • There are not enough functionality pilots demonstrated to the affected end users during the course of the implementation project.

After designing for usability the next critical issue involves Organizational Change Management Inside the SAP IT Support Organization. For long term direction Using Your SAP Steering Committee for Business Transformation can not be overlooked either. Finally, the user community, including training, change management, and ongoing super user development must be addressed.

Build a Thriving SAP Enabled Business Community and SAP Support Organization

Work to put the broader business community in a more accepting posture for your SAP / IT organizational changes by using Change Management Strategies and Knowledge Transfer Processes for a Successful SAP Project 1. Then work diligently toward Creating a Knowledge Centered Learning Organization for Business Transformation for IT Leadership. Whether you are already live with SAP, in the middle of a project, or just starting out, I would strongly encourage you to get serious about Organizational Change Management Inside the SAP IT Support Organization.

As an academic study I recently reviewed noted:

It is during [the post-implementation stage] that the effects of uncontrolled problems in previous stages appear due to the fact that users start the exploitation and evaluation of the system. During the implementation stage, users are usually limited to learn the basic functionalities [which support going live]… As a critical mass of users start mastering the system and they see its advantages on their work and its capabilities, they start using it in a more creative way and exploring its more advanced functionalities and requiring, even more functions… These are… signs of the system’s acceptance and assimilation which is… essential for the system’s success (Kouki, Poulin, and Pellerin, Ppg. 3-4).

SAP Certified Center of Expertise

Many of today’s SAP contracts include a provision that customers must create a Center of Expertise. In plain terms this means you are required to create your own internal support organization. This works well for SAP by putting your internal IT employees on the front line of defense but does little to ensure longer term acceptance, adoption, and even assimilation of the new system into the broader organization. Do not get confused by the terminology here either, the type of support SAP wants to see which constitutes a “Certified Center of Expertise” is related to you becoming less of a burden on their support organization, and in turn reducing their support costs for your company.  While this independence helps SAP it also helps to ensure you develop sufficient internal competence with the application.  In turn it is not enough and is just the beginning of the changes you must make.

The very basic components of building an Center of Expertise is contained in the Phase 6 RUN SAP ASAP Methodology. But as I’ve previously noted, this is just the first step of a critical path and process in Business Transformation for IT Leadership.

Understand the Series on SAP Competency Center or SAP Center of Excellence to gain the important insight for ensuring long term enterprise application success. Without a greater focus on the end user you may never fully realize business benefits or it will take longer than necessary, cost more than it should, and yield limited mid-term results.

————————

Kouki, R., Poulin, D., and Pellerin, R. (2006). ERP Assimilation Challenge: An Integrative Framework for a Better Post-Implementation Assimilation, CIRRELT Working Paper DT-2006-DP-1




Popular Searches:


  • SAP Post Go Live
  • competence center maturity level
  • SAP post go live change control organization
  • SAP Go Live
  • challenges for IT after SAP go-live
  • SAP project what to do the training environment after go-live ppt
  • SAP MM GO LIVE
  • SAP go live presentation
  • SAP Competency Centre
  • SAP after GoLive
  • sap after go live ppt
  • organization changes after sap go live

Related Posts: