The Real Story on IT Implementation Methodologies - Brightwork Research & Analysis

Executive Summary

There are a number of IT implementation methodologies, but they usually are not evaluated for their effectiveness.
We cover SAP consulting company methodologies as well as SAP’s Rapid Deployment Methodology.

Introduction to IT Methodologies

IT methodologies are often presented as major differentiators for implementation companies. However, IT methodologies are not what they appear. You will learn the reality of IT methodologies and what consulting companies do not want their customers to know.

Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.

This is published by a research entity, not some lowbrow entity that is part of the SAP ecosystem.
Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department. As you are reading this article, consider how rare this is. The vast majority of information on the Internet on SAP is provided by SAP, which is filled with false claims and sleazy consulting companies and SAP consultants who will tell any lie for personal benefit. Furthermore, SAP pays off all IT analysts -- who have the same concern for accuracy as SAP. Not one of these entities will disclose their pro-SAP financial bias to their readers.

What Are IT Methodologies?

The implementation methodology is how a consulting company performs the implementation. This can be considered the steps as well as the sequence of steps or project phases.

“A product software implementation method is a systematically structured approach to effectively integrate a software based service or component into the workflow of an organizational structure or an individual end-user.”

Methodologies are used to appeal to clients, particularly during the sales process.

Most IT consulting companies will declare that they have some proprietary implementation methodology and that this methodology adds significant value to the project. However, most of the methods have roughly the same steps or phases.

These are the following:

Project Preparation
Design aka Blueprint
Realization (which is the implementation of the design into the software — configuration, etc..)
Testing
Go-Live and support

Who Provides Some Information About SAP Implementation Methodologies

The major SAP consulting companies and SAP provide very little in the way of information about their implementation methodologies publicly. You have to either work for that company or be a client or prospect to receive access to these methodologies.

Problems with SAP Implementation Methodologies

One of the primary weaknesses of all methodologies offered by consulting companies. This weakness is that the methodology that is published is considered more important to help sell a business. As proof to the prospect, the consulting company should be selected rather than a competitor.

An implementer like me does not write SAP implementation methodologies. Still, by senior members of the company, administrators are basically people who don’t have to do any of the work to meet with ASAP. When I worked on Deloitte’s methodology, there was a great focus to include things that Deloitte could sell into the methodology, which did not have much to do with creating a coherent methodology as much as it was designed to support sales. I have called the Deloitte SAP implementation methodology the “wish list of things that Deloitte partners would like clients to purchase.”

Marketing SAP Implementation Methodologies Versus the Reality

These SAP implementation methodologies, in most cases, place an impossible standard upon project managers to cross every T on the methodology. But these things, in most cases, simply don’t happen on IT projects. If we look at SAP’s ASAP implementation methodology, conforming with all of ASAP areas would be very close to impossible.

I have never seen all of these forms and templates filled out on any project on every project I have been on. It is impressive if even one can simply find quality functional specification documentation. In most cases, the foundational documents are often poorly written or out of date.

Companies are not willing to pay to have all of these things filled out, and when a project gets behind, the documentation is the first thing to go out the window. So how well do SAP implementation methodologies represent what happens on SAP projects? In my view, very poorly.

The Waterfall Approach Versus Agile Approach for IT Methodologies

This is a standard linear approach or waterfall approach to projects. But this has been the same basic approach since systems were implemented, and other types of projects, such as projects not involving computer software implementation, use roughly the same steps. It is not possible to do these steps in a different sequence. For instance, you can’t put testing ahead of design, and you can’t place design before project preparation. However, some implementation methodologies use an agile approach, which means there are multiple cycles of these same steps.

Along with the steps and the sequence, there is all manner of other dimensions added to the methodology. For instance, Deloitte adds a tool called ARIS, which is for business process modeling. Often, some accelerator is included in implementation methodologies, which promises to allow the software to be brought live more quickly and less expensively. Methodologies are also continually being reworked, but not with the concept of reflecting the reality of projects, rather instead incorporating topic concepts so that the methodology appears to be leading-edge, desirable, and “relevant.”

