asap methodology 1st phase project preparation 38 pages

8/11/2019 ASAP Methodology 1st Phase Project Preparation 38 Pages

1/38

ASAP Methodology for Implementation 7.2

PurposeThe ASAP methodologyfor implementationis a phased, deliverable-oriented methodology that streamlines implementation projects, minimizesrisk, and reduces total cost of implementation. ASAP takes a disciplined approach to project management, organizational change management,solution management, and other disciplines applied in the implementation of SAP solutions. The methodology supports project teams withtemplates, tools, questionnaires, and checklists, including guidebooks and accelerators. ASAP empowers companies to exploit the power of theaccelerated features and tools already built into SAP solutions.Benefits of ASAP include:

Faster implementations with streamlined and focused methodology More reliable projects, thanks to proven tools, accelerators, and best practices Lower risk More efficient use of resources Reduced costs Effective project management based on Project Management Institute standards

PhasesThe ASAP methodology delivers the following phases:

1. Project preparation In the project preparationphase, the project team defines project goals, a high-level scope, and a project plan.Executive sponsorship is secured, and the project standards and organization are set up. The implementation strategyis defined and approved. At the same time, the project procedures, standards, organization, and staffing are finalized.Roles and responsibilities of the entire project team are agreed upon and documented. The objectives of the project arevalidated, and all initiation activities are documented in the project charter.

2. Business blueprint During this business blueprintphase, solution and technical designs are documented in the business blueprint. Leadby solution and industry experts from the SAP Consulting organization, a series of structured process workshops areplanned and executed to arrive at the to-be delivered" SAP enterprise solution. All available documentation forstandard, delivered support for SAP business scenarios and all relevant preconfigured support for best practices arereviewed and discussed with SAP experts. All functional and technical requirements, coupled with project issues andgaps, are documented in the SAP Solution Manager application management solution.

3. Realization In the realizationphase, the SAP software system is configured and tested in a number of cycles. Initially, the baselineconfiguration, which represents the core business process settings, is performed, tested, and confirmed. This isfollowed with a series of configuration and development cycles, to implement the entire end-to-end solution. Thesolution is tested in a number of cycle tests and in a focused end-to-end integration test. Configuration is documented inSAP Solution Manager. All development such as enterprise services, interfaces, data conversion programs, reports, andany required enhancements are built and documented in SAP Solution Manager. Legacy data conversion programs arecreated and tested. The production system is installed during realization.

4. Final preparation Within the final preparationphase, all systems are known to function correctly following the approved integration test.Technically, all integration issues should now be resolved. Detailed transition and cutover plans are created. Thecustomer support organization is put in place. The production system is set up with transports and customer data. At theend of this phase, the production system is switched on and business operations start in the new environment.

5. Go-live support The purpose of the go-live supportphase is to move from a preproduction environment to live production operation. An

easily accessible production support organization must be in place to support the end-user community, not just for thefirst critical days of production operations, but also for long-term support.

6. Run The primary goal of the runphase is to ensure the operability of the solution. Operability is the ability to maintain ITsolutions in a functioning and operating condition, guaranteeing systems availability and required performance levels tosupport the execution of the enterprises business operations. The recommended starting point of the phase is anassessment of solution operation after the go-live support phase to identify the relevant SAP standards for solutionoperations to be established or improved in the phase. The central operation platform is SAP Solution Manager, with thedocumented solution based on the transferred project documentation.


2/38

Work Streams

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

The deliverables in later phases leverage or build upon deliverables completed in earlier stages. The roadmap is structured as a work breakdownstructure(WBS) that represents a complete list of deliverables that need to be completed by the project team.The ASAP methodology for implementation projects represents a standardized work breakdown structure that provides the foundation for definingimplementation project work in a deliverable-oriented, hierarchical manner and managing the project work to completion.

ASAP methodology contains a standard set of templates, samples, accelerators, guidelines, and checklists for use by project teams in effectivelymanaging and completing SAP solution implementation projects.

SAPCopyrights and Trademarks

2010 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without theexpress permission of SAP AG. The information contained herein may be changed without prior notice.Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iSeries,pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power

Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS,HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli andInformix are trademarks or registered trademarks of IBM Corporation.Linux is the registered trademark of Linus Torvalds in the U.S. and othercountries.Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporatedin the United States and/or other countries.Oracle is a registered trademark of Oracle Corporation.UNIX, X/Open, OSF/1, and Motif are registeredtrademarks of the Open Group.Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks orregistered trademarks of Citrix Systems, Inc.HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide WebConsortium, Massachusetts Institute of Technology.Java is a registered trademark of Sun Microsystems, Inc.JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, Clear Enterprise, SAP BusinessObjects Explorer and other SAP products and servicesmentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries.Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and otherBusiness Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAPFrance in the United States and in other countries.All other product and service names mentioned are the trademarks of their respectivecompanies. Data contained in this document serves informational purposes only. National product specifications may vary.These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") forinformational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respectto the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statementsaccompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.


3/38

PHASE1 : PROJECT PREPARATION

1. Project Preparation

PurposeThe project preparation phase provides initial planning and preparation for the project. Although each project has its own unique objectives,scope, and priorities, the deliverables outlined below assist in completing the initiation and planning steps in an efficient and effective manner.

Work StreamsThe major work streams for this preparationare:

Project management Organizational change management (OCM) Training Data management Business process management Technical solution management Integrated solution readiness

1.1 Project Management

PurposeThe purpose of the project management phaseis to provide essential methodology for the requirements planning for and execution/controlling ofan SAP software implementation project.

Team Identification, Allocation, and CoordinationDuring subsequent phase start-up activities, the project manager coordinates the allocation of resources identified for the project phase using theproject schedule and the resource plan. This ensures the proper timing of resource assignments needed to complete project work. The projectmanager validates the participation and ongoing commitment of the steering committee members at the phase start-up.

Kickoff MeetingThe scale of this task varies with project size and complexity. For small, low-r isk projects, the kickoff meeting may be an informal review of theprocess by the project sponsor and the program or project manager. For larger projects, you should consider a formal kickoff of the project toachieve a common understanding of the objectives of the planning process and to clarify the various participants roles. The project managerclearly defines theobjectives of each phase kickoff meeting and designs the agenda to achieve that objective. Consider conducting the followingtypes of meetings:

Team-focusedmeetingsshould be focused on the team to ensure alignment around the work (definition and approach for outputs) to beperformed during the phase.

Communications-focusedmeetingsshould be focused more on communications across the organization, bringing the project sponsorand key stakeholders together to reinforce commitment to the project and raise awareness across the organization. This type of kickoffcould be an important part of the projects organizational change management approach.

The project manager balances these different types of kickoff meetings to ensure that stakeholder time is optimized and project communicationsneeds are metboth at a team level and an organizational level.

Project ScheduleThe project manager expands and updates the project schedule. At a minimum, the schedule should include the following components:

Phase deliverables and tasks Estimated effort (work) and duration Task dependencies such as predecessors and successors


4/38

Scheduled start and finish dates for each task, based on dependencies Task constraints such as must-start-on date, must-finish-on date, and so on Resources assigned to each task

The project manager uses a rolling wave approach to schedule development to allow the completion of the schedule for the entire project.

InputsProject management is relevant to the entire phase and should start only when the previous phase has been signed off.

Deliverables

Deliverables of this deliverable group are:

Phase start-up Executing, monitoring, and controlling of results Project management plan completion Phase sign-off

1.1.1 Phase Start-Up

Purpose

