Coventry University Postgraduate Program

Coventry University Postgraduate Program Coventry University Postgraduate Program

Module Title: KPIM03EEC_Lean and Six Sigma Analysis Tools and

Techniques – 1819AAA

Lean and Six Sigma (LSS) Methodologies in Software Services

Industry

Emp. No: 133967

Name: P U Divya Darshini
E-mail: P.Darshini@kpit.com

CU Enrolment Number: 9654866

Date of submission: 11th November 2019
 2

Declaration
The assignment submitted is a result of my own investigation and independent work.
All sections of the text and results, which been obtained from other sources, are fully
referenced. No confidential information of KPIT is included in this assignment. I
understand that cheating and plagiarism constitute a breach of University regulations
and will be dealt with as per prevailing university rules and regulations.

Signed: P U Divya Darshini Date: 11th November 2019

 3

Table of Contents
Declaration............................................................................................................................ 2
Table of Contents.................................................................................................................. 3
List of Figures ....................................................................................................................... 3
List of Tables ........................................................................................................................ 3
1 Literature Review ............................................................................................................... 4
2 Case Study ........................................................................................................................ 7
2.2 Identification of Waste ................................................................................................ 7
2.1 Mapping Value Stream: An efficient method to discover wastes ................................. 8
2.3 Implication of Wastes.................................................................................................. 9
2.4 Process Flow Chart: ................................................................................................... 9
2.5 DMAIC Methodology to eliminate Defects................................................................. 11
References ......................................................................................................................... 16

List of Figures
Figure 1: Proposed framework of Lean Sigma Implementation in Automotive Manufacturing
Industry ................................................................................................................................. 4
Figure 2: The tools and techniques of Lean and Six Sigma ................................................... 4
Figure 3: Conceptual Model for Software Six Sigma (Pan et al. 2007) .................................. 6
Figure 4: Architecture of Six Sigma Framework (Pan et al. 2007) ......................................... 6
Figure 5: Value Stream Map ................................................................................................. 8
Figure 6: Process Flow Chart of AUTOSAR Team .............................................................. 10
Figure 7: CTQ Tree ............................................................................................................. 11
Figure 8: Pareto Chart of Defects ........................................................................................ 12
Figure 9: Cause and Effect Diagram ................................................................................... 13
Figure 10: A3 Summary Document for Elimination of Delays .............................................. 15

List of Tables
Table 1: Wastes Identification: Activities that lead to increase wait time ................................ 8
Table 2: Frequency of Defects ............................................................................................ 12
 4

1 Literature Review
The automotive industry has witnessed an immense pressure from customers and competitors for a
delivery with lower cost, better quality and faster delivery (Kumar et al. 2006). Origination of Lean comes
from Japanese Total Quality Management (TQM; Toyota Production System). Lean is used for distinctly
identifying and elimination of waste and non-value-added tasks, whereas Six Sigma is used to minimize
variations and errors (Raval and Kant 2017). Kumar et al. (2006) and Vinodh et al. (2011) proposed to
use the framework as shown in Figure 1 which integrates Six Sigma (DMAIC) problem-solving
methodology integrated with Lean tools to minimize errors in the final product. Figure 2 shows the tools
and techniques of Lean and Six Sigma. This approach was taken to deal with defects in the product,
work-in-progress, inventory, rework cost and scrap better.

Figure 1: Proposed framework of Lean Sigma Implementation in Automotive Manufacturing Industry

Figure 2: The tools and techniques of Lean and Six Sigma

 5

Considering the software industry in general, there were a lot of controversies on implementing
Lean Six Sigma methodologies for process improvement. Software industry faces stiff competition
globally for excelling in their delivery to the customers. The implementation of Lean Six Sigma in the
Indian software industries is still evolving. For a company to give competition to other companies,
products need to be differentiated for the customers. Quality is an important differentiation factor.
Capability Maturity Model (CMM) and Capability Maturity Model Integration (CMMI) are the
methodologies followed by most of the software companies for process improvement. CMM and Six
Sigma go together and have helped companies achieve CMM Level 5 (Mahanti 2009).

Many fortune 500 companies have applied Six Sigma concepts to multitude projects. Examples
of companies are Texas Instruments, American Express, Boeing, Caterpillar, Fidelity Investments,
Honeywell International, J.P. Morgan Chase, Johnson and Johnson, Kodak, Lockheed Martin, Maytag,
Northrop Grumman and Texas Instruments. The Six Sigma ideologies spread from US to the European
Union, Canada, Japan and now it has spread to countries like India and other developing countries
(Desai 2012).

