SAP Implementation Project Plan (2.4 )

2.4 SAP Implementation Project Plan

Project Name:	TinKu Enterprise Limited (TEL).
Document Name:	Project Plan
Document ID:	NOVAR_PP_1.0			Version:	1.0
Prepared by:	XXXX (Project Manager)	Contact No.	1234	Date:	05.11.01
Reviewed by:	XXXX (Systems Manager, Project Quality Manager & Technical Controller)	Contact No.	4567	Date:	08.11.01
Approved by:	XXXX (Systems Manager & Technical Controller)	Contact No.	4567	Date:	09.11.01
Released by:	XXXX(Project Manager)	Contact No.	1234	Date:	09.11.01

Revision History

Sr. No.	Version No.	Date of Revision	Section Number	Description of  Change	Reason for Change	Change made by	reviewed by

Contents

1. PROJECT INFORMATION.. 4

2. PROJECT DEFINITION.. 4

2.1 BACKGROUND.. 4

2.2 REFERENCES. 4

2.3 OBJECTVIES. 4

2.3.1 CUSTOMER’S OBJECTIVES. 4

2.3.2 OUR OBJECTIVE: 6

2.4 SCOPE. 6

2.4.1 BUSINESS PROCESS SCOPE.. 6

2.4.2 ENTERPRISE SCOPE.. 6

2.4.3 INTERFACE AND APPLICATION SCOPE.. 7

2.5 DELIVERABLES. 7

2.6 APPROACH.. 8

2.6.1 TECHNICAL APPROACH.. 8

2.6.2 PROJECT MANAGEMENT APPROACH.. 8

2.6.3 KNOWLEDGE MANAGEMENT APPROACH.. 9

2.7 ASSUMPTIONS. 9

2.8 CONSTRAINTS. 10

2.9 EXTERNAL DEPENDENCIES. 10

2.10 CRITICAL SUCCESS FACTORS. 10

2.11 ESTIMATION METHODOLOGY.. 10

2.12 RESOURCE REQUIREMENT. 11

2.13 CUSTOMER RESPONSIBILITIES. 11

2.14 CUSTOMER SUPPLIED PRODUCTS. 12

2.15 PROJECT COMPLETION AND ACCEPTANCE CRITERIA.. 13

2.16 BILLING.. 14

2.17 PROJECT ORGANIZATION.. 14

2.18 ROLES AND RESPONSIBILITIES. 14

2.19 STAFFING.. 14

2.20 APPLICABLE PHASES AND SCHEDULE. 14

2.21 PROJECT MANAGEMENT TOOLS. 14

3. QUALITY PLAN.. 14

3.1 DEVELOPMENT LIFE CYCLE OF THE PROJECT. 14

3.2 QA PLAN.. 15

3.3 QUALITY GOALS & OBJECTIVES. 15

3.4 STANDARDS AND GUIDELINES TO BE FOLLOWED.. 15

3.4.1 DEVELOPMENT & DOCUMENTATION STANDARDS. 15

3.4.2 COMMUNICATION STANDARDS. 16

3.5 DEVIATIONS FROM STANDARD PROCEDURE (if any) 16

3.6 DEFECT PREVENTION PLAN.. 16

3.7 REUSE STRATEGY.. 17

4. CONFIGURATION MANAGEMENT PLAN.. 17

4.1 GENERAL. 17

4.2 CM RESPONSIBILITIES: 17

4.3 SCHEDULE FOR CM ACTIVITIES. 18

4.4 BASELINE CRITERIA.. 18

4.5 REQUIREMENT CHANGE MANAGEMENT. 19

4.6 DOCUMENT MANAGEMENT PROCEDURE. 19

5. TRAINING PLAN.. 19

6. TEST PLAN.. 20

7. REPLANNING CRITERIA. 20

8. PROJECT MONITORING AND TRACKING.. 20

8.1 WORK BREAKDOWN STRUCTURE. 20

8.2 PROGRESS STATUS REPORTING.. 20

