White Papers.

The posted White Papers provide state of the art topic-related industry overviews with regard to positioning of some of our products and services.

Expert MS: Turning Resolutions into Solutions

OUR VALUES:
VISION
INTEGRITY
PRODUCTIVITY
CHOICE
 
 
 

Telecom Performance Metrics and Six Sigma.

Synopsis. The quality levels at the telecommunications industry are fairly low as it presently considers 5 errors/hundred an acceptable quality standard. At the same time, other modern process-oriented industries are targeting and achieving 5 – 6 errors/million opportunities as an operating standard. Telecommunications Metrics (telecom metrics) and Six Sigma can improve the situation dramatically. Let us think about it and see why we need this and how it works.

Telecom metrics presently measure seven (7) families of concentration:

1.         Pre-order

2.         Order

3.         Provisioning

4.         Maintenance and Repair

5.         Billing

6.         Network

7.         General

Telecom metrics are generally organized into two tiers: 

Tier I. Carrier to Carrier Guidelines:

1.            These metrics may or may not have actual standards set

2.            These metrics may be “bright-line” i.e. have a specific performance standard and interval set and are calculated from actual data.

3.            These metrics may be “parity” based on the 1996 Telecom Act whereby the ILEC has to provide service at least equivalent to the service it provides its own customers.  The comparator is thus the ILEC’s Retail Customers.

4.            In the 14-state Verizon East region, all states but NJ copy the NY metrics with some delay and with some state specific metrics added.

5.            CLECs can replicate the “bright-line” metrics at two levels

a.    They can use the ILEC provided “Flat Files” and use a computer program (may or may not be available from the ILEC and may or may not have conditions of use).

b.    They can mine their own databases to determine actual source level data and use that in their calculations

c.      If b. is chosen, CLECs then have to reconcile between the two sets of results and possibly escalate the dispute

6.   Replicating parity metrics is more difficult because:

a.    The Retail comparator is not available to perform the permutation test normally required for pass/fail determination.

b.    The transactional source is based on data the CLECs do not obtain in the normal course of business, but have to exert extra effort to gain and convert to a usable format.

c.     The basic design of these metrics is flawed and parity is defined as one point of equality between two curves of unknown (and possibly differing) characteristics.

Tier II. Performance Assurance Plan (or Incentive Plan in some states):

Most, but not all, of these metrics are directly drawn from the Carrier-to-Carrier Guideline metrics. Some states use the NY Plan format where there are three tiers of penalties:

1.            Whole families must be failed to generate a penalty in the Mode of Entry metrics. Modes of entry are    basically product lines (UNE-P, UNE-L, DSL, etc.)

2.            Critical metrics carry their own penalties

3.            Special metrics are also distinctly examined.

4.            Penalty amounts are pre-specified and are basically all or none and are distributed proportionally to the number of lines.

1.                                                          New Jersey has a different IP setup where penalties are based on the number of failures.  There are two sub categories that combine to yield the total penalty, Frequency and Severity.

The metrics themselves tend to measure process steps and measurable events rather than true service, thus:

  • The metrics look at one side of an event i.e. timeliness or completeness

  • The issue of quality equaling an event (or deliverable) occurring at a specific time and being performed to a defined standard is ignored (and resisted by the ILEC).

The metrics standards tend to remain unchanged as ILECs resist raising standards (literally to the death) while Regulators seem to have bought the argument about the impossibility of achieving perfection.

As you could see, system Performance Metrics is about many things, including appropriate software.  It has been our experience that to ensure Performance Metrics consistent quality it is necessary to be Six Sigma-oriented from the very beginning

Six Sigma starts by examining what the customer (in this case the CLECs) defines as proper quality measurements and then engages in continuous programs of improvement.

As such, a Six Sigma approach would enable the Telecom metrics to serve as a substitute for competition. There have been many methods in the past that were designed to improve Customer Satisfaction, reduce Cycle Time, and reduce Defects. However, Six Sigma is an evolution that incorporates many of the individual features that enabled earlier methods to achieve results and integrates them into a unified approach. As an approach, Six Sigma requires total management commitment to a philosophy of excellence, customer focus, process improvement, and the rule of measurement.

