Analysis

1. Analysis Overview

In my opinion, the analysis 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.

The 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 usually 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 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 and one 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. It is the business reason you are deploying MetaFrame, i.e. the benefits that your customer is 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. You will need to discuss what they see as the goals of the project are and you will need to make sure that you are setting the proper expectations. In most cases, the customer might not understand completely what they want to accomplish. If this is the case, you will need to sit down with the customer and explain what MetaFrame can and cannot do for them. Then and only then will you be able to create a high-level list of goals that the deployment will address. Once documented, make sure that your customer reviews the Vision and signs off on it. Only then will you 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 break the project into five project management phases in which you will list the tasks that will need to be performed in order to achieve the vision.

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 that 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 required and more importantly, who in the router/firewall group is responsible for what tasks and by what date. Scoping of the project is something you will get better with over time, it is important for you to understand that the project scope. Also note that Methodology in a Box is just a starting point to turn you on to project management. In future versions I will be explaining more on this subject but in the mean time please refer to numerous project management site around the web and Citrix Consulting Services documentation for more information on this and other subjects found throughout this document.

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 determine 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. 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 will probably be necessary to modify the project scope to meet the goals of the vision based on new information found, decisions made or applications added. 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 an addition to the scope will result to a change in the time estimate, 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 basic Statement of Work.