Software Development Process

Project Management Review Procedure
The purpose of the procedure is to define adequate mechanism for periodic and event driven Project Management Re
(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 projects 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 Configuration Contro
(CC), PM, AM & Client (Optional)
Identify Configurable items
To maintain accountability, integrity, Visibility, traceability, reproducibility , PM shall identify the

configurable item (C.Is) 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 mai
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 through rev
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 on w
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 that
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 during
entire life cycle of the project.
CC shall prepare the below mentioned reports to maintain status accounting
Change request summary and status (Q252)
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 users 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 reexamine & 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
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. The
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 manua
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 wi
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
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 communicatio
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 distinc
each project.
Projects measurement objectives are derived from organizational objectives, client specific objectives and objec
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 basel
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
System Support and Administration
The purpose of this procedure is to describes the process o

system support and administration in order to have a control o
hardware (H/W) and software (S/W) in the organization.
The system support also includes preventive maintenance o
machines, virus and identification checking, and backup archiva
& retrieval of software.
Management of Hardware and Software
System Admin team maintains details of Hardware Allocation as per Use

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 th
System Administration.
Track of all pending calls is kept and is followed up with service agencie
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 fireproo
location.
Archival and Retrieval
PM shall submit two copies of the product/software/application fo

archival form (Q224)to the software librarian on completion of th
project.
The archives shall be maintained for a period not less than 3 years or a
stated in the Project contract.
Whenever a need arises for the software/product/application from th
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

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 b
taken.
System Security
Employee can access Organisation resources by obtaining their user ID t

logon to the network and systems.
Every employee shall abide by the companys Acceptable Use Policy
All systems should be protected with power on passwords
Floppy disk drives & all sorts of removable media is restricted in th
premises.
Preventive Maintenance
Preventive Maintenance shall be carried out once in six months as pe

the schedule prepared by Site Manager Systems.
The System admin team shall randomly check to verify the correctnes
and effectiveness of preventive maintenance done by the externa
vendor & record his observations in preventive maintenance verificatio
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 participants 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

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
Marketing Team
Account Manager
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

Review
Different for Maintenance Projects/ QA projects
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
Team Leaders
Presales
Reviewed & Approved Estimation sheet
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
Number
Number
Number
Number
Number
Number
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.
of
of
of
of
of
of
of
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.
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.
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)
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 Managemen
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 a
per Document Generation Procedure
Based on the impact analysis BEPG accept/reject/deferred the change reques

& update the requestor accordingly.
Change in Process Document
Head BEPG shall assign the approved change request to BEPG team member/SME fo
detailed impact analysis and modification of affected process artifact.
Assigned team member shall checks out assigned document from Working folder in VS
and make changes as per the change request.
Author is required to update version number & modification history detailing the specifi
changes made in the document.
The modified document is then subjected to Peer review/SME review as per th

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

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 Sc
Reports to be used as per client approved template.
Team Member shall prepare Online Help using the tool to facilitate quick
while working on the developed software product.
The Team Member shall prepare the Installation guide using the tool to f
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 (BS
the following,
Style and Grammar
Complete coverage of functionality as per Software Requirement Specific
Test the document by installing and running the software using the docum
The PM/TL shall record the observations and defects using defect Tracker
Closure & Verification of Defects
The Team Member shall close the defects and record the closure in the R
The PM/TLshall verify the closure of Defects. The review report is closed
when all the defects have been rectified.
Baseline the User documentation

Configuration controller baselines User documentation after PMs 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)
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

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 clients 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 customers 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)
Early Warning Process
The purpose of this process is to act as a proactive alert mechanism for deliver
function, wherein engagement and project level issues/Risks are proactivel
identified and informed to the Senior management and ensure corrective
prevention actions are taken.
Business excellence team shall publish the consolidated report/ Dashboard t

