Continuous Improvement

I just spent the last week attending the ACUTA conference in Orlando, Florida. Not only did I have a wonderful time, I met a number of amazing people and plan on keeping in touch. As a bonus, the facilities had me thinking about future vacations and I think I’ll be checking out the Hilton Bonnet Creek for a visit to the mouse within the next five years. My boy needs to get a few years under his belt to truly appreciate a day in Walt Disney World.

While there I attended a number of lectures and there were some wonderful speakers. Before leaving for the conference, I was thinking about the phrase “continuous improvement.” Honestly, I tend to be rather cynical concerning new management buzzwords. ISO 9001 came and went without much effect on the rank and file I manage. ITIL is now making the rounds around my office and I wonder how much of the core philosophy we will truly embrace. Continuous Improvement is one of the newer phrases I’ve heard repeated around my upper management. I find the idea appealing.

As a creature of habit, I find it very easy to fall into a rut of just “doing my job.” Day in and day out my team has a number of tasks that need to be accomplished. I make that easier for them either by arranging training, smoothing over political difficulties, or coordinating their activities to respond to upper management. That’s my job. But, focusing on the job does not give much opportunity for continuous improvement.

At the conference, I was attending a panel of past ACUTA presidents and I heard something that stuck with me. I would like to properly credit the speaker but I don’t recall panel member was speaking. He advised that when working, we should be constantly seeking out the problems and coming up with solutions. If we aren’t doing that, our jobs can be outsourced.

There is an implied threat in that statement but also an opportunity that I think does a great job of defining what continuous improvement means. Working within an organization provides an unparalleled opportunity to truly understand the needs of a customer base. An IT department that truly understands their customers, whether they be professors, students, doctors, or plumbers, has a chance to not only respond to customer requests but to anticipate them with a level of accuracy that cannot be matched by an outside agency. By working within the organization, we can identify the problems and provide the solutions. This means going beyond our job descriptions and beyond our direct managers and embracing that our jobs mean to serve our customers, whoever they might be.

At the conference, one of the most common questions is “What do you do?” We all work in IT/Telecom but we all know that means different things to different people. I found myself always giving a two part answer.

I manage a team that centralizes network support for local building networks – my job.

I invented our documentation/labeling scheme for networks and constantly tweak our systems management and Pinnacle database for error correction – what I do.

The first line is a good summary of my job description. I show up day after day and make sure that our new network deployments go smoothly. Sometimes, like all IT workers, I show up after hours and replace critical systems so users don’t experience the downtime associated with maintenance. I train staff and attend meetings to keep projects going smoothly.

But, that second line is where I make a difference.

Over the past ten years we have identified and solved problems that no one knew existed. By constantly improving our documentation, we have raised the bar, both for our own performance and for our customer’s expectations. I will never forget the day one of our core engineers (switch and router jockeys) publicly complained that the jumpers plugged into his router were not labeled. Some of my staff were understandably defensive. I loved it. Just one year prior, he wouldn’t have considered that a failure at all. With one very loud complaint, he publicly validated the utility of a process he disdained just one year earlier.

Each step along the way of refining our documentation methods we have identified problems and solved them. We have looked at what many consider “the cost of doing business” with an eye to what we can do to remove those barriers. This is something we can do as members of an organization that would be problematic for an outside agency. Along the way, we’ve created a system that truly sings.

This year we’re turning our attention to our Outside Plant cabling system. By the end of the year I expect we’ll have an accounting of our outside spaces and pathways that will let us document the conduit path of newly installed OSP cabling. Installation of our OSP cabling has been outsourced for years. UF personnel are leading up this documentation project.

In identifying and solving problems that are less evident to outside agencies, we have found our own path to continuous improvement.

I have to admit, I’m a bit less skeptical of this latest buzzword.

Joys of Data Entry

There are times that I feel I am at my most creative when I work alone.