In the Indian Software Services Industry, Wipro launched a pilot “lean” initiative where their
intension was to translate lean manufacturing ideas to software services. In their two projects of tooling
systems and a telecom product, they used combination of Design status matrix (DSM), Visual Control
Board (VCB), Automation of processes, prototype creations and Value Stream Map (VSM). DSM is an
approach which is used for scheduling designed by the Project Manager (PM) and Team Lead (TL).
Architectural DSM was used to divide the work packet into modules and technical DSM was used to
define the tasks within each module. This approach helped them to efficiently assign tasks to the team.
VCB was used to track daily progress of team members to evaluate % of task completed. Prototype
creation helped them to offer solutions to customers when they were not sure about the what they
wanted. Value Stream Mapping was used to analyze the drawbacks in the current process and
brainstorm ideas to make the process more efficient (Staats et al. 2009). Wipro is the first company to be
certified with CMMI Level 5 in software services company and first outside USA to receive IEEE Software
process award (Sharma et al. 2012).

The Capability Maturity Model Integration (CMMI) and Six Sigma both work towards the same
goals and principals. Both these approaches mutually support and complement each other. Integration
of CMMI and Six Sigma gives a new approach to improve process (Siakas et al. 2006). Example of
companies who follow this approach are mentioned below:
1) Tata Consulting Services (TCS): Six Sigma was implemented on their software review
process and decisions on program matrix. This was implemented for the center in Chennai, India
which was the engineering center for General Electric which is evaluated at CMMI, Level 5.

2) Motorola: Motorola has facilities evaluated at CMMI, Level 5, which is the founder of Six Sigma.
To determine the root causes of the delays in closure of corrective action reports and to improve
their audit process, they used multivariate techniques to software processes (Martin et al. 2001).

Pan et al. (2007) developed a conceptual model which collaborates Six Sigma with other software
process improvement methods like Personal Software Process (PSP), Team Software Process (TSP)
and CMM/CMMI. Figure 3 shows the conceptual model where each of the processes in PSP and TSP
can be improved using the Six Sigma Tools and levels, process areas and representations in CMMI can
be improved by Six Sigma framework and can be analyzed by Six Sigma Tools. Figure 4 shows the Six
Sigma framework which provides the components and their relationships and external components
which are required to assist in data collection and analysis.
 6

Figure 3: Conceptual Model for Software Six Sigma (Pan et al. 2007)

Figure 4: Architecture of Six Sigma Framework (Pan et al. 2007)

 7

In India, Lean Six Sigma Methodologies are prevailing in many industries, but a lot of them are still
facing barriers to transit to Six Sigma methodologies because of the following reasons (Antony and
Desai 2014)
i. Lack of financial, human resources and time etc.
ii. Internal technical and political resistance
iii. Lack availability of appropriate training
iv. Lack of concrete results.

From the above literature review we can conclude that the approach of integrating Six Sigma and
other software improvement processes like PSP, TSP and CMMI is a right fit for the Software Services
Companies in India. Even though transiting to using Lean Six Sigma methodologies has its own
challenges, we see a lot of companies taking the initiative to slowly incorporate these changes for
achieving their goals.

2 Case Study
This case study is of an automotive software company in India named PUD Limited. This company
provides software solutions for mobility across the globe. In this company we are going to look at a team
which is currently working towards migration of previous software components to AUTOSAR compliant
versions for their customer. This case study will focus to identify the wastes in the current development
process, implications of these wastes and use specific Lean Six Sigma methodologies to over come
these wastes to reap better profits for the company by utilizing their resources efficiently.

2.2 Identification of Waste

Muda (waste) could be anything which does not lean towards adding value to the customer. The seven
standard wastes were identified as a part of Toyota Production System (TPS) by Shigeo Shingo (Hines
et al. 2010). Various activities which have been identified from the processes followed in the case study
has been tabulated in Table 1.

Wastes in Wastes in
Sl. Manufacturing Software Activities Considered as Wastes for this Case
No Industry Industry Study
a) Multiple review stages before proceeding to
the next phase
b) Miscommunication to the team due to
1) Over Processing Extra Processes unclear requirements
c) Detailed Documentation of every single
instance
c) Very long and complicated quality processes
a) Required data to work with not received
from the customer
b) Human, software and hardware resources
not allocated on time
2) Waiting Delay
c) Delay in scheduling the reviews and
availability of the reviewer
d) Delay in providing appropriate training to
the resources
a) Knowledge gap between the two teams
3) Motion Hand-offs
(Migration and Validation Team)
 8

