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.

Solutions Engineering

So what is the difference between deploying a solution and a system? Sure, a system can be a solution to something, but deploying a solution has an entirely different scope of work. Deploying a system generally consists of having a few engineering sessions, going onsite to install it, doing some configurations, maybe migrating some data, training the customer and calling it done.

Deploying a solution is an entirely different ballgame and requires a different mindset from the client and the vendor standpoint. A solution will naturally have a system deployment component, but ultimately there are a lot of other moving pieces that contribute to program success.

Basically, there are a lot of other tasks involved in solution deployment to give the users a usable system that meets their needs. A prime example of this is training. In a solution deployment, you would not train users on the system; you would train them on the new business processing using the new system. Prior to training on the new business process using the new system, these processes would actually need to be re-defined, designed, developed, tested, deployed, vetted through user acceptance testing, re-designed and re-deployed and re-tested and re-vetted through users, etc… there is a lot of work involved.

Let’s go through a few differences on common deliverables between deploying systems and solutions. As a head up, I understand that all projects are different. It is certainly possible that some items from solution column bleed over to the system column. However, it’s important to acknowledge that when providing a solution you need to provide ALL of the pieces that make it complete. In other words, just because a system implementation has the project artifacts from the solutions column does not guarantee success. 

Deliverable	System	Solution
Technical Architecture	·         Hardware/Software Requirements ·         A few high level architecture drawings ·         Hardware is usually provided by the client	·         Hardware is usually included in the initial design ·         Environmental equipment such as load balancers, storage, networking, servers, KVM, UPSs are included in the design
System Documentation	·         System Manuals ·         Technical Support Number ·         CDs and License Keys	·         Installation Documentation ·         Configuration Documentation ·         Operations, Monitoring and Sustainment Plan ·         Test Plan ·         Migration Plan ·         Cut-Over Plan ·         Change Management Plan ·         Security Plan Project Documentation include: ·         Risk Management Plan ·         Training Plan ·         Communications Plan ·         Project Plan
Configuration	Only basic, essential configuration is implemented.	Specific to the client’s requirements.
Testing	Ensures the system and all components function as desired.	Tests the system under specific configuration of the client, usually involves load/stress testing, user acceptance testing, DR/HA testing, etc…
Change Management (Operations)	n/a	Perform change management to redefine existing business process to take advantage of new technology.
Change Management (IT)	Client makes any changes they want to the system.	Formal process for requesting, documenting, approving and implementing changes to the design.

Now that you’ve examined the list, I would ask you to reflect on your past experience with IT deployments and team members and ask yourself two questions: 

1)  Do you think some projects issues that you witnessed on previous projects could have been avoided by thinking in terms of a solution instead of a system?
2)  Who on the team is most suited to writing all of this documentation?

Most of this is Project Management 101; however, it’s very seldom implemented. Teams know that they should do it, but they choose not to, or the value of these artifacts is not stressed upon by the management. There is a lot of planning that needs to be done ahead of time for large solutions. This planning needs to be documented prior to system implementation. This does a few things, but one of the most important is that it creates the same expectation of the final product. This essentially defines