IT literature talks about something called a “desktop
lifecycle” and then goes on to define this lifecycle in a variety of ways.
However, very few people talk about the most common, and most subtle, trap we
can fall into along the way toward implementing this model: relying on a
project rather than a process. Fortunately, we can use a handful of simple
techniques to avoid this trap. Doing so allows us to reap the benefits of
lifecycle management while avoiding some of its more frustrating
Sizing up the problem: Project vs. process
Most IT people can tell a variation on the famous “a
five-person office takes more effort to migrate than an enterprise
backbone” story. The factors driving these stories (e.g., territoriality,
a need for self control, and political maneuvering) generate great gales of
laughter in the right crowd. Like all good stories, though, these tales speak
to a greater truth: The amount of preparation is, in fact, quite similar. The
problems encountered mirror—and not always on a small scale—those encountered
on larger projects. Why? To tackle this question, we need to address the
difference between a project and a process.
A project is a work entity that produces a unique product in
accordance with a specific set of goals. A process is a set of related
procedures with clear metrics that can produce the same results time and time
again. The real difference lies in the expected outcome: Projects produce
unique objects, while processes govern a steady workflow.
By these definitions, deploying a new operating system
requires a project. Rolling desktop hardware, though, does not produce a unique
product. The new hardware does not have to be functionally different from the
old hardware, just newer and with fewer technical problems. In fact, most
companies I’ve worked with over the years had to refresh hardware far more
often than really necessary just to refresh their OS.
What does this exercise in semantics get us? Why do we care
if desktop replacement is a project or a process?
If desktop replacement is a project, it requires all of the
ancillary project activity: intense planning, formation of special teams,
development of new methods to deal with unique challenges, etc. This means that
each time we replace desktop hardware en masse, we have a huge buildup and a
massive work disruption.
If, on the other hand, desktop replacement a known and
planned process, the work requirements can be dispersed over a much longer
period of time. Communications, logistics, and even technical planning for the
next replacement become part of the day-to-day activity of the organization.
This allows the IT team to focus on real projects, like planning the next
business continuance test.
The decision points
Once we decide to transform replacement from a one-time
project into a continual process we can decide on these elements:
The replacement cycleis the hardest thing to
deal with for some companies. Many of my customers wield very little control
over desktop hardware purchases. Their clients, the actual business users, buy
the equipment they feel they need. Other times, our lack of asset and contractual
management processes leaves us in a quagmire.
Assuming we can somehow exert influence over the cycle, most
successful programs fall into one of three groups:
replacement: Unless outpaced by an OS or ERP installation, most
desktop hardware chugs along nicely for between three and five years. This
cycle minimizes disruption in the workplace but suffers from a large
amount of “asset drift.” As equipment and people move, the asset
management records do not always receive proper updates, leading to an
increased need to engage in asset discovery as the cycle nears its end.
and 2: This group assumes a complete desktop replacement cycle every
three years. The IT team replaces the laptop population every two years.
Although this cycle forces the desktops and laptops out of synch, it does
account for the abuse mobile users inflict on their equipment. Like the
simpler three-year replacement above, it requires a fair amount of asset
management work as the cycle nears its end.
replacement: This extravagant cycle usually appears only in start-up
and small companies. They sign one-year leases with their vendors,
deliberately planning to replace the equipment within 12 months. This
reduces the need for detailed asset management auditing later in the
process but can cost quite a bit and introduces volatility into the
The cycle an organization chooses should be based on an
analysis of its asset management capabilities, its need for budgetary
stability, and its ability to analyze past trouble tickets for hardware trends.
The latter is particularly important. After installation,
hardware generally remains relatively stable until it reaches a break
point—usually somewhere between three and five years. At that point, hardware
tickets start to rise, inflicting additional punishment on the support staff.
If the organization can correctly identify its historical break points, it can
set its desktop replacement cycle just ahead of the next expected upsurge.
Replacement phase-in generally falls somewhere
between two extremes: total replacement and trickle in. In total replacement,
the organization sweeps up all of the elements for replacement in a very short
period of time. This is the traditional “roll-out,” where a team
moves in, grabs everything in sight, and replaces it all at once. With trickle
in, the team gradually replaces equipment, usually without disrupting the
environment. Trickle in requires a longer time window than total replacement
but less overall resources.
Most companies adopt an approach that’s somewhere between
total replacement and trickle in. They will totally replace the equipment in
one department and trickle in to another. Some use total replacement for the
bulk of their equipment and trickle in the stragglers. The method is not
important; what is important is that the process designers make a conscious
choice based on the best available evidence as to what will work best. They can
then revisit that decision at a later time.
Logistics and storage usually gets short shrift in a
desktop replacement cycle. However, it is a key consideration when making the
transition to a process. Will the organization buy or lease additional
equipment for replacements and new users? If so, how much, and where will it be
stored? A central facility? At local sites? If the latter, how will it be
secured? If the organization does not want to buy/lease equipment before it
needs it, how will it maintain hardware consistency? How will it dispose of old
Project attachments will always prove contentious. In
the traditional project model, OS and network upgrades often hitch their costs
to the cost of the more visible desktop replacement. Once we turn desktop
replacement into an operational process, that becomes less of an option. We
therefore need to decide whether to include a budget for these projects up
front or to let them stand on their own merits.
Management metrics cannot be ignored. To avoid the
sudden panics associated with projects, a replacement process must take place
over a period of years. This means the activity must be measured, and people must
be accountable for it. Typical metrics include:
ticket reports with analysis to track causes
time from submission of a new employee ticket to the completion of the
All of this seems terribly airy, so let’s look at two of my
customers who moved to this model. They both had specific organizational
problems that affected how they applied the ideas.
One was a fairly small professional services organization
with just under 200 traveling consultants and an office staff of 20. It bought
what it needed when it needed it, as well as a new laptop for every new service
employee. This resulted in a mass bone yard of old equipment, along with a
diverse hardware set.
When we sat down to get this under control, we first decided
on a standard hardware platform. We then took a hard look at the organization’s
growth rather than its employee turnover. We discovered that it had stabilized
in size about two years ago, but its purchasing mechanisms dated from when it
grew at a rate of 20 percent per month. In fact, it turned out that if we went
with a two-year total replacement plan with a 10 percent stock (22 machines),
we could save the company roughly $50,000 a year in hardware costs and 2,000
hours of employee time. The new process required roughly 200 hours of employee
time, resulting in a net savings of 1,800 hours—approximately one FTE.
The second company was somewhat larger (around 4,000
employees), consisting of a central company and a variety of purchased former
competitors. One of these “new offices” already possessed a
relatively sophisticated replacement process using the 3/2 model (three years
for the company desktops and two years for the sales force). It deliberately
placed its desktop OS upgrade project budget estimate into its hardware
In this case, my customer decided to merge the hardware
replacement cycles of the sales force first and then move on to the back
offices. At the unified annual sales meeting that year, we rolled out 1,000
brand new laptops on two-year leases. We kept back 100 laptops (10 percent) for
growth and rapid hardware replacement. This move alone cost my client roughly
$50,000 a month but saved it almost $70,000 a month—a savings that came from
three things: lowered lease cost on much of the equipment, lowered
administrative costs, and a little nest egg we found of overdue leased
equipment from one of the new offices that had a less sophisticated hardware
management method. This came to a net projected savings of $240,000 a year.
Processing the process
Adopting a hardware replacement process seems a bit
counterintuitive at first, especially if it involves a total replacement. That
much work just screams project to those of us used to that method of
thought. However, the advantage to adopting a managed, repeatable process with
deliberate decisions can far outweigh the penalties.