highlight early warnings effectively at appropriate levels and track them toward
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 Towe

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 case

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 o
weekly basis.
Escalation of Issue from One Level to Next Level:
All customer escalations are tracked at least at GDH level till the time issu
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 nex
level. However it can be moved back to earlier level if reviewe
recommends.
Issue Resolution:
For removal of escalations from the escalation dashboard, PM/AM shares th

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

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 t
be generated, collected and recorded.
This procedure is needed to ensure that all new/ existing client visits handled with consistenc
and coordination among all support and delivery function as needed.
Client Visit Planning Phase
Sales/BRM shall identify the client key objective & expectation from Birlasoft as Per (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
Mobilization Phase
BRM/Sales shall collate all the presentation and ensure that final presentation is as per th
corporate presentation format as suggested by Branding / Marketing team.
Admin SPOC shall share the logistic requisition form with the sales team to confirm visi
requirement. (Refer Q376-Client visit logistic requisition form)
BRM/AM/ Presales shall coordinate for a dry run of presentation to ensure Key Messages tha
have been identified & shall be delivered by the various Stakeholders as per state
objective and expectation for the client visit.
The master of ceremony/BRM shall ensure that all presentations are complementing an
covering the agenda as per client expectation.
BRM shall set for Business Lunch /Dinner discussion agenda and send invites to intende
participants.
If Live Experience / Bay visit / Facility walkthrough visit is involved, BRM shall communicat
it to all relevant stakeholder including delivery and admin SPOC.
All stakeholders should provide their commitment for the client visit. The presentatio
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 b
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 wit
relevant stakeholder.
Follow Up Phase
Sales/BRM shall prepare the detailed Client Visit Report and shares the same wit
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 share
with Sales and Client.
Presales/ BRM/AM Stores the Client Visit Presentations, Client visit Reports and Feedback i
centralized repository maintained by Presales team. All approved presentations shall b
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
Client
Tested and updated Software product

Defect Test Report /Review record (Q205)
Acceptance Sign-off communication (From Client)
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.

Project team Shall,
Identify most suited Process Performance Model for System testing (Manual /

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)

Testing team shall record the details of all failed cases by recording in defect
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)

Configuration Controller shall baseline the System Test Code based on PMs
approval.
(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
Baselined Source code

System Test Cases (Q217)
Updated User Documents
Defect Test Report /Review record (Q205)
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.

Project team Shall,

Identify most suited Process Performance Model for Unit testing (Manual /

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)
Testing team shall record the details of all failed cases by recording in defect
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.
Configuration Controller shall baseline the Integration Tested Code based on PMs
approval.
(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
Baselined Source code

Integration Test Cases
Updated User Documents
Review record (Q205)
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
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 :
Sub-system functionality and interfaces mentioned in HLD document.
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
Configuration Controller shall baseline the ITC &STC based on PMs 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.
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
Baselined Integration Test Cases

Baselined System Test Cases
Review Records (Q205)
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,

Identify most suited Process Performance Model for Unit testing (Manual /

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).

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.
The Project team updates the requirement traceability matrix form (Q284)
mapping all the requirements to suitable sections.
Schedule of Testing (Planned vs. Actual)

Effort spent in Unit Testing
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)
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.
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.
Schedule of Code (Planned vs. Actual)

Effort spent in review of Code
Review Efficiency
Tollgate SLA adherence
Account Manager
Project Manager
Team Leader
Project Team
Technical SME
Reviewed & Updated code

Integrated product
Review Log (Q205)

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 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)
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
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
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
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)
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
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
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 ( TPL-25Testplan) & 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
The review team will record defects using Defect Tracker/ Q205 .
The Project team will update the review comments and resubmit if for
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
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

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

Compliance
Project Management Process
Software Project Management is an umbrella activity within software engineering. It begins before any technical activities
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
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
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 Framewo
Internal Quality Audit Process
The objective of the internal audit is to determine conformity or non-conformity of th

