Tools & Templates
New User Guide
Technology, by its fast-changing nature, is difficult to keep under control. The same thing ends up being done several different ways within a company; the wheel is constantly being reinvented. That was certainly the case at H&A.
H&A did not exactly leap onto the computer bandwagon. In 1993, only about half the staff had computers, and these were mostly 286s (or worse) running DOS applications. Because computer technology had not been identified as an area of future importance, the company had no strategy and no centralised control. Each office (there were 9 at the time) did its own thing, as it saw fit. Most offices were too small to have dedicated IT staff; a local engineer-hobbyist handled their computer-related needs.
It was only around 1995 that the company began to recognise the importance that computer technology would play in its future, and not until 1997 that it established a corporate IT department with authority over computing services in all offices. But by then, we had a hodgepodge of LANs, servers, email systems, and applications. In the other offices, each workstation had been set up individually, with no attempt at consistency between them. Haphazard setup had resulted in crash-happy workstations. Providing technical support over the phone, for a workstation whose setup we could not guess at, running applications we had never seen, proved to be difficult, frustrating, extremely time-consuming, and sometimes fruitless. This approach was clearly a waste of company resources, especially of our time and that of the engineer having the problem.
So we established workstation setup standards, server organisation and naming conventions, and a standard set of preconfigured applications using WinInstall. Over the course of about six months in late 1998, we went to all the other offices (there were about 12 by then) and rebuilt each one from the ground up. Each rebuild followed this process:
These rebuilds were a significant undertaking. The average office had 20-30 workstations, each of which required a couple of hours to rebuild. We scheduled rebuilds for weekends, beginning on Friday afternoon to give us as much time as possible. We brought as many IT staff as we thought would be needed, and worked throughout the weekend, often late into the night. On Monday morning, the staff came in to a squeaky clean, standardised computer setup. One or more of us remained there on Monday, to address any issues that might crop up, and answer any questions the staff might have.
The end result of this effort was a sharp reduction in the volume of support calls received from the other offices--the staff could spend less time fighting their computers and more time using them productively. Also, because we then knew exactly how their workstations and applications were configured, the average support call was resolved much faster. And, in the case of hardware failures, we could set up a new computer and ship it overnight, in complete confidence that the user could just power it on and immediately get back to work; its configuration would be exactly right.
I planned and directed all the rebuilds, and participated directly in most of them.
Having performed these rebuilds came in handy when H&A subsequently opened new offices. The rebuilds forced us to identify exactly how an office should be set up, and how to do it. When a new office was opened, we could set up a server and all the workstations in Boston, ship them to the office, and presto! Instant network.
H&A also bought several existing companies, and had to integrate them into the existing operation. We did this by the same rebuild process, although it was more complicated because there were far more variables; an acquired company may have a current setup utterly unlike H&A's. Also, rebuilding an office that was its own company last week requires a great deal of delicacy and tact. (In other words, it's not a good idea to look like you're thinking "You will be assimilated. Resistance is futile.")
See also my musings elsewhere on the subject of consistency.
|Copyright © 2002 Lisa Nelson.||Last Modified: 9 March 2002||Back to Top|