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.
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.
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.
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.
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.
Loading ...
