Seio Project Change Managment

1. RFI: Project Change Management
Seioglobal
Cover Pictures: HQ in Shanghai | Suzhou Office | Jiaxing Tech Building –completion in 2009
Shanghai | Tokyo | Osaka | New York (WIP) | Chicago (WIP) | London (WIP) | India (via
partner) | Suzhou | Dalian | Wuxi | Jiaxing | Chengdu | Shenyang |
www.seioglobal.com
Executive Summary
This document is designed to describe the change management system and model used for
projects at Seioglobal. It showcases the model we have in place to manage frequent change
requests and changes in a project(s) as explained in the three scenarios for “Change
Requests” in this document.
Note: The document is part of the comprehensive RFP. Last update: October 2008.

2. Table of Contents
Statement of Confidentiality
This document contains material and information that is private and confidential to
Seioglobal, its subsideries or clients. The information is granted on grounds that it
will be held in strict confidence, not be disclosed, duplicated or used in whole or in part
for any purpose other than the evaluation and purpose of this request.
Introduction..……………………………………………….……………………………………...….3
Change Request Management Process……..………………………………………....3
Change Request Form (CRF)…………….…..………………………………………....3
Scenarios for Project Change Request Generations……...…………………………..4
Our Change Management Model……………………….……………………………………...….5
Detailed Change Request Management Process………..…………………………....6
Change Request Team Roles and Responsibilities (Seio Team)...…….…………....7
Project Change Management Communication…..…….……………………………………...…8
Communication Modes………..…………………………............................................8
Communication Levels for Change……………………………….....…….………….8-9
Contract Change Process.……………………………………………………………………...…9
Project Change Methodologies…..…….……………………………………...………………….10
Solution Approach 1: Iterative and Incremental Development Methodology………11
Solution Approach 2: Prototype /Pilot Integrated to Methodology……....………11-12
Keeping Projects ‘Change Ready’...…………………………………………………………...…12
Final Notes…..……………………………………………………………………………………...12
Company Confidential 2

3. Introduction
It is common for IT requirements to undergo frequent
Types of Changes:
changes in the evolution of a project. We have
developed and modeled an effective change  Scope of work
management processes that not only deals with these  Functional specifications
changes but is also anticipates them thus ensuring
 Design specifications
your projects are delivered with as little risk as
possible.  User defined look and feel
Change Request Management Process
The Client, prior to the beginning of project work, signs our change request management
process, which is defined in the project’s proposal. Any changes or differences between the
ongoing observed functions from the actual scope and/or plan of the project is documented in
the Change Request Form (CRF) sent electronically (email) or mailed. Both the Client and
Seio should keep records of all signed CRFs, whether approved or rejected.
Exhibit A: Change Request Form (CRF)
Request No: Date:
Priority: (Urgent, High, Medium, Low):
Client Name: Contact Name:
Project ID: Project Manager:
Project Name:
Initiated By:
Change required:
Reasons:
Effort and Impact:
Affected Modules and Documents:
Decision:
Approved / Not Approved:_____________ By:___________ Date :___________
Company Confidential 3

4. Scenarios for Project Change Request Generations
There are three scenarios which can lead to the generation of a project CRF, these include:
1. Client Requests
A CRF sent from a client to our delivery team requesting
existing projects scope modifications.
2. Requests by Discovery
A CRF is generated and proposed by our delivery team upon
the discovery of necessary changes to the project scope while
in the process of the project’s delivery. Upon receiving our
CRF the client may also generate a CRF pertaining to
discovered changes or additional changes to enhance the
product. Upon receiving the CRF, our delivery team would
also respond with a CRF and so on.
3. Delivery Bugs / Defects
Bugs or defects in the delivered project are reported in the
client reports. Upon receipt for the received changes from a
client it is discussed and if it is agreed that it is a change and
not a defect, a CRF is generated.
The Change Control Board (CCB) Team comprising of members from the client and Seio,
typically the client’s PM or Section Manager along with our delivery PM, are responsible for
approving, rejecting or deferring the change requests based on their study of the percentage
impact of the change on effort, schedule, quality or contractual requirements of the proposed
change which are outlined in the Change Response Report (CRR). To be noted, the duration
leading to the response of a CRF depends on the availability of the information proposed by
the change. Additional documents may be attached to the relevant CRF in question.
Company Confidential 4

