Installation Planning - Part 2

When developing the installation checklist it is important to keep in mind that the purpose of the document is to assist the engineer, thus it should be formatted by the individual based on his/her preference.This provides flexibility to do what you feel is best and not contain yourself with formatting, proper language and etc...

Here how my installation checklists usually look. They have six columns, TaskID, Task, Server, Notes, OPR (Office of Primary Responsibility) and Status. Then, there are several sections, each section is usually a specific product or a mini milestone.

The first section is always Pre-Requisites, this section lists everything that needs to be done in preparation for installation. This includes actions on your side as well as clients. I include items such as service account generation, hardware/software per-requisites, required access, licenses, downloading software, anti-virus exclusions if necessary, people resources and etc... Trust me, when it comes down to documenting what is required, it is always safer to list an item rather than ignore it, or verbally communicate it. This provides a one stop area for checking off completed items and can easily be copied and pasted for dissemination.

The next step is Onsite Preparation. This section includes items such as verifying prerequisites, staging software etc... It is important to budget some time for this because unmet prerequisites can present unforeseen challenges down the road. From personal experience, I never deployed a solution for a client where all prerequisites were met like they were supposed to.

The next sections are dependent on the solution, I usually have a section for each product with a single step for particular components or sub components. For example:

3. Install Product XYZ (this is the section heading and doesn't count as an actual task).
3.1 Install Product XYZ
3.2 Install subcomponent a
3.3 Install subcomponent b
3.4 Configure integration between Product XYZ and SharePoint.
3.5 Test the integration

I recommend including basic functional testing in each section, this ensures that each solution component is individually tested.

After all component deployment sections I usually have a section for end to end testing, this is defined by the solution, but at a minimum the data flow should be tested, all connectivity, backups, reboots (to make sure everything starts as expected). Keep in mind that this testing section is not a replacement for formal solution testing, this is only to ensure that the installation of product was successful.

Last, I have a finalize section. This includes system testing, altering of logging parameters, as well as documentation of specific installation parameters and system information.

Installation Planning - Part 1

During the course of any project there will be a time when the system actually gets installed. This is a step in the overall roll out of a solution that generally lasts from a few days to a few months depending on the type of a system and number of locations being installed. By this time all requirements gathering, planning, system designs have been completed, socialized and approved. To be more specific, an engineering team is scheduled to go onsite to actually install and configure the software. 

A common mistake I see is the lack of documentation for this phase; usually it is a line item on a project plan with some high level milestones under it. From a project management perspective, that is all that is required to maintain visibility, however this lack of documentation can significantly hinder the project depending on the circumstances.

The solution is an installation planning document. I usually build these documents in excel and they have at least 6 columns. Task ID, Task Name, Task Notes, Assignee, Status and Time Spent. This turns into a list of steps that the system installer will need to perform to get the system installed. It needs to be as granular as you feel is necessary, I prefer to document each configuration file change, installation locations, ports, host names and paths for temp directories. I also like to add snippets of configuration files in the Task Notes column. Generating this document can be time consuming; however the content is re-usable and provides a great data set for estimating the schedule for future installations. 

Spending time generating these installation checklists are well worth the effort. There are some very practical engineering benefits. For example, in complex systems by generating the configuration files ahead of time, you may be able to spot certain issues with the configuration. These issues are much easier addressed if they are spotted prior to system installation.  

If you have multiple engineers installing the system, the checklist is a coordination lifesaver. Each engineer will know what they will need to do and having configuration files ahead of time ensures that all settings will match up and the system will operate when you turn it on.

There are advantages from the management standpoint as well. A key one is a peer review process, the installation checklist can be disseminated for review to senior engineers, architects and the system manufacturer. They may be able to spot issues with the configuration ahead of time or offer some improvement suggestions. This truly takes advantage of corporate reach back that so many large vendors claim they have.

Furthermore, this can actually decrease costs of implementation since the configurations can be developed off site by architects and senior engineers and the onsite installation can be performed by lower level systems engineers. Since all hard design work was completed ahead of time, the lower level systems engineers will not need to be as experienced. In this scenario the onsite installer can still call and reach a higher level engineer if trouble arises, but this frees up your architects and other corporate talent to work on more projects.

If the system is being deployed in multiple locations the installation checklist will ensure that the system installation methodology and configuration is the same. This will assist greatly if the maintenance of the system has to be transitioned to a different support group within an organization. Operations and Maintenance (O&M) will be a nightmare if each system is configured differently and planning upgrades will not be easy.

These are just some of the benefits of spending additional time planning the installation. In the next post I’ll share some techniques and tips on creating an effective system installation checklist.