Six sigma implementation in it software product industry – a case study

International Journal of Computer Engineering and Technology (IJCET), ISSN 0976-

6367(Print), ISSN 0976 – 6375(Online) Volume 4, Issue 4, July-August (2013), © IAEME

475

SIX SIGMA IMPLEMENTATION IN IT SOFTWARE PRODUCT INDUSTRY –

A CASE STUDY OF SME IN MALAYSIA: SIX SIGMA METHODOLOGY IN

IT PROJECT MANAGEMENT

Whee Yen Wong1, Chan Wai Lee

2, Kim Yeow Tshai

3

Department of Mechanical, Materials and Manufacturing Engineering, University of Nottingham,

JalanBroga, 43500 Semenyih, Selangor DarulEhsan, Malaysia.

ABSTRACT

Project planning is one of the most important and critical stages in the modern software

development process because it defines the project based on the requirements gathered. Any IT

project without a solid blueprint of the project plan will most likely jeopardize the entire process and

eventually result in project failure. Most IT projects fail at the beginning due to a lack of sufficient

planning where project managers tend to “dive” into project execution with only a brief or high-level

project plan, thinking they know what to do, where to start and how to do it. Without a realistic

project plan, the software development process cannot be managed in an effective way and thus

having a negative impact not limited to dollar and cents spend on rework but seriously affecting final

software quality, team morale, motivation and company culture. This research integrated and

adopted the Six Sigma knowledge-acquisition approach known as DMAIC (Define, Measure,

Analyze, Improve and Control) in a small-medium enterprise (SME) (SYNDES Technologies Sdn.

Bhd.) in the IT software industry to examine the relationship between effort in project planning and

the attainment level of project success. This paper discusses the integration of various planning

aspects such as “detailed requirements definition”, “mapping of requirement definition items into

project schedule” and “project/modular quality delivery” which has major impact on the final

“project performance delivery”.

Keywords: IT Project Management, Software Industry, Project Planning, Project Success, Quality

Improvement Methodology, Six Sigma, SME Malaysia.

1. INTRODUCTION

Project failure and project delays are among the most common challenges faced by most IT

projects. According to the Standish group study in 2009 [1], 44% of all projects were challenged

with late delivery or over budget, and 24% failed due to projectsbeing cancelled prior to

INTERNATIONAL JOURNAL OF COMPUTER ENGINEERING &

TECHNOLOGY (IJCET)

ISSN 0976 – 6367(Print) ISSN 0976 – 6375(Online) Volume 4, Issue 4, July-August (2013), pp. 475-484 © IAEME: www.iaeme.com/ijcet.asp Journal Impact Factor (2013): 6.1302 (Calculated by GISI) www.jifactor.com

IJCET

© I A E M E



476

completion,undelivered or never used. The KPMG Canada Survey in1997 and the Bull survey

in1998 revealed that major causes of project failure during the lifecycle of the project is lack of

planning; and poor estimates or weak definitions of user requirements at the project planning stage

[2]. Therefore, it is not surprising that nearly three quarters of all IT projects suffered from one or

more of the following: total failure, cost overruns, time overruns, or a rollout with fewer features or

functions than promised [3].

IT project management is a structured, systematic and disciplined approach using modern

management techniques of planning, organizing, motivating and controlling resources to achieve

specific goals. Although a project is a temporary endeavor, a successful project requires effective

planning if the project team wishes to deliver a finished project on time and within budget.

In this paper, an in-depth analysis of a completed IT project for acase study company was

carried out to identifythe areas that required most improvement in IT project management through

adopting and implementing “The Roadmap and Tools of Six Sigma” by Pande[4]. Six

Sigmaprovides a structured problem-solving approach and a well-rounded quality improvement

methodology (QIM) that allows the research team to further explore opportunities by identifying the

case company’s weaknesses in IT project management and related operational activities for

continuous improvement. Hence, it is important for the research team to follow a set of guidelines at

