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 Lee2
, Kim Yeow Tshai3
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
ChangesToUserRequirements(%)
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
= ൜
5
8
ൠ x 10଺
=
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
= ൜
100
129
ൠ x 10଺
=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
Rework/PlanningEffort(Days)
TotalReportBugs
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

More Related Content

What's hot

Viewers also liked

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

More from IAEME Publication

Recently uploaded

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