8.3 PROGRESS REVIEW FRAME WORK.. 20

8.4 ESCALATION METHODOLOGY.. 21

8.5 RISK MANGEMENT PLAN AND STATUS. 21

8.6 ISSUES HANDLING PROCEDURE. 21

8.7 HANDOVER PROCEDURE. 22

SAP IMPLEMENTATION PROJECT PLAN

 

1                    PROJECT INFORMATION

(Give link to / Embed / Refer Project Report filled in for the project

Risk Escalation Level Calculator may be embedded here.)

2                    PROJECT DEFINITION

2.1             BACKGROUND

(This section briefly describes the customer's business and identifies why the project has been initiated. 

[Caution:  do not make broad statements about business benefits (cost savings, increased sales, improved profitability)!])

 2.2             REFERENCES

(This section describes all reference document which form basis for this document. Eg. Reviewed and Approved Proposal / Contract / Service Level Agreement (SLA) / Statement of work, Risks identified during Proposal/Contract, Project Quality Plan (at least in the draft version), Customer Project Schedule (Project Plan), Baseline / Initial documents from Customer if any. Date / version number of the referred documents also should be given. Copy of the documents referred here should be forwarded along with Project Plan while sending it for review. Documents of other projects, Lessons Learnt of other projects, reusables taken from repository etc. also to be referred )

 2.3             OBJECTVIES

2.3.1      CUSTOMER’S OBJECTIVES

(This section briefly specifies what business objectives and critical functions the project should achieve. Customer objectives as given in the MCA / Project Charter / agreed in the project preparation phase should be provided.

[Caution:  do not make broad statements about business benefits (cost savings, increased sales, improved profitability)!  ]

Examples: May contain one, many or all of the following types of objectives.

Strategic objectives	Time scales
Introduction of a new dp-supported IT solution	e.g. mid-1998
Orientation towards future market standards
Optimization of operating procedures, organizational structure and communication channels
Strengthening of competitiveness through .....

Organizational objectives	Time scale
All data should be accessible at every workplace (transparency of information) taking into account definable blocking and protective mechanisms (security).	e.g. mid-1998
Shared use of existing resources (resource sharing)
Protection of investments by use of open standards that can also be used in the future
Flexible technical adaptation to changes in the company structure
Team-oriented working (work groups)

Functional (application-related) objectives

Time scale

Standard methods and applications (products) are used to collate, prepare, exchange and evaluate all information. In this context, it must be possible to operate the application intuitively. Using these applications, it must be possible to make information available at short notice which can provide any viewpoint at all (selection criteria, summarization levels, etc.) for the widest possible range of areas within the company.

e.g. mid-1998

IT objectives	Time scale
Orientation towards market standards	e.g. mid-1998
Portable to different system platforms
Server/customer architecture
Development of a file server
Reduction of administrative expenditure to a minimum
Ability to recognize network-related bottlenecks and problem situations at an early stage
Increased availability

Shortcomings of current system

Example:

The use to date of conventional cabling techniques has caused the following main shortcomings to appear:

·             connection of existing subsystems is generally impossible because of the nature of the cables

·             not every workplace is able to access every application or resource within the business units, or else this can only be achieved by expensive multiple cabling

·             relocation flexibility is restricted by the conventional cabling technique and is thus very expensive

·             there are not enough facilities for switching over to standby equipment in the event of a failure

·             there is no global network management across all subsystems, which results in an increase in administrative work and expense)

2.3.2      OUR OBJECTIVE:

(This section specifies Siemens business objectives project is to support

e.g. New Technology, New account, Repeat Customer etc.)

2.4             SCOPE

(The scope identifies which aspects of the business are to be included in the project and which aspects are to be excluded. Higher Level Scope needs to be referenced from the Master Consultancy Agreement. Detailed scope is defined in the Business Blueprint Document. It determines what other external influences and impacts, such as interfaces, customer needs, and regulatory requirements, are to be addressed. We can use one many or all of the following domains of change to describe the scope of a project. Final detailed scope agreed during the project preparation phase should be given here. If there is a separate scope definition document available, the same may be referred here. )