each stage of the DMAIC process in customizing activities related to IT project management and to

ensure resource utilization is maximized.

2. CASE COMPANY BACKGROUND

The case company is a software service, software product and consulting SME company that

offer core operations of knowledge, technology and best practices in the capacity of a solution

provider. Apart from having a wide network across Malaysia, the case company also has a

significant international presence in Asia Pacific.

The company’s core activities include creation and implementation of intranet and internet-

based business solutions to improve mobile network and operational performance, as well as to

facilitate collaboration among managers, engineers, and customers.

In the past three years, the case companyhas completed a few projects covering various areas

of technology, including Human Resource Management System (HMS), Fleet Management System

(FLM), Website Portal, WiFi/WiMax related applications and performance tools.The overall high-

level identification and integration of the case company’s core processes, support processes and key

customers can be summarized in Fig. 1.

Figure 1 High-Level Overview of the Case Company

• WiMAX Network Performance

Analyzer

• K2 [blackpearl]

• Application Development

• Business Consultancy

• Customer Support

• Special Support

Retailer

Construction Developer

Network Service Provider

Insurance & Financial

Cosmetic & Healthcare

Electrical Engineering

COR

E

PRO

CESS

ES

CUST

OMER

S

IT Product

IT Service

IT Support

SUPP

ORT

PROC

ESSES Staff Hardware &

Software

IT Infrastructure Process Informal

QA Finance &

Strategies



477

3. SIX SIGMA DMAIC PROCESS

Six Sigma is a business management process that provides tangible business results to the

bottom line by continuous process improvement and variation reduction [5]. It is used to identify and

eliminate defects, waste and quality-control problems. Six Sigma also provides a discipline to

guarantee that one will work on the right problem, the root-cause will be identified and the best

solution will be determined and implemented [6].

Although the Six Sigma DMAICframework has been widely adopted and implemented in the

past, effort of in-depth analysis at each phase is required to ensure root-causes are identified and

analyzed, especially during the initial stage. DMAIC is a highly data-driven, fact-based application

of the scientific method of inquiry that emphasizes discernment and implementation of the so-called

Voice-Of-Customer (VOC as related to processes, products and services) that creates value for the

products and consumers [7].

3.1 DEFINE PHASE The key objective in the Define stage is to create a clear understanding of the most critical

cross-functional project management activities involved in the Project Life Cycle (PLC) and how

these activities interfere between different phases of the PLC.

A preliminary analysis of the IT project management procedures and process flow activities

were collected via interviews (both structured and semi-structured) and focus groups with the

managing director, software architect and team leaders. The information and details of completed

and/or existing case company’s IT projects work flow have helped to justify the potential of IT

projects in the case company as a Six Sigma case study improvement project:

• There exist performance gaps between planned/scheduled and actual IT project management

activities; such as scope, user requirements, timeline, costing etc.

• The reasons of deficiency in IT project management activities were not clearly understood and

the real root-causes must be identified.

• To-date, there is no significant effort being launched to bridge the “gap” and currently there isn’t

a predetermined solution or the optimal solution is not apparent.

3.1.1 Identify Core Processes, Support Processes and Key Customers The “big picture” of the case company’s business and cross-functional activities can be

described in a broader view of its PLC through the Supplier-Input-Process-Output-Customer

(SIPOC) diagram, as shown in Table 1.

Table 1 SIPOC Diagram for the Case Company Supplier Input Process Output Customer Requirement

• Printer

• Hardware

Vendor

• Software

Vendor

• Internet

Service

Provider

• Telco

Companies

• Network

Infrastructure

Supplier

• IT Knowledge-

based resources

• Project Schedule

• System

Requirement

Specification

• Software

• Hardware

• Network

• Internet

connection

• Contract

• Gathering User

Requirement

• Sign-off SRS

• Development of IT

Product / Services

• End Product Delivery

• Sign-off User Acceptance Test

(UAT)

• User Training

• Implementation

