Let us understand the organization structure of the quality function.

The organizational structure of the quality

function has an independent escalation path way up to the chairman. Let us go the bottom way up. This is the
project organization structure. Every project is assigned a quality co-ordinator (QC). Based on the size of the
project, each project could have one Quality Coordinator or a Quality Coordinator could span across multiple
projects. The role of a Quality Coordinator does not report to the Project Manager but reports directly to the
Technical Manager. This provides an independent an unbiased escalation path for quality issues. The quality co-
ordinator is responsible for product quality. Quality Coordinator functionally reports to the Software Quality
Assurance Manager. Each vertical has a Software Quality Assurance manager and a Software Quality Assurance
team responsible for process quality. Software Quality Assurance managers report to the Group Head-Quality who
reports to the Chief Quality Officer. The Manager Software Quality Assurance functionally reports to vertical head.
Similarly Group Head Quality functionally reports to Strategic Business Unit Head. The central functions Software
Engineering Process Group, Tools Group, Knowledge management and Quality Consulting also report to the Chief
Quality Officer.
Software Engineering Process Group or SEPG is a central function dedicated to coordinate quality related activities
in the organization. It consists of the following functions

Process Development and Process Verification
Metrics
Engineering Methods
Let us take a look at the key functions of each group.

The Process Development and Process Verification Function, owns the organizational process change and
maintains the quality system veloci-Q. It evaluates process improvement proposals and implements them. This
group verifies process compliance through mechanisms like audits and assessments.
The Metrics Function, collates the metric trends across the organization and develops process performance
baselines. It establishes organizational norms and revises them on a periodic basis. It also participates in external
forums and is involved in benchmarking initiatives.
The Engineering Methods Function, collects and disseminates best practices and the latest trends in developing
software. It also evaluates latest methodologies and trends in estimation, architecture and agile methods.
The key functions of the Tools Group include:
Identifying new tools in the industry
Creating awareness on Software Engineering Tools
Ensuring availability of tool licenses when required
Providing support to project teams
Let us take a look at each in detail.
The tools group identifies new tools in the industry by working with tools vendors to evaluate new tools. It also
conducts desktop research for new tools or features.
The tools group is responsible for creating awareness of Software Engineering Tools. This is done by conducting
S.E.T sessions for project teams, conducting PMs day out for PMs, conducting vendor sessions, and conducting
hands-on workshops.
The tools group ensures the availability of tool licenses as and when required. This is done through the Online
Tools Monitoring Usage System that is the OTMUS where licenses are shared across projects and value add is
provided to customers.
Finally, the Tools Group provides support to project teams by conducting hands-on workshops in ODCs. They
setup, configure and initialize the tools, demonstrate the usage of features of the tools provide technical support
to resolve technical issues and, Provide vendor support if required.
Tools group provides the following facilities to project teams :
Tools lab
Online Tools Monitoring Usage System (OTMUS)
Tools group maintains a tools lab. Project team members can access this facility to evaluate and do R&D on various
software engineering tools. Licensed versions of standard tools are available. Also tools experts are available for
clarifications in the tools labs.
The Online Tools Monitoring Usage System (OTMUS), can be accessed at http://channelw.wipro.com/tools/.
The objective of this system is to reduce the cost of tools in projects through optimum REUSE of existing licenses.
This system ensures the availability of software engineering support tools with Just-In-Time philosophy.
Usage of tools from OTMUS brings the following advantages to the project
Reduced cost - The project team is charged on tool usage basis rather than capital cost of the tool.
Cycle time for procurement of tools is reduced - There is no need to follow up with vendor and wait for getting
the licenses
Availability of expertise - There is a single point of contact for tools. Tools evaluation reports and expertise on
tools usage can be obtained from tools group.
To summarize, in this module you learned the following:
The objectives of this course, the pre-requisites and further trainings
The quality objectives of Wipro
The quality organization structure
The functions of the Software Engineering Process Group
The functions of the Tools group.
Now, that you are aware of the organization quality objectives, structure of the quality function, the key functions
of the SEPG, the Tools group and the facilities extended by the tools group, let us check your understanding with a
quiz.
PM Roles & Responsibilities
Welcome to this module on the responsibilities and authorities of a Project Manager. In this module we will learn
about the responsibilities and authorities of a project manager. By the end of this module,
You will be able to understand the customer interfacing and management responsibilities, understand The project
execution and management responsibilities and understand
The people management responsibilities of the Project Manager.
You will also be able to understand the authorities of the Project Manager.
The role of a Project manager is key to a project's success. His role involves managing the customer and ensuring
that their requirements are translated to the project deliverables. The Project Manager is responsible for managing
dependencies, risks and issues which arise during the course of the project and ensure that they do not impact the
schedule, cost and quality expectations of the customer. The Project manager is also responsible for assigning
tasks, addressing issues, trainings, performance appraisals and mentoring the team.
Customer Interfacing and Management Responsibilities
At project initiation the project manager should make sure that the:
Statement of Work and the proposal documents are reviewed.
Estimates made and risks identified at the proposal stage are reviewed
Contractual commitments and critical to quality aspects are translated to project plans
Agreed and planned tasks on time and as per the quality norms defined are delivered
Customer complaints are appropriately addressed and customer feedback sought for every execution
The project manager should also participate in pre-engagement activities, in preparing estimates and proposals
Project Execution
A project manager is required to prepare a project plan for the project. This involves:
Selecting the appropriate life cycle and processes for the project
Identifying appropriate tools, technology, standards, process and guidelines
Identifying critical to quality parameters, main and sub process performance goals and consequently derive the
metrics plan
Planning resources and training for the project team
The project manager is also in charge of risk management, disaster recovery plan, defect prevention plan, project
configuration management and tailoring.
The project has to be executed as per plan. The project manager needs to
Allocate and monitor project activities.
Implement projects such that the set quality targets are achieved through implementation of CMMi Level 5
Ensure collection and analysis of metrics at project level and implement corrective or preventive actions based
on analysis results
Plan and implement defect prevention activities at project level
Provide timely project status to Technical Manager
Handle non-conforming items according to procedures
Perform project closure procedures on completion of the projects
People management
Project Manager is responsible for People Management. As part of this responsibility the project manager needs
to:
Define clear objectives for the team members.
Manage team members problems and aspirations.
Conduct performance appraisals for the team members
Plan trainings for the team members and recognize talent by rewarding and appreciating performance
The responsibilities and authorities of a project manager are defined in the Organization structure in the Policy
Manual in Veloci-Q.


Project Managers have the authority to do all the following tasks.
Assign tasks to the project leads and team members and monitor them.
Authorize changes to the items under configuration management
Recommend project deliverables for release
Authorize training for project teams
Authorize intermediate deliverables and patch releases to client
Recommend purchase of resources required for project execution
Identify rewards and recognition for the team.
To summarize, in this module you learned the responsibilities and authorities of Project Managers.
Their responsibilities include, customer interfacing and management, project execution and management and
people management.
Project Manager's can:
Authorize changes to items under configuration management,
Recommend project deliverables for release,
Authorize training for project teams,
Authorize intermediate deliverables and patch releases to client,
Recommend purchase of resources required for project execution, and
Identify rewards and recognition for the team.
Project Manager Interfaces Objectvies
Welcome to this module on Project Manager Interfaces. After completing this module you will be able to:
Understand the role of the PM in the broader context of project life cycle from initiation to closure.
Understand the different stakeholder groups the Project Manager interfaces in the course of project execution.
Understand the typical instances when project manager interfaces with technical manager, quality co-ordinators,
test leads, SQA, and team members.
To begin with let us take a look at the role of the Project Manager in the broader context of a project life cycle -
from initiation to closure.

The Technical Manager initiates the project in the organizational database (SAP). Practically this happens as soon
as the proposal is accepted by the customer. This project will be auto-initiated in Wipros standard project
management tool as a Suspense Project. The project manager then selects a suitable life cycle model and prepares
the Project Plan. The baseline project plan defines the projects execution process.
During project execution:
Metrics and data are collected to assess the health of the project and analyzed periodically
Risks and issues are managed.
Defect prevention activities are planned and executed.
Reviews, Testing and other Quality Assurance activities are planned and executed
After completing the project - It is the responsibility of the Project Manager to obtain a signoff from the customer
on delivery and obtain project specific feedback from the customer.
A project performance analysis must be conducted and must be verified and approved jointly by the Technical
Manager and the Software Quality Assurance manager.
Finally, the Technical Manager should close the project in SAP.
Let us now take a look at the different stakeholder groups the Project Manager interfaces with, on a regular basis,
in the course of project execution. They are-
Technical Manager
Customers
Solutions Delivery Head(SDH)
Software Quality Assurance Manager(SQAM)
External Vendors
Project Team
Business Development Manager(BDM)
Quality Coordinator(QC)
On a need basis, the project manager also interacts with-
Talent Transformation
Logistics
Talent Engagement and Development
Tools Consultants
Let us understand the typical responsibilities of the following stakeholders.
Click each to know more.
Technical manager is responsible for:
Preparing proposals
Participating in proposal and contract reviews
Initiating projects in the organization database (SAP)
Planning and allocating human resources for projects
Approving project plans
Conducting project monitoring reviews to review project progress
Ensuring timely delivery and quality of the product or the service
Resolving customer complaints
Monitoring quality goals
Participating in project performance analysis
Updating closure of project in SAP
Conducting performance appraisals for project managers and reviewing project teams performance appraisal.
Quality coordinator is responsible for:
Conducting work product reviews, configuration and test audits
Tracking errors to closure
Maintaining review records
Preparing test plan and cases for final testing
Implementing defect prevention activities
Collating quality related data and helping in preparing the Project Data and Metrics Report
Obtaining and analyzing the errors defects and initiating corrective and preventive action
Identifying quality issues before work product is delivered to customer
Test Lead is responsible for:
Assigning work to test team members and monitoring their progress
Coordinating and preparation of test plan, test design, test suite and user documentation
Monitoring and reporting progress of test activities
Coordinating, configuration management activities related to testing
Organizing and executing code reviews for test programs
Identifying and implementing reusable test software
Software Quality Assurance manager is responsible for:
Reviewing project plan for adequacy of tailoring, process, identification of metrics, defect prevention planning
and collection of data
Providing adequate assistance to project teams in identifying and implementing new processes
Provide training to practitioners in implementing quality system changes
Reviewing Project Performance reports and updating them on Project Data Bank
Project team members are responsible for:
Preparing the design
Reviewing detailed designs and test reports
Coding and unit testing
Building the software as assigned
Reviewing codes
Fixing problems in the code
Writing and modifying user documentation
To summarize you have learned that:

The role of the PM in the broader perspective of project execution.

The different stakeholder groups the Project Manager interfaces with. That is TM, customer, Solutions Delivery
Head, SQAM, Business Development Manger, Quality coordinator, Project Team and External Vendors.

The instances when the project manager interfaces with technical manager, quality co-ordinator, test leads,
SQAM, and team members.
Pre Engagement Process Qualification
Welcome to this module on the Pre-Engagement Process. The activities carried out from identification of customer
opportunity to project initiation are part of the pre-engagement process. By the end of this module, you will be
able to:

-Understand the different steps in the pre-engagement phase of a project -like Lead Qualification, Proposal and
Contracting. These constitute the set of activities which are done typically by the Pre-Sales and Sales teams from
the time we receive a lead to the time a project is kicked off, and

-Understand the commonly adopted billing models with which the projects are executed.
The Pre-Engagement Process consists of:

-Lead Qualification

-Estimation

-Proposal Preparation

-Contract Administration, and

Hand over

The starting point for Pre-Engagement Process is the point where a lead or opportunity is identified by the sales
team.

With existing accounts and customers, proactive proposals could be made by delivery teams and in such cases
leads get identified by delivery managers.

An identified lead is qualified to

-assess the stability of the customer if signing up on a new relationship,

-evaluate our capability to handle the opportunity, and

-assess the risks in executing the engagement as a Fixed

The Pre-Engagement Process consists of:

-Lead Qualification

-Estimation

-Proposal Preparation

-Contract Administration, and

Hand over

The starting point for Pre-Engagement Process is the point where a lead or opportunity is identified by the sales
team.

With existing accounts and customers, proactive proposals could be made by delivery teams and in such cases
leads get identified by delivery managers.

An identified lead is qualified to

-assess the stability of the customer if signing up on a new relationship,

-evaluate our capability to handle the opportunity, and

-assess the risks in executing the engagement as a Fixed Price

Lead Qualification generates a score - If the Risks are higher, the score generated is higher too and authority for
giving a go-ahead is based on the Qualification scores.

A suitable financial model is assigned to the opportunity based on the approval

Proposal preparation follows lead qualification. Estimation is carried out in parallel with the proposal preparation.

A detailed risk evaluation is done during the proposal stage which results in a risk score. Authority for proposal sign
off is based on Risk score, Legal Exposure rating and project value.

In order to get more details about the application or requirements, a study or due diligence exercise may be
undertaken. This leads to a more accurate estimation and proposal.

The end point of a pre-engagement process is signed contractual document and hand over to delivery team which
executes the project.

The final response to proposal document is prepared and submitted to customer.

Upon confirmation of order from customer, a formal contract to execute the project is signed with the customer.

The commitments and proposal details are handed over to the delivery team for project execution.

There are two common types of financial models for engagements. Let us learn about each of them.

-Fixed Price

-Time and Material

Click each to know more.

Fixed price

A fixed price is a contract between Wipro and the customer characterized by the following features. The customer
defines the scope and provides well defined requirements. Wipro creates detailed estimates and plans based on
the requirements. The project cost is arrived at based on the estimates. A fixed cost is quoted to the customer. The
price is signed off in a contract with clear terms and conditions. A fixed prize contract is a high risk or high reward
option. Wipro is responsible for project management and is accountable
for the quality and timeliness of deliverables. Details like team size and activity distribution are not exposed to the
customer.
Time and material
Another billing model used is the time and material model. The customer pays for the time spent by the
outsourced team to develop the software. They are charged for additional services based on the people deployed
and extensions in duration of service. The customer is made fully aware of planning and monitoring. They are
provided with time sheets and status reports that show the progress. Projects where there is a periodic or monthly
billing with a ceiling on the billed amount or revenue are also considered as the T and M projects.
We will now understand each of the pre-engagement activities in detail.
Lead Qualification:
Let us understand how a new opportunity gets identified. The most common source is through the sales force.
There could be proactive proposals made by the delivery teams which lead to an opportunity. Any identified
opportunity should be input into a system called as Sales Logix.
A lead is assigned to an owner, typically called the RFP owner.
The owner ensures that the lead is qualified.
Lead qualification is done in 2 stages -
Stage 1 is to Qualify the customer account in case of a new customer
Stage 2 is applicable only if the opportunity is to be qualified for Fixed Price execution and the value of the lead is
greater than 250 k USD
Stage 1 of lead qualification is done for new customers. The qualification criteria typically consist of prospect's
financial position, capacity for continued or annuity business and other vertical specific criteria.
Once the customer account is qualified and accepted, then stage 2 of lead qualification should be carried out.
The proposal lead fills the lead qualification checklist. The overall score value arrived in the qualification checklist
determines the further progress.
If the score value is less than or equal to 60 the proposal qualifies for FPP. The pre-engagement team can draft the
proposal accordingly.

If the score is between 60 and 85, the Solution Delivery Head or the Group Heads approval is required for
executing the project as a fixed price project.
If the score value is more than 85, the risks associated with the opportunity are higher. A decision has to be taken
by the Senior Management to execute the project as a fixed price project.
If the opportunity does not get approved for a Fixed Price execution, the opportunity for any other financial model
like (T&M) for execution is considered. The plan for responding to the lead is drawn up accordingly.
The BUSINESS DEVELOPMENT MANAGER signs a Non-Disclosure Agreement and sends an 'Intent to Respond'
communication (if requested) to the prospective customer.
Click on Lead qualification checklist to understand how to fill it.
The lead qualification checklist consists of various criteria against which the opportunity is evaluated for fixed price
qualification. The criteria are listed under "Parameter/Criteria" column.
The rating column suggests the rating to be assigned for each of the parameters.
A rating of 1 or 3 or 5 can be assigned against each parameter. The rating value is entered under the "value"
column.
The importance of the parameter/criteria for qualification is decided by the "weightage" column. For example, if
the clarity on requirements is more important than clarity of technology used, then the requirements clarity
parameter is assigned a higher number than technology parameter.
The weighted value is arrived by the multiplication of values in weightage and value column.
The sum of all the entries in "Weighted Value" column gives the overall rating.
The risks and assumptions should be noted under "Qualification Summary".
Based on the overall rating, the FPP qualification decision has to be taken. The decision should be recorded under
"Decision Summary".
The lead qualification checklist can be customized if required. Additional parameters or evaluation criteria can be
added.


The inputs to the proposal process could be:
- A request for information (RFI) or request for proposal (RFP) from a prospective customer
- Business case for a proactive proposal, or
- A qualified lead in case of new accounts and opportunities greater than 250K USD of existing accounts
On qualifying the opportunity, the lead owner identifies the proposal team with a lead to work on the response.
Based on the requirements of the proposal, the proposal team could consist of representatives from various
practice or horizontal or functional groups.
For new accounts, the Solution Delivery Head identifies the Technical Manager representative for the proposal
who will provide the technical solution and the estimation for the proposal.
For a new customer, before we furnish information to the customer, a Non-Disclosure Agreement or NDA has to
be signed. The Proposal Lead would send the NDA to the Business Finance Manager. The BFM would subsequently
send it to Group Legal for review. On clearance from the Group Legal, the NDA is signed by the Authorized
Signatory.
The BFM sends the signed NDA to the customer and obtains the customer signed copy.
If contractual terms and conditions need to be agreed during the proposal stage, it should follow the Contract
Procedure.
Pre Engagement Process Proposal
The inputs to the proposal process could be:
- A request for information (RFI) or request for proposal (RFP) from a prospective customer
- Business case for a proactive proposal, or
- A qualified lead in case of new accounts and opportunities greater than 250K USD of existing accounts
On qualifying the opportunity, the lead owner identifies the proposal team with a lead to work on the response.
Based on the requirements of the proposal, the proposal team could consist of representatives from various
practice or horizontal or functional groups.
For new accounts, the Solution Delivery Head identifies the Technical Manager representative for the proposal
who will provide the technical solution and the estimation for the proposal.
For a new customer, before we furnish information to the customer, a Non-Disclosure Agreement or NDA has to
be signed. The Proposal Lead would send the NDA to the Business Finance Manager. The BFM would subsequently
send it to Group Legal for review. On clearance from the Group Legal, the NDA is signed by the Authorized
Signatory.
The BFM sends the signed NDA to the customer and obtains the customer signed copy.
If contractual terms and conditions need to be agreed during the proposal stage, it should follow the Contract
Procedure.
Customers seek more details about Wipro's service offerings and processes using a Request for Information or RFI.
Let us understand the process for responding to a RFI.
The proposal lead prepares a scheduled timeline for the response and communicates the same to the proposal
team. The RFI questions are assigned to specific owners / practice /horizontal/functions who are part of the
proposal team.
The proposal team prepares answers to the RFI questions. The proposal lead collates all queries raised by the team
and interfaces with the BUSINESS DEVELOPMENT MANAGER and customer to get the necessary clarifications. The
query clarifications received from customer is passed back to the proposal team.
The proposal lead collates the responses from the team and adds the executive summary to response to RFI. All
the assumptions, issues and risks are logged in the Pre-Engagement Issues and Assumptions tracker.
The BUSINESS DEVELOPMENT MANAGER reviews the RFI response document before sending it to the customer.
The review should ensure completeness and accuracy on all the requirements of the RFI.
Let us now understand the proposal process for responding to a Request for Proposal i.e RFP.
The proposal lead prepares a schedule timeline for the response and communicates the same to the proposal
team.
The proposal lead conducts a response kickoff meeting with the proposal team to discuss the approach, roles and
responsibilities and the timelines. The Lead Qualification checklist is also reviewed by the team.
The proposal team studies the RFP and any other documents received from the customer to understand the scope
of the opportunity and collate the questions for clarification.
The proposal lead co-ordinates with Business Development Manager and the customer in getting the queries
clarified.
Detailed estimates for the Effort and Resource are prepared.
All assumptions and issues are logged in the Pre-engagement Issues and Assumptions tracker.
The Business Finance Manager prepares the costing worksheet for the proposal based on the inputs provided in
the estimation.
The group legal representative derives the Legal Exposure rating, if the terms and conditions of the MSA are being
discussed.
The proposal lead collates all the responses and adds the executive summary in response to Request For
Information.
The proposal undergoes a peer review.
The proposal team evaluates the risks using the Risk Evaluation Sheet and arrives at the risk score. The proposal
approval authority is decided based on the risk score.
For a new account, the Business Development Manager reviews the proposal document before sending it to the
customer. The review should ensure completeness and accuracy on all the requirements of the RFP.
For an existing account, the proposal is reviewed by the Technical Manager. The commercial section is reviewed by
the Business Finance Manager.
The BUSINESS DEVELOPMENT MANAGER or Technical Manager should fill the proposal review template, as
applicable and send it to the owner.
The proposal and all review records should be maintained by the TM.
Let us understand the risk evaluation process. The risk evaluation checklist is used for this. The output of this
process is the risk evaluation score.
The approval authority for the proposal is decided by the risk evaluation score, the Legal Exposure Rating provided
by Group Legal and the proposal value.
Click on the risk evaluation checklist to understand how to fill the checklist
The "Risk Item / Description" column lists the various aspects of the proposal that could lead to a risk.
A value 0,1 3 or 5 is assigned for impact of risk. A value 0 is assigned if it is not a risk. When the impact of the risk
on the proposal is low, a rating 1 is assigned. A medium impact is assigned the value 3 and a high impact is
assigned 5. This rating is entered in "Impact of Risk" column.
A value 0,1 3 or 5 is assigned to represent the probability of occurrence of the risk. A value 0 is assigned if it is not a
risk. When the probability of the risk occurring is low, a rating 1 is assigned. A value 3 is assigned when the
probability is medium and a value 5 is assigned when the probability of occurrence if high. This rating is entered in
the "Probability" column.
The value in "Impact of Risk" Multiplied by "Probability" gives the risk quantification value. This is entered in
column "Risk Quantification".
The recommended actions to mitigate the risk are entered in "recommended actions" column.
The person who is responsible for the recommended action and target date for completion is entered in
"Responsibility and target completion date" column.
When the risk tracker is reviewed, the actions taken are entered in the "Actions Taken" column.
The risk should be re-evaluated based on the action taken and the new risk quantification value is entered in "Risk
New Rating" Column.
The sum of values entered in the risk quantification column gives the Risk Evaluation Score.
If the risk evaluation score value is less than 72 then it is a low risk proposal.
If the risk evaluation score value is between 72 and 360, then it is a medium risk proposal.
If the risk evaluation score value is more than 360, then it is a high risk proposal.

