Project Management Review Procedure
The purpose of the procedure is to define adequate mechanism for periodic and event driven Project Management Rev
(PMR). PMR helps in having project status data in a uniform format, which is to be used for analysis & finding trends in
project management cycle.
Plan for PMR

PM shall plan for PMR on monthly basis. The PMR shall be attended by :


AM, PM ,SQAG, Project Team (Mandatory)
Global delivery Head ,Head BE , Support functions (Optional)
Prepare for PMR

PM shall prepare for PMR based on the below mentioned agenda :

Review of action item from last PMR

Project execution status w.r.t Project plan

Review Relevant stakeholders involvement

Review of D&Q Plan (Inclusive of sub plans)

Monitoring the process/sub process performance in the project

Review of High Priority risks & Issues

Review of Causal Analysis corrective and preventive action

Effectiveness/Assessment of process compliance

Decision Analysis action items if any

Status of DMAIC projects and process improvement activities

Project VOC / Customer feedback

Any other areas of Concern

The concerned SQAR will verify and approve the PMR Presentation followed by the AM Approval.
Conduct & Track PMR




The PM shall conduct PMR ( Refer PMR checklist CHK-31)
The PM shall record the actions arising out of the PMR in the respective tracking sheet.
AM, PM & SQAR tracks the action items till their closure.
PM shall keep the PMR presentation in project central repository for future reference and usage.


Number of PMR action items identified
Number of PMR action item open







Global Delivery Head
Head Business Excellence
Support Functions
Account Managers
Project Managers
Project Team
SQAG


PMR Action Items
PMR Presentation

Periodic Reviews and Audits are conducted in order to ensure Process Compliance
Software Configuration Management Procedure
Software configuration management (SCM) is a project control procedure for management of software
products in order to ensure product integrity and traceability throughout the project’s life cycle.
Preparation of the SCM Plan
 PM shall prepare the SCM Plan ( Part of the D&Q plan)
 PM shall identify the Software configuration control board (SCCB) consist of
Controller (CC), PM, AM & Client (Optional)
Configurat
Identify Configurable items

To maintain accountability, integrity, Visibility, traceability, reproducibility , PM shall identify th
configurable item (C.I’s) based on the following criteria :





Products that are delivered to the customer
Internal work products like SRS, SAD, HLD, Data flow diagrams, Test cases
Acquired products from the customer like tools, standards, templates, test data
Other items that are used in creating and describing these work products like records and reports
Process performance Model output
Configuration Control
 The CC shall provide the appropriate access rights to the team depending on the role of the team members
 The CC shall review and ensure that the configuration of CIs is being controlled throughout project life cycle to main
the integrity and correctness of CIs. All CIs shall be labeled & commented properly
 CC shall maintain a log of changes and reasons for changes as appropriate. These details could be viewed thro
revision history of CIs using configuration tool
 In case the code is being managed by both customer and Birlasoft, the team will maintain and baseline the code
which we are working as a back up and history

In case the team is working directly on client instance & Birlasoft team is restricted to keep copy of code then in tha
case project team will maintain and manage all other documents except code in configuration tool
Change Control

The changes in CIs are consequences of one of the following:




Requirement change request (RCR)
Problem report (PR)
Defects
All the RCR/PR are handled as per the change management procedure (BSL/PRO/10)
Configuration status accounting

Configuration status accounting is a means of recording, managing and reporting the changes to software items durin
the entire life cycle of the project.

CC shall prepare the below mentioned reports to maintain status accounting



Change request summary and status (Q252)
Problem report summary and status (Q252)
Results of software baseline audits
Configuration Audits


SQA Lead conducts SCM audit (Part of PHI template)
PM conduct Baseline audit using Baseline audit Checklist.
Backup and Recovery The frequency for taking backups will be defined in the SCM plan in the DNQ plan usually as
follows :



Daily Back up
Incremental Back Up
Full back of all CIs on delivery
Risk Management Process
This Risk Management process defines the steps for risk identification &
managing risks in a project.
This process details out steps for how to identify the risk, prioritizes the
risk factors according to both the probability and the consequence of
failure and develops a risk management plan to implement strategies to
deal with those risks.
Risk Identification

PM Identifies the risks associated with cost, schedule, and
performance in all appropriate life cycle phases in a project.

Typical risk identification methods include the following:






Examine each element in work breakdown structure
Interview subject matter experts and stakeholders
Review risk related to similar products available in Organization
Project database (OPD)
Examine lessons-learned documents or databases
FMEA (Failure Mode Effect Analysis)
Taxonomy Based Risk Identification (Birlasoft/CHK/48)
Risk Sources & Categories
 Following are some of the Risk Sources needs to be considered
while identifying the risks associated with the project.











Estimates
Technology
Resource
Suppliers
Customer
Process
Requirements
Design
Coding
Testing
Categorize risk to provide a mechanism for organizing risks as
well as ensuring appropriate scrutiny and management attention
under following heads



Schedules
Cost
Performance
Risk Parameters
 Parameters for evaluating, categorizing, and prioritizing risks
include the following :



Probability of occurrence (Scale 1,3,9 (Low, Medium, High))
Severity if risk takes place (Scale 1,3,9 (Low, Medium, High))
Detectability (Scale 9,3,1 (Low, Medium, High))

The risks identified are analyzed, categorized and prioritized
based on the Risk Priority Number (RPN) and updated in D & Q
Plan.
Risk Mitigation Plan
 PM Prepares the risk mitigation & Contingency plan for a given
risk which includes techniques and methods used to avoid,
reduce, and control the probability of occurrence of the risk, the
extent of damage incurred should the risk occur or both.
 PM have options for handling risks typically include alternatives
such as the following:





Risk avoidance: Changing or lowering requirements while still
meeting the user’s needs
Risk control: Taking active steps to minimize risks
Risk transfer: Reallocating design requirements to lower the risks
Risk monitoring: Watching and periodically reevaluating the risk for
changes to the assigned risk parameters
Risk acceptance: Acknowledgment of risk but not taking any action
often, especially for high risks, more than one approach to handle
risk is generated.
Review of Risks
 PM shall review the risk management plan periodically to re-


examine & update the existing risk mitigation and contingency
plan (If required)
Risk management strategy is reviewed with relevant stakeholders
to promote commitment and understanding.
Risk Management plan is reviewed in team & management
reviews.
Threshold of Risks
 PM shall identify the threshold limits for all identified risk in
D&Q Plan.

The categories of risks for which the expected total RPN value is
between Baseline and 2 X base line value is reviewed in PMR or
in event driven meetings.

The categories of risks for which the total RPN value is above 2 X
base line value shall be reviewed by Global Delivery Head.






Risk Priority Numbers (RPN)
Risk identified at early stages
No of planned Risk
No. of actual Risk
Effort spent on identification and analyzing of risks
Effort spent on Risk management planning












Tower Head
Account Manager
Project Manager
COE (Center of Excellence)
Presales
Business Excellence
Support Functions
Sales
Pre Sales team
Global Delivery Head
Risk Management Plan
Periodic Reviews and Audits are conducted in order to ensure
Process Compliance
Sales Procedure
This procedure applies to the Sales team across all geographies.
Market Segmentation



The sales team along with Pre-Sales would define the Market Segmentation for Geography to
market using SWOT analysis.
Create tool kit for each of the service offerings.
Create brochures/presentations for domain/technology segmentation
Lead Generation
Lead Generation would happen through the following :

 Cold Calling
 Campaigns
 Events
 Internet Events/Webinars
The lead information is entered in Siebel CRM OD workflow application(WINGS) by BRM
Direction Setting Call

Direction Setting Call begins from qualified lead getting into a mature stage of Opportunity. Th
pre-requisite for this call is where strategic or tactical direction is required. (Refer Direction
Setting Call Procedure for details)
Closing process



The sales team would close the deal as per Approved OAP Guidelines as per Authorization manu
from finance team.
Estimations received from pre-Sales are taken. No changes to estimates can be made by Sales
The deal details are updated in WINGS system.
Handshake with Delivery

Sales team will hand over the documents using Handover-Takeover Sales to Delivery Checklist
with following details :
 RFP
 Proposal
 Contract copy/MSA copy
 Signed SOW
 Deal Qualification Sheet
 Account Management Plan
Account Management

Sales team will map the Customer account using Account Business Plan covering :






Organization Structure
Technology Stack of the client
Client business
Competition Analysis
Past History
SWOT Analysis
Contract/SOW Review

Contract/SOW review must be carried by Legal, Business Excellence Delivery before signing of









contract using Contract review checklist for Legal/Technical as per the SOW review Procedure
Every time an extension or revised scope, addendum is submitted for review.
Number of leads Generated.
Number of direction Setting Calls (DSC)
Number of Leads successfully realized.
Sales / BRM
Global Delivery Head
Presales Team
Account Manager
Business Excellence


Filled Estimation sheet
Account Business Plan
Approved OAP

Sales process shall be audited as per the Internal Quality Audit Procedure

Metrics Procedure
The scope of this process covers the description of all the standardized metrics across the organization, intent & use of these
metrics and the Storage procedures. It also covers the analysis methods for each metric, their interpretation and communicati
to identified persons.
Measurement objectives

Organizational objectives are identified as the Big Y.

Client Specific objectives are established at the time of startup of every project and hence they are generally dist
for each project.

Projects measurement objectives are derived from organizational objectives, client specific objectives and object
identified by project team.

The key objectives of the measurements are






Measuring and monitoring the performance
Effective decision-making
Completing the project successfully within given targets
Provide baselines and benchmarks for the future projects to have better estimates and predictions
Data to assess process stability and capability
Identify opportunities for improvement
Data Collection and Storage

PM shall collect & store the metrics data as per defined frequency as mentioned in D&Q Plan.

SQAR shall review & validate the metrics data using the integrated checklist in Baseline sheets.

BEPG shall consolidate and verify the metrics data shared by SQAG.

BEPG Shall store Organisation capability baseline (OCB) data in Centralized repository as per BEPG Plan.
Analysis and Results

Assess the collected data based on the following Criteria :




Verity
Synchronicity
Consistency
PM shall prepare the control chart for each metric and interprets the results.
Communicate the results

Metrics coordinator shall communicate the Project Metrics Results at organizational level as per defined frequency.
Transition Strategy

The Projects shall transit from the old baselines to the New Revised baselines whenever there is a new capability
baseline released & update their project goals accordingly.


Effort spent in Metrics data collection and analysis
Corrective and Preventive actions taken based on the metrics analysis.








Business Excellence Process Group (BEPG)
SQAG
Project Team
Project Manager
Account Manager
Senior Management
Updated Project Development/Maintenance/QA Baseline sheet
Released organization capability Baseline Reports
Periodic Reviews and Audits are conducted in order to ensure Process Compliance
System Support and Administration
The purpose of this procedure is to describes the process of
system support and administration in order to have a control
on hardware (H/W) and software (S/W) in the organization.
The system support also includes preventive maintenance of
machines, virus and identification checking, and backup
archival & retrieval of software.
Management of Hardware and Software


System Admin team maintains details of Hardware Allocation as per
User resource form (Q227) filled by the user during receipt of the
hardware.
Every user will be allocated not more than ONE machine. Only servers
may remain unallocated to any particular user, but may be allocated
to Projects.
Support on Hardware and Software


Employee can log service request by using Maximo Helpdesk
The helpdesk service engineer shall attend the problem & provide


resolution within defined SLA.
A monthly analysis report shall be generated from and maintained by
the System Administration.
Track of all pending calls is kept and is followed up with service
agencies by the system admin team.
Software Backup and Restore






During installation of software, the software librarian shall issue only
backed up media & update “Software issue register”.
System admin team shall take daily differential and full backup of
central VSS server on every Friday.
PM shall be responsible to ensure that proper backup / archive is
taken on off-line secondary storage media.
PM shall ensure that whenever there is an environment change,
structural change in the database, the backup of the server is taken.
The configuration controller of the project will be responsible for
taking the regular backups and maintaining the backup log (wherever
VSS tool is not used)
The backed-up media is maintained by system admin team in a
fireproof location.
Archival and Retrieval
 PM shall submit two copies of the product/software/application for
archival form (Q224)to the software librarian on completion of the
project.
 The archives shall be maintained for a period not less than 3 years or
as stated in the Project contract.
 Whenever a need arises for the software/product/application from the
archival, form Q285 shall be filled up to retrieve the material.
System Checking for Viruses
 System Admin Team shall do virus checking on all computers, and if
found shall clean the virus.
 The results of virus checking shall be filled up in virus checking form
(Q236) by the Helpdesk team and the signature of the user shall be
taken.
System Security
 Employee can access Organisation resources by obtaining their user ID