• Maintenance (contract basis)

• IT Software

• IT Hardware

• IT Services

• IT Support

• IT-related Specification

• User Guide /

Manual

• Stakeholder

• Department

Head / Manager

• IT Manager

• End-Users

• IT and non-IT SMEs

• Signed-off SRS

• Approved Project

Schedule

• On-time Delivery

• Within Budget

• Fulfilling and

Delivering user requirements

• Signed-off UAT



478

3.1.2 Identify Critical-To-Quality (CTQ) Once an overview of case company’s IT project management activities mapping was

established; the next step is to identify CTQs which is captured into Table 2. The preliminary

investigation revealed that the case company is experiencing an inefficient and ineffective time-cost

budgeting in IT project management activities. Majority of the IT projects were completed behind

schedule, over-budget, requiring repetitive effort and significant scope creep.

Table 2 CTQs Measure for the Case Company

No CTQs Output Measures Input/Process Measures

1. Quality Defect Quantity of reported

bugs by severity

level

Total quantity of bugs reported by

client after project implementation;

accordance to severity level of high,

medium and low impact.

2. On-time Delivery

Defects

Numbers of days

delay for a project

release

Discrepancies between plan and actual

product/service/support delivery date.

3. System

Requirement

Specification

(SRS) Defects

Percentage of

changes made to

baseline SRS

Discrepancies of user requirements

between baseline and delivered

product/service/support.

4. Planning Defects Total time spent on

project planning

Percentage of time spent on project

planning.

3.2 MEASURE PHASE Software quality has been the main concern from the case company’s Voice-Of-Customer

(VOC) as well as from the development team. Therefore, the authors are focusing on factors which

affect the outcome of software development and software production for the case company.

Quality has always been a difficult topic to define, and software quality management has

been exceptionally difficult [8]. The perception of quality varies from object to object as well as

person to person (i.e. clients, developers, end users, project managers, software quality personnel,

testers, stakeholders etc.). In short, quality often depends on the context in which a software

component or feature operates. Therefore, the case study has focused more on factors which affect

the development and production of an acceptable customized IT software product.

A total of eight projects from various areas were taken into consideration in the Six Sigma

Measure phase and we are focusing on data measurements based on the CTQs defined in the Define

phase. A comprehensive range of projectswere retrieved from various history sources/archives, and

the findings of project variables for the eight projects are summarized in Table 3. It can be observed

from Table 3 that only Project-C and Project-F spent 20% and 23% respectively on planning, the rest

of the projects utilized less than 10% or equivalent of the total project time on planning. As a result,

more bugs are captured during the PLC and rework is needed to correct these mistakes. The findings

reflected that the case company experienced a lack of planning effort in most projects. Kerzner[9]

recognized the importance of up-front planning and the most critical phase of any IT project is the

planning phase,whereany corrective actions after system implementation cost 20-times more than the

initial stage [1]. When a project is planned carefully; success is likely [9], rework is reduced, budget

is controlled and scope creep is reduced.



479

Table 3 Summary of Variables By Project

Project

Baseline

Duration

(days)

Actual

Duration

(days)

Planning

(days/%) FTE

SRS

Changes

(%)

Plan

Frequency

QA

Testing

Actual

Frequency

QA

Testing

Project

Status

Project

A 80 110 8 (7.4%) 2 40 3 1

Delayed

(30 D), 2

FTEs

Project

B

(Phase

I)

100 130 1 (0.7%) 3 40 3 1

Delayed

(30 D), 3

FTEs

Project

C 10 10 2 (20%) 2 0 3 1

On-

Schedule

Project

D 40 40 2 (5%) 1 5 3 1

On-

Schedule

Project

E 80 100 5 (5%) 2 30 3 1

Delayed

(20 D), 2

FTEs

Project

F 20 35

8

(22.8%) 1 20 3 1

Delayed

(15 D), 1

FTE

Project

G 5 5

0.25

(5%) 1 0 0 0

