Analyzing each phase of SAP Activate


After completing this lesson, you will be able to:

  • Analyze each phase of SAP Activate

Details by Phase

The above diagram displays a high-level view of some of the core activities performed across each phase of SAP Activate.

We are going to look at the following:

  • SAP Activate Phases detailed activities

  • SAP Activate Prepare Phase approach

  • SAP Activate Explore Phase approach

  • SAP Activate Realize Phase approach

  • SAP Activate Deploy Phase activities

This slide provides a description of the Prepare phase along with related key activities to be performed.

This figure shows some examples of accelerators that are available for use when delivering a project using SAP Activate. Accelerators are documents, templates, or links to tools and other assets that can help a project team complete their work faster by providing clear guidance or a starting point for producing an outcome like a deliverable.

In the Prepare phase, we have different accelerators:

  • Delivery supplement

  • Solution scope document

  • Software and delivery requirements for the Best Practices Work Breakdown Structure

  • Project management plans and governance documents

This slide provides a description of the Explore phase along with related key activities to be performed.

This diagram provides a description of the purpose of the fit-to-standard process.

The above diagram details in six steps, how to approach the fit-to-standard workshops.

These are the intended outputs of the fit-to-standard workshops.

Following are the principles to be applied in the fit-to-standard workshops:

  • Fit-to-standard: Adopting a Fit-to-standard approach and SAP standard functionality, will minimize delivery risk and ultimately lower the total cost of the implementation and operation.
  • Value Justification: SAP applications are built on industry best practices and any proposed customizations should be motivated against business value.
  • Show and Tell: Leading design activities through showing rather than telling, contributes significantly to business adoption, enablement and acceptance
  • Active Participation: Active participation by the business users in the design and acceptance activities fosters collaboration and is key to delivering a successful solution.
  • Focus on simplicity: When designing the solution, focus on simplicity and ease of use while minimizing unnecessary complex functionality as far as possible.
  • Design Acceptance: Applying these principles in Fit-to-Standard workshops facilitates adoption and leads to design acceptance by the business.

The following seven high-level activities are performed during the fit-to-standard workshops.

  1. Set Reference Value:

    Agree fit-to-standard guiding principles.

    Prepare organizational structure, master data, and process diagrams. Bind processes to value drivers.

  2. Validation of SAP Solution:

    Show and tell SAP standard key design elements.

  3. Collect Delta Requirements:

    Identify gaps to SAP standard.

    Log or create additional scope items.

  4. Create Initial Backlog:

    Set priorities and efforts estimates. Identify dependencies.

    Plan sprints for the Explore phase.

  5. Enhance Solution Documentation:

    Update process diagrams and process design. Visualize UX.

  6. Verify and Accept:

    Verify process and solution documentation. Drive acceptance.

  7. Plan Sprints and Releases

A major consideration before executing the fit-to-standard workshops is to enable business users on key topics that will be covered in the workshops. These include enablement on master data concepts, SAP terminology, workshops' approach, and the SAP Activate Methodology, among other activities.

Enablement sessions should be aligned to project scope to better prepare the business audience for active participation in the workshops.

Here is an example of an accelerator on how to run your fit-to-standard workshops, which is available for download from the SAP Activate Roadmap Viewer and for use in your projects.

There are many other accelerators available for use for each phase, workstream and roadmap available for activities throughout the project.

Applying a full agile approach by running sprints in the explore phase is also possible when using SAP Activate.

The above diagram details activities on how to initialize scrum activities, as well as how to conduct the requirements gathering sessions using sprints in the explore phase workshops.

Continuing with running applying scrum in the explore phase, the above diagram shows how to perform design updates, verification, and sign-off, using a sprint in the explore phase workshops.

This slide provides a description of the Realize phase along with related key activities to be performed.

Project teams in SAP projects can be structured in different ways. The above example shows the structuring of scrum teams by modular or end to end process, as well as by supporting teams.

  • Scrum teams include 5 to 9 members with assigned SAP Project Roles.

  • Scrum teams may be organized by workstream and/or by Application Area.

  • Scrum Master and Product Owner work with scrum team.

  • Work across several scrum teams is coordinated through the Scrum of Scrums Ceremony, where each scrum team delegates its representative.

  • Project Managers, Agile Coaches, Architects, and other roles may also join the Scrum of Scrums Ceremony.

  • The Scrum of Scrums ceremony is used to discuss topics of overlap or integration.

