Move IT!

Moving people and computers in modern offices.

This is the HTML version of a book that I self-published some years ago. It is still copyright, and you may not copy it or re-use it without my permission. However, you may print this edition for your personal use, whether that is to help you at work or for other reasons.

This text was originally published with ISBN 0-9520429-0-8

If you want a copy of the updated version, that includes much more material plus discussion on moving data centres, it is available to buy through all good bookshops. This is a link to it on Amazon, you can buy it from the publisher's web site or order it using the following details:

Move IT!
The complete guide to moving corporate data centres and offices:
the staff, the cable and the machines.
Paul Friday
Published and printed in the USA by Adams-Blake Publishing.
ISBN 1-883422-08-6

Foreword

This book is aimed at those who have responsibility for moving people and computers around. It covers the two basic scenarios; the move to somewhere new, and the shuffle within an existing area.

The shock dawns...

If you are lucky, the office move starts with a wild gleam in somebody's eye. This means that there is still time. No-one has yet started to pack removals crates. Tell the wild gleamer that it is a wonderful idea, but will need just a little planning. Give them a copy of this book. If you are really lucky they will read it and realise what "just a little planning" really means. The problem is that you can't persuade fanatics with reasonable argument (and people with bright ideas about moving count as religious zealots). They will read this and know that it is possible to move people and computers without major disruption. With their belief thus strengthened, you had better start planning. Read this book through from the beginning, and expend at least twice as much effort planning as doing. It pays.

If you are unlucky, you are the last person to find out about the move, typically on the Friday afternoon with everything set to roll on Saturday. Go straight to the emergency checklists in Appendix A. When the dust settles, read this book to prepare for next time.

You could always run a Satisfaction Survey after the move to find out how successful it was. Compare this with how good it could have been if you had been able to do it properly, and sell the difference. You might get a few more days warning next time!

In the moves I've been involved with, the computers and printers are the responsibility of the people who normally support them. Depending on your circumstances, this could be anything from your barefoot computer doctor in a small business to the PC Support Team in a large Corporate office. This book is aimed mainly at the large end of the scale. If you are alone and moving a handful of PCs unaided you should be just as careful, but you will have far less hassle. Most of the comments and techniques described here apply to large moves, where you can employ a team of people. If you have less to work with, then adapt things. Where I refer to specific teams of people, you will have perhaps just the one team and you will have to give them different tasks to cover the necessary work.

Traditionally, office moves have been the responsibility of the Office Services or Facilities Department, employing a firm of removals people. In the bad old days they could just pile everything into some boxes and move it. Now that businesses use computers, you will find that the computer systems and data are worth more to the business than physical assets like desks and chairs. Most people could work sitting on the floor with a packing crate for a desk, as long as their computer systems were up and running.

These days you have also to consider things like Service Levels, customer support and quality. "Bung it in a box and move it" is not good enough any more.

Modern office moves should be run by IT people. These are the only ones with the insight of how important the computer systems are, and what it takes to keep them working. If you let Facilities or removals people move your IT, it will be treated in the same way as desk lamps and calculators.

On the other hand, the Facilities people must not be marginalised. They often own and control the desk layout, the building wiring and the removals team. Make them part of your efforts and they will be rewarded by a successful move, plus you will have a powerful ally in getting things done.

This all assumes of course that you are moving an outfit large enough to have separate IT and Building Services Departments. In a really small operation, you have a charmed existence: the fewer the interfaces, the fewer the opportunities for politics and misunderstandings. All the rules and lessons described here still apply, and the results should be no less professional. It will just be easier to get things done.

One final idea: even if you are not planning a move, read this book. The groundwork of creating and maintaining an inventory plus the knowledge of how to move IT, could form a major part of your Company's disaster recovery planning.

The Basics

The ground rules

The first rule of moving things is to spend at least twice as long planning as it will take to do (unless you are in a real emergency: see Appendix A).

Never skimp on planning, it's the only thing between you and disaster. Computers are now so important to the way most people do their work that taking their IT services away could be career-limiting. Moving computers is also such a minefield for the unwary that it's easy to stop them working. To this end, look carefully at the following rules of moving PCs. These rules apply everywhere and all the time. Try to work to the first set, but be sure that you plan with the second set in mind.

The Up side ... (these are what you should be doing).

1. Do no harm.
2. Ask what they want.
3. Listen, and feed it back as what you are going to do.
4. Do it, when you said you would.
5. Ask them how it went, and correct problems fast.
6. Learn by your mistakes.
7. KISS (Keep it simple, stupid). Design projects the way they used to design motorbikes: add lightness and simplicate.
8. Make everybody glad they were part of something good.

The Down Side ... (this is what usually happens).

1. Only Sod's law applies.
2. No-one ever keeps a promise.
3. No-one ever keeps to a deadline.
4. Everybody makes assumptions.
5. No-one ever makes a decision for which they might be accountable.
6. All decisions are made for short-term gain.
7. People never talk to each other.
8. It is the nature of machines to break.
9. Data communications have an infinite number of ways to fail.
10. All mistakes are repeatable.
11. The highest standard that a move can ever achieve is to be unremarkable. (There are no medals).
12. Every interface or separate responsibility multiplies the effort spent in politics and communication.
13. Nobody ever listens.

These may look cynical, but you can bet on most of the Bad Thirteen happening. The point of this book is to warn you what could happen, and to show you some practical ways of avoiding the larger pitfalls. If you are planning something as complicated (and potentially career-stunting) as a large IT move, then develop some serious paranoia fast. Remember that God is in the details, and check everything.

Reasons to be cheerful - or, why projects fail

In surveys of a large number of projects of all sizes, there were six main things that had to be done right for the project to succeed. These were:

1. Clear and consistent objectives.
2. Effective planning.
3. Proper means of control.
4. Leadership.
5. Teamwork.
6. Suppress the impulse to act before planning.

Do these things as well as you can and you are on the path to success. Ignore them or get them wrong and you will join the ugly pile of failed projects.

The sixth item is the unusual one. It does not mean that you freeze into analysis-paralysis. It does mean that you should think before you spring into action. The temptation is very strong to look busy, but try hard not to confuse activity with progress! Some of the planning techniques described later use large wall charts. These are excellent for reassuring those in authority that something is happening despite the lack of people running around aimlessly.

Types of move

The basic terms.

All sorts of new terms will crop up in this book (except some of my more colourful ones). Most of the words are self-evident: if not, I'll explain when I produce one.

The most general terms I use are:

A move is where people and things move from one place to another.

A shuffle is where people and things swap places.

A restack is where people and things move and shuffle between floors in a layered building.

I'll tend to use MOVE to represent all three.

I've also used Ethernet to mean IEEE 802.3 They are not really the same thing, but Ethernet is more widely understood, and a lot easier on the eye.

Authority

So, the move is afoot, and you have some kind of responsibility for organising it.

The very first things to get sorted are authority, responsibility and accountability. These go hand-in-hand. If you are accountable to anyone, demand that you have the authority to make it work. If you are the organiser, ORGANISE! Almost everyone will react well to being told what to do in the right way. If you are visibly in control you will have control. You cannot afford to be indecisive or weak-willed. If you think you will have problems, this is the time to appoint a Project Manager. Appoint someone with the sole responsibility to drive a project through, a kind of Attila the Planner, and then appoint yourself in charge of your area of expertise, reporting to Attila. There is nothing wrong in taking quiet responsibility for an area of expertise, and letting someone else drive the project as a whole. However, if you are in overall charge, then take charge overall: you must consider everything globally. If you ever let go of the reins to concentrate on your own favourite subjects, the rest of the horses will pull the project apart.

So, decide now: Can you take and manage overall charge of this move? Are you instead in control of one of the sections in a complex move? Can you find good deputies to take control of sections under your general control? Would you rather be a cog?

Sometimes there is no choice but to be a cog. You may have been given responsibility for just one small part in a larger project. If this is the case, use this book to make your bit work, and to ensure that everyone else is clear on what you need to succeed.

As they say, if you can keep your head while all about are losing theirs …

Risk, money and using someone else