On-

Schedule

Project

H 100 120

10

(8.3%) 1 10 3 1

Delayed

(20 D), 1

FTE

A plot of “Level of Changes Made to SRS” versus “Project Delivery Performance” showed a

consistent pattern and alinear relationship between these two variables as shown in Fig. 2. The

observation concluded that an increase in percentage of “Changes to user requirements” will result in

an increase in time taken (i.e. delay) to deliver a project for this case study. This means that

“Percentage of changes to user requirement” is an important factor contributing to project delivery

performance.

Figure 2 Changes to User Requirement (Y) vs. Project Delay (X)

0

10

20

30

40

0.0 5.0 10.0 15.0 20.0 25.0 30.0 35.0 40.0

Ch

an

ge

s T

o U

ser

Re

qu

ire

me

nts

(%

)

Behind Schedule (%)



480

Further effort was spent to identify the current Six Sigma performance level on software

quality defects and delivery defects which is summarized in Table 4. Since it is common for many

ordinary businessesto actually operate in between two to three sigma performance [10], any business

performing below two sigma may require special attention as a means to improvement. Therefore, the

case company required immediate attention to streamline its investigation into root-cause analysis

which contributed to low sigma performance of 0.744σ in Project-B(Phase-I) for high-severity

software quality defects. Project-B (Phase-I) is a project scheduled for 100 days but was delayed for

30 days. A total of 129 bugs were reported and 77.5% (i.e. 100 bugs) of those were at high severity,

requiring immediate and ad-hoc attention where re-shuffling of technical staff(s) was necessary to

give priority to fix the bugs within the shortest time-span possible (normally within two hours from

the time the bug was reported) and prior to a return to their routine business operations.

On the other hand, the overall project delivery performance was disappointing where five out

of eights projects were reportedly delayed with a computed sigma level of 1.181 (Table 4). In

summary, there is only a 38% chance that a project will be delivered on time; other delayed projects

were observed with a high percentage of SRS changes where minimal time was spent on project

planning. Therefore, there is an urgent need to investigate “changes to SRS as an important factor

contributing to project delay”.

Table 4 Six Sigma Calculation – Defection Defection

Description Defect Unit

Opportunity

for error

per unit *

No of

defects

Defect/Unit

(DPU) DPMO

Sigma

Level Remark

Project

Delay

Delivery

Defect

Each

delivery

1 per

delivery

5

projects

was

delays

8 projects

DPMO= �58 x10

�

=

625,000

1.181

Project

A, B,

C, D,

E,F, G,

H

Reported

Bugs

Quality

Defect

Each

bug –

High

severity

1 per bug

100

high

severity

bugs

129 bugs

DPMO= �100129 x10

�

=775,193

0.744 Project

B

3.3 ANALYZE PHASE Despite data analysis in the measure phase, the authors furthered the investigation into project

life cycle activities using a high-level process map, input-process-variables process map as well as

looking into the main contributing variables to quality defects. The main objectives were to ensure all

incidents are investigated and root causes are identified. The team started with a brainstorming session

with the case company’s technical and support teams. The possible causes of defections or hypotheses

are: (1) Most of the IT projects are delayed due to existence of SRS changes; (2) Tendency of the

project team to omit or prepare insufficient project documentation during the PLC; (3) Lack of

planning effort during project start-up; and (4) Despite project delays, the project team faces

significant rework from the large number of reported bugs.

In support of the investigation, the authors aim to find out the root-causes contributing to SRS

changes which have a positive relationship with project delivery performance. A preliminary analysis

of the relationship between the variables of “Planning Effort”, “Quantity of Bugs” and “Rework

Effort” is outlined in Fig. 3.



481

Figure 3 “Planning Effort” vs. “Quantity of Bugs” vs. “Rework Effort”

Fig. 3 combined the variables of “Planning Effort”, “Quantity of Reported Bugs” and

“Rework Effort” for both Project-B (Phase-I) and Project-E. Project-E kick-started with five days of