5. Our Change Management Model
The figure below depicts our model for managing change requests:
- Analysis of CRF
- Work with Delivery
Team to Generate CRR
Client
(SE / PM) Seio Delivery Head
(SE/ PM)
- Generate CRF
Evolving Changes
- Approve CRR
- Reject CRR
Delivery Team
- Analysis of CRF
- Version Control
Change Response Report (CRR): - Generate CRR
Summary * Project Plan Updates * Resources *
Quote (Estimate) * Change Modules & Impact *
Results * Consultancy
Figure Summary:
 Client sends change request (CRF)
 Our delivery head receives CRF, analyses it, delivers and works with our
delivery team to generate a report (CRR)
 The CRR is sent to the client who together with the delivery head (via the CCB)
decide whether to approve or disapprove
 If approved, changes are made and documented by both sides. If disapproved
another CRF may be generated by either our delivery head or the client
Company Confidential 5

6. Detailed Change Request Management Processes
The figure below depicts our change request management process evolution:
Initiation Prioritization & Estimation
Unique CRF Generation Finalization CRF tracking and
CR# Assigned for Tracking CR Prioritization by client recording
PM and Seio PM (CCB) Seio PM / SE
Decide CR handing onsite / coordinates with the
offshore delivery team to
Requirements Finalized by prepare CRR
OSC & client team composed of
OSC delivers CR document (Estimates, Project
to Seio Plan, CRF impact)
CRR is reviewed &
approved by client &
CCB
Production Review & Deliver Construction
CBB signs (approves) Tasks  Delivery QC team Seio PM updates the Query
System Test Environment vigorously evaluate changes Tracking Sheet
Production starts upon Any bugs are reported to The Detailed Design /
clients sign off (approval) PM and the delivery team Program Specification
Delivery document detailing documents are sent to the
deliverables as outlined in CCB for approval
the CRF and CR documents Upon CCB approval coding
 Deliverables include: begins
Program Specs, Test Plan
Summary, Test Results and
any other project elements
Company Confidential 6

7. Change Request Management Team Roles and Responsibilities (Seio team)
Roles Responsibilities
Seio Project Manager (SE/PM)  Project & Resource Management
 Risk Management
 Client Relationship Level activities or any other
responsibility as defined by Seio / Client Management
 Business (Domain Knowledge) and Technical
Seio Onsite Coordinator  Collect, consolidate, confirm business requirements
(Available on Case by Case)  Package CR, identify deliverables and get client
approval
 Query resolution & offshore coordination
 Product delivery coordination
 Assistance during acceptance testing
 Assistance in production roll-over
 Execution of critical CRs onsite
Seio Development Team (PL,  Day-to-day assigning / monitoring of tasks
Sr. PG, Jr. PG)
 Status reporting
 Collection & analysis of quality measurement data
 Defect prevention & configuration management
 Escalation for non-compliance / project related issues
 Analysis & Estimation efforts for the CR
 Creation of Unit Test cases
 Preparation of Detail Design Specifications
 Coding & Unit Testing & Delivery of packages onsite
Seio Quality Control Team  Quality check of specification document, unit test
(SQA, TL, TS) cases, code and test results
 SCM (Software Configuration Management)
Company Confidential 7

8. Project Change Management Communication
Our project management model not only ensures concise and as much ‘on demand’
communication as possible, but most noteworthy, a transparent project.
Communication Modes: The key modes of
Communication Channels:
communication between the client, onsite and
offshore teams are comprised of, but not limited to,  Email
the diagram.  IM (Skype, Msn, client IM)
Please see diagram on the right.
 Teleconferences
 Video Conferences
 Periodic Shared Status
Reports
 Physical Meetings