to logon to the network and systems.
 Every employee shall abide by the company’s Acceptable Use Policy
 All systems should be protected with power on passwords
 Floppy disk drives & all sorts of removable media is restricted in the
premises.
Preventive Maintenance
 Preventive Maintenance shall be carried out once in six months as per
the schedule prepared by Site Manager – Systems.
 The System admin team shall randomly check to verify the correctness
and effectiveness of preventive maintenance done by the external
vendor & record his observations in preventive maintenance
verification form Q234.





Server uptime
Project support/software complaint resolution time
LAN uptime
Leased line uptime
Internet connectivity uptime

All Birlasoft Employees






Completed archival/retrieval form (Q224)
Completed H/W, S/W resource requisition form (Q227)
H/W and S/W release form (Q295)
Completed hardware stock entry register (Q228)
Completed software stock entry register (Q229)
Completed preventive maintenance form (computers)
(Q231)
Preventive maintenance form (printers) (Q232)
Preventive maintenance form (Hubs & switches) (Q233)
Preventive maintenance verification (Q234)
System correctness and identification (Q235)
Virus checking form (Q236)





The System administration and Support Process shall be
audited as per the Internal Quality Audit procedure
Project Initiation and Planning Process
The objective of this procedure is to describe the process of Project
Initiation in project start-up phase. It includes the activity of having
Tollgate Reviews within the Project Start up time. It is also required that
the affected groups are informed about the project initiation through
project initiation mail through ESA.
Project Initiation & planning

Project shall complete Project initiation and planning activities
at the start of the Project as mentioned below :









Execution of Process performance model for development projects
and large enhancements in Maintenance projects
Identification of Risks for the Project along with its Risk priority
number (RPN)
Preparation of Project Plan and approval from Client
Review of Statement of work (SOW) which includes Business
Excellence and Legal Review
Set up of Project in PPM 7.1/Kintana
Identification of Project Goals & SLAs of the project
Preparation of PDSP & DnQ plan. PDSP should have all the tailoring
which are required for the project
Identification of Change Management Process & Templates
Project Kick Off Meeting with the objective of sharing information
& taking commitment from the project participant’s on scope,
risks, methodology, delivery schedule etc.
Tollgates- Check for Process Adherence

Tollgate 0 happens on the 5th working Day of Project
Initiation in ESA

Tollgate 1 happens on the 15th working Day of project
Initiation in ESA

Project Initiation Mailer is received to all the relevant
stakeholders & the Process owner

SQAG maintains a tracker for scheduling for Tollgate 0 & 1

Tollgate Review Dashboard is released by the Process owner
telling the status of the Tollgates

Tollgate 1 is NA for Staff Augmented Services (SAS) Projects
Release of Dashboards



Stakeholders shall receive Tollgate Review Dashboard within
1 day of the Tollgate reviews
Stakeholders shall receive Monthly Tollgate Review
Dashboard in first week of every Month
Stakeholders shall receive an Escalation Dashboard for the
Projects which have not cleared the Tollgates within the SLA
timelines in first week of every month


Process level Sigma Value at Organization level




Tower Leaders
Account Manager
Project Managers
SQAG

Tollgate Zero and One are Cleared
Periodic Reviews and Audits are conducted in order to ensure
Process Compliance
Customer Complaint Process
A Complaint is defined as a response/feedback from customer wherein the
customer expresses his unhappiness or reports unsatisfactory performance
by the product/services supplied to him.
This document describes the process to be followed on receipt of a
customer complaint.
Documenting the Complaint


The recipient of a customer complaint shall document the complaint on the
Customer Complaint Form (Q268).
The recipient of the complaint shall send an acknowledgement of the complaint to
the customer .
Complaint Handling



The Department/Project/Account concerned shall take remedial/corrective action
depending on the nature of the complaint .
The Department/Project/Account taking actions shall write the corrective and
preventive actions on the complaint form (Q268).
The resolution/reply of the complaint shall be sent to the customer, with a copy to
Head Business Excellence.
Identifying Corrective and Preventive Actions

The Department/Project/Account attending to the customer complaint shall
conduct root cause analysis and should take suitable corrective and preventive
actions in adherence to the Causal analysis procedure.
Complaint Followup and Tracking





PM, AM and Department Head shall follow up for closure of the customer
complaint for department /project/Account respectively.
Delays in closure of the complaint shall be escalated. Closure SLAs and Escalation
mechanism needs to be referred as per Escalation Management process.
SQAR shall audit the project for tracking of closure of the customer complaints.
Total number of customer complaints
Number of customer complaints where the resolution time exceeds the defined
SLAs

CXO

Tower Leaders

Global Delivery Head

Marketing Team

Account Manager

 BRM/Sales
COE Leaders







GEO Leaders
Business Excellence
VOC Champion
Causal Analysis form
Corrective and Preventive action
Closed customer complaint
The Customer Complaint Process shall be audited as per the Internal Quality Audit
procedure
‘
Estimation Process
Estimation process applies to the process of estimating size, effort and cost required
for executing any or all phases of software development project. This estimation
process is applied during the Proposal Preparation and at any time the estimate is
required to be revised during the project life cycle.
Determine the Scope of Work/Requirements

During Proposal stage , identify scope and measure in terms of
functional/business areas, performance criteria and constraint.

At proposal stage, identified ESTIMATOR prepares the level 0 estimates&
reviewed by the respective identified REVIEWER from COE.

During the execution of the project, the PM revisits the estimate and after review shares it with
the client

The requirements are decomposed into functions during the execution of the
project which is a Level 1 estimate
Effort Estimation

Effort is estimated on basis of the organizational productivity (when
estimated through FP/ UC point methods) or through the complexity method
for each of the COE when size factor is not used

Consider the following factor while doing estimate:










Expertise available in the target business area
Expertise available in the target technical environment
Training requirements specific to the project
Dependencies on the client for input documents, feedback and approval etc.
Potential idle time based on activity interdependency
Impact of project size, project complexity and project schedules on project
management / Quality Assurance & Control activities.
Impact of Risk on estimated efforts
Document the basis of the productivity
Determine phase wise effort
Duration is arrived from the effort and the resources who will be allocated for
the project
Resource/Cost Estimation

On the basis of skills/grade of professionals, travel/onsite
stay/communication

Hardware and software costs

DQT template is used to arrive at the cost estimation
Documenting the Estimates

Estimation Sheet has to be prepared by selecting the models in QMS
applicable for the project/proposed project once all the factors have been
analyzed

Different for Maintenance Projects/ QA projects
Review and Approval of Estimation Sheets

Approved by COE Head, Tower Head at the proposal stage
 Reviewed by the Account Manager and COE Reviewer at execution stage
 Review carried out in accordance with the Review procedure (BSL\ENG\01)

Review comments are recorded in Estimation Review log (TPL 278 Estimation
Model Review Log)

Approval after review comments are incorporated


Effort spent on preparing estimation sheet, OAP sheet
Additional risks identified





Account Manager
Project Manager
COE (Center of Excellence)
Team Leaders
Presales

Reviewed & Approved Estimation sheet

Periodic Reviews and Audits are conducted in order to ensure Process
Compliance
Statement of Work (SOW/Contract/MSA) Process
This Process identifies the applicability and impact of the contractual clauses before it
is sent to the Client for formal signoff.
This process also ensure review from legal and technical coverage perspective.
Receive the Purchase Order (PO) from the Client

The BRM /Sales SPOC communicate the high level details of the project and
share the Purchase Order to the Account Manager.

BRM shall prepare Master Service Agreement (MSA) which will be duly
reviewed by Head - Legal.

Sales/BRM shall provide the filled up commitment log for all verbal/
additional commitments made to the client to the delivery team.
Project Initiation in ESA

AM shall request for project code creation to Business Excellence.

Business Excellence team shall create project code based on prerequisites as
follows :





Billing base PO has to be shared as evidence for Billing base by AM
PM shall provide the ESA snap shot to PMO for validation
For New Win – MSA review record by Legal
DQT Sheet along with approvals as per the Executive Summary and Approval tab,
it shall be shared with *DQT repository group in which BRM/sales person has to be
in loop.
PM shall share the name of the Account to ESA SPOC
Handover Takeover activity closure with Sales and Delivery

The HOTO shall take place between Sales and Delivery within 2 working days
of Project Initiation in ESA.

BRM shall handover Proposal, DQT, MSA, MSA review record by Legal and the
communication mails between client to AM as part of the HOTO.
SOW creation by Delivery

PM shall prepare the SOW by taking inputs from the BRM/Sales SPOC. The
SOW has to be created before Tollgate 0 which is conducted within 5 days of
Project Initiation in ESA .

AM shall perform self review of SOW from Technical, Legal, Financial and
Business perspective.

PM shall incorporates the review comments and the comments are tracked to
closure. For the New Win , the solution shall be reviewed by the COE.

AM shall share the self reviewed SOW with the Business Excellence SPOC and
Legal team for review.

BE & Legal team share the review comments inthe Contract Review Log
template.

PM shall incorporate all review comments & track them towards closure
Deliver & Sign off

BRM sends the reviewed & approved copy of final SOW to the Client for

signoff.
SOW is signed off by the Client. From Birlasoft, the SOW is signed off by Sales
SPOC with the signature







Number of
Number of
Number of
Number of
Number of
Number of
Number of







Tower Head
Account Manager
Project Manager
Head Legal
Business Excellence
Business relationship Manager (BRM)
Pre Sales team





Contract/SOW review records -Technical
Contract/SOW review records – Legal
Contract/SOW review process monitoring Dashboard
Contract/SOW (SOW) updated with review comments
Contract/SOW Issue Tracker

Periodic Reviews and Audits are conducted in order to ensure Process
Compliance.
SOW received for review before client sign off
SOW received for review after client sign off
SOW received after delivery sign off to Legal and technical review.
defects observed.
defects closed.
SOW sent to the client without verification of review records
SOW sent to the client after verification of review records
Causal Analysis & Resolution Process
This procedure defines the methodology of identifying and analyzing the
causes of defects and other problems during the execution of the projects and
taking suitable actions to correct those types of defects and problems to
prevent them from recurring.
Triggers for Causal Analysis

Customer complaint

Defect trend analysis at organization level

Output of process performance model (PPM)

Non compliances found during process audits

Total no. of Change request raised are more than five

If top risks affect the Project goals

At Project phase end

After each review/test cycle

At project closure
State the Problem

Project team shall Collect the data for causal analysis and Document the
problem in the Causal Analysis form (Q272)
Conduct Causal Analysis

Conduct the causal analysis using causal analysis techniques as per
“Causal analysis guidelines” (Birlasoft/GUD/06)

Identify all the causes of the problem in the Causal analysis form
(Q272).

Out of all the Identified causes, identify the root causes using PPM
and use process performance baselines for predicting most likely
root cause.

Identify corrective and preventive action (CAPA),prioritize their
implementation.


Conduct cost benefit analysis to achieve intended results.
Update Project define software process (PDSP) for changes in
project defined process and OSSP (organization standard software
Process)for bringing organization level process improvements.
Tracking and Evaluation of Actions

Use PPM to determine if the change has positively contributed to
meet process performance Objectives.

Pre Causal and Post Causal data is evaluated statistically to validate
that change is significant.

All CAPA shall be tracked for their effectiveness on a weekly basis
by monitoring their trends.

Based on the positive trend, CAPA can be further analyzed &
implemented at the organization level.

Analyze anticipated and Actual benefits by implementation of CAPA.
CAPA – Organization level improvement

CAPA may result in process improvement, which can be taken as
the Process Improvement Proposal using six sigma technique.
Defect Analysis at Project level :
PM shall do the project level defect analysis on the basis of :

Severity of the defects

Technical classification of defects

Causewise classification of the defects
Defect Analysis at Organization level
 Metrics team will analyze the defect data at the organizational level
for all the buckets such as SDLC, Maintenance and QA.

Metrics team shall prepare the Defect Prevention Plan for each
quarter
&
track
the
Defect
Prevention
Strategies
at
the
organizational level.

Metrics team shall conduct the causal analysis on the most common
cause of defect for the different buckets on quarterly basis, as per
Defect Prevention plan.
Review of Corrective & Preventive Action

Business Excellence shall present the statistical report on
effectiveness of CAPA during Management Reviews.

Metrics team shall disseminate the knowledge and actions taken
though
this
process
and
management
reviews
organization.


Effort spent on causal analysis

Reduction in rework effort

Process performance before and after Causal Analysis
All Birlasoft Employees
across
the

Corrective and preventive actions

Defect Analysis Reports (SDLC, Maintenance, QA)

Corrective and preventive actions result disseminated