2.4.1      BUSINESS PROCESS SCOPE

(The business process domain addresses what the enterprise does, how it does it, in what sequence it does it, what rules it follows, and what type of results it obtains. Change in the business process domain drives change in all the other domains.

In Scope	Out of Scope
Materials Management Purchasing Inventory Management	External Service Management
Financial Accounting General Ledger Accounts Receivable Accounts Payable	Funds Management
Cost Centre Accounting

)

ENTERPRISE SCOPE

(The enterprise domain deals with the organizational units of the enterprise. It also deals with the locations: manufacturing, depots, etc.

In Scope

Out of Scope

ABC Limited

XYZ Private Limited

Manufacturing Location at Pune

Sales depots

Head office in Mumbai
Regional office in Delhi

)

2.4.2      INTERFACE AND APPLICATION SCOPE

(The interface domain deals with the features, structure, and interfaces with third party software, tools, hardware, user interfaces, etc.

In Scope	Out of Scope
Interface between XYZ Payroll Management System and FI-GL using Flat-File uploads	Interface with mobile handheld devices
Interface with MS-Excel	Interface with bar-coding systems

)

2.5             DELIVERABLES 

( Deliverables given in guidelines below should be tailored to suit the project requirement. Internal & customer deliverables in the project should be listed here. All deliverables to customer should be as agreed in MCA / Project Charter.

No.	Phase	Deliverable	QA Activity	Responsibility
1	Project Preparation	Project Charter Project Plan Set up of Prototype Solution Start PES Documents	Review by SM, PQM Review by SM, PQM, TC as applicable Review by PQM	SISL / Customer SISL SISL
2	Business Blueprint	Overview of Prototype solution to Core Team Training to Core team Business Blueprint Document	Review by PQM & PM	SISL Customer
3	Realization	Configuration of Quality System Completion of Baseline testing in Quality System Completion of Integration Testing in Quality System & sign off Functional & Technical Specifications for ABAP Developments	Process Review by PQM Review by PT/PQM: ·        FS Review ·        Code Review ·        Test Plan review ·        Test Specification Review	SISL SISL / Customer
4	Final Preparation	Upload of all master data & cut-over data. Go-Live	Process Review by PQM	Customer / SISL
5	Post Go-Live Support	Customizing Documentation Agreed duration of Support after Go-Live has been provided Lessons Learnt & End PES Documentation	Internal Review by PQM Review by PQM	SISL SISL
6	Monthly	Project Report	Review by PQM, SM & TC	SISL

2.6             APPROACH

(This section defines the approach that will be used to achieve the results and the project management standards that will be used to control and monitor the project. The approach is often described by the activities to be performed and the deliverables the client will receive. Approach defined may be in line with the same given in MCA / Project Charter.)

2.6.1      TECHNICAL APPROACH

(Can list the Roadmap, System Landscape, Roll-out strategy etc. The project shall be implemented first in Mumbai as a pilot phase. Subsequently, the solution will be rolled out to Delhi. During the roll-out to Delhi, the team shall be based in Delhi for a period of 3 months….)

2.6.2      PROJECT MANAGEMENT APPROACH

(The Project shall be managed by:

• Project Steering Committee

Name of Person	Organization	Role
Mr. ABC	Customer	Project Sponsor
Mr. XYZ	Customer	Program Manager
Mr. Hemant Samant	SISL	Program Manager/Systems Manager
…

• Project Management Team

Name of Person	Organization	Role
Mr. ABC	Customer	Project Manager
Mr. XYZ	SISL	Project Manager
Mr. PQR	SISL	Project Quality Manager
…

• Project Monitoring Team

Name of Person	Organization	Role
Mr. ABC	Customer	Financial Controller
Mr. XYZ	SISL	Technical Controller
Mr. VB Mulay	SISL	Financial Controller
…

Brief Responsibility of each team may be given)

 

2.6.3      KNOWLEDGE MANAGEMENT APPROACH

(Indicate the knowledge management approach planned for the project like

·      Project Manager has relevant skills on project implementation methodology.

·      Resources for the project have required technical skills and domain expertise.

·      Expert consultants pay visits on need basis for additional inputs in technical / domain knowledge areas.

·      Livelink would be used for reuse and reference.

·      Lessons Learnt of other projects will be referred & good practices are adopted)

)

