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.

Requirements

Alice: Oh, no, no. I was just wondering if you could help me find my way.
Cheshire Cat: Well that depends on where you want to get to.
Alice: Oh, it really doesn't matter, as long as...
Cheshire Cat: Then it really doesn't matter which way you go.

The requirements are the start of it all. If there weren’t any we would all be in the unemployment line. Without solid requirements, the solution will never meet expectations. It’s as simple as that. Most of the information here is common sense and industry’s best practice; however it still gets ignored most of the time. You would be surprised at how many systems start being designed without requirements. There are a few things that I would like to add on top of the regular “requirements gathering” curriculum.

There are plenty of resources on requirements gathering and I will not attempt to explain the entire process, however here are some common pitfalls that I have seen:

●      Requirements gathering and validation is a very politically and fiscally challenging process. Few people realize that there is a very direct relationship between requirements and money. Simply said, the more you ask for, the more you will need to pay. If this is not acknowledged, the project team needs to help the customer manage expectations.

●      Another common mistake is for incorrect requirements, your requirement can’t be to buy product XYZ. The requirement needs to be for a system that provides functionality A, B and C. Based on this the project team should conduct market research and select the best product or a combination of products to meet the requirements.

●      The requirements shouldn’t be blindly accepted by the project team. If the information you need is not there, you need to take a step back and get the right information. This is sometimes difficult.

●      Nothing kills morale more than working for weeks in one direction only to find that the requirements weren’t accurately documented and having to shift gears.

●      Requirements are complete when all requirements have been documented and mapped to validation criteria which in turn map to validation scenarios. Documentation of requirements is essential because it communicates the requirements to all parties involved. Language in the document needs to be plain, clear and specific.