And this gets to one of the primary weaknesses of all methodologies offered by consulting companies. This weakness is that the methodology that is published is considered more important to help sell a business. As proof to the prospect, the consulting company should be selected rather than a competitor, that it is to actual implementation. The evidence I can provide to this effect is if you look at who writes implementation methodologies, it is the most senior members of the organizations that create them. These are individuals who don’t implement projects as much as they sell projects. It would be rare to obtain very much involvement from active implementors in developing the implementation methodology.

Methodologies Per Consulting Company

Below each excerpt from a methodology document or article, I have included commentary that should help readers understand my material observations. This email is not a conclusion on what to do with the SAP implementation methodology information. But is more of an explanation of the exploratory research into the area. From this, we can determine what the next step is.

Now we will review the methodologies that I was able to find from SAP consulting companies and SAP. These consulting companies were chosen from Gartner’s Magic Quadrant, which lists the world’s largest SAP implementation consultancies. Most of them did not have anything even mentioned in SAP implementation methodology. However, I would assume that virtually all of them have some private SAP implementation methodology. The question of whether they adhere to it is separate.

Deloitte

Deloitte has a methodology that they call BPM or business process modeling. It is focused on ARIS process modeling software. A screenshot from Deloitte’s methodology document is included below.

This shows being able to keep multiple process documents open. This provides Deloitte with better transparency and collaboration than using Microsoft documents saved to Sharepoint. Deloitte did not always use this as a counterpoint of their methodology.

Ten years ago, they did not use ARIS at all, but they decided to become more tool-centric in their methodology at some point between then and now.

IBM

IBM has a methodology called Innovative Implementation. According to IBM, it simplifies and Accelerates ASAP Blueprint, which is SAP’s implementation methodology. Therefore, IBM’s methodology is highly based on SAP’s.

KPMG

Nothing found

E&Y

Nothing found

HP

Nothing found

Accenture

Nothing found

InfoSys

Nothing found

Tata

Nothing found

NTT

Nothing found

CSC

Nothing found

Cognizant

Nothing found

WiPro

Nothing was found specific to its methodology was published publicly. However, WiPro does have an article where they refer to something called the RDS or rapid-deployment solution.

The SAP Rapid Deployment Solution

This quotation is from an article from WiPro on the SAP RDS

“The flavor of the season seems to be RDS (Rapid Deployment Solution). But anyone familiar with the SAP marketplace will also be familiar with its earlier avatars-best practice templates, pre-configured templates and so on. Why this sudden fancy with RDS then? Well, I think it is a result of many factors.

Firstly, large ‘soup to nuts’ green field implementations have become a thing of the past, at least for the most part. Now, RDS as a concept is more amenable to be implemented in small chunks. Consequently, most RDSs are focused on sub-processes within various Lines of Business.

Secondly, SAP as an organization is pulling out all stops to promote RDS as a concept. The slew of RDS offerings in the marketplace needs to be seen to be believed. RDS solutions are not restricted to Line of Business solutions. They are cutting across processes, domain and technology. You have RDSs around HANA, mobility and even on something as new in the SAP stable as Crossgate.

Thirdly, everyone is rooting for low TCO, faster speed to market, low custom code, best practice templates, easy usability, agile implementation, et al. SAP is tapping into this mindset by aggressively promoting RDS as a concept across all its platforms. This is a win-win situation across the board. Customers get a deep and broad application like SAP at a lower cost and faster speed. After a quick launch and acceptance, they can expand the footprint in due course, budgets permitting. For SAP, it can effectively counter competition and reduce shelf ware.

I fundamentally believe that like HANA, Sybase and a couple of other strategic initiatives, SAP is beginning to get it right with RDS. For example, XML5 and other UI related initiatives eminently address usability needs HANA disruptively addresses performance needs Sybase and its tools are best in class mobility solutions; with Syclo in the bag as well, SAP has become the undisputed market leader in mobility Shorter software releases significantly transforms software upgrade and maintenance processes And now RDS.