If the move is risky, and there is money available, then subcontract. Use as much outside specialist help as you can get or afford. You will still need to be totally in control of the planning, unless you can appoint a Consultant or Facilities Management person to handle that as well. Put your contractors on some kind of a bonus scheme, based on target dates, and the satisfaction of the people being moved. The priority order you should subcontract in is: Removals company; Packers; PC engineers.

Planning

As a basic rule of thumb, you should aim to spend twice as long planning the move as you will take doing it. Take another look at the "downside rules" back at the beginning. All of these things can really happen. It is only planning that will avert them. Plan until it hurts, and then make sure that everyone involved shares your plan.

It is at this stage that one of the fundamental questions must be asked: why on earth are you moving PCs around? If you had a halfway decent network and some basic data organisation, there would be no need to assign PCs to particular owners. The staff would only need to move their personal effects to the new desk and log-in. Think about this. If you foresee many shuffles around the office, then persuade whoever it takes to install a "proper" network. This is one where a person's data is not tied to any particular PC, but is available across the network wherever they happen to log in.

If your office move is a genuine move rather than a shuffle, wouldn't it be simpler if all your PCs were identical? It wouldn't matter which PC ended up on which desk, as long as they all linked into the network. You could also use the network to build-up the register of who was using which machine, for your inventory and Help Desk.

If you have the usual mix of different sorts of PCs and printers, odd software and weird cabling, then think about this carefully. Try and work out the true long-term costs of supporting and maintaining this mess, versus the cost of replacing it with a common standard. If you are still not convinced, have a look at the price of good-quality clone PCs. Now ask yourself again, "does it really have to be this complicated?" (See Upside rule 8).

How much time do you have?

It's true to say that you will probably never get as much notice nor as much time as you deserve. On the other hand, even when you do get plenty of advance notice, human nature keeps you busy and preoccupied as the move gallops towards you. Just like everything else in life, you will see the planned move as a small, harmless dot in the distance. You will shift your attention to something else, and the dot will start to accelerate. Before you even know it, a cross and hungry move will be all over you. If you have normally have problems with this, try and get on a time management course. They have some useful techniques for organising yourself.

If the move really is an emergency, then get the basics done: what goes where and setting people's expectations. See Appendix A.

If you do get a decent lead time, then use it to block out your milestones in a diary. Book your helpers, schedule their tasks, then stick to your timetable.

Who and When

Who is moving, FROM where and TO where? When?

When

Strange as it may sound, you have two options on setting the move date: the soft one and the hard one. One will cause the most inconvenience possible, the other the least.

Large moves, that range from a Department to the whole Company, have to be done to cause the minimum impact. You will plan these to take place over weekends or overnight. The aim is to have your Customers go home one evening, and come in the next working day to find all their systems up and working as normal.

For small moves, it is often wise to do just the opposite. Small moves, where from one to a few people want to move, and particularly where there is no real business need, should hurt the Customer! If you make every whim to change desks painless, you will be making a rod for your own back. It is in your interest to create a "move threshold". Moves that are below the threshold should be strongly discouraged, those above the threshold made to work perfectly. Ask yourself "what can I get fired for?".

Small moves sap an awful lot of effort for very little return: avoid them.

Big moves are highly visible and scary; do them extraordinarily well.

One way to set a threshold is to charge for your efforts. Make a realistic charge for small moves, and charge big moves to the cost of the whole project. This is ideal, as it makes it relatively cheap for one person to move, expensive for a small group, but makes big projects easy (while supplying the correct cost information to the Project Controller).

Another type of threshold is to schedule small moves for during working hours. Make a small move a serious interruption to the people moving, and they will treat it with the respect it deserves.

The Project Calendar (The Sticky Bar Chart)

In the Control chapter later I discuss the need for change control. The Project Calendar is a part of this. There should be only one Project Calendar, to which all the participants have access.

You will probably have to deal with much rescheduling, particularly in a large move. The bigger and more visible the calendar the better. It should also be easy to change or update.

One technique that works well for concentrating everyone's minds is to make a project planning wall calendar. The best type of all is the sticky bar chart. Project planning software is great, but no-one else can see it inside your PC. What you want is something really obvious, but informal. Being big and obvious serves to concentrate everyone's minds. Informality means that you can react to changes fast. Get a roll of plain lining paper from a wallpaper shop. Mark-off along it's length alternate distances of five and two inches. The five-inch gaps represent working weekdays, with the two-inch gaps being the weekends. Divide the chart across it's width into three-inch wide "streams". Each of these streams is used for the activities of one part of the Move Team. You might have one stream for PC Support, one for the cabling people and another for the removals company.

Get a load of Post-It notes, the five by three inch ones. These will stick perfectly onto the working week columns. Cut them into two-inch widths to fit the weekends. Use these to mark-up your activities for each week, and for each team. What you have just created is a cheap and very visible Gantt chart. You can now shuffle and play with your tasks at will. Because it is so simple, and because you can see the whole of the project at once, you should be able to spend more time planning than fiddling with a piece of software (which is the whole idea). It also encourages people involved in the project to come and look at it and talk to you. The more people query and correct your plan, the more likely it is that you will know what is going on.

In laying-out your planning calendar, work backwards from the end of the project. The planned end of the project should fall at the end of the paper roll. Draw a heavy black line down the chart, to mark the planned end date. You want to make slippages as psychologically difficult as possible. Fix the stick bar chart to the wall where you sit, and use it.

If you have sets of linked or dependant activities, then try linking them for real with tape or string. If the project falls into phases, then draw-up each phase on a strip of card and Blu-Tack it to the plan. Phases can then be moved as complete blocks, without having to move all the component Post-Its.

You could also try marking the number of people required on each Post-It or phase and totalling them at the bottom. Whatever you do, make it bold and visible. Nothing sharpens the mind like a good, concrete plan!

Now that you have the means to reschedule and shuffle your activities, create a method of showing how much you have accomplished. When an activity is complete, strike it through on the wall chart or put it on a trophies board. You want everyone involved in the move to see how much they have achieved.

Obviously, don't bother with this sticky bar-chart when the move is small or imminent.

The only drawback this chart has over project planning software is in making a backup, so lay your hands on a Polaroid or video camera. This camera will also come in useful during the move for recording things (especially breakages).

If you can find it, read British Standard 6046, parts 1-4. This is all about the use of flowcharting methods for project control, and it makes a great deal of sense.

Tell

Identify a single point of contact with each group moving. Tell them what is about to happen. If there is enough lead time, start a regular meeting for two-way communication.

Start a regular meeting for representatives of every group involved in making the move happen. Coordinate your actions. Agree areas of responsibility and the move timetable.

Communication

A straightforward or small move is simple. Everyone knows (or should!) that they are moving, and what will happen. Things start to get tricky when your Company takes the opportunity to reorganise at the same time (perhaps the reorganisation is driving the move.) If this is the case, then you will find that communications break down. You will be trying to move people who have not been told what is happening to them, or who have been told and don't like it. I have been in situations where staff only realised they were being made redundant when they saw there were no places for them in the new office.

This is a political minefield. You need to dissociate your move operations from any of the hard decisions over who goes or stays. If there is any doubt at all over wether people know about their future, then treat everyone as though they were staying. Any survey of equipment or decisions over seating plans should cover all the people in the group. You may need to be very discreet with the actual move plan or list of names. It's normally best to keep your move team fully informed, but to warn them about secrecy. Use all the pressure you can bring to bear to get the decisions into the open, remembering that the only source of this information must be Personnel or the relevant Departmental Manager.

If you do have to plan "secret moves" where some people are moving out rather than to a new desk, then do it this way:

• Survey everyone.
• Only publish plans that show when whole Departments are moving.
• Do not name individuals.
• Keep the actual list of people moves in a secure place. Remember that your Move Control area is the first place that people will look to find out what might be happening.

Be warned, when I was in a similar situation, somebody stole the hard disk out of a locked PC system unit in Personnel to try and find out (but the data they were looking for was not on it!).