Pre Causal and Post Causal Data

The Causal Analysis & Resolution Process shall be audited as per the
Internal Quality Audit procedure
Management Review Process
This procedure defines the system to review the continuous suitability and
effectiveness of the quality system as related to company’s business activities
as well as to set objectives and goals for qualitative improvements.
Management Reviews and Frequency
 Management Reviews shall take the form of a meeting to be presided over
by Center Head at each location
 Center heads shall inform all the participants. Management Review Meeting
shall be attended by the following:
1.
Location Level :
 Centre SQAG SPOC
 Head of Functions (Delivery Groups, HR Resourcing, System Support and Administration,
Training) for respective location
 Account Managers -Projects
2.
Corporate Level :



CEO, CFO, Head HR, Tower Heads, GEO Heads, Delivery Heads, Function Heads, BE Leaders
will preside of the session.
Representatives of respective Functions should attend the meeting in absence of any one of
the above
Global Delivery Head shall allow any other person to attend the meeting, if so requested,
by any of the designated participants.
Management Review Meeting Agenda

Center Head shall prepare the agenda of
Functions atleast one week in advance

The agenda shall normally
















MRM
in consultation with Head of
comprise of :
Review of open items from last meeting
Operation of the company in relation to the status of implementation of the QMS
Organization capability Baselines against defined targets
Causal Analysis Findings
Trends/ Predictive Analysis from Process Performance Models
Summary of assessment of internal audits conducted
Statistical data on customer complaints & their redresses
Training Needs
Evaluation reports of Projects (current / closed) during the period
Corrective & Preventive Actions taken
Policy Issues
Status of Defect Prevention activities
Decision Analysis action items if any
Status of DMAIC projects and process improvement activities
Any other areas of Concern
MR is responsible to highlight non-conformances that are contributing to
in-ordinate delays in its closure.
Minutes of Meeting

Center Head shall ensure that the minutes of Management review meeting
along with actions items recorded. Copies of minutes shall be made
available to all designated participants.

Head of respective functions are responsible for timely and effective
implementation of actions. These actions shall be reviewed in the next
meeting.
Tracking of Closure of Action Item

Center Head shall keep the track of the closure of Action Items as discussed in
Management Review Meeting. Deviations are to be escalated to Global Delivery Head
in next Management Review Meeting.



Number of Non compliances raised in MRM
Number of open and closed action points of MRM
Number of participants present and absent in the MRM

CXO

MC Members

Global Delivery Head

Head of Functions

Management Representative (MR)

SQAG SPOC

Account Manager

COE Head

Tower Leader



Minutes of Meeting with Action Items
Management Review Presentation
The Management review procedure shall be audited as per the Internal
Quality Audit Procedure
Handing/Taking over of Charge
This Procedure describes the method of handling the Handing/Taking Over
of Charge method at organization level. It also caters to special situations
where only taking over of charge happens on account of the absence of
handing over employee.
Assign resource for taking of charge

Account Manager shall define the scope and extent of transfer. He shall identify
the replacement who will take charge from the outgoing employee.
Handing/Taking over of charge





The outgoing employee shall fill form Q219 to report all issues / concerns, pending
work, list of hardware / software and documents being handed over within the
scope of the transfer.
The outgoing employee provides orientation to the incoming employee on
important issues.
The incoming employee needs to ensure that he stands apprised of all issues /
concerns and relevant data is taken by him is in order.
Both employees shall review and sign the completed form Q219.
In case of handing over includes multiple people, then separate Q219 should be
filled for each incoming employee.
Taking over of charge

In case outgoing employee is not available for handing over the
responsibilities, then AM shall assigns the incoming employee all the
necessary responsibilities including issues and open work items.

The incoming employee shall identify & discuss risks/issues along with AM for
mitigation strategy.
Incoming employee shall sign form Q219.

Risk Assessment


Identify risk which affects the project execution due to change in responsibilities
as per the risk management procedure.
AM Shall approve the form Q 219.
Inform Customer

Inform the customer the change in responsibilities with complete information
about the incoming employee. (Applicable for A4 and above)
Appraisal


AM along with PM shall do performance appraisal as per organization practice.
IF PM is the outgoing employee, then he shall appraise all team members before
leaving the project.
Relieving of responsibilities

On completion of all formalities ,employee is relieved of all responsibilities and
confidentiality issues if any.
Maintenance of Q219

The incoming employee shall maintain form Q219 in the project file.


Effort spent on handing/taking over in any project.
No. of handing/taking over that took place in any project .

All Birlasoft Employees


Complete & signed Handing/taking over form Q219
Appraisal forms Q271 (If applicable)

The Handing/Taking over of Charge procedure shall be audited as per the Internal
Quality Audit procedure
Decision Analysis and Resolution
Decision analysis is a process by which one can select the best option out of different
alternatives available based on certain parameters. Not every decision is significant
enough to have a formal evaluation process as this process is costly.
This procedure also explains approach, Methods for decision analysis and how to select
the best from different alternatives.
Identify Areas for Decision analysis

Some of the areas where there may be a need for formal decision analysis :





Risks with High exposure
Selecting the architecture
Use of reusable components
Selecting suppliers
Any big business decisions where cost is very high
Plan for the Decision Analysis & Resolution (DAR)


DAR activities are planned in D&Q Plan for successfully identifying the best
solution
Identify the relevant stakeholder along with their roles and responsibilities.
Identify Alternative Solutions

Take input from different stakeholders

Document rationale for evaluating identified alternatives
Select Criteria for Evaluation

Identify the evaluation criteria which are going to impact the decision into
the following three categories :



Functional requirements
Non functional requirements
Legal requirements
Select Evaluation Methods
Few options for evaluation are as follows :

Brainstorming method

Voting/Survey method

Prototyping

Simulation

Decision Tree

Process performance model
Comparative Evaluation of Alternatives

Identify, evaluate and document all the assumptions.

If process performance Model is used for identifying best alternative, it
statistically evaluates the alternatives.

Evaluate identified alternatives based on the evaluation criteria and the
methods.

Identify the weightage for each factor based on the priority and importance.

Calculated the scores by summing up the multiplied weight and rated value
for all the parameters

Select the best solution from different alternatives.

Document the rationale for selecting the best solution

Identify the risks associated with implementing this new solution
Approve the solution

Take the approval from the relevant stakeholders who are going to get
impacted by the decision


No. of Decisions taken by using formal Decision analysis process
Effort spent in conducting DAR





Project Managers
Account Managers
Business Excellence
Senior Management
Global Presales

Rationale for selecting the best alternative

Decision analysis matrix (Filled template)

Periodic Reviews and Audits are conducted in order to ensure Process
Compliance
Document Change & Control
The purpose of this procedure is to define and lay out the guidelines for
initiation, authorization & implementation of change requests for all in Quality
Management System (QMS).
QMS includes Quality Manual, Policy, Process Handbook, Procedures, Templates,
Guidelines, Checklists, Standards, Tools, Forms Training Material and Sites)
Initiate Change Request

Employee raise request to Business Excellence Process Group (BEPG ) through On-line
QMS Feedback System available at Kmantra

Changes to QMS are triggered through :



Improvement suggestion proposed by any employee.
Analysis & recommendations of software process assessments
Analysis of Defect prevention /Causal analysis activities.

Inputs from Learning database at organization level.

Result & analysis of project tailoring database at organization level

Analysis of project tailoring database at organization level

Analysis of Process and product measurement data

Process improvement Initiative (Six sigma Projects)



Internal / External audit/assessment results
Incorporate Industry best practices
Internal Business Excellence team review
Review and Approval of Change Request

BEPG evaluates all the document change requests and process improvements
as per Document Generation Procedure

Based on the impact analysis BEPG accept/reject/deferred the change
request & update the requestor accordingly.
Change in Process Document

Head BEPG shall assign the approved change request to BEPG team member/SME for
detailed impact analysis and modification of affected process artifact.

Assigned team member shall checks out assigned document from Working folder in
VSS and make changes as per the change request.

Author is required to update version number & modification history detailing the
specific changes made in the document.

The modified document is then subjected to Peer review/SME review as per the
Procedure Index (Q319).

QMS Training material is updated appropriately to reflect the changes done in the
QMS.

The review comments are logged in Q205/Defect Tracker and tracked towards closure.
Baseline of Process Document

CC shall baseline the reviewed and approved artifact in VSS & on KMANTRA and update
the QMS Release Note (Q320) for the new/updated documents with the latest Version.
Release of QMS

Management Representative (MR) approves QMS Release Note (Q320), which includes the
details of all baseline artifact available in QMS.

QMS release is done periodically and communicated to all employees through mail along
with the QMS Release Note (Q320) & Deployment Plan.

BEPG shall plan and conduct awareness sessions to ensure implementation of the newly
added/modified documents in the projects.

Number of Change request received

All Birlasoft Employees

Approved & baseline Artifact in QMS

Training Material
The Document Change & Control Procedure shall be audited as per the Internal
Quality Audit procedure
Product Integration Procedure
This process defines the sequence for integrating various modules/ Product
components in an orderly manner to ensure that the end product meets all the
requirements specified by the customer.
Integration Sequence
Project Team shall



Identify the Product components to be integrated and the verification of the
same.
Identify alternative product integration sequence if there are more than one
layer of integration.
Apply Decision analysis and resolution (DAR) technique & choose the best
sequence (Refer DAR procedure)
Integration Environment
Project Team shall


Apply DAR technique for taking the decision of Integration environment to
make, reuse, buy results
Create Integration environment if it is not acquired & need to be maintained
throughout the integration as per the future needs.
Product integration process

PM shall prepare product integration plan , which shall capture product
integration environment, criteria, all interfaces, steps of integration, criteria
for validating and evaluating product component for e.g. Levels of testing,
verification of interfaces, &final integrated products are to be validated and
delivered.

SME shall review the product integration plan.

PM shall update the review comments & get it verified by SME.
Assembling Product component
Project team Shall



Perform the assembly sequence as per Product Integration plan
Perform evaluation of the assemble product components
& record results.
Deploy and deliver the product as per deployment plan.






Number of defects Captured
Account Manager
Project Manager
Team Leader
Project Team
SQAR



Product
Product Integration plan
DAR Records

Periodic Reviews and Audits are conducted in order to ensure Process
Compliance
User Documentation Procedure
The Purpose of this procedure is to prepare Documentation that guides users
operating and managing software product being developed.
Preparation of User Documentation
Project Team Shall



Study the SRS & HLD Document to design the User Manual with all the S
Reports to be used as per client approved template.
Team Member shall prepare Online Help using the tool to facilitate quic
while working on the developed software product.
The Team Member shall prepare the Installation guide using the tool to
installation, operation covering the following,