The purpose of the phase start-updeliverable is to coordinate the setup of an appropriately sized team and to prepare the team for the activitieswithin the phase. This deliverable ensures the involvement and commitment of the team and other key resources to the project schedule. It alsoexamines the approach for the specific project phase.

Note: The phase start-up for the project preparation phase also includes a handover of information gathered in the pre-implementation projectactivities.

The phase start-up involves:

Identifying, allocating, and coordinating resources for the team and phase activities

Creating, expanding, and updating the project schedule for the phase (consider using a rolling wave approach to schedule development)

Preparing for and conducting a phase kickoff meeting and starting the phase project work

InputsThe inputs for the phase start-up include information from any previous phase sign-offs.

DeliverablesThe project management phase start-up generates these deliverables:

Allocation of resources to the project team for the specific phase Updated detailed phase schedule Completed phase kickoff meeting

1.1.1.2 Definition of Project Organization, Roles, and Responsibilities

PurposeThe purpose of this activity is to define the organizational structure, roles, and responsibilities of the project team. To complete this activity:

Review the project charter and scope Identify the project and business process areas to be addressed as part of the project and get a feel for the size of the team Determine the project team structure Review the project team structure with the program manager for approval Define roles and skills required for team members

InputsThe inputs to this task are:

Handover information from the opportunity management phase Work breakdown structure with role assignments from the ASAP methodology roadmap

SubdeliverablesThe deliverables from this task are defined project organization, roles, and responsibilities.

Additional Information

If the project scope includes applications based on service-oriented architecture (SOA), ensure in an early stage of the project that the customerprepares for SOA readiness. Further guidance on this topic is provided in Run >> Governance Model for OrganizationOptimization >> SOAReadiness (see also the linked node).


5/38

1.1.1.3 Phase Resources Allocation

Purpose

The purpose of phase resources allocation is a confirmation of resource availability for the particular phase. The resource plan andscheduledetail the resource requirements, but in the start of each phase you need to ensure the proper timing of resource assignments needed tocomplete project work.

1.1.1.4 Assignment of Roles and Responsibilities

PurposeThe purpose of this deliverable is to identify and select global company and external resources for the project in accordance with the requiredroles, skills, and responsibilities specified in the preceding task. The assignment of people to roles should also take into account their qualificationsand availability for the whole project time frame.Care should be taken to fill these positions with the most capable people in the company.To assign roles and responsibilities: Match company and consulting resources to roles

Company personnel need to fill roles on business process teams. The ratio of company staff to consultants used will vary depending on theavailability of company resources, program managements strategy on the use of consultants, and funding considerations. During a start-upphase of a global program, the development project typically employs one consultant for every three to four company resources. As the

program progresses and knowledge transfer occurs, fewer external resources should be required.External resources are ideally suited to functions that need specialized business process and configuration skills for short durations.Unless IT management is outsourced for strategic reasons, it is advisable to have client IT personnel in the SAP project (see also SAPCustomer Competence Center). Otherwise, it is difficult for the corporate enterprise to properly evaluate different IT strategies andtechnologies.

Assign resources to roles

Inputs

The inputs to this deliverable are the defined project organization, roles, and responsibilities.

Subdeliverables

The subdeliverables are:

The project team organizational chart with assigned people Resources assigned to roles and responsibilities

1.1.1.5 Team Onboarding

PurposeThe purpose of this activity is to prepare the onboarding package for external consultants from SAP and partner companies.The triggers for this activity are:

Defined milestone plan High-level project schedule Organizational chart for the project, showing both internal and external resources Definition of the existing SAP landscape Determination of possible premises for the consultants Travel policies and other project guidelines, if available

InputsThe inputs to this activity are assigned roles and responsibilities.

SubdeliverablesThe subdeliverables from this activity are:

Handover project guidelines (company overview, consultants guidelines, project timeline, and project scope, for example)

Onboarding package

1.1.1.6 Phase Kickoff Meeting

PurposeThe phase kickoff meetinghelps ensure the involvement of the team and other key resources and their commitment to the project schedule. Themeeting is also used to examine the approach for the specific project phase.

The scale of this activity varies with project size and complexity. For small, low-risk projects, this may be an informal review of the process by theproject sponsor and the program or project manager. For larger projects, consider a formal kickoff of the project to achieve a commonunderstanding of the objectives of the planning process and to clarify the various participants roles.

The project manager must clearly define theobjectives of each phase kickoff meeting and design the agenda to achieve that objective. Considerconducting the following types of meetings:


6/38

Team-focusedmeetings should be focused on team members to ensure alignment around the work (definition and approach for outputs)to be performed during the phase.

Communications-focusedmeetings should be focused more on communications across the organization, bringing the project sponsorand key stakeholders together to reinforce commitment to the project and to raise awareness. This type of k ickoff could be an importantpart of the projects organizational change management approach.

The project manager balances these different types of kickoff meetings to ensure that stakeholder time is optimized and project communications

needs are met -- both at a team level and an organizational level.

InputsThe inputs for the phase kickoff meeting include information from any previous phase sign-offs.

SubdeliverablesThis step generates:

Project team ramp-up training (ideally conducted before the blueprint phase) Allocation of resources to the project team for the specific phase Updated detailed phase schedule Completed phase kickoff meeting

1.1.2 Project Initiation

PurposeThe purpose of this project initiationdeliverable is to formally recognize that a new project exists. It supports the decision to accept the project,align stakeholderssuch as clients, customers, and SAP managementaround a project and its scope, provide updated information for planning,and obtain a commitment to proceed. It ensures alignment between SAP, the customers strategic direction, and the satisfaction of operationalrequirements.

InputsThe inputs to this activity are:

Implementation project phases and deliverables SAP solution map and/or SAP business scenario map (output from Solution Composer) Implementation effort estimates based on work packages Final project calculation (PPM) Results of risk assessment in the form of a risk profile statement Definite staffing assumed and availability verified

Proposal documents Value-based solution scope High-level technical architecture Delivery model drafted according to ISD guidelines Business case and/or CVA (optional)

DeliverablesThe deliverables generated from this activity are:

Project charter

Scope statement Business case Schedule for project planning Project manager agreement

1.1.2.1 Business Case

PurposeThe business caseidentifies expected benefits and balances them against the strategic direction and costs. It provides the economic justificationfor the proposed project and documents how and when the investment will be profitable for the customer. Information included in the businesscase is the essential business reason for this project, the costs, and the benefits. The business case is a key input for the Value Roadmap.

InputsIn creating the business case, consider the following inputs:Section Key Content Inputs

Objective What business need the project issolving

Customer business case

SAP business case, valueassessment, orbusiness assessment

SAP collaborative value assessmentProblem andOpportunity

As-is situation

ProposedResolution

To-be situation Statement of work (SOW)

Proposal


7/38

Strategic Alignment Customer business strategy andtechnical strategy



SAP collaborative value assessment

Benefits Tangible and intangible benefits Customer business case


SAP collaborative value assessment SAP value map from the SAP Value

Delivery Management portfolio of services

InvestmentAppraisal

Cash inflows

Cash outflows

Discount rate




Dependencies Geographic and organizationalscopepeople, associatedlocations, languages, andorganizations affected or impactedby the proposed solution




SAP value map SOW

Proposal

Affected Systems System scopesystems andassociated locations affected orimpacted by proposed solution




SOW

Proposal

Stakeholders Starting with C-Level management Company fact sheet

SAP value map

SAP has developed two platforms to accelerate the creation and development of project business cases: SAP Value Lifecycle Manager and SAP

Benchmarking program.

