One tool in every IT manager’s arsenal is Total Cost of Ownership (TCO). We use it regularly to make thoughtful purchasing decisions. In my struggle to be more creative with handling my budget, I decided to revisit TCO and see if some of its concepts made sense when looking at replacing computers.
At Council Rock School District, we had long been in the cycle of replacing computers every four years. The driver behind this was that our computers were purchased via lease, which allowed us to regularly refresh our systems. Because we are a large district, we cannot possibly replace everything every year, so we broke out the process into four separate leases, on four-year cycles. That changed two years ago, when our business manager changed, and the leases went away. Computer refreshing is now part of my annual operating budget.
The challenge was to break the four-year pattern for replacing technology, and fit the replacements for not just computers, but services, switches, routers and the other infrastructure equipment into the operating budget. That challenge is what led me to revisit the TCO framework.
Basically, TCO accounts for all of the costs directly related to the ownership of an item, for as long as you have the item. Here is a quick and simple example. Let’s say you purchase a desktop computer (CPU, monitor, keyboard, and mouse) for $600. In addition to the purchase, you need to include:
■ Ordering the machine (15 minutes) $11.25
■ Configuring, unboxing, setup (30 minutes) $22.50
■ Average of four support calls the first year $270.00 ($45 per hour, 6 hours)
So your total cost of ownership the first year is really: $903.75. If you average three calls ($202.50) the second year, five calls ($337.50) in year three, and six calls ($405.00) in year four, your total cost of ownership is $1,848.75. Of course, that assumes you retire the unit at the end of four years.
How does this concept apply to refreshing computer equipment?
Once a computer is purchased, configured, and installed, it begins its slow crawl toward death. However, some computers need to be replaced sooner than others. In some cases, this is rather obvious—the computers die, the job needs change, etc. In other cases, though, the computer may be perfectly suited for the job, and could stay in place for far longer than in the past.
To help me understand this better and give me a framework I could use to explain this to others, I focused on four main areas:
■ Configuration. This takes into account the processor speed, total memory, hard drive type and speed, etc.
■ Usage. How is the machine actually being used? What applications are being launched, how often are they used, what types of resources are they using, etc.?
■ Incidents. How often has the machine had problems?
■ Politics. This one is obvious, and we know that, regardless of numbers or logic, sometimes politics trump everything else. I mention it here as a factor because no matter how strong your numbers, it’s critical that when you present your findings, you do it in a matter that works for your organization.
Once these categories were identified, I needed to determine how to apply them to each piece of equipment. Looking at the total scope of our inventory, the environment we are in, the expectations of our users, and, of course, the budget, I was able to determine a score for each machine, for each category. By adding up the scores for each category, I was able to determine a ranking for each system. This provided me with an objective criterion.
Having a solid strategy in place, the next logical step was to define each category, and determine how I was going to assign a score.
Maintaining a current and accurate inventory of all your systems can be a daunting task. As equipment gets moved into a production environment and out of your control, things can change. Hard drives can be added or replaced, memory can be upgraded, software can be installed or removed. Despite tight controls, over the course of four years the computer as it was deployed is rarely the same computer that is being replaced. Updates, patches, fixes can all contribute to these changes.
Once you’ve been able to secure a good inventory, you then need to decide what makes sense, from a scoring standpoint, for your environment. For example, does a Celeron processor rank higher or lower than an i-7? Are there situations where this is important and others where it isn’t? Location is usually the determining factor here. A computer in a drafting lab needs more horsepower than a computer in a library lab—usually. You need to determine what is more important to you, create a scale, and assign a value to each computer.
Usage has always been a hard thing to determine. If you ask the typical user, they will tell you they use their system all the time. But that isn’t what we are referring to when we talk about usage. It’s not how often the computer is used, but exactly how the computer is used.
A computer that is used constantly to surf the web would most likely have a different score than a computer that is used to create large graphic files once in a while. You need to figure out a way to determine how the system is actually being used, and assign a value based on that use. Once you decide what is important, you can create a scoring system, look at your data, and assign a value.
When an end user experiences a problem, they need help. Most organizations implement some way of taking requests for help, assigning someone to help the end user, and tracking what the issue was and what was done to resolve it. What most systems fail to track, however, is whether the problem with the computer was an actual computer problem, or a result of the end user.
You need to decide if you want to track every incident as part of your equation or not. I would recommend against this, because it strains the idea that this information is objective. If you only include incidents that are hardware- or softwarerelated, then you eliminate the perception that it is a people issue.
Regardless of the source of the incident, you need to create a scale and assign a value to each computer.
The last step in your process should be to add your scores for each machine, and then rank them based on their total score. Look again at your landscape—budget, environment (did I mention politics yet?), and needs. Using this information, determine what the cut-off score is. This will give you an objective list of what needs to be replaced—and more importantly, what you can hang on to a little longer.
Sorting Through the Data Mountain
As I began to work through this process, I quickly realized that trying to collect the data I needed, create the scores, and prepare a list would become a full-time job. I needed a way to do this that was practical, consistent, and repeatable. I found an application called Ziften that lives on the computers and reports back system performance information. Ziften collects the data and provides me with the report I need quite easily.
Whether you use a tool like Ziften or implement your own system, by revisiting the TCO formula, IT directors can stretch dollars further by replacing systems that truly need to be replaced, and extending the life of systems that can last just a little while longer.
Matthew J. Frederickson is the Director of Information Technology at Council Rock School District, ninth largest school district in Pennsylvania.