Further, Six Sigma has a goal and a target structure:

  • Two Sigma is 68% defect free operations

  • Three Sigma is 93% defect free

  • Four Sigma is 99.4% defect free

  • Six Sigma is 99.9997% defect free.

 While each improvement has its own costs, these costs are offset by benefits, such as:

  • Improved quality (i.e. performing a function at a specified time to a defined standard) reduces error repair and customer service costs.

  • Improved quality makes a product more desirable in the marketplace  (e.g. the premium price and higher trade in value of Japanese import vehicles vs. American made competitors.)                                          

 Each defect also has hidden costs, for example:

  • Surveys show dissatisfied customers tell 9 to 10 people that there was a problem while satisfied customers only tell 5 people about their experience.

  • Surveys also show 31% of customers never complain to the company for a variety of reasons but 91% of these people will never again do business with the offending company.

 The major emphasis areas of Six Sigma are:

  • Focus on the customer

  • Data and fact driven management

  • Processes are the focal point for delivering value

  • Proactive management is necessary for improvement

  • Collaboration between areas is essential

  • Seek perfection but allow for failure.

To achieve results, Six Sigma uses a progressive 5-step method of problem solving (DMAIC):

 Step 1.   Define the problem:

  • What is the problem

  • Why is it important

  • What is the scope of the effort and what limitations will be placed on the resolution

  • Who are the project stakeholders and what is the expected timeframe for each stage.

 Step 2.  Measure:

  • What are the relevant processes and what are the proper statistics to measure them.

  • What sigma is the process currently at.

                              Step 3.  Analyze:

  • Use the statistics to determine the root cause.

                Step 4.  Improve:

  • Sometimes split into Improve and Implement

  • Design the solution that resolves the problem

  • Gain the signoff of the Stakeholders

  • Implement.

                               Step 5.  Control:

  • Keep measuring

  • Monitor improvement

  • Catch and correct slippage.

 Finally, the keys to Six Sigma improvements, in Telecom as well as in other industries, are:

  1. Senior management commitment

  2. Experienced project/program management

  3. Properly defined and scoped projects with appropriate resources

  4. Proper and effective use of measurements, statistical tools and analytical procedures

  5. Employee involvement.

 In conclusion:  It is high time to achieve major, visible quality results in Telecom. The shift of paradigm in quality is  feasible only if we apply special Performance Metrics with Six Sigma-oriented approach and methodology. It pays to measure.

 

IT Project Management: A Project Manager.                                                                                         

Synopsis. As increasingly recognized in the industry, IT Project Management evolved into a special skill domain, and the role of the IT Project Manager continues to grow. A truly competent Project Manager of today is unthinkable without appropriate project-oriented software, as different in scope and design as IT projects per se. 

As a result of client surveys conducted in 1998-1999, the research department of the Massachusetts based consulting firm Darwin Partners determined that 80-85% of IT projects were less than totally successful.  Informal discussions with industry professionals indicate that this number may be low.  This is surprising given the amount of resources, planning systems and money expended on these projects. 

The IT community has life cycle development planning, project management systems, training for management personnel and management philosophies.  What is less than generally realized is that the skills, techniques and orientation required for management are different from the skills, techniques and orientation that are necessary to make an excellent developer. So in fact, IT development and IT management are two different animals.

Technical personnel have to be competent at a specialized skill set and can narrowly focus, in depth, on a system or subsystem.  Technical personnel develop in an arena that defines a project life cycle in terms of:

  • Preliminary Proposal

  • Project Plan

  • Requirements Definition

  • Alternatives Analysis

  • System Design

  • System Development

  • System Testing and Acceptance

  • System Implementation

  • Post Implementation Support

Project management personnel have to be concerned with these and other aspects of a project to the preclusion of an in depth concentration on any one factor to the exclusion of others.  Thus, project management personnel develop in an environment that is concerned with:

  • Business Goals and Objectives

  • Project Goals and Objectives

  • Project Financial Criteria (i.e. Return on Investment, Payback Period, etc.)

  • Stakeholder (senior level personnel representing all concerned business areas) Involvement

  • Creation of a Climate of Project Support

  • Corporate Politics

  • Project Timetables

  • Project Resource Consumption

  • Achievement of Goals and Objectives

  • Measurement of Progress, Achievements and Resource Consumption

