Analysis

1. Analysis Overview

In my opinion, the analyses phase is the most important phase in the process.  When you complete it successfully, you will be well on your way to a successful deployment.  

Your goal for the analysis phase is twofold:  First is to prepare yourself with all of the information you will need to successfully plan, implement and rollout MetaFrame in the proposed environment.  Second is to present this to your customer in the form of a Project Plan and Infrastructure Assessment.   

The analysis phase is broken down into the following four segments:

       Vision / Project Scope (Statement of Work)

       Project Plan

       Infrastructure Assessment

       Proof of Concept

Deliverables are created for each of the above segments upon completion of that segment. 

I have also been known to call the Analysis phase the setting expectations phase.   What I mean by this is that during the process of completing each of the segments, you will be spending the bulk of your time in meetings with your customer asking questions and setting the rules for the project. 

Being a big fan of analogies, I like to explain it like this:  If two parties are playing a game and have a small wager on the outcome of the game. If one of the parties set the rules and draws the playbook, which one would you, bet on?  Obviously the one who makes the rules and draws the plays! 

With a little experience and the right know how, you will be able to set the rules to your advantage and guide your projects towards successful completions. 

The following is an example of an Analysis Phase Overview:

2. Vision / Project Scope (Statement of Work)

The first section you will address is performed prior to any obligation from the customer.  In this section you will create the vision and define the Project scope in the form of a Statement of Work (SOW). 

To define the vision is to define the project.  Its the business reason you are deploying MetaFrame, i.e. the benefits that yours customer are expecting to receive from a successful deployment.   All decisions made throughout the lifespan of a project will be verified against the vision.

A vision is derived from your customers goals and business case for the project.   You will need to set up a meeting with the customer to identify and quantify this.   Once documented, make sure that your customer reviews the Vision and signs off on it.  Only then will you will be ready to start on the project scope.

I like to break the project scope down to what I call in scope, out of scope.    This is probably the second most important element of the project, so be very careful in creating it.   You do this by creating a table that lists the vision and then breaks the project into four project management phases.  Each phase is then broken down into segments that identify all of the high level tasks needed to complete during each phase.

In the scope you need to list what you are responsible for, what you are NOT responsible for, what the customer is responsible for and the resources that you will be utilizing throughout the project. For example, if you are deploying MetaFrame for both LAN and WAN access, you will need modifications to the firewall which requires you to document who is responsible for those changes.  In some cases this may be you but more often, you will need to work with the party who is responsible for the routers/firewalls.   In this case, you will document the changes your roll will require and more importantly who, in the router/firewall group, is responsible for what tasks and by what date.  

You will also create a list of applications that will be deployed.  This will assist in defining the Project Plan and Proof of Concept and help you scope the time it will take to deploy in completing the project. 

You will want to make the SOW as comprehensive as possible and then present it to your customer in the form of a formal document during a formal meeting setting.  Note that it is important to get the individual or group(s) responsible involved, as it gives them a stake in the project.  

Your customer will now have the opportunity to engage your services and continue with the MetaFrame project as documented in the SOW. 

Throughout the lifespan of a project it might be necessary to modify the project scope to meet the goals of the vision based on new information found or decisions made or the addition of more applications.   If this is necessary, you will need to have the customer sign off on a change request, modify the scope and the estimated time for completion.  A successful project is one that not only achieves the vision but one that comes in on time.  From my experience, scope additions can and will cause a project to come in over the estimated time and dollars amount.  If you present your customer with the knowledge that any additions to the scope will require scope and time estimate to change, then you will have set the proper expectations.     Remember that in creating the scope, you are creating the rules and plays of the game and need to be as thorough as possible.

The following is an example of a complete Project Vision / Scope.

3. Project Plan

Now that you have finalized the Vision / Scope, you need to expand the scope and develop a detailed list of the tasks to be completed.   The desired audience for this document is the LAN/WAN Engineer who is not a project manager.  Therefore, I will provide two options for creating a comprehensive project plan; by hand or with Microsoft Project.  I know that not everybody is a MS Project expert, but I highly recommend spending the time necessary to learn how to use it as it is not that difficult.  When I first started creating projects for my jobs, I did everything by hand (Microsoft Word).  Then I went out and picked up a Dummies guide to Microsoft Project and was blown away by how much easier it made my job.   Please take a peek at it; I think you will be impressed with what you find.

Your project plan should consist of a list of every task that needs to be completed.  Each task should consist of the name and phone number of the individual responsible, any other parties that are needed to assist and an estimated timeframe for completion.   You should do this for each task in your project and with as much detail as possible.  Remember, it is necessary to go into as much detail as possible in order to set the proper expectations and to provide the necessary framework required to complete the project.

When estimating the time allotted for each phase, be very careful not to underestimate.   Time estimation is far from an exact science.  Remember to leave time for application tuning and troubleshooting.  In case you underestimate this, you will need to discuss with the customer any additional time needed to complete the project and why. 

At the end of the Analysis phase you will have a completed project plan.  Next you need to setup a meeting with your customer and have them sign off on the overall plan.     It is also important to make sure that your customer knows the project plan is not set in stone.  You will probably need to add or subtract items or go into greater detail as you move through the Design and the Implementation Phases.  Each time you make a change you will need to inform all parties and supply them with an updated copy of the plan. 

The following is a basic project plan for a small to medium size MetaFrame deployment: