International Journal of Computer Engineering and Technology (IJCET), ISSN 0976INTERNATIONAL JOURNAL OF COMPUTER ENGINEERING & 6367(Print), ISSN

0976 6375(Online) Volume 4, Issue 4, July-August (2013), IAEME

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
IAEME

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
475

International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 6375(Online) Volume 4, Issue 4, July-August (2013), IAEME 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 companys 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 companys core activities include creation and implementation of intranet and internetbased 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 highlevel identification and integration of the case companys core processes, support processes and key customers can be summarized in Fig. 1.
Retailer
WiMAX Network Performance Analyzer K2 [blackpearl]

IT Product COR E PRO CESS ES

Construction Developer Network Service Provider

IT Service
Application Development Business Consultancy

Insurance & Financial Cosmetic & Healthcare Electrical Engineering

CUST OMER S

IT Support
Customer Support Special Support

SUPP ORT PROC ESSES

Staff

Hardware & Software

IT Infrastructure

Process

Informal QA

Finance & Strategies

Figure 1 High-Level Overview of the Case Company

476

International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 6375(Online) Volume 4, Issue 4, July-August (2013), IAEME 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]. 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 companys 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 isnt 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 companys 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 Printer Hardware Vendor Software Vendor Internet Service Provider Telco Companies Network Infrastructure Supplier Input IT Knowledgebased resources Project Schedule System Requirement Specification Software Hardware Network Internet connection Contract Process 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) Output IT Software IT Hardware IT Services IT Support IT-related Specification User Guide / Manual Customer Stakeholder Department Head / Manager IT Manager End-Users IT and non-IT SMEs Requirement Signed-off SRS Approved Project Schedule On-time Delivery Within Budget Fulfilling and Delivering user requirements Signed-off UAT

3.1

477

International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 6375(Online) Volume 4, Issue 4, July-August (2013), IAEME 3.1.2 Identify Critical-To-Quality (CTQ) Once an overview of case companys 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 1. CTQs Quality Defect Output Measures Quantity of reported bugs by severity level Numbers of days delay for a project release Percentage of changes made to baseline SRS Total time spent on project planning Input/Process Measures Total quantity of bugs reported by client after project implementation; accordance to severity level of high, medium and low impact. Discrepancies between plan and actual product/service/support delivery date. Discrepancies of user requirements between baseline and delivered product/service/support. Percentage of time spent on project planning.

2.

On-time Delivery Defects System Requirement Specification (SRS) Defects Planning Defects

3.

4.

MEASURE PHASE Software quality has been the main concern from the case companys 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.

3.2

478

International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 6375(Online) Volume 4, Issue 4, July-August (2013), IAEME Table 3 Summary of Variables By Project
Project Baseline Duration (days) 80 Actual Duration (days) 110 Planning (days/%) FTE SRS Changes (%) 40 Plan Frequency QA Testing 3 Actual Frequency QA Testing 1 Project Status Delayed (30 D), 2 FTEs Delayed (30 D), 3 FTEs OnSchedule OnSchedule Delayed (20 D), 2 FTEs Delayed (15 D), 1 FTE OnSchedule Delayed (20 D), 1 FTE

Project A Project B (Phase I) Project C Project D Project E Project F Project G Project H

8 (7.4%)

100

130

1 (0.7%)

40

10 40 80

10 40 100

2 (20%) 2 (5%) 5 (5%) 8 (22.8%) 0.25 (5%) 10 (8.3%)

2 1 2

0 5 30

3 3 3

1 1 1

20 5 100

35 5 120

1 1 1

20 0 10

3 0 3

1 0 1

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.

Changes To User Requirements (%)

40

30

20

10

0 0.0 5.0 10.0 15.0 20.0 25.0 30.0 35.0 40.0

Behind Schedule (%)

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

479

International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 6375(Online) Volume 4, Issue 4, July-August (2013), IAEME 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 5 projects was delays 100 high severity bugs Defect/Unit (DPU) DPMO DPMO 5 = x 10 8 = 625,000 DPMO 100 = x 10 129 =775,193 Sigma Level Remark Project A, B, C, D, E,F, G, H

Project Delay

Delivery Defect

Each delivery

1 per delivery

8 projects

1.181

Reported Bugs

Quality Defect

Each bug High severity

1 per bug

129 bugs

0.744

Project B

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

3.3

480

International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 6375(Online) Volume 4, Issue 4, July-August (2013), IAEME

120 Total Report Bugs

30 25 20 15 10 5 0 Project B Total Bugs Rework Project E Planing Effort

80

40

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 companys 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 Effortusing a Pareto Diagram.
481

Rework / Planning Effort (Days)

35

International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 6375(Online) Volume 4, Issue 4, July-August (2013), IAEME
100 100

75 50

75 50

25

25

0
Reported Bugs Code Walkthrough Funtional Specification System Specification SRS Changes Planning Effort

Log. (Cumulative Report Bugs)

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 projectrelated 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]. 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
482

3.4

International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 6375(Online) Volume 4, Issue 4, July-August (2013), IAEME 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 highseverity 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 companys team culture where sharing of knowledge among technical teams and support teams will further improve project health.
483

International Journal of Computer Engineering and Technology (IJCET), ISSN 09766367(Print), ISSN 0976 6375(Online) Volume 4, Issue 4, July-August (2013), IAEME 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] [2] [3] [4] K. Schwalbe, Information Technology Project Management, 6th ed. Boston, MA: Thomson Course Technology, 2009. http://www.it-cortex.com/Stat_Failure_Cause.html, "Project Failure Statistics." vol. 2013, 2013. S. Berinato, "The Secret to Software Success," 2001. 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. Q. Feng and K. C. Kapur, "New to Six Sigma? An Introduction to Six Sigma for Students and New Quality Practitioners," 2007. 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. 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. H. Kerzner, Project Management: A Systems Approach to Planning, Scheduling and Controlling. Hoboken, NJ: John Wiley & Sons, 2003. H. Kerzner, Advanced Project Management: Best Practices on Implementation. Hoboken, NJ: Wiley, 2003. http://www.businessballs.com/sixsigma.htm. vol. 2011. J. R. Meredith and S. J. Mantel, Project Management: A Managerial Approach, 6th ed. Hoboken, NJ: Wiley, 2005. J. T. Marchewka, Information Technology Project Management : Providing Measurable Organisational Value, 4th Ed ed.: John Wiley & Son, 2011. J. A. Hoffer, J. F. George, and J. S. Valacich, Modern Systems Analysis and Design, 4th edition ed.: Prentice Hall, 2005. 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. 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.
484

[5] [6]

[7]

[8] [9] [10] [11] [12] [13] [14]

[15]