SAPs Value Lifecycle Manager (VLM) is an online business-case building platform with over one million datapoints (best practices and valuedrivers) covering more than 70 sub-industries. VLM has industry and solution specific Business Case templates that can significantly reduce theeffort required to complete the analysis and produce a deliverable.

SAPsBusiness Performance Benchmarkingwas developed in conjunction with users groups and industry associations, the program identifiesKPIs and best practices that can be deployed to help companies diagnose business performance and to develop high-impact recommendationsfor improvement. Established in 2004, SAPs initiative is now one of the largest benchmarking programs in the industry, including more than10,000 participants from more than 3,000 companies.

Subdeliverables

This activity generates a reviewed and approved project business case that is documented and communicated to the project team. It also providesthe foundation for value based scoping or value roadmap. A Value Roadmap aligns the project scope and implementation sequence to operationaland strategic goals optimizing time-to-value.

If It Is Not Done

The business case is the central controlling instrument for value delivery during the project. If this step is skipped, the primary business objectivesand customer expectations cannot be measured at the end of each project phase. It is important for customers to assess their business objectivesduring the review of project deliverables at the end of each phase closure and realize that their expectations are being met. Without a businesscase there would not be a record if the project was successful based on the value dimension and there is a high risk that the full value potential ofthe project cannot be reached.


For further information, refer to: Business Transformation Services group services: business case, value assessment, and business assessment service; collaborative value

realization service; and value roadmap

SAP value engineering tools and services: SAP Value Lifecycle Manager, SAP Benchmarking Program and collaborative value assessment

service PMBOK

Fourth Edition, Chapter 4, Project Integration Management

Adapted from PMBOKFourth Edition, Chapter 4, Project Integration Management 2008 Project Management Institute


8/38

1.1.2.2 Project Charter

PurposeThe project charter is developed by reviewing documents from the pre-project negotiationprocess and through interactive meetings with thecustomer to facilitate an understanding of the projects goals, business case, external assumptions, and constraints. The project charter clearlyand explicitly defines the objectives of the proposed project, analyzes all possible benefits, and quantifies benefits in financial terms. Thisinformation and supporting documents align key stakeholders around the strategic intent of the project.

InputsWhen creating the project charter, consider the following inputs:

Section Key Content Inputs

Project Overview Current, as-is situation and business needs

Proposed resolution, to-be situation, and high-level summary of what the project will deliverfrom an organizational, functional, technical, andgeographic point of view

Project business case

Statement of work (SOW)

Project Scope Characteristics of the solution or service that theproject was undertaken to create; note out-of-scope organizational, functional, process, anddevelopment objects (such as data cleansing),

and technical applications Overall project goal

SOW

Proposal

Project Objectives SMART (specific, measurable, attainable, relevant,and time-bound) aims of the project derived fromrequirements, benefits, project needs, and measuresof success aligned to corporate and organizationalstrategies and the project goal

SOW

Proposal

Deliverables Produced by the team to ensure project success SOW

Proposal


Business CaseSummary

Summary of justification for project, return oninvestment (ROI) and related key performanceindicators (KPIs)


Value BasedRoadmap

Proposed sequence of projects and programs that isrequired to achieve strategic and operational goalsand optimize the time to value


On-going initiatives

Total EstimatedProject Costs

Estimated total project costs through closing SOW

Proposal


ImplementationStrategy

The approach selected for the project based on theanalysis of solution options during the evaluationphase

Proposal

Prestudy

Project Planning A summary level schedule (chart or graph) with high-level dates that identifies the major ASAPmethodology milestones related to phases and valuedelivery

SOW

Proposal

ProjectStakeholders Persons or organizations actively involved in theproject or whose interests may be positively ornegatively affected by execution or completion of theproject

Project business case SAP value map from the

SAP Value DeliveryManagement portfolio ofservices

Assumptions Factors that are considered to be true, real, orcertain without proof of demonstration and projectlimits

SOW

Proposal


SAP value map

Constraints Factors that limit options and are beyond the controlof the project team, resulting in a state, quality, orsense of being restricted to a given course of actionor inaction

SOW

Proposal


SAP value map

Risk Assessment Factors that may have a negative impact on theproject Proposal SAP risk assessment

Approval Approval from the program sponsorthe keyindividual, person, or group that provides financialresources to the project

Signatory authorization

SubdeliverablesThis activity generates a reviewed and approved project charter that is documented and communicated to the project team.

If It Is Not DoneIf you skip this step, the project is not formally approved by the customer sponsor and the project manager is not authorized to applyorganizational resources to project activities.


9/38

Additional InformationAssess whether the customer has existing: Organizational policies and procedures, standard product and project lifecycles, and quality policies Standardized guidelines, work instructions, and proposal evaluation criteria Guidelines and criteria for tailoring the organ izations set of standard processes to satisfy the specific needs of the project Organizational communication requirements, such as record retention and security requirements Procedures for issue and defect management, including controls, identification and resolution, and action item tracking Change control procedures, including the steps by which the company modifies, approves, and validates official company standards, policies,

plans, and procedures as well as project documents Risk control procedures, including risk categories, probability definition and impact, and probability and impact matrix

For further information, refer to PMBOKFourth Edition, Chapter 4, Project Integration Management.


1.1.2.3 Scope Statement

PurposeThe scope statement facilitates an initial understanding of the project scope and associated project-related assumptions and constraints. Theproject scope statement evolves through the initiation and planning of the project and clearly and explicitly defines the deliverables of the proposedproject. This information and supporting documents align key stakeholders around what the project is going to deliver.

InputsIn completing the scope statement, consider the following inputs:

Section Key Content Inputs

Project Goal To-be process describing the overallgoal to be achieved by the project


Project charter

Solution or ServiceDescription

Detailed summary of organizational,functional, development, technical,geographic, and language scope

Statement of work(SOW)

Project Requirements Documentation of the capabilities orconditions that must be met by the project

SOW

Proposal

Project Objectives Customer strategies (corporate andorganizational) aligned with project goals

Validated Business Case Proposal

Deliverables Key deliverables produced by the team toensure success

SOW

WBS

Project Boundaries List of specific systems (SAP andcustomer applications) within the projectscope

SOW

Out of Scope Notation of out-of-scope organizational,functional, process, and developmentobjects (such as data cleansing forconversions), and technical applications

SOW

Proposal

Project Assumptions Items or factors that are considered to betrue, real, or certain without proof ofdemonstration and project limits

SOW

Proposal

Project Constraints Factors that limit options and that arebeyond the control of the project team,resulting in the state, quality, or sense ofbeing restricted to a given course of actionor inaction

SOW

Proposal

Project RiskAssessment

Risks that may have a negative or positiveimpact on the project

SOW

Risk register

ImplementationStrategy

Description of the ASAP methodology andapproach for implementation

SOW

ASAP methodologydescription

Initial Work BreakdownStructure (WBS)

Decomposition of deliverables WBS

Project Organization Project organizational chart of individualsand organizations that have specific rolesin the project team

Human resource

management plan

Acceptance Criteria Scope verification process Scope management plan

Schedule Milestones Key project milestones and dates SOW

Order of MagnitudeProject Costs

Estimated total project costs throughclosing

SOW

Business Benefits Validated business benefits associatedwith the implementation program

Validated Business Case(including Value Maps,Value Enablers, KPIs,PPIs)

Configuration The approach for documenting product Integrated changecontrol plan


10/38

ManagementRequirements

characteristics and integrated changecontrol

Project Costs Neededto Proceed