Communication Levels for Change:
Changes are communicated to the client at the; Strategic Level, B2B Level, and Project Level
as illustrated in the table below.
Strategic Level These are done at the highest levels to review the progress of
the project and gather feedback related to the overall
direction of the business relationship. Members of this
meeting include:
o Client’s Regional Manager
o Client’s CIO /CTO
o Seio Division Manager
o Seio CIO /CTO (Delivery Head)
Company Confidential 8

9. Project Level These are comprised of, but not limited to, frequent and weekly
teleconferences between the client’s PM /SE and Seio’s PM,
PL, and TL (if necessary we have our coordinator onsite). Plans
for the subsequent week are discussed and day-to-day
feedback on the project delivery may also be provided.
Contract Change Process
Contract changes are typically initiated by a CRF that is part of the respective projects
documents. The current system we use at Seio dictates that each change is in writing,
mutually negotiated and agreed upon by both parties. This change reflects all aspects of the
proposed change including commercial and technical issues.
The Contract Change Process is described in the diagram below:
CRR ·The CRR and attached relevant project change documents
represent estimates for additional resources or efforts,
project plan, and delivery implications. In addition to this any
incremental estimates for such efforts and costs are
submitted to the client as an add-on to the approved
proposal (with an additional SPA / SOW being signed when
necessary).
Work Starts ·Work on the new software changes and requirements only
begins upon the client’s formal approval of any additional
project costs.
Company Confidential 9

10. Change Project Methodologies
We realize that change is almost never an excluded factor in any project. In fact, we have
clients that require changes and consultancy in order for their products to be delivered meeting
their standards / expectations. Thus, apart from the standard Waterfall Methodology used for
ADM, we have developed a methodology that we call Prototype. This enables us to
simultaneously make changes to parts of the project delivery stages while making changes to
only the relevant affected parts of the system. Our model in turn makes it easier for us to
manage projects with frequent changing requests and specifications.
We have two solution approaches below for dealing with projects that need excessive changes
as depicted in the two figures that follow.
Solution Approach 1: Incremental and Iterative Development Methodology
Client Seio Delivery Head
(SE / PM) Change Request (SE/ PM)
Iterative Software
Verify, Test & Change
Test & Send
Verify, Test &
Change Request
Change
Repeat As Many
times: Test & Send Verify, Test &
Requests Change
OK Change, Test &
Deliver
Company Confidential 10

11. Summary of Solution Approach 1:
 Client sends change request (CRF)
 Our delivery head receives CRF, analyses it, delivers and works with our
delivery team to generate a report (CRR)
 The CRR is sent to the client and CCB who together may approve/disapprove
 If approved changes are made and documented by both sides. If disapproved
another CRF may be generated by either our delivery head or the client
Solution Approach 2: Prototype / Pilot Integrated to Methodology Model
Change Phases
Client (SE/PM) Prototype
UI / Functions
DONE
Begin ADM Methodology
(typically Waterfall for big
teams)
Company Confidential 11

12. Summary of Solution Approach 2:
 A solution typically used for managing change for most of our projects in
which the client sends a change request and changes are made with the
objective of Seio produces a prototype / pilot for the client to evaluate
 We create the design and structure for the prototype / pilot which fulfills the
basic functions without much coding
Once the specifications and structure are done then the client evaluates the
pilot / prototype (Client may give a more detailed feedback along with
additional changes that are as close to the final product)
 Once this is approved, an ADM methodology such as Waterfall, Agile, etc can
proceed smoothly all the way to delivery
Keeping Projects ‘Change Ready’
We have adopted a forward-looking approach that anticipates that changes can happen within
the development and delivery of our projects. This approach helps to keep projects within the
expected delivery date(s) and minimize risks associated with changes to the proposed project
plan.
 We do this via simulating and providing estimates inclusive of the margins for changes
that are evident or possible.
 For small changes, if they can be covered by our internal costs, we implement them
free of charge and include them in a report to the client if possible (this is done on a
case to case basis as they are only free after meeting some internally set criteria that
does not interfere to a large extent with the project plan).
FINAL NOTE
 Change Requests and Models are flexible according to the clients needs / requirements
END
Company Confidential 12