To conclude, I think RDS might end up changing the way SAP and other tier 1 applications get implemented. The day may not be far when classical SAP implementation has to re-orient itself to an RDS based implementation methodology.” – WiPro on SAP RDS

This article was written back in 2012. However, none of the things in this article came true. This is true of most articles written by people with a sales quota on SAP. These articles are designed to drum up interest in SAP and demonstrate competence, not to predict what will come true. RDSs were useless for improving the implementation of SAP projects. They were simply designed to give the clients the impression that they could get software implemented faster than the consulting company was willing or able to.

I analyzed several RDSs for a consulting company. My conclusion was that they did not help do anything but providing the inaccurate expectation that the SAP software module covered by the RDS could be implemented more quickly than it actually could be.

Capgemini

“iSAP is CapGemini’s SAP implementation methodology.

iSAP includes six phases: project preparation, blueprint, realization build, realization test, final preparation, and operate.

In each phase, we bring the extra value that makes iSAP singularly effective in delivering an SAP solution that works successfully, supporting your company in the achievement of its goals:”

“Business process perspective — By focusing on how people and systems work together, we find measurable opportunities to improve end-to-end process performance through SAP-enabled changes and lean best practices.
Beyond-the-basics development — Because our methodology is robust with best-practice templates for the basics, we can quickly apply two added-value techniques — “Design by Acception®” and “critical path sequencing,” sure the new system fits your business.
User-responsive data management — Industrialization enables optimized data migration.
Organization change management — iSAP provides change management tools for the SAP-enabled business transformation of people, processes, and technology.
Project management — We work lean, always looking for and finding ways to incorporate the best, established standards and procedures for project management to achieve optimal productivity.”

“What makes your business a success?

We care about that question, and we keep it top-of-mind during your SAP implementation.

For Capgemini, excellence is fundamental.We’re committed to client satisfaction, each and every time. iSAP is the newest way we’re proving our value as an SAP “Global Partner Service Innovator” and a recognized leader in SAP implementations around the world. The right methodology, at the right time — made to deliver more value, right now — that’s iSAP.”

In a separate document, CapGemini states the following:

“When Capgemini invented iSAP it brought Lean manufacturing principles to the practice of implementing SAP rec projects. In doing so it also created an ideal solution for a problem that has challenged SAP project teams for a long time — how to apply Agile on an industrial scale. It turns out that the same methods and tools iSAP uses for Lean are also well suited for Agile. For example, they are designed to make highly visible those activities that either add value or contribute waste and also those critical decisions that customers and project leaders still need to make. (In fact, one of iSAP’s key practices is called “visual management.”) Once identified, that information is a natural input to Agile teams looking for rapid and holistic feedback — holistic in that the feedback may come from anyone on the project, especially customers who have new requirements. iSAP’s inventors call this Design By Acception®— focusing on the relatively few difference makers that truly add value for the customer — which is a turn on the Lean phrase of “management by exception” — which is to only focus on (and eliminate) things that make waste. Design By Acception® also dovetails naturally with Agile, which is all about finding opportunities for adding value in short iterative bursts of development. In both Lean and Agile, value is what the customer says it is, so the only way to know for sure is by asking the customer. Agile assumes that what the customer wants will constantly change in light of new information (including the arrival of new project deliverables). So by highlighting the “waste makers” iSAP can drastically enhance the quality of collaboration with the SAP customer and thereby drastically streamline Agile.”

This PDF document just continues in this manner. This document is designed to sell potential CapGemini on iSAP, not to explain what it is.

To access the actual methodology, it would probably be necessary to either work for CapGemini or be a current client or prospect of CapGemini. One could contact CapGemini and ask, using the idea that one is conducting research implementation methodologies.

PwC

PwC has a concise document that describes its methodology. I have a few screenshots copied below:

As you can see, this is very general information. PwC is communicating that the methodology is related to other factors. But once again, this is at the level of generalization.

Neoris

The following quote is from Neoris’ SAP implementation methodology web page:

“S2OA (SUSTAINABLE SOA)

The SOA offer by Neoris responds to an integral approach that aligns processes and information technology with the business goals. Neoris considers the organization a system and articulates the technology, information and processes as components of an overall structure. Neoris can ensure that the SOA implementation is sustainable, manageable and profitable through an appropriate articulation and alignment of processes and business goals.

This does not make any sense. This document was written in 2015, but SOA is a technology approach that was promoted by SAP that is no longer a term that is even used. In practice, SAP is against SOA because it increases competition for them.

This Neoris implementation methodology explanation is pure marketing hyperbole that won’t have anything to do with an actual implementation.”

SAP

SAP has had its implementation methodology for many years. ASAP has introduced roughly 20 years ago, and all consulting companies will state that their methodology is consistent with ASAP.

What follows is a high-level explanation of ASAP that is publicly available.

ASAP focuses on tools and training, wrapped up in a five-phase process-oriented roadmap for guiding implementation.

The road map is composed of five well-known consecutive phases

• Phase 1 Project Preparation

• Phase 2 Business Blueprint

• Phase 3 Realization

• Phase 4 Final Preparation

• Phase 5 Go-Live and support

You can access the ASAP Methodology on the SAP Service Marketplace pages (login required).

Benefits of ASAP 8 Methodology include

“Reduced total cost of implementation by embedding the principles of SAP Advanced Delivery Management into a prescriptive, streamlined and modular implementation road map for ASAP.”

“Content-rich implementation accelerators, templates, and guides for implementation projects from strategy to operations

Transparent value delivery through a consistent reflection of the business case.

Efficient project governance, quality management, and guidance for implementation projects and Business Process Management

An approach that combines user-centric design, business processes, and IT architecture

Coverage of the entire project lifecycle – from evaluation through delivery to post project solution management and operations.”

“Consistent content from Value Maps, Solutions, configuration to business process monitoring.”

“(the) Latest version of Solution Explorer and Solution Configurator to explore SAP solution capabilities, select appropriate solutions and determine best pre-assembled RDS for your project

Proven and scalable implementation methodology guiding your team through the agile implementation project and ensuring seamless setup of solution operations

Seamlessly integrated with SAP Solution Manager in both implementation and solution operations

Simplify implementation further — EVERY implementation starts with best practice content based on pre-assembled RDS ASAP methodology framework is provided to end users in four variants (pre-selections)) to support various deployment strategies for implementation of SAP system. The following ASAP 8 pre-selection variants are available for end-users in SAP Service Marketplace (and also in SAP Solution Manager starting with ST-ICO SP37 content package release level):

Simplified Rapid Deployment Solution Experience / Assemble to Order Project

The success of your SAP solution is to a large degree determined by the speed and the effectiveness of the software implementation to add value to your organization. That is why SAP has introduced the Simplified Rapid-deployment Solution Experience. It combines the ability to explore SAP solution capabilities, select the appropriate pre-assembled RDS as a starting point for your project, and implement the solution in your business with the help of structured implementation approach – ASAP 8 Methodology for Simplified Rapid-deployment Solution and integrated operation supported by SAP Solution Manager.”

“Simplified Rapid Deployment Solution Experience / Assemble-to-Order Project Methodology Phases – The Simplified Rapid Deployment Solution Experience / Assemble-to-Order Project Methodology is structured into the following phases.

Project preparation – This phase provides initial planning and preparation for the project. Each project has its unique objectives, scope, and priorities. The deliverables described in this phase assist in completing the initiation and planning steps efficiently and effectively – like the setup of project governance, project plan, and project schedule are prepared at this stage.

Scope validation – The purpose of this phase is to achieve a common understanding of how the company intends to run SAP to support their business. It focuses on the rapid setup of the environment that is available for validation workshops with business users to confirm the scope and determine delta requirements that will be realized in the next phase to enhance the baseline provided by pre-assembled RDS.

