AGILE for SAP ERP implementation?

[WaldemarFal]

With reference to my post under the same title I like to ask for the practical experiences – my experiences with leaving the open blueprint and later (during realization stage) modifications of specification by SAP ERP implementation are bad. This is of course possible and sometimes necessary but – in my opinion – requires very smart project management. What is your opinion and experiences?

[sam_bayer · Accepted solution]

Waldemar,

Blueprints are simply contracts that are used to punish users for giving their honest opinion about how real software fits their real world.  I believe the only time a business really understands whether a configuration will work in their environment is when they try to use it.  You can't "use" blueprints.  They are only a representation of the solution. 

I believe the Realization phase should be looked at as the time when the Blueprint gets updated to reflect reality.  It shouldn't be thought of as the period where the Blueprint is implemented. 

The challenge is how do you spend the minimum amount of time and energy to get to the point where real users have something real to evaluate?  A related challenge is how do you "contain" the number and types of changes that you allow those users to make to the system?  Those are the real project management challenges. 

Sam

[WaldemarFal · Accepted solution]

Dear Sam,

Thank you! I agree with you in the event the subject of the project is application like CRM or any kind of BI. There you can really go into realization without wasting time for blueprints and reach some pieces of really functional application to give the users for testing or even use!

But my subject are ERP systems and my strong belief based on experience that without good fundament of blueprint and robust realization there will be nothing beside wasted time and disappointment. Example are ERP systems used by students – very rare these system are very well maintained in terms of configuration and provided with daily flow of business transactions (what is normally in business systems) what leads to many warnings during the workshops.

So I mean ERP systems have to be maintained with “boring” waterfall – agile methods will help only in some subsets or areas. That is my point.

Regards

[former_member205178 · Accepted solution]

Hi Waldemar,

As far as New Implementation of SAP ERP is concerned - I totally agree with the assessment. Having said that, I again agree with you that we can potentially use a  combination of ASAP & Agile for SAP ERP New Implementations which might be more effective.

Agile, can be only effective for a set of activities in a phase. Like you said -> ASAP which has “boring” waterfall method and Agile methods will help only in some subsets or areas. 

I have been in projects involving each of them separately and I think Agile does not fit as a overall solution at all for any New Implementation.

Coming to what Sam was saying, my point is that a Blueprint is a Blue Print. What we can bring additional into a Blueprint is a seriousness into the details of -> Business Process Listing, Process Flows, Detailed Use Cases, as many process exceptions as possible, Etc..

At this stage, we should have the main foundation pillars of the Enterprise called as Enterprise Structure to fruition. We should have that clarity. We cannot use a build as you go approach because we are building Pillars and Foundations of the Enterprise that potentially stay for a long long time - technically till the company is living.

My two cents.

Thanks.

[Former Member]

Waldemar,

Take a look at this eBook

I think you may find some really useful tips that outline some real-world practical advice on how to move to a more agile SAP delivery model.

How to run Agile Development for SAP

Cheers,

Olly

[WaldemarFal]

Dear  Colleagues,

first I like to thank you for for participation in the discussion! I’ve learned a lot and I started to write some kind of summary of my private research started with this discussion:

AGILE for SAP implementation? Yes of course!

I can conclude: the discussion is coming very often to the point of contract – and contracts are inevitable in business. Next post will be about contracts and the question: do the organization like to learn (and change as the result of learning) or like to have clear and very detailed contract which de-facto excludes the learning during the project? Do the company like to be agile or not? PRINCE2 and Agile are about to enable learning and change.

SCRUM is strictly described methodology destined for coding - that is no wonder that incorporation of SCRUM by ASAP was made as compromise. I am fully committed to that SCRUM is bringing a lot of positive energy into SAP projects (because that all sexy-stuff like artifacts and rituals) and that was great idea and work to incorporate SCRUM into ASAP. I like use this opportunity to thank you Jan and your team for this!

The question if that is still SCRUM (in Agile ASAP) or not because of some abbreviations, is in my opinion not so important as the project methodology has to be effective.

[janmusil]

Waldemar,

