Six Sigma Project

© Copyright 2011 Tata Communications Ltd. All rights reserved. (Enter information) Topic | Title

Six Sigma Project for Cost Reduction/Process Improvement

for IP Provisioning


Tollgate Review DatesRoles and Responsibilities

Tollgate Date Signoff

Define

Measur

e

Analyze

Improv

e

Control

01-Feb-2016 02-Feb-2016

07-Feb-2016 09-Feb-2016

18-Feb-2016 20-Feb-2016

29-Feb-2016 29-Feb-2016

11-Mar-2016 16-Mar-2016

Team Vaibhav Agrawal, Ananya Shukla,Abhishek Gharge,Aliya Shaikh

Process/Project coordinator

Abhishek Gharge

Process Owner Vaibhav Agrawal

Black Belt /Process Champion from TCS/Coach

-

Sponsor Kuldeep Jain

Stakeholders & Milestones


To investigate and to reduce the cost of the project by 10-15% (approx 1.5 to 2 lakhs for the current project) by using SIX Sigma.

Scope

Area of work is restricted to IP Address and no other inventory. It includes both Private & Public IP allocation. It will be done both for V4 & V6.

Work will be done only in module of IP Address allocation which is part of various inventory project Current network deployment supported within IMS system (Cramer)

Scope Exclusions Inventory other than IP AddressBusiness processes or network implementations

Objectives

3


Goal is to reduce the cost of the IT project and to make the IP Allocation Rule Engine more efficient and the target is to achieve this using Six Sigma.

Hard Dollar Savings150000 to 200000 for this IT project (Cost savings will continue henceforth for all projects in future)

Other BenefitsApart from the cost reduction, we will be using less human resource and human efforts plus the completion of the project will take less time.

Project Goal

4


Define


After the brainstorming session within the team, the main factors that identified for increased efforts towards new developments/modification in IP Rule engine are:• Dynamic business and network in TCL• Changing requirements after shared with IT• Software design• Software development• Software testing

We have used the Interrelationship Diagraph to find impact of these main causes and derived that the software design, thus development and thus testing are all equally complex and interdependent.Further, as this engine allocates IP Address to customer which is an integral part of all the Layer-3 services being offered by TCL, we see a substantial opportunity in this area and thus have decided to use Six Sigma to achieve the goal.

We have estimated a cost saving of around 1.5 to 2 lakhs INR in an ongoing project which is around this engine. Also the benefits will continue for the upcoming projects around this module.

The plan is to complete the MEASURE phase and confirm whether the steps/factors that we have listed in define phase are valid and correct to progress.

Define in a nutshell

6


Interrelationship Diagraph

7

© Copyright 2011 Tata Communications Ltd. All rights reserved. 8

DMAIC: MeasureIP Rule Engine


There are various ways to approach effort estimation. On a very broad level, below are the categories:

Expert estimation: The quantification step, i.e. the step where the estimates (effort) are derived based on domain/technical expertise and prior project experiences. This also has gut element attached to it.

Formal estimation model: This quantification step is based on mechanical processes, for e.g. use of a formula derived from historical data

Combination-based estimation: This quantification step is based on a combination of judgmental and mechanical estimates.

Methods/Approaches for Effort Estimation:

9


“Best Approach”: Differences in estimation accuracy of different estimation approaches and models suggest that there is no best method per se. Relative accuracy of one approach in comparison to another depends strongly on the context.

Expert estimation is on normally as accurate as some model-based effort estimation technique. In certain situations or business cases, where relationships between parameters and parameters used in the model

are not present, expert estimation is most suitable.

Formal estimation models are not tailor-made for any particular company demands or models, and thus may not fit every time.

Also can be a case where a defined estimation model is perfectly suitable for a project and specially as the experts estimates are perhaps subjective.

In forecasting domains - the most robust finding, is that combination of estimates from independent sources, preferable applying different approaches, will on average improve the estimation accuracy.

We have also considered other factors such as ease of understanding and communicating the effort derivations to business, training and cost attached to usage of a specific model/tool and finally for accounting the hidden requirements in the projects.