Realization – The purpose of this phase is to implement all the business process delta requirements defined during the Scope Validation phase. The team configures, develops, tests, and documents the solution in a series of time-boxed iterations. Before the solution is released to the next stage, it is fully end-to-end integration tested and accepted by end users.

Final preparation – The purpose of this phase is to complete the cutover activities (including technical and load testing, end user training, system management, and cutover rehearsal activities) to finalize your readiness to go live. The Final Preparation phase also serves to resolve all remaining critical issues. On successful completion of this phase, you are ready to run your business in your live SAP System.

Go-live support – The purpose of this phase is to move from a project-oriented, pre-production environment to live production operation and provide sustained support to business users to aid their transition into the new environment

Operate – The purpose of this phase is to fine-tune the application lifecycle standards, processes, and procedures established during the project and align them with operational needs. The central operation platform is the SAP Solution Manager, which leverages the documented solution for system operations.”

“ASAP has been adjusted over the years to account for various trends in software implementation. One of these trends in IT project implementation management it called agile.

Agile ASAP 8 Methodology

The success of your SAP solution is to a large degree determined by the speed and the effectiveness of the software to add value to your organization. That is why SAP has introduced Agile ASAP; a new, practical implementation methodology that allows you to implement operating functionality in short iterative cycles. In each cycle the team implements the most valuable and important functionality first. This enables you to generate results faster, gain immediate insight into the value, increase the flexibility of the implementation and improve progress monitoring.

Agile ASAP 8 Methodology Phases – The Standard ASAP 8 Methodology is structured into the following phases.”

“Project preparation – This phase provides initial planning and preparation for the project. Each project has its unique objectives, scope, and priorities. The deliverables described in this phase assist in completing the initiation and planning steps efficiently and effectively – like the setup of agile project governance, project plan, and project schedule are prepared at this stage.

Lean blueprint – The purpose of this phase is to achieve a common understanding of how the company intends to run SAP to support their business. It focuses on the rapid setup of a solution validation environment for validation workshops with business users to confirm the scope and determine delta requirements that will be realized in the next phase to enhance the baseline build of the system.

Realization – The purpose of this phase is to implement all the business process delta requirements defined during the Lean blueprint phase. The team configures, develops, tests, and documents the solution in a series of time-boxed iterations – the most valuable functionality first. Before the solution is released to the next phase, it is fully end-to-end integration tested and accepted by end users.

Final preparation – The purpose of this phase is to complete the cutover activities (including technical and load testing, end user training, system management, and cutover rehearsal activities) to finalize your readiness to go live. The Final Preparation phase also serves to resolve all remaining critical issues. On successful completion of this phase, you are ready to run your business in your live SAP System.

Go-live support – The purpose of this phase is to move from a project-oriented, pre-production environment to live production operation and provide sustained support to business users to aid their transition into the new environment.

Operate – The purpose of this phase is to fine-tune the application lifecycle standards, processes, and procedures established during the project and align them with operational needs. The central operation platform is the SAP Solution Manager, which leverages the documented solution for system operations.”

“Standard ASAP 8 Methodology

Standard ASAP 8 Methodology takes a disciplined approach to project management, organizational change management, solution management, application life-cycle management and other disciplines applied in the implementation of SAP solutions. The Standard ASAP 8 Methodology is built around the SAP Advanced Delivery Management model and supports project teams with templates, tools, questionnaires, and checklists, including guidebooks and accelerators. Standard ASAP 8 Methodology empowers companies to exploit the power of the accelerated features and tools already built into SAP solutions.

Standard ASAP 8 Methodology Phases — The Standard ASAP 8 Methodology is structured into the following phases.”

“Project preparation – During this phase, the team goes through initial planning and preparation for the SAP project.