Hardware Configuration
Operating System
Application Software
Networking
Pre-requisite data
Troubleshooting
Operating the system etc.
Review/Testing of User Documentation
The PM/TL shall review the user documents, as per guidelines for Review (BSL
the following,
 Style and Grammar
 Complete coverage of functionality as per Software Requirement Specif
 Test the document by installing and running the software using the docu
 The PM/TL shall record the observations and defects using defect Tracke
Closure & Verification of Defects


The Team Member shall close the defects and record the closure in the
Form.
The PM/TLshall verify the closure of Defects. The review report is close
PM/TL when all the defects have been rectified.
Baseline the User documentation
 Configuration controller baselines User documentation after PM’s approv




Total number of defects in the User Documents
Effort spent in preparing the User Documents
Review Effort
Rework Effort






Project Manager
Team Leader
Project Team
Testing Team
Configuration Controller
Technical Writer





User Manual
Installation Guide
Online Help Bundle
Quick Reference sheets
Updated Review Records (Q205)
Periodic Reviews and Audits are conducted in order to ensure Process Complian
Maintenance Procedure
Maintenance Procedure
The purpose of the Maintenance process is to manage the maintenance
projects in the organization. This may include all kinds of tasks
associated with the maintenance projects that is enhancement, bug
fixing and production support
Bug Fix and Production Support

Project Team shall
1. Analyze, collect and elicit stakeholder/client needs
2. Perform Size estimation for the work packet as per the
estimation procedure




PM review the impact analysis and assign the work packet to the
appropriate team member
Team member shall perform coding as per the code generation
procedure
Project team shall review and test the piece of code as per the
review and testing procedure using review checklist
(BSL/CHK/61)
Project team updates the requirement traceability matrix form
(Q284)
Enhancement tasks
PM shall decide & follow below mentioned steps depending upon the
scope in the project and the deliverables to the client as per the task
order

Project team analyze the work packet

Size estimation is performed as per the estimation procedure

PM shall assign the work packet to the appropriate team
member

Prepare design as per the design procedure. System and
Integration test plans will also be prepared (if applicable).

Design review shall be done

Perform Coding as per the code generation procedure

Integrate modules and interfaces, if applicable, as per Product
Integration procedure

Perform code review will be done as per the review procedure

Perform Testing as per the testing strategy mentioned in the
D&Q plan.
The Project team updates the requirement traceability matrix
form (Q284) mapping all the requirements to suitable sections.

Project Data Analysis (Applicable in all scenarios )

Project team shall record the project related data for Delivery
Variance, Effort Variance, Review Efficiency, Testing Efficiency
&client specific metrics (If any) as per project baseline template
for Maintenance project

PM shall analyze the data trends and document the
interpretation in the respective sheet of the Project Baselines
templates.

Project Team shall perform causal analysis and take corrective
action for any data point found beyond the targeted control
limits as defined in the Project objectives & Goals sheet (Project
baseline template)




Effort spent in completing the work packet
Rework effort
Review Effort
Testing Effort






Account Manager
Project Manager
Team Leader
Project Team
Testing Team
SQAR

Updated Work Packet

Periodic Reviews and Audits are conducted in order to ensure
Process Compliance
Implementation Procedure
This procedure describes the procedure for installing and commissioning the software
product and getting an approval from the client on successful running of the system
.The procedure also describes the training activity for the end users so as to facilitate
them in using the software product at the client’s environment.
Installing and Commissioning the Software Product
Project team Shall
 Port, convert or migrate the data to the accepted system as per the
contractual obligations.
 Install software & commissioned in the customer’s environment by creating
different directories and placing the files in them as per the Installation guide.
 Track all defects to closure using Q205.

Follow Change Management Procedure for any changes reported during the
Installation & commissioning.
Update User Documentation
 Update the user manuals and installation guide on completion in this phase.(If
applicable)
User Training


User Training will be conducted only if it is part of contract.
Define the scope/objective in terms of :







Complete System
Module/Sub-system
Installation procedure/manual
Prepare the User Training Schedule
Prepare the Training Material
Conduct training as per the schedule and take feedback from participants.
Take corrective action based on the feedback provided by the participants.
Sign Off from Client


PM shall be responsible for obtaining a sign off from client indicating software
product has been accepted.
PM shall ensure VOC of the project is raised and received.




Implementation Schedule (Planned Vs Actual).
Effort spent in implementation.
Rework effort.
No. of defects found in implementation phase.




Account Manager
Project Manager
Project Team
Client



User Documentation (If applicable)
Training material (If applicable)
Acceptance Sign-off communication (From Client)

Periodic Reviews and Audits are conducted in order to ensure Process
Compliance
Early Warning Process
The purpose of this process is to act as a proactive alert mechanism for delivery
function, wherein engagement and project level issues/Risks are proactively
identified and informed to the Senior management and ensure corrective /
prevention actions are taken.
Business excellence team shall publish the consolidated report/ Dashboard to
highlight early warnings effectively at appropriate levels and track them towards
closure.
Early Warning/Escalation Identification:

SQAG Tower Leaders identify the early warnings based on the below
mentioned parameters:

















Customer Escalation through any channel
VOC less than 4
Contracts/SOW not available
Missing SLA target in Production Support project
Missing milestones
No Plan available
Tollgate failure
High impact Risk
Audit NC not getting closed within Target Date
VOC not received
Requirements not agreed by client
PMR not done
If PHI Trend is dropping
SOW review comments not closed
FIR Failure
Customer Complaints
SQAG Tower Leader collates, categorizes early warnings as per “ROY”
methodology (Red – Escalation to CEO, Orange – to Global Delivery Head,
Yellow – to Tower leader).
Tower Level Dashboards:

SQAG Tower Leader publishes the dashboard on weekly basis to Tower
Leader.
Monitoring and Review

Tower Leader reviews the dashboard published by SQAG Tower Leader and
shares updates if any.
CXO Level Dashboard



SQAG Leader publishes consolidated dashboard on a weekly basis, in cases
where issues need CXO level attention.
CXO Level Dashboard includes all the issues from all towers which are
categorized as Red/Orange.
Global Delivery Head reviews the issue with respective stakeholders on
weekly basis.
Escalation of Issue from One Level to Next Level:



All customer escalations are tracked at least at GDH level till the time
issue comes under control.
For any Early Warning/ Escalation, If there is no update provided by PM/
AM for 3 subsequent weeks, it will be escalated to next level radar for
review.
Any open issue with aging >30 days at one level should be moved to next
level. However it can be moved back to earlier level if reviewer
recommends.
Issue Resolution:

For removal of escalations from the escalation dashboard, PM/AM shares
the evidence for the closure of the escalation; SQA Tower Leader verifies
the evidence and removes it from the dashboard.

Number of early warning issue reported by BRM/AM/SQAG
Issue Resolution Rate






Global Delivery Head
Tower leader
Business Excellence
CXO
Delivery




Project Manager
Account Manager
Sales / BRM
Support Function

Updated early warning Dashboard
Quarterly Analysis
Learnings


The Early Warning Process shall be audited as per the Internal Quality Audit
procedure
Client Visit Process
This procedure defines the client visit process at Birlasoft premises at all India location
offices. This procedure describes the activities to be performed, roles and responsibilities,
and data to be generated, collected and recorded.
This procedure is needed to ensure that all new/ existing client visits handled with
consistency and coordination among all support and delivery function as needed.
Client Visit – Planning Phase

Sales/BRM shall identify the client key objective &
(TPL-304-client key objective mapping)

BRM shall take the cost approval from their respective Tower Head.

BRM & AM shall specify any additional requirement for prospective client if any. Sales
team/ AM shall prepare the detail client visit agenda and share with all the relevant
stakeholders.

Sales/BRM shall prepare Dossier and agenda for the client visit (TPL-303-Client Visit
Agenda) and share with relevance stakeholders.
Admin team shall prepare the logistics plan and share it with Presales/ AM/ BRM for
review.
BRM/AM/ Presales shall decide on client visit modalities and presentation content. They
shall inform all the relevant stakeholders for the key presentation support required from
them.
AM/ BRM shall decide the master of the ceremony who will be responsible for:






Agenda with the visitors
Checkpoints during the mid sessions
Summarizing the various action points
expectation from Birlasoft as Per
Mobilization Phase







BRM/Sales shall collate all the presentation and ensure that final presentation is as per
the corporate presentation format as suggested by Branding / Marketing team.
Admin SPOC shall share the logistic requisition form with the sales team to confirm visit
requirement. (Refer Q376-Client visit logistic requisition form)
BRM/AM/ Presales shall coordinate for a dry run of presentation to ensure Key Messages
that have been identified & shall be delivered by the various Stakeholders as per stated
objective and expectation for the client visit.
The master of ceremony/BRM shall ensure that all presentations are complementing and
covering the agenda as per client expectation.
BRM shall set for Business Lunch /Dinner discussion agenda and send invites to intended
participants.
If Live Experience / Bay visit / Facility walkthrough visit is involved, BRM shall
communicate it to all relevant stakeholder including delivery and admin SPOC.
All stakeholders should provide their commitment for the client visit. The presentation
should be shared as per the SLA Matrix.
Conduct Phase




Sales team will present the dossier and sets the refined agenda with Client on his
arrival.
BRM/Master of ceremony will presents Company Overview, Enterprise Direction followed
by presentation session by stakeholders as per the detailed agenda
BRM/AM/Master of ceremony will present the Gifts and Memorabilia presentation
Sales/BRM SPOC will identify Actionable Items from the Client Visit and shares them with
relevant stakeholder.
Follow Up Phase




Sales/BRM shall prepare the detailed Client Visit Report and shares the same with
Management / Tower Leads.
BRM/Admin lead shall take the formal feedback from the client during wrap up session..
Sales/BRM shall monitors and tracks to closure all Actionable Items. Information is shared
with Sales and Client.
Presales/ BRM/AM Stores the Client Visit Presentations, Client visit Reports and Feedback
in centralized repository maintained by Presales team. All approved presentations shall
be uploaded at Kmantra for future reference.


Customer Satisfaction Index
Return on Investment










Sales/BRM
Presales
Account Manager
Project Manager
Delivery team
Administration team
Marketing team
Delivery team
COE
Practices


Human Resources
Business Excellence


Client Visit Detail agenda
Client feedback form
Presentations shared by Delivery/COE/support functions

The Client Visit Process shall be audited as per the Internal Quality Audit procedure
Acceptance Testing Procedure
This procedure describes the methodology of performing acceptance testing. It details
out the activities involved in acceptance testing including identifying the resources
and environment for acceptance testing, providing support for acceptance and getting
the final signoff from the client .
This procedure also describes the method of handling problems detected during the
acceptance phase and to take corrective action accordingly
Plan for Verification
Project team Shall,


Select the product component for verification.
Identify most suited Process Performance Model for Acceptance testing
(Manual / Automated) so that Project defined goal can be achieved.
 Identify the verification environment to ensure it can be carefully controlled
to provide for replication, analysis of results, and re-verification of problem
areas.
Application Set-up


The Project team shall set up the hardware servers, installation and
configuration of the operating system in consultation with the client.
The Project team shall install the Software product. Setup
Database, create user logins (If applicable)

Ensure that the baseline Integrated sub-systems/modules are installed
Conduct Acceptance Testing and Reporting

Testing is performed as per the Acceptance Test Plan.

The client shall performs the testing with the approved test cases. The status
is reported to the Project Manager/Program Manager as per the plan
Defect Reporting and Recording
 Project team shall record the details of all failed cases by recording in defect
tracking tool review /Q205 execution.

Update Acceptance test cases for the missing scenarios, change requests or
inconsistencies if any, and update the RTM accordingly.
Closure of Defects
 Project team shall close the defects as per the identified corrective actions.

PM analyzes and identifies the corrective action for the defects and update
test plan (TPL-25-testplan) and test cases (Q217) if required.


The Review Team shall verify the closure of Defects.
PM shall analyze the defect data at Phase end or at the end of each iteration
and corrective action shall be identified and tracked.
Change Control

Any changes initiated by the client needs to be recorded as change requests,
and the change control procedure needs to be followed (Refer
Birlasoft/PRO/10).
Bi-Directional Requirement Traceability Matrix
 The Project team updates horizontal and vertical traceability matrix form
(Q284).
Update User Documents

The user documents e.g. (SRS document, HLD, LLD) including the user
Manuals are updated based on changes /defects found during Acceptance
testing.
Acceptance or Sign Off from Client

Project Manager shall be responsible for obtaining a sign off from client
indicating software product has been accepted.





Total number of defects found in the application
Total effort spent in Acceptance Testing
Total duration/time spent in Acceptance Testing
Rework Effort
Defect Density at UAT






Account Manager
Project Manager
Project Team
SQAR
Testing Team
Configuration Controller

Client



Tested and updated Software product
Defect Test Report /Review record (Q205)
Acceptance Sign-off communication (From Client)

Periodic Reviews and Audits are conducted in order to ensure Process
Compliance
System Testing Procedure
The System testing procedure describes the steps followed after successful integration
testing is completed & all the unit processes making up the subsystem have been
successfully integrated.
System Testing include Regression Testing, Performance Testing, User Interface
Testing, Load Testing, Volume Testing, Stress Testing and Security Testing.
Plan for Verification
Project team Shall,

Select the product component for verification.

Identify most suited Process Performance Model for System testing (Manual /
Automated) so that Project defined goal can be achieved.
 Identify the verification environment to ensure it can be carefully controlled
to provide for replication, analysis of results, and re-verification of problem
areas.
Configure Testing Environment




Ensure that the baseline Integrated sub-systems/modules are installed
Configure the servers
Populate Master data (if applicable)
Hand-over the system to the Testing Team
Conduct Testing and Reporting

Testing Team Member shall conduct the System Testing as per the System test
cases .The TM shall record the actual results using Test Cases (Q217)

Testing Team shall perform the various categories of System Testing (Refer
guidelines for Testing Birlasoft/GUD/24)
Defect Reporting and Recording
 Testing team shall record the details of all failed cases by recording in defect
tracking tool review /Q205 execution.
 Testing Team shall provide detailed description of all the failed case in the
Defect Tracker. Team is also responsible for filling the complete defect details
including defect type classification.
 Testing team shall prepare the Test Report using Test Cases (Q217)
Closure of Defects
 Project team shall close the defects as per the identified corrective actions.

Corrective action may also result in updating test plan
(TPl-25) & System test cases (Q217)


The Review Team shall verify the closure of Defects.
Configuration Controller shall baseline the System Test Code based on PM’s

approval.
PM shall analyze the defect data at Phase end or at the end of each iteration
and corrective action shall be identified and tracked.
Bi-Directional Requirement Traceability Matrix

The Project team updates horizontal and vertical traceability matrix form
(Q284).




Total number of weighted defects in the application
Rework Effort
Effort spent in Test Execution
Schedule for System testing






Account Manager
Project Manager
Project Team
SQAR
Testing Team
Configuration Controller



Baselined Source code
System Test Cases (Q217)
Updated User Documents

Defect Test Report /Review record (Q205)

Periodic Reviews and Audits are conducted in order to ensure Process
Compliance
Integration Testing Procedure
The Integration testing procedure describes the steps for testing the functional
integration between the Unit Process/modules. It also tests the data flow between
them.
Plan for Verification
Project team Shall,


Select the product component for verification.
Identify most suited Process Performance Model for Unit testing (Manual /
Automated) so that Project defined goal can be achieved.
 Identify the verification environment to ensure it can be carefully controlled
to provide for replication, analysis of results, and re-verification of problem
areas
Configure Testing Environment






Configure the operating system
Install the Software
Configure the servers
Populate Master data (if applicable)
Build the application and install the same
Hand-over the system to the Testing Team
Conduct Testing and Reporting

Run process performance Model & take decision on whether Integration
Testing will be manual or automated and accordingly Unit Test Cases and Test
Script will be prepared.

The Testing Team Member shall conduct the Integration Testing as per the
Test Cases .The TM shall record the actual results using Test Cases (Q217)
Defect Reporting and Recording


Testing team shall record the details of all failed cases by recording in defect
tracking tool review /Q205 execution.
Testing Team shall provide detailed description of all the failed case in the

Defect Tracker. Team is also responsible for filling the complete defect details
including defect type classification.
The Testing team shall prepare the Test Report using Test Cases (Q217)
Closure of Defects


The Project team shall close the defects as per the identified corrective
actions.
The Review Team shall verify the closure of Defects.

Configuration Controller shall baseline the Integration Tested Code based on
PM’s approval.

PM shall analyze the defect data at Phase end or at the end of each iteration
and corrective action shall be identified and tracked.
Bi-Directional Requirement Traceability Matrix

The Project team updates horizontal and vertical traceability matrix form
(Q284).





Schedule of Integration Testing
Effort spent in rework
Number of defects captured
Number of defects in a particular functionality/Module.
Effort spent in Test Execution.






Account Manager
Project Manager
Project Team
SQAR
Testing Team
Configuration Controller




Baselined Source code
Integration Test Cases
Updated User Documents
Review record (Q205)

Periodic Reviews and Audits are conducted in order to ensure Process
Compliance
Preparation of Test Cases Procedure
This procedure is followed during the Requirement and Design Phase of the Project
and covers preparation of System Test Cases (STC) and Integration Test Cases (ITC).
Identification of ITC & STC
Project team shall,





Study the HLD Document and the Functional Model to understand
the functionality of the integrated sub-systems
Determine the Functional dependency between the Unit
Processes based on the SRS & HLD document.
Identify the interfaces and data inflow and outflow of each sub-system.
Identify the key principles, features, and phases for product or productcomponent validation throughout the life of the project.
Determine which categories of user needs (operational, maintenance,
training, or support) are to be verified and validated.
Preparation of ITC
The Project team shall prepare the ITC(Q217) taking into account the following :





Correctness


Sub-system functionality and interfaces mentioned in HLD document.
Functionality
Logic
Error, Exceptions and Boundary Conditions
Adherence to Standards and Guidelines for Test Cases (BSL/GUD/24)
Preparation of STC
The Project team shall prepare the STC,taking into account the following :
All the requirements in the Software Requirements Specifications have been
met.

Other requirements like performance, security, error recovery,
maintainability, portability and compatibility etc.
Review of ITC & STC

The Integration and System Test Cases shall be reviewed by the PM/TL, as
per Test case Review Checklist.


The Review Team shall record the findings in PPM/client specific tool/Q205.
The Project team shall close the defects as per the identified corrective
actions.
Closure of Defects

The Review Team shall verify the closure of Defects.

Configuration Controller shall baseline the ITC &STC based on PM’s approval.

PM shall analyze the defect data at Phase end or at the end of each iteration
and corrective action shall be identified and tracked.
Bi-Directional Requirement Traceability Matrix

The Project team updates RTM(Q284) to ensure Test Case coverage and
completeness with respect to SRS & HLD.
Approval & Baseline Code

PM reviews the final Code & submit to client for review.

Configuration controller baselines Code document after approval.





Effort spent in preparing the ITC &STC.
Effort spent in review
Total number of defects in the Integration test Cases
Total number of defects in the System Test Cases
Effort spent in Rework.










Account Manager
Project Manager
Team Leader
Project Team
Testing Team
Configuration Controller
Baselined Integration Test Cases
Baselined System Test Cases
Review Records (Q205)
Periodic Reviews and Audits are conducted in order to ensure Process
Compliance
Unit Testing Procedure
The Objective of the Unit testing is to ensure the steps to be followed to confirm that
it meets the functional requirements as specified in Program Specifications.
This procedure covers :

Testing of the user interface to ensure that information properly flows
into and out of the program unit under testing.

Examine the local data structure to ensure that data stored temporarily
maintains its integrity during all steps in Test Case execution.

Test boundary conditions to ensure that the program operates properly at
boundaries established to limit or restrict processing.
Plan for verification
Project team shall,


Select the product component for verification.
Identify most suited Process Performance Model for Unit testing (Manual /
Automated) so that Project defined goal can be achieved.

Identify the verification environment to ensure it can be carefully controlled
to provide for replication, analysis of results, and re-verification of problem
areas.
Conduct Unit Testing



The Configuration Controller shall move the Code to the Review/Testing area
for Unit Testing, on approval from PM/TL.
Conduct Unit Testing as per the Unit Test Cases as per the guidelines
BIRLASOFT/GUD/24.
Prepare the Test Report using Test Cases (Q217).
Defect Reporting and Recording
The Team Leader/Member other than developer of program code will :

Understand the functional specifications in HLD/LLD Document, program
specifications and unit test cases to understand the flow of the process.

Update the unit test cases for the missing scenarios or inconsistencies if any,
and update the Requirement traceability Matrix accordingly.


TL/ TM will record defects using Defect Tracker/ Q205.
The Configuration Controller shall move the code to the Working area for
update of code on approval from PM/TL.
Closure of Defects

Developer will update the program code and close the defects in the Defect
Tracker for the test cases executed as per test cases (Q217)

Developer will update the review comments and resubmit it for verification to
review team.

Developer will ensure the closure and verification of the defects by performing
another cycle of unit Testing.

PM shall analyze the defect data at Phase end or at the end of each iteration
and corrective action shall be identified and tracked.
Bi-Directional Requirement Traceability Matrix

The Project team updates the requirement traceability matrix form (Q284)
mapping all the requirements to suitable sections.
Approval & Baseline Code

PM reviews the final Code & submit to client for review.

Configuration controller baselines Code document after approval.





Schedule of Testing (Planned vs. Actual)
Effort spent in Unit Testing
Effort spent in rework
Number & type of defects captured
Number of Unit Test Cycles






Account Manager
Project Manager
Team Leader
Project Team
Testing Team
SQAR



Unit tested & baselined code
Review Log (Q205)
Periodic Reviews and Audits are conducted in order to ensure Process
Compliance
Code Generation Procedure
This procedure applies to the Coding and integration of the product (Code generation,
Code Walkthrough, Code Review and product integration).
Code Generation
Project team Shall,

Identify most suited Process Performance Model for generating code, so that
Project defined goal can be achieved.

Project team should check the reusable components repository for the
existing components that can be re- used in the project.

Project team write the program using program template and coding standards
as defined for the project.

Compile the program code.
Code Review

Review team shall review the Code ,RTM & method resulted from Process
Performance model execution.

Review is performed as per the code review checklist (BSL/CHK/07) and
traceability matrix for fulfillment of requirements.

The review team will record defects using Defect Tracker/ Q205.

The Project team will update the review comments and resubmit it for
verification to review team.

The review team ensures the closure and verification of the defects.
Bi-Directional Requirement Traceability Matrix

The Project team updates the traceability matrix form (Q284) mapping all the
requirements to suitable sections.
Tollgate Reviews


Conduct Tollgate4, phase1 at 20% completion of coding.
Conduct Tollgate 4 Phase 2 at 80 % completion of coding.
Approval & Baseline Code

PM reviews the final Code & submit to client for review.

Configuration controller baselines Code document after approval.






Schedule of Code (Planned vs. Actual)
Effort spent in review of Code
Effort spent in rework
Number of defects captured
Review Efficiency
Tollgate SLA adherence





Account Manager
Project Manager
Team Leader
Project Team
Technical SME



Reviewed & Updated code
Integrated product
Review Log (Q205)

Periodic Reviews and Audits are conducted in order to ensure Process
Compliance
Low Level Design Procedure
Low Level Design (LLD) Process focuses on detailing on the data structures and
algorithmic representation as presented in HLD. The system is broken down into
procedures/programs. The logical design is done for every program and Program
Specifications document is prepared.
Define Low Level Design
Project team Shall,

Identify most suited Process Performance Model for developing the LLD, so
that Project defined goal can be achieved.

Project team finalizes the physical structure of entities, optimizes the design
by de-normalization, and details out the physical data elements using HLD.

The Project team prepares program specification as per specified format.
(Refer TPL-15-LLD & TPL-16-LLD)
It contains details about different views such as database states/modes,
logical, functional, environment, build and security.(Refer Security Guidelines
for Web Applications)
Unit Test Cases and Test Scripts

Run process performance Model & take decision on whether Unit Testing will
be manual or automated and accordingly Unit Test Cases and Test Script will
be prepared.

Prepare Unit test plan and test cases using Q217 to cover the functionality of
the program unit as per LLD.

Exercise all independent paths through the control structure to ensure that all
statements in the code get executed at least once.

Test all error-handling paths.(Refer guidelines on testing for preparation of
test cases and scripts)
Bi-Directional Requirement Traceability Matrix

The Project team updates the traceability matrix form (Q284) mapping all the
requirements to suitable sections in the Low Level Design Document.
Low Level Design Review

Review team shall review the LLD ,RTM & method resulted from Process
Performance model execution.

Review is performed as per the LLD checklist (BSL/CHK/07) and traceability
matrix for fulfillment of requirements.

The review team will record defects using Defect Tracker/ Q205.

The Project team will update the review comments and resubmit it for
verification to review team.

The review team ensures the closure and verification of the defects.
Approval & Baseline HLD

PM reviews the final LLD & submit to client for review.

Configuration controller baselines LLD document after approval.





Effort spent in LLD (Planned vs. Actual)
Schedule of LLD (Planned vs. Actual)
Effort spent in review of LLD
Effort spent in rework
Number of defects captured





Account Manager
Project Manager
System Analyst
Team Leader
Project Team




Program Specification
Unit Test Cases and Test Scripts
Physical data elements (Technical Package)
Review record (Q205)

Periodic Reviews and Audits are conducted in order to ensure Process
Compliance
High Level Design Procedure
This procedure describes how High Level Design (HLD) is prepared (confirming to the
addressed agreed standards as mentioned in the D&Q plan), reviewed and approved.
Select and Develop Product-Component Solution
Project team Shall




Identify most suited Process Performance Model for developing the HLD, so
that Project defined goal can be achieved.
Define alternative solution and selection criteria using Decision Analysis and
Resolution (Refer DAR procedure)
Define an initial set of architecturally significant elements to be used as the
basis for analysis.
Define an initial set of analysis mechanisms for all non functional requirement
including Safety, Security, Performance etc.(Refer to Design Security
Guidelines)
Prepare the HLD with below details :




Define the Run-time Architecture
Define Distribution
Define Sub System Design
Implement the Product Design
Bi-Directional Requirement Traceability Matrix

The Project team updates the traceability matrix form (Q284) mapping all the
requirements to suitable sections in the High Level Design Document.
Prepare System and Integration Test Plan

The Project Team prepares the System Test plan, Integration Test plan ( TPL25-Testplan) & Integration test cases (Q217) and takes the sign off from the
client
Design Review

Review team shall review the HLD ,RTM & method resulted from Process
Performance model execution.


The review team will record defects using Defect Tracker/ Q205 .
The Project team will update the review comments and resubmit if for
verification to review team.
The review team ensures the closure and verification of the defects.

Approval & Baseline HLD

PM reviews the final HLD & submit to client for review.

Configuration controller baselines HLD document after approval.




High Level Design effort
Review Effort
Number of review comments
Rework effort





Account Manager
Project Manager
System Analyst
Team Leader
Project Team




High level design (HLD)
Updated Requirement Bi Directional -Traceability Matrix
System Test Plan and Test Cases
Integration Test Plan and Test Cases

Periodic Reviews and Audits are conducted in order to ensure Process
Compliance
Requirement Specification Procedure
This procedure describes how requirements are gathered, analyzed and elicited.
The main objective of the requirement analysis is to produce a document that
properly specifies all requirements of the customer. This process is applicable to
SDLC projects >300 person hrs.
Develop and Understand Customer Requirements
PM Shall



Identify most suited Process Performance Model for developing the
Requirement so that Project Defined Goal can be achieved.
Prepare Requirement Gathering Plan (Refer requirement Gathering guideline
for details)
Prepare Stakeholder request gathering template to identify Stakeholders need
and map it to the customer requirement.
Develop and establish product requirement




Align the project team in their understanding of the system and take the
commitments on the requirement.
Identify and select Architecture for the system using
Architecture Lab
Guideline.
Develop bi-directional traceability matrix using form Q284 which will be used
for identification of dependencies and for managing the requirement.
Identify the security requirement (Refer Security Guideline)
Analyzing and validating the requirement


Analyze requirements to ensure that they are complete, feasible, realizable,
and verifiable by taking QFD methodology and by defining Integration test
cases.
Update Requirement validation kit along with details of validation results
Preparation and Approval of Software Requirement Specification
(SRS)




The Project Team prepares the SRS document as per the Template.
PM shall identify the most suitable SDLC Process Performance model in order
to achieve project goals.
The Project team prepares the Acceptance test & take customer approval (If
applicable)
PM shall review and approve the SRS & Acceptance test plan and submits to
the customer for sign off (If applicable)
Baseline the Document

Configuration controller shall baselines the approved SRS & acceptance test
plan.
Re estimation of Size
 The team shall re-estimate the size of the requirements & use estimation
checklist to review the estimates.
 PM shall use re-estimated value to calibrate the process performance model to
calibrate the same.
Requirement Tollgate

During requirement Phase-there are two tollgate reviews
a)
b)
Tollgate 2, Phase1 (Requirement gathering),
Tollgate 2, Phase2 (Requirement Analysis and validation)

