Small companies (say, those with fewer than 500 people) are prime candidates for a new model of IT help desk. The model I'm about to propose to you doesn't require fancy management reporting tools or a sizable IT staff. In my case, it relies on contingent staffing, well-chosen outsourcing, a network of friends and a couple of spreadsheets made publicly available within the company.
Where It All Began
Some 20 years ago I read an article titled, "If you are comfortable, you are in trouble." Even though the actual text has long been lost, the article ended up being life-changing for me. It talked about change and competitive edge. The author wrote of redefining one's scope or view on everything. This article shares a new vision of the IT help desk in the small enterprise. In the course of developing my thinking on the topic — over years of practice — I've had to discard some of my beliefs about IT service.
Reinventing yourself in the workplace can be as easy as stepping up to the task and changing the way you communicate within your global network.
What you do — and don't do — is seen by everyone. This is one of your most powerful tools, both in terms of real IT change and reinventing yourself as a leader. Don't waste it. Bring everyone — management, users and IT staff — in and make them part of the process. The key to this model is essentially a project exposure and tracking process that I call "visual reporting." I generally use two documents that comprise the visual reporting process.
Every major project, undertaking or substantial problem is compiled in one document and placed on the network where it's visible for everyone to see. Let's call this List One. This is the formal enterprise wide tracking and notification document, and it tracks dollars. The goal with List One isn't to track steps but to provide a snapshot in time.
Pick a friendly name for List One. I personally like the words "project," "development," and "mission." I try to stay clear of words like "job," "task" or "assignment." Those reflect historic IT thinking (and sound like a lot of work involving little, unimportant tasks).
I add notes to the right of each line item giving its status. Items that may not start for weeks or months should have proposed start dates. Leave nothing unanswered. (Otherwise, you'll catch the readers' attention and they'll ask questions of the sort that can continually put it into an approval holding pattern.)
If there are dollars required but not approved, I place that amount to the left of the item name and make that particular column available to the management team only. This can be accomplished using an Excel worksheet. Simply hide the costs column and password-protect the worksheet.
I also track constraints with expected solutions. If there's a problem with a project, I record the problem on this document. The larger the project in dollars, time, profits or the like, the more data and entries should be recorded.
When any project is finished, it's removed from this document.
In its use, the list must have flexibility so that the support team can focus on achieving its priorities while also keeping the users fully operational. (Ask any manager if he or she can place a higher priority on project deadlines over that of a broken phone system or a downed email server, and the project will usually take second place.) This system is designed with that reality.
Here's a small portion of my List One. I don't list finished dates in List One. Instead I track the current state.
Example of List One
Physical Therapy office area. (3 drops) — finished
MRI Nurse Station. (4 drops) — finished
Computer room (25 pair cable) – finished
2nd floor New Dictation station (4 drops) — proposed — waiting approval
3rd floor medical records room (8 drops) — proposed — waiting approval
LL receiving / mail room (2 drops) — proposed — waiting approval
Snap Server — Historic patient records — Installed — ready for service
Biscom Server — network fax solution — Installed – waiting for training
RIO/Exabyte – Backup and Restoration — in process
2nd floor Dictation station — in process — wiring quote requested
2nd floor Physicians office — in process
When I explain to managers the value List One gives the organization, I tend to use the analogy of making the jump from financial accounting to managerial accounting. We can take historic data and forecast with reasonable accuracy where we think we'll be next year, while still realizing that there are factors outside of our control and that we'll need to make mid-year corrections.
As an IT manager, I also procure a substantial amount of outsourcing services. The second document, List Two, can be used for tracking outsourced items — from contracts and SLAs to software change requests and support calls. I currently call it, "Application Issue Log." It's generally application-based and I use it for more detail than the List One snapshot.
Example of List Two
Relocate record storage from old site
Med list update
Configure new/updated Med list — link to Lab
Update with Dr Paul
Document routing to patient record — held in queue
Record tag corrected
Other tracked items might be:
- Service provider technical staff names
- Phone numbers
- Fax numbers
- Ticket numbers
The management team generally isn't interested in this information, but my visual reporting model exposes the entire IT process to the enterprise. We use a network share drive "deptshare," which is the company repository for shared documentation. I'm sure that most people within the company don't care about many of the almost 4,000 documents available online in this folder, but the data is available if they have an interest. This exposure keeps me from having to gather and interpret data in one-off requests and — even more importantly — generating reports.
All of my in-house direct report staff is outsourced to me via contract. They support my IT needs exactly like a direct hire except that I get 52-week coverage. I have two full-time staff members (contracted direct reports) working out of my offices.
Because my support team doesn't spend time (or dollars) tracking what I call common user support calls, the team has more time to work on the top items on List One. However, I do track the top one or two calls per day that take the support staff away from List One. I look for trends like training or pending equipment failure. These are common management functions that aren't reported. When training, application or hardware calls occur more frequently than I would expect, they get prioritized and possibly added to List One or Two.
From time to time we'll want to implement a project that requires a special skill set. In those situations, we put together a statement of work (SOW) for that service, which generally includes both the system and the install team.
I've developed great vendor working relations and have both verbal and written PO processes in place. I use a select small set of vendors for most quotes. I also have built and maintained a network of friends over the past 15 years. As each of us changes environments, we talk about what works and what doesn't. This helps cut the learning curve for new project development.
As projects crank up, I request written quotes and post the dollar amounts to List One. As projects move up the list, those with "change power" over dollars and timelines move into the spotlight for cost and timing discussions. Reprioritization goes on constantly.
Using fundamental financial and managerial accounting information, I build and present a case for "special" projects that require rapid deployment without major disruption to the schedule. I call this "deployment shifting." An example of a special project might occur when a previously nonexistent project is placed at the top of List One because a business principal saw some system implementation and wants one. Generally, the sell is easy. Protecting the currently budgeted projects (dollars) by justifying the budget overrun is the challenge. Another example is when a simple concept grows into a costly project and takes on a life of its own. Of course, a special case could be made to terminate a project based on its value, cost or timing. This works both ways.
Speeding Up Help
For user solutions, my team maintains preconfigured computers on the shelf and generally exchanges systems rather than spend time fixing them at the user's location. With a library of standard system images, popping off the cover and re-imaging the hard drive is a quick fix for many system failures.
My purchasing process is Just in Time (JIT). As you probably know, this means it happens as something is needed. Project timing and funding allocations are JIT as well, and user support is JIT. This is where planning comes into play. If you don't plan for a failed computer, network switch failure or power failure, you're stuck in reaction mode, and that costs money. You may be asking, isn't JIT being reactionary? No. Reactionary is backward thinking. JIT, implemented correctly, is activist (forward thinking). Plan to have quotes approved beforehand and in queue waiting for submission. If there's a computer scheduled for replacement in September, quote it in June, approval in early July, order in mid July, set it up in August, queue for installation. Don't make something as simple as PC deployment a problem. (If the schedule gets tight, I pull one of those preconfigured computers off the shelf.)
Three years ago I deployed a round 90 new desktops at a company where I worked. Working with distributor CDW, I ordered 90 systems — with 10 systems shipped every four business days. The systems came in, two pallets at a time, just like clockwork. This was JIT at its finest. There was no technical reason to have all of the systems come in at the same time.
Help Desk by Walking Around
Management by walking around is the final tool I'll share with you. I've used it for about 15 years and love it. My support team also manages the workload by walking around. With List One posted, the user community has access to project status and what "bug fixes" are being worked on. This eliminates lots of questions. With support people making several passes through the building every day, they can fix small problems that might otherwise be called into a help desk. This cuts down on support team interruptions and gives the team some power over when they take a break for List One work.
(And if interruptions are interrupted, it's time for me — the IT manager — to spend time with users. If they're hungry for support, it's the IT manager's job to come in and figure out why. If need be, priorities are once again adjusted.)