quality activities and related results against the defined and implemented qualit
systems.
Key Audit activities
Audit
Audit
Audit
Audit
Audit
Audit
Audit
Planning and Scheduling

Opening Meeting
Execution
Reporting
finding report (AFR) validation for its completeness
Analysis
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
Implemented Improvement Plan
w.r.t.
last
defined
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
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
Tower Leaders
Business Excellence
Signed UAT/Client sign off (Customer

deliverables)
Customer Feedback review report
Project Completion Report
Project Performance Summary report
Product NC report
Sign off from Finance
acceptance
on

Compliance
Account Management Process
The Account management Process is built in context of customer retention and repeat business from t
account or engagement YoY. The process focus on GO-TO-Market Strategy to accelerate Revenue growt
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 def
execution plan to ensure that we should move from on demand provider to mutual allies categ
The AM should form their core team with key people considering the business, proces
technical knowledge/competency required for the account. The core team should not excee
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 strate
detailed execution plan to achieve the same. Account management plan will be review
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 (CDFW) on
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 conform
Birlasoft standard policies and procedures.
Account Management Plan Induction of Freshers
The account need to induct the trainees / freshers at least 5% of the total strength of the a
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 bas
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 t
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
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,
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 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 manag
time whenever a new work item is added and / or changed and ensures all the changes are addressed in release planni
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 process
in order to realize the product. The goal of the meeting is to inspect and adapt team practices and processes in an
take action on the key issues that are hindering the teams progress.
Manage Release
Releases shall be aligned with Product Owners target date for Time to Market creating maximum value for the busines
Manage distributed scrum team
The key way to scale Scrum when working with large teams is to coordinate a Scrum of scrums. With this approa
works normally and each team has a representative to attend the Scrum of Scrum meetings and coordinate the wo
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 Knowledg
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 Clients processes and develop a plan to identify the most suitabl
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 o

Requirements
Gain working knowledge of client's design approach, development standards, testin

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 K
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 fo
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 SMEs &
will review of all the prepared KT documents
Customer /SMEs 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 Customers way of working on some of the packets.
Execution of Reverse Shadowing Customer observes and KT Receivers 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)

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 effec
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 of

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 app

task/phase.
Discuss the inputs required for the task and check their availabili
Discuss the outputs to be produced. If required, prepare templat
guidelines and formats to produce the outputs of the task.
PM Shall
Disseminate the benefits, changes & results of defect prev

Disseminate the outcomes from Process Performance mo
different methodologies which will be followed by the pro

activities.
Share the list of common errors made in earlier phases/
nature executed in the organization. The intent is to learn
Identify & share the Defect preventive strategy with the P
Implement changes on a trial basis to evaluate the above
or recommendations from previous Causal Analysis meeting
Disseminate project specific software quality goals, cli
and the organization's requirements.
Update the work breakdown structure by scheduling the re
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 Proj
Effort spent in task/phase kick-off meetings
Project Manager
Project Team
Project Learnings
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 Qu
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
consistent and timely manner. And as a last resort, when an issue remain
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 an
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 t
the type and severity of the issue.
The issue may also be escalated at AM level followed by Tower leve
escalation and Global Delivery Head (GDH) level.
PM shall identify the target date for completion of the actions t
resolve the issue.
Issue Monitoring & Resolution
For all critical issues identified in the project the closure cycle time wil
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 b
escalated to next level
The PM may decide to treat the issue as a change in scope, and invok
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
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 whe
there are some new requirements or changes to existing requirements or change in the existin
working environment.
The basic goal of the change management process is to control changes and minimize their effec
on the project.
Initiation of Change/ Problem request
Any project member/customer can initiate change/ Problem request based on the nature o
request as mentioned below :
Change Request (CR) - Any change in the allocated & approved requirements or if a ne
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 wi
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 projects 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 effor
with respect to planned effort.
Senior Management approval is required whenever the impact of PR affects the effor
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
Project Closure Procedure
The Purpose of the procedure is to define the process of handling the closure/suspension o
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) sha
verify and provide sign off for project closure activities with respect to their concerne
area (Refer Project closure checklist)
Once sign off is received from Support Functions, SQAR will verify the project closur
report and other relevant quality checkpoints and provide sign off (Refer Projec
closure Report)
Once SQAR signs off, Finance shall verify the project closure activities and provide thei
approval.
AM may initiate administrative closure of the project In case Finance requires more tim
to give sign off on various financial parameters.
On receiving approval from Finance, AM shall close the project in ESA.
Number of Case Study / Learnings shared