planning effort and resulted in eleven reported bugs which took the team five days to rectify the

bugs. In contrast, Project-B(Phase-I) only took one day to plan and 129 bugs were reported. There

exist a positive correlation in “Planning Effort” against “Reported Bugs” and “Rework Effort”.

Whenever there is an increase of “Planning Effort”, there will be a reduction of “reported bugs”

which leads to “less rework”. Schwalbe[1]quoted that the relative cost to repair defects/bugs towards

the end of the PLC is 30-times more thanat the beginning of the PLC. This implies that proper

project planning (by spending sufficient time at the start of PLC) in determining user

requirements(i.e. SRS) is a crucial factor contributing to quality and product delivery.

In addition to analysis of archived documents, the research team has discovered other factors

that contributed to planning defects:

• System Requirement Specification (SRS) There are 7 projects (A, B, C, D, E, F & H) out of a total of 8 projects tracked in this work that

was reported with changes made to baseline SRS. A total of 75% of the case company’s projects

required changes to user requirement even after the SRS had been signed off. The level of

changes to the SRS varied among projects; with 40% reported for Project A and B; 30% for

Project-E; 20% for Project-F, 10% for Project-H and 5% for Project-D. This implies that there is

a high chance that Project-A, B, C, D, E, F and H encountered rework during the PLC.

• Project Schedule The case company has a code of practice to have its’ project schedule constantly updated,

showing the state-of-art of the project at any point of the PLC. However, the project schedule

does not reflect the project health as items in the SRS are not mapped into the project schedule.

The current way of managing projects result in redundant efforts in ensuring SRS items are

performed and the schedule is always up-to-date [11]. As such, the tasksappearing in project

schedules do not reflect fulfillment of items in the SRS and hence making project tracking and

monitoring less effective and inefficient.

Furthermore, it is a common practice in the case company to schedulea single task with 5, 10,

15 or 20 man-days of effort. This manner of high-level descriptive of task scheduling creates

unhealthy assumptions withthe developer [1] which will further lead to rework and more changes to

the SRS requirements.

Since Project-B (Phase-I) is the least performing project, it was chosen to gauge this positive

correlation between the variables of “Planning Effort” against “Total Reported Bugs” and “Rework

Effort”using a Pareto Diagram.

0

5

10

15

20

25

30

35

0

40

80

120

Project B Project E Re

wo

rk /

Pla

nn

ing

Eff

ort

(D

ay

s)

To

tal

Re

po

rt B

ug

s

Total Bugs Rework Planing Effort



482

Figure 4 Pareto Diagram – Project-B(Phase-I)

It can be observed from the Pareto Diagram in Fig. 4 that the high frequency of reported bugs

for Project-B (Phase-I) is caused by insufficient code walkthrough referring to brief

functionalspecification and brief system specification. The reason for not producing detailed project-

related documents (i.e. Functional Specification, System Specification) is due to scope creep where

changes are encountered (i.e. 40%) to the SRS. The root-cause of the recorded 40% of SRS changes

is due to lack of project planning.In project management, effective planning is absolutely required if

the individual or group wishes to deliver a finished project on time and on budget [1]. Project

planning is one of the most important stages in Project Management because it defines the objectives

of the project based on requirements gathered. Without Project Planning, the project will most likely

fail [1, 12].

3.4 IMPROVE PHASE Upon completion of the Analysis phase, the team produced a list of possible actions and ideas

to address the root causes. The team shared the possible actions and/or ideas with the Managing

Director and the shortlisted suggestions included ways to improve the chances of on-time software

product delivery by adopting a structured and scientific approach of IT project management.

IT project management requires a “structured and scientific approach” to the practice of

management in order to meet the myriad challenges of the modern era in the rapidly evolving IT

industry. This is the main reason why the case company must take the practice of project

management seriously. Without a scientific approach to the task of managing the projects and

achieving objectives, it would be very difficult for organizations to successfully execute the projects