I suggest you to review the Agile ASAP methodology. It provides clear description of how to do visual blueprinting. It definitely does not leave the scope definition or blueprint open until Realization stage. Even in pure SCRUM projects you start with definition of the backlog which is exactly what we do in the front end of the project.

We do either Scope Validation (in case we have a good baseline build that we can start with) or Lean Blueprinting which has objective of completing the backlog of work for the Realization stage. Where we differ is that the full design work is not done in Blueprint, but rather some of the more fine elements are left for Realization. This gives the team ability to better react to changing requirements resulting from end-users (product owner) understanding the solution capabilities better. We also recommend to use value based decision making about modifications or enhancements.

I assume that your main concern is scope management after the backlog is completed. This is especially important in relationships where customers contract companies to deliver the solution. In my mind the fact that the methodology is open to product owner introducing changes does not preclude the contractor from adhering to the contracted scope and handle any out of scope items as scope change requests.

[former_member205178]

Hi Jan,

Interesting !

Does this Visual Blueprint Approach of Agile ASAP methodology apply to every type of SAP Project ?? -> New Implementation, Green Field Implementation, Reimplementation, Roll Out, Upgrades, Etc. ?

Is this a new term I am hearing or is it something which is a registered word - Agile ASAP. If it is I assume it is only SAP Related as ASAP is SAP methodology.

I can try to learn from other sources on this but would be nice since you seem to be an expert on this subject. 🙂

My Experience with Agile is what I have already mentioned in my reply to Waldemar. 

Thanks. 

[janmusil]

Well as we say at SAP - today's ASAP is not your father's ASAP. We keep bringing innovation to the methodology. There are several areas that have been added into ASAP in past several years. Let me focus on the four that may be of interest for this discussion:

1. BPM work stream -- we have completely re-worked the content for business process management work stream - the area of the methodology that deals with requirements gathering, solution design, configuration/development and solution documentation. This has been done for ASAP 7 few years back and we keep this content up to date.

2. Use of visualization techniques -- we have introduced use of show and tell approach in ASAP 7 and later enhanced it with use of visualization for any requirement that can not be easily shown in live system. The use of visualization during blueprint helps clarify the requirements much better than the traditional white boarding and sets the baseline for developers or consultants (depending on the nature of the work that needs to be done).