Executed Process performance model
Project Manager
Account Manager
Team Leaders
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

Head Business Excellence
Support Functions
Account Managers
Project Managers
Project Team
SQAG
PMR Action Items

PMR Presentation

Compliance
Software Configuration Management Procedure
Software configuration management (SCM) is a project control proc

management of software products in order to ensure product integr
traceability throughout the projects 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 bo
consist of Configuration Controller (CC), PM, AM & Client (O
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 cases
Acquired products from the customer like tools, standards, templates, te
Other items that are used in creating and describing these work products
and reports
Process performance Model output
Configuration Control
The CC shall provide the appropriate access rights to the team dependi
of the team members
The CC shall review and ensure that the configuration of CIs is be
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 appro
details could be viewed through revision history of CIs using configuratio
In case the code is being managed by both customer and Birlasoft,
maintain and baseline the code on which we are working as a back up an
In case the team is working directly on client instance & Birlasoft team i
keep copy of code then in that case project team will maintain and mana
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 (B
Configuration status accounting
Configuration status accounting is a means of recording, managing and re

changes to software items during the entire life cycle of the project.
CC shall prepare the below mentioned reports to maintain status accoun
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 users
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
Presales
Business Excellence
Support Functions
Sales
Pre Sales team
Risk Management Plan
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 customers 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
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
Team Leaders
Presales
Reviewed & Approved Estimation sheet
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 participants 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

Software Development Process

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Development Process

Uploaded by

Copyright:

Available Formats

Project Management Review Procedure

Plan for PMR

AM, PM ,SQAG, Project Team (Mandatory)

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

Conduct & Track PMR

The PM shall conduct PMR ( Refer PMR checklist CHK-31)

Number of PMR action items identified

Global Delivery Head

PMR Action Items

Software Configuration Management Procedure

Preparation of the SCM Plan

Identify Configurable items

To maintain accountability, integrity, Visibility, traceability, reproducibility , PM shall identify the

Products that are delivered to the customer

The changes in CIs are consequences of one of the following:

Requirement change request (RCR)

Configuration status accounting

CC shall prepare the below mentioned reports to maintain status accounting

Change request summary and status (Q252)

Risk Management Process

PM Identifies the risks associated with cost, schedule, and

Typical risk identification methods include the following:

Examine each element in work breakdown structure

Risk Sources & Categories

Categorize risk to provide a mechanism for organizing risks as well

Probability of occurrence (Scale 1,3,9 (Low, Medium, High))

The risks identified are analyzed, categorized and prioritized based

Risk Mitigation Plan

Risk avoidance: Changing or lowering requirements while still meeting

Risk Priority Numbers (RPN)

Risk identified at early stages

Periodic Reviews and Audits are conducted in order to ensure

Direction Setting Call

Handshake with Delivery

Deal Qualification Sheet

Number of leads Generated.

Filled Estimation sheet

Organizational objectives are identified as the Big Y.

Measuring and monitoring the performance

Data Collection and Storage

Analysis and Results

Assess the collected data based on the following Criteria :

Communicate the results

Effort spent in Metrics data collection and analysis

Business Excellence Process Group (BEPG)

Updated Project Development/Maintenance/QA Baseline sheet

System Support and Administration

The purpose of this procedure is to describes the process o

System Admin team maintains details of Hardware Allocation as per Use

Support on Hardware and Software