b) Miscommunication through unnecessary

circulation of mails
a) Defects identified at the customer end due
to logical errors
b) Ignored defects at the initial stage that
4) Defects Defects propagates further
c) Errors in documentation
d) Misinterpretation of requirements
a) Resources working on multiple tasks
5) Transportation Task Switching b) Reviewers overloaded with reviews and
their own tasks
a) Implementation of extra features to please
6) Over Production Extra Features the customer which would not be useful to
them

Table 1: Wastes Identification: Activities that lead to increase wait time

2.1 Mapping Value Stream: An efficient method to discover wastes

To discover wastes in a development process, value stream mapping is useful. Process of value
stream mapping has constantly led to conclusions about if a process is efficient enough to meet
customer needs (Poppendieck 2013).

Figure 5: Value Stream Map

Figure 5 shows the process flow from the point the proposal is submitted till the customer delivery
is done. With this map we can derive wastes which is causing the wait time to be longer. It takes about
8.5 months for complete execution of a project from the proposal stage. The duration required from
analysis phase till the deployment phase is about 4 months for migration of a single component currently.
The team comprises of a project lead, team lead, 4 software engineers who play the role of a developer,
tester and a reviewer as per the need. The billability details of these software engineers are as follows:
• Per day billability: Rs.1500
• They work for 8 hours in a day, hence their per hour billability becomes Rs.188.
• The team works for 5 days a week.
 9

2.3 Implication of Wastes

The wastes identified in Table 1 have an impact on time, which eventually has an impact on the cost of
the project. Let’s look at the resources lost due to the wastes identified above. For the time loss calculated
below, refer to the process map in Figure 3.

1. Extra Processes:
There are 3 levels of review for migration process and 3 levels of review for validation process.
Each level of review takes about 3 hours which makes it 9 hours of review. We see that there
are 2 extra review stages.
• Time required for each level of review: 3 hours
• Time required for 6 reviews: 18 hours
• Time lost due to extra number of reviews: 12 hours
• Resource efficiency lost in terms of cost biweekly per resource (Software Engineer):
Rs.188*12 = Rs.2256
2. Delay:
a) There are delays in scheduling the reviews due to unviability of a reviewer. This delays the
process of reviews. Total delay in scheduling the review is about 6 hours every week due to
which, while considering validation and migration reviews it adds up to a delay of about 2
weeks.
b) Allocation of hardware, software licenses and human resources takes 2 weeks after the
project kick-off due to unavailability of appropriate resources.

3. Hands-off:
It often happens that migration and validation is done by two different set of people and
appropriate knowledge is not transferred from one team to the other team. Due to this
approximately 1 week of time is lost as the validation team would have to consult the migration
team for their work.

4. Defects:
Errors at every stage have a direct cost and time loss. Adding up all the time lost in rework due
to errors we see that the team works for 3 more weeks than the estimated time.

5. Task Switching:
Engineers work on multiple tasks. They do either migration or validation along with being a
reviewer for reviews. This overloads them with work which brings down their productivity due to
which the error rate increases. Since their productivity goes down, they tend to be spending 6
hours more every week to complete a task.

6. Extra Features
Engineers work towards pleasing the customer for which extra efforts are required. Every
engineer spends about 2-4 hours a week to create extra features which do not add value to the
customer.

2.4 Process Flow Chart:

Process flow diagrams are a method to represent and describe process and its corresponding tasks in
a sequence graphically (Elahi 2018). Figure 6 shows the process flow diagram currently followed by
the AUTOSAR Team in PUD Limited.
 10

Notes Process flow of AUTOSAR Team Documentation

Figure 6: Process Flow Chart of AUTOSAR Team

 11

2.5 DMAIC Methodology to eliminate Defects

DMAIC is an approach in Lean Six Sigma Methodology which is data-driven life cycle approach for
improving the process of the company. DMAIC stands for five phases: define, measure, analysis,
improve and control (Sokovic et al. 2010).

DEFINE: What Problems Do We Need to Solve?

From Table 1 we see that defects are one of the identified wastes from the process currently being
followed by the company. Figure 7 shows a CTQ Tree which is a six-sigma tool, which translates
customer needs, expectations and requirements into specifications. It has three stages where the need
of the customers is defined at a general level, after which a specific quality driver is used to identify
measurable parameters and features so that they can be managed (ISIXSIGMA n.d). Figure below
shows how minimum defect is one of the quality aspects of a good software and efforts to automate
processes and improved review techniques can bring down the number of defects reported by the
customer and other intermediate defects before delivery which consume a lot of time for rework.

