TCS Siebel Implementation Methodology Module 4 - Ver 1.0

TCS Siebel Implementation Methodology Module 4May 2007

TCS Confidential

*

AgendaUnderstanding Onsite OffshoreSiebel Implementation Methodology RecapOffshore Startup ProcedurePhase Wise Onsite Offshore Activities & OrganizationEnvironment Setup OptionsOnsite Offshore CommunicationProject Monitoring and ControlBest Practices

TCS Confidential

*

Onsite OffshoreNetworkClient / Partner siteOnsiteTCS SiteOffshore Offshore team works as a virtual extension of the project team at onsiteOffshore Project TeamOnsite Project Team

TCS Confidential

*

Onsite Offshore By Phase

TCS Confidential

Phase

Onsite

Offshore

Onsite : Offshore

Definition

(

100:00

Discovery

(

90:10

Design

(

(

60:40

Configuration

(

(

30:70

Validation

(

(

60:40

Deployment

(

90:10

*


TCS Confidential

*

Siebel Implementation MethodologyCMM Level 5 Integrated Project Management System PCMM Level 4ValidationDeploymentConfigurationDiscoveryDesignSteering committee and project teamProject planProject standards and templatesRequirements Functional, Operational, Conversion, Interface, Data, Sizing and ArchitectureDevelopment environment setupGap analysisTraining and deployment planApplication design, workflow, business rulesApplication data administrationConversion design Interface designApplication support designUnit and system test planApplication configurationStaging area setupInterfacesReports developmentUnit testingTest environment setupPreparation of environmentSystem and integration testingUAT Preparing production environmentProduction pilot setupSupporting Production pilotUser trainingGo LiveOffshore TeamDesign DocumentsUnit Tested ApplicationSystem and Integration Test PlanTraining and Deployment PlanSystem and Integration Test ResultsUAT ApplicationDeployed ApplicationTraining Manuals and User DocumentsDefinition HighlightsProgram and Project ManagementQuality ManagementChange Acceleration Plan and Communication StrategyETVX MethodologyProject PlanRequirements SpecificationGap Analysis

TCS Confidential

*

Onsite Offshore - Project Life Cycle CollaborationSeamless integrated onsite and offshore project team with a single project management entity for accountability, communications and delivery Build, Unit Test Integration TestingSystem RolloutProd. PilotDesign Selected resources from offshore are added to the onsite project team to ensure seamless coordination Onsite leads will track and coordinate work done by offshore team members via scheduled conference calls, deliverable reviews and progress routine metricsJoint Onsite TeamTCS Offshore TeamApplication Development & Unit TestApplication LLD & Unit Test PlanReview changesBug Analysis & FixTesting & SupportUAT, Training Set-upDefinitionDiscoveryTracking & Control

Connectivity and team setupInfrastructure set-up (machines, space etc.)Resource allocation Resource BuildingDC and Support Groups

TCS Confidential

*


TCS Confidential

*

Offshore Startup ProcedureOffshore facility setupSecured network link setup (between 128 KBPS & 2 MBPS based on load)Secured physical environment setupHardware infrastructure setup and software installationCommunication facility setup (for conference call and video conference)Project AllocationProject creation in IPMS tool (Integrated Project Management System)IPMS coordinator is allocated to the projectProject allocation to SEPG (Software Engineering Process Group)Project is created in PAL (Process Asset Library)Project allocation to QAG (Quality Assurance Group)Offshore project plan template is discussedProject metrics for the project are identified and adopted for the projectProject allocation to BAG (Branch Audit Group)Set project audit scheduleContd

TCS Confidential

*

Offshore Startup ProcedureResource AllocationThe respective DC is involved inResource allocation - Resources identification based on required skill-setsResource building - Providing project specific training (domain and technical) Client InteractionKick-off meeting between Client, onsite and offshore team is executed

TCS Confidential

*


TCS Confidential

*

Design Phase Collaboration Desktop support DBA Support Network Admin support Web Admin supportJoint Onsite TeamTCS Offshore TeamProject Infrastructure Support (Client)

Architecture Kick-off Define Technical Architecture Define Integration Architecture Web Admin support System Architecture (Siebel)

Application Design Real Time Integration Data Migration (Data Cleansing)Design & Test Plan Application Design Prototype Reports Design Business Process Automation Data MigrationDesign

Performance Test Plan (Siebel) UAT Plan Training planTest Plan Unit Test Plan Integration Test Plan System Test PlanTest Plan Conduct Design ReviewTCS Siebel Practice Review

Conduct Design ReviewSiebel Expert Service Review

Analyze review commentsConsolidate Make changes to design doc Update test plans Update Siebel review report with updatesConsolidate

Sign-off design documents Review ed Test Plans Reviewed Project Standards DocumentSIGNED-OFFPhase objective is to design the solution meeting business requirements and to prepare plans for testing and training Development env setupEnvironment Setup

Development env setupEnvironment Setup

TCS Confidential

*

Configuration Phase CollaborationJoint Onsite TeamTCS Offshore Team Data Object Layer Data Migration (Setup staging area) Real-time IntegrationConfiguration

Business / UI object layer Business Process Automation Scripting Data Migration Application Administration Unit Testing Configuration

Conduct Configuration ReviewTCS Siebel Practice Review

Conduct Configuration ReviewSiebel Expert Service Review

Analyze review comments Make Integration changes and changes in Integration test plan Unit testConsolidate Make configuration changes Incorporate required changes to test plans Unit test Update Siebel review report with updatesConsolidate

Check-in unit tested SRF, Swt, Dll, ROX, ROD, ROL, Workflows, Repository etc.Configuration Management

Create VBC, IO, Business Service Build connectors Unit Testing Real-time Integration

Check-in tested SRF, Swt, Dll, ROX, ROD, ROL, Workflows, Repository etc.Configuration Management

Create Deployment Plan Contact list of deployment usersDeployment Plan (TCS / Client / Siebel)

Integration test / System test environment setup Data LoadsEnvironment Setup

Application Admin tasks Setup Pilot Production environment Data LoadsEnvironment Setup

TCS Confidential

*

Validation Phase CollaborationJoint Onsite TeamTCS Offshore Team Import repository Apply changes to physical db Build / import test data Compile SRF Complete Admin tasksTest Preparation

Fix defectsBug Fixes

Functional test Run EAI test for real time integration Record test resultsIntegration Testing

Analyze results Update configuration / design and update documentReview Results


Run user interface test scenarios Run all client types Run end to end functional test Record test resultsSystem Testing

Analyze results Update configuration / design and update documentReview Results

Set-up the training env Build Training database Review training materila Train usersUser Training

Run end to end functionality Run performance test scriptsUAT / Performance Test


Review performance results Review defect logSiebel Expert Service Review

TCS Confidential

*

Example 1 - Short Engagement For an Existing Relationship

TCS Confidential

Sheet1

Weeks123456789101112131415

Phase

Definition

Discovery+Design

Configuration

Testing

UAT

Training

Deployment

Phase I Resources

Onsite

Project Manager111111111111111

Business Analyst111111111111111

Configurator111111111111111

EIM111

EAI1111111

Reports111

Training Lead1111

Sub total Onsite666333333334455

Offshore

Project Lead111111111111111

Configurator222222222222211

Reports1111111111

EAI122222221111

EIM111111111111

Sub total Offshore333677777776644

Total Onsite+Offshore999910101010101010101099

Sheet2

Sheet3

*

Example 2 Project with Siebel Analytics

TCS Confidential

Sheet1

Weeks123456789101112131415161718192021222324252627282930

Phase

Definition

Discovery

Design

Configuration

Testing

UAT

Training

Deployment

Onsite

Project Manager111111111111111111111111111111

Solution Architect111111111111111111111111111111

Business Analyst222222222211111111111111111111

Project Lead111111111111111111111111111111

EAI (Siebel - Sap/Legacy)222222111111111111111111111111

Configurator222222222222222222111111111111

Analytics Expert222222111111111111111111111111

Reports111111

Training Lead1111

Sub total Onsite121212121212999988888888777777778888

Offshore

Project Lead111111111111111111111111

EAI (Siebel - Sap/Legacy)111122222222211111111111

Configurator111144444444422221111111

Reports111111111111111111111111

Analytics Expert111133333333322221111111

EIM11111111111111111111

Sub total Offshore000000555512121212121212121288886666666

Total Onsite+Offshore121212121212141414142020202020202020191515151513131314141414

Sheet2

Sheet3

*

Example 3 Complex Project Using Siebel EAI

TCS Confidential

*


TCS Confidential

*

SiebelLocalDatabaseSiebel ServerOnsite TeamSiebel ServerSiebel DatabaseOnsiteOffshoreProsIndependent Development SetupNo downtime as the development process is independent of network Time benefit in development as check-in / check-out is conducted locally Low network costs ConsAdded environment setup time Added costs like hardware, licenses, support teams Increased cycle time for deliverables Development & testing of interfaces cumbersome Conflict during repository merge.Development Environment OffshoreOnsite-Offshore Environment Setup Options

TCS Confidential

*

Development Environment OnsiteOnsiteOffshoreSiebelDeveloper(s)Onsite TeamSiebel ServerProsNo additional environment setup required at offshoreEIM/EAI tasks can be carried out without complexity Faster deliverables as development can be quickly moved in to QA / Production Continuity for maintenance support from offshore Cons Check-In/check-out process is time consuming More bandwidth may be required for frequent check-in and checkout operations Siebel DatabaseSiebelLocalDatabaseSiebelLocalDatabaseTCS suggested option for onsite offshore environment setupOnsite-Offshore Environment Setup Options

TCS Confidential

*

Onsite Offshore Link -OptionsLogMeIn Remote Desktop (formerly known as 3 AM Labs RemotelyAnywhere 5.0)Features - Remote Control, File Transfer, SSL security, Performance MonitoringConsiderations Slow on Dial-up

TCS Confidential

*

Onsite Offshore Link -OptionsF5 FirePassFeatures High ScalabilityConsiderations Requires hardware appliance installation

TCS Confidential

*

Onsite Offshore Link -OptionsTerminal Server and Remote Desktop ConnectionRapid, centralized deployment of applicationsLow-bandwidth access to dataRemote Desktop Connection is built into Windows XP and Windows Server 2003Multiple Logon SupportRemote Administration Mode

TCS Confidential

*

Onsite Offshore Link -OptionsCitrix Access Suite Features Highly Scalable, can be implemented for small, medium and large organizationsConsiderations CPU, Memory intensive (2-CPU server can support only 17-22 clients)

TCS Confidential

*

Onsite Offshore Link -Options

Basic InformationRemotelyAnywhereFirePassRemote Desktop ConnectionCitrix ServerFull Screen AbilityYesYesYesYesSSLYesYesYesYesRSA SecurID SupportYesYesNoNoPerformance MonitoringYesNoNoNoAutomatic Clipboard TransferYesNoYesYesClient Resource RedirectionYesNoYesYesUnix System/Host AccessNoYesNoYesHardware InstallationNoYesNoNoAccess though Browser YesYesNoYesAutomatic protection from VirusNoYesNoNoAutomatic ReconnectionNoNoYesYes

TCS Confidential

*


TCS Confidential

*

Onsite Offshore Communication ProcessProject Event Calendar Is used to publish milestones events in projects like weekly status meeting, onsite offshore meetingsProject team availability calendarContains availability of client and TCS associates both at onsite and offshoreOnsite Offshore Team Contact DetailsContains most recent contact details of team associates across onsite and offshoreEscalation ProcessIs uses for escalation mechanism, severity definition and issue resolution timeProject Status MeetingPeriodic scheduled status meeting are conducted between onsite offshoreProject ReportingWeekly Project status report is circulated to all the stake-holders between onsite and offshoreIssue TrackingIssue tracking tool OR spreadsheet is used to log all issues with status updates across onsite and offshoreRisk Management LogRisk Management Tool OR spreadsheet is used for project risk management across onsite and offshoreChallenges of an onsite-offshore model Team visibility across onsite and offshore Seamless communication between onsite and offshore teamHence the need for a proper Project communication plan, which includes :

TCS Confidential

TCS Siebel Template Project Communication Plan

Project Communication Plan

Version 1.0

May 2004

Confidentiality Statement

The data contained herein shall not be disclosed, duplicated, or used in whole or in part for any purpose other than to evaluate the report, provided that if a contract is awarded to this offer as a result of, or in connection with, the submission of these data, the proposee shall have the right to duplicate, use or disclose the data to the extent provided in the agreement. The restriction does not limit the right to use information contained in the data if it is obtained from another source without restriction.

Table Of Contents

41Introduction

41.1Overview

41.2Audience

41.3Scope

62Communication Steps

62.1Project Event Calendar

72.2Project Team Availability Calendar

82.3Team Contact Details

92.4Roles and Responsibility

102.5Meetings

112.6Project Status Meeting and Reporting

112.7Issues Tracking

122.8Risk Management

122.9Change Control Procedure

132.10Escalation Process

1 Introduction

1.1 Overview

This document will give the detail for Communication plan to be followed in the project.

The overall communication structure may be as shown below.

1.2 Audience

The audience of this document is the entire project team.

1.3 Scope

Communication plan will cover the details and steps to be followed for communication in following areas:

Project Event Calendar

Project Team Availability Calendar

Team Contact Details

Roles and Responsibility

Meetings

Project Status Meeting & Reporting

Issues Tracking

Risk Management

Change Control Procedure

Escalation Process

2 Communication Steps

Following section will detail the steps to be followed for communication in each area mentioned in section 1.3 above.

2.1 Project Event Calendar

Project Event Calendar will be used to publish the milestone events in the projects. The Program Management Office (PMO) comprising of the Project Managers from and TCS will have authority to add or update calendar events. Any changes (add or update of event) in the calendar will be notified to the project team.

Author of the event can set access to view or edit the event and send notification while publishing the event for any addition or updation.

This can be achieved by using any tool like Quickplace or by publishing the calendar using a spreadsheet to a shared location. Project team can see the Events in calendar. A sample event calendar is provided below.

Event Calendar

Objective

Supplier

Topic Areas

Distribution

Facilitator

Timing

Frequency

Weekly Status Report

Team leads 2.0 - 8.0, TCS, Training PM, Data Quality PM, CSS PM, IMLP

Last week accomplishments, open issues, risks, upcoming milestones

QuickPlace

Comm Manager, Quality Manager

Friday 5 PM

weekly

Project Review Session

Quality PM, 8.0 PMs, Biz PM, Project Sponsor

Review weekly status report, review project plan, set agendas for weekly team meeting, deliverables for the upcoming week, message to the team, leadership gut check

meeting

Project sponsor

Monday 1 PM

weekly

Weekly Status Meeting

Team leads 2.0 - 8.0, TCS, Training PM, Data Quality, CSS, IMLP

Last week accomplishments, open issues, risks, upcoming milestones, overall project message, issue and risk log review, team gut check

meeting

Quality Manager, 8.0 PM, Biz PM

Tuesday 10:00 AM - 11:30 AM

weekly

Status Report to Steering Committee and PQC

8.0 PM, Biz PM, Quality PM, Project Sponsor

Score Card

email

Comm Manager, Quality Manager

Friday

bi weekly

NIKU Director

Training PM, TCS, Data Quality, CSS, IMLP

Time

NIKU Report

Yan / IMLP

Friday

Weekly

8.0 PQC Tollgate

8.0 PM, Quality PM

tollgate list, deliverables

meeting

MBB

TBD

TBD

Steering Committee Meeting

Biz PMs, 8.0 PM, Quality PM

Project scope status, risks & issues, resources, timeline

meeting

Biz Project Manager

as needed

bi monthly

Responsibility for updating:

Respective PMO member managing or owning the event and/or the project manager

2.2 Project Team Availability Calendar

Project Team availability calendar will be placed in the tool (if used) like QuickPlace or on a spreadsheet in a shared location. This calendar will contain the availability of and TCS resources.

1Users of the calendar will be team and the TCS onsite team members.

2Purpose of the calendar is mainly to disseminate information on team members' availability within the group.

3Editing permission with all members and calendar information to be updated by individual members.

4Only one version of the Calendar will be maintained. Please follow the "Check-out/Check-in Page" process if applicable.

5Calendar updating has been kept simple. A blank cell will mean that the member is available in-person to participate in discussions, meetings, checkpoints etc.

6In case of non-availability due to any reason e.g. - vacation, travel, other official work - member will update concerned dates as "Out of Office" (OF). Member may leave contact details as Excel "Comments", if available remotely.

7On updating information, member will inform concerned persons thro' normal channels i.e. e-mail, phone.

Sample of the availability calendar created in MS Excel is as shown as sample:


Individual team member for his/her availability status

2.3 Team Contact Details

The most recent information on the contact details of the team members will be made available in Common Place e.g. Tool like QuickPlace or spreadsheet in shared location. The sample format that may be followed is as given in the figure below:


Respective PMO member for his team members

2.4 Roles and Responsibility

The role description and expected activities for each team member involved in the Project will be defined in the Roles and Responsibility document.


Respective PMO member for his team members

2.5 Meetings

Any project team member can call a meeting concerning the Project. The following procedure shall be followed to call a meeting.

1. Person calling the meeting (Chairperson) prepares the agenda and circulates the same to concerned team members by e-mail at least one day prior to the meeting.

2. The agenda structure will include the following:

Attendees

Schedule - Date, time & venue

Agenda

Sample of Meeting Agenda is as attached:

3. The Chairperson will designate a Minutes Scribe

4. The Minutes will be prepared and circulated by the Minutes Scribe within a day of the meeting.

5. The Minutes shall include the following:

Attendees

Next Meeting Schedule - Date, time & venue

Minutes containing meeting notes, action items, action by and action dates. Action items should be entered in the Tracking List so that we have one place to follow up on items (instead of having in each minute's document). The actions will be documented in the same format from the Tracking List and then just pasted into the tracking list (update the number for the next number to use).

Sample of Meeting Agenda is available in AMO kit. Please refer to the AMO documents.

Responsibility for Meeting Agenda:

Meeting Chairperson

Responsibility for Meeting Minutes:

Minutes Scribe

Responsibility for updating the Tracking List

Minutes Scribe - for new items

Item Owner - for existing items

2.6 Project Status Meeting and Reporting

This covers the following periodic status monitoring meetings. Additional meeting may be added to the list as decided.

Meeting name

Periodicity

Venue

Participant

PMO meeting

PMO members

Tech Team meeting

Status meeting

Steering Committee meeting

1. In case the meeting cannot be held on the scheduled date/time, the designated meeting chairperson shall decided the alternate date and inform all attendees.

2. The chairperson shall circulate agenda one day prior to the meeting.

3. The Chairperson will modify the list of participants as required.

4. Minutes to be prepared and circulated by the designated minutes scribe within a day of the meeting.

5. TCS Project Manager will update TCS weekly status report in the repository. Sample / Template of status report provided in the AMO kit needs to be used for this purpose. This will be completed by .

6. All issues will be posted in Tracking List for tracking as well as for discussion. A separate project management section will be used.

2.7 Issues Tracking

Some tool (e.g. QuickPlace) can be used for Issue Tracking System. Otherwise, Issue Tracker Spreadsheet can also be maintained which is listed in AMO_Kit.

The analysis would be performed by and discussed in the weekly PMO meeting.

Responsibility for recording, assigning and tracking:

Member raising the issue

Assignment of the owner and protocol for notifying the owner is decided, based upon the requirement. Suggested owner can be assigned if the person opening the item is also the owner. If it is someone different assign the person and contact her/him for 1) notification and 2) agreement he/she will own the issue.

Responsibility for analysis:

PM for analysis and for accepting revision marks each week, keeping 2 prior copies for reference and ensuring consistent use of categorization and numbering.

2.8 Risk Management

Risks to the execution of the project would be identified, and relevant mitigation plan would be put in place per the Risk mitigation procedure. This would then be analyzed, tracked and risk managed per the project priority. Any tool meant for risk management may be used. The simple issue tracker may also be used for this purpose

The analysis will be performed by Project Manager and discussed in the weekly PMO meeting.

Responsibility for recording, assigning, tracking and mitigation:

Project Manager

2.9 Change Control Procedure

The Change Control Draft A document attached describes in details the scope, responsibilities and procedure to control changes to released items. All Change Control Documents i.e. Change Register, Change Impact Form and Change Request will be posted in QuickPlace (if used) or the share location

Responsibility for raising a change

Any team member

Responsibility for evaluating

Concerned TCS team member

Concerned IT Owner

Responsibility for approving, authorizing and implementing the change

TCS Project Manager

Responsibility for accepting the change

2.10 Escalation Process

Documented escalation process shall be used. There will be 4 escalation levels each at and TCS. The escalation mechanism, severity definition and issue resolution times have been mentioned in the Escalation Process v1.0 document attached.

Responsibility for escalation:

Any PM member could put an issue in this track. Once in the track, it would be tracked as per the process.

TCS Offshore Lead

Management

TCS RM

TCS Onsite Developers

Project Manager

TCS Project Manager

EMBED Word.Picture.8

TCS Offshore Developers

Tata Consultancy ServicesTCS InternalPage 13 of 13

_1141134280.doc

_1144673616.doc

Change Control

for

Version 1.0



Table Of Contents

41Purpose

42Scope

43Responsibilities

54Procedure

54.1Raising Change Requests

54.2Evaluation and Approval of Change

64.3Acceptance and Authorization for Change

64.4Change Implementation

75Appendix

75.1Change Request Form

105.2Change Request Tracker

115.3Change Impact Form

1 Purpose

To control changes to released items.

2 Scope

This procedure describes the method to be followed for handling changed to baselined items.

For changes that affect formally controlled baselines of the project, this procedure will be followed in its entirety. For other changes, the TCS Project Manager may exercise discretion in following this procedure. In either case, the Change Impact Analysis set out in this procedure will always be followed.

3 Responsibilities

Activity

Responsibility

Raise of Change Request

Anyone

Evaluate of change

1. Concerned TCS team member

2. Concerner IT Owner

3. Concerned Siebel team member

Approve the change

TCS Project Manager

Accept the change

Project Manager

Authorize the change

TCS Project Manager

Implement the change

TCS Project Manager

4 Procedure

The specific procedures for change control in the project will be derived from the procedure set out here. It will cover:

Identification and documentation of the need for change.

Evaluation and Approval of Change Request

Acceptance and authorization of request

Implementation of change

4.1 Raising Change Requests

Changes to released items will be triggered by:

A Change Request raised by any person associated with the project. The TCS Project manager will allocate a unique Change Request Number on its receipt.

A Problem Report necessitating a change.

A Review Report/Defect Log raised during the review or testing process necessitating a change.

In this procedure the Change Request, Problem Report and Review Report/Defect log will be referred to and treated as Request for Change (RFC).

The TCS Project Manager will log all RFCs in the Change Register and allocate serial numbers to them.

4.2 Evaluation and Approval of Change

On receipt of an RFC, the concerned TCS team member, Siebel team member and Client IT owner will evaluate it and identify:

The items impacted

The alternative methods of implementing the change

The effort involved

The impact will be recorded in the Change Impact Form. The item ID may be filled at the time of incorporating the change.

The TCS Project Manager will consult the Siebel Project Manager in case the change impacts Siebel efforts or deliverables.

The TCS Project Manager will approve or reject the RFC and record the decision on the Change Impact Form.

If the change is approved, the TCS Project Manager will select the method of implementation and will process the change further.

4.3 Acceptance and Authorization for Change

The TCS Project Manager will obtain acceptance from Project Manager if the change affects the project deliverables. In such cases, Clients decision will be recorded on the Change Impact Form and the Change Register.

The TCS Project Manager will authorize the implementation of the change after obtaining Clients acceptance, if any.

4.4 Change Implementation

Change to Documents

If a change impacts a document under preparation, it may be changed directly.

If a change impacts a baselined document, the following will be done:

Users of the document will be notified, if necessary

The document will be changed as required.

The revised/changed document will be reviewed, approved and authorized for release.

The document will be released again.

The start and end dates will be recorded in the Change Register.

Changes to Programming Products

If a change impacts a program under development, the program may be changed directly.

If a change impacts a baselined program, the following will be done:

Users of the program will be notified, if necessary

The program will be moved to the programmer's work library.

The program will be changed as required.

The program will be re-tested.

Test results will be reviewed and the program approved for release.

The program will be released again.

The start and end dates will be recorded in the Change Register.

5 Appendix

5.1 Change Request Form

Project Manager:

Project Change Request #

(assigned by PM)

Project Name:

Instructions:

Use this document to log and obtain approval of any project change that may impact scope, dollars, or delivery dates.

Any member of the Project Team or Impacted stakeholders not directly on Project Team can submit a request.

Requester completes the first section electronically. The form is then forwarded to the Project Manager.

The Project Manager completes the second section electronically with assistance from the Project Team. The Project Manager then presents the options and recommendation to the Change Control Board for their review.

Work on a change request will not begin until approved. Acceptable documentation includes e-mails as well as meeting minutes showing the change was approved. All approvals must be noted, dated and stored with the Change Control Change Request Form.

All Project change requests will be kept as part of the Project documentation.

Section 1 (To be completed by Requester):

Requester(s) Name:

Request Date:

Department:

Phone:

Title:

E-mail:

Reason for Change: (check all that apply)

FORMCHECKBOX

Mandatory due to law or policy

FORMCHECKBOX

Business Impact

FORMCHECKBOX

Competitive advantage

FORMCHECKBOX

Financial Impact

FORMCHECKBOX

Quality & Reliability

FORMCHECKBOX

Other

Description of Change:

Business Reason for Change (include an explanation of reason(s) checked above):

Business Impact if not done:

Is there a business work-around?

Section 2 (To be completed by Project Manager/Lead and Project Team members as assigned)

Solutions Options / System Work-arounds: (please number)

Option #

Description

Impact(s) to Project (answer all questions for each option, be as specific as possible):

Work Effort (hours):

Dollars:

Timeline:

Resources:

Project Deliverable Impacts:

All areas/projects impacted:

Issues/Concerns:

Recommendation:

Section 3 (To be completed by Project Manager/Lead at the direction of the Change Control Board):

FINAL DECISION:

FORMCHECKBOX

Accept As Is

FORMCHECKBOX

REJECT

FORMCHECKBOX

Accept With Revisions

FORMCHECKBOX

Escalate

FORMCHECKBOX

Defer

FORMCHECKBOX

Escalate To

Decision Date:

Explanation:

-----------------------------------To be filled by TCS PM-------------------------------------

CR No:

Date received:

--------------------------------------------------------------------------------------------------------

5.2 Change Request Tracker

The change request tracker tracks the change request from its being logged to final acceptance/rejection.

\\S:\Maintenance\AMO_kit\04-Maintenance\ TCS Siebel Template Change Request Tracker1 v1.0

5.3 Change Impact Form

Change Impact Form

Change Reg. Srl. No. :

Date Received:

Evaluated by

:

Remarks

:

Implementation Alternatives :

Items affected:

Item ID

Item Description

Item Ver. No.

Nature of change

Responsibility

for change*

(* Responsibility for change may be specified as Customer, Support group, Project Team or others)

Estimated effort:

Impact on schedule:

Impact on cost

:

Approval

:Approved/Rejected/Deferred

Approved by

:

Authorized by

:

Date :

Customer acceptance Ref.:

1

TATA Consultancy ServicesIn ConfidencePage 3 of 11

_1144674541.doc

Escalation Process

for

Version 1.0



Table Of Contents

31Purpose

32Scope

33Escalation Mechanism

44Escalation Levels

55Severity Definition

1 Purpose

To escalate issues, risks and concerns.

2 Scope

This procedure describes the method to be followed for handling issues, risks and concerns that do not get resolved within the agreed timeframe.

3 Escalation Mechanism

4 Escalation Levels

5 Severity Definition

Issue Resolution Time (days)

Executive Sponsor

Business

Relationship

Executive Sponsor

Level 1

TCS

Stop

Determine Severity of the issue and Timeframe

No

Project Manager

Executive Sponsor

Delivery Manager

Director, Commercial Operations

Project Manager

Regional Manager

Level 4

Level 3

Yes

Client

Level 2

EMBED Excel.Sheet.8

EMBED Excel.Sheet.8

Project Manager

Project Coordinator

Siebel

Issues / Concerns / Risks

Escalate Issue to next level in your organization

Issue resolved

within time for the defined severity?

Escalate Issue to Peer Level

1

TATA Consultancy ServicesIn ConfidencePage 5 of 6

_1114624012.xls

Escalation Process

Time to Resolve Issues

SeverityEscalation Level

12345

343211

222111

1110.50.50.5

Severity Definition

RankingDescription

1Major Impact

2Moderate Impact

3Minimal Impact

Sheet2

Sheet3

_1114624116.xls

Escalation Process

Time to Resolve Issues

SeverityEscalation Level

1234

11111

23211

344NANA

Severity Definition

RankingDescription

3Impacts delivery to business

2Impacts Transition schedule, quality and thus DELTA savings but does not impact delivery to business

1Minimal or No impact to Transition schedule, quality and thus DELTA savings

Sheet2

Sheet3

_1141131855.doc

PM Meeting Agenda

Attendees:

:

TCS:

Schedule:

Date/Time: , , at

Agenda:

Sample Issues are documented below.

1. Status on Action Items from last meeting

2. TCS Status Report Week ending

3. Approach for using Repository for project documentation and progress tracking during

Prepared by:

*


TCS Confidential

*

Offshore Project Monitoring & ControlProject Meetings Periodic Project review meeting at least once in a week between PL and team membersMeeting with Account ManagerMeetings with offshore Account Manager is held on a need basis, at least once on fortnight, primarily to discuss managerial and technical issuesProject Management Review MeetingRepresentatives of Senior Management conduct Project management review meeting to analyse the health of project with respect to Management and Client Requirements. Issues identified are logged in Issue Tracking Tool IPMS and tracked to closure within 15 elapsed daysProject MonitoringInitiated by QAG (Quality Assurance Group) to determine the health of the project with respect to iQMS. The findings are recorded in Issue Tracking Tool IPMS tracked to closure within 15 elapsed daysInternal Quality AuditInternal Quality Audits are conducted as per BAG (Branch Audit Group) planStatus Report OffshoreStatus report is sent to Account Manager and to Project Manager at onsite.Weekly Time SheetsEvery team member fills weekly timesheet using IPMSTele-conferenceWeekly teleconferences are held between onsite and offshore to understand the project progress and issues

TCS Confidential

*


TCS Confidential

*

Onsite Offshore Best Practices - GeneralClear Definition of Roles and ResponsibilitiesProject PlanDefine empowerment and escalation rules, points of contact Communication PlanSensitivity and clarity of communicationCommunication being recorded as MOM, Issue Tracker, eMailsRegular communication, reporting and reviews at all levelSingle report being circulated to Client and TCS governance bodyReliable InfrastructureBackups, LocalDBEffective Knowledge ManagementDocumentation, Onsite-Offshore RotationCross culture training across both organizationsCulture workshops being conducted

TCS Confidential

*

Onsite Offshore Best Practices Siebel SpecificAll developers at onsite and offshore must work on their own local database.Data model changes should be made by one person preferably at onsite.One person, preferably onsite, should be responsible for compiling all Siebel master data (Admin) changes for replication on other environments.It is a good practice to integrate Siebel tools with version control tool for all development work at offshore.

TCS Confidential

*

Thank you

TCS Confidential

Date post:	07-Nov-2015
Category:	Documents
Upload:	dindina12
View:	46 times
Download:	5 times