Project Technical Documentation

In my experience you need full visibility and agreement on a set of key Technical Documents to ensure no deviations are forced upon you during the project.

Start with a High Level Email Migration Strategy that any person can pick up and read to gain an overall understanding on what will take place. This should be no more than 20 pages.  From that document other more detailed documents can be written until all areas of the migration are covered. You need the business to understand and agree on the High Level Email Migration Strategy – this document can be changed during the project, but must remain the one place any stakeholder can gain an understanding of how the email migration project will be carried out.

Once you have written the High Level Email Migration Strategy, and it has been agreed, you can start work on a Detailed Migration Plan.  This will likely be a large document (maybe 200 pages) as will need to cover technically how the email migration will be done.   It is important that key technical staff document how to do the migration, in case any staff leave during the project.  There should be no secrets held back by any staff.   I have been involved in email migration projects where key staff have left, and the project has been stalled for a long time as a result.  Migration planning can mitigate this risk.

Business Project Sponsor

Your project team should include a senior representative from the business, who is identified as the sponsor.   This person will be kept informed on progress of the project, and any major issues.   The sponsor can help communicate with the rest of the business, and can provide valuable input into the email migration project, based on a business viewpoint.   Email migration projects who neglect to include such a person often get a poor reception from the business, as they feel excluded, which results in ill feeling against the project, making it harder for the project to succeed.

Communication Planning

Keep your business sponsors and users informed on what is happening during the project.   This could involve information on the company intranet, wall posters, or emails.  Let them know that email migration is on its way and they will be affected.  A good tactic I have seen is to hold a competition to see who can reduce their mailbox by the most amount, the winner receiving a prize.  This gets people involved and gets them talking about it.

People will often not read any communications made available, and for that reason it is important to at least post information on the Intranet.   At least you can say that the information was made available throughout the project, and users then have little excuse if they complain later.

Adding a library of training material on the Intranet is also a good idea, and can be built up over time.

User Expectation Management

People do not like change.   Migrating to a new email platform is a major change for most normal users.  You need to make them aware that change is on the way and that there will be disruption for a limited period of time whilst they get used to the new email client.  Decide how you will manage user expectations early in your migration planning.

Project Metrics

Agree with your project sponsor a set of metrics by which your  project will be judged.   One of the most common, and potentially damaging, feedback from users is the comment “email is broken”.  Users are normally happy to find fault with an email migration project — and this can soon spread amongst the user community and damage the reputation of your project.    What does the complaint mean ?   That user’s Outlook client may be broken, or their PC may be off the network, or their password may have expired.   As feedback, the complaint is of little use to the Technical Support Team, and needs further qualification.   That much is obvious.

However, at a project-level you can’t stop this sort of feedback, you can only manage it.  It can be managed by agreeing some metrics by which your project will be judged by your Project Sponsor.   It is easy to define Failure Metrics, as these could be derived from the number of Helpdesk Calls.  However, defining Success Metrics are more difficult as this area is harder to define.

An example Success Metric would be:
On Day 1 after migration, are 95% of users successfully using their new email client and can send and receive internal and external email.

This is my favourite Success Metric and one I have used across many email migration projects to change management opinion of how successful the project has been.   How can this be measured ?  Easy — On the night before the Day 1 “Go-live” day on the new email system, send a new Outlook email (from a system mailbox) to all the user mailboxes with a subject line of “From the Email Team — please open this email”.   Then, importantly, tag the email with the Request Read Receipt, and Request Delivery Receipt options.  And send it.    Monitor the system mailbox Inbox and you will see the Delivery Receipt come back in to show the email was delivered successfully.   Then, when you are in early in the morning on Day 1 “Go-live”, have Outlook open for the System Mailbox, and watch those “Read Receipt” acknowledgements flood into the mailbox.

Then, when anyone attempts to claim that “email is broken” or your project is a disaster, you can just say, for example, “Well, it is now 9:30am, and we have 400 users actively using Outlook out of a total of 500 users. Please can you explain what metric you are using to back up your claim, as it looks successful to me ?”   At this point the person usually starts backing up very rapidly and you will not hear from again !

Risk Management

