Jul 19, 2012
I used to work in Digital Equipment Corporation’s (DEC’s) corporate IT organization at a time when DEC had roughly 125,000 employees worldwide. In hindsight, most of the time I was at DEC was spent going to meetings. For example, for one stretch of about two years, I was one of several participants in a weekly half-day meeting, the goal of which was to review the status of all of the ongoing IT projects. There were also multi-day, quarterly management meetings with representatives of the networking organization of each of DEC’s three geographies – i.e., the Americas, the Pac Rim and EMEA. While the ongoing projects were also reviewed at these meetings, the primary goal of these meetings was to approve and prioritize new projects.
The environment at the time, both inside DEC and inside most large companies, was that it was OK for projects to take a long time. One project stands out in my mind as an example of something that took much longer than it should have.
At the time, DEC had two very expensive private lines between the US and Australia. The suggestion was raised that we should implement compression, and hence reduce the size and cost of the two private lines. That suggestion had to wait for just under two months for the next quarterly management meeting in order for it to be discussed and prioritized.
It took just over a month and a half for the equipment to be ordered and received and for us to set up a test lab. We ran the tests for two months and roughly two months after that we approved the implementation of the compression devices at the quarterly management meeting. It took roughly a month to ship the devices to Australia, do some final testing and put the devices into production. In total, it took about nine months from when the suggestion was first raised to when we had the solution in place. During that time, we were spending notably more money than we should have for those private lines.
In the current environment, businesses are under ever-increasing pressure for agility and that means IT organizations must become increasingly more agile. The pressure to become more agile is one of the driving factors that have caused the vast majority of IT organizations to implement server virtualization and avoid the protracted installation intervals for servers that used to be common.
In order for IT organizations to become more agile, though, they have to do more than just reduce the amount of time it takes to deploy compute resources. They also have to transition away from spending nine months on projects such as the DEC project described at the beginning of this blog.
There are two key components of the transition away from excessively long IT projects. One of those components involves changing the IT governance model. As described above, the governance model that DEC used at the time added roughly four months of delay to the project by making the project team repeatedly wait to get the approval of the management committee. Unfortunately, in many instances, changing the IT governance model requires a difficult cultural shift on the part of IT organizations.
The second component of the transition away from unduly length IT projects is notably simpler to implement. It involves the adoption of a different model for trailing, acquiring and shipping network equipment. In the DEC example, the compression devices were hardware based. The fact that these devices were hardware based added to the overall delay both to acquire them but also to ship them to Australia.
Fortunately, in the current environment software-based solutions that provide network and application optimization functionality are readily available. As will be described in a future blog, software-based solutions provide a number of advantages, including making IT organizations notably more agile.
image source: flickr (shishberg)