3. Agile project delivery -- the use of SCRUM predominantly in Realization to build the solution in short time-boxed iterations with fixed scope in each. This approach is based on SCRUM methodology and you can learn more about it from the ADM webinars we delivered earlier this year (http://scn.sap.com/docs/DOC-27840)

4. Design thinking -- earlier this year we have worked with our colleagues in Design Thinking practice to develop guide for using DT in the ASAP project context. This collaboration resulted in creation of 4 guides for use of DT in projects - activities like solution design, architecture, etc.

I'm glad to help if you have questions. If there is interest I'm ready to blog about the above items.

Best Regards, Jan

[former_member205178]

Hi Jan,

Thanks for your assessment and reply.

I like the part about - today's ASAP is not your father's ASAP.

I believe then I am the Father's ASAP person since I have been very long in SAP 🙂 and have used old ASAP. 

Thanks.

[janmusil]

"I believe then I am the Father's ASAP person since I have been very long in SAP 🙂 and have used old ASAP. "

You and I both . I have been working on ASAP in some capacity since 1998 - so I can really identify with what you are saying. Funny - that reminds me I still have these ValueSAP Edition 2 CD sets in my desk. Not like you can install them on any machine today .

I recommend you to consider updating your knowledge with the ASA380 course (or it's on-line variant ASA38R that should be already available from SAP Education). The course provides good level of detail about the new ASAP.

[former_member205178]

Hi Jan,

Good to be in a good company. Even though it has been 15 + Years in SAP for me too, still it is like an ocean of learning and we learn something new every day . I am sure most people in our group feel the same.

Will take your advice on updating my ASAP knowledge asap by taking ASA380.

You have a good one.

Thanks.

[Former Member]

Jan,

It wold be great if what you’ve described could be elaborated within the Agile Roadmap description. Specifically:

- Agile Roadmap - 1.5 Scope Statement - requirements gathering approach (e.g. obtaining customer sign off for project scope) a bit contradicts with agile/SCRUM principles. Rather it might be a sign off (refinement) of a product log (or even a product backlog portion for first sprints). Also, there are no references from scope statement/customer requirements to product backlog or user stories. At the same time other documents like “Agile Project and Sprint Backlog.XL”S do have references to user stories and backlog. I assume Scope Statement description/chapters should be a bit re-designed to comply with Agile principles/methodology (in similar manner it's already  described under 2.16 "Baseline Build" deliverable). 

- Agile Roadmap - 1.9 Execution, Monitoring, and Controlling of Results - Activities could be adjusted more to Agile/SCRUM principles - e.g. change management approach is less strict – backlog grooming/refinement activities are performed on ongoing basis instead of suddenly appearing CRs; a project status is communicated via the demonstration of a workable product increment rather than via “paper-only” status reports etc.

- Agile Roadmap - deliverables 2.15, 2.16 refer to "fully functional environment to demonstrate the standard functionality" - the statement is shy of details which environment is meant here - most probably this should be a development environment. If not, then there should be an activity before this one to build this environment; if yes, then the deliverable 2.23 might need to take place before 2.15, 2.16

I’ve also noticed some inconsistences in RDS Roadmap:

- RDS Roadmap - 2.2 - activities include Agile activity "Conduct Scrums Meetings" – assume activity should be removed because RDS does not follow Agile approach.

- RDS - 3.2. "Sprint initiation" – the same comment as above.

In general, ASAP 8 is a nice blend of an implementation methodology (from SAP itself), project management methods and techniques (from PMBOK) as well as value and business case management approaches (from PMI PgMBOK, OGC MSP and OGC MoV). In my opinion, what could make ASAP even more complete is:

- a bit more details in the area of procurement management (like it’s outlined in PMBoK). Procurement aspect is especially important for companies which do not use SAP (but rather other vendors) services for ERP implementation. For instance, guidelines regarding specific vendor selection criteria, which for SAP projects should be focused on implementation/configuration skills rather than on installation skills, like outlined in these posts: http://www.r3now.com/more-on-vendor-selection-criteria-and-methods-for-erp-project-success/, http://scn.sap.com/people/bill.wood/blog/2010/11/09/sap-implementation-partner-or-company-selection-...

- an embedment of PM soft competencies (you've mentioned this topic in one of your replies). Possibly, IPMA behavioural competences (http://www.ipma.ch/assets/ICB3.pdf) could be used as a baseline. 

Thanks.

Cheers,

Alexey

[janmusil]

Hello Alexey,

thank you for comprehensive response and analysis. Let me add few comments to explain the logic behind some of the decisions.

"- Agile Roadmap - 1.5 Scope Statement - requirements gathering approach (e.g. obtaining customer sign off for project scope) a bit contradicts with agile/SCRUM principles. Rather it might be a sign off (refinement) of a product log (or even a product backlog portion for first sprints). Also, there are no references from scope statement/customer requirements to product backlog or user stories. At the same time other documents like “Agile Project and Sprint Backlog.XL”S do have references to user stories and backlog. I assume Scope Statement description/chapters should be a bit re-designed to comply with Agile principles/methodology (in similar manner it's already  described under 2.16 "Baseline Build" deliverable). "

This is clear demonstration that Agile ASAP is a hybrid approach (along with keeping the phases, Q-Gates, etc.). The sign-off here is more from the contractual side of things which is especially important in commercial contracts that are typical for implementation of COTS solutions. Think of this as a way to formalize the parameters of the contract. This does not imply that the backlog is frozen.

- Agile Roadmap - 1.9 Execution, Monitoring, and Controlling of Results - Activities could be adjusted more to Agile/SCRUM principles - e.g. change management approach is less strict – backlog grooming/refinement activities are performed on ongoing basis instead of suddenly appearing CRs; a project status is communicated via the demonstration of a workable product increment rather than via “paper-only” status reports etc.

This is the same as above - you need to look at the commercial arrangement that typically specifies the scope of work that is being done under the contract. This needs to be handled in a way to satisfy the needs of both parties. The other view is the dynamic of the backlog that is handled just as in any other SCRUM project, but we do recommend in the methodology that the PM from contractors side is a proxy product owner as they typically own the delivery of the project to the contract. SCRUM assumes ideal conditions which can not be always achieved.

- Agile Roadmap - deliverables 2.15, 2.16 refer to "fully functional environment to demonstrate the standard functionality" - the statement is shy of details which environment is meant here - most probably this should be a development environment. If not, then there should be an activity before this one to build this environment; if yes, then the deliverable 2.23 might need to take place before 2.15, 2.16

In case of Agile ASAP we are setting up the DEV environment in during the Lean Blueprint phase that is used for Baseline Build. Sometimes you may have arrangements where cloud based environment is used and we may call that a Demo Environment. This is the approach we use in Simplified RDS Experience Roadmap.

I’ve also noticed some inconsistences in RDS Roadmap:
- RDS Roadmap - 2.2 - activities include Agile activity "Conduct Scrums Meetings" – assume activity should be removed because RDS does not follow Agile approach.
- RDS - 3.2. "Sprint initiation" – the same comment as above.

I believe you are referring to the Simplified RDS Experience roadmap which is really more of a assemble-to-order deployment methodology for pre-assembled RDS packages - think ERP on HANA or CRM on HANA. These packages are delivered as a baseline build for the project and the deltas are then built with Agile iterations. I hope this makes it clear.

In general, ASAP 8 is a nice blend of an implementation methodology (from SAP itself), project management methods and techniques (from PMBOK) as well as value and business case management approaches (from PMI PgMBOK, OGC MSP and OGC MoV).

Thank you for very positive feedback and suggestions below.

In my opinion, what could make ASAP even more complete is:
- a bit more details in the area of procurement management (like it’s outlined in PMBoK). Procurement aspect is especially important for companies which do not use SAP (but rather other vendors) services for ERP implementation. For instance, guidelines regarding specific vendor selection criteria, which for SAP projects should be focused on implementation/configuration skills rather than on installation skills, like outlined in these posts: http://www.r3now.com/more-on-vendor-selection-criteria-and-methods-for-erp-project-success/, http://scn.sap.com/people/bill.wood/blog/2010/11/09/sap-implementation-partner-or-company-selection-...
- an embedment of PM soft competencies (you've mentioned this topic in one of your replies). Possibly, IPMA behavioural competences (http://www.ipma.ch/assets/ICB3.pdf) could be used as a baseline. 

We have done assessment of ASAP with external bodies and the recommendation was to add more content for Procurement Management. We have not done that mainly because in SAP we have very strong process for procurement management and did not have the need to focus on this as strongly as other areas that we kept improving - e.g. Data Migration, Cutover Planning and Execution.

As of the PM soft competencies - we handle this outside of the methodology as part of our practice management which focuses very strongly on growing our talent pool through training, simulations, assessments and certification. I believe this is more of a organizational topic than project topic.

[Former Member]

Hi Jan,

Thank you for the detailed answer and clarifications. With your comments, highlighted ASAP sections make sense for me now. Especially, your comments that Agile roadmap does not precisely follow SCRUM or other Agile methodologies but instead provides a framework of how to enable SAP implementation process to respond to new realities of constantly changing requirements, earlier value delivery and so on.

Maybe, still would be nice to have one day more details in the procurement management area so ASAP can become a one-stop shop for those (not from SAP ) who want to use it as both - SAP implementation methodology and project management methodology.

Thanks.

Cheers,

Alexey

[Totorians0501]

Hi Jan,

Our organization is trying to explore Agile in SAP projects implementation, is there somebody  in SAP Australia that you could recommend us to get contact with?

Thanks.

Regards,

Annie

[janmusil]

Hello Annie,

please send me message on my e-mail and we can figure something out. My e-mail is my first name dot last name @ sap.com

Jan