Figure 7: CTQ Tree

Current data of Defects of AUTOSAR Team is as follows:

a) Defects reported by the customer: 13 defects per component
b) Total number of defect opportunities in a component: 80 defects per component
c) Current % of defects per component: 16.25

MEASURE:
In DMAIC model, measure phase is used to understand how often a defect occurs and what is the main
factor in the process causing these effects (Biswas and Ahmed 2013). With the help of process map
shown in Figure 3, a list of defects has been identified and the data comprising its frequency has been
taken from the number of defects occurred in previous component migration which is seen in Table 2

Figure 8 shows the pareto chart where we can clearly see that 86% of the defects are due to
logical defects and 14% of the defects are due to errors in documentation and process compliance. This
gives a clear picture that the team needs to focus on reducing the logical defects by analyzing different
methods to reduce these defects.
 12

Sl. No. Type of Defect Defects Frequency Cumulative Cumulative %

1 Functional Defects 4 4 29%
2 Requirement Defects 1 6 43%
3 Simulation Defects 1 7 50%
Logical Defects
4 Code Generation Defects 1 8 57%
5 Migration Defects 2 10 71%
6 Validation Defects 2 12 86%
7 Documentation Defects 1 13 93%
8 Other Defects Process Compliance Defects 1 14 100%
Total Defects 14

Table 2: Frequency of Defects

Figure 8: Pareto Chart of Defects

ANALYSE:
This phase has an objective to identify the root cause of the problem and its relation to the cause. Figure
7 shows the cause and effect diagram for the problem of defects in the software component delivered. It
shows the various reasons and its cause, which was listed down after using the technique of brain
storming session that involved the members of the project team. Regression analysis can help the team
to understand which of the changes in the input variables have an impact on the output.
 13

Figure 9: Cause and Effect Diagram

From brain storming and regression analysis, it was observed that relationship between automated
scripts at various phases and number of defects was positive and as a result % of defects went down
considerably as the resources did not have to put in manual efforts which caused most of the defects.

Improve and Control

Improve:
Since the major root cause of the defects was due to manual implementation, automated scripts need
to be developed which will reduce the efforts of the resources and increase their productivity.
Following are the proposed solutions for improvement:
1) Automate scripts at, as many stages as possible making sure, this process does not affect the
functionality.
2) Reassigning of tasks to the resources: The team needs a dedicated reviewer to avoid task
switching and delays during reviews which would increase the number of defects. Amongst the
four engineers, one will play the role of the reviewer, one will be a tester and one will be a process
consultant.

In the current case study, the above solutions were implemented and accordingly project plan and
estimations were redesigned. With this approach, it was clear that the number of defects and the over all
time taken was reduced. The table below shows the % of defects which has reduced after automation.

For the control phase, we need to continuously monitor if our proposed solution is giving us the
desired targeted results. A defect dashboard will help us measure and if the number of defects continues
to not decrease, new solutions need to be proposed and implemented. The control plan could follow 5
steps: 1) Develop a control plan, 2) Determine the improvement capabilities, 3) implement process
control and 4) Close the Project.
 14

Frequency
Sl. Type of Frequ Cumm Cummul after Cummul
No. Defect Defects ency ulative ative % automation ative %
Functional
1 Defects 4 4 29% 2 33%
Requirement
2 Defects 1 6 43% 1 50%
Simulation
3 Defects 1 7 50% 0 50%
Logical
Code
Defects
Generation
4 Defects 1 8 57% 0 50%
Migration
5 Defects 2 10 71% 0 50%
Validation
6 Defects 2 12 86% 1 67%
Documentatio
7 n Defects 1 13 93% 1 83%
Other Process
Defects Compliance
8 Defects 1 14 100% 1 100%
Total Defects 14 6

2.6 A3 Summary Document for elimination of Delays

A3 problem solving report is a way to see a specific identified problem with a different perspective. This
document helps to document problems, root cause of the problems, solutions and implementation plan
along with a follow up plan (Lee 2009). A3 can be used for reporting project status, solving problems and
proposing policy and process changes. It helps in analyzing a problem in depth and solving the problem
throughout the process. Figure 10 shows the summary document for elimination of delays in current
process of AUTOSAR Team in PUD Limited. This summary report was used to understand the target
which the team wanted to achieve, analyze the root cause of the identified problems and implement the
proposed solutions.
 15