2.7             ASSUMPTIONS

(Mention the assumptions made in the project such as

·      Local requirements are properly defined.

·      Organization and processes are stable.

·      Customer can provide the required resources (number and skills)

·      No change in selected R/3 release, database or operating system during the course of the project.

·      Scope of implementation is not changed

·      Test data and test cases will be provided by the customer

·      The customer has procured necessary licenses, hardware and software etc.

·      OSS connectivity will be provided by the customer

·      )

2.8             CONSTRAINTS

(Mention the constraints in the project such as

·      IDES is not available. Project Team Training needs to be conducted on Development Server.

·      On-line connectivity to OSS shall not be available. OSS needs to be accessed through the SAP Service Marketplace on the internet.

·      Training Environment will not be set-up. End-user training needs to be conducted on Quality Server.)

2.9             EXTERNAL DEPENDENCIES

(Mention the external dependencies of the project such as

·      Availability of Quality and Production server.

·      Leased line / VSAT link availability for remote manufacturing plant / depots.

·      Connection speeds between production server and the local nodes in remote locations.

·      Parallel projects that could affect the timeline.

·      OSS response time

·      Interface specifications for external systems

·      )

2.10        CRITICAL SUCCESS FACTORS

(Mention the critical success factors of the project such as

·      Ability to take decisions quickly.

·      Prompt resolution of identified issues.

·      Adoption of Standard Business Practices defined by SAP without major modifications.

·      Management of project with milestone monitoring.

·      Definition of approval levels for the project team.

·      User involvement

·      Availability of test data

·      Depth and coverage of functional testing)

2.11        ESTIMATION METHODOLOGY

(Mention the estimation Methodology used for the calculation of Resources. E.g., Tool, Delphi Method, Functional Point, Given by Customer, WBS Method etc. Embed the estimation work sheet)

2.12        RESOURCE REQUIREMENT

(This can be maintained outside in case it is dynamic & shall be updated as & when required. Refer Resource Requirement)

(Give link to / Embed / Refer Project Report filled in for the project)

2.13        CUSTOMER RESPONSIBILITIES 

(This section identifies customer responsibilities. The customer must understand not only their responsibilities but also the impact on the project if these responsibilities are not fulfilled. The responsibilities identified should be agreed with the customer.

The services to be rendered upon introduction of the R/3 standard software are divided between the CUSTOMER and SISL as follows:

Services	Customer	SISL
Project management:
Detailed project planning of each phase	B	A
Definition of test concept	B	A
Definition of training concept	B	A
Definition of documentation concept	B	A
“IMG“ configuration	B	A
Project staff coordination by project management	A	A
Project controlling (time/costs)	A	-
Facilitation of project meetings	A	-
Creation of project status report for Steering Committee meeting	A	B
Recording of minutes during meetings	A	-
Introduction of R/3 standard software:
Team leadership in specialist departments	A	A
Business process design (detail planned concept)	A	B
One-time and/or complex customizing	B	A
Ongoing customizing	A	B
Test run concept	B	A
Implementation of test runs	A	-
Creation of training materials for in-house training	A	B
End-user training	A	-
Interfaces
Detail interface specification	A	A
Interface programming	A	B
Interface documentation	A	-
Interface testing	A	-
Customer-specific Developments:
Detail specification for ABAP programming	A	A
ABAP programming	A	B
Documentation	A	-
Testing	A	-
Data transfer
Data transfer concept	A	A
Development of Data Transfer Tools	B	A
Preparation of old data	A	-
Test data transfer using standard R/3 tools	A	B
Productive data transfer using standard R/3 tools	A	-

Services	Customer	SISL
System administration
Installation of R/3 system: Development, Testing and Production	B	A
Configuration of correction and transport system	B	A
Definition and configuration of authorization profiles	A	B
Definition of security concept	A	B

A  =  Performs and bears primary responsibility for the task described:

Performs the task, taking the initiative for it. Monitors time/costs and schedule for the task and reports deviations.

B   =  Checks, supports, consults:

Supports the task from a planning, methodical and business administration perspective. Provides information on necessary corrective actions. Provides instructions for performing the task. )