The diagram, Transparent Requirements to Deploy, illustrates the terminology structure and relationship metrics in SAP agile projects.


Sprints are a unit of measure or a period or time between two to four weeks long, where incremental building of the solution takes place. Generally ending with a show and tell session back to the business audience that raised the requirement in the workshop.


Waves are a unit of measure, and larger period with many sprints assigned to a one Wave. Waves are generally one to three months in duration.


The Realize phase is the build phase and consists of one or more waves depending on the size of the project.


A release is all functionalities built ending with a go-live. Projects can have one or several releases, depending on project scope and time.

This diagram provides a good illustration of what a typical Realize phase looks like in an agile context. In the example, there are several sprints from the start of the phase, ending with a user acceptance testing. Included in this example is i firm-up sprint where string testing is performed. Sting testing tests the integration or overlap aspects of the functionality built in the prior sprints.

Integration testing can also be delivered via sprints. Integration testing covers the testing of all functionalities built. This is the final testing performed by the consulting team before the business team tests the system in User Acceptance Testing.

The Sprint Backlog is a list of tasks identified by the Scrum team to be completed during the Sprint. During Sprint planning, the team plans and selects several Product Backlog items, and identifies the tasks necessary to complete each User Story.

A Scrum Board is a tool that helps teams make Sprint Backlog items visible. The board can be physical or digital but serves the same purpose of tracking sprint tasks. The board is updated by the team during daily stand-up session and displays all items that need to be completed for the current Sprint.

The diagram above illustrates the scrum ceremonies performed in a large project. Emphasis behind this slide is, that within a large project, many resources are part of the project team. Essentially, each resource wears 'one cap' and/or a segregation of duties is enforced.

An example of this could be that in a large project, a project manager will only perform project management activities, as the project may have a dedicated release manager and quality manager. Similarly in a large project, there may be a testing team. In this case, the functional consultants will not be responsible for any testing, as the testing team will assume that function.

The above diagram illustrates the scrum ceremonies performed in a small project. Emphasis behind this slide is, that smaller projects have less resources, in their project team, and each resource may need to perform more than one function on the project, essentially wearing 'more caps'.

An example of this could be that in a small project, a project manager will not only perform project management activities but may also need to perform release management or quality management tasks. Similarly in a small project, there may not be a dedicated testing team. In this case, the functional consultants will also be responsible for testing related tasks.

This diagram displays an example of a solution with two releases. In the example displayed above, the first part of the solution is built using sprints in the Realize phase, and subsequent deploy activities performed in the Deploy phase. The first release then goes live and the solution is now productive. After go-live, the project immediately enters the hypercare period, where all project consultants perform support related tasks and activities to support the business with the adoption of the new solution. Once the hypercare period has ended, the second release activities are started, and performed through the different phases until the second go-live, where the entire solution becomes productive.

The diagram above provides an overview and description of the key deliverables performed in the Deploy phase.

Cutover is a set of activities which are performed on the last weekend before go-live. This is a period between switching off access to the old legacy systems and switching on access to the newly built SAP system.

Cutover is planned in the Realize phase and executed in the Deploy phase. Cutover activities can also be performed in sprints to manage cutover related tasks.

This is an example of a cutover template, which is available for download and for use in your projects, from the SAP Activate Roadmap Viewer.

SAP has a total of sixteen standards for key operations processes within a company's business and IT units.

Each standard contains best-practice procedures on how to run the individual tasks, explanations on which tools inside SAP Solution Manager should be used, and available training and services that support the adoption of the standard. The implementation and optimization of these SAP Standards for solution operations are the key deliverables of the Run phase work packages.

These key standards and practices address the needs of business process experts who are responsible for the design and execution of business processes, and of IT departments who ensure that the services provided by the SAP solutions are available for business users post go-live.

The SAP standards for operation are available for download at:

Log in to track your progress & complete quizzes