There is also an issue to be solved with communication. It is almost impossible to tell everyone who will be moving what is happening. It certainly is impossible to manage the cycle of Inform - Gather changes - Inform again. The answer is to make each Department responsible for their own people, and to have only one authority for changes to the move plan. What you have to do is define the one person in each Department that you will deal with. Tell the whole Company that any decisions on who moves where for each Department are only valid if they are authorised by this person. Anyone wishing to discuss anything other than technical matters must deal through this person. What you must do is separate your planning of the move from any Departmental wrangles associated with the reorganisation.

This Departmental Representative is also the focus for all communications in and out of their Department. You should hold a series of move forums (fora?), inviting all the Reps. Use these to inform people about what is happening, and make the Reps your only authority on the Department's wishes. Use the Reps to distribute all written notices, and if possible issue them with copies of thefloor plann and FROM/TO list. This will make them special and important, and involve them in your planning. If they are involved and feel important, they will commit to the plans.

If you can, hold the move forums over lunchtime (call them Chat and Chew sessions or Eating Meetings). This will cause the minimum interruption to everyone's work, and if you provide the sandwiches they are certain to attend!

Tell the people moving that you will not accept changes from anyone other than the Reps. Use a memo something like the following, sent to the Departmental Heads:

Things like the siting of shared printers never seem to satisfy everyone, so ask the Reps where they should go. They will then support you against the sniping afterwards. The best way to get agreement on the siting of things like printers is to provide a floor plan with the desks marked, and ask the Rep to mark-up the plan.

Part of your discussions with the Reps should be on service levels. Computer moves are usually done by the resident PC Support people. This means that normal support services are bound to suffer during the move. Be upfront about it, tell them what the support arrangements will be and ask their help and sufferance.

This network of Departmental Reps will provide the foundation for your change control, as you will see in the next chapter.

If you are installing new IT services or a network during the move, you will need to consider training. If this is a large move, try and get a training room set up, with PCs, network and printer to match the new environment. If you can, get the training handled by a proper training company, using their own off-site facilities. Keep them informed of the move timetable, so that they can arrange their training plans to coincide with it.

Other devices that help with communications are demonstrations, newsletters and feedback.

If you are moving people into new premises, see if you can arrange a tour of the new building for them. If there will be a new desk layout, then build a mockup for them to see and try. Even if you don't intend to seek their opinions, still show them what they are going to get. People will whinge just as much about something good as something bad, if they feel they were not involved.

A newsletter is a good mouthpiece for setting expectations. It can be as simple as a single page on the Department's noticeboard. Whatever you plan to do during the move, tell everyone that you are about to do it, then keep doing it until you tell them you are going to stop, then stop.

If the move is spread over a period of time, try to get the Reps who have already been moved to attend the later sessions. Ask them for their feedback on how the move went. If you have done your job right, they will reassure the other Reps, and give you the backing for some of your less popular decisions on things like deadlines (see Change Control later).

If your move is large, then internal communication will become a problem. If more than one group or team are involved, coordination will be difficult. If you have time during the planning, schedule a series of Move Control Meetings. For these, you will want one representative of each of the teams, with sufficient authority to be able to commit to an action. The purpose of the meeting is to make sure that everyone involved is aware of the plan and the timetable, and to give them a forum for voicing their concerns.

As with all things, preparation is key. For your part, bring along the sticky bar-chart Move Calendar and copies of all the planning documents covered later. If you are the only one at the meeting with a visible plan, guess which plan they will work to?

Control

Establish change control. Only your defined contacts may ask for changes to your plans. Tell them that there is a deadline, after which no changes will be considered. Tell them that there is also a "clean-up" period after the move, during which no changes will be considered.

Inventory

It is crucial to establish as early as possible who will be moving, and what they will be taking with them.

An accurate inventory is required of what equipment is to be moved. This may also generate a list of components needed for upgrading and a list of machines that are to be replaced. This inventory must be indexed on a unique number associated with each PC. If you already have some system of asset tagging or numbering, then use it. If not, use the manufacturer's serial number on the back of the PC system unit as your reference. This unique number will be the key field for most of the databases used in the move.

This inventory must be under change control and is owned by the Database Administrator. Change control means that all changes to the database are logged. The log should record who requested the change, who authorised it, what the change was, and when it was applied. A proper change log will allow you to regress the database, one request at a time. It will also prove that requests were made and adopted with the proper authority.

If you decide to use a computer database for the inventory, be very careful about designing the change log. It is very easy with DIY databases to make changes, but not record what they were, or what the previous state of the database was. A database change log can be as simple as a record of which fields were changed on what date, with a reference to the paper Change Request Document.

Unless you already have an accurate inventory, you will need to make a survey of what you are moving. It is extremely rare to find any Company that has an accurate record of their computer equipment. Even if they do, it never contains the information you will need.

Audit

Just as important as the physical or technical inventory of hardware is the audit of services. This is what the Customer actually sees: they don't know one PC from another, but rightly demand that all of their IT services are moved safely. It is important to identify all the services used by your Customers: what software, printers and communications they use, and where the data is stored. This information is fundamental to planning how the services will be maintained or replaced. As a bonus, you will probably find that there are a number of services that people have, but no longer use. Stripping these out can simplify your move, save some money, and make your support burden lighter in future.

If you talk to the Customers in terms of service delivery, you may also find that some services are more important than others. In that case you have an opportunity for spreading your workload. If some IT services are not needed immediately after the move, you may be able to connect and test them later when you have more time. This will also identify those services that are vital. These are the ones that you must re-establish and that you guarantee to the Customer.

It is because you want to talk to your Customers in terms of service that you have to be careful who does your audit and survey. If you let the propeller-heads loose, you will get a good technical survey but no record of the services or what they are used for. On the other hand, if you use warm and cuddly types, you might get good descriptions of the Customers' services and service expectations, but have to do a separate survey to identify the hardware they are using.

The ideal is to use people who can do both, or to temper the extremes by using a good questionnaire.

Questionnaire

Only survey your Customers once. If you have to go back and ask more questions, they will think that you don’t know what you are doing. If two people ask the same questions, then it is obvious to the Customer that the IT people don't talk to each other. So be careful, and make sure you ask everything you need to know with one pass. Use the Move Control Meetings to agree a common and complete set of questions covering all the IT teams’ needs.

The exception to the One Visit rule is if you agree to do an initial survey, and to revisit the "interesting" cases for a more searching interview.

To be able to move IT equipment, you will need to know the following:

For a simple shuffle, you will probably not want to know this level of detail. For a complicated move involving upgrading PCs and connection to a network, you will need all of it and more.

Unless you already have a system of asset-tagging, use the serial number of the system unit as the basis of your records. Screens and keyboards tend to get swapped rather than repaired, so simplify matters by assuming that every system unit has one of each. Don't bother to track them individually. Special or costly screens should be treated as an asset, and numbered separately.

Making a technical survey can be very difficult. You want to cause the minimum disruption, but you also want to be as thorough as possible. It's not always convenient or practical (or safe) to take the lid off every PC, an some of your surveyors wouldn't recognise the bits inside anyway. The ideal is to have a utility that will reliably "fingerprint" the PC configuration while leaving the surveyor free to interview the user of the PC.

There are several utilities that will do the job on most hardware platforms. One is included on the accompanying diskette. If you are really smart and have a network, why not use it to gather the information you need?

If you are using a diskette for the technical survey, be extremely vigilant against viruses. Your promiscuous diskette is the perfect medium for spreading one Customer's infection to everyone else. Building the virus test into the survey is also a good method for checking all the PCs for cleanliness anyway.

Appendix G deals with PC survey tools.

Once you have your survey information, be sure to carry forward any special systems to the Moving and Testing phases.

Using barcodes in the survey

If you have a large number of PCs, and either have no existing inventory or plan to move things around often, then think about using barcodes for management. Most system units are now barcoded with their serial number. A good barcode reader will recognise the various formats used, and save many mistakes in both writing and rekeying the serial numbers. To make barcode surveys efficient, label the desks using a barcode as well. Make up a small crib-card, listing types of PC with a barcode for each. To make the inventory check, you will then only need to "swipe" the system unit, desk label and PC-type card to record where everything is.