When the proposal value is less than 250K USD and risk score is less than 72, the proposal can be approved by
technical manager.
When the proposal value is less than 250K USD and the risk score is between 72 and 360, the proposal should be
approved by solution delivery head.
When the proposal value is less than 250K USD and the risk score is greater than 360, the proposal should be
approved by business unit head.
When the proposal value is greater than 250K USD but less than 1 million USD, legal rating is E/G and the risk score
is less than 72, the proposal should be approved by solution delivery head or Group Head and Business Finance
Manager.
The vertical Head and Business Finance Manager should approve the proposal when
- The proposal value is between 250K and 1 million USD, legal rating is E/G and risk score is between 72 and 360
- The proposal value is between 250K and 1 million USD, legal rating is A/BA and risk score is less than 72
- The proposal value is greater than 1 million USD, legal rating is E/G and risk score is less than 72 and 360
The proposal should be approved by Strategic business unit head when
- The risk evaluation score is greater than 360
- The risk score is between 72 and 360, the value of the proposal is between 250K USD and 1 Million USD and legal
rating is A/BA.
- The risk score is between 72 and 360, the value of the proposal is greater than 1 Million USD and legal rating is
E/G.
- The proposal value is greater than 5 Million USD and legal rating is E/G.
The proposal should be approved by the Chief Executive Officer when
- The proposal value is between 1 Million USD and 5 Million USD, the legal rating is A/BA and the risk score is
greater than 72.
- The proposal value is greater than 5 Million USD and the legal rating is A/BA
After the proposal has been submitted to the customer, the proposal lead should also create a presentation, if
there is an opportunity for a proposal walk-through with the customer.
When the proposal is accepted, a formal communication on the acceptance should be sought from the customer.
The BUSINESS DEVELOPMENT MANAGER should update the Sales Logix on the status of the proposal. The reasons
for unaccepted or accepted proposal should be documented in Sales Logix.
The Vertical Head should analyze the Proposal Win/Loss ratio on a quarterly basis. This information should be
taken from Sales Logix.
All Proposals and related documents should be maintained by TM/Presales team, irrespective of whether the
proposal is accepted or not.
Pre Engagement Process Estimation
Estimation:
The Request for Proposal i.e. Request for Proposal owner constitutes an estimation team to arrive at project size,
effort, cost, schedule and resources estimate. The estimation team could be formed with representatives from the
vertical and various technology groups. For large Request for Proposal, there could be multiple estimation teams
involved.
The estimation process consists of the following steps -
Step 1:
Clearly understand the requirements. Seek clarity from customer if required.
Step 2:
Identify the appropriate formal estimation technique to be used.
Step 3:
From knowledge repository, identify best practices or past project data that could aid in estimation.
Step 4:
Compute the estimates for size, effort, cost and schedule.
Step 5:
Incase of fixed price projects, estimate the phase wise effort. Prepare the planning resource loading for onsite &
offshore for the entire duration of the project.
In case of maintenance projects, estimate the number of persons required to support the application.
Step 6:
Document the assumptions made and the risks identified.
Step 7:
Summarize the estimates in estimate summary form.
The output of estimation process is an estimation worksheet, resource loading sheet, costing worksheet,
estimation summary and Updated risks and assumptions.
The Request for Proposal team collates the estimates from the estimation team and prepares the response to
proposal.
Note: In large projects, 2 independent estimation teams should prepare the estimates for the project. The two
estimates should be merged by discussing their pros and cons and then the final estimate should be prepared.
The project size is an absolute measure of the software product. The size of the project is described using kilo lines
of code, function points, features or use cases and other such absolute numbers. It is important that size is
measured using these standardized size measures to ensure easy comparison between projects as well as for
benchmarking. Non-standard measures like components, screens, programs, etc should not be used for size
measurements.
Each of the size measures have standard estimation methods which are globally accepted. Some of the formal
estimation techniques are:
Work Break Down Structure
Function Points
Internet Points
Domino Points
UML Use Case Points
Feature Points
Wipro developed estimation methods
Click to know more about them.
Work Breakdown Structure
This is a bottom up estimation technique. The project tasks are decomposed into smaller components until actual
activities are defined in sufficient detail. The individual activities are estimated for effort, schedule and cost. The
sum total of individual estimates gives the project estimates.
Let us understand more about the Work Breakdown Structure estimation technique. The Work Breakdown
Structure is a bottom up estimation technique. The project tasks are decomposed into smaller components until
actual activities are defined in sufficient detail. Individual activities are estimated for effort, schedule, and cost. The
sum total of individual estimates gives the project estimates.
There are two types of Work Breakdown Structure - Activity based Work Breakdown Structure and functionality
based Work Breakdown Structure.
In Activity based Work Breakdown Structure, the project development activity is broken down into smaller tasks.
For example, the activity based Work Breakdown Structure for a development project would typically involve the
estimates for phases like requirements, design, Code and Unit Testing , testing, etc. The estimate for each phase is
arrived at from the estimates of the sub-tasks of the phase.
In a functionality based Work Breakdown Structure, the application functionality is broken down into smaller
functional units. The activities for each functional unit are listed and estimated. For example, consider a project -
development of inventory system. The application is broken down into smaller functional units like order
management, warehouse management, etc. The activities under each functional unit is estimated and summed up
to arrive at the estimate for the functional unit.
Thus in a Work Breakdown Structure, the activities and the sub-activities form a tree structure. The component at
the highest level is the root. The components below the root are the branch and lowest level components are the
leaf.
The leaf level estimates can be arrived at using the Simple-Average-Complex method or Three times estimate
method.
Let us understand more about these methods.
Let us understand the simple-average-complex method using an example. Consider there are 4 programs to be
developed in the Code and Unit Testing phase. The Code and Unit Testing phase has the following sub-activities -
Program specification and unit test case preparation, coding, review and testing.
The sub-activities are listed in page 1. The estimate for each sub-activity is worked out as in page 2.
Let us consider the sub-activity "Program specification and unit test case preparation". Based on functionality, the
programs are classified as Simple, Average and complex. The typical efforts for Simple, Average and complex
programs are entered in the SAC to person days table. With this as reference, the "value" column is updated with
the effort. The sum of efforts is computed and entered in "Sum total for the activity" as well as in the "Effort"
column of page 1 table. Similarly the estimates for other sub-activities are computed.
Let understand the Three Time Estimate Work Breakdown Structure method using the same example.
Consider the sub-activity "Coding". In page 2, for each program we arrive at 3 size estimates in number of lines of
code - a pessimistic, an optimistic and a most probable estimate. The size estimate is obtained by the formula:
(Pessimistic plus Optimistic plus 4 into the Most Probable) divided by 6
The sum of the estimates for all the programs gives the size estimate. Based on Code and Unit Testing productivity
norms the "Lines of Code to Person days" table is updated.
Size estimate (in Kilo Lines of Code) divided by "Lines of Code to person days" value gives the effort estimate. This
value is entered against Row 2 of page 1 Work Breakdown Structure table.
Similarly the estimates for the other sub-activities are arrived at. They are summarized in Page 1.
Function Points
This estimation technique is based on estimating software by quantifying the functionality based on logical design.
The numbers of function points are described in terms of number of inputs, outputs, etc. Function Points remain
constant regardless of who develops the software or what language the software is developed in.
Internet Points
Internet Points are designed for estimating a web, internet, or intranet project. They are similar to function points,
but with a better recognition of the types of web pages to be created.
Domino Points
This methodology is used for software development projects using Lotus Domino development methods. It
describes a systems functionality in terms of Forms, Navigators, Pages, and Views.
UML Use Case Points
Use-Case Points are used for development projects using the Rational Unified Process. They assume that the Use-
Case scenarios are defined in accordance with the Rational methodology and Rational sponsored training or
literature.
Feature Points
This estimation technique is similar to function points but, considers the number of algorithms used in the
application and slightly modifies some of the weightages used in function point estimation.
Wipro developed estimation methods
For some technology areas where there are no specified estimation techniques, Wipro has developed specific
estimation methods for size estimation.
The following units of size measure have been defined:
Data Warehousing Unit (DWU) -For Business Intelligence and Data Warehousing Projects
Enterprise Application Integration Unit (EAIU) - For Enterprise Application Integration Projects
Delivery Unit (DU) - For SAP and Oracle Applications
A Business Intelligence & Data Warehouse project typically consists of one or more of these three major
development components.
Data Warehouse Databases
ETL Process
Analysis and Reporting Process
Each of the above components requires a different kind of tool for its development.
Hence the size a project will have multiple unit of measures based on the tool or the development component.
A standard unit of measurement for various tools and the conversion factor into a common unit of measurement
has been derived. This common unit of measurement is Data Warehousing Unit (DWU).

A Data Warehousing Unit is an equated measure, arrived at, based on Wipro's own experience of executing Data
Warehouse projects. It is an equated size of 1 person day of code and unit testing effort as on 1st January 2005.
With this point in time as a reference, conversion factors between multiple units of measure in a Data Warehouse
project with the standard Data Warehousing Unit, has been derived.1 Kilo Lines of Code is equivalent to 10 Data
Warehousing Units.
A typical Enterprise Application Integration i.e. EAI project will have one or more of the following four major work
items:
Interfaces
Message Transformations
Business Process Model, and
Adapters
The above work items are measured as:
Interface Points for Interfaces
Points to be Considered while counting lines of code:
- In case of Multiple Languages, each language is counted separately
- Count 'Executable Statements' and 'data definitions'
- Macro instructions and unique expansions are to be counted
- Unique reusable modules are counted separately
- Changed code is counted separately from new code
- Deleted code is counted separately
- Support code is counted separately from product code
- Test case code is counted separately from product code
- Do not count commentary lines or information appended to executable lines for informational purposes
- The following are to be counted
. Verbs or action statements, such as assignments, print commands, conditionals and loops
. Equations and mathematical expressions
. Procedure definitions
. Each formal parameter with a procedure
. Procedure labels
. Unexpanded macro calls
. Expanded macro instructions
- Clearly identify and explain the specific counting rules you have selected
Transformation Points for message transformations
Modeling Points for Business Process Model, and
COTS points for Adapters
A common sizing measure, Enterprise Application Integration Unit is defined to have an Enterprise Application
Integration work items independent software sizing measure.
An Enterprise Application Integration Unit is an equated measure, arrived at, based on Wipro's own experience of
executing Enterprise Application Integration projects. It is an equated size of 1 person day of code and unit testing
effort as on 1st June 2005. With this point in time as a reference, conversion factors between multiple units of
measure in an Enterprise Application Integration project with the standard Enterprise Application Integration Unit,
has been derived.
1 Enterprise Application Integration Unit is equivalent to the Development and Unit test effort for
An Interface having size 6 interface points OR
A message transformation having size 11 Transformation points OR
A process model having size 7 modeling points OR
Adapters having size 4 COTS points
Here are some recommendations for the selection of the estimate techniques.
For Client server or GUI based technologies function points technique is recommended.
For Web Based technologies, Use Case, Internet Points or Function Points technique is recommended.
For estimating Embedded, Real Time Systems and Systems Software, Work Breakdown Structure or Feature Points
is suggested.
For Telecom, Work Breakdown Structure or the Feature Points technique is advocated.
Work Breakdown Structure is also recommended for Mainframe technologies.
Domino Points estimation technique is suggested for Lotus Domino, and
UML Use Case Points is suggested for projects using Rational Unified Process.

Project size forms the input for effort estimation. Effort can be computed from size using Productivity Norms.
The overall productivity is used to arrive at the effort required for end-to-end development project execution.
The CUT productivity is used to arrive at the effort required coding and unit testing of programs. Using the phase-
wise effort distribution norms, the CUT effort is extrapolated to arrive at total project effort.
An effort estimation model available in Veloci-Q can be used to validate the effort estimate. This model is based on
past projects' data.
Under Project Performance Models, select estimation validation model.
Select Estimation Validation Tool
Select Application Area, Size unit of measure. Enter the estimated size.
Under required parameters, select Effort and click on "Submit". The estimated effort in person weeks is displayed.


The effort estimate is influenced by certain factors. Based on these factors, the base effort estimate should be
modified suitably.
Based on the risks identified, additional contingency effort may need to be added.
Consider the type of technology to be used and Wipro's expertise in it. That is whether it is an altogether new
technology or a familiar technology.
Consider the tools and methodology used, that is the effort savings by using the tools and the efforts required for
learning and tools set up.
Identify the reusable components and to be used in the project. The estimate needs to be modified for the effort
savings due to the use of these components. However the effort needed to customize these components should
be factored in.
The productivity norms that are to be used is an important aspect of effort estimation. The basic formula to
calculate effort is:
Effort = Size / Productivity Norm
The productivity norms are available in - veloci-Q.
Another important factor is the experience and the skill level of the team.
When the above factors are considered, you will get a reasonably good effort estimate.
Sometimes it may be required to express the effort estimate in different units like person days or person weeks or
person months. The following conventions are followed while making these conversions.
One person day equals 8 hours.
One week is taken as 40 hours.
One person month is considered as 20.8 days or 166.67 hours and one year is taken as 2000 hours.
In a development project, the typical effort distribution for each phase of development is as follows:
The requirement collection and analysis -> 8 -11%
Design and PS -> 14 - 20%
Code and unit test -> 35 - 38%
System Testing -> 20 - 24%
Acceptance Testing -> 8 - 10%
Project management -> 8 - 10%