within the constraints of time, scope and quality and deliver the required result [1]. In other words,

there has to be a framework and a defined way of doing things to ensure that there is a structure to

the art of project management.

Several process improvement activities were introduced in various phases of the PLC. The

following is asummary of the suggested project management activities particularly focusing on the

phases of planning and execution:

• Action Plan 1 – SRS: SRS is a control document of baseline user requirement established

during the Planning phase and is used by the project team for planning and execution.

The project team will plan, schedule and develop the end product based on the

“criteria” defined in the SRS. A good SRS should give the project team a “detailed”

understanding of the project scope, outlining what are the expected deliverable

0

25

50

75

100

0

25

50

75

100

Reported Bugs Code Walkthrough Funtional

Specification

System Specification SRS Changes Planning Effort

Log. (Cumulative Report Bugs)



483

items/modules/functions/products/services/supports. Items in the SRS are normally being

referenced in the scheduling process to estimate total time, cost and resources needed to develop

“these” deliverables. Therefore, it is necessary to pay closer attention to the SRS to minimize the

chances of scope creep.

• Action Plan 2 - Project Schedule:Items in the SRS are the main source or input for project

scheduling [13]. Hence, it is important to break down items in the SRS into smaller and more

manageable items so that mapping of SRS items against project schedule can be carried out more

effectively and efficiently [1]. In the event thatthe SRS items can be segmented into independent

module(s), modular delivery by stages is recommended.

Whenever items in the SRS are being itemized and mapped into respective “smaller manageable

task” (i.e. tasks with more than one man-day effort must be listed as a separate task) in the

project schedule, the project team manager needs to ensure all items in SRS are taken care of

with entries into the project schedule. As a result, at any one time the case company only requires

to maintain project schedule (i.e. which was mapped with SRS items) [1, 9, 12] and the next

focus would be tracking, controlling, developing and delivering “these” SRS items in the project

schedule.

In order to investigate the effect of a structured and scientific approach to IT project

management, the list of IT project management activities proposed in section 3.4as a result of Six

Sigma DMAIC approach was applied tothe second phase of Project-B. Project-B (Phase-II)execution

began in February 2013 but project planning activities were initiated since October 2012. Only team

leaders were involved in finalizing user requirements into SRS.

In view of the nature of Project-B (Phase-II), the project was segmented into five independent

modules with each delivered at different stages of the project execution phase. To-date, all the five

modules are delivered on-time and in compliance to SRS specifications.Although there are bugs

reported after modular delivery, there is a significant improvement oftotal sigma level in high-

severity software quality defects. Project-B (Phase-II) demonstrated a great improvement in software

quality defects where there have been no high severity bugs reported as compared to 100 out of 129

reported previously. Although there are 23 low severity bugs reported, those bugs fell into the

category of “cosmetics” rectification where fixing was straight forward and a minimum of re-testing

was required. The adoption of the Six Sigma DMAIC approach in the case company has improved

the deliverables quality by 82.17%, with a lowernumbers of total bugs reported (total 23 reported

bugs as compared to 129 prior to Six Sigma adoption). Furthermore, all the five modules were

delivered on-time, within-budget and met project scopes.

The importance of up-front planning in IT project management has been proven in this Six

Sigma Project-B (Phase-II), showing 20 days effort (against 1 day planning effort in Phase-I) in

project planning has resulted in better SRS management, less rework (only 5% as compared to 15%

in Phase-I) and more manageable bugs (no high severity bugs as compared to 129 bugs in Phase-I).

Although Phase-II was captured with a 5% change to SRS, a great improvement of 87.5% was

reported in better managing and better handling of SRS over the Phase-I project which reported 40%

changes to SRS baseline. The success of up-front planning also yielded other positive practices such

as producing a detailed SRS, mapped SRS items into project schedule, all tasks in project schedule

having less than or equal toone man-day effort and aided preparation of a comprehensive test plan