Business blueprint – The purpose of this phase is to achieve a common understanding of how the company intends to run SAP to support their business. In Standard ASAP 8 Methodology, the result is the Business Blueprint, a detailed documentation of the results gathered during requirements workshops.

Realization – The purpose of this phase is to implement all the business process requirements based on the Business Blueprint. The system configuration in Standard ASAP 8 Methodology is done in two work packages: Baseline configuration (major scope); and Final configuration (remaining scope). During this phase, the solution is also tested.

Final preparation – The purpose of this phase is to complete the final preparation (including technical testing, end user training, system management, and cutover activities) to finalize your readiness to go live. The Final Preparation phase also serves to resolve all critical open issues. On successful completion of this phase, you are ready to run your business in your live SAP System.

Go-live support – The purpose of this phase is to move from a project-oriented, pre-production environment to a live production operation.

Operate – During this phase, the system is operated with the help of the central operation platform, SAP Solution Manager, with the documented solution based on the transferred project documentation.”

Each phase has a set of deliverables produced during the stage and serves as the input to follow-up phases. Each deliverable provides a list of outputs it consists of and methods used to produce the deliverable.

“Work Streams

The ASAP 8 Methodology is structured around the key project work streams that are outlined in the picture below. For each work stream, the methodology provides the number of deliverables that are to be produced in each phase of the project.

ASAP 8

ASAP 8 is available at a protected SAP portal that customers and consulting companies can access.

The sequence is the following:”

Project Preparation

Project Initiation
Project Governance
Project Charter
Kick-Off Workshop
Scope Statement
Project Schedule and Budget
Project Management Plan
Project and Operational Standards
Execution, Monitoring, and Controlling of Results
Organizational Change Management Roadmap
Project Training Strategy and Plan
Project Team Training
Business Process Map
Value Determination
Business Scenario Design
Prepare Testing Policy
Data Migration Approach and Strategy
Technical Requirements Design
Interface Inventory
Initial Hardware Sizing Proposal
Project Support Tools and System Setup
Phrase Closure and Sign Off Phase Deliverables
Project Start to Design

Business Blueprint

2.1 Phase Initiation
2.2 Execution, Monitoring, and Controlling Results
2.3 Stakeholder Analysis
2.4 Change Impact Analysis
2.5 Communication Plan
2.6 End User Training Strategy and Plan
2.7 Project Team Training
2.8 End User Training Content
2.9 Scope Validation / Fit-Gap Analysis
2.10 Business Solution Design for Business Objects
2.11 Detailed Design – Business Scenario #1 -n
2.12 Detailed Design – Business Process #1 – n
2.13 Value Realization
2.14 Detailed Design – Configuration and Enhancements
2.17 Visualization
2.19 Legacy Data Migration
2.20 Legacy Data Archive
2.21 Technical Solution Design
2.22 User Access and Security
2.23 Development Environment (DEV)
2.24 Testing Strategy
2.26 Phase Closure and Sign-Off phase Deliverables
2.27 MILESTONE: Design to Build

Project Realization

3.1 Phase Initiation
3.3 Execution, Monitoring, and Controlling Results
3.4 Organizational Alignment
3.5 Educational Readiness Review
3.8 Knowledge Transfer
3.9 End User Training Delivery Enabled
3.10 Configured General Settings and Organizational Structure
3.11 Configured Master Data Objects #1 – n
3.12 Core Configuration and Documentation – Process #1 – n
3.13 Delta Configuration – Process #1 – n
3.15 Enhancement Development – RICEFW Object #1 – n
3.16 SOA / Composite Application Development #1 – n
3.17 Business Process Procedure
3.18 Value Audits
3.19 Scenario Test #1 – n
3.20 Quality Assurance Environment (QAS)
3.21 MILESTONE: Build to Test
3.23 Preliminary Cutover plan
3.24 Approved Integration Test
3.25 Legacy Data Migration
3.26 Approved User Acceptance Test
3.27 SAP Data Archiving
3.28 Production Environment (PRD)
3.29 Failover Environment
3.30 System and Performance Test
3.31 SAP Going Live Check
3.32 System User Roles and Authorization Administration
3.33 Technical Operations and Handover Plan
3.34 Technical Integration Check
3.35 Phase Closure and Sign-Off phase Deliverables
3.36 MILESTONE: Test to Deployment