Estimated project costs required to moveto the next phase

Project cost and effortestimate

Approval Approval from customer project sponsor,customer key stakeholders (if applicable),customer and SAP project managementteam, and customer and SAP team leadsto manage organizational, functional,

development, technical, and geographicscope in the next phase of the projectimplementation

Signatory authorization

DeliverablesThis step generates a reviewed and approved scope statement that is documented and communicated to the project team, enabling integratedchange control.

1.1.2.4 Schedule for Project Planning

PurposeThe schedule for project planning covers all project planning activities for the entire project, including identification of milestones, quality gates,and end dates, as well as estimated costs and budgets. The schedule for project planning includes all scheduled tasks, resources, and start andend dates for all activities that will be performed during the planning of the project.The project manager builds on this schedule during subsequent planning activities, using a rolling wave approach.

Schedule Development (Rolling Wave)During the project preparationphase, the team details the schedule that takes team members through to the end ofthebusiness blueprint phaseonly (that is, the planning phase approval checkpoint). Activities in later phases are definedand scheduled during the business blueprint phase, using a rolling wave approach, which enables the completion of theschedule for the entire project. Using this approach, the planning team develops schedule details for the next phase (forexample, the realization phase) and schedules subsequent phases. Replanning points are scheduled toward the end ofeach phase (as detailed information for the next phase becomes available) to update the schedule in preparation for thenext phase.

Inputs

The inputs to the schedule for project planning are: Project charter

Scope statement

SubdeliverablesThis step generates the detailed project schedule.

1.1.3 Project Management Plan

Purpose

The purpose of the project management plan definitiondeliverable is to develop the project management plan and the subsidiary plans on thebasis of the project scope defined in the project charter. This includes the development of the project schedule, the budget, and appropriateupdates to the business case.

The project management plan is a comprehensive document (or collection of documents) that includes the schedule, cost information,monitoring/controlling plans for each of the nine knowledge areas of the project management body of knowledge (PMBOK), and other information,as appropriate.

The subsidiary management plans developed for each of these areas provide the foundation to support the consistent application of projectmanagement practice:

Integrated change controlprovides a method of controlling and monitoring project changes. Change is defined as any activity that alters the

scope, schedule, deliverables, value, or costs of the project.The issue management procedureprovides a method of managing and resolving project issues. An issue is a situation, action, problem, orquestion arising during the project, that the project team cannot resolve efficiently or effectively.

The scope management planoutlines the processes required to ensure that the project includes all of the work required, and only the workrequired, to complete the project. The scope management plan elaborates on sections of the project management plan that pertain to thefunctions of scope management.

The time management planoutlines the processes required to ensure timely completion of the project. It elaborates on sections from the projectmanagement plan that pertain to the functions of time management.

The cost management planoutlines the processes required to plan, estimate, budget, and control project costs. It elaborates on sections of theproject management plan that pertain to cost management.


11/38

The quality management planoutlines the specific organization, processes, and services needed to ensure quality on the project. It elaborateson sections of the project management plan that pertain to quality management.

The human resource management planoutlines the processes required to staff, organize, and manage the project team. It elaborates onsections of the project management plan that pertain to human resource management.

The communication management planoutlines the processes required to ensure timely generation, distribution, storage, and retrieval of projectinformation. It elaborates on sections from the project management plan that pertain to communication management.

The risk management plandefines how risks are identified, analyzed, review, and managed. It describes how often risk reviews are conducted.

The project contract inventorycontains all contractual agreements with product and service providers for the project. For an implementationproject, this may include contractual arrangements with hardware providers, organizational change management, training, hosting, off-shoredelivery, and application management service providers, for example.

InputsThis deliverable includes the following inputs:

Project charter Handover from proposal or preproject activities Statement of Work (SoW) Customer policies, procedures and guidelines Assigned roles and responsibilities Stakeholder Analysis Applicable templates

DeliverablesThis deliverable generates the following outputs:

Project management plan and subsidiary plans Project schedule Project budget


For further information, refer to PMBOKFourth Edition, 2008 Project Management Institute

1.1.4 Executing, Monitoring, and Controlling of Results

Purpose

In directing and managing project execution, the project managers and the project team perform multiple actions to execute the projectmanagement plansto accomplish the work defined in the project scope statement.

In executing project work, the project team:

Performs activities to accomplish project objectives Expends effort and funds to accomplish project objectives Staffs, trains, and manages the project team members assigned to the project Obtains, manages, and uses resources Implements and executes the planned methods and standards Creates, controls, verifies, and validates project deliverables Manages the scope of the approved work Manages risks and implements risk response activities

Manages issues to closure Adapts approved changes to the scope, plans, and project environment Establishes and manages internal and external communications Collects project data and reports progress and performance

In monitoring and controlling project work, the project team:

Compares actual project performance against the project management plan Assesses performance to determine whether corrective or preventative actions are needed Monitors and controls project risks Provides metrics to support progress and performance reporting and forecasting Monitors implementation of approved changes

Management plans developed during the project preparation phase (see Project Management Plan Definition) guide the team's approach tomanagement, execution, and control of project activities. The project manager is responsible for ensuring that management plans are applied atthe appropriate level of control.

InputsThe inputs to the executing, monitoring, and controlling of results are:

Project initiation documentsThe project initiation documents (business case, project charter, project scope statement) describe the project in terms of objectives,scope, stakeholders, and project influences (risks, assumptions, and constraints).

Management plansThe management plans detail specific activities for each of the nine project management body of knowledge (PMBOK) areas. These plansprovide the foundation to support the consistent application of project management methods across the SAP project organization basedon the project scope.

Project scheduleThe detailed project schedule defines the work to be performed, what resources and associated time commitments are required for the


12/38

project, and its phases. The work breakdown structure (WBS) is the foundation for the schedule and documents the deliverables to beproduced as part of the project. The resource and t ime commitment estimates can be used to calculate end dates and costs.

Project budgetThe project budget outlines all of the costs associated with the project, including labor, hardware, software, contracting fees, and facilities.

Project charter

DeliverablesThe outputs of this deliverable are:

Project performance reports, including: Team member status reports Project status reports Executive status reports Quarterly operations reviews

Project budget updates Approved change requests Change control log updates Issue log updates Refined WBS and WBS dictionary Project schedule and blueprint workshop schedule Requests for change Scope statement updates Scope verification matrix updates Project schedule updates Risk register updates Communication matrix updates Team member evaluations (non-SAP resources) Team member appraisals (SAP resources)

Additional InformationFor further information, refer to PMBOK

Fourth Edition, Chapter 4, Project Integration Management.


1.1.4.1 Project Performance Reports

PurposeThroughout the project, a number of project performance reports need to be produced for different purposes and audiences, as defined intheproject communication plan.

Inputs

The inputs to project performance reports are: Communication management plan Interim team member status reports Interim project team status reports Interim project status reports Interim executive status reports

Subdeliverables

This step generates: Team status reports, using the team status report template

Project status reports, using the project status report template Program status reports, using the status report program template

1.1.4.2 Project Budget

PurposeThe project budget, including monitoring and control,outlines all costs associated with the project, including labor, hardware, software,contracting fees, and facilities.

Inputs

The inputs to the project budget are: Project charter

Cost management plan

SubdeliverablesThe outputs of a project financial management tool are:

Detailed information on contracting fees and associated travel expenses Approved project budget baseline


13/38

1.1.4.3 Change Request Log Updates