Above all, the Project Manager can never become so involved with the technological aspects of the project as to lose sight of the fact that the technology only exists to solve a business goal or objective.  Thus, the Project Manager has to create and foster a project team understanding that the project exists to serve business needs and solve business problem.  The Project Manager cannot lose sight of the fact that a project is a defined activity that has both a discrete beginning and end, has specific objectives and dedicated resources and is chartered to achieve specific business related goals at a defined cost. 

Thus, the Project Manager is required to exercise a skill set as specialized as a systems developer.  Both the management and development skills are required to provide the technical-business partnership that is a prerequisite for a successful project, but a serious problem arises when personnel with one skill set are required to exercise both.  The problem is compounded when the Project Manager’s job is defined as a “Project Administrator” who is assigned to coordinate the actions of various equal organizations each of which is independently conducting a piece of the project.  In that case, there is a void in the control, direction and overall program vision. 

The modern IT Project Manager’s role may be seen as a derivative of a construction industry project manager who manages all the trades and skill crafts and is responsible for the overall project completion, but may not be the best carpenter, riveter, or mason. 

The Project Manager has to perform the managerial role of assessing the business goals and objectives that the project has to meet and then define the project goals and objectives that will accomplish that.  These project goals and objectives have to be coordinated with, and approved by the stakeholders so that they (the stakeholders) have both a sense of project ownership and a responsibility for project success.  Then, the technical requirements to meet the goals and objectives can be defined and preliminary resource cost estimates can be prepared.  These goals, objectives and costs then have to be analyzed and tested to verify the completed project will satisfy the business financial criteria and validate the project is a legitimate use of business resources. 

After the successful preliminary validation, the project technical team has to define the various available alternatives (including specific deliverable definitions) to accomplish the defined project goals.  Then the Project Manager assesses the alternatives against the project goals, objectives and financial criteria and recommends the solution that best satisfies all the business requirement, goals and objectives to the stakeholders.  This review process has to be repeated each time a significant change is required. 

After the project approach has been selected, the Project Manager has the responsibility to create an environment in which the technical personnel can efficiently operate.  The Project Manager has to ensure the adequacy of properly skilled personnel, properly capable equipment, and sufficient ancillary functions.  Further, the Project Manager has the responsibility of tracking the project’s accomplishments and achievements against the project schedule and plan.  This is one of the critical points where the Project manager’s business orientation becomes a critical element.  While the Technical Team is accomplishing the system development, the Project manager is creating the environment in which the team works, managing the external interfaces, measuring progress against interim and final goals, ensuring that deliverables meet their defined quality standards and building a “pro-project” consensus. 

This is not to imply that the Project manager should not be technically aware.  The Project Manager has to manage technical personnel; that fact necessitates a requisite degree of technical competence.  The defining criteria is that the Project Manager has to fundamentally be business oriented because the focus of the Project Manager’s job is to deliver a completed system that meets business goals and objectives.  This fact is lost on the IT organizations that combine the Technical and Project Management roles.  Over emphasis on the Project Manager’s technical competence ignores the skills differential inherent in the two roles and ignores the fact that the time spent away from technical work diminishes the level of technical currency. 

The proof of the need for strong, focused, business oriented Project Management is in the statistics.  Any system that produces a 15-20% success rate is in need of improvement and change. 

In Conclusion: IT Management software from Expert MS has two basic goals to achieve:                                   1.      To help a business-oriented Project Manager to successfully accomplish the project on time and within budget;                                                                                                  

2.      To help a Project manager maintain seamless business systems functioning while introducing enhancements on a permanent basis—to keep abreast with the innovations in the industry and always be a step ahead of the competition..

 

You are welcome to send mail to info@expertms.com with questions or comments about this web site.
Copyright © 2004 Expert MS
Last modified: 03/08/04