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
*
AgendaUnderstanding Onsite OffshoreSiebel Implementation Methodology RecapOffshore Startup ProcedurePhase Wise Onsite Offshore Activities & OrganizationEnvironment Setup OptionsOnsite Offshore CommunicationProject Monitoring and ControlBest Practices
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
*
AgendaUnderstanding Onsite OffshoreSiebel Implementation Methodology RecapOffshore Startup ProcedurePhase Wise Onsite Offshore Activities & OrganizationEnvironment Setup OptionsOnsite Offshore CommunicationProject Monitoring and ControlBest Practices
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
*
AgendaUnderstanding Onsite OffshoreSiebel Implementation Methodology RecapOffshore Startup ProcedurePhase Wise Onsite Offshore Activities & OrganizationEnvironment Setup OptionsOnsite Offshore CommunicationProject Monitoring and ControlBest Practices
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
Fix defectsBug Fixes
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
Fix defectsBug Fixes
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
*
AgendaUnderstanding Onsite OffshoreSiebel Implementation Methodology RecapOffshore Startup ProcedurePhase Wise Onsite Offshore Activities & OrganizationEnvironment Setup OptionsOnsite Offshore CommunicationProject Monitoring and ControlBest Practices
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
*
AgendaUnderstanding Onsite OffshoreSiebel Implementation Methodology RecapOffshore Startup ProcedurePhase Wise Onsite Offshore Activities & OrganizationEnvironment Setup OptionsOnsite Offshore CommunicationProject Monitoring and ControlBest Practices
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
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:
Responsibility for updating:
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:
Responsibility for updating:
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.
Responsibility for updating:
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
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
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
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
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:
*
AgendaUnderstanding Onsite OffshoreSiebel Implementation Methodology RecapOffshore Startup ProcedurePhase Wise Onsite Offshore Activities & OrganizationEnvironment Setup OptionsOnsite Offshore CommunicationProject Monitoring and ControlBest Practices
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
*
AgendaUnderstanding Onsite OffshoreSiebel Implementation Methodology RecapOffshore Startup ProcedurePhase Wise Onsite Offshore Activities & OrganizationEnvironment Setup OptionsOnsite Offshore CommunicationProject Monitoring and ControlBest Practices
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
Top Related