PurposeA consistent, comprehensive approach to managing the lifecycle of a potential change is a critical component of an integrated change controlsystem. The change request form enabling the change control procedure must support the multiple levels of analysis and approval required todeal with a requested change. For tracking purposes, all change requests are logged in a change request list.

InputsThe change request form supports the execution of the integrated change control procedure.

Subdeliverables

This step generates: Disposition of change requests in accordance with the integrated change control process. Updated change request list

Additional InformationWhen dealing with change request management for the implementation project, it is recommended that you define operational changemanagement procedures. Further guidance on this topic is provided in Run >> Change Management >> Change Request Management/ChangeControl Management (see also linked nodes).

1.1.4.4 Issue Log Updates

PurposeA consistent, comprehensive approach to managing project issues is a critical component of an effective project management system. The SAPSolution Managerapplication management solution (or an issue log, if SAP Solution Manager is not available in your project) supports the issuemanagement procedureby enabling the multiple levels of analysis and decision making required to deal with an issue. The issue report in SAPSolution Manager (or issue log) is a formal record of all issues raised for the project. Effective issue management involves the appropriate level ofmanagement making decisions on issues and tracking progress on issue resolution in accordance with the project issue managementprocedure. The issue log is formally closed out with other project controlling documentation during project completion activities.

InputsThe SAP Solution Manager or issue log supports the execution of the issue management procedure.

SubdeliverablesThis step results in the disposition of project issues in accordance with the issue management procedure.

1.1.4.5 Work Breakdown Structure and Dictionary

Purpose

The work breakdown structure (WBS)is a deliverable-oriented, hierarchical decomposition of the work to be executed by the project team tocomplete the project. It is the basis for the organization and coordination of the project. A WBS consists of WBS elements that describe projecttasks and subtasks to perform within a defined time period.

Inputs

The inputs to the WBS are: Project charter Statement of work Business case and value map (if available) Scope management plan template WBS template (from the opportunity managementphase)

Subdeliverables

This step generates a reviewed and approved first WBS as well as a WBS dictionary, which are documented and communicated to the projectteam.

If It Is Not Done

Skipping this step limits visibility and control in managing scope and integrated changes; this can adversely impact the schedule, budget, value,and quality of the project.


For further information, refer to PMBOKFourth Edition, Chapter 5, Project Scope Management.

Adapted from PMBOKFourth Edition, Chapter 5, Project Scope Management 2004 Project Management Institute


14/38

1.1.4.6 Project Schedule and Blueprint Workshop Schedule

PurposeThe detailed project scheduledefines the work to be performed, the resources and associated time commitments required for the project, andthe phases of the project. The work breakdown structure (WBS)serves as the foundation for the schedule and deliverables to be produced aspart of the project.

At a minimum, the schedule should include: Deliverables and tasks for the current phase Estimated effort (work) and duration Task dependencies (such as predecessors and successors) Scheduled start and finish dates for each task, based on dependencies Task constraints (such as must-start-on date and must-finish-on date) Resources assigned to each task High-level schedule for subsequent phases

The project manager further elaborates this schedule during subsequent planning activities, using a rolling wave approach.Use the time management plan template, in consultation with the customer project manager, to define an appropriate time management plan forthe project.

Inputs

The inputs to the project schedule are: Time management plan template Project charter Project scope statement WBS template (from the opportunity managementphase) Customer policies, procedures, and guidelines

SubdeliverablesThis step generates a refined time management plan with a blueprint workshop schedule.

Additional InformationFor further information, refer to PMBOK

Fourth Edition, Chapter 6, Project Time Management.

Adapted from PMBOKFourth Edition, Chapter 6, Project Time Management 2004 Project Management Institute

1.1.4.7 Project Risk Register Updates

PurposeThe purpose of the project risk register isto document the risks affecting a project and the strategies chosen by the project team to managethem. The project risk register details the following information (note that this is not an exhaustive list of all project risk data types):

Basic project information including project name, customer name, project purpose, and key participants

Risk title (name) Condition

Indicator Consequence

Impact Owner

Expected loss Response type etc.

Inputs

The inputs to the project risk register update are: Project management plan

Risk management plan Project risk list with identification of risk management roles (responsible, accountable, consulted, informed)

SubdeliverablesThis step generates the project risk register update, a comprehensive view of project risk, impact, and response strategies adopted by the projectteam.

If It Is Not DoneIf the project risk listis not created and managed, the project team will not have a complete picture of project risks, impacts, and responsestrategies. The lack of this important document will likely result in cost overruns, project delays, and customer dissatisfaction due to ineffectiveresponses to risks.

1.1.4.8

Communication MatrixPurposeThroughout the project, as more is known, the communication matrix should be reviewed and updated. The communication matrix documentsthe project teams approach to communication. It captures the analysis completed as part of communications planning and serves as a tool toguide the project team throughout the project.The matrix holds the following information for each communication:

Communication reference number

Target audience (stakeholder) analysis, including:

o Audienceo How the audience is impactedo How the audience will be engaged


15/38

Communications planning, development, and delivery, including:

o Communication event

o Message intento Timingo Vehicleso Sendero Feedback mechanism

o Comments

Project communication typically falls into one of two primary categories: internal project communications or stakeholder communications.

Inputs

The inputs to the communication matrix are:

Communication management plan

Stakeholder analysis

Subdeliverables

This step generates a reviewed and updated communication matrix.

1.1.4.9 Team Member Evaluations and Appraisals

PurposeAs part of the human resources management of the project, the project manager manages and develops the team, including evaluatingperformance. You should introduce the concept of team member evaluations and appraisals when new members join the team, to discussperformance development opportunities and objectives for the individual while on the project. This information needs to be recorded for referenceand reviewed during a final meeting before the team member leaves the project.

Inputs

The inputs to team member evaluations and appraisals are: Additional appraiser template

Feedback from the customer program manager, project manager, and subproject manager

SubdeliverablesThis step generates internal and external appraisals.

1.1.5 Project Standards

Purpose

Project standardsprovide a consistent means of executing and governing project work in an efficient and effective manner. Their key objective isto identify, define, approve, and communicate standards related to project execution.

Project standards are elaborated throughout the project initiation and planning phases. During the project preparationphase a subset of theproject standards must be defined, approved, and communicated to the project team. Communication of project standards should be included inproject onboarding communications and phase start-up meetings. Given the integrated nature of project standards, changes must be managed inaccordance with the integrated change control procedure.

Inputs

The inputs to project standards are:

SAP Solution Manager usage guidelines Business process modeling standards Initial development management standards SAP Services deployment plan Software system configuration standards Enhancement and modification standards Support package and upgrade standards

Change request and transport management standards Test management standards Postimplementation service and support standards Enterprise service standards Composite application design and development standards

Subdeliverables

This step generates documented, approved, and communicated project standards in accordance with the integration management plan.


16/38