Once the project effort estimate is computed, we need to determine the duration of the project, also known as
project schedule.
Obtain the elapsed duration based on the total effort and considering 20 days effort per month. Let it be 'X' person
months.
Average holidays per year are taken to be 9 days. An average of 10 days per employee per year is considered for
personal leave and trainings.
In a year, an employee may not take any leave or attend trainings OR the employee may avail 10 days leave and
attend 10 days training. The employee could be unavailable in the project for a minimum of 0 days or a maximum
of 20 days. Thus the average unavailability due to trainings and holidays would be for (0+20)/2 that is 10 days. The
employee would be unavailable during holidays, that is 9 days. Hence, in all, the employee would be unavailable
for 10 + 9 that is 19 days for personal leave, training and holidays. This should be considered when the schedule is
drawn.
A factor Y is computed as Y = (19/12)* X.
'Y' person days is added to X person months to get a realistic schedule.
For example, if the elapsed time (`X') is 3 months, the following is the work out:
Y = ( 19 / 12) * 3 = 4.75 days ~ 5 days.
5 days is to be added to 3 months of elapsed time.
The project schedule thus derived may need to be suitably modified based on the following factors.
Employee related - holidays, personal leaves, training,
Customer related activities such as telecons, video-conferences, customer visits, presentations and on-site travel
Team related factors such as appraisals, team meetings, skills trainings boot camps, and team building activities
Project Management factors such as milestone reviews, audits and assessments.
Once the project effort and schedule are computed, we need to calculate the project cost. The factors that need to
be considered while computing cost are -
The experience level of resources, the hardware costs, the software costs, acceptance support effort, warranty
support effort, the travel cost, user training, and communication link.
There are also some other costs such as the video or the teleconferencing costs which are often overlooked but
need to be considered. There can be some other miscellaneous costs such as late working that is overtime, etc. too
that need to be considered.
The costing worksheet template available in veloci-Q is to be used to calculate the cost estimate.



Pre Engagement Process Due Diligence
Let us now understand the due-diligence process. Due Diligence is a study conducted to validate the assumptions
made in preparing the proposal and to obtain more information about the applications that are in scope for
outsourcing. Through this study, the needs of the Business, Technical, Process, HR, Legal and financial aspects of
the outsourcing are also validated.
Due Diligence should typically be conducted after the first submission of the proposal response for the Request for
Proposal and when the customer has short-listed the vendors for the bid or for an existing customer when the
Statement of Work preparation is in progress.
Due Diligence is typically carried out onsite at the customer's premises and is facilitated by a questionnaire that is
used to specify the information to be gathered regarding the applications.
Pre Engagement Process Contract
A contract is a business agreement between Wipro and the customer, forming the basis for project execution. It
contains the terms and conditions of services to be rendered by Wipro.
Contract documents can be categorized as:
-Master Contract
-Project specific Contracts covered under Master Contract such as Statement of Work and
-Letter of Intent, that is, LOI
Click each to know more.
The Master Contract
The master contract could be a Master Business Agreement (MBA), a Master Delivery Agreement (MDA), Master
Service Agreement (MSA) or an Umbrella Agreement (UA). It is finalized at the account level.
It contains negotiated general terms and conditions and includes legal aspects like Limitation of Liability,
Indemnity, Confidentiality, IP, etc
The Master Agreement also includes commercial clauses that include the payment term, warranty, billing hours
and billing rates which is optional.

A copy of Master Contract and Contract Review Record are retained by Business Finance Manager till contractual
obligations are fulfilled or as required by statutory requirements, whichever is later.

Letter of Intent

In case there is a delay in signing the master contract, the project can be initiated based on a Letter of Intent. A
Letter of Intent is an email or letter from customer indicating acceptance of proposal. On receiving a Letter of
Intent, the technical manager should raise an internal Work Order and get it approved by the Vertical Head. The
Letter of Intent is valid for 90 days and it should be ensured that the master contract is signed within this period.

A Statement of Work

is signed for each project in the account and it includes project specific terms and conditions. It covers Scope,
Assumptions, Critical Dependencies, Risks Identified, Execution Plan, Environment, Project Management, Project
Schedule, Deliverables, Change Control, Quality System Details, Acceptance Criteria and Acceptance Procedure,
Warranty or Post Delivery Support, Service Level Agreement, Payment Milestones, and other Commercial Terms
Clauses that override MASTER CONTRACT clauses. Specific attention should be paid to overriding clauses.

All contract documents are to be subject to document control.

The contract documents shall be retained until the contractual obligations are fulfilled or as required by statutory
obligations, whichever is later.

In case of internal projects, requirements Specification approved by Technical Manager shall be treated as a
Contract.
Before starting any engagement with the customer, the customer and Wipro should sign a Master Contract.

Group Legal along with Technical Manager or Proposal Lead prepares the MASTER CONTRACT and sends to
customer. After MASTER CONTRACT is discussed, negotiated and finalized with the customer, the MASTER
CONTRACT is signed by Wipro's Authorized Signatory.

The list of Authorized Signatory is available with the Business Finance Manager and Group Legal team.

The Business Development Manager sends the signed MASTER CONTRACT to the Customer for their signature. On
receipt of the signed MASTER CONTRACT back from the customer, the original document is sent to the legal
representative and a controlled copy is sent to the Technical Manager or Account Manager.

In case there is a delay in signing the Master Contract, a Letter of Intent should be signed by the customer and
Wipro.

The Letter of Intent is valid only for 90 days and it should be ensured that the MASTER CONTRACT is signed within
this period.
Before starting any project, a Statement Of Work detailing the scope, the schedule, the commercials and payment
terms has to be signed by the customer and Wipro.

Every Statement of Work should reference the Master Contract. The terms and conditions mentioned in the
MASTER CONTRACT would be applicable for each Statement of Work signed under the MASTER CONTRACT. The
terms & conditions in the Statement of Work are specific to the project.

The Technical Manager should ensure that the Project Managers and the Team Members are aware of the
responsibilities and obligations of the company as specified in the contract documents.
Let us understand some of the typical contractual commitments included in contracts.

Liability

Any contract gives rise to several liabilities. Liability is the onus to do or not do something and it is capped and
limited to controllable activities.

If there is a failure to meet any liability a compensation for the damages must be made. Damages can be direct or
indirect.

Direct Damages are made only for liability for damages of direct nature i.e.: caused as a direct result of us not
doing a required act or on doing an act not required. This type of liability could be accepted in the contract.

Liability for damages which arise indirectly on account of any direct failure should not be accepted in the contract.

Examples of Indirect damages are consequential, special, exemplary, punitive, lost income or profits, substitution
costs, loss or harm to reputation, business interruptions, etc.

Year-on-Year Improvements

Some clauses could be related to improvements in productivity or output on a regular, usually yearly basis.

Year-on-Year obligation should not be linked to financial payment. All commitments on Year-on-Year
improvements contractually committed should be converted to metrics.

Over Time Billing

In a Time and Material billing model, all daily Overtime, Weekend and Holiday Over Time and On-call 24 by 7
support should require a premium billing over normal rates.

There are many other contractual commitments which need to be taken care of in a contract.

Billing Clauses

Other expenses like travel for short term trips, training hours and others should be taken into account in the billing
clauses of the contract.

Warranty

Warranty is an obligation for the organization to remedy a problem in workmanship for a prescribed period at no
charge.

The recommended warranty period is 30 days and warranty in excess of 30 days should be costed in the proposal.

Warranty is restricted to Fixed Price engagements.

Acceptance

Clauses for acceptance of deliverables need to be paid attention to. The deemed accepted clauses to force
clients to act on deliverables within a reasonable time should be included.

Dispute Resolution

Clauses for resolution of disputes, the resolution mechanism and the jurisdiction should be essentially included to
cater for any eventuality the project might run into.
Pre Engagement Process Handover
Once the contract negotiations are completed and the customer is ready to sign the contract, the proposal details
should be handed over to the project delivery teams.

The proposal lead should collate all the details related to the proposal and prepare a hand-over docket. The docket
includes

-The customer's organization structure and contact points.

-Our understanding of the customer's business and their vision.

-A detailed note on the applications or Technology or Platforms that will be covered as part of Handover.

-Request for Proposal or Questionnaire or Email communications related to clarifications.

-Wipro response, presentations.

-Commitments, Concessions and assumptions made.

-Final version of the Estimation, Resource loading, costing sheets and Proposal.

Hand-over sessions as required should be conducted to explain the Request for Proposal, proposal response,
assumptions, schedule, questionnaire and other details of the engagement.

The project manager should revisit the assumptions and the estimates, and document his observations in the
estimation summary form. In case of major discrepancies leading to a substantially different effort estimate, the
same should be negotiated with the customer or approved by the Solutions Delivery Head or Vertical Head.

Project Manager should verify the assets being handed over and complete the Handover Checklist. The filled
checklist should be sent to the Software Quality Assurance Manager and the Solutions Delivery Head or Technical
Manager. Solutions Delivery Head or Technical Manager should approve the handover based on the checklist.
Pre Engagement Process Summary
To summarize, in these modules you learned:

-The Pre-Engagement Processes consists of the following stages

-Lead Qualification

-Proposal Preparation

-Estimation

-Contract Administration

-Hand over

-Lead qualification is done in 2 stages - to qualify the customer account and to qualify the opportunity for FPP
execution. The lead qualification checklist is used.

-Depending on the lead qualification, a proposal is made.

-A proposal team is formed to prepare the response to the proposal.

-The requirements of the proposal are distributed to the relevant groups who prepare a detailed effort, cost,
schedule and resource estimates. Some formal estimation techniques such as the following are used.

-Work Breakdown Structure

-Function Points

-Feature Points

-Internet Points

-Domino Points

-UML Use Case Points

-Wipro developed estimation methods.

-Sometimes a short study or due-diligence could be carried out to get addition information required for preparing
the proposal.

-The final proposal response is consolidated and submitted to customer

-When the proposal is accepted, a master agreement is signed with the customer at the account level and
statement of work is signed at the project level.

-Once the contract is signed, the proposal & contract documents are handed over to project team.







Project Execution Process Objectives
Welcome to this module on Project Execution process : Initiation. At the end of this module, you will be able to:

- Understand the project initiation process

- Understand the different types of projects that are executed

- Understand the various life cycle models

- Understand the engineering processes. That is

. Requirements

. Design

. Code & Unit Testing

. Testing

. Release
Project Execution Process Initiation Process
To begin with, let us understand the project initiation process.

The inputs to the project initiation process are the proposal and contract documents handed-over from the pre-
engagement process.

They include

- High level project requirements

- Accepted statement of work

- Approved work order

- Hand over docket

- Records of estimations used for the proposal /contract

- Risk Evaluation and Tracker

- Filled Cost Estimation Worksheet

- Resource Loading Sheet

The technical manager enters the project details in the organizational database, SAP. The project is tagged as
auditable or non-auditable. This should be done within one week of signing the contract or Statement of Work.

In the absence of an Statement of Work, the project should be initiated only with an approved work order. This
work order should be prepared by the technical manager with inputs including the proposal price, expected
contract price, start and end dates, deliverables milestone and payment milestones and expected date of customer
sign off of the Statement of Work.

The work order should be approved by the vertical head. The approval of the Vertical Head is valid for a period of 4
weeks. If the Statement of Work is not available after 4 weeks of the execution the approval from Vertical Head
should be renewed.
Project Execution Process Auditable and Non Auditable Process
Let us understand the terminologies - Auditable and Non-auditable Engagements.

All projects offshore or onsite where Wipro is responsible for project management and internal projects are
flagged as auditable projects on SAP.

The following type of projects can be flagged as non-auditable engagements -

- Onsite/ Offshore staff augmentation projects or projects where the project management is customer's
responsibility

- Projects which are less than 4 weeks in duration and 1 to 2 person months of effort

- All maintenance/ production support/ service projects with Team size less than and equal to 2).
Project Execution Process Initiation
All projects created in SAP and team members allocated to it are automatically initiated as a "Suspense Project" in
the Organizations standard management tool.

For an auditable project, the project manager in consultation with the SQA selects a suitable life cycle model for
the project.

Upon selection of the project life cycle, the project is converted into a valid project in the Wipros standard
management tool. The project manager will be able to plan, assign, monitor tasks and generate reports through
the Wipros standard management tool. The team members will be able to enter their efforts against the tasks
assigned to them.

All auditable projects should be converted into a valid project within 30 days.

An auditable project can remain as a suspense project only when the existing process models in veloci-Q or the
Wipros standard management tool cannot be tailored to fit the project scenario.

Such projects should define the execution process, planning and tracking specific to the needs of the project and
get the same approved by the SQA Manager.
Project Execution Process Life cycle Model Type of Projects
The different types of projects are:

Development projects

Application Maintenance and Support Projects

Testing projects

Conversion projects

Development Projects - Development Projects are those which involve ground up development of software for an
application or major feature enhancements to the existing software or applications.

Application Maintenance and Support Projects - Application Maintenance and Support projects involve bug fixing,
minor enhancements, production support and adhoc service activities.

Testing Projects - Testing Projects are those that involve test design and development, execution of testing and
building test automation scripts and executing them.

Conversion Projects - Conversion Projects are those that involve database conversion, platform conversions and
Language upgrades.
Project Execution Process Development Projects Project Categorization
Analysis of project performance of completed development projects have shown that the project effort and
duration are major factors that determine the performance of the project.

Large projects have found to perform adversely with respect to the quality parameters, schedule deviation, effort
deviation, post delivery defect rate and customer satisfaction rating.

Hence, based on the effort and duration, development projects are categorized as Small Projects or Large Projects.

Large projects have more project management control compared to small projects. You will learn more about
them in the forthcoming modules.

Note: Project performance is constantly analyzed with respect to size to determine project categories. The project
categories are determined based on this analysis. Hence refer veloci-Q for definition of Small and Large
projects.
Project Execution Process Life Cycle Models
There are various life cycle models available in veloci-Q for each of the project types. They can be customized to
address customer needs and provide a good review mechanism on process and deliverables.
Click on each to know more.
Development projects
Development projects could select one of the following process models
Waterfall Process Model

V Process Model

2I that is Incremental & Iterative process model

Agile or eXtreme Programming that is XP Process Model

Rational Unified Process (RUP)

Application Maintenance and support projects

The typical application maintenance and support services are grouped into one or more of the following life cycle
models:

Release based maintenance process model

Production support process model

Service process model

Conversion or Porting Projects

Conversion Process model. Also called Porting Process model.

Testing Projects

Testing or QA Process model.
Project Execution Process Life cycle Models Group Specific Process
Some of the generic process models like V-Process model, 2I process model, etc have been customized to arrive at
group specific process models to meet the needs of specific technology groups or practices.

Some of them are

- BI & DW Development process model

- Data Profiling Process Model

- Enterprise Application Integration Process Model

- Enterprise Application Process Model

- Lifeline Process Model

- Medical Devices specific processes

- Industrial Automation and Avionics specific processes

- Automotive Electronics specific processes

- Pharmaceutical group specific processes

- Portals Process Model

- Content Management Process Model

The advantages of group specific processes are

- They enhance specificity and reduce the scope of tailoring repeatedly by projects within the group.

- The group specific processes have been developed based on the practitioners' requirements and expertise. Hence
they enhance practitioner ownership

- Based on evolving and changing business requirements, new group specific processes can be developed, piloted,
test run and broad-based.

Project Execution Process Life cycle models - Water fall Process Model
Before we understand the various life cycle models in detail, let us understand the ETVX concept. ETVX stands for
"Entry", "Tasks", "Validation" and "Exit". A description of a process is complete only when the entry criteria, tasks
to be performed, validation mechanism and exit criteria are identified for the process. 'E' specifies the entry
criteria, that is inputs for the process. It could be a document or code or checklist, etc. 'T' specifies the task to be
performed. It could be preparing a document or writing the code, etc. 'V' represents the mechanism for validating
the tasks performed. It could be a review or a test. 'X' specifies the exit criteria. For example, the approved
requirements document is an exit criterion for requirements phase. Thus each phase of a life cycle model will have
the E, T, V, X criteria described. Often the exit criteria for a phase forms the entry criteria for the subsequent
phases.
Let us take a look at the different life cycle models for development projects:

Waterfall Process Model

The Waterfall Lifecycle model also known as the "classical lifecycle" or the "linear sequential model" is
recommended for Small development projects.

The salient features of this model are Development progresses through analysis, design, coding, testing and
warranty phases sequentially. Requirement analysis phase begins after successful demonstration of feasibility of
the project. Design starts after requirements analysis is complete

Coding begins after the completion of design activity and

Testing starts after coding is completed.

And the System is installed after successful completion of testing.

The key activities that are carried out at each phase are -

Requirements Phase:

Requirements study

Preparation of requirements specification and

Preparation of traceability matrix.

Design Phase

Preparation of comprehensive design

Updation of traceability matrix.

Construction Phase

Development of source code

Preparation of unit test plans and test cases.

Unit testing of source code and

Preparation of user documentation.

System Integration and Testing Phase

Preparation of system test plan and test cases.

Perform System testing

User Acceptance testing and Warranty Support

Preparation of acceptance test cases

Perform user acceptance testing

Fix issues raised by customer during user acceptance testing
Project Execution Process V Process Model
V-Process Model

This process model is recommended for large development projects and Small development projects involving
mission critical systems.

The salient features of this process model are:

Test planning and development is done along with the development phases of Requirements Specifications,
Functional Specifications and Design.

Acceptance planning is done during Requirement Specifications phase.

System test plan is developed during the Functional Specifications phase.

Integration test plan is done during the Design or Detailed Design phase.

The key activities that are carried out in each phase are:

Requirements Specification Phase

Requirements Elicitation

Preparation of requirements specification.

Preparation of acceptance test plan and

Preparation of bi-directional traceability matrix.

Functional Specification phase

Preparation of functional specification.

Preparation of acceptance test cases

Preparation of system test plan and

Updation of traceability matrix

High Level Design Phase

Identification and evaluation of design alternatives

Design approach selection and preparation of high level design.

Preparation of system test cases

Preparation of integration test plan and

Updation of traceability matrix

Low level design phase

Preparation of low level design specifications.

Preparation of integration test cases

Preparation of unit test plan and

Updation of traceability matrix

Construction Phase

Develop source code

Unit testing of source code

Preparation of user documentation and

Updation of traceability matrix

Integration testing phase

Perform integration testing and

Fix integration testing defects

System Testing Phase

Perform system testing and

Fix system testing defects

Acceptance Testing Phase

Perform user acceptance testing and

Fix acceptance testing defects

Install the system in customer's environment

Obtain client sign-off
Project Execution Process 2I Process Model
2I Process Model

2I that is iterative and incremental process model is recommended for projects where requirements are evolving
and cannot be frozen at the beginning of the project.

Here the entire project is split into a number of mini projects, each one being an iteration.

Each iteration has all the phases of a development project that is requirement analysis, design, construction,
testing, and release.

Each iteration is planned in such a way that unclear requirements are pushed to the later stages of the project so
that they can evolve as the project progresses. An increment is a small and manageable part of the system that is a
subsystem. An iteration can have multiple increments constructed in it. Thus, an increment adds functionality or
subsystems to the system, where as each iteration refines the previous subsystems.

The key activities that are carried out in each phase are:

High level requirement specification

Preparation of broad requirement specifications

Preparation of overall project plan

Iteration Planning Phase

Preparation of iteration plan

Requirements Specification Phase

Requirements Elicitation

Preparation of Requirements Specification

Preparation of Acceptance test plan

Preparation of bi-directional traceability matrix.

Analysis Modeling Phase -

Preparation of Functional Specifications

Preparation of Acceptance Test Cases

Preparation of Integration & System test plan

Updation of traceability matrix

Architectural Design Phase

Identification and evaluation of design alternatives

Design approach selection and preparation of architectural design document.

Preparation of integration & system test plan

Preparation of integration & system test cases

Updation of traceability matrix

Construction Phase

Preparation of unit test plan and test cases

Develop source code

Unit testing of source code

Preparation of user documentation

Updation of traceability matrix

Integration testing phase

Perform integration testing

Fix integration testing defects

System Testing Phase

Perform system testing

Fix system testing defects

Acceptance and Evaluation Phase

Perform user acceptance testing

Fix acceptance testing defects

Obtain client sign-off
Project Execution Process Large Development Projects
For Large Development Projects, the following are mandated.

During requirements elicitation, voice of customer tool should be used to analyze requirements

Sub-system level requirements should be derived and documented in the requirements specification.

Table review with the client is mandated for review of requirements specification.

A requirements management tool should be used by the project for managing requirements

A functional specifications phase should be carried out after the RS phase. In this phase the requirements should
be analyzed and detailed functional specifications should be prepared.

A prototype or proof of concept should be carried out to assess the technical feasibility of complex requirements.

Failure Mode Effect Analysis that is FMEA technique should be applied to design and design risks should be
identified and addressed.

Preparation of sanity test plan and test cases for testing the core functionalities to be delivered.

A build co-ordinator should be identified for the project to the build activities. A build plan should be prepared.
After each build, appropriate code quality metrics should be analyzed and build completion report should be
prepared.

After a successful build, sanity testing should be conducted. Code that has successfully completed sanity testing
should be released for integration and system testing.

Build should be performed on System tested code post fixing the defects logged in System testing. Sanity testing
should be conducted on completion of system testing before releasing the deliverables to the customer.

Project Execution Process XP Process Model
eXtreme Programming or XP as it is commonly known, is a methodology that is recommended for development of
new products or major enhancements to existing software products. XP can also be followed for release based
application support and maintenance project.

XP in essence is a time boxed iterative, incremental methodology. Timeboxing implies start and end time of an
iteration are fixed while the contents can vary. Customer decides on the priority while team decides on the effort.
XP also puts increased stress on engineering discipline.

XP lifecycle follows the following phases - Exploration, Planning, Iteration and Release.

The key activities carried out in each phase are -

Exploration Phase

Preparation of story cards. Story cards are a form of specifying the requirements.

Planning Phase

Estimate preparation for the story cards

Prioritization of story cards for the release

Release planning

Iteration phase

Iteration planning

Development and implementation of the story cards selected for the iteration

Daily stand up meetings

Release Phase

Release of deliverables and documentation

XP recommends the following key practices to be followed during the lifecycle of the project.

Click on each to know more.

Release planning game

Developers and QA estimate the effort required for implementing the stories or the features. Based on the
estimates, customer selects the stories that can add maximum value to the application, to be implemented in a
release.

Iteration planning game

Customer selects the stories for the iteration. The individual stories are broken into tasks and the task lengths are
estimated by the developers.

Small and frequent releases

Evolutionary delivery. Each request cycle is short with specific functionality that is added to the software, which
can be used by the customer.

Simple Design

Focus is on the design for that particular iteration or release instead of speculative design.

Test First

Write unit test cases first and then the code to make the test pass. All unit test cases should pass before the code
is checked in.

Refactoring

Simplify and clean the code and design, without changing the functionality. This is also called continuous design
improvement.

Pair programming

Two programmers sit together on a computer to code. When one programmer is coding, the other termed as
observer, is intended to perform real-time code review as well as think about the big picture.

Collective ownership

No single owner for any piece of code. Anyone can fix any piece of code if required.

Continuous Integration

Code that is checked-in to the repository is compiled and all test cases are run automatically preferably on a daily
basis.

Sustainable pace

A team should be able to continue working on the project forever with the same energy levels.

On-site customer

Customer(s) is to be available with the development team for the complete life cycle to provide clarifications on
stories.

Coding Standards

Due to frequent refactoring, swapping partners in pair programming and collective code ownership, common
coding standards is necessary.

Retrospectives

A meeting to discuss lessons learnt and best practices from previous iterations and suitable action is identified and
implemented. Metrics from the previous iteration are also analyzed as part of the retrospective. All these feed into
the next iteration planning.

Daily Standups

A short meeting held everyday during an iteration in which inputs from each team member on key questions
What happened yesterday? What is the plan for today? Are there any roadblocks? Any new tasks discovered?
Any lessons to share?

Metaphor

Used to explain the system being developed in simple terms. Helps the team to have a common view of the project
objective.
Project Execution Process Rational Unified Process (RUP)
The Rational Unified Process Model or RUP is recommended for large development projects.

RUP prescribes Iterative development process for application development. This process model incorporates the
best practices of software development and is more suitable for projects following Object Oriented Application
Development methodology.

Typically the RUP model consists of the following phases: Inception, Elaboration, Construction, and Transition.

The key activities carried out in each of the phases are -

Inception Phase

Formulating the scope of the project

Planning & preparation of business case

Developing the design approach and a decision on make/buy/reuse of components for the solution

Prototyping

Elaboration Phase

Baselining the architecture

Preparation of detailed architecture plan

Preparing the development environment

Construction Phase

Development and testing of solution components

Assessment of product releases

Transition Phase

Executing deployment plans

Testing final deliverables

End user training


Project Execution Process Development Projects Guidelines for Life cycle model Selection
Application Development
Criteria for Evalution Life Cycle Models

Waterfall Vprocess 2I XP RUP
Requirements Volatility Low Low High High Medium
Requirements Clarity High High Medium Low Medium
Development type Bespoke Bespoke/Product Product
Bespoke / Product /
Feature enhancements
Bespoke
Availability of Business
users
Low Medium
High and tapers
to Medium
Medium
High and tapers
to Medium
Criticality of the project Low High Medium Low High
Complexity -
Technical & Business
Low, Low Medium, Low High, High High, Medium
Medium,
High
Size Low High High Medium High
Customer Involvement
Life Cycle
Low Low Medium High Low

We have understood the life cycle models that a development project can choose from.

This table gives some guidelines for selecting a life cycle model for a development project.

For example, when the requirements are fairly clear that is requirements volatility is low, waterfall or V-process
model could be selected. But when the requirements are evolving and are not very clear initially, 2I or XP process
model is recommended.
Project Execution Process Application Maintenance & Support Process Models Application Transition
Let us now understand more about application maintenance and support process models.

The first task in an application maintenance and support project is the transition of application and process
knowledge from the customer or existing vendor team to Wipro team. Typically the customer's applications would
be maintained by their in-house IT team or another vendor team.

Wipro team will have to gain an understanding of the applications that need to be supported and the current
maintenance processes followed. The application transition model provides a systematic way for carrying out this
activity.

The key activities carried out in each phase of this process model are

Application Assessment Phase: The objective of this phase is to assess the off-shoreability of applications,
sequence the applications to be offshored and arrive at transition timelines. The key activities carried out in this
phase are

-Obtaining information on applications, execution environment and support through client information.

-Analyzing the off-shorability of the applications using the outsource-offshore matrix.

-Sequencing the applications for transition

-Deciding the transition phases and transition duration for the applications

Master Transition Planning Phase: The objective of this phase is to develop a master transition plan, identify
transition risks and arrive at a resource plan for the transition activities. The key activities carried out are

-Determining the scope of transition in terms of applications, infrastructure and people to be transitioned.

-Identification of external vendors and dependencies.

-Identification of transition deliverables, evaluation plan and acceptance criteria, typically covering criteria for
evaluating the readiness to move into Parallel Perform and Steady State phases.

-Determining the roles and responsibilities of the transition team

-Planning for the training needs for the team covering domain, technical and behavioral aspects.

-Identification of the transition governance model covering periodic reviews, status reporting, both internal and
customer specific reviews.

-Identification of tools & techniques, data security, disaster recovery and continuity management plans for
transition.

-Setup of a joint Risk Management Committee with client representatives.

-Preparation of Master Transition Plan.

-Table review of Master Transition Plan

-Customer Sign-off of Master Transition Plan

KAP: The objective of this phase is to gain and demonstrate knowledge of the applications that are being
transitioned. The key activities carried out in this phase are:

-Planning for knowledge acquisition phase This involves deciding the mechanisms for knowledge acquisition that
is classroom sessions, self study and hands-on and preparing a detailed plan for the same.

-Setup of infrastructure required for transition

-Applications orientation training

-Trainings for individual applications

-Preparation of System Maintenance Technical Document i.e SMTD document and Execution Process Document i.e
EPD Document.

-Monitoring the progress of KAP and taking suitable corrective or preventive actions for smooth completion of KAP

Parallel Perform Phase

The objective of this phase is to obtain hands-on experience of handling maintenance requests. This phase is
executed in 2 sub-phases Shadow support phase and primary support phase.

The key activities carried out during shadow support are:

-Set up of infrastructure required for carrying out the parallel perform activities.

-Understanding the request or ticket handling process

-Knowledge transfer from onsite team to offshore team

-Analysing major observations (such as increased support or interaction time/effort) and devising remediation
plans

-Documenting shadow support learnings in System Maintenance Technical Document and Execution Process
Documents.

The key activities carried out during primary support are:

-Transfer of primary ownership of the applications support to Wipro team.

-Defining offshore-onsite handshake on hand over of tasks.

-Finalizing and baselining the System Maintenance Technical Document and Execution Process Documents.

-Sign-off with the customer on service levels.

Transition Governance

The purpose of transition governance is to monitor the transition phase of the engagement and make a go or no-
go decision to steady state of application maintenance.

The overall progress of transition should be monitored during KAP and parallel perform phases by means of
periodic progress review meetings. The participants for progress meetings should be transition manager, program
manager and other stakeholders identified in the master transition plan.

The following aspects should be reviewed in the progress meetings.

-Master transition plan

-Transition Dashboard

-Deviations in planned and actual schedule and efforts.

-Risks involved

-Progress against planned infrastructure setup

-Progress on previous meetings action items.

At the end of KAP, readiness of the team to move to parallel perform phase.

-At the end of parallel perform phase, readiness of the team to move to steady state

On completion of application knowledge transition, the project should select one of the application maintenance
and support process models based on the kind of support services to be provided.
Project Execution Process Maintenance Process Models Release Based Maintenance
The release based maintenance Life Cycle model is applicable for a project that works on bug fixes and
enhancements of an existing application.

The fixes and enhancements are made as part of planned scheduled releases. The releases could be time boxed
with scope changing based on the inflow of bugs/enhancements or the scope could be determined during the
initial release planning phase and the release schedules fixed accordingly.

The key activities carried out in each phase of this process model are

Maintenance Planning

Preparation of Maintenance Plan

This phase overlaps with application knowledge transition and is usually carried out during parallel perform phase.

Release Planning

Identification of enhancements or bug fixes for the release

Regression test planning for the release

Planning for sanity testing for the release

Preparing the build plan for the release

Maintenance Phase

Prioritization and allocation of requests planned for the release

Analysis and implementation of the changes

Unit testing of the changes

Regression testing phase

Perform regression testing

Perform Build and sanity testing
Project Execution Process Maintenance Process Model Production Support Process
Production Support Process model is used for projects which involve support of a large set of applications or
products on field. The activities in such a project could involve incidents which may or may not need code fixes,
monitoring batch cycles and jobs, performing scheduled tasks and building enhancements. Production Support
projects are usually governed by Service Level Agreements.

The key activities carried out in each phase of this process model are

Production Support Planning Phase

Preparation of production Support Plan

This phase overlaps with application knowledge transition and is usually carried out during the parallel perform
phase.

Production Support Phase

Performing scheduled tasks

Performing job monitoring activities

Resolution of tickets or incidents

Implementing enhancement requests and

Performing adhoc requests

Release Phase

Carrying out release activities as per production support plan

Project Execution Process Maintenance Process Model Service Process Model
Service Process Model is used for projects where the activities supported are heterogeneous in nature. The service
requests being handled are typically development activities which could be one or more non consecutive phases of
the development life cycle.

The different types of services provided could be:

* Code and Unit Testing

* Requirements Analysis

* Proof of Concept

* Tools Evaluation

* Benchmarking

* Performance Tuning

* Analysis and Consultancy

* Testing of programs

* Design services

* Document Review.

Click on the attached table to understand the Entry, tasks, validation and exit criteria for each of these service
types.

Service Model should not be used when the ownership of the maintenance of a product or application lies with the
support team.
Service type Entry Task Verification Exit
Coding and
Unit Testing
* Design
Document
* Analyze the design
document
* Estimate schedule,
effort, size
* Prepare unit test
plan and test case
* Code the Program as
per design
document
* Compile for
successful execution
* Review the code
* Conduct Unit testing
* Review of unit
test plans and test
cases against
design document
* Review the code
against design
* Unit tested
code
* Unit test plan
* Unit test cases
Requirements
analysis
* Client request
for Requirement
Specification
* Requirement
Elicitation
* Requirement Study
* Requirement
Specification
* Review of
Requirement
Specification.
* Reviewed and
approved
Requirement
Specification
document.
Proof Of
Concept
(POC)
* Client
Request for
POC
* Requirement
Elicitation
* Review of POC. * Reviewed POC.
* Requirement Study
* Create Proof of
Concept
Tools
evaluation
* Tool to
Evaluate
* Analyze the tool to
evaluate
* Strategy for Tool
evaluation
* Evaluate the Tool
* Create evaluation
report
* Review of
evaluation report.
* Reviewed
evaluation
report.
Benchmarking * Work product
to benchmark
* Analyze the work
products to
benchmark.
* Create strategy to
benchmark
* Use Pugh matrix
* Perform
benchmarking
* Create
benchmarking report
* Review
benchmarking
report.
* Reviewed
benchmarking
report.
Performance
Tuning
* Client
Request for
performance
tuning
* Code
* Analyze the tuning
requirements
* Strategy to perform
tuning
* Perform tuning
* Create tuning report
* Review the
deliverables
(Code), if any.
* Review tuning
report
* Reviewed
deliverables, if
any.
* Reviewed
tuning report.
Analysis and
Consultancy
* Existing
system/
program to be
analyzed
*
Scope/Objective
of the analysis
work
* Study the existing
system/program
* Estimate, schedule,
effort, error,
productivity
* Perform analysis
* Acceptance by
review of the
report
* Review the
report
Analysis report
with relevant
supporting Docs.
Testing of
programs
(UT,
* Program or
system to be
* Using the
functionality
related/design
* Verification of
test results against
test plan/test
* Tested code
* Test plan/Test
Performance
testing, ST )
tested
* Test plan and
test cases
Functionality
related or
design
documents
document study the
program/system to be
tested.
* Estimate schedule,
effort, error
* Prepare test
plan/test case if
necessary
* Conduct the testing
and log the results
cases.
* Acceptance by
review
* Test Audit
cases (optional)
* Test results
Design
service
* Design
document
template
* Requirement
specification
and/or design
document
* Analyze the input
document
* Estimate schedule,
effort
* Design as per
template and as per
the input document
* Document
review
* Reviewed and
approved Design
document
Document
Review
* Customer
supplied
document
* Estimate schedule,
effort
* Review the
document
* Review metrics * Review report

The key activities carried out in each phase of this process model are

Service Planning Phase

Preparation of service plan

This phase overlaps with application knowledge transition and is usually carried out during the parallel perform
phase.

Service Phase

Prioritization and allocation of service requests

Analysis and servicing the requests

Release Phase

Carrying out release activities as per service plan
Project Execution Process - Maintenance Process Models Guidelines for Life cycle Model Selection


Application Support and maintenance

Release based
maintenance Production Support Service

Enhancements to existing
Product or Application
Support of a Large set of
application/products on field
Heterogeneous requests being
handled

Defined Product Release
cycles-time boxed or
scope fixed
Predominantly SLA base
measurement
1.No release based activity
2.No ownership for product or
application maintenance

Patches and Emergency
fixes part of scope ---------------------------
Development activity where
only one phase in the life cycle
is required as part of the
service

Project Execution Process Conversion Process Model
The Conversion Process Model is used for Conversion and Porting projects in which components of a software
system are modified from one language or platform to another, while delivering the same business or end-user
functions.

The typical activities carried out in each phase of this process model are

Conversion Study Phase

Understanding the scope of conversion activity

Preparation of conversion plan

Conversion Phase

Converting the source code

Preparing Test data and cases

Unit Testing the converted code

Regression Testing Phase

Preparation of regression test plan and test cases

Performing regression testing

Acceptance Testing Phase

Release of deliverables

Acceptance testing of delivered code.
Project Execution Process Testing Process Model
The testing or QA process model is applicable for projects that handle repetitive test cycles. The typical activities
carried out in each phase of this process model are -

Test Requirements Phase

Study of requirements to be tested

Preparation of test requirements document

Planning Phase

Preparation of project plan

Test Development Phase

Deciding testing approach

Development of test plan and test cases

Test Execution Phase

Setup of test environment

Execution of test cases

Release/Acceptance/Test cycle closure Phase

Release of test results

Sign-off by customer


Project Execution Process Engineering Process Requirements Introduction
Let us now understand the requirements process

Once the proposal has been accepted and the contract signed with the customer, the project proceeds with
collecting the requirements for the project.

The requirements process involves the following activities.

- Gather or elicit requirements from user groups

- Organize, clarify & consolidate requirements

- Articulate Requirements and resolve conflicts

- Validate Requirements

- Prioritize requirements

- Identify Acceptance Criteria

- Prepare requirements specifications document

- Obtain customer sign-off on requirements

Through the course of the project, manage changes to baseline requirements. The output of the requirements
gathering process is the base lined requirements specification document that has been reviewed and signed-off by
the customer and project teams.

To carry out these activities, the project manager identifies a requirements study team. The study team would
include personnel with technical and domain expertise.

The requirements specification is an important document as further project activities are based on this. Hence it is
very important to have a good understanding of the requirements and document them in clear, unambiguous
terms.

Project Execution Process Engineering Process Requirements Gathering
The study team identifies the relevant users or user groups they have to interact for obtaining requirements.

Then they decide on the approach for meeting the users. Some techniques are

Interviews

Focus Groups

Surveys

Brainstorming sessions

Click on the requirements gathering techniques to learn more about them.

Interviews can be used to learn about a particular segment or new features where we do not have a hypothesis as
to their needs.

Advantages:

- Interviews are very focused and are excellent for understanding concepts and seeking clarifications

- They can be conducted telephonically or in person

- They form the basis for focus group interviews

Challenges:

- Interviews could be time consuming

- The responses could be influenced by interviewer bias

- Prior preparation, interviewer skill and well defined questions determine interview outcomes.

- Typically smaller samples of responses are obtained

Focus groups are primarily used to gather a collective point of view from several key stake holders at same time to
test if a certain hypothesis concerning their needs is true.

Advantages:

- Focus group discussions are very helpful in understanding collective needs of a group.

- They are an excellent medium for obtaining clarification & definition of terms

- They can be conducted with various segments or stakeholder groups

- The response rate is usually very high

Challenges:

- Organizing focus group discussions could be a time consuming process.

- The discussions could get influenced by moderator bias

- The group can be influenced by dominant personalities

- Typically smaller samples of response data are obtained.

Surveys are often used to obtain customer needs and priorities on a large scale to aid statistical analysis.

Advantages:

- Surveys help in targeting a large audience and getting diverse views

- The survey data is usually large and hence helps in arriving at statistical conclusions

Challenges:

- Selecting the right audience for the survey

- Framing the right questions

- Getting adequate responses from the participants

The purpose of brainstorming is to generate, clarify, validate, consolidate ideas and firm up requirements.

Advantages:

- Brainstorming is essentially a team activity.

- Brainstorming sessions could be very focused and lots of ideas are generated in a short time

- It helps to get team buy-in as the contributions have come from the team.

Challenges:

- Brainstorming requires a facilitator who is good at encouraging and moderating participants

- The facilitator should be able to keep the discussion focused and help the participants to articulate their
ideas.


Project Execution Process Engineering Process Requirements Gathering Techniques Technique Solution
The table here gives some guidelines for selecting a suitable requirements gathering technique
Characteristic Mail Phone
Phone
Automated
Call Back
In-Person
Group
Sessions
Written
Electronic
Data Collection Costs Low Moderate Moderate High Moderate Low
Time Required To Collect High Low Medium High Medium Low
Response Data Moderate High Moderate High High High
Interviewer Bias None Moderate None High Low None
Acceptable Length Of Survey Long Short Medium Medium Long Short (One Screen Or Page)
Ability To Obtain Open-Ended
Responses
Low Low Low High High Medium
Perceived Anonymity High Low High Low Moderate None


Project Execution Process Engineering Process Requirements Gathering
Based on the approach, the relevant people are intimated and interviews or workshops scheduled.

The requirements gathering checklist is reviewed and customized for the study. The study team should be able to
gather functional and non-functional requirements. The non-functional requirements could be requirements
related to performance, security, usability, compatibility, flexibility, reliability, portability, etc.

The study team should also be able to draw operation concepts and scenarios.

The operation concepts and scenarios form the basis for developing use cases for the system.
Project Execution Process Operational Concepts and Scenarios
Let us now understand what is meant by "Operational Concepts and scenarios".

An "Operational Concept" is a general description of the way in which an entity (product, product component or
project deliverable) is used or operates.

An "Operational scenario" is a description of possible sequence of events that includes the interaction of the
product with its components, environment and users. Operations scenarios are used-

- To evaluate requirements

- To design and develop the system

- To develop validation test cases
Here is a case study that shows how Operational Concepts and scenarios are developed.

Following are the requirements of an audit server module for a security product, which secures the web
applications.

Requirement 1: XML Configuration file updation

Requirement 2: Support for email and SMS messaging

Requirement 3: Case sensitiveness for all repository entity.

Requirement 4: Support for a third party log analysis tool, Sawmill

Click each to know how Operational concepts and scenario are defined.

Requirement 1: XML Configuration file updation

When audit server is up, it should provide a GUI for configuration file update.

After all the information is filled and submitted the changes should be automatically updated in the XML file.

The new configuration should be effective when the server restarts.

Requirement 2: Support for email and SMS messaging

When an event of a specified audit level, such as "Unauthorized access attempted", occurs,

An email should be sent to administrator

Also an SMS message should be sent to administrator's mobile.

Requirement 3: Case sensitiveness for all repository entity

Role, resources, user id, etc should be case sensitive. For example, User name Ajay & ajay should be taken as 2
different users.

Requirement 4: Support for a third party log analysis tool, Sawmill

From the audit server log selection screen, when log statistics button is pressed, the control should transfer to
Sawmill GUI.

All the Sawmill GUI options of analyze logs should be available to user.
Project Execution Process Engineering Process Requirement analysis Tools
The requirements as gathered from user groups should be analyzed. There are some tools that help in analyzing
requirements. Let us understand them.

Click on each to know more.

Affinity diagram

Affinity diagram is a tool used to organize and present large amounts of data which includes ideas, issues,
solutions, and problems into logical categories. It is used to discover meaningful groups of ideas within a raw list. It
is used to allow the groupings to emerge naturally instead of preordained categories. This method is also known as
the KJ method after the inventor Kawakita Jiro.

Voice of Customer

VOICE OF CUSTOMER is a powerful tool that is used to gain clarity of the requirements and identify missing
requirements.

KANO Model

KANO model is a methodology that helps to determine the influence of requirements of a product on customer
satisfaction. Using this tool, we can profile customer requirements and identify how they influence customer's
perceived quality of the product.

Quality Function Deployment

QUALITY FUNCTION DEPLOYMENT is used to prioritize the requirements and identify critical requirements based
on quantitative scores. The QUALITY FUNCTION DEPLOYMENT also helps in identifying parameters that are
important to the customer that is Customer Critical to Quality Needs.
Project Execution Process Engineering Process Requirements analysis
Now that we have seen the various Requirements Analysis tools, let us move further and learn about
Requirements Specifications. As a result of requirements analysis, the study team should identify requirements
that are incomplete, unclear, ambiguous or conflicting and get them clarified from the user groups.

The requirements specifications document should be prepared. The Requirement Specifications should include
user and system requirements covering functional, performance, internal and external interface requirements,
maintenance requirements, Non-functional requirements, statutory and regulatory requirements and acceptance
criteria.

Acceptance criteria are an essential part of requirements specification. It includes the criteria for acceptance of the
delivered software. It includes

List of all deliverables

Target environment of the Acceptance Test

External dependencies which might affect the Acceptance Test

Approving authority for Acceptance Criteria

In some projects, there could be a need to develop a prototype or proof of concept. A prototype is a trial product
used to verify the technical feasibility of complex requirements. It is also used to validate requirements related to
user interfaces like GUI, screens, navigations and others.
Project Execution process Engineering Process Requirements supplied by Customers
In some projects, customer provides the requirement specification for the project team. The project team should
analyze the requirements and identify unclear, ambiguous or conflicting requirements and get them clarified. The
requirements analysis tools like VOICE OF CUSTOMER, QUALITY FUNCTION DEPLOYMENT and others should be
used. The project estimates should include at least 5% of effort for this activity.

The project team should also verify if the acceptance criteria is clearly specified. If Requirement Specifications does
not have clear acceptance criteria, then the project team should define the acceptance criteria and obtain
customer signoff.
Project Execution Process Bi directional traceability Matrix
Once the requirements specification is prepared, the Bi-directional traceability matrix is prepared.

Each business requirement could translate into a number of system and sub-system requirements. Multiple
components of the design could address a requirement. In the construction phase, a number of programs or
modules could implement the requirement and there could be multiple test cases to test the functionality. The Bi-
directional traceability matrix helps to trace requirements through design, code and test cases.

This document is prepared in the requirements phase and the relevant sections are updated in the subsequent
phases of the project. For example, in the design phase, the traceability between requirements and design
components is updated.

Using a traceability matrix we can find out if all the requirements have been addressed in the design, construction
and testing phases.

The traceability matrix is also very helpful in analyzing the impact of changes to requirements. When a
requirement changes, the affected sections of the design, code and test cases can be identified.

This matrix not only helps to trace requirements to test cases, but also helps to trace test cases to requirements.
When a test case fails, we can easily trace the requirements that are not met. Hence it is called Bi-directional
traceability matrix.

Project Exectuion Process Engineering Process Requirement Management
The signed-off requirements specifications form the baseline requirements.

During the course of the projects there could arise changes to these requirements. They should be
handled as change requests. For every change request, the impact of the change on the design, project
estimates and cost should be analyzed and discussed with customer. After obtaining customer approval,
the project plan should be revised and the change should be implemented.

Requirements management tools like Requisite Pro, Doors, Calibre RM and others are quite helpful in
managing requirements.

The usage of a requirements management tool is mandated for large development projects.
Project Execution Process Engineering Process Design Process Overview
The design process involves translating business or functional requirements into technical solution. The
requirements and functional specifications form the inputs to this process.

The key activities of the design process are:

-Identify design alternatives

-Establish operational concepts and scenarios for each alternative.

-Evaluate the alternatives and select the best design solution.

-Prepare design specifications

-Obtain customer approval/sign-off for the design.
Project Execution Process Engineering Process Design Process Design Selection
-Having understood the customer requirements, the project team should identify all possible design
solutions and document them in the Design Alternatives document.

-Operational Concepts and scenarios such as use cases and event trace diagrams should be established
for each of the alternate solutions.

-Various criteria such as technology, performance, constraints, design issues and others should be
identified for evaluating the design alternatives.

-The design alternatives should be evaluated against these identified evaluation criteria and the most
effective design selected.

Pugh matrix is a design tool that is quite helpful in evaluating the alternatives and selecting the best
design. Click here to know more about Pugh matrix.

Additional information on usage of Pugh Matrix is available in veloci-Q under Guidelines section.
Project Execution Process Engineering Process Design Process Design Elaboration
The best design solution that is selected from the alternative solutions, should be elaborated.

Design methodologies such as prototyping, design patterns and design reuse should be used to develop
a robust design.

Non-functional aspects such as maintainability, modularization, coupling and complexity of modules
should be taken care in the design.

ACE or architecture complexity estimator is a design tool that helps to measure complexity of the
architecture. Complex modules should be broken into smaller manageable units.

The project team should then mistake proof the design by identifying ways in which the design can fail.
The design should be suitably modified to handle these failure modes. Design Failure Mode Effect
Analysis or DFMEA is a design tool that is used for this purpose.

Non-functional aspects such as maintainability, modularization, coupling and complexity of modules
should be taken care in the design.

Click here to know about Architecture Complexity Estimator and DFMEA
Architecture Complexity Estimator
ACE, the Architectural Complexity Estimator, is a tool that measures complexity of the architecture or a
system. The ACE measure can be used to evaluate architectural or design alternatives using complexity
as an evaluation criteria.

The tool measures the dependencies between the modules, which is Coupling and the number of
functions performed by each module which is Cohesion. Coupling and cohesion together define the
complexity of the architecture.
To measure architectural complexity, the first thing that you need to do is to draw the high level block
diagrams of the modules or systems or subsystems comprising the system.

Then define the interfaces or dependencies between the systems. The interface is characterized as
extremely dependant, highly dependant, moderately dependant or less dependant. This defines the
coupling. To define the dependencies, click the mouse on the dependency arrow and drag the mouse
cursor between the systems or subsystems boxes. Repeat the dependency definition by clicking the
mouse on the dependency arrow and dragging the cursor between the required systems.

Then you need to define the number of functions performed by each system or subsystem. The higher
the number of functions, the lower is the cohesion. Cohesion is defined by placing the cursor on the box
and pressing the right mouse button. You will get a drop down box and one of the elements will be
number of functions. Now, choose the number of functions. Repeat this exercise for each system or
subsystem. Now you need to estimate the dependencies.

Click the Estimate Dependencies button. You will get a matrix that shows numerical figures of the
dependences between the subsystems.
Next click on Calculate ACE. You will get another table.

The first column is the "Names of the sub-systems"; the 2nd column is the "Number of Functions
Performed" by the system. Next, is MDSI which stands for Module Dependency on System Index.

This indicates how much the module is dependant on the system. Then, we get SDMI, which is the
systems dependency on the module. Next is MCC, which is the modules contribution to complexity. The
next column is the "No-cohesion or Lack" of cohesion. You will find that for sub-systems that have a
higher number of functions, the lack of cohesion is high. The last column is TCC, which is regarding total
contribution to complexity. This is useful to estimate the effort for the module, and also to make work
allocation decisions.

If we measure the system or sub-system complexity for past projects, we can baseline complexity norms
for technology specific architectures. This will help the team to take corrective actions in future
architecture development i.e. when the ACE value for architecture goes above a norm, then the team
can decide to re-design.
By looking at the Module Contribution to Complexity and Total Contribution to Complexity, we can
make architectural decision as to which design is superior. Complexity is a predictor of efforts, by
measuring which, we arrive at a more accurate estimate for modules.

This will help in assigning modules based on the skill levels of the people, which means, the ability to
differentiate between what should be assigned to an experienced person and what to a fresher. By using
the complexity indicator, the efforts can be estimated and a better bid can be given to the customer.
The effort estimate is much closer to the reality.
Project Execution process Engineering Process Mistake Proof Design
Mistake Proofing or POKA Yoke (Poka Yokee) means ensuring that mistakes are never possible in the
first place. There is a likelihood of human error but how do we design a system in such a way that even if
people make a mistake, the system will never let them make a mistake. Simple examples we are familiar
with are a VIP suitcase that cannot open upside down or floppies, which cannot be inserted the other
way around. Mistake Proofing is built in the design process so that the system never fails and is always
safe.
Failure Mode Effect Analysis (FMEA)
Failure Mode Effect Analysis is a disciplined process that allows the practitioner or engineer to anticipate
failures and prevent them even before they occur, or even if they occur, they would minimize the risk of
the impact.

Failure Mode Effect Analysis is a process of de-risking design. It is a structured approach, and it helps us
to identify ways in which a design can fail to meet critical customer requirements. It helps to estimate
the risk of potential failures quantitatively and take appropriate actions based on the risk priority.
When do you do RCA (Root Cause Analysis)?

A Root Cause Analysis is done after the event occurs and then we put corrective actions followed by a
preventive action in place. While Root Cause Analysis is done after the event, Failure Mode Effect
Analysis is done before the event. While Root Cause Analysis is reactive, Failure Mode Effect Analysis is
proactive. As part of your Look Ahead Meetings, Failure Mode Effect Analysis is a very powerful tool
which you can use for de-risking design.
Before we learn about Failure Mode Effect Analysis, let us look at definition of some of the terms.

-Severity denotes the impact of the failure. Could also be concerned with safety and other risks if failure
occurs.

-Occurrence- It denotes the frequency of occurrence of the failure mode.

-Detectability - Capability of Current Controls to detect the failure mode.

All the three use a scale of 1-10, with 1 being best or lowest risk, 10 being worst or highest risk.
Failure Mode Effect Analysis takes its inputs from Trade Off Matrix, that is, the best possible design
approach. Let us look at a simple form here. The first column says, process step or part number, but how
do you relate it to your design areas? It is the best possible alternative that comes out of the Trade Off
Matrix.

The question is how can the best design alternative fail, and if it fails, what is the effect? Next, what is
the severity of the failure mode? You rate the severity on a scale of 1 to 10. 1 being low severity and 10
being high severity.

Next, is the potential causes of the failure mode. There can be many causes for a single failure mode.
We can list down many potential causes.

Next is the likelihood of occurrence. 1 being low occurrence and 10 being high occurrence.

Next, are the current controls. If current controls are strong, then it is easy to detect the failure mode.
That is you rate detectability as 1 if it is easy to detect and as 10 if it is difficult to detect.

Next, we calculate RPN, which is the Risk Priority Number (RPN) by multiplying Severity x Occurrence x
Detectability. If we have scores of 9, 9, and 9 for Severity, Occurrence, and Detectability then the Risk
Priority Number will be 729.
Based on the Risk Priority Number, we would come up with some recommended action; put up a
preventive action or mistake proofing plan in place, and decide upon the members responsible to
implement it.

Just like the risk management plan which you plan at the beginning of the month, monitor, track and
control, Failure Mode Effect Analysis also follows the same process. Having come up with the initial Risk
Priority Numbers, action plans and assigning it to the individuals, we start reassessing Risk Priority
Numbers at periodic intervals.

We check to see if the frequency of occurrence, detectability, and severity has come down. Severity may
or may not change, unless you do something drastic to ensure that severity also comes down. 729
should come down to at least 81.

That is what you do as part of evaluating Risk Priority Numbers over a period of time. If we find that the
Risk Priority Number has come down to a lower level we can remove the risk. If Risk Priority Number is
still at higher level take a look at the prevention plans again and take appropriate action to mitigate the
risk.



The input to the Failure Mode Effect Analysis is the best possible design alternative which comes from
either the Pugh Matrix or the Trade off Matrix. The steps of the Failure Mode Effect Analysis process for
each function and feature are:

1.First, identify potential failure modes.

2.Then identify the effects of the failure modes.

3.Identify the severity of the failure mode on a scale of 1-10. 1 being low severity and 10 being the
highest severity.

4.Identify the potential causes for the failure mode.

5.Rate the occurrence frequency of the failure mode. 1 being low occurrence and 10 being the highest
occurrence.

6.Assess the current design controls.

7.Rate the detectability of the failure mode. If the current design controls are robust, then it is easy to
detect the failure mode and hence detectability will be 1. If the current design controls are weak, then it
is difficult to detect the failure mode and hence detectability will be 10.

8.Now calculate Risk Priority Number, which is the Risk Priority Number, by multiplying severity *
occurrence * detectability.

9.Based on the magnitude of Risk Priority Number, prioritize the failure modes, determine
recommended actions, assign responsibilities for closure of action, and finally recalculate Risk Priority
Number periodically and assess risk status.

Here's an example, of how a project team has applied Failure Mode Effect Analysis. The potential failure
mode is global and static variables used in the Linux are added to the task control block while porting to
V x Works. The potential effect of failure is that the system crashes and the severity is 9.

The potential cause is that multiple tasks are accessing the same global and static variables. The
probability of occurrence of this failure is rated as 9. There is no current design control. Hence,
detectability of the failure mode is weak and it has been given a rating of 7. Risk Priority Number is 567
and recommended actions assigned to individuals are shown here.

The risk of implementation has to be assessed periodically.
Project Execution Process Engineering Process Design Specifications
Let us now understand how to prepare design specifications after elaborating the design. Design
specifications should be prepared to document the selected design. Based on the complexity of design,
the project team could prepare the design specifications using one of the following approaches.

Approach 1

Prepare the high level or architectural design and then the detailed design or program specifications.

The high level or architectural design includes information on modules and the interfaces between the
modules.

The detailed design includes the processing details of each component or program.

Approach 2

For projects where the modules are few, a comprehensive design document could be prepared. The
comprehensive design includes information on the architecture design as well as program specifications.

The project team should also update the bidirectional traceability matrix with the requirements to
design traceability information.
Project Execution Process Engineering Process Design Review
The draft Design specification that is high level design, detailed design or comprehensive design
documents should be reviewed. For large development projects, table review of the design is mandated.

The reviewed design should be discussed with the customer and sign-off should be obtained. The
baselined design documents should be placed under configuration management.

During the course of the project when change requests involving changes to design are implemented,
the design documents and traceability matrix should be updated.
Project Execution Process Engineering Process Developing Code
CUT that is construction process involves translating the design to source code, testing individual
components and integrating them.

Detailed design or comprehensive design document forms the basis for development of code.

During the planning stage itself, the project manager should identify ways to improve CUT productivity
and improve code quality.

Effective methods such as automatic code generation, code reuse and design patterns usage should be
considered.

Code generation and code review tools should be identified and procured.

Coding standards and Naming conventions to be followed should be identified and should be made
available for the team members.

The Project Manager should also decide the scope of the code review based on the project needs. The
code review should cover the entire developed code or the code for critical modules.

The generic code review checklist should be customized and the project specific checklist should be
available for the team for performing code reviews.

The errors found in the code reviews should be analyzed and suitable measures should be taken to
reduce the defects.

In the construction phase, changes to the design should be recorded in Design Implementation Changes
Form. The consolidated list of changes to design should be implemented as a single change request at
the end of construction phase.
Code quality metrics should be captured for the source code developed. When any of the metric
exceeds the suggested norms, the developer should refine the code and recheck the metrics. Tools are
available for measuring the Code Quality Metrics. When the code is run through the tool, Code Quality
Metrics are captured. Refer to OTMUS (On-line Tools Monitoring Usage System) for details about the
tools available for measuring Code Quality Metrics

Following are the code quality metrics that need to be computed

. Cyclomatic Complexity Indicates the complexity of the program

. Efferent Coupling Indicates the dependency of the class on other classes

. Depth in inheritance tree Indicates the distance of the class to the root of the inheritance tree.

. Number of methods per class Number of methods in a class including constructors

. Number of attributes per class Number of attributes in a class.

A class should be dependent on as few other classes as possible. The Metric that is used to measure this
dependency is Efferent Coupling represented as Ce or Outgoing Dependency. Ce should not be high for
Domain classes, Business classes, Utility classes and Common classes. If a package has a large number of
controller or facade/Wrapper classes, Ce can be > 20 but should not exceed 30. High Efferent Coupling
indicates that the package is not stable. This will limit the package's re-use.

In order to reduce Efferent coupling, minimize

1. The number of classes with which another class collaborates

2. The number of message sends between a class and its collaborator

3. The amount of collaboration between a class and its collaborator.

4. Fanout in classes.

The Depth in Inheritance Tree represented as DIT measures the distance from the class to the root of
the inheritance tree. Depth in Inheritance Tree should not be > 5 as it may effect the readability and
maintainability of code. If Depth in Inheritance Tree value is high, large number of methods and
variables are likely to get inherited which may affect performance.

Class with very large numbers of methods points to incomplete class identification. The Number of
Methods per Class represented as NMC is the metric used to count the number of methods in a class
including constructors. In case of pattern classes such as facade/wrapper classes and controller classes
the Number of methods per class can be > 15 but should not exceed 20. A class with very large number
of methods typically means that fine grain object identification has been missed. At this stage, have a
hard look at your design to identify more classes.

The Number of Attributes per class represented as NAC is the metric used to count the number of
attributes in a class. If the class is a Domain class or Business class, Number of Attributes per Class can
be >20 but should not exceed 30. If a class has large number of attributes this indicates that the class is
not focussed. In such a case the class needs to be broken down into smaller classes.

The recommended norms for the code quality metrics for C++, Java, C# and .NET technologies are:

. Cyclomatic complexity: less than 10

. Efferent Coupling: 0 -20

. Depth in Inheritance: 0-5

. Number of methods per class: 5-15

. Number of attributes per class: 5-20

Note: Refer veloci-Q for the latest organization norms for these metrics.
Project Execution Process Engineering Process Unit Testing
Let us now learn about Unit testing. Once the source code has been developed, it should be unit tested.
Unit test cases should be written based on unit test plan.

Suitable unit testing tools should be used to reduce unit testing effort and improve test efficiency. The
necessary drivers, stubs and test programs should be used for unit testing.

The errors identified should be logged and fixed.

The unit tested code should be made available for build. Build co-ordinator should perform the build as
per build plan.

On successful completion of build, sanity testing should be performed. After sanity testing is successfully
completed, the code should be released to the testing team for integration and system testing.

The project team should also prepare the user documentation such as user manual, operations manual,
online help and others as per requirements of the customer.
Project Execution Process Engineering Process Build Plan
Let us understand more about the build process.

Build can be performed during

. Construction phase

. Completion of Construction Phase

. During the testing phases

. Completion of each of the testing phases

. And before release to the production

A build coordinator should be identified for the project to the co-ordinate the build activities.

The project manager in consultation with the build co-ordinator should prepare the build plan. The
frequency of builds for Construction phase and subsequent Integration and System Testing phases
should be identified in the Build Plan.


Here is the Build process Flow for a full life cycle project.
At the end of construction phase, development build is carried as per build plan. On successful
completion of build, the code is baselined and released for integration and system testing. Once
integration and system testing defects are fixed, QA build is performed upon successful completion of
build, the code is baselined and released for User Acceptance Testing or Regression testing. Once User
Acceptance Testing defects are fixed, production readiness activities are carried out. Production build is
performed. On successful completion of production build, the code is baselined. A Release note is
prepared and the code is released for production.
Prior to carrying out a build, the PM should ensure readiness for build by carrying out configuration
audit. The audit should typically focus on:

1. Integrity of baselines against projects change requests and Traceability Matrix.

2. Closure of all testing defects

3. Proper code compilation

4. Environmental sanity

5. Correct build instructions

6. Check-in of all files

The exit criterion for a successful build is passing of sanity test. A Sanity test is conducted to ensure that
the software being built is valid enough and basic functionality is working before turning it over to the
next level of testing.

At the end of a build cycle, a Build Completion Report should be prepared. In case a Build fails, the Build
coordinator should report the same to the project leads. The code fixes should be made to ensure
success of the build.

The following Build metrics should be captured for each build.

Cycle time for build completion

Number of build failures before build success

The baselined code that is outcome of a successful build should be packaged for deployment to the next
phase as per the build packaging process identified in build plan.
Let us now look at the various sections of a build plan.

The purpose and scope of build and the stakeholders are documented in the Introduction section. The
hardware, software, tools and personnel requirements are documents in the Resource Requirements
section. The following details are captured under the Operational Requirements section.

. Entry Criteria The criteria for commencing the build activities are documented here.

. Exit Criteria The criteria for closure of build activity is noted here.

. Build Process and Procedures In this section, step by step build procedure, aspects like environment
readiness, verifying baselines, ensuring correct library files and make files, are documented.

. Build Sequence - The order and sequence in which the build activity will be executed is noted. In case
of incremental development, the different builds and the order in which the build and integration are to
be done will be documented.

. Build Packaging - Details on how the output of the build process will be packaged to be deployed on
the next level, is noted here.

. Sanity Testing Needs The procedures to conduct Sanity Testing is documented here.

The dependencies, risks and assumptions are also documented in the build plan.
Project Execution Process Engineering Process Test Development
The test development process involves 3 main activities-

-Establishing test approach

-Developing test plan and test cases and

-Developing test scripts or code for executing the test cases

Test Approach

This activity involves developing a test strategy for the project. The various types of testing that are
appropriate and required for the project are identified. The resources required for the testing activity
are also identified.

The typical testing conducted for a development project are unit testing, integration testing, system
testing, sanity testing and user acceptance testing.

For maintenance and conversion projects, unit testing and regression testing are conducted.

Test Cases Development

This activity involves development of test plan and test cases for each type of testing to be conducted.

The Orthogonal Array technique is quite helpful in developing an optimum number of test cases.

Test Scripts development

This activity involves development of test scripts and code required for executing the test cases. A
README file that aids the testing team to build test suite, run the tests and interpret the results should
also be prepared.

On completion of test development, bi-directional traceability matrix should be updated with
requirements to test case traceability information.

Click here to know about DOE and Orthogonal Array techniques.
Let us now look at testing process.

Testing is carried out to verify and validate the source code that has been developed.

As decided in the test approach, different tests like unit testing, integration, system testing and user
acceptance testing and regression testing are carried out at the suitable phase of the project.

Before testing, the necessary test data and test environment are setup.

Then the conditions as mentioned in the test cases are executed and the results compared with the
expected results. Any differences between expected and actual results are logged.

The development team fixes the errors and the testing team should retest them. Additional rounds of
testing may have to be conducted until the test exit criteria are met.

At the end of integration and system testing, the Quality Coordinator does a test audit and records the
observations in test audit report.

The Technical Manager or Project Manager should review the test audit report and give the approval for
release.

Acceptance testing could be conducted by the project team or the customer. The acceptance test
defects should be logged as post delivery defects or field errors and fixed.

On completion of acceptance testing, customer sign-off should be obtained.
While we are on the topic of testing, you will learn how to measure the reliability of the software
product. Measuring reliability will help us to ascertain product quality and help project managers decide
when to stop testing. It also helps us to plan for resources during the sustenance phase.
Challenges in the Testing

Circumventing the Challenge
To overcome the challenge we need a method to measure software reliability. Wipro's software
reliability model helps in the same. ORTHOGONAL ARRAY based testing which provides uniform
coverage coupled with reliability assessment will provide a robust testing strategy.

Project Execution Process Engg. Process Reliability & Software Reliability Modeling
Reliability is defined as the probability that the software will work without failure for a specified period
of time. It also reflects the probability of failure free operation over a period of time.
Software reliability models help us to assess the latent or residual defects in the product. There are two
types of software reliability modeling, Static and Dynamic.
Project Execution Process Engg. Process Types of Reliability Model
Static models are used to model based on static and past data to derive empirical models. Examples of
these are defect propagation models, regression models etc.

Dynamic models are of two kinds, Rayleigh and exponential. Exponential growth model are also known
as reliability growth model. While Rayleigh, models the entire development process, reliability growth
model models the testing process. Dynamic models are based on current project data.

Project Execution Process Engg. Process Reliability Growth Model
Reliability growth models are further categorized into, time between failure models and fault count
model. We will now focus on fault count model.




Project Execution Process Engg. Process Generic Realibility Model Assumptions
Here we will learn about generic reliability model assumptions. The assumptions for fault count models
are that the time intervals are independent of each other. Also that the testing between time intervals is
homogenous.

The number of defects detected in different time intervals is independent of each other. The most
important for all models is that if there is lack of effective test planning and execution it would result in
overly optimistic predictions. Also for comparisons across products, additional data like coverage, and
test efficiency should also be factored.
Project Execution Process Engg. Process Assumptions behind Wipro Software REalibility Modeling Tool
Here we will look at the assumptions of Wipro's Software Reliability model. Since testing effort is not uniform
always, defects have been normalized with respect to test cases. Test cases should have an acceptable amount of
coverage, probably should have used ORTHOGONAL ARRAY.

The time sequence of the test data should be maintained, i.e. if there are 10 weeks of testing data, the timeline
should be preserved. At least 75% of the testing should be complete and a scatter plot of the defect trend should
show a downward trend.

Project Execution process - Engineering Process Steps of Reliability Prediction
Here we will see the general steps for reliability prediction used by the Wipro's software reliability estimation tool.
First, plot the defect data. Compare test defect trend with standard distributions. Find the best fit among the
distribution. Estimate model parameters. Finally, make predictions. Test the model using data from past projects
to validate if the prediction and actual match.
Now, let us see how the tool works. Step 1 is to specify cumulative test cases.

Step 2 is to enter the cumulative number of defects detected.

In Step 3 you have to click on this button to estimate remaining defects.

This window here is a result of the previous screen where in you will enter the required confidence level. To
proceed you will have to click on continue. The screen shot that you see here shows the results table 1 which
indicate that the remaining defects in the system is 24. The prediction table here tells how many defects will be
detected if that many test cases are executed. The result table here indicates the additional test cases required to
detect 24 defects.

In the next step enter number of test cases for which you want to estimate number of defects. Next, click on this
button and you will see that for 1200 test cases system estimates that 58 defects will be remaining.

Then you have to click on this button to estimate defects for features yet to be tested. On clicking this button a
window will be displayed which displays the number of features tested, number of features untested, and relative
complexity weightage and then click on proceed. Now, what happens here is that if you have already tested 15
features and 5 are untested. If the complexity of your tested feature is say high and you rated it 9, then the defects
in the untested feature is 273.
Project Execution Process Engineering Process Review
Let us now look at the review process.

Reviews are conducted to find errors or defects in the work product.

The inputs for a review could be documents such as requirements specification, project plan, design specifications,
etc or code such as source code, test scripts and test code.

On completion of the document or code, the author submits the work product to the reviewer.

Reviewer analyses the work product and identifies errors, records them in a review form and passes them to the
author for rework.

Author works on the feedback provided. Once the errors are fixed, the reviewer verifies the work product and
when all the review comments have been fixed, approves the work product.

Project Manager should analyze the review data. When the review metrics exceed the norms, root cause analysis
should be done and suitable corrective action should be taken.

The review effort and defect data should also be used to take measures to reduce the effort and defects in the
subsequent phases of the project.







Types of Reviews
There are two types of reviews.

Table Review

Peer Review

Click on the icons to know more.

Table Review

Table review follows the typical Fagan's method of inspection. Review members have assigned roles as Reader,
Reviewer, Recorder and moderator/Review Team Leader (RTL).

Review items are sent in advance to the reviewers for preparation.

Reviewers come prepared with all identified issues. A review meeting is held where the issues identified by all the
reviewers are presented and discussed. The recorder logs all the errors. At the end of the review session, the
review team decides if the work product should be approved or review team lead's verification after rework or
another review session after rework. Table review is mandated for RS, Plan, Design and Test plans for large
development projects.

Peer Review

In a peer review, one or more persons other than the author review the work product. The review comments are
logged in the review form and sent to the author for rework. Once the errors have been fixed, the reviewer verifies
and approves the work product.



Answer is 3 option
Project Execution Process Engineering Process Release
Release Process The activities involved in delivery of work products to the customer form the scope of
the release process. The work products for release could be intermediate deliverables or final project
deliverables.

There are three types of releases.

-Intermediate Release

-Formal Release

-Patch Release



Intermediate Release

These are releases made during the life cycle of the project. These could be contractually planned
deliverables or releases made on request of the customers for demo or evaluation purpose.

The project manager in consultation with QC and SQA manager should evolve the process of
intermediate releases and document them in project plan.

Formal Release

This release involves the delivery of work products and contractually agreed as a final project
deliverables. In a release based maintenance project all planned schedule releases of Formal Releases.

Patch Release

In development projects post release defects fixed are released as patch releases. In maintenance
project fixes that are implemented after a formal release or a patch release.
Project Execution Process Engineering Process Release - Type of Release
In a Development project, releases could be

-Intermediate Release

-Formal Release or

-Patch Release

In a Maintenance project, releases could be

Patch Releases / Individual Maintenance request release and

Maintenance Releases
Project Execution Process Engineering Process Release - Formal Release Process
Let us now look at the formal release process.

During project planning, the plan for releases and the deliverables of each release is identified, The plan
for pre-release, release and post release activities are documented in the project plan.

Prior to the release the quality co-ordinator conducts a test audit and configuration audit of the
deliverables. The test audit is conducted to ensure that Testing is done as per Test plans, errors detected
are resolved and log of the tests conducted are available.

Configuration audit is conducted to ensure the integrity of work products.

The project manager then prepares a release note. The release note includes the list of deliverables of
the release, installation instructions, known bugs, known performance issues if any and work a-rounds.

A Release Review team is set up. The team reviews the deliverables; Test Audit and Configuration audit
reports and the release Note. The review observations are documented in the release review summary
form. Based on the feedback from the release review team, the technical manager approves the release.

Once the release is approved, the project deliverables are released to the customer through electronic
transfer after necessary security checks. The Release Note is also sent along with the deliverables.

The period from the release to the acceptance of the deliverables and warranty is the post release
period. During this period, the defects reported by the customer are fixed and implemented. The project
manager also prepares the schedule for project closure activities.

At the end of the post release period, the project manager should obtain a formal sign-off of the
deliverables.

In case explicit sign-off is not obtained within the agreed timeframe, the customer should be
communicated about the "deemed acceptance" clause as per contract.


Project Execution Process Engineering Process Maintenance Projects
In a maintenance project the bug fix requests received from the customer are recorded as a
maintenance requests that is MR. Each MR goes through the following processes.

-Impact Analysis

-Implementation

-Regression Testing and

-Release & Acceptance.

Impact Analysis

Based on the information provided, the bug is simulated and the source of the bug is identified. The
solution to fix the bug is identified, which could be a code fix or a data fix.

Implementation

The changes as identified by impact analysis are implemented. Suitable source code or data changes are
made and unit tested.

Regression Testing

Regression testing is carried out to ensure that the changes made do not impact the existing
functionality of the system while meeting the requirements of the MR.

Regression test is carried out when access to the complete product source code is available. At the end
of regression testing, the regression test report is prepared.

Release & Acceptance

The individual bug fixes and major releases are released as per Maintenance plan. Before the release the
deliverables are verified. Each release includes the impact analysis of MRs and release note apart from
the deliverables.

Once the maintenance requests are accepted, they are closed.

To summarize, in these modules you learned about:

- Project initiation process

- Life Cycle Models

- Engineering Processes

. Requirements

. Design

. Construction

. Testing

. Release

. Maintenance

- Reviews, Testing

. Release

. Maintenance


Project Management Process Planning Overview
Welcome to this module on Project Management Process: Planning. By the end of this module, you will
be able to understand:

The project planning process

The project shared vision

The process performance model

The key project metrics

The main and sub process goals

The various sections of the project plan

The defect prevention activities that are conducted in a project

The Configuration Management process

The Document Control process

The Disaster Recovery process

The typical System Administration activities carried out in the project

The Risk Management process

The Tailoring process
To recapitulate, at the end of the pre-engagement process, the proposal documents are handed over to
the project team for executing the project. The proposal lead updates the project manager with the pre-
engagement activities and the commitments made to the customer.

Prior to starting the planning activities, the Project Manager reviews the proposal, contract, initial
estimates, risks and assumptions. In case the project manager identifies differences or issues, they
should be discussed with technical manager and closed with suitable action plans.

As part of Project Planning, Project Manager carries out the following activities.

The project team with their roles and responsibilities is identified.

A project shared vision is derived and a team charter is prepared. The life cycle model is chosen for the
project and tailored to suit the needs of the project.

The risks identified at the pre-engagement stage are re-assessed. Additional risks are identified and
mitigation and contingency plans are arrived at. The methodologies, tools and techniques to be used are
identified Main process and sub-process goal are identified; consequently, the metrics to be tracked are
identified. Configuration Management activities to be carried out are identified.

Defect prevention activities are identified.

Issues that require a structured decision analysis are identified and documented in decision tracker.

The results of the project planning activities are recorded in the project plan document.

Project Plan is reviewed by Software Quality Assurance Manager and approved by the Technical
Manager.

The output of the project management processes are: the project plan, the project schedule, the risk
management plan, the communication management plan, the decision tracker and the master list of
documents

NOTE:

The Project Plan should be approved within 3 weeks of project initiation.

Projects greater than 75 person week of effort should use a planning tool such as MS Project.

The Project Plan Contents are:

Project Overview

Project Development and Target environment

Resource Plan

Training Plan

Tools and Methodology Plan

Milestone and Project Monitoring Plan

Development and Quality Process plan

Metrics Plan

Defect Prevention Plan

Configuration Management Plan

Disaster Recovery Plan

Back-up Details

Risk Management Plan

Standards and Guidelines
Project Management Process Planning Project Metrics Definition
Shared Vision is very important for any project. What takes place at the strategic level is that the
organization's guiding principles, mission and values are established. Based on this the organization's
shared vision is derived. Once the organization's shared vision is instituted, the business plan for the
year is derived. This is followed by deriving an operating plan and business targets for the year for
Verticals. The goals and objectives of Technical Manager are set, based on the vertical's goals and
objectives.

The project shared vision is based on

-Organization's Shared Vision

-The Vertical's goals and objectives

-The organization's process performance baselines

-Customer requirements and

-The project needs

The project shared vision helps to articulate the purpose of the project and create a unity of purpose
amongst the stakeholders

The project vision helps to derive the main process performance goals and Sub-process performance
goals for the project.

The goals and objectives of the project manager are then derived based on the project shared vision.

The goals and objectives of team are derived from Project Manager's goals and objectives.

Project Manger should

Involve team members in deriving project shared vision

Conduct kick-off meeting and share the vision, goals and objectives of the project with all the project
stake holders.

Communicate the project shared vision periodically to the team to reinforce the relevance of the shared
vision in performing individual and team activities and tasks.

The organizational vision of an OFFSHORE DEVELOPMENT CENTER is articulated as

At the OFFSHORE DEVELOPMENT CENTER our endeavor is to be the customers first partner of choice
through technology leadership and synergy.

The project shared vision of a project in this OFFSHORE DEVELOPMENT CENTER is To show continuous
improvement in productivity, deliver good quality and value added services in the journey towards
providing turnkey solutions.

This can be achieved by,

Ensuring 100% SLA adherence for acceptance and resolution of incidents, and

Improving the productivity by more than or equal to 15%.
Project Management Process Planning Process performance Model
Process Performance Model

The main aim of any project to have a satisfied customer by delivering a product or service that meets
the customers requirements. The customer satisfaction rating or the CSAT rating is an indication of this.
Let us understand the factors that determine this rating.

The performance of the project influences the customers rating. The project performance is determined
by:

schedule deviation Indicates whether the project is delivered on time.

Effort deviation Indicates whether the project is delivered within the planned effort.

Post Delivery Defect Rate Indicates the quality of deliverables.

Schedule and effort deviation are influenced by the overall productivity of the project.

The factors that determine productivity are

The size of the project

The team size

Technology

Expertise profile of the team members

Tools Usage

Amount of re-use code or components used in the project

Requirements volatility

Rework effort

The factors that affect Post Delivery Defect Rate are phase containment and defect removal efficiency.
Defect removal efficiency is the number of errors identified and rectified in a phase. Phase containment
is the number of errors of the earlier phases that are detected in the later phases of the project.

Phase containment and defect removal efficiency are determined by the number of errors identified and
fixed through reviews and testing.

The number of errors detected in reviews and testing is indicated by the defect density.

Thus the process performance model indicates the various linkages between processes in a project
execution scenario and hence is very helpful in setting project specific main-process performance goals
and sub-process performance goals.

For example, if I need to improve the schedule deviation of the project, I can look at the factors that can
be improved to meet the objective.

Project Management Process Planning Project Metrics Definition
Project Metrics

The metrics that need to be tracked for a project are:

Metrics that are required to meet contractual commitments or Customer specific Service Level
Agreements

The key metrics specified for the project life cycle model.

The sub-process metrics that are used to track main process performance goals.

Once the project metrics are identified, the necessary data to compute the project metrics needs to be
captured in the project.


Let us understand the key metrics for different types of projects.

Click each to know more:

For Development Projects, the mandatory metrics are: Schedule Deviation, Effort Deviation, Overall
Productivity and Post Delivery Defect Rate.

The recommended metrics are Requirements Volatility, CUT Productivity, Phase Containment, Code
Review Rate, Test Case Efficiency, Defect Density, Defect Removal Efficiency and Phantom Error Rate.

The additional mandatory metrics for large projects are:

Unit Test Case Density

System Test Code Coverage

Percentage residual defects predicted

Review effort percentage

The recommended cost of quality metrics are:

Appraisal Cost

Preventive Cost

Internal Failure Cost

External Failure Cost

Performance Cost

Cost of Quality

Cost of poor quality

The metrics for conversion projects is similar to development project metrics. However in conversion
projects, conversion productivity is computed instead of CUT productivity.

The mandatory metrics for Maintenance projects and Service projects are Not on Time Index, Rejection
Index and Enhancement Productivity.

The Bug Fix metrics for maintenance projects are: age of open bugs, overall bug fix productivity, mean
time to fix, average resolution time and backlog management.

Other metrics are the schedule deviation for enhancement Maintenance Requests, schedule adherence
of enhancements and post delivery defect rate for enhancement Maintenance Requests.

Release Level Metrics are:

Release Schedule Deviation

Backlog Reduction Percentage

Post Release defect rates

The Enhancement Metrics for maintenance projects are:

Schedule Deviation

Effort Deviation

Mean Schedule performance

Defect density for enhancement

Post Delivery Defect rate and

Overall Productivity

The common metrics for service projects are:

Service not on time index

Service Rejection Index

Defect Removal Efficiency

Backlog Management Index

The service specific metrics are as follows:

Code and Unit Testing

CUT Productivity

Review Effort expressed as a percentage

Code error rate

Analysis and Consultancy

Productivity

Review Effort expressed as a percentage

Analysis Error rate

Testing

Testing execution Productivity

Test Case Coverage

Maintenance Request/Service Request/Defect Rejection Ratio

Maintenance Request/Service Request/Defect slippage Ratio

Design Service

Review Effort expressed as a percentage

Design Error rate

Productivity

The metrics for testing projects are as follows:

Schedule Deviation

Effort Deviation

Test case Design/Development

Manual Test Case Development Productivity

Automation Test Script Development Productivity

Requirements coverage

Test Execution

Manual Test Case Execution Productivity

Automation Test Case Execution Productivity

Test Case Coverage

Test Case Efficiency

Defect Rejection Ratio

Defect Slippage Ratio

Defect Detection Rate

Test Automation

Automation Percentage

Return on investment on Automation

Cost of Quality Metrics

Appraisal cost

Preventive costs

Internal Failure cost

External failure cost

Performance cost

Cost of quality

Cost of poor quality
Project Management Process Planning Main and Sub-Process Goals
The main process performance goals for a project are derived from the project shared vision, the
Customer Critical to Quality needs, the business objectives, organizations process performance
baselines and the process performance models.

In order to achieve the main process performance goals, sub-process goals are derived. The steps to
identify sub-process goals are

Identify the factors that need to be improved to achieve the main process goal. Refer the process
performance model for this.

Identify the metrics that are used to measure the above factors. These form the sub-process goals

Set the project norms for these metrics.

Then arrive at an action plan for achieving sub-process objectives. These action plans should be
continuously monitored through out the project. If any deviations in sub-process goals are observed,
corrective and preventive actions should be implemented.

Let us see the following examples to understand main and sub-process goals.

Example 1:

The main goal of the project is to improve the productivity by 10 %. In order to achieve this, the sub
process goals are identified as

1. Increase re-use

2. Increase tools usage and

3. Reduce rework effort

The project norms for these metrics are set. Reuse % - 10%, At least 15% tools generated code, and
reduction in rework effort to 10%.

The action plan to increase reuse would be

Identify more re-usable components from Knet and

Make the design to enhance re-use.

In order to increase tool usage, identify and use tools for code generation.

To reduce the rework effort, the reviews in Requirement Specifications and Design phases are to be
strengthened. Look Ahead Meeting in design and CUT phases should be conducted and daily build
mechanisms should be implemented. The rework effort could also be reduced if scripts are written for
automating tasks such as code generation, test data setup, etc.
The main process performance goals for a project are derived from the project shared vision, the
Customer Critical to Quality needs, the business objectives, organizations process performance
baselines and the process performance models.

In order to achieve the main process performance goals, sub-process goals are derived. The steps to
identify sub-process goals are

Identify the factors that need to be improved to achieve the main process goal. Refer the process
performance model for this.

Identify the metrics that are used to measure the above factors. These form the sub-process goals

Set the project norms for these metrics.

Then arrive at an action plan for achieving sub-process objectives. These action plans should be
continuously monitored through out the project. If any deviations in sub-process goals are observed,
corrective and preventive actions should be implemented.

Let us see the following examples to understand main and sub-process goals.

Example 1:

The main goal of the project is to improve the productivity by 10 %. In order to achieve this, the sub
process goals are identified as

1. Increase re-use

2. Increase tools usage and

3. Reduce rework effort

The project norms for these metrics are set. Reuse % - 10%, At least 15% tools generated code, and
reduction in rework effort to 10%.

The action plan to increase reuse would be

Identify more re-usable components from Knet and

Make the design to enhance re-use.

In order to increase tool usage, identify and use tools for code generation.

To reduce the rework effort, the reviews in Requirement Specifications and Design phases are to be
strengthened. Look Ahead Meeting in design and CUT phases should be conducted and daily build
mechanisms should be implemented. The rework effort could also be reduced if scripts are written for
automating tasks such as code generation, test data setup, etc.

Here is another example where

The main goal of the project is to keep the post delivery defect rate less than 0.1 defects per Kilo Lines
Of Code.

The sub process goals identified are:

1. Improve test case efficiency,

2. Increase code coverage, and

3. Increase Unit Test Case Density

To achieve the first sub process goal and adhering to the norms of keeping the test case efficiency
greater than 20 percent, the action plan would be to increase test cycles till the target test case
efficiency is achieved.

The strategy used to facilitate increased code coverage is to develop additional test cases to increase
code coverage while testing and use Orthogonal Arrays for test case development.

In order to increase unit test case density to at least 1 unit test case for 30 kilo lines of code, increase
the number of test cases to enhance coverage of paths in the program code.



Project Management Process Risk Management
Let us now understand an important aspect of project management, Risk Management.

Risk management involves:

Risk Identification

Risk Quantification

Response Development

Risk Monitoring

Risk Identification

During project planning, project execution risks are identified. The risk identification checklist, past
project data, risks identified at proposal stage and discussions or brainstorming sessions with
stakeholders help the project manager to identify new risks. The new risks identified should be logged in
the risks & issue tracker.

Risk Quantification

For each of the risks, the probability of occurrence and impact of the risk on Cost, Schedule,
performance and safety aspects, are assessed. The probability of occurrence and impact are quantified.

The probability of risk is quantified as: High (9), Medium (3) and Low (1). Impact is quantified as High (9),
Medium (3) and Low (1).

The Failure Mode Effect Analysis or FMEA tool is recommended for this activity.

The probability of occurrence score multiplied by impact score gives the risk score. It could be a
minimum of 1 and maximum of 81.

Risk Response Development

The next step is to develop mitigation and contingency plans. Mitigation plans are the actions to be
taken to minimize the occurrence of risk and contingency plan are the actions to be taken when risk
becomes a reality.

Mitigation & Contingency plans are mandatory for risks where the risk score is greater than or equal to
27.

All the identified risks and action plans should be recorded in the risk management plan. The risks
should be communicated to the customers and the affected groups.

Risk Monitoring

The action items from the risk management plan should be tracked and implemented by their due date.

Risks should be continuously monitored and re-assessed by way of Project Monitoring Reviews,
Milestone reviews and Look Ahead Meetings.

For all fixed price projects, a Sum of risk scores should be arrived. At any point of time, if the risk score
at a project level exceeds 162 then the risk management plan should be reviewed by the Solution
Delivery Head.
Project Management Process Defect Prevention Activities
Defect prevention activities are carried out to prevent the occurrence of defects.

These activities aimed at:

Preventing defects those have occurred in past projects in repeating in the current project.

Preventing defects those have occurred in the current project, repeating in the future.

The quality co-ordinator and the project manager are responsible for all defect prevention activities for
the project. The defect prevention activities are:

Look Ahead Meetings (LAM)

Root Cause Analysis (RCA)

For small projects, Look Ahead Meetings should be planned as per project needs. For large projects,
Look Ahead Meetings are to be conducted at the beginning of a phase. The topics that are discussed in
Look Ahead Meetings are:

1. Adoption of tools and best practices from other projects.

2. Prevention of common defects. These are done by classifying & prioritizing by using Pareto analysis
and arriving at corrective and preventive action plans.

3. Issues or concerns of the previous projects or phases.

Root Cause Analysis is conducted to identify the root cause of problems and devise corrective actions.

The triggers for conducting root cause analysis are identified and documented in the Defect Prevention
Plan. These triggers could be:

Deviation in project metrics

Customer complaints

process non-conformances identified in audits and assessments.

The Pareto analysis and fish bone diagram techniques are recommended for conducting Root cause
analysis.

Once the root causes of a problem are identified, corrective and preventive action plans should be
devised. The action plans are documented in defect prevention reports. Tangible actions that need to be
taken in subsequent phases should be discussed in look ahead meetings".

The effectiveness of these actions should be tracked in project monitoring reviews.
Project Management Process Configuration Management
Configuration Management

Configuration Management process involves:

Identifying and acquiring configuration items.

Managing baselines by controlling changes.

Configuration status accounting through configuration audits.

The plan for configuration management activities is recorded in the Configuration Management or CM
plan.

Acquiring configuration items & creating baselines:

All configuration items are identified. An item that impacts the deliverables or an item, whose changes
need to be controlled, is a configuration item or CI. Examples of Configuration Items are requirements
specification, design documents, project plan, source code, standards, customized checklists, customer
supplied items, etc.

Appropriate configuration management tools are identified.

The phases at which the baselines are created are identified.

The base-lined Configuration Items along with version number are recorded in Baseline Record (BR).

The plan for back-up and disaster recovery of Configuration Items should be documented in the
Configuration Management plan.

Controlling changes

Changes to baselined items should be subjected to change control process.

A change control board or CCB involving senior team members and customer should be setup. Changes
should be recorded as change requests or CRs with unique Ids.

The change control board should evaluate the change requests and assess its impact on schedule, effort
and risk. Changes that impact the schedule and effort should be approved by the customer. Changes
that do not impact the schedule/effort can be approved by Project Manager.

Once the change is approved, a plan for making the changes should be drawn and implemented
accordingly. The details of all change requests should be recorded in the change control register (CCR).

Configuration Audits

Regular Configuration audits are to be performed by the Quality coordinator. The findings should be
recorded in the Software Configuration Audit Report (SCAR) and tracked to closure.

The outputs of configuration management process are the configuration management plan (CM Plan),
Baseline Record (BR), Change Control Register (CCR), Project Plan and the Software Configuration Audit
Report (SCAR).
Project Management Process Document Control
Document Control Process

Project Documents, Project Quality Records and Customer or Third Party supplied documents are
subject to the Document Control Process.

The Project Manager should identify and classify all project documents as public, internally restricted,
confidential and very confidential.

For adhering to this procedure, provide a unique document identified for all project documents.
Document identifier should be of the following format:

<project code>/AAA-BBB.XX.YY

Where AAA is document type,

BBB optional field, and

XX.YY is version number.

Please maintain a master list of documents and follow version control mechanism for changes to project
documents.

Click each to know more.

Document Version Control of documents is maintained in following way:

A document initially prepared is considered as a draft.

On review, it is versioned and the version number is incremented until it is approved. It then becomes
an Approved Document.

When a significant change is made to the document, it is treated as a version change. When a minor
change is made, it is considered a revision change. For example, consider a document whose current
version is 1.05. When a major change is made, the version is changed to 2.00. If a minor change is made,
the version is incremented to 1.06.

Master List of Documents

All documents used in the project must be included in the master list of documents. Every revision of a
document must be updated in the master list of documents. The master list of documents should be
used to identify the latest version of a document.

Document Classification

Public Non-sensitive information available for external release. Example press note.

Internally Restricted Information available to employees, contractors and trainees. Example Test
plan.

Confidential Information that is sensitive within the company and available only to a group of people.
Example Project Plan.

Very Confidential Extremely sensitive information and available only to a few named personnel.
Example Team member appraisal.
Project Management Process Disaster Recovery
The foremost step in a Disaster Recovery Process is detecting critical IT systems for the project.

The disaster recovery process gives rise to a comprehensive statement of consistent actions to be taken
before, during and after a disaster which is the Disaster Recovery Plan

The next step would be to classify the level of disaster that is, whether it is an asset level failure, site
level failure or a city level failure.

Based on the level of the disaster, identify teams for disaster recovery such as Crisis Management Team,
System Recovery Team and Restoration team.

Then, develop recovery strategies for each level of failure and document in disaster recovery plan.

Share the disaster recovery plan with the disaster recovery teams.

Test the disaster recovery plan through mock disasters.

Click on each to know more.

Asset Level Failure

Any disruption to the project due to failure of any individual IT system or asset.

Site Level Failure

Non-availability of the location in which the project is running.

City Level Failure

Non-availability of the city in which the project has been running.

Crisis Management Team

In case of a disaster they do an initial assessment of the damage, declare a disaster and notify the
concerned stakeholders.

System Recovery Team

Initiates restoration activities at recovery site. This includes set up of project servers, communication
link and re-installation of data from back-ups.

Restoration Team

Determines what is salvageable from the disaster site with the help of central support teams. They also
help in determining if the project can continue at the same site.
Project Management Process System Administration
System Administration Activities

The typical system administration activities that are to be carried out in a project are:

User account management

Security related activities

Capacity planning and change management

Housekeeping activities

Back up

Other activities

As a part of User Account Management you must:

Create unique IDs for new users in the project.

Ensure project user ID is the same as Wipro user ID.

Have fixed login attempts for users before the account gets locked and

Delete project user ID when the user moves to another project or resigns.

As a part of security related activities.

Define security practices for the project.

Follow client defined practices. Where there are no specific client specified practices, follow Wipros
Information Security Management System policies.

Keep system passwords in a safe place in a sealed envelope.

Enable idle time-out for the system.

Ensure that privileged accounts should be accessed by authorized persons only.

Obtain client approval for remote dial up connectivity to Offshore Development Center and

Monitor system logs.

For doing Capacity Planning and Change Management, monitor system performance for capacity
planning, maintain configuration details for all system resources, record system/software changes
before and after an upgrade and plan and review Operating system upgradations adequately before
implementation.

Housekeeping activities have to be undertaken regularly as part of the system administration activities.
Expired system environments or folders should either be reused or deleted.

Temporary files, log files should be deleted regularly for better utilization of disk space. And
communicate maximum storage space to all users.

Back-ups

Taking back-ups is an important system administration activity. Identify Critical files for back up.
Determine the type of back up (full, incremental, differential) and periodicity for back up. All back up
media should be labeled and stored in a safe place. A back up and restoration log should be maintained.

Other activities that are a part of system administration include: protecting all servers with latest anti-
virus scan engines, ensuring availability of the latest signature files information on the central server and
logging incidents related to security breaches in Security Incidents Reporting link in TEDWEB.
Project Management Process Tailoring Process
Process Tailoring

veloci-Q has an approved set of life cycles, procedures, guidelines, templates and checklists that are
aimed to cater to the needs of different types of projects in the organization.

However, these processes may need to be modified in order to suit the project needs. Also some
processes may need to be customized to meet project needs. This practice of adapting the approved
processes for project scenario is known as process tailoring.

A need for process tailoring may arise due these reasons.

The defined processes are not adequate to meet the project needs.

The defined process may be too elaborate for the size and duration of the project.

The project may need to follow some client processes. The veloci-Q processes may need to be adapted
to suit them.

The following points need to be considered while tailoring:

The requirements of the new process.

The adequacy of the process to meet the project needs.

The definition of Entry Criteria, Tasks to be performed, Validation mechanism and Exit Criteria for each
phase or activity of the new process.

Impact of tailoring on organizational quality requirements.

It is imperative that the project specific tailoring be documented in the project plan. The project should
follow the tailored procedures. Any deviations from the tailored processes will be considered as a non-
conformance.

It may be required that some process changes are required at a group or an account level. Then group or
account level tailoring is done.

All the projects in the group or account should follow the tailored processes. The group or account level
tailoring should not be repeated in the individual project plans.
Project Management Process Planning Tool Usage
The usage of tools brings in multiple benefits to the project in terms improved productivity and reduced
defects.

The tools to be used in the various phases of the project are to be identified in the project planning
stage.

As an indicator of the tools usage in the project, the tools usage index is computed. The tools usage
index helps in tracking tools usage through out the project. The Tools Usage Index is reviewed on a
monthly basis in project status reports.

Various factors like scope of tools usage, applicability of tools, planned tools and actual tools used are
considered for computing the Tools Usage Index.

The tools are grouped into the following categories Requirements Management, Design, Configuration
Management, Performance Testing, Static Analyzers, Unit Testing, Integration and System Testing, Code
Generation and other project specific tools.

Weightages are assigned to each category as shown in this table.
Let us learn more about the Tools Usage Index. TUI is based on scope and applicability of various phases
of the project. Therefore normalized planned TUI is the ratio of planned TUI over scope of TUI

The planned tools usage index is the sum of weightage values of those categories where "Planned" is Y.

The Scope of tools usage index is the sum of weightage values of those categories where "Applicable" is
Y.

Consider this sample tools plan for a development project. The total weightage here is 100. The Scope of
Tools Usage (S) is equal to 100 and Planned Tools Usage Index is 100. Thus, the Normalized planned TUI
would be equal to 1 that is 100 percent.

Project Management Process Planning Tools Plan
Let us look at the tools plan section of the project plan.

The first column is the category of tools.

The second column is, Applicability. It is marked with "Yes" if the category of tools is applicable for the
project and "No" otherwise.

The third column is Planned Usage. It is marked with "Yes" if a tool has been planned to be used under
the category and "No" otherwise.

The tools that are planned in the category are listed in the "Tools Planned" column.

The rationale for selecting the tool to be used is noted in the "Rationale for the method/tools used"
column.

In the sixth column, the date by which the tools are required, is filled.

In the last column the remarks or the justification for not choosing tools in the category is filled in.

Note:
The commercial aspects of the tools listed in the tools plan should be taken care of.
Project Management Process Planning Actual TUI An ideal case
Let us now see how the actual TUI is computed with an example.

Consider a project is currently in DESIGN phase. The tools Plan for this project is as shown in this table.

In the PDMR, the 'actually used' column is updated as 'yes' if the planned tools have actually been used
in the project. For the phases that are yet to start, the 'actually used' cell is not applicable at this point of
time and hence this is updated with 'phase yet to start

In this project, the Scope for TUI = 80

The normalized planned TUI = [Sum of Planned column ( where planned = Y & actually used ! = phase
yet to start) ] / [ SCOPE ] = [ Sum of weightages of RM + Design + SCM ] / [SCOPE ] = [10+20+5] / [80] =
43.75

Normalized actual TUI = [ Sum of actual column where actually used = Y ] / [ SCOPE] = [ Sum of
weightages of RM + Design + SCM ] / [SCOPE] = [10+20+5] / [80] = 43.75

Since, till the design phase, all the planned tools have been used in the project, the Normalized Planned
TUI is equal to Normalized Actual TUI.

Project Management Process Planning Actual TUI A Defaulter
Let us look at an example where the Actual TUI is not equal to the Planned TUI. The current phase of the
project is CUT.

For this project Scope for TUI = 80

Normalized planned TUI = [ Sum of Planned column ( where planned equal to Y & actually used not
equal to phase yet to start) ] / [ SCOPE ] = [10+20+5+5+15+20] / [80] = 93.75

Normalized actual TUI = [ Sum of actual column where actually used = Y ] / [ SCOPE] = [10+20+5+10] /
[80] = 56.25

Here we find, For Static Analyzer category, tools are planned but not actually used as per the plan.
Similarly for unit testing and code generation tools categories.

In case of IT / ST category, applicable and planned is N but actually used is Y. That is tools usage is
not planned but actually used in the project.

Due these discrepancies, the normalized actual TUI is much less than normalized planned TUI. The
project manager must analyze this and take corrective actions.

NOTE:

The tools usage index is computed at account, domain and Wipro Technologies level. Lower actual TUI
of a project affects the TUI of these levels.
Project Management Process Planning Project Plan Example

Project Management Process Revisions to Project Plan
The draft project plan should be reviewed by SQA manager and approved by the technical manager. The
approved project plan should be base-lined. The base-lined project plan should be revised when

There are changes to project scope.

Change requests that impact the deliverables, effort, cost or schedule, are to be implemented.

There are process changes due to internal audits and assessments.

Changes due to veloci-Q releases.

Revisions to organization norms.

Changes to the plan due to Root Cause Analysis findings.

Through all the revisions, the Project Plan document should be version controlled. It is mandatory to
maintain all the versions.

Please bear in mind that the revisions impacting effort, schedule, cost and deliverables should be
approved by the customer.

For FPP projects

In case of any revisions to the Development and Quality Process Plan, the Defect Prevention Plan, the
Metrics Plan, Project Specific Tailoring or the schedule and efforts plan,the project plan should be
reviewed by the Software Quality Assurance Manager and approved by the Technical Manager.
Project Management Process Planning Development & Conversion projects Overview
Having understood the generic project planning processes, let us understand how project planning is
done for different types of projects.

Development and Conversion Projects

The following activities are to be carried out when planning for development or conversion projects:

Identify best practices, past project learnings and reusable components from knowledge repository.

Identify the appropriate tools & methodologies to be used.

Revisit the estimates prepared during the pre-engagement stage.

Revisit the risks identified during the pre-engagement stage and update the risk management plan if
any new risks are identified.

Document the stakeholders information in the communication management plan.

Prepare the overall schedule using MS-Project. If a project activity is outsourced, then include
Vendor/Supplier schedules.

Update training planner and tracker with the training needs for each member of the team.

Identify the disaster recovery plan and document the same.

Update decision tracker with key decisions and the rationale behind them.

Prepare the project plan. The project plan should be reviewed by SQA manager and approved by
technical manager.

Apart from these activities, there are additional activities to be carried out in case of large development
or conversion projects. They are:

Derive the project shared vision based on the organization shared vision and the project objectives.

Define the project team structure with their roles and responsibilities. The team should include:

Leads from the individual practices, if multiple technologies are involved.

An architect

A design team with designers

A quality co-ordinator

An independent testing team

Conduct a project kick-off meeting involving the key stakeholders and the project team. The project
shared vision, projects goals & objectives and the team charter should be discussed.

Based on the project shared vision and customer critical to quality parameters, main and sub-process
goals should be derived. The norms and action plans to achieve the sub-process goals and consequently
the main process goals should be arrived at.

A table review should be conducted to review the project plan.
Project Management Process Release Based Maintenance Projects Overview
The planning for maintenance projects are typically done during the parallel perform phase of
knowledge transition. The following activities are to be carried out -

Identify the team structure with their roles and responsibilities for steady state.

Conduct a project kick-off meeting involving the project stakeholders. The project vision, goals and
objectives and team charter should be shared.

Prepare the maintenance plan and execution process document (EPD) for the project.

The maintenance plan is used for internal tracking and monitoring. It includes Resource plan,
metrics, defect prevention plan and project specific tailoring.

Identify best practices, past project learnings and reusable components from knowledge repository.

Identify project risks and update the risk management plan.

Document the stakeholders information in the communication management plan.

Identify the disaster recovery plan and document the same.

Update decision tracker with key decisions and the rationale behind them.

Document the approach for handling enhancements to the application. Enhancements less than 3
person months of effort can be treated as a maintenance request. Enhancements that exceed 3 person
months of effort must follow the development life cycle.

The maintenance plan should be reviewed by SQA Manager and approved by technical manager.

At the beginning of a release cycle, the maintenance release plan should be prepared. It should include
release specific details such as enhancements, bug fixes planned for the release, schedules, release level
metrics and release level risk plan. A look ahead meeting should be conducted before kick-starting the
release.
Project Management Process Service Projects Overview
The planning for service projects are usually starts during the parallel perform phase of knowledge
transition. The following activities are to be carried out:

Identify the team structure with their roles and responsibilities for steady state.

Identify the different types of services that would be rendered and the activities to be performed for
the service type. Refer the service guidelines in veloci-Q for the comprehensive list of service types and
the typical activities performed for each service type.

If the service to be provided does not fit into any of the pre-defined types then:

1. Identify the new service type.

2. Identify the activities for the new service type.

3. Identify the new service type and the typical activities performed under the new service type. Clearly
define the metrics that would captured for the requests of this type.

Identify best practices, past project learnings and reusable components from knowledge repository.

Identify project risks and update the risk management plan.

Document the stakeholders information in the communication management plan.

Identify the disaster recovery plan and document the same.

Obtain consultation from tools group regarding the tools planned to be used in the project.

Update decision tracker with key decisions and the rationale behind them.

Prepare the service plan and execution process document (EPD) for the project.

The service plan is used for internal tracking and monitoring. It includes Resource plan, metrics, tools
plan, training plan, defect prevention plan and project specific tailoring.

The service plan should be reviewed by SQA Manager and approved by technical manager.
Project Management Process Production Support Projects Overview
The planning for production support projects usually starts during the parallel perform phase of
knowledge transition. The following activities are to be carried out:

Identify the team structure with their roles and responsibilities for steady state.

Identify the different types of services that are in scope.

Identify best practices, past project learnings and reusable components from knowledge repository.

Identify project risks and update the risk management plan.

Document the stakeholders information in the communication management plan.

Identify the disaster recovery plan and document the same.

Obtain consultation from Tools group regarding the tools planned to be used in the project.

Update decision tracker with key decisions and the rationale behind them.

Prepare the production support project plan and execution process document (EPD) for the project.

The production support project plan is used for internal tracking and monitoring. It includes
Resource plan, tools plan, training plan, metrics, defect prevention plan and project specific tailoring.

The Execution Process Document covers aspects that are of interest to Wipro as well as the customer.
It covers:

Definitions of the services that are in scope.

Project organization, communication process, program governance should be described in the EPD.

The detailed work flow for each type of activity like incident, hot fix and enhancements. The work
flow should typically include end to end implementation from receipt till delivery, implementation
environment, review and testing process, release processes and client acceptance processes.

Criteria for enhancements in scope of the Production Support engagement should be established.

Configuration management plan and Build process.

SLA as per the contract.

Status reporting for customer.

Commitment being made towards the process improvement should be described.

The production support project plan should be reviewed by SQA Manager and approved by technical
manager.

A customer sign-off should be obtained on the Execution Process Document(EPD).
Project Management Process Monitoring and Control Metrics Collection
In the project planning module we saw how the metrics are defined for the project. During the course of
the project, raw data needs to be captured for computing these metrics.

The basic data that needs to be collected for development and conversion projects are

-Schedule

-Effort

-Defects and their classification and

-Product size

For maintenance, production support and service projects, the basic data to be collected are

-Requests serviced

-Not-on-time requests

-Rejected requests and

-Effort

For testing projects, the basic data to be collected are

-Test Cases written

-Passed test cases

-Failed test cases

Once the project plan is approved, the project manager assigns tasks to the team based on the project
plan. Each task should have a planned start date, planned end date and the planned effort. The team
should capture the actual start date, actual end date and actual efforts for the tasks assigned to them.

Similarly, the project manager should also plan for reviews and identify the review team. For reviews,
the review team should capture the review start date, completion date, review effort, defects identified
and their classification and verification efforts.

Post review, rework effort should be captured, by the team. The above data captured forms the basis
for metrics analysis and project monitoring.

Statistical Tools like control charts, hypothesis testing and trend analysis aid in metrics analysis. The
guidelines for usage of these tools are available in veloci-Q.

When any of the actual metrics deviates significantly with respect to the project norms, a root cause
analysis should be conducted. Corrective and preventive actions should be taken to enable project to
perform within norms.
Project Management Process Monitoring and Control Metrics Reporting Development Projects
The project data collected by means of work plans, review records, test reports, defect tracking tools,
etc. is consolidated and reported on a monthly basis in Project Data and Metrics Report and Project
Monitoring Report.

Let us understand the different sections of the Project Data and Metrics Report for a development
project.

Overall Schedule Table

This section consists of

Original planned schedule - Start Date and end date for each phase as per original project plan.

Revised planned schedule - Start Date and End date for each phase as per latest project plan.

Note that the schedule can be revised only if prior customer approval has been obtained

Projected End Date - Date by when the phase is expected to be completed. For a phase that is ongoing
or yet to start, this information is to be determined by PM and entered. For completed phases, it is the
same as actual end date.

Actual Schedule - The Actual start and end dates of a phase are entered.

Schedule deviation

(i) With respect to original plan - Difference between projected end date and original end date
multiplied by 100 divided by original schedule

(ii) With respect to revised plan - Difference between projected end date and revised end date
multiplied by 100 divided by revised schedule

Reasons for performing above or below norms - If the schedule deviation with respect to revised plan is
above or below the project norms, then the reasons for the same should be documented.
Project Management Process Monitoring and Control PDMR for Development Projects
Overall Effort Table This section consists of Actual Team Size - The peak onsite and offshore team size
for the phase is entered here.

Original planned effort - Original Planned effort for onsite and offshore in person hours.

Revised planned effort - Planned effort for onsite and offshore in person hours, as per the latest version
of project plan.

Note that project effort can be revised only if prior customer approval has been obtained

Projected Effort - The effort that is required to complete the phase. For a phase that is ongoing or yet to
start, this information is to be determined by PM and entered. For completed phases, it is 0.

POC - Percentage of completion - This indicates how much has the phase been completed.

Actual Effort - Effort that has been expended at onsite and offshore expressed in person hours. This
does not include change requests and review efforts.

Actual Extra Effort due to requirement changes - Additional effort due to changes in requirements that is
change requests effort.

For a table review process the total review effort for a review cycle can be distinguished as review
preparation effort and review effort. Review preparation effort includes effort for going through the
documents and listing out individual findings prior to a table review.

The effort spent in review discussions and error finalization during the table review process is logged as
review effort. Phases like Design and Requirements mandate the table reviews. The ratio of review
preparation effort to the total effort is monitored in these phases to assess effectiveness of reviews. For
Peer reviews the entire effort is captured as review effort.

Rework Effort - Effort spent in fixing review errors.

Total Effort - Sum of actual effort, effort due to requirements changes, review effort and rework efforts.

Rework percent - Ratio of rework effort to total effort expressed as a percent

Effort Deviation

With respect to original plan -

This is calculated as - (Projected effort + Actual total effort) - original effort multiplied by 100 divided by
original effort

With respected to revised plan -

This is calculated as - (Projected effort + Actual total effort) - revised effort multiplied by 100 divided by
revised effort

Reasons for performing above or below norms - If the effort deviation with respect to revised plan is
above or below the project norms then the reasons for the same should be documented.
Project Management Process Monitoring and Control PDMR for Development Projects - Reviews
and Testing
Reviews

The document reviews and code review sections of the Project Data and Metrics Reports are used to
report review data. It includes -

Size - Number of pages in case of documents and code size for code. Code size should be expressed in
the relevant unit of measurement such as lines of code or function points, data warehousing units, EAI
units, etc.

-Review team size

-Total Preparation Effort - Effort spent in preparation for reviews.

-Total Review effort - Effort for conducting the review.

-Ratio of preparation effort to review effort - Total preparation effort divided by Review effort

-Number of Defects in each severity category - Fatal, Major and Minor.

-Number of defects in each type category of defects.

-Total number of errors

-Review rate - Document or Code size reviewed divided by review effort

Rework Effort - This includes effort for fixing of defects and verification effort by reviewer.

Testing

For each type of testing carried out in the project, the following details are to be documented -

Total number of test cases designed,

Number of test cases generated by tools,

Number of test cases executed by tool,

Total number of test cases executed,

Number of test cases successful in finding errors,

Test case efficiency - Number of test cases successful in finding errors divided by total number of test
cases executed multiplied by 100.

Code coverage - percent of code covered during testing

Error or Defect distribution matrix - Summarizes the defects captured in each phase of the project. It
includes review as well as testing defects.

Phase containment is calculated as errors found in the phase * 100 / (Errors found in the phase + the
phase defects found in the subsequent phases).
Project Management Process Monitoring and Control PDMR for Development Projects - Other
Sections
Tools Usage: The actual tools used in the project are reported in this section. Based on this the actual
Tools Usage Index is calculated.

Process Performance Metrics

For each of the sub-process objectives, the actual performance is reported. The performance of the sub-
process objectives should be monitored to ensure that the main process objectives do not deviate from
the goals. To ensure this the sub-process objectives should be monitored frequently and intermittently.
In case of deviations, they should be brought back under control so as to not impact the main process
objectives.

KNET usage

The artifacts that the team has used from KNET and the contributions made to KNET are recorded in
these sections.

Trainings attended

Details of trainings attended by the team are reported here. This includes mandatory trainings and
internal project trainings.

Defect Prevention Activities

The actual defect prevention activities carried out are reported in this section. These could be Look
Ahead Meetings, audits and Root Cause Analysis reports.

Risk Tracking

The action plan from the risk management plan is tracked against the planned implementation date. The
actual date implemented is also reported.

Size Tracking

This is an important section for reporting Code and Unit Testing productivity. The manually generated
and tool generated code for each language is reported in this section. In case of enhancements to the
existing code, the number of units of code added, modified, deleted and reused is entered. The effort
for code developed is also reported.

Requirements Management

This section indicates the stability of requirements in the project. For each phase, the following details
are reported:

Initial number of requirements, Number of requirements that were added, modified and deleted, the
estimated effort for implementing the changes, Actual effort spent in implementing the changes,
Requirements volatility is calculated as ratio of changed number of requirements to original number of
requirements multiplied by 100.
Project Management Process Monitoring and Control Revenue Recognition
Revenue Recognition is a very important process for Fixed Price engagements and is the basis for
financial accounting. This is done based on percentage of completion of the project. The actual effort
consumed until now as a percentage of the overall efforts (Actual consumed + Projected effort)
represents Percentage of Completion. While the project is in progress the Project Manager should
estimate the Projected Effort as the Balance to Go effort to calculate Percentage of Completion.

Revenue Recognized is calculated as Contract Value multiplied by Effort expended multiplied by 100
divided by [Effort expended + Balance effort to go + contingency]. Since the percentage of completion is
used as a basis for revenue recognition, projections for the Balance to Go efforts are to be computed
separately for offshore and onsite.

The contingency percentage on balance is same as that taken during estimation.

As the project progresses the contingency efforts drop based on the project completion percentage. This
means that if the 10 percent contingency effort in a project works out to be 40 person weeks, this
contingency effort will not remain as 40 person weeks until project completion. The contingency effort
will have to be calculated as a percentage of the balance to go effort.
Project Management Process Monitoring and Control PDMR
Let us understand the different sections of the Project Data and Metrics Report for a maintenance
project.

SLA based resolution or Response time norms - The response time and resolution time norms and
compliance percentage required for these service level agreements are listed for reference Application
Dashboard.

For each category of bugs, the following data for the current month as well as the cumulative data from
start of project till date is reported.

-Average Response Time

-Average Resolution Time

-Number of Maintenance Requests Received

-Number of Maintenance Requests Resolved

-Number of open Maintenance Requests

-Number of Maintenance Requests Resolved with Code Fix

-Backlog Management Index (percentage) - This is calculated as ratio of number of requests delivered
during the month to the number of requests received during the month expressed as percent

-Average Open Age of maintenance requests (Days)

-Not-On-Time Index - This is calculated as number of requests not delivered on time multiplied by 100
divided by total number of requests delivered.

-Percentage of compliance to resolution time SLA - This is calculated as number of bugs that are
resolved within the resolution time SLA multiplied by 100 divided by total number of bugs resolved.

-Percentage of compliance to response time SLA - This is calculated as number of bugs that are
responded to within the response time SLA multiplied by 100 divided by total number of bugs received.

-Average Schedule Deviation with respect to norms in resolving Bugs i.e.(percentage)

-Number of maintenance requests Rejected in Internal QA Cycle - The number of requests that have
failed in regression testing is reported here.

-Number of maintenance requests rejected by Customer

-Effort spent in resolving maintenance requests with Code Fix (Person hours)

-Total Effort spent in maintenance request resolution (Person hours)

-Mean Time to Fix - Actual effort divided by number of maintenance requests resolved

-Overall Bug Fix Productivity - This is calculated as number of bugs resolved with Code Fix divided by
Effort spent in resolving bugs with Code Fix

-Overall Sustenance Productivity - This is calculated as number of bugs Resolved divided by effort spent
in resolving the bugs
Project Management Process Monitoring and Control PDMR for Maintenance Projects Release
Release

Data related to releases are reported in this section.

Release Data

Release Number - Release identifier

Accepted - Whether the release has been accepted by customer.

Release Effort - Total effort spent for the release.

Planned release date

Actual Release Date

Schedule Deviation percentage

Backlog Management

For each category of bugs, enter the number of backlog maintenance requests before and after the
release.

Regression testing effort and schedule- The planned and actual schedule and effort for regression
testing for each release is reported here. Schedule deviation and effort deviation are computed.

Regression testing details

Total number of test cases existing

Total number of test cases added or modified

Total number of test cases executed manually

Total number of test cases executed using tools

Total number of test cases that were successful in finding defects

Test case efficiency - Test case efficiency is calculated as "Number of test cases successful in finding
errors divided by total number of test cases executed multiplied by 100

Test set up efforts

Test execution efforts

Test analysis efforts

Testing productivity - Testing productivity is calculated as total number of test cases executed divided by
total effort spent for executing the test cases
Percentage of code covered
Defect classification table

Classification of test defects into fatal, major and minor is reported.
Project Management Process Monitoring and Control PDMR for Maintenance Projects
Enhancements
Enhancements

Data related to enhancement requests are reported in this section.

Schedule and Effort Table - The details to be captured in this table are similar to the schedule and effort
table of development PROJECT DATA AND METRICS REPORT.

Percentage enhancements delivered on time - This is reported for current month, previous months and
cumulative till date.

Size and defect tracking table - The details to be captured in this table are similar to the size and defect
tracking sections of development PROJECT DATA AND METRICS REPORT.
Project Management Process Monitoring and Control Project Monitoring Reviews
The progress of the project is monitored at the project level and account level.

Monitoring at Project level

The project manager monitors the progress of the project by means of project monitoring reviews.

These review meetings should be conducted

-On a weekly basis using the weekly status reports.

-On a monthly basis using the Project Data and Metrics Report and Project Monitoring Report.
Weekly Status Review Meeting

The weekly status review meeting should be conducted with the team. The activities carried out in the
week and the plan for next week should be discussed. The Quality Coordinator should present review
and testing data analysis for the week. The team should look for early warning signals and take suitable
corrective actions.

Monthly Project Monitoring Review Meeting

The project manager discusses the project progress with the technical manager in the monthly project
monitoring review meeting. The Project Data and Metrics Report and Project Monitoring Report aid this
discussion

-Project progress against planned schedule, effort and cost.

-Status of pending change requests, if any from customer on project requirements.

-Completion of Phase or milestone or requests for the month

-Requirement of Resources i.e. (HW/SW, Equipment, Personnel, Lab, Others.)

-Status against planned work product reviews, Defect Prevention activities, and Configuration
Management activities.

-Status on Metrics and Quality goals and performance against norms.

-Review of the action taken on customer complaints, non-conformance reports, audit and assessment
findings.

-Review status of planned tools usage against actual usage in the project and future plan.

-Status on projects specific and mandatory training's of team members.

-Critical or Outstanding issues to be addressed by customer for ensuring effective execution of the
project.

-The status of previous Project Monitoring Reports action items and the efficacy of preventive and
corrective actions.

-Relevant issues or concerns ought to be highlighted to the senior management.

Another important aspect of the Project Monitoring Report review is the review of risk plan.

The actual implementation of action items should be reviewed.

All the risks should be reassessed and the plan should be updated with the new impact and probability
scores.

Any additional risks foreseen, along with their mitigation and contingency plans should be included in
the risk plan.

The action items arising out of the project monitoring review meetings must be documented and
tracked to closure. If required, the project plan should be revised.



Project Management Process Monitoring and Control Project Monitoring - Account Level
Monitoring - Account Level

The Project Data and Metrics Reports of all projects in the account and the Project Data and Metrics
Reports of all projects in the account provide inputs for generating the Account Status Report or ASR.
The Account Status Report is reviewed with senior management.

The discussion points include

-Projects deviating from norm

-Issues or Risks not resolved at project level

-Customer Complaints and Commendations

-Project specific customer feedback

The action items arising from the ASR review could be at the individual project level or at the account
level. The technical manager should document these action items and tracked them to closure.
Project Management Process Monitoring and Control PM Transition
During the course of the project there could be change of project manager due to resignation or internal
rotation. In such a case the technical manager should identify a new project manager for the project.
The transition process is to be followed to ensure smooth hand over of the project to the new project
manager and no disruption to the project activities.

The existing project manager should prepare a transition plan. It should include handing over of project
documents, updation of the status in the role, the overlapping period and the transition review and
completion dates.

The role based transition review checklist should be used as an input for preparing the transition plan.

The Technical Manager should communicate the change of Project Manager to the client.

The new Project Manager should conduct a role based audit and audit findings should be updated in the
transition plan.

On completion of the overlapping period, the supervisor should review the transition.

The Software Quality Assurance manager should verify the effectiveness of the transition and sign-off.

NOTE:

The Role transition process is applicable to critical roles like Project Managers, Technical Managers,
Quality Coordinators, Project Leaders or Team Leaders and Software Quality Assurance Managers.
Project Management Process Monitoring and Control Management Reviews
Metrics Analysis

Metrics Analysis is performed at project, account, group and organizational levels.

Metrics analysis of the data gathered is carried out periodically to lead decisions on project activities.

Statistical Tool like control charts and trend analysis should be utilized for metrics analysis.

The Root Cause Analysis must be carried out for any deviation in the metrics norms.

The action items in Project Monitoring Report must be documented and tracked to closure.

At the end of the project or on completion of one year, a project performance analysis should be
conducted and the lessons learnt documented in Project Performance Report.

The metrics reported at the project level are analyzed at vertical or group and organizational level to
review the effectiveness of the quality system.

At the vertical or group level, the metrics are reviewed on a monthly basis in Quality Improvement
Councils that is QICs).

At the vertical or business unit level, the review is conducted on a half yearly basis in vertical
management review meetings.

At an organizational level, the review is conducted annually in MRMs or Management Review Meetings.



Project Management Process Monitoring and Control QIC & MRM
The QIC that is the Quality Improvement Council is conducted once a month and the participants are:
Vertical Head, Strategic Business Unit Head, Technical Managers and the Software Quality Assurance
team

The aspects to be discussed are:

-Discuss exceptions in project related activities

-Customer Complaint Analysis

-Six Sigma review

-Audit or Assessment findings presentation

-Update from Software Engineering Process Group and Tools group

-Identification of process improvements

-Presentations on lessons learnt from closed projects for the previous month and new projects initiated.

-Discussion on significant process deviation and process implementation issues.

-Escalations regarding resource requirements

The Domain Management Review Meeting takes place once in six months and the participants are:
Vertical Heads, Group Vertical Heads, Strategic Business Unit Heads, Functional Heads, Software Quality
Assurance Managers, Software Engineering Process Group Head, Tools Group Head and Software
Quality Assurance team of the vertical.

The aspects to be discussed are:

-Metrics Analysis

-Customer Satisfaction and Customer Complaints analysis

-Six Sigma review

-Audit or Assessment findings presentation

-Discussion on Vertical Metrics Norms Revision

-Identification of process improvements

-Discussion on unresolved issues of Quality Improvement Council

The Management Review Meetings take place once in a year at the organization level.

The participants are: Vice Chairman, President, Vertical Heads, Group Vertical Heads, Strategic Business
Unit Heads, Functional Heads, Software Quality Assurance Managers, Software Engineering Process
Group Head, Tools Group Head and GEO Heads.

The aspects to be discussed are:

-Metrics Analysis and Metrics Trend

-Customer Satisfaction and Customer Complaints analysis

-Six Sigma review

-Audit or Assessment findings

-Metrics Norms Revision

-New Quality Initiatives

-Update on New standards, statutory or regulatory requirements

-Updates from functional groups

-Discussion on unresolved issues of Domain Management Review Meeting



Apart from the common agenda, other quality-related issues can also be discussed in the Quality
Improvement Council and the Management Review Meeting.

Problems and process improvement suggestions are prioritized. Task forces are formed to work on the
analysis and implementation aspects.

The proceedings are minuted. The action items, persons responsible and target completion date are
documented and tracked to closure.

The task force teams analyze the problem or process improvement and present recommendations.

The recommendations are implemented upon endorsement in the relevant forums i.e. (Quality
Improvement Council or Management Review Meeting), Thereafter, updations are made to the quality
system if required.




Project Management Process Customer Focus and Project Closure Customer Focus
In order to understand the customer's perception about the services we provide, customer feedback is
taken regularly. There are 2 mechanisms of obtaining this feedback.

-Transactional survey

This is done at a project level. Here feedback is obtained from the customer project manager typically
on completion of the project or a major milestone in the project. The project specific feedback form is
used for this. The feedback form comprises of mandatory questions and can be customized based on the
project requirements. The guidelines for customizing the questionnaire are provided in veloci-Q. The
customized questionnaire should be administered.

For development/conversion/testing projects, project feedback is obtained either after a major release
or at the end of the project.

For Application support and maintenance projects, the feedback is obtained as part of pseudo-closure or
the final closure. Long running maintenance projects should obtain Project specific feedback at least
once a year.

The project manager should analyze the comments given by the customer and improvement
opportunities should be planned and tracked to closure.

The technical manager should consolidate the project feedback of all the projects in the account and
report them to the senior management.

Project specific feedback should be uploaded on the online repository.

Annual Survey

Annual Survey is rolled out across the customer base of the organization once every year. The objective
of this survey is to measure the customer satisfaction based on the expectations, assess the health of
the relationship, derive strategic inputs at the account level and organization level and determine the
customer perception on the core value proposition being delivered to them.

In such a survey, a hierarchial response is sought. Customer managers are mapped to different
hierarchial levels like - Mid Management, Senior Management and CXOs. The format of the survey is
different for the hierarchies. Normally a 3 tier survey is conducted.

The Annual surveys could be conducted by independent third party agencies on a need basis or
administered by an independent authority within the organization like the Quality Head or Software
Engineering Process Group.
Project Management Process Customer Focus and Project Closure Project Performance analysis
The project performance analysis or PPA is conducted to analyze how the project was executed and
consolidate best practices and lessons learnt.

For development and conversion projects, Project Performance Analysis should be conducted within
one month of the final release. For projects spanning for more than a year, pseudo Project Performance
Analysis should be conducted at least once a year.

For maintenance and service projects running for more than a year, pseudo Project Performance
Analysis should be conducted once a year and final Project Performance Analysis should be conducted
during project closure

The latest updated Project Data and Metrics Report, the release documents and the Post Release Plan
are inputs for Project Performance Analysis. A Project Performance Analysis meeting involving the
project team, Software Quality Assurance Manager, KM prime and tools group member should be
conducted. The Project Performance Analysis meeting should discuss the:

-Actual Project performance results

-Deviation from quality & productivity goals

-Distribution of effort, defects

-Review & Test Effectiveness

-Best Practices i.e. (Tools, Technology, Process, Management, Re-Use, Defect Prevention)

-Experiences, lessons learnt from the project

-Customer complaints or Commendations
-Corrective and preventive actions
The project performance report that is document is prepared.
Here is a sample Project Performance Analysis.

Project Management Process Customer Focus and Project Closure Project Closure
Once the project is delivered to the customer and all contractual obligations of the project are met, the
project manager initiates the project closure process. The key activities to be performed are:

Obtain customer sign-off at the end of the acceptance phase.

Obtain project specific customer feedback.

Conduct the Project Performance Analysis and prepare the Project Performance Reports.

Software Quality Assurance Manager and Technical Manager should verify and approve the final Project
Data and Metrics Report and Project Performance Reports. A Disaster Recovery backup must be taken.

The Technical Manager should update the project closure details in organization database.

The Software Quality Assurance manager should upload Project Performance Report to the PDB and
send Project files for Archival
Project Management Process Customer Focus and Project Closure Archival
During project closure, the project documents are archived.

The steps to be followed to do this are:

Copy project related documents to a CD for archival.

Typical documents for archival are proposal, contract file, acceptance letter, minutes of important
teleconferences, project plan, specification documents (Requirement Specifications, Functional
Specifications, design), test documents, approval emails and customer sign-off emails.

List all the documents contained in the archival CD in the archival transmission note.

Submit the archival transmission note and the archival CD to ISD.

NOTE: Items which have customer restrictions or contractual obligations or IP rights should be retained
with project team and not archived.

In case only hard copies of the document are available, they can be sent to ISD where they would be
scanned and archived.

Project Management Process Techniques and Tools


Program Framework (Refer PPT)
CMMI High Maturity Practices an Overview (Refer PPT)