We thus use Expert estimation approach for any project effort estimations.

Selection of suitable estimation approach:

10


We have calculated total efforts for 3 projects delivered in past. The data is represented in the above figure.

Data collection and validation

11


Case 1:

We have considered efforts which is number of days required for development. In case 1 this is 155.

From past experience, designing would need 31 days i.e. say approximately 20%.

System Integration testing phase has more effort associated. Say roughly ~30%. i.e. ~46.5 days.

In User acceptance testing we deliver the project and the user is testing the functionalities. Since one level of testing is already closed, this will ideally require lesser time. Say 10%. So, 15 days.

Next is Production Release, where we release the project in live environment for the business / client. For this we have approx. 20 days i.e. roughly 10-15%.

So, total effort is total summation i.e.~267.5

12


DMAIC: ANALYSEIP Rule Engine


A cause and effect diagram also known as the “fishbone” diagram is the best representation to showcase the Analysis phase is of this project, which in turn can help in brainstorming to identify possible causes of a problem and in sorting ideas into useful categories. A fishbone diagram is a visual way to look at cause and effect.

Approach for Analyse Phase: Fishbone Diagram

14

© Copyright 2011 Tata Communications Ltd. All rights reserved. (Enter information) Topic | Title 15

Cause-Effect Analysis for high development cost:


Problem statement: High Development CostMajor categories of causes of the problem: Skill, Dynamic Business, TAT, Risk Aversion

The below causes adds to the high IT development cost:

1. SKILL : When a new system is being introduced, a skilled/Trained professional, domain experts etc. are required which added to the high development cost.

2. Dynamic Business: In a dynamic industry like Telecom, new product launches are very frequent and which further has various variants coming into picture. This leads to continuous changes in the IT SYSTEM architecture. Thus impacts the modularity and design of IT code base.

3. TAT Pressure ( Turnaround time for a service): There are various small fixtures/developments which may take a small amount of IT development time and thus needs to be taken up on high priority. Thus, there are mostly done without understanding an E2E impact. Many such frequent additions ultimately may break the code design, its modularity and may end up containing lots of redundancy. Thus further new addition makes it more complex and increases the cost of development.

4. Risk aversion: A normal development tendency is to create a new code base for incorporating a new feature. This is to avoid an undue risks on the running piece. This again breaks modularity and redundancy creeps in.

16

Fishbone Diagram - Elaborated


DMAIC: IMPROVEIP Rule Engine


• Post ANALYSE phase, we have identified various factors which finally lead to cost of development for a new project or modification in existing rules of IP Rule engine.

• Using DOE, we have categorized these factors into controllable and Uncontrollable input factors.

Controllable input factors are the input variables that can be modified in an experiment or process. It is these factors were MAJOR concentration will be in IMPROVE phase.

Uncontrollable input factors are those parameters that cannot be changed and controlled.

Responses also called as output measures, are the elements of the process outcome that gage the desired effect.

DOE to determine KPIV:

18


DOE to determine KPIV contd..

19

IP Allocation Rule

Design Modularity Code Tuning

Hidden requirements Dynamic Business needs

Reduced design and development efforts

Reduced testing efforts


Modified the code base and made it more modular based of logical functional blocks

Replaced traditional methods of implementation with OOB available product features

Fine tuned code:Fine tune logic of expected IP count Vs Actual IP count. This

particular block is very complicated and thus makes new logic changes and new development very difficult from design and development perspective.

Code refining will be done using new Work order functionality and removing this old implementation.This has resulted in removal of ~500 Lines of code and complex IF… ELSE conditions.

With this implementation, even the testing effort has come down drastically.

Steps Implemented:

20


The estimated effort vs Actual effort for the ongoing project was reviewed.

With this implementation, the actual efforts were reduced by count of approximately 35-40 Man days.

Due this effort/cost saving, actual development team was able to take up additional required without any cost implications.

So in effort brought a saving of ~ 1.5 L INR or delivery of addition business needs without any extra costs.

Evaluation:

21


Visit tatacommunications.com

Thank You

http://www.tatacommunications.com/

Six Sigma Project

Documents