Final Preparation

4.1 Phase Initiation
4.2 Execution, Monitoring, and Controlling Results
4.3 Organizational and Production Support Readiness Check
4.4 Pre Go-Live End-User Training Delivery
4.5 Approved Technical System Tests
4.6 Production Cutover
4.8 Phase Closure and Sign-Off phase Deliverables
4.9 MILESTONE: Production System Live

Go Live Support

5.1 Phase Initiation
5.2 Execution, Monitoring, and Controlling Results
5.3 Knowledge Support Strategy
5.4 Post Go live End-User Training
5.5 SAP Going Live Check – Verification Session
5.6 Production Support After Go Live
5.7 MILESTONE: Deploy to Run
5.9 End User Acceptance Survey
5.10 Project Closure and Sign-Off Project Deliverables
5.11 MILESTONE: Project Complete

Each one of these entries has associated documents available at the SAP Service Marketplace. I will provide a few examples of what is contained within these entries.

Under Go-Live Support

If we take the first entry under Go-Live Support as an example, there is a document titled Project Start Up Check List. This checklist contains four pages of tasks. This document has been attached to this email for the readers’ review.

Under Business Solution Design for Business Objects

Under the entry Business Solution Design for Business Objects, the following accelerators are listed.

Under Technical Solution Design

Under the Technical Solution Design entry, there is a document titled Design Thinking for IT Architecture Design. This is one of the many philosophies that influence ASAP. Design Thinking is a concept that has been used by SAP across multiple areas, as I have also seen it as part of the sales training at SAP.

Interpretation of ASAP

I could explain many parts of ASAP, the documents that come along with it, etc.. However, the point should be taken that this an extensive area to cover. Conforming with all of the areas of ASAP would be very close to impossible. I have never seen all of these forms and templates filled out on any project I have been on. It is an accomplishment if one can find quality functional specification documentation at a company after implementation. In most cases, the foundational documents are often poorly written, incomplete, or out of date.

I have not found that companies are willing to pay for such expensive resources to have all of these things filled out ideally. When a project gets behind, the clients themselves will deemphasize things like documentation. Furthermore, if you look at projects that were implemented without a consulting company, such as internal client projects, they do not conform to such high standards as outlined in the ASAP methodology.

Now on the consulting company web pages, you would never have any company admit to this. This is true for any other consulting company. The reality of projects is much messier than the idea that every T is crossed on every document or that what is the wide variety of documents, checklists, and rules that are part of ASAP will be followed.

Conclusion

The only complete methodology I have access to without reaching out to people is SAP. This is because I have a login to their Service Marketplace, which is restricted to clients and those that work with SAP. SAP’s ASAP methodology is considered the source methodology, and all SAP consulting companies will state that their methodology is consistent with SAP’s ASAP.

The negative aspect of ASAP is that ASAP is so extensive that it sets an impossibly high standard that no project could meet. It is not written by an implementor like me, but by senior members of SAP, administrators, etc.. These are people who don’t have to do any of the work to conform to the methodology. Instead, it is written or at least managed in its writing by people with a sales responsibility, so the focus is less on the methodology’s usability. When I worked on updating Deloitte’s methodology roughly ten years ago, there was a great focus to include things that Deloitte could sell into the methodology. It did not have much to do with creating a coherent methodology as much as it was designed to support sales. I have called the Deloitte SAP implementation methodology the “wish list of things that Deloitte partners would like clients to purchase.”

The issue with methodologies is that they are as much designed to help sell projects as they are designed to improve projects’ implementation. There is also not any evidence that following any of these methodologies enhances the success of implementation projects. And there will never be. No company would ever admit that their methodology was ineffective.