In case the Toll Gate 2 Phase1/Phase2 is not cleared, it would be highlighted
in the Prewarning dashboard.






Effort spent in Requirement Analysis
Defects found during the Review
No. of change request received
Review Effort
Rework Effort
Effort spent during Requirement Tollgate






Account Manager
Project Manager
System Analyst
Business analyst
Solution Architect
SQAR








SRS Document
Modification of Estimation, if applicable
Accepted Change request by the client
Modified D&Q Plan
Filled Requirement Gathering Plan
Filled Requirement Validation kit
Executed Requirement Engineering Tollgate Check List
Periodic Reviews and Audits are conducted in order to ensure Process
Compliance
Review Procedure
The purpose of Review procedure is to define the process of planning, organizing,
conducting and recording the activities related to review of a software item or
product and the associated documents.
Plan for Review
PM shall

Plan for 100% peer reviews and formal inspection on selected sample (based
on criticality and complexity)

Identify Work product to be reviewed in D&Q Plan

Identify and define verification method in D&Q Plan to ensure that the
verification environment is available when necessary

Identify reviewers (Subject Matter Experts) for Planning, RA and Design
phases.

Schedule the review meeting, select the meeting place and inform the review
team.

Share review kit including, work product, checklist, or Standards etc. to the
reviewers.
Preparation Phase

