How To Deploy 20,000 PCs and Get a Promotion

I had a chance to chat with the recently promoted director of IT from Cummins awhile back on a large deployment of Windows XP machines. She saved her company around US$10 million, which resulted in promotions for her and her team. I thought it would be interesting to explore this because it represents what is likely a good practice when it comes not only to deploying lots of desktop hardware very quickly, but also to addressing any complex project.

As team leader, the IT manager in charge of the project probably considered getting her resume in order when she looked at the complexity of the problem. Cummins had been under tight expense control for an extended period of time and the hardware that was deployed, initially estimated at 15,000 machines, was every age, shape and type you could imagine. The actual count was 20,000 machines.

It spread over 24 countries, and the software applications were in 12 languages. They had performance users who needed fast hardware cycle times and had unique needs, manufacturing floor implementations that were older than dirt, and a growing mobile population that was putting the “B” in breakage. Every group had its unique needs, and there was little in the way of an obvious common thread.

The group didn’t know for sure how many machines were out there, what their ages were, where they were and what they were running. Nor did they have any sense how old any of this stuff was. All they knew at the front end was that the current situation was killing company productivity and needed to change.

Mess to Deal With

On top of that, buying and responsibilities were decentralized, and even Cummins’ applications wouldn’t run on Windows XP, which was expected to be the target platform.

This mess was creating a massive drag on the company, which, because of an anticipated market recovery, was expected to be asked to ramp up operations very quickly to deal with the changing needs and volumes of Cummins’ customers. So the process of replacement couldn’t be very disruptive, even though the need for a massive change was clear.

With a core team of 10 people and a Six Sigma template, the project justification was created. The Six Sigma part was important because it built measurements into the process at the front end. Those measurements were critical to proving the benefits at the back end, which formed the foundation for proving the project a success. It was this success that drove the promotions.

Remember this for any project: If you don’t have measurements, you have no way to show your management that your efforts had value and, without this, you will often feel underappreciated.

The deployment team favored a “Big Bang” approach. A Big Bang deployment is where you do everything at once (or as close to at once as you can) to minimize deployment risk, get the full benefits of the deployment almost immediately and to eliminate incompatibles and excessive software images.

Three Images

Three products meant three images (an image is the core software operating system and application load, and it usually includes the e-mail client), and that was vastly better than the nearly unlimited numbers they had before deployment. All hardware products would be retired in three years, putting the entire company on a three-year service cycle to maintain this low complexity perpetually.

At this time, the first critical team member was identified — the communications director — because this team member kept the various remote divisions focused on the benefits of the project, not on the responsibilities they would be losing. The request for proposal (RFP) was created and sent to three vendors: Hewlett-Packard, IBM and Dell.

HP, which was still in the midst of consolidating its people and systems after the Compaq acquisition, bid too high and was knocked out in the initial round. Dell and IBM went the distance, but concerns about Dell’s ability to execute a deployment like this, and IBM’s lower bid, made IBM the choice. Dell tried to promote the idea that it would always be available by phone, but Cummins understandably wanted a significant, qualified presence, and IBM, which was already a major Cummins vendor, was favored.

It generally is better to go with a vendor who knows you in cases like this, because the cost of the vendor learning how you work can be significant. Still, in these large “Big Bang” deployments, I run into IBM more often than any other vendor and have come to see this kind of thing as an IBM specialty.

Experienced Team

The deployment team needed to grow significantly during the deployment process, and they took a phased approach, with remote offices first, small plants next and then the rest of the company.

This allowed the team to put the most effort where the most problems were likely to be — small plants and remote offices — and hit the major portion of the rollout with an experienced team. However, there were several problems that they ran into that are worth exploring.

  • Death by Paperwork. Every vendor has a problem that just doesn’t seem to want to go away. For IBM, it is the pain of dealing with a bureaucracy.

    Cummins was faced with a contracting nightmare of agreements that needed to be set with each of the various IBM units in each of the locations. This identified the second critical team member, a contracts administrator. This individual spent full time managing the contracts and process, and if it weren’t for that person, the deployment likely wouldn’t even have started, let alone ended, as a success.

  • Disposal Nightmare. Getting rid of the old stuff was much of the reason behind why the contracting process became a nightmare. Many people have no idea how problematic this has become, particularly for CRT monitors, or they would never buy another one. With much of this stuff now considered hazardous waste, it is only going to get worse going forward.
  • Laptop Creep. Before the deployment, about 25 percent of the company used laptops, but the team felt it should have been 100 percent laptops. What was planned was 35 percent connected to secure wireless networks, but this went to 40 percent before the deployment was complete. After the deployment, a substantial amount of pressure was put on the system to increase this penetration of laptops significantly.

    In a similar project with another company recently, more than 60 percent changed to using laptops. For Cummins, that much change could break the three-year cycle for all machines that was so painful to create. The benefits of being mobile are clear in the new world, and others would be wise to heed Cummins advice and deploy a higher percentage of laptop computers.

  • Five Finger Discounts. Theft during the deployment was painful, as laptops found ways to escape the company, particularly in remote locations. These products are valuable and easily sold, and one of the problems with large deployments like this is that there can be a lot of shrinkage.
  • Health and Safety. In Europe, the law requires that monitors be at eye level. This is a problem for laptops. After a substantial amount of work, two stacked monitor stands were purchased to meet this requirement. When you think of the laptop name, and how they are most often used, it is good to remember that Europe is just weird sometimes.
  • Software-Hardware Qualification. They didn’t know what software was already in the field, so much of the predeployment effort was to identify the software. A lot of old products were discarded as a result. They now favor Marimba for software management companywide.

    In addition, they didn’t accurately anticipate the needs of their high-performance users. This resulted in a late, unplanned specification change and suggested more involvement with that group is needed to avoid this.

  • Asset Management. They still don’t have a good handle on where everything they bought actually is. While in better shape then they were, if Cummins had to do one thing over, it would be to make the asset manager a key team player at the front end, rather than at the end of the process. They now use a product called Eracent for asset management, and they swear by it.

    Financial Goals Exceeded

    The end result of the deployment exceeded its financial goals, without even taking into consideration the massive improvement in employee uptime, user satisfaction and company flexibility that Cummins now enjoys.

    Even though they will competitively bid this again when they do the next big roll out, they were pleased with IBM’s help, and, given the problems, this makes the deployment a success in anyone’s book.

    The lesson learned is that for complex projects to be successful, you need a strong leader, a strong team with dedicated qualified members, Six Sigma-like goals and measurements, a vendor who can execute and the full support of management.

    Success should have a very positive career impact. If any of this is missing, well, early retirement does have its benefits. However, I would suggest that doing this right might be the better choice.

    Rob Enderle, a TechNewsWorld columnist, is the Principal Analyst for the Enderle Group, a consultancy that focuses on personal technology products and trends.

  • Leave a Comment

    Please sign in to post or reply to a comment. New users create a free account.

    More by Rob Enderle
    More in Chips

    Technewsworld Channels