2.14        CUSTOMER SUPPLIED PRODUCTS

(Indicate how you control the customer supplied product if any like who is the responsible person & where is it maintained etc.e.g. Customer supplied documents shall be maintained under the folder “Customer’s Document. Hard Copies shall be stamped “Customer’s document” These documents shall be maintained & controlled by PM. A folder with name Customer Documents needs to made be available in Livelink under the project folder.)

2.15        PROJECT COMPLETION AND ACCEPTANCE CRITERIA

(A phase of the project shall be deemed complete when the outputs of the phase have been delivered. A phase can commence only when the preceding phase has been completed. The completion of a phase shall be recorded through signed-off Acceptance Documents. The acceptance document may be signed conditionally, if there are outstanding concerns that need to be addressed. Such concerns should be listed along with the acceptance document. In any case, the acceptance document must necessarily be signed-off.Project Completion criteria defined should be in line with what is agreed with the customer in MCA / Project Charter

Phase / Event	Acceptance Document	Completion Criteria
Project Preparation	Project Charter	Project goals and objectives have been defined Scope of implementation is clarified Implementation strategy has been defined Overall project schedule and implementation sequence have been defined Project organization and committees have been established Resources have been assigned
Business Blueprint	Blueprint Document	Scope of implementation is firmed Business Processes have been documented Level 2 training for Core Team members has been conducted
Realization	Integration Test Results	Business Processes have been mapped Integration Testing has been completed
Final Preparation	Approval for Go-Live	Production Environment has been set-up End-User Training is complete Cutover strategy is defined Data take-on is complete
Event: Go-Live	Go-Live Acceptance Document	Phase “Final Preparation” is complete Transactions are executed in the production system
Post Go-Live Support	Project Closing Document	Agreed duration for post Go-Live support has elapsed

2.16        BILLING

(Mention the approach for billing. Billing amount need not be given where as the billing milestones with percentage may be given.)

2.17        PROJECT ORGANIZATION

(Refer the document SAP_Project_Organization_Structure & tailor it to suit the project requirement. Organization structure may include customer team also. Responsibilities are to be clearly defined.)

2.18        ROLES AND RESPONSIBILITIES

(As per the SBU level defined roles & responsibility, refer to SAP_Project_Organization_Structure. In case of any deviation, pls. mention.)

2.19        STAFFING

(Staffing can be maintained outside in case it is dynamic & shall be updated as & when required.

(Give link to / Embed / Refer Project Report filled in for the project)

2.20        APPLICABLE PHASES AND SCHEDULE

(This can be maintained outside in case it is dynamic & shall be updated as & when required..)

(Give link to / Embed / Refer Project Report filled in for the project)

2.21        PROJECT MANAGEMENT TOOLS

(Name of Tool to be used . e.g MS-Project, ASAP , Live kit tools.)   

3                    QUALITY PLAN

3.1             DEVELOPMENT LIFE CYCLE OF THE PROJECT

(Mention the Life Cycle used in the development of the Project with details of phases. E.g. Standard overlapping Waterfall lifecycle methodology will be used for development of project where each phases should be completed before the completion of next phase. The phases of life cycle under the scope of this project are as indicated below.)

• Project Preparation
• Business Blue Print
• Realization
• Final Preparation
• Go-Live
• Post Go-Live Support

3.2             QA PLAN

(Select the Review Object for the project as given in deliverables / list of project documents & define the appropriate Quality Assurance mechanism. Refer to the Quality Assurance table given in the SAP_Reference Documents)

Sr No	Review Object	Responsibility	Reviewers	Type of review	Approval

3.3             QUALITY GOALS & OBJECTIVES

(This shall be filled in for during the planning phase & has to be updated monthly for the completed objects as an average value. Refer to SAP_Quality Goals & define metrics with appropriate goal & control limits )

S. No.	INDICATOR	UNIT	Project Goal	Min	Max

3.4             STANDARDS AND GUIDELINES TO BE FOLLOWED

3.4.1      DEVELOPMENT & DOCUMENTATION STANDARDS

(Please refer to R3DevelStd for the Coding standards and naming conventions. List down all the documents with the standard applicable. If there are separate documents prepared on project statndards the same may be referred.

List all the project documents as shown in table below. SAP-Rreference Documents may be referred to identify the list of project documents required in the project. Document Numbering Scheme defined in the SAP_reference Document may be referred for Naming / Numbering conventions used in the project. SAP Formats may be referred to indicate the Template Formats used for project documentation.

Sl no	Document/Checklist	Standard1
1	Project Charter
2	Project  Plan
3	Business Blue Print
4	Project Quality Report
5	Delphi Estimation Sheet
6	PES Reports
7	Unit Test Specifications
8	Functional Specification
9	Technical Specification
10	Code
11	Project Progress Report
	…………

3.4.2      COMMUNICATION STANDARDS

• Medium of Communication to be English unless specifically stated otherwise.
• Emails should be used for official written communication.
• MOM must be made for all meetings. Weekly or Monthly meetings should be held. The members, frequency and mode should be defined.
• Communication with other entities (Support group, Implementation team etc) thru e-mail.)

3.5             DEVIATIONS FROM STANDARD PROCEDURE (if any)

(In case there is any deviation from the standard procedure, mention the same here.)

3.6             DEFECT PREVENTION PLAN

( Provide the approach planned to eliminate / control  the defects in the project like

• Training of Personnel on standards, quality etc.
• Lessons learnt of previous projects will be referred
• 100% BBP Walk through with customer.
• Document Review  - 100%
• Code Review – 100%
• Test Coverage – 100% (internal)

)

3.7             REUSE STRATEGY

(Mention the reuse strategy adopting in the project)

4                    CONFIGURATION MANAGEMENT PLAN

4.1             GENERAL

(Tailor the guidelines given in the table to suit the project requirement.

Scope	(Write Down the scope of the CM activities like changes after the customer acceptance phase only will be treated as change request. SAP Back up is under customer scope. Configuration Audit is limited to the verification of the Traceability Matrix & Change Control Log & Livelink. S/W & H/W environment configuration management is out of scope )
CM Tool Name & Ver.:	( Mention the Configuration Management tool used & it’s version no. if any like Excel Sheet, VSS etc.)
Configurable Items:	( List down all the configurable items like Project Plan, Blue Print, Test Specification, Functional Specification, Technical Specification,  Test Plans, etc. SAP_reference documents may be referred to identify the configurable items in the project)

 

4.2             CM RESPONSIBILITIES:

CM Activity	Responsibility	Periodicity	Mode
Configuration Audit	PQM	At the end of Realization Phase and at the end of a project	Project Report updated with PQM’s observations
Configuration Status Accounting	PM	As & when required	Traceability Matrix, Revision History Sheet & Change Control Log
Back up	Customer, PM	After each Configuration Audit	Windows Backup Tools used by the Customer; Replication of Document Files on the laptop used by the PM
Document Approval & Release Management	BBP – PM FS – PT TS – PT Code – PT Project plan – PM	As & when required	Project documents are deemed to be approved after the closure of review observations are verified by PQM. Review result indicates the approval of the document.  The document shall be maintained under directory structure on the Central Document Server / Livelink after formal approval. History of the obsolete documents is maintained. Access rights will be set in such a way that only latest documents will be available for use at any point of time for all concerned. Release of new documents will be communicated either in meetings or vide e-mail / phone.  Document Distribution List may be attached.
Change Management	PM	As & when required	Change Control Log
Project Library Maintenance	PT	As & when required	Central Document Server

4.3             SCHEDULE FOR CM ACTIVITIES

( Mention the configuration activities planned for the project. This can be maintained outside in case it is dynamic & shall be updated as & when required. )

4.4             BASELINE CRITERIA

(Mention Baselining Criteria for all Configurable Items defined under section 4.1)

Sr. No	CI	Baseline Criteria
	Project Charter	Approval from SM/Customer
	Project Plan	Approval from SM, TC
	Blue Print	Approval from Customer
	Customized code	End of Integration testing
	Functional Specification	Sign off from TL
	Technical Specification	Approval from TL
	Unit Test Specifications	Approval from TL
	Code - Object	At the end of  Integration testing
	Integration Test Specification	Approval from Customer
	Customization Document	Customer

 4.5             REQUIREMENT CHANGE MANAGEMENT

(Requirements

 Requirements can be tracked through out the Life cycle of the project with the help of traceability matrix updated by project team and reviewed and controlled by Team Lead.

Changes if any to the requirement after the integration testing are treated as change requests. Change to the original requirement as per the Busiess Blue Print, if identified will be informed through a request to change the Project by the Project Manager of Customer

Changes

Project Manager (PM) of SISL analyzes the change and identifies the impacted items and the effort required to do the change. Change Control Log is updated. Based on the Project Manager’s remarks on the Change Control Log, the Project Team Member (PT) carries out the change. The details are updated in the Change Control Log.

Configuration Audits

Configuration Audits will be conducted after the Realisation Phase and at the end of the Project.

In case separate change control mechanism is agreed in the MCA/Project Charter, same may be added..)

4.6             DOCUMENT MANAGEMENT PROCEDURE

• All Project Documents shall be stored in a Central Document Server available at the Project Site / Livelink.
• These documents shall be replicated into the laptop of the Project Manager at least once in a week and also at other times based on the specific requirements.
• Provision for “Customer Documents”
• Naming conventions for documents
• (As per SAP_QMS)
• Status and version control for deliverables
• (As per SAP_QMS)
• Documents Distribution List
• (Define the distribution list/access rights for different documents)
• Directory structure for central document storage /Livelink
• (Define Directory structure for central document storage /Livelink)
• Data retention policy
• (Define the retention policy of the documents))

5                    TRAINING PLAN

(Give link to / Embed / Refer Project Report filled in for the project)

6                    TEST PLAN

The following tests would be performed on the system:

 (Refer SAP_Implementation_Project Test Plan)

7                    REPLANNING CRITERIA

(The excel sheets in the Project Plan will be maintained live. This shall be shall be updated in PR on a monthly basis & the same shall be forwarded to SM, PQM & TC.

Project re-planning will be done based on the decision taken in the steering committee meetings / Project meetings / PSR based on major changes in the project or after prior approval from SM. Schedule will be revised after approval from customer.

Project plan will be revised only in case of changes affecting the static section in the project plan. Changes in embedded documents / annexures will be tracked separately. Changes in Excel Sheet will be maintained live & updated as & when required / monthly & will be discussed with SM & TC in PSR.

General trigger for re-planning for the project are like in case of End of milestone / Extension of Go-Live date / Specific request from Customer, Change in scope, amendment of contract etc. Other possible reasons are,

Schedule Slippage more than 2SD or 1 month

Effort Accuracy Deviation is more than 2SD or 10%.

Replanning will lead to reconcile work at resource level i.e., lowering or differing technical performance requirements, negotiating more resource, finding ways to increase productivity, outsourcing, adjusting of staff skill mix, or revising all plans that affect project or schedules. Establish new agreements with the customer, sub contractor & other stakeholders..)

8                    PROJECT MONITORING AND TRACKING

8.1             WORK BREAKDOWN STRUCTURE

Provide hyper link to MS project Plan

8.2             PROGRESS STATUS REPORTING

(in addition to the internal reporting mechanism, progress reporting may include the reporting mechanism agreed to the customer also.)

From (Who)	To (Whom)	Periodicity	Deliverable
PM	PQM, SM,TC	Monthly	PR

 

8.3             PROGRESS REVIEW FRAME WORK

(in addition to the internal review mechanism, progress review framework may include the review mechanism agreed to the customer also. Meeting may be conducted offline / through con call also.)

Participants	Frequency	Deliverable
TC,PQM,SM, PM,PT(PT as per requirement)	Monthly (Review Meetings)	Project Status Review Report in PR
PM,TL, PT	Weekly (Review Meetings)	MOM
TL,PQM,SM,PM,TC,FC (Mkg, HR admin, Sys admin if required )	Start PES (During starting of project. Draft PP and PQP should be discussed and commitment from all stakeholders is taken)	Decision Sheet
TL,PQM,SM,PM,TC,PT,FC (Mkg, HR admin, Sys admin if required )	End PES (During Completion of Project.)	Decision Sheet

 

8.4             ESCALATION METHODOLOGY

(Escalation Methodology given in the table may be tailored to suit the project requirement. It may be validated with the escalation mechanism agreed with customer in MCA / Project Charter)

Sr. No	Type of Problem	Mechanism	Reported by	Reported to	Threshold For SBU Head	Threshold For RRB
1.	Technical	Weekly Meetings	TL/PM	PM/SM	5 days
2	Manpower	Immediately Also in PPR	ALL	Next Higher Level	1 Week	2 Week
3	Quality	PQR	PQM	SM	As per Statistical Norms – Refer to Procedure for Quality Measurement
4	Causes of defects	PQR/PSR	PQM	SM	Problem Dependant
5	Financial	Immediately Also in PPR	FC	SM	1 Month	1 Quarter
6	Infrastructure	Immediately Also in PPR	PM	SM	1 Month	1 Quarter
7	Customer (Performance, Delays etc.)	Email / Letter  to customer Also in PPR	PM / SM / AM	Customer	Problem Dependant	Problem Dependant

8.5             RISK MANGEMENT PLAN AND STATUS

(Give reference to relevant section in  Project Report filled in for the project

Risks identified in the proposal phase / Risk Escalation Level Calculator to be tracked. Similarly risks with respect to assumptions, constraints and external dependencies if any to be tracked)

8.6             ISSUES HANDLING PROCEDURE 

(If Issues occur during the course of the project, they will be reported to the project management team and documented by means of an Issue log. The project manager will then evaluate the possible effects and will either decide on his own responsibility about suitable measures to be taken or, in the event of serious problems, will declare the problem to be critical and escalate to the steering committee.

A project crisis has occurred if one or more of the following non-scheduled situations is recognized or has occurred:

·      the deadlines approved by the steering committee are expected to be exceeded by more than 15%

·      the budget fixed by the steering committee is exceeded by more than 15%

·      the planned and promised personnel / resources are not available or are available only to a limited extent

·      phase results cannot be produced

If the extent to which the deadline/budget is expected to be exceeded remains within the above tolerance limits, (%), it is up to the project management team to plan, introduce and monitor suitable preventive / corrective measures. If the tolerance limits are passed, the project management team must inform the steering committee immediately. 

Issues both internal & external including customer complaints are logged in the Problem, Issues , Open points in the Project Report and tracked to closure. Monthly PSR discusses these points

)

8.7             HANDOVER PROCEDURE

(As per Responsibility Transfer Format. The person handing over the responsibility has to handover the objects & fills in the responsibility transfer format. Person taking over the responsibility has to accept & sign the same. Next higher authority has to verify & approve the same.)