A barcode reader that I have used successfully is a small standalone unit, about the size of a thick credit card. It can be programmed with software downloaded from the PC to ask for data in a particular order, and display prompts on a small LCD display. It also has a numeric keypad to let the user enter information directly. All the recorded data is time and date stamped, and downloaded to the PC as a delimited ASCII file through the serial port.

This made PC inventories simple: I downloaded my program to the reader, and sent someone off to do a survey. All they had to do at each desk was "swipe" the desk number label, the system unit, and punch a number to represent the type of PC or printer. I uploaded the data file when they returned, and used it to update the inventory database on my PC. The time and date stamping of the data went straight into the change log, to track when equipment had moved.

Nobody likes to do inventory surveys, but this made it as painless as possible both for the person doing the survey, and for the Customers.

See Appendix C for details on this particular barcode reader.

The move database

For small moves or shuffles you can probably cope using the flow diagram described in the Planning section, plus some paper lists. Big moves will need a database. If you intend to use a database, then appoint a database administrator if you possibly can. You will want to be planning the move, rather than punching data and producing reports.

There should be only one master database. It is acceptable for specialist groups to maintain databases covering their own areas of interest, such as cable patching or telephone numbers. However, all these small databases must use the master database as a source. Only the master database should hold the records of who is moving FROM and TO, and when.

Ideally the master database would be in a shared data area on a network, so that all the teams involved have access to changes, and can make references to the master table. The alternative is to issue change reports for everyone to rekey into their tables.

The master database should be used to produce reports for the Customers following every change.

It is at this point that the regular Departmental Reps meetings become even more useful. These meetings define the frequency of the change cycle. If the Dept Reps meet weekly, then you should report to them from the database at the meeting, incorporate their changes and issue a fresh set of move reports afterwards. The fastest practical change cycle is probably one of two working days, with reports issued on Tuesdays and Thursdays.

The reports from the database should show:

• Move records: By Department, who is moving FROM and TO, with what equipment, on what date.
• The same, ordered by surname.
• The same, ordered by move date.
• Inventory: A detailed listing per person, showing the survey information and what is intended for each item, if any changes are to be made during the move.
• Clashes: People without desks to move TO.
• TO desks with more than one person.
• Empty TO desks.

All of the snags and clashes are to be referred to the Dept Reps to resolve.

