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 particularities.
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:
- Replacement cycle
- Replacement phase-in
- Logistics and storage
- Project attachments
- Management metrics
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:
- 3-year 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.
- 3 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.
- 1-year 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 environment.
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 hardware?
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:
- Asset management reports
- Hardware ticket reports with analysis to track causes
- Equipment move/add/change
- Response time from submission of a new employee ticket to the completion of the ticket
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 replacement.
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.