When I work alone, I am not bound by other's past failures. When I am cheerful, I don’t realize how monumental a task I have broached. When I cannot build on the work of those that came before me, I am not hindered by their missteps. And there are conventions in Telecommunications industry of which I am completely ignorant.

A few years ago, when we first started documenting the physical infrastructure of the University of Florida there were only a few student laborers and myself. I don’t think any of us truly appreciated the breadth of the task we were undertaking. In the beginning, we were only tasked with documenting OSP fiber cables. Now, piece by piece, the breadth of that project has grown to encompass every physical aspect of the UF building networks. We have grown as well. From a group of student laborers and me, we have grown to include over 20 full time staff members.

In the beginning, each individual staff member held complete responsibility for documenting their own work. Any one person that deployed a new circuit held responsibility for documenting every component of that circuit. With only four staff members, we clearly could not hand off our documentation to any other group. In addition, by deploying a new labeling standard we were in a position where no one else could understand the significance of the labels we were creating. No one person was expected to be an expert but each staff member was expected to be able to navigate a plethora of systems managed by other groups. By documenting the physical cabling infrastructure we interfaced with our networking core group, our facilities group, all local IT support personnel, and UF’s physical plant division.

As VoIP began to take hold on our campus, we experienced the now common struggle of integrating our telecom staff with our networking groups. I am sad to say that over time, the majority of our telecom staff has been let go. But, as the few that are left have been brought into the fold, there is an interesting idea taking hold.

A number of us that grew out of the telecom industry are asserting that we could increase productivity by removing data entry and documentation responsibility from the field technicians and move it into the hands of data entry specialists. The idea has some merit. Data entry specialists can be expected to know the ins and outs of our documentation systems and should have an easier time sorting out system problems. This would free up our network technicians to focus on solving network problems and focus on delivering new network services. If we had more staff to begin with, we may have gone this same route.

Our own core networking group has student staff dedicated to updating their logical diagrams and router documentation. But, we didn’t, and I’m glad.

I am certain that the separation between those that do the work, those that update the documentation, and those that use the documentation does irreparable harm.

For our core group, logical diagrams are often out of date. An engineer that does work may forget to hand off the documentation work. The doc team, for all of their good intentions, has no follow up capability because they don’t know what each member of the core group is doing. The most reliable documentation they maintain is based on dynamic querying of the devices that they manage.

For our telecom group, this means that a technician hands off notes from a work order to a customer service rep to enter into their billing system. The CSR enters what they are given but have no true understanding of activity in the field. Where there is confusion between the technician and service rep, the technician must be available to clear up the problem. In a situation where they must call back a technician to explain, the department then has to account for those hours since each technician’s hours must be billable.



So, a documentation specialist calls a technician/engineer for clarification.

The technician/engineer is not responsible for documentation so they delay in answering questions.

This rewards the service rep for “figuring” it out.

This corrupts the documentation.

The documentation then has no value for the field technician.

The field technician does not document their work.

And the cycle goes on, and on.



Our staff who spent time working in telecommunications lament the days where others performed data entry and documentation. In their minds, the older system worked. Their tasks were simpler, and they weren’t hounded for documentation mistakes. Where before they handed folders off to data entry specialists they are now expected to document their own work and account for any errors they create in the system. The transparent nature of this model makes it appear less credible than its telecommunication predecessor.

Our current system constantly checks itself for documentation errors. Those errors are assigned as work orders and corrected. Current error counts are public record and currently stand at .47% of our total record count of 50,000 records. But, the old system never reported errors because it had no method for discovering them. Therefore, it was perfect.

The paradigm shift from specialized data entry staff to distributed data entry can be difficult for staff. Any change can be difficult. There are those here that still bemoan the expense of labeling a cable. But, for our application, holding individual technicians responsible for their own documentation has paid dividends over and over again. Not only can individual technicians document their own work, they invest the documentation with value through their own use.

Unused documentation is not worth having.