An immediate benefit that you can gain from the Move database is to provide a telephone book for the new location (if it's a new building) or a floor plan of where everyone will sit.

Change control

In any normal move or shuffle, you will be under pressure to accept changes up until the very last minute. Even when you are packing the PCs away, some people will be changing their minds about where they want to sit. Some will even decide not to move at all! Not having change control will wreck your careful planning.

What you must do, through the "single point of contact" of your Departmental Reps, is to establish how changes may be made, and where the deadlines are.

The first step is to make your Reps responsible for changes in their Departments: tell them that they are the only avenue that you will recognise for change requests. All changes from a Department must be signed by the Department Representative and presented to you or the Database Administrator. Determine from the start what change cycle you can maintain: It should not be impossible to achieve a two-day turnaround from change request to a re-issued set of reports. If you were moving people at weekends, this might mean that you issued the reports on Tuesdays and Thursdays. The Tuesday report still gives time for the Reps to spot mistakes or ask for changes before the weekend. The Thursday reports are the ones that the Move Team will use for the coming weekend's moves.

The next step is to define what deadlines you need. If you are moving a large number of people over several weekends, you will need to "freeze" any change requests a few days before each move. This allows you to plan properly for the move, print reports and move lists, and have control of what is happening. If you were moving people at weekends, then the Wednesday before the weekend might be the deadline for changes.

The final step is to define the "waiting time" before changes will be accepted after the move. There will always be people who got their change requests in too late, or who are unhappy with their new situation. In a large move that may span several weeks, you will want to concentrate on the people moving, rather than on those who have already moved. If you try to attend to the people who have already moved, you will probably spread your resources and energy too thin. There will be a risk of failing one or more stages of a large move, because of trying to get the earlier stages completely happy. What you need is an agreement that once moved, everybody has to sit still until the whole move is over. When the dust finally settles, you can then revisit them in move order.

Again, communication is vital: everyone involved must know what to expect. An example notice to distribute through the Departmental Reps might be:

All movements of PCs and printers, plus all purchases and disposals must be subject to change control in the period before the move. Every change affecting the hardware or services being moved must be notified to the Database Administrator (DBA). The key databases under the control of the DBA are the only true record of what is planned. All change requests, even from non-IT sources, must be made through the DBA.

Standards

Why do we need standards?

Moves are like warfare: so chaotic and disorganised that it's often hard to tell winner from loser until years afterwards. So much will be happening during a move and so much will go wrong, that you need to control everything you can. You want to be able to treat all the PCs, printers and IT services in standard, well-defined ways. You need to be able to plan your work, and train your resources. This is impossible if every item you move is atypical or a surprise.

If you can get some basic standards agreed, then at least you will have nailed some of the known unknowns.

Desk layout

The first thing to standardise is your desk layout. Every desk must have mains power, space to put the kit, and a network connection point (if you have a LAN).

The best (and easiest) way to arrive at a desk layout standard is to get hold of a PC and a desk and practice. This will show you immediately what is possible, and help you to find the best arrangement. Draw a picture of the layout, and insist that everyone sticks to it.

If you are using desks with cradles that allow the PC system unit to hang on-edge under the desk, check now that the full range of PCs that you will be moving will actually fit into the cradle. You should also decide now which way the system unit will face: will it always be top surface facing out (neatest looking), or always the same way up regardless of wether the cradle is on the left or the right of the desk. Beware: if your Company use diskettes a lot, you will cause grief and confusion if you vary the orientation of the PCs, as people will be forever putting the diskettes in the drives the wrong way up!

If you have any floor-standing PCs, such as IBM PS/2 Model 80s, then be careful where they are sited. If you put them next to the desk, there is a risk of them being knocked over or the cables pulled out as people walk past. The best arrangement is to place them "inside" the knee-hole of the desk. If you are using desk with cradles, you will need to take the cradle off to be able to do this. (So make sure it's possible during your practise run, and be sure to have the right tools on the day).

If you find you are trying to put more than one PC on a desk, try smaller keyboards! Seriously, there is a type of keyboard that squeezes the whole of an enhanced keyboard into the space normally occupied by the alphabet keys on the standard Enhanced Keyboard. The same company sells a flat screen as well, for when space is really tight.

Another option is to move the system units off the desktop using extended keyboard and screen cables. These work well in most cases, but I have had problems trying to extend the video cable on some Compaq VGA screens. See the Appendices for lists of cable vendors.

If you have a large move into a new area, do the Space Planner a favour, and check the plan for sanity. Things to watch out for are desks where people will be walking behind the seat of the occupant (very annoying), places where printers are located (busy), and people with windows behind them (dazzling reflections).

Ergonomics

There are some excellent books on this at your local library; look under Dewey Decimal number 620.8 in the Engineering section. It will suffice to say that you shouldn't layout people's desks so that their backs or necks are twisted when trying to use the computers. The screens and keyboards should be set at a good working height. For the least eyestrain, set your screens to maximum contrast, then turn-up the brightness to a suitable level.

Power supply

A basic PC needs two power sockets, plus one for a printer and one more for every extra peripheral. Check your fuse ratings: if you are going to put lots of kit in a small area, you may overload the desk, the floorbox or the nearby fusebox. A basic PC can consume more than 300W alone, so think of the heat output too. Don't go putting several PCs into a small sealed room!

You will probably find that you never have enough power sockets. Before the move, buy in a stock of 4-block extension leads: a type of mains extension cable with a four-socket block on the end. You can buy these with built-in surge and spike suppression, which is worthwhile.

Data points

Try to get the data-point or floorbox distribution standardised as well. If you are moving into a new area or desks are being moved, get in early with your advice. All desks must have at least one LAN connection point. If these are on the wall, make sure that your space planner puts them in a sensible position relative to the desk. If you are using floor boxes, ensure that they are placed under the desks, near to a leg and at the back. The worst possible places for floor boxes are next to a desk in a passageway, or under a chair. One will cause tripwires, the other will guillotine your nice new cables.

While you are getting the floor boxes put in sensible places, take a look at the insides of one as well. Will your network cables connect without excessive bending? Will the lid chop the cables when someone stands on it? Is the LAN connection point labelled clearly? Is there room to bring two serial cables, two network cables and two mains cables out of the floorbox, and still shut the lid?

Cabling

Data cabling is another thorny issue. You may have to deal with any combination of serial, parallel, network and mainframe terminal cables. Parallel printer cables are only really of use for directly attached local printers: don't use them for anything further away than the next desk.

If you are connecting your PCs to printer-sharing switches, consider going serial. It's slower in use, but an awful lot easier and cheaper to cable.

Serial printing

If you are going to use groups of PCs sharing a printer, or you have to print over long distances, use serial cables. You will need eight-core cable, which you can buy in large reels. All of the cables should be terminated at the PC end with a 25-pin D connecter, of female or socket presentation (no pins sticking out). The printer ends must all be 25-pin male or plug presentation. Either buy or make the cables as straight-through: that is no crossovers. Connect pins 2-8 and 20 straight through to the same numbered pin at the other end.

Now, some peripherals will need some of the pins crossed. Buy a whole bunch of patch boxes and make the crossovers you need as add-on units for the end of the cables. These patch boxes are small plastic boxes, about the size of a box of matches, with male and female 25-pin connectors at the ends. You solder or connect the patch wires inside to provide the crossovers you need. If you buy lots, you could probably get the Vendor to do it for you.

If you make a bunch of these and label them, you have the tool to adapt any of your standard cables. This means that you can leave all of your cables in place during future moves, just adapting the ends and crossovers to suit as you need them.

Another thing you will need are some 9-25 adaptors. You can buy these ready-made. These will convert the 25-pin PC end of the cable down to 9-pin, to fit PCs with 9-pin serial ports. You may also need some that work the other way: to convert a PC 25-pin serial port to take a 9-pin ended cable. If you don't have one of these adaptors, you are bound to need one!

The final tool for serial cabling is the gender-bender. One of the hazards of serial cables is that you always find them with the wrong type of end. Buy-in a supply of male-male and female-female gender-benders, but keep them locked away with the 9-25 adaptors. These things are so useful that they evaporate rapidly if left lying around.

Appendix E has the connection diagrams for these adaptors.

Old cables

If you are moving into an area that has been in use, then remove or destroy any cables that you cannot positively identify. Cut the ends off old cables to prevent anyone using them by mistake. Don't pull cables out from under the floor if you can help it, as you will probably disturb all sorts of other cables that you do need.

Make it a policy to label all cables that you do lay. Make it another rule that you will cut the end off any unlabelled cable that you find.

Network cabling

If you already have a network, then you are probably stuck with what you have.

For the move, buy a stock of spare flyleads. If you find a damaged flylead during the move, cut the ends off before you throw it away. Life is too short to try repairing them, and you don't want anyone reusing them by mistake.

If you are planning to provide a network as part of the move, look seriously at using unshielded twisted-pair cabling. The flyleads are cheap and easy to cable-manage.

IBM Type 1 (Token Ring) cabling is pretty robust, but hell to cable-manage tidily.

Thin Ethernet usually gets old and unreliable quickly. The ends drop off the cables, and the cables themselves develop kinks and breaks. If you are using Thin-net, try to protect the main "backbone" cable, and use "disposable" flyleads to connect out to the PCs.

Thick Ethernet is seldom used now, but it's still good if you have it. The problem here are the transceivers and drop cables (AUI cables). Transceivers tend to hide in the most inaccessible places, and AUI cables always fall off. Make sure your transceivers are well­connected and firmly attached. If a transceiver is out of site under the floor, stick a label on the visible part of the cable to point to where it is. Always strap the AUI cables to the transceivers with plastic wire ties to stop them falling off.

If you are inheriting some existing cabling, try and get a health check done on it. For Ethernet, try to hire a TDR (time domain reflectometer) and someone to use it. It will tell you wether the cables are good, where the bad points are, and what is wrong. There are similar devices for most types of network cabling. If money is tight, and you have Thick or Thin Ethernet, use an electrical resistance meter. The resistance between the centre and outer braid should be 50 Ohms. Do disconnect the PCs first, or you may destroy some of the network cards!

Optical fibre is either a delight or a torture. The installer of the cable should use a light meter to test the quality of the cable ends when they are made. It's usually a fair bet that an existing fibre backbone for the network is satisfactory, as it gets little physical abuse.

If you are using fibre flyleads to connect out to the PCs, then they will break your heart. You will get flyleads with poor light transmission, broken ends and broken cores. Fibre uses two cores, one taking the signal from the PC, one carrying the signal to it. It is possible for only one of the cores to fail, causing difficult to track problems. If you do get problems, first make sure that both ends of both cores are clean, then swap-over the connections of both ends of the flylead. This swaps the transmit and receive cores. If the flylead that was originally showing a healthy red light at the end goes dark when swapped, then one of the cores is broken.

Carry a stock of spare flyleads, and be sure to dump all the failed leads into a marked bin. If money is really tight, they may be recoverable by remaking the ends, which is where they usually fail.

As fibre flyleads are fragile, consider using external optical transceivers. These can be strapped under the desks, well out of harm's way. They are then connected to the PCs with "sacrificial" AUI cables. You can often cover the extra cost of the transceivers by using cheaper network cards, as fibre-optic cards are expensive.

If anyone other than yourself is doing your cabling, you must specify in advance the standard you require. Make sure that you tell the cabler that you are specifying your needs, not because you don't trust them to do a good job, but because you must be certain that all desks are cabled in a certain fashion. In the chaos of the move, you must be able to rely on all desk cabling being the same, and having the correct ends.

Try adapting the following memo:

Obviously, edit this to suit your own circumstances. If your desks have no cable-trays, you will need to arrange the cable management in another way.

The cable management of desks

All desks should be cable-managed. This means that all the cables should be tucked carefully out of site, and out of harm's way. Many modern desk designs have a cable-tray built-in. If you are using old or odd desks, be sure to have a stock of plastic cable-ties. Use them to gather the slack in the cables, and to hang the cable-bundles out of sight. You will probably want to do the cable-management as the last item during the move: it would be silly to have to undo someone's work to rearrange a PC. Make sure that the cables are not pulled too tight, especially mains cables as they could be pulled out. Also be sure that each cable is tied and managed separately. You don't want to have to untangle all the cables just to replace a network flylead.

The best way to establish a workable cable management standard is to hold a demonstration. Use a spare desk to layout a PC and cables to the standard you require. Get your move teams together before the move, and show them how it works. This means actually cabling the desk while they watch: showing someone a completed desk is useless, because it's not obvious where the cables go, or what order to work in.

Printing

This is another issue that causes ulcers. It will be better for everyone if your Company standardises on one type of printer, or at least as few types as possible. If you haven't done so already, try to standardise on one type of laser printer. You might settle on one type of Postscript laser printer, one colour printer and one plotter. If you are looking at standards for Departmental or network printers, look at printers with more than one paper tray such as the Hewlett-Packard Laserjet IIIsi. This, and some other printers, is capable of switching protocols according to the incoming data. With the right fittings, these printers will switch between Postscript and "normal" HP Laserjet emulations. With a second paper tray for headed stationery, these make ideal workgroup printers.

For similar reasons, make sure that all of your standard peripherals are autoloading. Choose plotters and colour printers that load their own paper from a tray or magazine. Nobody minds loading their own personal plotter, but no-one will attend to a networked plotter on behalf of anyone else.

An office move is a golden opportunity to slim-down and rationalise the typical collection of different personal printers. Make a concerted effort to take as few printers as possible with the movers. Remember, add lightness and simplicate.

If you don't have a network, consider fitting automatic switches for sharing one printer between a group of PCs. Be sure to use the electronic kind, not the manual switches. The manual switches always seem to wear out or be on the wrong setting. Just like network printers, no-one will want to take responsibility for them.

If you are using shared printers of any type, you will need to give some thought to the location of them. For a start, never put shared printers on personal desks because you will make enemies. Always put shared printers on their own stands, with space for extra paper underneath. Use your Departmental Reps to define to you who the workgroups are, and where they would like their shared printers to be put. Plan to have no more than eight PCs connected to each printer.

Get out your trusty floor plan again, and plan the route of the cables from the PCs to the printer. Place the automatic serial printer switch next to the printer, and label all the cables with the desk number they come from. This will help enormously with fault-finding and changes in future. The serial cables running into an automatic switch are usually heavy enough to pull the switch backwards off the table or printer stand. Use plastic cable ties to strap the cables to the desk or stand and stop this happening. Supporting the weight of the cables will also make the connections with the switch more reliable.

Finally, tape a plastic bag or envelope to the bottom of the automatic switch, and put the manual in it. This will save you many tears when you come to make changes or trace faults in future.

Sources of automatic switches are listed in the Appendices.

If you are really smart, and get a chance to define your own cabling, then use unshielded twisted-pair (UTP) with two connections to every desk. The first connection to a desk may be used for the network, and the second one as a serial printer cable. You can then put the printer sharing switches out of harm's way in your patching cabinet, and use one of the UTP connections back to the printer. This use of generic rather than dedicated cables makes things much easier during subsequent moves!

PC configuration

If you are providing new PCs as part of the move, buy them to a standard type and configuration. An example is where you are moving to new premises, and providing new PCs and a network at the new site. If you don't already have a standard PC configuration, start now.

(Note: this next paragraph just shows how quickly things change!)
Don't buy anything less than 386SX machines. Try to buy ones that use SIMM memory, and get them all with at least 4Mb fitted. SIMMS are cheap, so it will be easy to add more later, for power-users. Your standard PC should include a mouse, and a colour VGA screen. If you have an installed base of plotters or modems, get all of the PCs fitted with a second serial port as standard.

Don't be afraid of clones, cheap does not necessarily mean shoddy. You need a standard architecture, rather than a classy name.

If you have some older machines already, then buy the new ones with both 3½" and 5¼" diskette drives fitted. The extra cost is small compared to the saved aggravation.

Alternatively, you might try to "retire" the old PCs, and equip everyone with the new standard.

The other standard to adopt is software. If you don't have a standard yet, then think about setting one. This is probably a longer-term decision than the hardware, as one PC is very like another.

To start with you will need a word-processor, a spreadsheet, a database and a menu system. You are looking for a set of products that are well-known and supported, not too feature-rich or complicated, will import your existing data and will transfer data amongst themselves.

If you are starting from scratch, take a good look at Windows and a set of Windows software.

Defining a standard set of software tools means that you will have to migrate existing data and applications. This is why it is best to wait until after the move. By then, everyone will be on your side, following your successful move, and it will be easier to get people to listen constructively.

If you have to move people from existing systems onto new as part of the move, then you will need to get involved in migration. This is an art in itself. (See the section on Migration, Page )

Plan

Plan-out the flow of people and equipment. Get your move team together. Tell them what will happen. Assemble the tools and information they will need to do their job.

Planning the flow

This is probably the most important part of the planning cycle. Get this right, and everything will fall into place. Get this wrong, and you will never succeed. The first rule is to never take-on more than you can handle. Plan to break large moves into phases, and then treat each phase as a separate move. Use the technique shown later to break shuffles into independent parts, and take the same approach. See the section on resource estimating on page for methods of determining how much you can handle in one go.

For a plan to work, it is imperative that you have a unique and reliable method of identifying desks. Make everyone involved in the move stick to the system, and you will all be talking the same language.

If you are lucky enough to already have desk numbers, make everyone stick to them. Refuse all attempts to refer to desks or equipment by the name of the person using it (unless you are moving a very small group, and all the people involved in the move know everyone else.)

If you don't have a desk numbering system, try basing it on a floor plan for your office. This will often have the desks marked. Unless the desk layout is also changing, stick with the floor plan. If you have floorboxes providing your data points, try using the numbering scheme from these to refer to the desk above.

It is so important to be able to refer to things unambiguously that I would refuse to do a large move without proper desk numbering.

If you don't have an existing numbering system, you will need to invent one, and to physically tag the desks. If you were to start at the front door of your building with Desk 1, and work your way round, you will have problems. How will you know where to find desk 99? What happens when (not if) you add a desk? What happens if you lose count, or use two people to do the numbering?

A numbering system that I have used before is based on the code FF.AA.nn.DD.

This means that the desk numbers start with a two-digit code for the floor level within the building (FF); followed by a two digit code for the area within the floor (AA, divide your floor plan for each level into areas, or use Mail Point numbers if you have them); the last two digits are the desk number within that area (keep your areas small, it helps for locating desks). The two digits .nn. are optional: if you have to get desks numbered in a hurry by more than one person, assign each of them a unique .nn. code. This will ensure that your desk numbers really are unique.

Using this code, to find a desk numbered 02.08.01.09, you would go to the second floor, Mail Point 8, and look for desk 9. Any problems, and it was Joe who labelled it.

If the desk layout is marked on the floor plan, and is fixed, you could simplify things by using the "hotel" numbering system. This is just like the way hotels number their rooms: use a four-figure number for each desk. The first digit is the floor level, the last three digits are the desk number. This allows a maximum of ten floors, with up to 1000 desks on each floor.

Where to stick the labels? If you are in a hurry, and need the numbers only once, stick them on a back corner of the desktop. To have any hope of survival beyond about one week, stick the numbers on the side of the desk drawers facing into the "knee hole" of the desk, close up to the underside of the desktop. This keeps them out of the way of little fingers, but leaves them easily visible. Mark the desk numbers on your floor plan as you go, and you will create an extremely useful map. The use of this is covered in the next section.

Stick a copy of this map on the wall next to the sticky bar chart. You have now established Move Control, which will become the one true source of knowledge during a lengthy planning process.

Planning a shuffle

What distinguishes a shuffle from a move is that the desks people are moving TO are already occupied. It is truly a shuffle, as everyone has to move at once.

The flow of moving hardware and services around is important, because it's easy to get confused.

When planning a shuffle, the information you should ask for from the people moving is a list of FROM and TO, using your desk numbers.

Imagine for this example that you have a regimented desk layout, shown in Figure 5.

Say that the list of movements that you have been given looks like this:

Table 2. Movements list.

A list like this is useless as it stands: you can't see if it is even possible to move these people to the desks shown. There is no way of telling wether a desk has been left out, or two people will be trying to sit at one desk. There is also no reliable way to allocate the work to your move team members. To solve this, take your floor plan and draw two arrows against each desk: one pointing to the desk, one away. Work your way down the move list, writing for each desk on the plan the number the current occupant is moving TO, and the number the new occupant is moving FROM. The result will hopefully be like Figure 6.

In the case of a desk with two PCs, where the kit is moving to different tables, draw two or more arrows away from the desk. As long as there are as many arrows pointing TO desks as you have pointing FROM, then everything should be accounted for.

This plan is an excellent basic tool. If there are an equal number of arrows pointing TO desk as FROM, then you have accounted for everything (unless you have forgotten to draw some of the arrows). Each desk on the plan may be "read" to learn the history of the items moving FROM and TO it. For example, desk 11 in Figure 5.

Looking at the marked-up plan tells you that kit is moving FROM desk 15 TO desk 11, and FROM desk 11 TO desk 5.

The next stage is the truth table. Divide a sheet of paper into to columns, headed FROM and TO. Start with the first desk on the marked-up plan and write down FROM and TO of the first arrow, in this case FROM 4 TO 1. Leave a blank line below this, the write down the second part of the twin arrow, FROM 1 TO 8. Work through the plan, leaving blank lines between each combination, until you find a combination that already exists. Write this down in the blank line beneath the one you wrote earlier. Keep going until you have written down all the moves.

As an example, after working across the top of our plan from left to right the list will look like the following:

Truth Table for Shuffle-type Move.
From	To
4	1
1	8
9	2
2	10
10	3
3	4
3	4
11	5
5	6
5	6
6	18
12	7
7	21

Note here that some of the numbers are already paired (FROM 3 TO 4 and FROM 5 TO 6). This pairing is the "truth" in the table. If the numbers pair-up, then the flow plan is self-consistent.

Keep working through the plan, writing down the FROM and TO desk numbers of each arrow. If you are using purely numerical desk numbers like in this example, you will be able to total both columns. If the plan is correct, the list will show all of the combinations paired, and the column totals will match. Any errors will be obvious. The full move table for Figure 6 is shown in Table 2.

Table 3. Truth table for shuffle-type move.

This kind of thing is easy to do with a spreadsheet.

The truth table serves to prove that your move plan is consistent. If there are errors, it shows you where they are.

You now know that the move will work, so it's time to squeeze the full use out of the floor plan.

Use a pencil to start connecting the FROM and TO arrows. With any luck you will find that what looked like a complicated random shuffle will break down into isolated chunks. The example plan in Figure 6 actually splits into three blocks of seven desks, like so:

If you consider just the top-left section of the plan, this will appear like Figure 8:

This "chunk of work" in the form of a marked-up floor plan is useful during the actual move. It shows better than any table of FROM and TO exactly what is happening to each desk.

You can divide your team into smaller groups, each with a portion of work to do. This avoids the awful chaos that can happen when lots of people are all trying to shuffle equipment around at the same time. Without this kind of division of labour, they will start to get in each other's way, and start moving the wrong things to the wrong places.

During the move, give each team a marked-up plan showing their responsibility, along with a copy of the truth table. Get them to cross-off each move from the truth table as they do it. That way, you will both know when they have completed their task.

Planning a move

In a move, you will probably find the desks people are moving TO are empty. Moves are typically groups of people moving into new premises.

The flow planning is not as critical here, as you don't have the complication of getting people off a desk to make way for the new occupant. You will still need to number the desks, except that you might now be dealing with two different numbering systems: the old one and the new one. There is still value in making a proving table like for a shuffle, to show the inconsistencies.

The Change Control cycle

Now that you have established the plan of who goes where, you will need to change it! As covered on page , change control should be managed through your Departmental Representatives. It is possible to represent the change control cycle on your sticky bar chart. Doing this will make it obvious where the various deadlines are. For example, suppose you were moving a large group of people over two weekends. Each move would be shown on the bar chart by a Post-It note. To shown the change freeze period around the moves you might stick lengths of ribbon on the chart. The reporting dates from the Change Control process would then be shown by another set of Post-Its.

The result would be like Figure 9.

If you have broken a large move or shuffle into phases, the easiest way to manage the sticky bar chart is to draw each phase onto a horizontal strip of paper and Blue-Tack it to the chart. Make the scale of the strip match the scale of the chart. This is true to life, as the start-time of phases will alter (usually slip), but the timing of the components of each phase will remain the same.

Using this technique you can look at one bar chart to see when all of the activities are due.

Labelling

You can never have too many labels. The mechanics of labelling desks with desk numbers has already been dealt with (see Page ). You should also label every item that is moving and provide a "desk information label" on the TO desks. You should even label the items that are not moving, to make sure they don't.

For the item labelling you will need your trusty roll of sticky white labels again. Every component item of every PC, printer and peripheral needs a label. The labels should identify the owner of the kit, should identify which components go together and should identify where the kit is to go. If you can, use your database to print the labels. NEVER use Post-It notes to label equipment, they fall off. Use the most aggressively sticky labels you can find, and standardise on a non-intrusive place to put them on the PC kit.

Label all cables before you remove them. On a PC, put a row of labels across the back just above the ports. Before you disconnect anything, wrap a label around the end of each cable. Mark matching numbers on the PC case and cables. This is particularly important with serial cables and Apple Macintosh computers, where it is not always obvious which cable does what.

PC and cable labels.Provide extra labels for the packaging. You should have labels stuck to the hardware itself, and to the outside of all the packaging. The labels attached to the kit are a backup, in case the ones on the packaging are lost or removed. For this reason, NEVER remove the labels until the whole move is over.

The next label you will need is the desk information label, stuck to the desks in the TO location. They show the name of the person moving onto the desk, the equipment that is supposed to be there, the ID and default password, and the testing checklist.

Table 4. Example desk information label.

The way to use these labels is to have a member of the move team tape them to the desks, just before the move starts. They are to stay on the desk until the move is over. They serve as a valuable check during the move that the correct equipment is arriving at the desk. If you only use strips of tape across the top and bottom of the label, you will be able to slip the other bits of printed matter underneath. This will protect your carefully-written communications and newsletters vanishing in the confusion after the move (the confusion over unpacking their desk contents, obviously. Never the confusion over the PCs!).

The bold writing of the user's name helps them to find the right desk in the new location. The checklist proves that everything works, and is filled-in and signed as the testing phase of the move progresses.

Again, you could probably get your move database to print these.

Upgrading

It may be that as part of your move you are moving some old PCs, and will need to attach them to a new network. Almost certainly, some of the old PCs will need to be upgraded. You will have the options of upgrading old PCs, or replacing them. If you choose to upgrade, then make every effort you can to bring all machines to the same standard. Remove any unused option cards, and bring all the software and DOS versions up to date. This is where you will need the information from your survey or inventory. An accurate survey or database of what is to be moved will allow you to order the right bits and plan the upgrades.

If you are replacing machines, try to do it as far in advance of the move as possible, to give yourself plenty of time in case of failures. Alternatively, install the new PCs in the new location, and only move the person's data.

The upgrading or replacing work will follow-on after the survey and audit. With a large phased move, plan the upgrades to occur in phase-order. If the move is protracted, you may not need (or even be able) to complete the entire upgrade program before moving the first phase. If you have sufficient resources, plan a "wave" of upgrades timed to have completed each PC just before it is moved. If you do not have enough time or people, you will have to use money instead, and pay someone else to do the work. This could be your hardware vendor or your hardware maintenance Company, or even a bunch of hungry PC contractors. If you do choose the latter, think carefully about security and liability insurance. See the section on page for how to define the work standard and procedures.

Moving a network

For any move involving networks, you have to be careful with workgroups. Any group that shares data or applications need to be moved en masse. You will have to shut-down and backup the LAN servers early enough in the day to be able to move them. You will need to bring them up as early as possible after the physical move, to give yourself time to test and repair them. If you do ever have to split a workgroup, you have three choices. You can move the first part without the network, you can move the first part with the network, or you can create a duplicate network. The first two choices will leave some people without their shared tools, so you may have to arrange for software to be loaded on their local hard disks temporarily. The third option is the best, as you can be certain that the new network is working before shutting-down the old one. It does raise problems with data currency and version control, though. You may have to invent a method for merging two sets of data, when the workgroup recombines.

A lot of your decisions will be guided by the structure of the network. Small shuffles within one Department might be simple, providing all the desks are cabled. Even quite large shuffles are simplified if you are using a structured cable system. This is where your truth table comes in useful again, as this provides a patching list to the person updating the network connections. (The patching list also provides a checklist that all the connections have been moved, and allows you to reverse the change if necessary).

If you have one of the "old-fashioned" style Ethernet LANS where a single cable winds around from desk to desk, you may have to pick up the whole thing and move it. In this case, it's very unlikely that the new desks will be in the same positions as the old ones, so you will have to recreate the layout. Wherever possible move away from the old-style methods of running a single cable to only the desks that you want to connect at that time. Plan for the future, and provide a network connection at every desk. Take a good look at modern structured cabling techniques, particularly using unshielded twisted-pair (UTP) cables. This can make it much easier to modify or extend your LAN later.

If you do have an existing backbone-type LAN, one common problem is that no-one knows how it is connected! Appletalk and small "desk area networks" are easy enough to trace by simply following the wires. An old and much extended Thin Ethernet backbone running under the floor of your office can be a nightmare. To trace this, the best tool is a time-domain reflectometer. These are expensive and technical beasts, so try to hire one with a person to operate it. (Once you have seen the hire cost, look again at the cost of just ripping all the wires out and starting from scratch). A TDR is like a radar for cables: it can look down the wire and measure how far away the end is. In the case of Ethernet, it can measure the distance to the terminator and each of the Transceivers or connections. Pick a quiet weekend before the move, and sit your man with the TDR on one end of the Ethernet backbone. Find the other end, and remove the terminator. This gives you the maximum length of the backbone. Mark the terminator desk on your floor plan with the length of the cable. Now wander around, pulling the cable apart at each T junction in turn. Note on the floor plan what the cable length is at that point. When you have measured all the T pieces, join them dot-to-dot in length order. The result is a plan of how your Ethernet backbone is laid-out. (In my experience this will give you a nasty shock). The TDR will also identify all the damaged lengths of cable and poor connections. Replace them as you go, and your LAN users will bless you.

In the case of Thick Ethernet, you can't pull T pieces apart. The backbone cable is generally in much better shape than a typical Thin Ethernet, so the TDR should be able to discern and measure the position of the transceivers directly.

With structured cabling systems, like 10BaseT or Token Ring, the cables are typically arranged to run from each desk back to a patch-panel. With an old LAN, you will typically find that there is no record of the patching, and that many more cables are patched than are in use. You have to bite the bullet with these, and check all of the patching from first principles. Set aside a whole weekend with some helpers to investigate the wiring. You will have to pull all of the cables out of the patch panel, then replace them one-by-one, testing the whole time to find which PC is connected to which cable. Be sure to label or tag the cables before starting. This way, you can keep records while you work, and even reverse the change if necessary.

With this type of system you have two options: you can patch every desk; or you can only patch what you need. Patching every desk or floorbox is expensive when only a few people are using the LAN. It does mean however that you will never need to touch the patching again. Only patching the desks in use is cheaper in LAN hardware, but means that you need good records and change control for every alteration.

If possible, try not to move your network file servers. In an ideal world the file servers would be located in a special room of their own, with protected power supply and restricted access. In a shuffle, you should be able to leave the servers alone. If you are moving to a new building, then you will have to plan very carefully. First determine wether the network will be moving in one go, or in sections. If it's moving in one go, are all the LAN users moving at the same time? If not, how will they have access to their applications and data?

If the LAN is moving in sections, will the components be able to function on their own?

Last but not least are breakdowns. File servers are seldom switched-off. For this reason, they typically fail when they are switched off. The only satisfactory way to move fileservers is to subcontract to a specialist, either internal to your Company or someone outside. They should be able to rebuild one of your fileservers using spare parts that they supply, to reinstall and reconfigure the version of the network operating system you are using, and backup and restore data using your media and backup devices.

As a warning, some of the worst experiences I have had involved file servers where backup tapes could only be used in certain drives, due to head misalignment; where the configuration of the file server had been changed, which only took effect after the machine was rebooted (and there were no records of the original configuration); where an IBM PS/2 server lost it's setup, and there was no reference disk available; and when a fileserver hard disk automatically parked it's heads when powered down, and refused to unpark them when powered up. That is why you will want to leave these jobs to the experts.

If you are moving people around on an existing LAN, you may have to move their data and accounts. This happens typically when people transfer between Departments. Again, leave this to the experts. The mover's entire data-set and applications will need to be identified and moved. Any links to workgroups or shared data may need to be preserved. Their applications may need to be reconfigured to use different printers or directories.

Follow the Up-side rules from the beginning of this book: at all times keep the Customer informed of what will happen, and what has happened, and never make their service worse by your actions.

What happens if Support are moving too?

Moves involving IT are usually done by the Company's PC Support people. If Support are part of the move, then move them first. In fact, try to move them well ahead of anyone else. This will give you an excellent practice run, and iron out some of the snags. It serves to highlight any deficiencies in planning or implementation. It also means that the Support Team are ready and organised to provide support throughout the move, without the distraction of moving themselves.

Migration

The actions involved in migrating data and applications are:

• Identify.
• Group.
• Inform.
• Perform - which has the options of:

                Transport.
                Translate.
                Migrate (recreate).

Identify.
First you need to identify what is out there. The source of your information should be the survey. You should also ask your Departmental Reps to use their own knowledge of their Departments to flag any systems or data that will need to be migrated.

Group.
Having identified everything that needs migration, group them together into similar systems. You may find that several Departments have invented the same wheel or are using the same systems.

Inform.
Having made your plan, tell the Customer what you are going to do. Get everyone's agreement now, and save some tears later.

Perform.
Finally, do what you said you would.

You have three options for migration. The first is transport. This means simply moving existing data or applications from the old location to the new one. An example might be moving an application and it's data from a local hard disk onto a network drive.

If you can arrange to add the option for the "old" systems to the new menus, that would make things easier. If you cannot, or can't allow the old and new to coexist, you will need a method for switching PC configurations.

Included on the accompanying disk is SWAPPER. This is a crude and simple method for swapping configurations. All it does is to maintain several sets of the two configuration files AUTOEXEC.BAT and CONFIG.SYS. The owner uses a DOS batch file to copy the relevant pair of files into the root directory of their boot disk, and reboot the PC. See Appendix D for more information.

The second option is translation. This means translating the existing data into a form that will work with the new applications. An example might be where you translate a bunch of word processor documents created using several different packages into the file format used by your new standard word processor. Some of this work can be done by the Customer themselves. Rather then do the work yourself, use your efforts to create a Migration Manual. This will be a manual for importing data from all of the old packages into the new ones (there should be no instructions on how to convert it back again!). These sorts of file conversions are pretty standard: write down clearly how to do it, and make that available to everyone. If specialised file-conversion utilities are required, buy one copy, and set-up a "conversion centre". Provide a PC with both sizes of diskette drive, a manual, some easy menus and a good virus-checker for people to do their own conversions.

If your are moving to a new suite of software, then one winning selling technique is to provide a manual for how to transfer data between the various packages. This is a common question; answering it will help to persuade people to adopt the new systems.

I did this in the form of a grid, with each of the standard software packages listed across and down the grid. To convert from one to another, you would look along the FROM row to the correct TO column, and turn to the page number listed. That page had the description of how to move data between those two packages, in that direction. Obviously, some combinations didn't work. It is rare to be able to use a PC graphics file in a mainframe package. If the combination did not work, the manuals said so and gave the reason.

This kind of thing will promote the success of your chosen software suite. It will also help to stop the common practice of using a spreadsheet as a word-processor or a word­processor as a database, because the user did not know how to get their data into the correct place.

Table 5. Example data transfer table.

This kind of thing may look as though it's beyond the call of duty, but it does win people over. As they say "give a man a fish and feed him for a day. Teach him to fish and feed him for life".

The final option is "proper" migration; the recreation of an old system using the new application software. This is complicated and time-consuming. If you really must do this, pay to get it done professionally.

Security

In the chaos of a move, security will be important. A move is the perfect time to lose hardware or data. You need to consider the physical security of the FROM and TO locations, the security of the systems and data that you move, and the access security of passwords and IDs.

Physical.
First is theft. During a shuffle, you will only need to prevent items "evaporating" during the turmoil of the actual movements. Arrange with your building security to examine ALL bags both entering and leaving the premises. Anything that they don't recognise is to be reported to you. Tell everyone involved in the shuffle what will be happening. The reason you give them is that it is for their own protection. There may well be all sorts of contractors and repair-men wandering around during the shuffle. If anything is even mislaid, you want your people to be proved "clean".

During a move, you will need to provide security at both the FROM and TO locations. You will need access control, as well as bag searches. If you are moving into a new building, demand that there is some form of access control before the move even starts.

Imagine the nightmare of moving into a new building, where the computers vanish as fast as you move them in.

Loss.
Next consider loss. You can protect against loss by having accurate records. Your database of what is to move and when (see the section on databases) is your protection. You need to have every item labelled with it's origin and destination, both on the outsid