Updates from November, 2010 Toggle Comment Threads | Keyboard Shortcuts

  • support 3:19 am on November 29, 2010 Permalink | Reply
    Tags: , , , , TL project planning   

    Planning Your Quality Management System (QMS) Implementation: New Series 

    We hope you had a great Thanksgiving holiday!  At the request of several clients and support desk subscribers, we’re beginning a new series on TL 9000 QMS project planning.  Planning a QMS implementation can be a daunting task, especially if you don’t have much experience in project planning.  So after you recover from panic mode, you may be looking for some basics to help you along.  In this new series, we will dedicate several articles to “tips” for planning a QMS project.  So let’s begin!

    First, you need to know what the major milestones are and when they must be completed.  Without them, your plan will either be late or will fail.  Every project has them.  For instance, if I plan to go to Hawaii in June of 2011, I need to make plane reservations (by a certain date) or I’m not going.   That’s an example of a major milestone!

    Next, I use a technique called “backward planning.”  I start at the end and plan to the project’s beginning.  This is because things normally need to happen in sequence and some milestones have to happen before others–to make the plan complete on time.  To illustrate this, let’s return to the Hawaii travel plan.  I need to make reservations far enough ahead so that I can get them at a reasonable cost. This is where the interval becomes important.  Furthermore, I know there are 5 people going, so before I can make plane reservations I need to reach out and firm up all 5 schedules.  This scheduling activity becomes a major milestone that has to occur before “booking reservations” and with a healthy interval in between!  Both of these intervals work against the trip taking place on time and both milestones need to be done in the proper sequence.  Get the idea?

    A QMS plan is no different.  There are “drop dead” milestones that if not completed on time, will become “show stoppers.”  Work to identify these from the plan end date–to the present and plug them in.  I can help you identify many of these for the QMS, but it is likely that you will have some others based on barriers you need to overcome and so forth. Also, remember that we’re talking about major milestones.  There will be multiple others in between.  Here are some of the common major milestones in a QMS plan, working backward from the completion date:

    •    Completion and certification
    •    Registrar audit
    •    Management review
    •    Internal audit of your QMS
    •    Measurements reporting (TL 9000)
    •    Documents complete and released
    •    Conduct initial project plan meeting

    In our next article we’ll flesh out some of these milestones and the recommended intervals in between them, working with the “backward planning” technique.  If you need immediate assistance please contact bclancy@bizphyx.com

  • support 1:38 am on November 22, 2010 Permalink | Reply
    Tags: Accessing Performance Data Reports, , PDRs, , , tl9000.org   

    Accessing Performance Data Reports: Have You Set Up The Correct Permissions? 

    Are you having trouble accessing information after you log into the TL 9000 web site?  It might be as simple as setting up the correct permissions.  A colleague’s firm recently joined QuEST Forum in order to view TL 9000 PDR’s (Performance Data Reports), but could not access them.  My colleague then tried to view the PDRs to see the trended data.  He was unable to see the data.  As it turns out, even though his firm became a member, he needed to log in and set permission for himself to view the information.

    QuEST Forum’s portal information strategy involves setting up various permissions on the web site to prevent unauthorized persons from gaining access to your company account and other information gateways.  If you’re having trouble viewing data, one of the first things you should do is check your user profile.  To do this, simply go to tl9000.org and log in.  Click on “manage user permissions”.  Choose the user and click on “edit permissions”.  Check the box that says “View TL 9000 Performance Data Reports”.

    As the primary administrator, you may set permissions for yourself and others in the company.  As a secondary user, you will need to contact the primary administrator of your company and request permission for activities such as viewing PDRs.  If you don’t know who your primary administrator is, you may search for the name at tl9000.org. Put your cursor on the TL 9000 Registration tab, then on Certified Registrations.  You will see a screen where you can search for your company.  When you find your company name, click on it.  The information will be listed.  This post should help you access information on the TL 9000 website.  If you require further assistance, contact bclancy@bizphyx.com.  As TL 9000 experts, our consultants are always available to answer questions about the TL 9000 standard and QuEST Forum.  Next week, we begin a highly requested series on “project planning”.

  • support 2:19 am on September 6, 2010 Permalink | Reply
    Tags: , DSR Advisories, , , ,   

    TL 9000 Measurements: DSR Advisories 

    As we continue the discussion on recent measurement changes, there are some changes that do not necessarily accompany the Release 4.5 Measurements Handbook , but are important to know.  One such change is the introduction of advisories on the DSR (Data Submission Report) that QuEST Forum emails to users of the Measurements Repository System, to confirm that measurements data has been received.  The DSR contains useful information including the submission date, which helps the auditor and your management determine whether or not the data was submitted timely.

    At the bottom of the DSR, you will see a notation called Advisory Message(s).  There may be one or more advisories listed along with an explanation as to what they mean.  This is due to the fact that QuEST Forum has upgraded their measurements repository algorithms to look for anomalies in your data submission.  There are thirteen such advisories.  You can find the list and guidance on the TL 9000 website under alerts and news/data submissions.  Advisories are designed to tell you that something odd was noticed in the data. Here is an example message: “NPR1 >>>>> Advisory #1 – the calculated Measurement over the smoothed period is perfect.” This doesn’t mean that something is necessarily wrong with the data, but it looks odd since the measure has been perfect (i.e. no problem reports) over the period monitored.

    What does this mean to you?  As a certified organization you are required to analyze the data and determine if it was wrong.  If there is no issue, no action is required.  If the data is wrong, you are required to resubmit it.  More importantly, you will be required to demonstrate conformance with this requirement.  Therefore, you should use a text or word document to record that you investigated the data in question and that there was nothing wrong, or record what was wrong and what corrective action was taken.  This should answer any questions you have regarding DSR Advisories.   If you require further information or upgrade support, contact bclancy@bizphyx.com.

  • support 1:42 am on August 23, 2010 Permalink | Reply
    Tags: , Fixed Response Time, , , , , TL 9000 Measurements Handbook R4.5,   

    TL 9000 Measurements R4.5: Treatment of FRT-Fixed Response Time 

    This week, we are addressing the changes to FRT in Release 4.5 of the TL 9000 Measurements Handbook.  As you may know, the TL 9000 Measurement FRT is a common measurement reported by all certifying organizations.  FRT stands for Fix Response Time.  The idea behind FRT is to measure the organization’s overall responsiveness to customer reported problems.  These are problems reported by your direct customer.  FRT is a measurement of the interval between the time an organization receives a customer problem report and the time a fix is delivered and accepted by the customer.  This measure allows organizations to benchmark their responsiveness to customer problems and to improve their fix delivery performance against industry standards.

    For companies in categories 1-6, the thresholds for fix intervals are 30 days for major problem reports and 180 days for minor problem reports.  For organizations in categories 7 and 8, fix response time intervals can be negotiated through service level agreements with your customer and become what you and your customer agree they should be. In the absence of service level agreements to define fix intervals you can document and perform to your own intervals.

    Since categories 7 and 8 only report one problem report measure, you can have a single FRT interval instead of intervals for major and minor problem reports.  This is only true if none of your customers prevent you from doing it by specifying fix response time intervals through contractual agreements.

    Note that these intervals have changed in release 4.5 of the Measurements Handbook for Product Category 9, End Customer Services.  The new intervals have been provided by consensus of the membership to be more realistic for this type of service and will be 2 working days for major problem reports and 5 working days for minor problem reports, beginning with R4.5 of the Measurements Handbook.

    Also note that there is no fix response time interval for critical problem reports because QuEST Forum member companies assume that by definition, critical problems are worked on until they are resolved.  We hope this post helped clarify aspects of Fixed Response Time.  If you require further information or upgrade support, contact bclancy@bizphyx.com.  Tune in next week, as we discuss DSR (Data Submission Report) Advisories.

    • Leticia Hernandez 8:25 am on August 23, 2010 Permalink

      I actually have a question about 7.3.1.C.6 Estimation but didn’t know how to begin a new topic. Can you provide an explanation of this new clause? What type of document/record could we show as evidence that it’s being met?

  • support 3:01 pm on August 4, 2010 Permalink | Reply
    Tags: , , , , , ,   

    TL 9000 Measurements R4.5: SSO Product Categories and The Net Effect 

    Last week we began a new series on the TL 9000 Measurements Handbook Release 4.5.  As discussed, in Release 4.5  EIO has been replaced by the broader measurement called SSO or “Support Service Caused Outage Measurement”.  This change is intended to ensure that the measurement can be applied to more than just Installation or Engineering organizations.

    SSO now applies to the following 9 product categories: 7.1.1 Installation, 7.1.2 Provisioning, 7.1.3 Construction, Fixed Network Engineering Services, Mobile Network Engineering Services, 7.3.1 Network Field Maintenance, 7.3.2 Network Operations Center, 7.3.3 Network Support Services, and 7.5 Customer Support Services. Here is the net effect beginning with the use of Release 4.5:

    Certified or Certifying Organizations currently in Categories 7.1.1 Installation and/of 7.2.1 Engineering

    1. You will continue to report the same numbers for Installation and Engineering Caused outages.

    2. You will need to change any references to EIO in your local documentation to SSO.

    3. You will need to change any references to Neo and Nio, (current data points) to Nso (number of Support Service Caused Outage) and any reference to Ne and Ni to Ns (number of normalization units)

    Other certifying organizations in the product categories listed above:

    You will need to begin reporting outage data based on product category table A-2 beginning July 2011.  The table will give you the required normalization unit to use for Nso.

    There are several significant changes with R4.5.  We hope this post helped clarify the movement from EIO to SSO.  If you require further information or upgrade support, contact bclancy@bizphyx.com.  Next week, we discuss other changes with R4.5.

  • support 1:11 pm on July 26, 2010 Permalink | Reply
    Tags: , EIO, Measurements Handbook, , , ,   

    TL 9000 Measurements Handbook Release 4.5 Series Begins: EIO Is Now SSO 

    This month we begin a new series for users of the TL 9000 Quality Management System.  Many of you may know that release 4.5 of the TL 9000 Quality Management System Measurements Handbook was approved by member vote in 2010.  Release 4.5 can be used for all data submissions to QuEST Forum beginning with January of 2011. Certified organizations are required to use Release 4.5 beginning with July of 2011.  With Release 4.5 there are many clarifications and several significant changes.  Over the next month we will be addressing many of these changes.  This week we are focusing on changes to the category known as EIO” or “Installation or Engineering Caused Outage Measurement”.

    Among the several outage measurements that are being reported by applicable organizations is a category known as EIO (Installation or Engineering Caused Outage Measurement).  This measurement was intended to provide insight into the impact of Installation and Engineering activities on network elements in the field.  It only applied to two product categories, Installation, 7.1.1 and Engineering, 7.2.1.  Release 4.5 changes all that.

    EIO has been replaced by a broader measurement called “SSO” or “Support Service Caused Outage Measurement”.  Member companies realized that the measure as it stood was too narrow and did not apply to other appropriate certified organizations.  Therefore, the measurement was broadened and with Release 4.5 it will apply to 9 product categories.  Next week, grab a pen and paper as we outline these 9 categories and the net effect of the changes with Release 4.5.  Until then, if you need immediate assistance with upgrades please contact bclancy@bizphyx.com.

  • support 11:35 am on July 19, 2010 Permalink | Reply  

    Corrective and Preventive Actions: Wrap Up 

    For the past few weeks we have been discussing the keys to an effective corrective action system including the three elements of every corrective action: correcting the defect, analyzing why the defect occurred (a.k.a. root cause analysis) and preventing future recurrences of the defect.  Let’s wrap up this topic thread by discussing another frequently asked question.  Should I close a corrective action first or verify, then close? You can close the corrective action when you fix the defect, thus meeting a timely interval for taking action to fix that particular defect.  However, it remains to be seen whether the root cause has been found and solved.  The analysis of the defect’s root cause and preventing recurrence may take longer, so don’t log verification of the corrective action until you are sure your action plan has been effective.

    Let’s go back to our original example of the flat tire.  Recall that we had a flat tire (defect) and an analysis found the root cause to be the mall parking lot was full of nails.  Our analysis led us to contact mall management to ensure that the root cause was cleaned up.  Our corrective action was closed when the defect was fixed.  However, we aren’t going to log it as verified until we have confirmed that the root cause has been eliminated, i.e. there are no nails in the lot.  We can inspect the lot, we can hire a third party to inspect and report, or we can contact management to see if they have removed the nails.  Any of these are OK, but in this instance inspection is probably the best verification.

    Why do all this? We don’t want to get back in the car and have a flat tire again if we can avoid it.  Again, one of the key elements of an effective corrective action system is not just correcting things after they happen, but preventing them from happening again when we already know about them!  This quality management topic was presented by Bob Clancy, SVP of BIZPHYX.   For further information, please contact him directly: bclancy@bizphyx.com

Compose new post
Next post/Next comment
Previous post/Previous comment
Show/Hide comments
Go to top
Go to login
Show/Hide help
shift + esc