The need for new hardware seems to constantly plague IT departments. Servers fail. Our clients constantly request new functionality without any clear understanding of the underlying hardware concerns. Leases run out, forcing us into replace-or-purchase decisions. New technologies refuse to work properly with older equipment, despite the manufacturer’s warranty that everything will “play nicely together.” How do we sift through all of the conflicting data to figure out what we really need to buy?

There are as many ways to work out the answers to the above questions as there are managers forced to make these decisions. However, all of us have specific triggers that cause these decision points to appear, as well as several generic decision parameters we plug our unique situations into. By balancing the factors of the triggering event with the various parameters, we can come to some kind of understanding about what kind of new hardware we actually need to purchase.

Triggering events
We don’t generally wake up one morning and say, “Let’s go out and spend a million dollars on new desktops! That sounds like a great idea!” The need to buy new hardware, to deploy it, and to add it to the maintenance schedule comes about because some factor in the IT environment has changed. These changes come from a variety of sources, each requiring a slightly different approach to the analysis.

Common trigger events include:

  • Massive increases in hardware-related problem tickets.
  • Utilization numbers reaching a critical threshold.
  • Leases running out.
  • The installation of a new software package.
  • Regime change in the executive management.
  • The requests of specific user groups for new equipment.

The first two seem to be based on “objective” measurements. The first uses problem report trends to indicate when hardware reaches the end of its sustainable life. When we see a steady increase over a period of time (usually three to six months) in the number of problem tickets related to hardware failure, it may well be a sign that our “build” needs to be replaced. Similarly, in theory we have established hardware utilization thresholds (usually defined as processor or disk utilization numbers) that allow us to accurately predict the need for incremental upgrades.

The second two appear, on the surface, to be reactions to outside events. In the first case, the company is coming to the end of its lease duration on specific pieces of equipment. Depending on the lease structure, you may have the option to replace the items, purchase them outright, extend the lease at a substantial operating fee, or even extend the lease at the same terms. Similarly, business actors outside of the IT organization drive the installation of a software package. IT executes the work, but some other organization requested the change and eventually drove the product though.

The last two fall into what we might call a “political” category. In the first, new top-level executives enter the organization, bringing with them their preexisting set of relationships. As problems occur, they call on their old friends who helped them out in the past. Eventually this leads to some wholesale hardware revisions. In the second case, a user group requests some new hardware with a business-related purpose. These hardware requests may range from the mundane (new monitors for a group about to shift to a fully integrated imaging package) to the highly esoteric (extended wireless networking into the local Starbucks so that the creative team can have coffee meetings).

Each of these initiation events requires that we ask at least one unique question during the new hardware assessment discussion. These problems, their categories, and the requirements are listed below:



Questions to ask.
Objective Hardware tickets rising Is the hardware the cause of the problem or do the issues stem from old OS builds? Are specific components failing, or are you seeing more general system wide failure?
Objective Utilization threshold achieved Is the threshold crossing a predictable spike, a one time event, or part of a general long term trend. Are the thresholds appropriately set for your known growth rate?
Reactive Leases ending What secondary costs will the company assume under each of the lease ending conditions?
For example, if you choose to deploy new leased equipment what costs will you incur in doing so?
Reactive New software request What hardware does the new software absolutely require?
Political Regime change How will changes to the new vendor change existing support contracts? What secondary costs will the company assume during the change?
Political New functionality request What is the real business motivator behind the request? Can this business motivator be achieved in any other way?

Note that the answers to these questions are only as good as the data you gather. If you have limited utilization data, making a utilization-initiated new hardware assessment will be difficult at best.

Decision pairs
Once you have answers to the questions raised by the initiating event, you can move on to calibrating the response based on at least a couple of the following pairs:

  • Minimum against maximum response
  • Radical against incremental changes
  • Customized against standardized configurations

When we weigh a hardware purchase, we need to decide whether we’re going to meet the immediate need plus one or two years of expected growth (a minimal response) or meet the immediate need plus three to five years of expected growth (a maximum response). Minimum responses generally cost less money up front, but must be revisited more often. Maximum responses require more money up front, but generally have fewer costs over time. For example, one manufacturer was faced with a reactive hardware request because the sales force wanted to install a new customer relationship system. The company ended up purchasing extremely expensive new laptops with an expected three-year lifespan, planning on moving them out of the sales force and to the mobile office staff in the third or forth year of service. The manufacturer might have responded minimally by leasing less powerful equipment, intending to return it after the lease expired.

Similarly, we must decide whether we’re going to enact an incremental or a radical change. Incremental changes (like installing new memory) can cause unintended side effects while extending the useful life of existing equipment. Radical changes (like installing all new desktops) generally produce the desired result but have a much higher initial cost. For example, a training company once faced a reactively initiated training lab update. Their hardware could no longer sustain the new software they needed to train people on. Rather than buy all new hardware, they purchased new memory and video cards. Although this alleviated the immediate problem, it caused a host of other issues over time with the old training software. They might have responded more radically by completely replacing the hardware.

Finally, we have to ask whether we will follow a standardized configuration or customize one for a unique application. Executives and others with a large amount of budgetary control typically receive more custom designs than the standard worker, but occasionally unique configurations must be allowed in the interests of the business. For example, one local hardware store chain ended up installing a number of monitor lenses for individuals with impaired vision in response to several customer complaints.

The events listed above do not cover all of the possible events, but they demonstrate how a specific event generates a request for new hardware that then flows through competing decision criteria. Once the competing criteria balance, we can move on to making the case for the new hardware purchase.