A3 Summary Document
Background: Proposed Countermeasure(s):
PUD Limited's mission statement: On-time Delivery with good Proposed Solutions: The proposed solutions has been captured with use of
quality software solutions. AUTOSAR team is aiming to deliver an affinity diagram given below:
their migrated components to the customer quicker by
eliminating the delays.

Current Conditions:
Currently a single component is being migrated and delivered
in 32 weeks starting from the proposal till the delivery phase.
Pareto chart below shows the different reasons for the delay.

5
CHART TITLE
55% 73% 91% 100%
0 27%

Implementation Plan:

Target(s)/Goal(s)
Target is to deliver a migrated component right from the
proposal stage till the delivery for future incoming projects in
24 weeks.

Analysis
After using the technique of 5 why's, some of the root causes
are:
1) Available resources do not have the required skill set.
2) Allocation of hardware and software takes time due to a long
approval chain.
3) Delay in receiving data from the customer end due to
inappropriate communication. Follow Up Plan:
4) Required training not avaibale to resources due to the non- Following activites to be performed in the follow up plan:
availability of an AUTOSAR expert as there are very few 1) To maintain a dashboard to measure the delays after the implemntation
experts who can train other resources. of the proposed solutions.
2) Analyse further methods to eliminate the waiting time between the
Team Name: AUTOSAR Team processes.
Date: 2nd November 2019 3) Regular meetings with steering committee to review the issues and
delays between teams.

Figure 10: A3 Summary Document for Elimination of Delays

 16

References
"ISIXSIGMA" Critical to Quality(Ctq) [online] available from
<https://www.isixsigma.com/dictionary/critical-to-quality-ctq/> [1st November 2019 2019]

Buckley, P., Prewette, P., Byrd, J., and Harrison, G. (2017) Staying Lean: Thriving, Not just
Surviving.: Productivity Press

Chakrabortty, R. K., Biswas, T. K., and Ahmed, I. (2013) 'Reducing Process Variability by using
Dmaic Model: A Case Study in Bangladesh.'. International Journal for Quality Research 7 (1)

Desai, D. A., Antony, J., and Patel, M. (2012) 'An Assessment of the Critical Success Factors for
Six Sigma Implementation in Indian Industries'. International Journal of Productivity and
Performance Management 61 (4), 426-444

Elahi, B. (2018) Safety Risk Management for Medical Devices.: Academic Press

Kumar, M., Antony, J., Singh, R. K., Tiwari, M. K., and Perry, D. (2006) 'Implementing the Lean
Sigma Framework in an Indian SME: A Case Study'. Production Planning and Control 17 (4),
407-423

Mahanti, R. and Antony, J. (2009) 'Six Sigma in the Indian Software Industry: Some Observations
and Results from a Pilot Survey'. The TQM Journal 21 (6), 549-564

Martin, R., Schwaber, K., and Beedle, M. (2001) 'Agile Software Development with Scrum'

Pan, Z., Park, H., Baik, J., and Choi, H. (eds.) (2007) 14th Asia-Pacific Software Engineering
Conference (APSEC'07). 'A Six Sigma Framework for Software Process Improvements and its
Implementation': IEEE

Poppendieck, M. and Poppendieck, T. (2013) Lean Software Development

an Agile Toolkit. Canada

Raval, S. J. and Kant, R. (2017) 'Revealing Research Trends and Themes in Lean Six Sigma: From
2000 to 2016' 9 (3), 339

Siakas, K. V., Nisioti, K. S., Voutsa, E. A., and Gellén, M. (2006) 'Integrating Six Sigma with CMMI
for High Quality Software'

Sokovic, M., Pavletic, D., and Pipan, K. K. (2010) 'Quality Improvement methodologies–PDCA
Cycle, RADAR Matrix, DMAIC and DFSS'. Journal of Achievements in Materials and
Manufacturing Engineering 43 (1), 476-483

Staats, B. R. and Upton, D. M. (2009) 'Lean Principles, Learning, and Software Production:
Evidence from Indian Software Services'. Harvard Business School Technology & Operations
Mgt.Unit Working Paper (08-001)

Vinodh, S., Gautham, S. G., and Ramiya R., A. (2011) 'Implementing Lean Sigma Framework in an
Indian Automotive Valves Manufacturing Organisation: A Case Study'. Production Planning &
Control 22 (7), 708-722