Having a well-maintained Risk Management Plan is very important to maintain your email migration project’s credibility with the business.    Often, this is overlooked.   Managing risk is a crucial ingredient in any successful email migration.  Set up your risk register early in your migration planning phase.

As an example, a common question from senior management is this:
“How do we roll-back during the email migration if we hit problems ?”.

You need to be able to answer this confidently, otherwise you may not be able to proceed.   Risk management is critically important from a technical and political point of view.   At all points in the project you need to be able to roll-back all the changes you have made.   This could be rolling back the internet email routing change to the new email system, or moving a mailbox back to the legacy email system.

The Risk Management Plan, if properly done, will prove itself a very useful tool as proceed through the project, as new risks will appear.  These must be captured any addressed.   If your project falters at least you can show that all steps were taken to approach the migration in the right way.

User Training

Offer training to users on the new Outlook Client.   Many users will be familiar with the Outlook Client, but some may not be.   The users may not wish to do training but you need to ensure you are seen to be offering it.   You will always get a subset of users who will complain about lack of training.   It is usually a financial reason why training is not offered, and you need to make it clear if that is the case, and make people aware is not a decision made my the email migration project.   To cover yourself, you can ask the business sponsor for user training at the start of the project, and let the business decide !

Senior Executive and Personal Assistants

How do the Personal Assistants manage their Manager’s mailbox/Calendar.     Will this change under Outlook — most probably it will ?   Keep the Personal Assistants on your-side, as they are unhappy they will complain to their Manager — who will complain to you !   Keep them informed, and ensure they get special attention from support staff after the migration.

It is a good tactic to migrate all the senior management and their personal assistants very early in the project, even as part of the pilot.   It is a brave move, but in most cases a very useful one.   Once you have done this, then complaints from other parts of the business tend to fade away, as if the senior management are all on the new email system, and are happy, what is there to complain about !

Who to Migrate ?

When the time comes to carry out the actual migration of mailboxes, you need to have an accurate list of users who are to be migrated.   Often, it is difficult to get this list finalised.  You are advised to put this list into Excel and use it to track the migration status of each user.  Also, ensure you have a unique identifier for each user, to avoid mistakes with common names being mixed-up – such as more than one “John Smith”.   The author has used the user’s smtp email address to provide the unique identifier, alongside their Active Directory login id as a backup attribute.

You may wish to consider updating a user’s legacy display name in the legacy email system’s address book with a suffix of “- Migrated to Outlook” to help clarify where each user resides.  This is more useful during any co-existence phase of a migration.

Global Address List

Ensure that the Global Address List in the new email system is accurate and displays names in the expected format.  Check the format in the legacy email system – it may be “Firstname, Surname”, and then check the new email system – it may be “Surname, Firstname”.  It is an easy item to overlook, but with the integration of Exchange with Active Directory, the author has seen this happen.

This may also be an opportunity to tidy up the Global Address Book.  Often, the first entry may make the list look untidy if it is not a normal mailbox name.   A good example would be to introduce a dummy mailbox with the name ” ** Company Global Address Book **”.  Make sure you use the ” ” character at the start of the Display Name field so the name appears at the top of the Global Address List.

In addition, you may wish to group all Resources together by adding the prefix of “RES_” to the start of the Display Name.  Users will then be able to quickly navigate to them from Outlook.

Migration Tracking

Setup a spreadsheet that contains the complete list of users who are to be migrated.  Include their user login names, email address, and full name details.   Add columns to cover events such as new Exchange mailbox, migration completed, and any other key migration events, such as setting a forwarder, or archives migrated.  Lastly, add a column to track the successful migration, and a comments field to cover any errors.    During the migration it is important to record any errors or problems, and press on to complete the overall migration.   Then you can re-visit the errors afterwards.

Do not be distracted by individual errors during the main migration events.  They can distract and delay you. However, if there are multiple common errors encountered, then these may point to a wider issue, that may need addressing with more immediacy.

Also, if any users need to be rolled back, you need to know the exact state of all your users during the migration.

Issues Register

Set up and maintain an Issues Register, into which you can log any issues reported during the email migration project.   These can be pilot issues, design issues, or general user issues.   This way, you can track, and manage all related issues, and assign actions to the relevant person(s) to resolve.  This puts you in control of any problems you may encounter, and provides a single document for the business sponsor to review on a weekly basis.