I frequently talk to managers in companies that plan to standardize their platforms. I typically ask about the approach they're planning to take, and I'm always amazed at how many companies plan for future rollouts that aren't based on the most recent version of the OS that will be in place at the time the rollout is executed.
For example, one company that wanted to roll out a standard desktop in the 2003 to 2004 time frame planned to use Windows 2000 as the desktop standard. At the time of my conversation, Windows XP had already been available for several months, yet this company planned to roll out a new standard that would be a full 3 years old at the time of the rollout. The company's basic reasons for choosing Win2K over XP were that the IT staff was familiar with Win2K but not XP, and management wanted to reduce the training costs associated with the rollout.
Another large company was preparing for a server standardization rollout from 2004 through 2006. That company was using a mix of servers—primarily Windows NT, but also workgroup-based servers running Windows 9x and Linux and UNIX servers. This organization could choose between Win2K Server and Windows Server 2003 and planned to go the Win2K route. Although Windows 2003 hadn't been released at the time, the industry knew that the OS would be generally available in the April 2003 time frame, and the rollout wasn't scheduled to begin until 2004. Both these companies also had aging hardware that they knew they needed to replace for either solution.
Be the Second Kid on the Block
Don't get me wrong—I don't advocate that enterprises live on the bleeding edge. I'd never suggest rolling out anything that uses beta or release candidate (RC) software. With regard to OSs in business, I believe that being the second kid on the block is the best situation.
But being the second kid on the block isn't the same thing as being the last kid. Like being last, being second lets you learn from the early implementers and avoid most of the pitfalls. However, when you're second, you can still take advantage of the improvements in the platform and reap the benefits of those improvements. When you're last, you forgo those benefits.
Keep Your Eye on the Future
In addition, when you're planning, you need to keep an eye on the future. Any rollout, but especially a large one, can take a long time—months or even years in some cases. Beginning a long-term, large-scale rollout with a back-level OS is like playing a round of golf and teeing up for your drive 50 yards behind the tee. You might hit a great first shot, but you're going to wind up well short of the place you'd like to be. Instead of being in position for an easy shot to the green, you'll be in the middle of the fairway behind some obstacles that a tee shot would have let you easily avoid.
No OS is immune to eventual obsolescence. But when you're planning for the future, you need to plan as far ahead as possible. In this age of rapid software turnover, large enterprises can't roll out software on a large scale as quickly as manufacturers can release new versions. All factors involved in rolling out new standard platforms—assembling your team, inventorying current hardware and software, replacing hardware when needed, and deploying the new software—can take months or years from the time you begin the project. Planning future implementations around the platform that will be current at the time of the rollout helps to maximize ROI while providing the benefits of the newer platform and a longer useful implementation.
End of Article
Register