The reviewer(s) reviews the work product and will prepare their
comments/defects, recommendations and questions on the work product to
be discussed at the review meeting.

For code reviews the team would prepare project specific code review
checklist.
Review of Work Product

The author will initiate the review meeting, and will clarify the issues raised
by the review team member(s) on the work product.

The review team will record the review comments using Defect tracking tool
Defect Tracker or client supplied tool or the review form Q205.

Review Team fills in review recommendation, other metrics and authorizes a
verifier to verify closure of defects identified.

The Review Leader assigns comments / defects for closure, to the respective
author(s).

The Author and the Review Team will resolve defects raised during the
review.

The Author will discuss with the Review Leader to resolve the open issues (If
any)
Rework Phase

The author reworks on the defect/comments of the work product as recorded
in Defect Tracker or the review form Q205.
Defect Closure Phase

Author will close the review comment and share it with Review team.

The designated verifier from review team shall approve the closure of defects
recorded in Defect Tracker/Q205.
Root Cause analysis of defects

The Review Leader in discussion with review team will analyze the cause of
defect and complete the “Defect Origin” column by writing the stage / phase
responsible in defect tracking tool/Q205.








Size of the product (KLOC/# of pages/no. of functions)
Size and composition of the review team
Preparation time per reviewer
Length of the review meeting
Types and number of defects found and fixed
Rework effort
Actual effort expended on reviews Vs. Planned
Number of products reviewed Vs total number of products

Whole Organization


Review Form (Q205)
Updated work product

Periodic Reviews and Audits are conducted in order to ensure Process
Compliance
Project Management Process
Software Project Management is an umbrella activity within software engineering. It begins before any technical activitie
initiated and continues throughout the definition, development and maintenance of software projects.
The purpose of this document is to describe the processes, procedures, guidelines and templates that should be followed
effectively manage a software project.
The key project management activities performed in this process areas are as follows :












Contract Review
Project initiation
Development of Plan
Planning and preparing for a phase
Task assignment and monitoring
Tracking and re-planning
Re-estimation
Metrics collection
Phase end review
Project closure
Status reporting
Project failure


Effort spent in Project Management activities (Estimated Vs. Actual)
Number of Failed projects in a quarter






Account Manager
Project Manager
Tower Leader
Global Delivery Head
COE Leaders
Business Excellence




D&Q Plan
SCM Plan
Metrics
Project Process Capability


Project management process is audited during Internal audits
Implementation check is done through FP Governance, Project management review (PMR) & Common Delivery Framew
Internal Quality Audit Process
The objective of the internal audit is to determine conformity or non-conformity of the quality activities and
related results against the defined and implemented quality systems.
Key Audit activities –











Audit Planning and Scheduling
Audit Opening Meeting
Audit Execution
Audit Reporting
Audit finding report (AFR) validation for its completeness
Audit Analysis
Audit Closure Meeting
Findings Closure Verifications
Number of NCs/ OBs reported
Finding ageing analysis report
NC Profile











Management Representatives
Software Quality Assurance Representatives
Auditees
Internal Auditors
Tower Leaders
Account Managers
Project Managers
Common Root Causes & Improvement Plan
Trend analysis to demonstrate Improvement w.r.t. last defined & Implemented Improvement
Plan
IQA trend analysis and action plan
Monthly management reviews
Centre of Excellence (COE) Handbook
The COE Handbook is aimed at providing a complete overview of the COE Operations. The
handbook defines the Roles and Responsibilities of COEs and describes about different activities
performed.
Prepare COE charter detailing COE Specific activities :
 Market Size / Market Analysis
 Win-loss Analysis
 Basic Offerings
 Object Of Sales (OOS)
 Account mining and Revenue plan
 Supporting Alliance Management
 Geo Sales People
 Preparing Case studies and White Papers
 Supporting Pre Sales
 Manpower Planning
 Risk Management
 Uploading COE specific Documents on KMantra
 Delivery Management Support
 Core area offerings
 Creating and Maintaining Technology Lab
 Creating WOW plan
 Implementation/Transition & Process Standardization
 Competency Development
 Conducting Reviews
Review Mechanism














COE Leaders shall send weekly Status sheet to Global Delivery head on the
below mentioned parameters :








Critical Project Issues
Top 5 Open Opportunities (by size, over 60% probability)
Top 5 Target X-Sell Accounts
SME Induction status
Resource Induction Status
Other issues
Risks
Other COE activities etc.
ORR reviews are conducted at monthly frequency.
Competency index (CoE level)
Competency index trend analysis (CoE level)
Training Effectiveness
COE Capability Index
CoE Revenue (USD M)
CoE GM%
Direct cost per FTE (CoE) - Offshore
Resource Utilization
Project Delivery Failure rate
VOC
Proposal Conversion ratio
% of externally certified people





COE Maturity Index
Employee Retention Ratio
Next level of leaders in place
SME Coverage for identified Offerings
Competency Index







Tower Heads
COE Leaders
COE teams
Account Managers
Project Managers
Business Excellence
Practice Heads







COE Charter
Revenue Plan
Case studies and White Papers
COE Manpower Plan
WOW Plan
Training Documents
Updated Metrics tracker
Periodic Reviews and Audits are conducted in order to ensure Process Compliance
Engineering Design Services Process
This procedure covers operational process approach that will mainly be used to
support product development lifecycle process for Engineering Design Services
project.










Project initiation and Planning (Prepare PDSP)
Customer Inquiry received.
Check whether it can be executed as a Jobs (duration upto 80 estimated
hours or as non- Jobs (greater than 80 estimated hours)
Prepare Project plan {Define -PDSP (project defined software process)
creation.}
Queries/ Issue clarifications from customer
Prepare concept and design
Final verification of the deliverable
Receive customer acceptance / Feedback
Prepare project performance review report
Update customer feedback review report

Schedule Variance (Phase wise)






Project Managers
Account Managers
PMO
Global Delivery Head
Tower Leaders
Business Excellence
 Signed UAT/Client sign off (Customer acceptance on deliverables)
 Customer Feedback review report
 Project Completion Report
 Project Performance Summary report
 Product NC report
 Sign off from Finance

Periodic Reviews and Audits are conducted in order to ensure Process
Compliance
Account Management Process
The Account management Process is built in context of customer retention and repeat business from
same account or engagement YoY. The process focus on GO-TO-Market Strategy to accelerate Revenu
growth through more focused and consistent execution of the Account management (AM) plan.
Input from Go –To Market Strategy
 “Cross Sell” -Existing Offerings to Existing Places
 “Up Sell” -New Offerings to Existing Places
 “New Market” -Existing Offerings to New Places
 “Next Generation” -New Offerings to New Places
Prepare Account Management Plan


The AM and BRM will jointly prepare the Account management plan . AM needs to defi
execution plan to ensure that we should move from on demand provider to mutual allies cate
The AM should form their core team with key people considering the business, process
technical knowledge/competency required for the account. The core team should not exceed
than 25% of the complete team size.
Review and approval of Account Management Plan

The AM plan will clearly demonstrate the clear mapping between account mining strateg
detailed execution plan to achieve the same. Account management plan will be reviewe
approved by CXO.
Regular execution review of Account management / Detailed Execution plan


For the Top Strategic account, the Steering Committee will review all the large engagements
For all accounts, it is mandatory for AM to plan for Common Delivery Framework (CDF
monthly basis on the similar pattern as it is planned for Steering committee review.
Prepare Business Continuity Plan

Account manger will prepare the business continuity plan for the engagement in conforma
Birlasoft standard policies and procedures.
Account Management Plan – Induction of Freshers

The account need to induct the trainees / fresher’s at least 5% of the total strength
account. This will enable on the job learning for the new joinees in the organization.
Account Management Plan – Change management

Based on the input received in the various review forums, The AM shall revisit the AM Plan ba
the following trigger :






Change in the relevant stakeholder
Go- To market Strategy need amendment.
Client focus is change, thus trigger to change in strategy
Birlasoft business focus is changed
Birlasoft strategic planning input
Account level VOC
Account Management – VoC

AM is required to raise account level VOC on six monthly basis. This VOC is independent from
VOC raised at Project level. This VOC will be raised to the top management of the client.




Budgeted Vs Actual Cost
Target Vs Actual Revenue
Target Vs Actual Resource
Account level –VOC








Project Manager
Account Manager
Business relationship Manager
Global Delivery Head
Tower Head
CXO
Updated Account management plan
Common delivery framework template
For the Top Strategic account, the Steering Committee will review all the large engagements.
The key stakeholders include- CEO, Tower leaders, Center head, Global Delivery Head, Practice head
Head BE, BRM, Legal Representative, AM, PM & SQAG.
Agile Methodology
The purpose of this procedure is to describe the Agile practice followed in the organization.
It details out the guidelines and templates that shall be followed while adopting agile methodology.
Project Start up and Perform Pre-sprint Readiness

Understand the business context (including contract, fixed bid / Time and Material etc.)

Understand operational considerations ( single / multi locations)

Understand technical considerations

Estimate budget and cost

Identify scrum team (cross functional)
Perform Sprint (single iteration) Planning

In the sprint planning meeting the Scrum team and the Product owner shall determine the sprint goals and decide t
the release backlog that they can complete during the sprint.
Manage ongoing SCRUM

Perform daily stand up meeting

The scrum team member (individually) shall answer three scrum questions during the daily stand up meeting :

What did he / she did since yesterday?


What will he / she do today?

Are there any impediments in his / her way?
The Scrum Master shall manage the block lists and remove the impediments
Manage Product and Release backlogs

The Product Owner shall provide inputs whenever there is a change needed in the product. The scrum team manage
time whenever a new work item is added and / or changed and ensures all the changes are addressed in release plann
Perform Sprint Review / Demo

A sprint review meeting shall be conducted with the Product Owner to ensure all acceptance criteria of the work c
met. This is an informal meeting wherein no presentation included and should not last for more than 2 hours.
Perform Sprint Retrospective

The retrospective meeting provides the team an opportunity to collectively evaluate their performances and
followed in order to realize the product. The goal of the meeting is to inspect and adapt team practices and proc
identify and take action on the key issues that are hindering the team’s progress.
Manage Release

Releases shall be aligned with Product Owner’s target date for Time to Market creating maximum value for the busine
Manage distributed scrum team

The key way to scale Scrum when working with large teams is to coordinate a “Scrum of scrums”. With this approac
works normally and each team has a representative to attend the Scrum of Scrum meetings and coordinate the wor
teams.



Velocity – Points consumed per sprint
Sprint burn down chart
Release burn down chart
Hard value delivered





Business Excellence
CoEs
Project team
Sales/Presales
 Successful completion of the project by meeting / exceeding expectations and creating value for the client.
The Agile methodology shall be audited as per the Internal Quality Audit Procedure.
Knowledge Transition Procedure
The purpose of this procedure is to ensure Complete, Comprehensive and Correct Knowledge
Transition (KT) & to measure effectiveness of the KT.
This procedure is applicable to all projects falling in the buckets of QA,
Production Support and Maintenance, where KT is applicable.
The KT Procedure is not applicable to SDLC and SAS projects.
Planning Phase:



PM Shall define the Scope of Engagement:

understand scope with regard to Applications, Support levels and work definitions

Finalize the Maintenance Service Level Agreements
PM shall prepare for KT by ensuring following steps:

Detailed information on Client’s processes and develop a plan to identify the most suitable
processes roadmap for the engagement

Receiving KT Documents (BRD, URD, FRD) from Customer for initial understanding

Execution of the Requirement Completeness Checklist for checking the Completeness of
Requirements

Gain working knowledge of client's design approach, development standards, testing
standards and maintenance procedures

Facilitate client's understanding of Birlasoft maintenance methodology and quality
processes

Finalize the outsourcing schedule and the models to be adopted

Understand the current levels of documentation available

Customer Expectation for Measuring the KT Prepare a detailed Risk Mitigation plan for the
KT phase.
Ensure the infrastructure and network set up
Knowledge Execution Phase – Customer to Onsite team

Project team shall conduct planned KT session with Onsite Coordinator (KT receiver
Team) and Customer on the following areas :



Functional Understanding
System Understanding
Application Process Understanding and Technical Environment Study

Project team shall log all queries in the query tracker and work along with Customer
for their closure.

Project team shall prepare KT Documents (FS, TS, SOP, DOU, SLA Document, Risk
Management Document, Security Document, Quality process Document),

KT team shall perform Reverse walk through with the Customer and Internal SME’s &
will review of all the prepared KT documents
Customer /SME’s shall log review comments & project team shall fix all the defect
and track them towards closure.
Project team shall execute KT Checklist (Maintenance, QA, Production Support)


Knowledge Execution Phase – Onsite to Offshore
Onsite team and PM shall





Assess Infrastructure Setup & Augment Offshore Team
Conduct an Induction Training program to deliver the knowledge gathered onsite to
the offshore team.
Impart classroom-based as well as hands-on training to the offshore team members.
Capturing the Actual for Sessions & Artifacts to measure KT Effectiveness
Updating the Traceability Matrix and Self Rating Sheet in KT Effectiveness sheet.
Piloting (Service) Phase:
PM shall ensure :







Execution of Shadowing Activity– KT Receiver (Both Onsite and Offshore) observes
and analyses the Customer’s way of working on some of the packets.
Execution of Reverse Shadowing – Customer observes and KT Receiver’s performance
on some of the assigned sample tickets/work packets.
Capturing the Actual for Shadowing & Reverse Shadowing to measure KT
Effectiveness
Baseline Audit by PM before Tollgate Review by using KT Validation Checklist.
Tollgate Review with Relevant Stakeholders
Client Sign Off on all Deliverables
Customer Rating for measuring the KT Effectiveness




Schedule Variance for KT Phase
Effort Variance for KT Phase
SLA Adherence for KT Tollgates
KT Effectiveness Measurement

Process Level Sigma Value






Project Manager
Account Manager
Project Team
Tower Leader
Senior Management
Software Quality Assurance Group (SQAG)

Business Excellence Process Group (BEPG)





Completely Executed KT effectiveness measurement sheet
Executed requirement completeness checklist
Knowledge Transfer Checklist
KT Validation Checklist
KT Documents (SOP, DOU, FS, TS, Risk Document, SLA Document etc)
The Knowledge Transition Procedure shall be audited as per the Internal Quality
Audit procedure & through SQAG reviews
Task Kick off Procedure
The purpose of this procedure is to define steps for conducting a task/phase
prepare the team members involved to perform the activities of the task effe
This procedure is also applicable for Phase kick off meetings conducted during
Initiate Task / Phase Kick off Meeting

The PM Shall call for task kick off/Phase kick off
attendees of the meeting shall be:






Project Manager
Team Lead(s)
Team Members
SQAR
BEPG Member (optional)
In the task/phase kickoff meeting, the Project team shall:



Discuss the software processes, standards, methods and tools ap
task/phase.
Discuss the inputs required for the task and check their availabi
Discuss the outputs to be produced. If required, prepare templa
guidelines and formats to produce the outputs of the task.
PM Shall


Disseminate the benefits, changes & results of de
activities
Disseminate the outcomes from Process Performance mo
different methodologies which will be followed by






different activities.
Share the list of common errors made in earlier phases/ p
nature executed in the organization. The intent is to learn
Identify & share the Defect preventive strategy with the
Implement changes on a trial basis to evalu
recommendations or recommendations from previous
meetings. (If required)
Disseminate project specific software quality goals, clie
and the organization's requirements.
Update the work breakdown structure by scheduling th
and activities of task (person and role wise)
Execute Task kick off meeting checklist and take input
from project team to ensure project execution as per Pro

Effort spent in task/phase kick-off meetings




Project Manager
Project Team
Business Excellence Process Group (BEPG)
Software Quality Assurance Group (SQAG)



Project Learning’s
Updated task kick off checklist
Minutes of Meeting of task/phase kickoff meeting
The Task Kick off Procedure shall be audited as per the Internal Q
procedure
Escalation Management Procedure
The Purpose of this procedure is to ensure effective Management of Project
issue. Project related issues need to be documented, monitored, and resolved in
a consistent and timely manner. And as a last resort, when an issue remains
unresolved it must be escalated to the senior management.
Define the Issue & Action Plan



The Project team or client can identify a potential issue.
PM shall review the issues , define its severity as critical major and
minor, and accordingly identifies action plan to resolve the same.
PM shall escalate the issue to AM through weekly status report.
Assign Responsibility



The PM shall assign the issue for resolution to team member according
to the type and severity of the issue.
The issue may also be escalated at AM level followed by Tower level
escalation and Global Delivery Head (GDH) level.
PM shall identify the target date for completion of the actions to
resolve the issue.
Issue Monitoring & Resolution




For all critical issues identified in the project the closure cycle time
will be 4 days
For all major and minor issues the closure cycle time will be two
weeks
If the issues are not closed as per these time lines they should be
escalated to next level
The PM may decide to treat the issue as a change in scope, and invoke
the Change Management process.
Monitor & Progress & document results


PM shall monitor all open issues and update D&Q plan as appropriate.
PM shall update issue log for all the resolved issue and update
concerned stakeholder accordingly.

Number of Issues opened at Phase End

Idle time in the project due to open issues






Project Manager
Account Manager
Tower Leaders
Business Excellence Process Group (BEPG)
Software Quality Assurance Group (SQAG)
Global delivery Head


Issue Closed in the issue Log
Updated Non compliance report with the status as closed
The Escalation Management Procedure shall be audited as per the Internal
Quality Audit procedure
Change Management Procedure
The change management procedure defines the set of activities that needs to be performed when
there are some new requirements or changes to existing requirements or change in the existing
working environment.
The basic goal of the change management process is to control changes and minimize their effect
on the project.
Initiation of Change/ Problem request

Any project member/customer can initiate change/ Problem request based on the nature
of request as mentioned below :




Change Request (CR) - Any change in the allocated & approved requirements or if a new
requirement is identified. The customer approval is required.
Problem Report (PR) - Any change required in the baselined work products, as identified
by project team, however there is no change in allocated & approved requirements.
Customer approval is not required.
The Project Team shall log the CR/PR logged in the change request register form (Q294)
& ensure they are tracked till closure.
The Project team shall update the CR/PR(Q252) based on the available details.
Impact Analysis of Change


PM shall assign the CR/PR to a team leader/member.
The designated team member carries out the Impact Analysis of the CR/PR which will
involve :





Identifying configuration items that need to be changed and evaluating the quantum of
change/problem to each configuration item.
Estimate the size for the CR/PR and the impact on effort of the Configuration Item (CI) &
project
Re-estimate the delivery schedule if required.
Re-estimate the cost sheet if required.
Re-assess the project’s risks by revisiting the Risk Management Plan.
Review and Approval of Impact Analysis




PM shall review & approve the Impact Analysis & send it to SCCB for approval
Customer approval is required whenever the impact of CR results in 15% increase in effort
with respect to planned effort.
Senior Management approval is required whenever the impact of PR affects the effort
and/or delivery schedule beyond threshold limits
PM shall assigns approved CR/PR to team member to incorporate the changes as per CR/
PR.
Change Implementation



CC shall verify that all the required changes have been made before checking in the
configuration items.
PM tracks the closure of Changes in the Change Request form (Q252) and the Change
Request/Problem Report Register (Q294) is updated.
Change Request measures in terms of Size, effort, schedule & cost.
Project Closure Procedure
The Purpose of the procedure is to define the process of handling the closure/suspension of
projects.
Project closure Initiation

PM shall complete all activities listed in Project Closure Checklist/Form (BSL/CHK/20)
from Delivery perspective & initiate the project closure in ESA Application.

PM Shall prepare project closure report and take inputs from Project Team (Please refer
project management process)


Once PM gives signoff, Support functions (Primarily, System Admin, GMAT and HR)
shall verify and provide sign off for project closure activities with respect to their
concerned area (Refer Project closure checklist)
Once sign off is received from Support Functions, SQAR will verify the project closure
report and other relevant quality checkpoints and provide sign off (Refer Project
closure Report)
Once SQAR signs off, Finance shall verify the project closure activities and provide
their approval.
AM may initiate administrative closure of the project In case Finance requires more
time to give sign off on various financial parameters.
On receiving approval from Finance, AM shall close the project in ESA.


Number of Case Study / Learning’s shared
Executed Process performance model







Project Manager
Account Manager
Team Leaders
Business Excellence Process Group (BEPG)
SQAG
ESA Team
Support Functions




Project closure report
Sign Off from all relevant stakeholders on Project Closure Form/Checklist
Minutes of the meeting for the project debriefing meeting
Learning document/Case Study



The Project Closure procedure shall be audited as per the Internal Quality Audit procedure
Project Management Review Procedure
The purpose of the procedure is to define adequate mechanism for periodic
and event driven Project Management Review (PMR). PMR helps in having
project status data in a uniform format, which is to be used for analysis &
finding trends in the project management cycle.
Plan for PMR

PM shall plan for PMR on monthly basis. The PMR shall be attended by :


AM, PM ,SQAG, Project Team (Mandatory)
Global delivery Head ,Head BE , Support functions (Optional)
Prepare for PMR

PM shall prepare for PMR based on the below mentioned agenda :













Review of action item from last PMR
Project execution status w.r.t Project plan
Review Relevant stakeholders involvement
Review of D&Q Plan (Inclusive of sub plans)
Monitoring the process/sub process performance in the project
Review of High Priority risks & Issues
Review of Causal Analysis corrective and preventive action
Effectiveness/Assessment of process compliance
Decision Analysis action items if any
Status of DMAIC projects and process improvement activities
Project VOC / Customer feedback
Any other areas of Concern
The concerned SQAR will verify and approve the PMR Presentation followed by the
AM Approval.
Conduct & Track PMR




The PM shall conduct PMR ( Refer PMR checklist CHK-31)
The PM shall record the actions arising out of the PMR in the respective tracking
sheet.
AM, PM & SQAR tracks the action items till their closure.
PM shall keep the PMR presentation in project central repository for future
reference and usage.


Number of PMR action items identified
Number of PMR action item open







Global Delivery Head
Head Business Excellence
Support Functions
Account Managers
Project Managers
Project Team
SQAG


PMR Action Items
PMR Presentation
Periodic Reviews and Audits are conducted in order to ensure Process
Compliance
Software Configuration Management Procedure
Software configuration management (SCM) is a project control pro
management of software products in order to ensure product integ
traceability throughout the project’s life cycle.
Preparation of the SCM Plan
 PM shall prepare the SCM Plan ( Part of the D&Q plan)
 PM shall identify the Software configuration control boa
consist of Configuration Controller (CC), PM, AM & Client (
Identify Configurable items

To maintain accountability, integrity, Visibility, traceability
reproducibility , PM shall identify the configurable item (C
on the following criteria :





Products that are delivered to the customer
Internal work products like SRS, SAD, HLD, Data flow diagrams, Test case
Acquired products from the customer like tools, standards, templates, t
Other items that are used in creating and describing these work product
and reports
Process performance Model output
Configuration Control
 The CC shall provide the appropriate access rights to the team depe
role of the team members
 The CC shall review and ensure that the configuration of CIs is bein
throughout project life cycle to maintain the integrity and correctness
shall be labeled & commented properly
 CC shall maintain a log of changes and reasons for changes as approp
details could be viewed through revision history of CIs using configuratio
 In case the code is being managed by both customer and Birlasoft, t
maintain and baseline the code on which we are working as a back up a

In case the team is working directly on client instance & Birlasoft team
to keep copy of code then in that case project team will maintain and m
other documents except code in configuration tool
Change Control

The changes in CIs are consequences of one of the following:




Requirement change request (RCR)
Problem report (PR)
Defects
All the RCR/PR are handled as per the change management procedure (
Configuration status accounting

Configuration status accounting is a means of recording, managing and r
changes to software items during the entire life cycle of the project.

CC shall prepare the below mentioned reports to maintain status accoun



Change request summary and status (Q252)
Problem report summary and status (Q252)
Results of software baseline audits
Configuration Audits


SQA Lead conducts SCM audit (Part of PHI template)
PM conduct Baseline audit using Baseline audit Checklist.
Backup and Recovery
The frequency for taking backups will be defined in the SCM plan
Risk Management Process
This Risk Management process defines the steps for risk identification & managing risks
in a project.
This process details out steps for how to identify the risk, prioritizes the risk factors
according to both the probability and the consequence of failure and develops a risk
management plan to implement strategies to deal with those risks.
Risk Identification

PM Identifies the risks associated with cost, schedule, and performance in all
appropriate life cycle phases in a project.

Typical risk identification methods include the following:






Examine each element in work breakdown structure
Interview subject matter experts and stakeholders
Review risk related to similar products available in Organization Project database
(OPD)
Examine lessons-learned documents or databases
FMEA (Failure Mode Effect Analysis)
Taxonomy Based Risk Identification (Birlasoft/CHK/48)
Risk Sources & Categories
 Following are some of the Risk Sources needs to be considered while
identifying the risks associated with the project.











Estimates
Technology
Resource
Suppliers
Customer
Process
Requirements
Design
Coding
Testing
Categorize risk to provide a mechanism for organizing risks as well as ensuring
appropriate scrutiny and management attention under following heads



Schedules
Cost
Performance
Risk Parameters
 Parameters for evaluating, categorizing, and prioritizing risks include the
following :




Probability of occurrence (Scale 1,3,9 (Low, Medium, High))
Severity if risk takes place (Scale 1,3,9 (Low, Medium, High))
Detectability (Scale 9,3,1 (Low, Medium, High))
The risks identified are analyzed, categorized and prioritized based on the
Risk Priority Number (RPN) and updated in D & Q Plan.
Risk Mitigation Plan
 PM Prepares the risk mitigation & Contingency plan for a given risk which
includes techniques and methods used to avoid, reduce, and control the
probability of occurrence of the risk, the extent of damage incurred should
the risk occur or both.
 PM have options for handling risks typically include alternatives such as the
following:





Risk avoidance: Changing or lowering requirements while still meeting the user’s
needs
Risk control: Taking active steps to minimize risks
Risk transfer: Reallocating design requirements to lower the risks
Risk monitoring: Watching and periodically reevaluating the risk for changes to the
assigned risk parameters
Risk acceptance: Acknowledgment of risk but not taking any action often,
especially for high risks, more than one approach to handle risk is generated.
Review of Risks
 PM shall review the risk management plan periodically to re-examine & update


the existing risk mitigation and contingency plan (If required)
Risk management strategy is reviewed with relevant stakeholders to promote
commitment and understanding.
Risk Management plan is reviewed in team & management reviews.
Threshold of Risks
 PM shall identify the threshold limits for all identified risk in D&Q Plan.

The categories of risks for which the expected total RPN value is between
Baseline and 2 X base line value is reviewed in PMR or in event driven
meetings.

The categories of risks for which the total RPN value is above 2 X base line
value shall be reviewed by Global Delivery Head.






Risk Priority Numbers (RPN)
Risk identified at early stages
No of planned Risk
No. of actual Risk
Effort spent on identification and analyzing of risks
Effort spent on Risk management planning








Tower Head
Account Manager
Project Manager
COE (Center of Excellence)
Presales
Business Excellence
Support Functions
Sales


Pre Sales team
Global Delivery Head

Risk Management Plan

Periodic Reviews and Audits are conducted in order to ensure Process
Compliance
Development & Quality Plan Procedure
The development and quality plan provides a framework for planning, executing and
controlling a software project.
This process describes how Development & quality (D&Q) Plan will be prepared,
reviewed and authorized within Birlasoft.
Study of Project related artifacts

PM shall study the project related document for detailed project planning as
mentioned below :




Proposal/Contract or any other acceptable statement of work (SOW)
Work Breakdown Structure (WBS)
Estimation records
Organization Project Database (OPD)
Preparation of D&Q plan

PM shall prepare the D&Q Plan using PPM 7.1 alongwith PDSP & detailed
project schedule.
D&Q Plan comprise of






The scope and objective of the project.
Client specific Information.
Milestones/ Deliverables.
Details about customer supplied products.
Details on supplier agreement management activities to be planned.
The Operational process model (Refer to Life Cycle guidelines for selecting










project life cycle )
Details of any deviation/work ahead taken in the project.
Roles and Responsibilities of Project team & customer
Assumptions & dependencies of the project.
Strategy for Risk Management, Reviews
Mechanism for Status reporting and Escalations
Hardware/Software Resources/Critical resources if any
Details about Work Environment
Details about the reusable components used /to be developed in the project
Plans like Defect Prevention, Software Quality Assurance, Configuration
Management, Training, Test Strategy, Data Management, Quantitative Process
Management Plan (Refer Metrics procedure) and Decision Analysis and
Resolution (DAR)
Project defined software process
Review and approval of D&Q plan

AM shall select the review team for the review of D&Q plan.

The Review team comprises of :






Another PM, having domain or application knowledge or has worked on similar
project
SQA Representative
Customer (If applicable)
Account Manager
The review shall be carried out using D & Q Checklist (Birlasoft/CHK/03)
PM shall incorporate any modifications/changes evolved as a result of review
and obtain final approval from AM
Modification of D&Q plan

PM shall maintains the D&Q Plan and monitors the progress against the plan.

D&Q Plan, once approved, is revised only in response to major changes as
mentioned below :













Significant Changes to users/business requirements
To incorporate suggestions from customer’s representatives
Change in schedule / timelines
Release of new QMS
Project Management review
Internal /External audit feedback
Change in resources/ Methodology
Project data/ metrics analysis leading to change in plan
Change in Organizational level DP Plan/ Training Plan
Change in Organizational level Training Plan
Change in BEPG Plan/ SQAG Plan
Change in Organizational level Business Plan
Change in Department level Business Plan

Changes in the life cycle/methodology & structural changes in the Project
Organization


Effort spent on preparation of D&Q Plan
Effort Spent in the Project Management activities






Account Managers
Project Managers
Team leaders
Team members
Business Excellence
Support functions


Approved D&Q Plan
Detailed Project Plan

Periodic Reviews and Audits are conducted in order to ensure Process
Compliance
Estimation Process
Estimation process applies to the process of estimating size, effort and cost required
for executing any or all phases of software development project. This estimation
process is applied during the Proposal Preparation and at any time the estimate is
required to be revised during the project life cycle.
Determine the Scope of Work/Requirements

During Proposal stage , identify scope and measure in terms of
functional/business areas, performance criteria and constraint.

At proposal stage, Delivery Manager prepares the level 0 estimates& reviewed
by the respective COE POC.

During the execution of the project, the PM revisits the estimate and after review shares it with
the client

The requirements are decomposed into functions during the execution of the
project which is a Level 1 estimate
Effort Estimation

Effort is estimated on basis of the organizational productivity (when

estimated through FP/ UC point methods) or through the complexity method
for each of the COE when size factor is not used
Consider the following factor while doing estimate:










Expertise available in the target business area
Expertise available in the target technical environment
Training requirements specific to the project
Dependencies on the client for input documents, feedback and approval etc.
Potential idle time based on activity interdependency
Impact of project size, project complexity and project schedules on project
management / Quality Assurance & Control activities.
Impact of Risk on estimated efforts
Document the basis of the productivity
Determine phase wise effort &location wise requirement
Duration is arrived from the effort and the resources who will be allocated for
the project
Resource/Cost Estimation

On the basis of skills/grade of professionals, travel/onsite
stay/communication

Hardware and software costs

DQT template is used to arrive at the cost estimation
Documenting the Estimates

Estimation sheets to be prepared once all the factors have been analyzed

Different for Maintenance Projects/ QA projects
Review





and Approval of Estimation Sheets
Approved by identified COE SPOC at the proposal stage
Reviewed by the Account Manager and COE SPOC at execution stage
Review carried out in accordance with the Review procedure (BSL\ENG\01)
Review comments are recorded in Estimation Review log (TPL 278 Estimation
Model Review Log)
Approval after review comments are incorporated


Effort spent on preparing estimation sheet, OAP sheet
Additional risks identified





Group Manager
Project Manager
COE (Center of Excellence)
Team Leaders
Presales


Reviewed & Approved Estimation sheet
Periodic Reviews and Audits are conducted in order to ensure Process
Compliance
Project Initiation and Planning Process
The objective of this procedure is to describe the process of Project Initiation in project
start-up phase. It includes the activity of having Tollgate Reviews within the Project Start
up time. It is also required that the affected groups are informed about the project
initiation through project initiation mail through ESA.
Project Initiation & planning

Project shall complete Project initiation and planning activities at the start of
the Project as mentioned below :









Execution of Process performance model for development projects and large
enhancements in Maintenance projects
Identification of Risks for the Project along with its Risk priority number (RPN)
Preparation of Project Plan and approval from Client
Review of Statement of work (SOW) which includes Business Excellence and Legal
Review
Set up of Project in PPM 7.1/Kintana
Identification of Project Goals & SLAs of the project
Preparation of PDSP & DnQ plan. PDSP should have all the tailoring which are required
for the project
Identification of Change Management Process & Templates
Project Kick Off Meeting with the objective of sharing information & taking
commitment from the project participant’s on scope, risks, methodology, delivery
schedule etc.
Tollgates- Check for Process Adherence

Tollgate 0 happens on the 5th working Day of Project Initiation in ESA

Tollgate 1 happens on the 15th working Day of project Initiation in ESA

Project Initiation Mailer is received to all the relevant stakeholders & the
Process owner



SQAG maintains a tracker for scheduling for Tollgate 0 & 1
Tollgate Review Dashboard is released by the Process owner telling the status
of the Tollgates
Tollgate 1 is NA for Staff Augmented Services (SAS) Projects
Release of Dashboards




Stakeholders shall receive Tollgate Review Dashboard within 1 day of the
Tollgate reviews
Stakeholders shall receive Monthly Tollgate Review Dashboard in first week of
every Month
Stakeholders shall receive an Escalation Dashboard for the Projects which
have not cleared the Tollgates within the SLA timelines in first week of every
month

Process level Sigma Value at Organization level




Tower Leaders
Account Manager
Project Managers
SQAG

Tollgate Zero and One are Cleared
Periodic Reviews and Audits are conducted in order to ensure Process Compliance