SAP has defined the following ALM processes. More information on these processes can be found at SAP Service Marketplace(http://service.sap.com/ALM).

Find below a high level mapping of ALM phases and SAP Standards for Solution Operations.

ITIL ALM Phase SAP ALM Process SAP Standard for Solution Operations

Requirements Solution Documentation Solution Documentation

Design Solution Implementation Test ManagementTemplate Management

Build & Test

Test Management Test Management

Change Control ManagementChange Management (Change RequestManagement, Change ControlManagement)

Deploy Application Incident ManagementIncident ManagementRemote SupportabilityRoot Cause Analysis

Operate

Technical OperationsSystem AdministrationSystem MonitoringRoot Cause Analysis

Business Process Operations

Exeption Handling & Business Process &Interface MonitoringJob Scheduling ManagementData Integrity and Transactional

CorrectnessData Volume Management

Optimize

Maintenance Management Change Management

Landscape Transformation

Upgrade ManagementChange ManagementUpgradeData Volume Management

Not assigned Security

1.1.5.1 SAP Solution Manager Usage Guidelines

PurposeThe purpose of the SAP Solution Manager usage guidelinesdeliverable is to define and set up a structured way for the SAP Solution Managerapplication management solution to support a standard SAP implementation project to the best effect in the preparationphase. The SAP SolutionManager usage guidelines include the setup of a project in SAP Solution Manager and provide the project team with the definition of fundamentalproject standards including naming conventions, document types, status values, and authorization concepts.

InputsThe inputs for the SAP Solution Manager usage guidelines are:

Project team organization Project standards System landscape

SubdeliverablesThis step sets up the project in SAP Solution Manager, including a definition of project standards.

Expected ResultsBy completing the SAP Solution Manager usage guidelines subdeliverable correctly, the project will gain a fundamental basis for standards in theproject and align them to SAP Solution Manager.

Additional InformationThe SAP Solution Manager usage guidelines refers to document types and corresponding templates to be used in SAP Solution Manager. Thesecan be found in an attached accelerator.

When defining documentation standards for various documentation needs during the implementation project (for example, project documentation,configuration documentation, enhancement and modification documentation) it is recommended that you define and prepare for as well as cross-check the SAP standards for solution operations. Further guidance on this topic is provided in Run >> SAP Application Management >>Solution Documentation (see also linked nodes).

Furthermoreyou find one service link to Expert Guided Implementation. Expert-guided implementation is a new optimized, short-term setupservice to configure basic settings for SAP Solution Manager without long-term, in-house consulting. This service balances the combination of

training, practical experience, and expertise on demand and allows customer to create ready-to-use baseline functionality for implementation ofend-to-end solution operations.

1.1.5.2 Business Process Modeling Standards

PurposeThe purpose of business process modeling standardsis to have a standard approach for executing process modeling. SAP provides astandardmodeling handbook, which delivers the rules for process-oriented analysis and design. This handbook is meant as a generalguideline for everybody who does work on either:

Process modeling Service modeling
http://service.sap.com/ALMhttp://service.sap.com/ALM


17/38

The modeling handbook also gives information about the integration between: ARIS software and SAP Solution Manager ARIS and the Enterprise Services Repository (ES Repository)

The handbook provides comprehensive definitions and is strictly focused to deliver process modeling guidelines that are clear and directly

applicable in project work.

The process modeling tool used for the modeling guidelines is ARIS; it should be seen as an example. Thus, the definitions, shapes, and stencils

provided can be transferred to any other process modeling tool easily; an example is given for Visio. Please view the SAP Modeling Handbookon

the Business Process Expert (BPX) community Wiki site.

Inputs

The inputs to the business process modeling standards are: Project scope Basic business scenario Process inventory

Subdeliverables

This step generates: Business scenario documents Business process documents Process flow diagrams

By completing the business process modeling framework deliverable correctly, the project gains a fundamental basis for process modeling andservice modeling standards.

When defining business process modeling standards, it is recommended that you define and prepare for as well as cross-check the SAP solution

documentation: SAP standards for solution operationswith respect to business process modeling. Further guidance on this topic is provided inRun >> SAP Application Management >> Solution Documentation (see also linked nodes).

1.1.5.3 Initial Development Management Standards

PurposeWith the increasing number of systems and technologies, the complexity of IT solutions is rising. The key to successful landscape planning andoperation is an accurate and complete description of the solution landscape itself with all business processes. All reporting is based on thisfundamental information.

As part of SAPs standards for end-to-end solution operations, the standard for solution documentation describes in general how customersachieve the required transparency of their SAP solution. On one hand, minimal documentation as described in this subdeliverable lays the groundfor leveraging many operations support functions offered via SAP Solution Manager (for example, identifying affected custom business processes

or customizing change requests). On the other hand, it is important to have the documentation in a standardized location and format to ensure theoptimal delivery of SAP support services. To enable SAP to deliver services for custom projects especially, a minimum amount of documentationis required. This subdeliverable describes the required content of this documentation as well as the tools and formats to be used to deliver it.

InputsThe input to initial development management standardsare the best practices and recommendations for SAP custom development standards.

SubdeliverablesThis step generates customer-agreed standards for custom development. By completing the deliverable correctly, the project gains guidelines forcreating custom development documentation, enabling future services and upgrades.


When defining documentation standards for various documentation needs during the implementation project (such as project documentation,configuration documentation, and enhancement and modification documentation), it is recommended that you define and prepare for as well ascross-check the SAP solution documentation: SAP standards for solution operations. Further guidance on this topic is provided in Run >> SAP

Application Management >> Solution Documentation (see also linked nodes).

1.1.5.4 SAP Services Deployment Plan

PurposeManaging complexity, risk, and costs as well as skills and resources is at the heart of implementing mission-critical support for SAP-centricsolutions. The complexity rises even further with the trend of out-tasking and outsourcing process components. To help customers manage theirSAP-centric solutions, SAP provides a comprehensive set of standards for solution operations.

Out of this set of standards, the system administration standard describes processes for the administration of SAP-centric solutions. The termsystem administration encompasses all activities that ensure the successful, long-term operation of a solution from a technical perspective. Therange of activities that can be included in the broadest sense of system administration is therefore very extensive. As usual in this context, themain areas of system administration are treated separately. Procedures for data management, change management, and incident management,for example, are explained in separate documents. This document provides an overview of the various regularly-occurring standard systemadministration tasks and associated tools.

Over the course of evolving to service-oriented architecture (SOA) solutions, vertical system administration based on a technical system gives wayto horizontal system administration based on processes. Consequently, the different subject areas in system landscape administration must becombined and provided in a central location. The platform for this is SAP Solution Manager.

Inputs

The input to the SAP Services deployment planis the SAP Services deployment process.


18/38

Subdeliverables

This step generates:

SAP Services deployment plan

System administration guidelinesBy completing the SAP Services deployment plan correctly, the project gains guidelines for deploying system administration services.

1.1.5.5 Software System Configuration Standards

PurposeThe purpose of the software system configuration standardssubdeliverable is to establish standards for SAP software system configuration forthose who perform initial configuration setup. The system configuration is a crucial part of SAP software implementation, so only selectedgroups should have access and authority to make any changes to the SAP software configuration. The defined standards must follow the SAPinstallation guides and best practices but should also take into account already established principles for existing systems.Software system configuration standardsmust provide guidelines for software installation as well as specifications for the initial systemadministration and system monitoring configurations.

InputsThe inputs to the software system configuration standardsfrom the project are:

Project standards guide Standard installation guides and best practices guides

An overview of the standards and naming convention in the existing infrastructure is required to adapt the project landscape to the existing

landscape: Naming conventions for systems and software Customer-specific standards for system configuration (hardware, operating system, and software) Documentation requirements

SubdeliverablesThe software system configuration standardsgenerate:

Naming conventions for operating system setup Documentation of standards for hardware and operating system setup Naming conventions for software installations Documentation of standards for software installation Specification of configuration requirements for system monitoring

Specification of standard configurations for system administrationAdditional Information

Accelerators giving guidance on how SAP system configuration standards are applied using SAP Solution Manager can be found via the linkednodes.

When defining documentation standards during the implementation projectincluding project, configuration, and enhancement and modificationdocumentationit is recommended that you define, prepare for, and cross-check the SAP solution documentation: SAP standards for solutionoperations. Further guidance on this topic is provided in Run >> SAP Application Management >> Solution Documentation (see also linkednodes).

1.1.5.6 Enhancement and Modification Standards

PurposeCustom development, enhancements, and even modifications of SAP software are not rare at companies today. They are implemented to extendthe functionality of SAP standard software and to adjust it to the company-specific needs and business processes. This is often needed andlegitimate.

But over time, such changes often become major cost drivers and performance bottlenecks. Additionally, custom code is developed despite thepotential for standard enhancements, often due to insufficient information about standard functionality provided by SAP. In addition, custom codecan become obsolete over time though still maintained. And finally, poor software quality often causes problems in production environments anddrives costs for improvement and adaptation.

All these are reasons for implementing sustainable custom code managementin your organization. Custom code management is the processof constant examination and optimization of the four dimensions of custom code: quantity, quality, technical severity, and business criticality, aswell as the preparation and adoption of SAP custom development for daily operations and support. Thus, enhancement and modificationstandardsprovide a holistic view of custom development from the operations perspective, not from the development itself. The topics andmethodology described in this subdeliverable are oriented purely to the ABAP programming language.

InputsThe inputs to enhancement and modification standards are best practices and recommendations for enhancement and modification standards.

Subdeliverables

This step generates: Customer-agreed enhancement and modification standards SAP custom code management procedures


If the project scope includes custom code development, it is recommended that you ensure in an early stage of the project that the customerdefines and prepares for custom code management. Further guidance on this topic is provided in Run >> Custom Code Operations >> CustomCode Management (see also linked nodes).


19/38

1.1.5.7 Support Package and Upgrade Standards

PurposeManaging complexity, risk, and costs as well as skills and resources is at the heart of implementing mission-critical support for SAP-centricsolutions.The complexity rises even further with the trend of outsourcing process components. To help customers manage their SAP-centric

solutions, SAP provides a comprehensive set of standards for solution operations.

In this set of standards, the upgrade standardprovides guidance for holistic and effective quality management of an upgrade project end to end,from its earliest stages of evaluation until after a successful cutover of the productive system. The standard defines the key focus areas, providesguidance, and explains best practices for the management of upgrade projects. All this helps customers better understand and manage the majortechnical risks and challenges of an upgrade project and to make it a non-event for the business.

This subdeliverable provides details regarding the upgrade standard. It explains the basic concept of the standards, describes the seven key focusareas of upgrade projects, and lists and explains the activities within the different phases of a standard SAP upgrade project.

Inputs

The inputs to this subdeliverable are the SAP support package and upgrade standards.

1.1.5.8 Change Request and Transport Management Standards

PurposeThe purpose of change request and transport management standards is to set up and configure the change and transport system (CTS)scenario within fully-controlled change request management. This subdeliverable gives the customer a method for monitoring change requeststhat are in progress or completed in an implementation project and in a production system. It also helps the customer manage and control thetransports that belong to the change request. A controlled change request management process using functionality of SAP Solution Managercontrols the integrated change and transport lifecycle of an implementation project and of a production system landscape.

InputsThe inputs for the change request and transport management standardsare:

CTS standards and procedures for project members SAP Solution Manager technical configuration and setup of the system landscape

SubdeliverablesThis step generates:

Setup and configuration of an enhanced CTS using the change request management functionality of SAP Solution Manager An integrated change request and transport management approach using SAP Solution Manager

By completing this subdeliverable correctly, the project gains an integrated approach to controlling and handling change requests and transportswithin the implementation project and in a productive system landscape by:

Documenting and monitoring all relevant change requests Reducing the number of uncontrolled transports Documenting all transports


When dealing with change request management for the implementation project, it is recommended that you define and prepare for operationalchange management procedures. Further guidance on this topic is provided in Run >> Change Management >> Change RequestManagement/Change Control Management (see also linked nodes).

1.1.5.9 Test Management Standards

PurposeQuality assurance and testing are an integral part of the project and application lifecycle. Within an implementation project, testing follows astructured approach consisting of functional and non- functional test stages.

Functional tests ensure the functional correctness of test objects (Question: Does the system act as expected and according to requirements?)and are typically conducted in multiple stages for every deliverable within the project lifecycle (e.g. unit test, scenario test, end-to-end integrationtest).

Non-functional tests deal with a systems run time behavior, e.g. with defined perfo rmance parameters.

After the successful go-live, testing still remains a central element of the application lifecycle: SAP solutions are changed on a regular basisthrough SAP enhancement packages, support packages, SAP notes or customer-triggered change events, which require customers to test theirbusiness processes thoroughly. Each change has to be tested to ensure that there are no negative side effects.

This subdeliverable describes the SAP standards for test management, which provides SAPs best-practice approach for end-to-end testmanagement. During project preparation, the high-level test strategy for the project should be defined. If possible, the currently employed testmanagement approach should be assessed and adapted for the project.


20/38

Inputs

The inputs to test management standards are:

Operational guideline: test management Test Theory Best practices and recommendations for test management for solution operations Current test strategy / test management approach

Subdeliverables

This step generates a customer-agreed high level test strategy and test management standards.

Additional InformationSee linked nodes for a guideline to assess the current test approach and for further details on setting up the test strategy.

1.1.5.10 Postimplementation Service and Support Standards

PurposeCompanies may recognize that their current IT support organization is not adequate to support an SAP platform. They first need to calibrate theiroverall operational maturity and then develop and execute a plan for a support model at the lowest total cost of ownership (TCO) for the customersatisfaction level defined. For that, SAP offers guidance through support services and defined support standards. The purpose of thissubdeliverable is to start defining the services and standards for the time after the implementation project closes and operational activities becomethe main tasks.

Implementation StandardsThe SAP Active Global Support organizationprovides SAP Enterprise Support servicesthat are a key enabler for integrated, standardized,end-to-end solution operations. The key focus of SAP Enterprise Support is the holistic application lifecycle management of customers softwarelandscapes and applications. In addition, more customer-tailored support is offered through the SAP MaxAttention support optionand SAPSafeguarding services.

Support StandardsCompanies expect high availability and continuity of their solutions, flexibility to quickly implement changes, and low TCO. Additionally, they needto be able to manage out-tasking and outsourcing relationships across different time and geographical zones and to control and monitor service-level agreements. To achieve this, IT governance is key. Companies need an IT strategy that focuses on the management of complexity, risks,

and costs as well as skills and resources. Standardized procedures that leverage the experience of the organization and the software supplier area key prerequisite for the optimization of application management.

InputsThe inputs to postimplementation service and support standards are:

SAP standards for solution operations Current IT support organization capabilities and maturity Business-user service levels and budgetary constraints SAP support services

SubdeliverablesOutput for this step includes:

Results of SAP operation planning assessment (for companies new to SAP) Results of operations maturity assessment (for SAP customers)

Roadmap for conducting support operations design and implementation

1.1.5.11 Enterprise Service Design Standards

PurposeA governance process for enterprise service design and development must be in place before the modeling, definition, and development ofenterprise services can begin. This enterprise services design governance process ensures that all enterprise services are defined according tocertain rules that ensure consistency, standards compliance, harmonization of business semantics, and reuse across all SAP so lutions. Eachenterprise service is subject to a harmonized service cut, aligned naming conventions, consistent documentation, a shared service description,


21/38

and service orchestration. As a result, the enterprise services modeled represent a common language for the business with an optimal level ofgranularity.

Subdeliverables

This step generates enterprise services design standardsthat include the definition of governance rules and a framework for developingenterprise services (design time governance). Key aspects to be considered are:

Service modeling and implementation guidelines

Service development rules (for example, how to ensure item potential) Service documentation rules Service versioning and publication process Service change management (for example, when and how to update clients when the interface of a service changes)

To set up a framework, you need to define processes, roles, and responsibilities for the above topics. The processes should be supported byappropriate tools, templates, and guidelines.

A key tool for supporting the governance of enterprise service modeling and implementation is the central Enterprise Services Repository.

Additional InformationSAP has developed an advanced metamodel and governance process for defining and modeling its ready-to-use enterprise services. The keyconcept in this metamodel is the business object model. Each enterprise service is assigned to a business object that represents a well-definedbusiness entity or document. Each business object is, in turn, assigned to a process component. Process components are units of software thatcover a well-defined set of business tasks that logically belong together and are usually executed in the same department.

When the project scope includes SOA-based applications, it is recommended that you ensure in an early stage of the project that the customerprepares for SOA readiness. Further guidance on this topic is provided in Run >> Governance Model for OrganizationOptimization >> SOAReadiness (see also linked nodes).

1.1.5.12 Composite Application Design and Development Standards

Purpose

The purpose of the composite application design and development standards is to set up the standards to be followed when designing,developing, and deploying composite applications.

Subdeliverables

This step generates:

Development process for the projecto Project development guidelineso Naming conventions (for development components, packages, and so on): The naming convent ions are aligned with the enterprises

naming guidelines for software development. This avoids naming conflicts and ensures clarity.o Logging: This document describes what is to be logged, how it is to be logged (framework/tool to be used), and where the logging data

is to be stored.o Exception architecture: This designates how the application will handle errors. Are the components that cause the error supposed to try

to solve the problem or is the error delegated to the caller? This architecture is closely correlated with the logging concept forpersistent data relating to problems that occur.

Documentation: How is development to be documented? For example, are various document templates or metadata in the code to beused?

Infrastructure list:o VC/Web Dynpro/CAF/Plain J2EE/GP/SAP Interactive Forms software by Adobeo SAP NetWeaver Portal component or other central portalo SAP NetWeaver or third-party development infrastructureo SAP NetWeaver Business Process Management (SAP NetWeaver BPM) component


When the project scope includes SOA-based applications it is recommended that you ensure in an early stage of the project that the customer

prepare for SOA readiness. Further guidance on this topic is provided in Run >> Governance Model for Organization Optimization>> SOA

Readiness (see also linked nodes).

Development ProcessesGreenfield projects are not the norm. It is therefore important to consider guidelines that are already in place and project constraints that aredetermined at enterprise level or by predecessor projects. This ensures consistency with existing projects and processes. Requirements such asthose determined by the Sarbanes-Oxley Act should also be considered.

Organizational StructuresAfter the toolset has been selected, the next step is to organize the development team and, if necessary, to identify and fill in the gaps on their

learning map for the composite development process. Ordering hardware, scheduling training, and building up skills can be a rather time-consuming task (with project-external dependencies), which is why it is important to start early in the project.


22/38

1.1.6 Phase Closure and Sign-Off

PurposeThe purpose of the phase closure and sign-offdeliverable is to:

Ensure that all required deliverables from this phase and the project are complete and accurate, and close any outstanding issues

Identify lessons learned during the phase to prepare for formal project closure

Capture customer feedback and potential Customer References

When sign-off is obtained, the project can be closed.

InputsThis deliverable has the following inputs:

Project documentationincluding status reports, risk and change logs and schedule for the phase

Phase-specific deliverables - Project deliverables are the key tangible products of the project. The team must complete thesedeliverables, and the customer must approve and accept the deliverables prior to closing. The deliverables acceptance is the deliverablethat documents the customers acceptance of the projects deliverables.

Lessons learned- As part of each project management process (or life-cycle phase), the project manager should capture lessonslearned. They should review lessons learned from previous processes and phases, as well as lessons learned from similar projects.

This deliverable is triggered by the completion of the project.

DeliverablesThis deliverable generates:

Lessons-learned log

Project Quality Gate scorecard

Project Management Review report

Phase acceptance and project closure report

1.1.6.1 Lessons-Learned Log Updates

PurposeIt is good project and knowledge management practice to collect knowledge assets and lessons learned at the end of each phase of the project.Collecting documents, experiences, project highlights and lessons learned throughout the duration of the project can help to facilitate the projectby providing quick access and insights into key deliverables from earlier stages of the project.

The quality of the information collected will be higher if collected while the project team is still focused on what happened during a particularproject phase because information will be fresh in the minds of the project team. This knowledge will then continue to live on past the projectscompletion, helping us to ensure we can expedite delivery of future projects more successfully.

DeliverablesLessons Learned Template

The project team collects and documents the lessons learned in the lessons-learned template that is made available to the project team andshared with other projects in the organization.

During the process of collecting lessons-learned, remember to engage SAP (PMO, Consultants, GDC, AGS, Sales, etc.), customers, partners, andany other third party resources who may have been involved with the project. Accurately tracking all resources who work on a project will helpgreatly in this process

1.1.6.2 Project Quality Gate

PurposeThe purpose of the Project Quality Gate is to provide a quality check at critical stages of the project. Project Quality Gates are an integral part ofSAPsQuality Built Inapproach for SAP primed, partner or client led projects. The objectives of the Project Quality Gate are:

To assure that all key deliverables and actions of the gate have been completed in compliance with recommended practices and to thecustomers satisfaction

To enable project management to continuously communicate the process and build quality directly into the project

To provide a tool to effectively manage project expectations and monitor customer satisfaction

Project Quality Gates are defined in the Project Management Plan and are set at critical stages in the project lifecycle. Four quality gates are

mandatory and the other three quality gates are optional as agreed with the customer: Project Preparation Phase -mandatory

Business Blueprint Phase - mandatory

Baseline Configuration - optional

Final Configuration (Solution Built) - optional

Realization Phase (Integration Tests of Realization Completed) - mandatory

Final Preparation Completed (Go Live Readiness) - mandatory

Completed Project (Project Closure)- optional


23/38

InputsThe inputs to this deliverable are the completion of all documents, activities and WBS elements to the satisfaction of the client as identified in theproject WBS.

Expected resultsThe Project Quality Gate delivers a scorecard that records the results of the quality review of each individual key deliverable.

Quality gate is passed. There may be some action items in place in order to complete or improve certain deliverables.

Quality gate is not passed. Action items are defined for follow-up by the project team. Project Manager requests a second assessment to re-evaluate the deliverables with action items.

1.1.6.3 Project Management Review

PurposeThe purpose of Project Management Reviewis to provide a proactive quality assurance review, with an impartial analysis of all aspects of theprojectacross all project management disciplines, enabling early detection of project issues with actionable recommendations.

The Review of Project Management Service is intended for customers implementing SAP solutions. These projects may have SAP as the primeintegrator, SAP playing a support role, or no direct SAP implementation involvement.Review of Project Management Service is an integral part of Quality Built In and provides the following business benefits: Fast identification of implementation risks early in the process to accelerate project delivery Validation that appropriate goals, timelines, and milestones are being met Effective sharing of best practices and recommendations for needed improvements to keep the project on-time and within budget Identification of business opportunities resulting from effective monitoring of the project's progress

The project review service provides consistent quality assurance to protect customer software investment throughout the implementation lifecycle.The service is composed of five logically-sequenced and

asap methodology 1st phase project preparation 38 pages

Documents