and testing to be carried out in all phases not limiting towards the end of project execution.

As an initiative of continuous improvement, the achievement of team productivity has

increased by 50% due to better controlling and better organization of IT project management

activities. In return, better team motivations and team spirit was embedded into the case company’s

team culture where sharing of knowledge among technical teams and support teams will further

improve project health.



484

4. CONCLUSION

The success of an IT project relies on a blend of demanding conditions. Those conditions are

always worthwhile reviewing before and during the course of a strategic IT project.Careful and

effective planning with Six Sigma DMAIC adoption ensures that projects will not overrun deadlines

and/or pile on unexpected costs. Thereforeaccording to the well-known 10/10 Rule which emphasize

the need of proper planning; in order to complete the project within 10% of the estimated cost, 10%

of the total estimated cost must be allocated to planning.The greatest reason for project failure is lack

of planning, so the ability to build and manage a project schedule is a top priority if one needs to

succeed at any IT project.

REFERENCES

[1] K. Schwalbe, Information Technology Project Management, 6th ed. Boston, MA: Thomson

Course Technology, 2009.

[2] http://www.it-cortex.com/Stat_Failure_Cause.html, "Project Failure Statistics." vol. 2013,

2013.

[3] S. Berinato, "The Secret to Software Success," 2001.

[4] P. S. Pande, R. P. Neuman, and R. R. Cavanagh, The Six Sigma Way; How GE, Motorola,

and other top companies are honing their performance. New York: McGraw-Hill

Companies, 2000.

[5] Q. Feng and K. C. Kapur, "New to Six Sigma? An Introduction to Six Sigma for Students and

New Quality Practitioners," 2007.

[6] A. C. Tonini, M. de Mesquita Spinola, and F. J. Barbin Laurindo, "Six Sigma and Software

Development Process: DMAIC Improvements," in Technology Management for the Global

Future, 2006. PICMET 2006, 2006, pp. 2815-2823.

[7] R. L. Edgeman, D. Bigio, and T. Ferleman, "Six Sigma and Business Excellence: Strategic

and Tactical Examination of IT Service Level Management at the Office of the Chief

Technology Officer of Washington, DC," Quality and Reliability Engineering International,

vol. 21, pp. 257-273, 2005.

[8] H. Kerzner, Project Management: A Systems Approach to Planning, Scheduling and

Controlling. Hoboken, NJ: John Wiley & Sons, 2003.

[9] H. Kerzner, Advanced Project Management: Best Practices on Implementation. Hoboken,

NJ: Wiley, 2003.

[10] http://www.businessballs.com/sixsigma.htm. vol. 2011.

[11] J. R. Meredith and S. J. Mantel, Project Management: A Managerial Approach, 6th ed.

Hoboken, NJ: Wiley, 2005.

[12] J. T. Marchewka, Information Technology Project Management : Providing Measurable

Organisational Value, 4th Ed ed.: John Wiley & Son, 2011.

[13] J. A. Hoffer, J. F. George, and J. S. Valacich, Modern Systems Analysis and Design, 4th

edition ed.: Prentice Hall, 2005.

[14] U. D. Gulhane, C.A.Nalawade, K.P.Sohani and V.S.Shirodkar, “Six Sigma Implementation

Model for File Manufacturing Industry”, International Journal of Mechanical Engineering &

Technology (IJMET), Volume 3, Issue 2, 2012, pp. 59 - 66, ISSN Print: 0976 – 6340,

ISSN Online: 0976 – 6359.

[15] S.Manivannan and Dr.S.Balasubramanian, “Software Process and Product Quality Assurance

in IT Organizations”, International Journal of Computer Engineering & Technology (IJCET),

Volume 1, Issue 1, 2010, pp. 147 - 157, ISSN Print: 0976 – 6367, ISSN Online: 0976 – 6375.

Six sigma implementation in it software product industry – a case study

Business

Transcript of Six sigma implementation in it software product industry – a case study