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:

4. Infrastructure Assessment

The infrastructure assessment (IA) section of the Analysis phase is one of the most overlooked sections of a successful project but is one of the most important to the perception of performance.  From my experience, a MetaFrame deployment will augment the environment you deploy into.  What I mean by this is that if you place a MetaFrame farm in a poorly laid out network you will most likely experience problems.  However, if you prepare your environment and deploy in to a network that meets the necessary requirements, your customer will love the outcome and you will make more money with less hassles.

During the Infrastructure Assessment, you will be tasked to document the readiness, requirements and considerations for each of the following sections.  This information will allow you and your customer to understand which areas of their current environment are ready for a rollout of MetaFrame and identify the ones where more attention is needed. 

Upon completion of the infrastructure assessment, you will be able to spot problem areas and make recommendations for changes that will let you achieve the vision. 

An Infrastructure Assessment is broken down into the following sections:

Network Architecture: The Network Architecture segment is very important but sometimes is completely overlooked.  Please give it the attention it deserves. Citrix is a great thing if you have a good network but can turn ugly real quick if the network infrastructure that you are installing into is not properly designed.  You will want to document what network protocols are on the wire, if they are using switches / hubs and how they are configured. You will document how they are segmenting the network (VLANS, subnets), what topologies are in play (Ethernet, Token Ring, ATM) and any bandwidth management software they may be running.

In order to make sure that you are not responsible for any possible security holes, you will want to discuss with your customer what security precautions they have in place I.E. (firewalls, access controls, and two factor authentication). You will also want to determine and document who has access to the physical presence of the hardware

Hardware Environment: You will want to document the vendor, the amount of memory, processors, disk drives, NIC(s) required and any additional hardware.

Operating Systems Environment: Window 2000 - you will need to document how the Active Directory is designed.   Document information such as: name resolution, pertinent IP addresses, OU structure and file/print structure. Parse through the login scripts for any possible issues, group membership, any users/groups that will has administrator access and any additional information that might be specific to your customers AD design. 

NT Server 4.0 - you will need to document how the NT domain is designed.   You will want to gather such information as: the Domain model (Single Domain, Multiple Domains, Multiple Master, etc), name resolution (WINS, DNS), file/print structure. Parse through the login scripts for any possible issues, group membership, any users/groups that will has administrator access and any additional information that might be specific to your customers domain design.

Novell Netware - you will need to document how the Novell network is designed.  You will want to gather such information as: what type of Novell directory services are they running, i.e. NDS, Bindery. If they are running NDS, you will want to document the NDS design (OUs, trees, etc.), name resolution, all the protocols that are running and their respective addresses. Parse through the login scripts for any possible issues, group membership, any users/groups that have administrator access, and any additional information that might be specific to your customers Netware design.

MetaFrame Environment: If you will be deploying into a network with an existing MetaFrame / WinFrame installation, you will need to verify the following: Farm Architecture, ICA Browser, Servers, Load Balancing, Network Structure, Users, Applications, Application Delivery and Licensing.

Printing Environment: If you have been around the Citrix world for awhile you will know that the print subsystem is one of the most finicky problem spots and requires proper configuration for optimum performance.  With this in mind you will want to make sure you do your best in analyzing your customers print environment.  You will need to document all the print servers for such things as what OS it is running, how the printers are attached and how many printers are on each print server. You will also need to document as many of the home / off-site printers as possible.  

I liked to throw this task in to the hands of my customer and task them with the responsibility of supplying me with a list of all the printers that need to be supported.  I also make sure that they are aware that any additional printers might require additional changes.

Client Environment: In a server-based computing environment you spend 99% of your time on the back-end but it is still important to know what type of client workstations you will be deploying into so that you can account and support them as needed.  You will want to document what operating systems you will need to support, if they are desktops or laptops, how the users will be connecting to the server and from what type of connection.  (RAS, ICA dial-in and or TCP/IP via the Internet)

Change Control Environment: The goal of any deployment is not only to successfully deploy the product but also to leave an environment that will not fall apart after you leave. This is done by creating policies and procedures on how future changes will be orchestrated.  This is what we call change management.   

In most cases you will not find any change control mechanism in place but this does not mean you will want to leave it that way.  Document any change procedures that might be in place, whom is able/responsible for making changes and inform your customer that you will be creating basic change control procedures for their new MetaFrame environment.

The following is an example of a basic Infrastructure Assessment finding:

5. Proof of Concept

In a Proof of Concept, (POC) you will want to create a small MetaFrame test environment to prove to your customer and yourself that a MetaFrame rollout is able to meet the vision set forth, i.e., if your vision is to deploy home grown application to doctors while adhering to HIPPA complicacy, then you will want to verify that the home grown application is compatible. 

Keeping with the scope of the document, this phase is somewhat of a quandary.  I mean, if you are deploying  common applications (Microsoft Office, GroupWise) over typical connections (Cable/DSL, Dialup) then from experience you will know that this is possible and dont really need a POC as this will add to the  expense.

On the other hand, if you will be deploying applications that you are unsure of,  or have little or no experience with, then you will want to do a basic Proof of Concept to verify that you will able to achieve the vision. 

If you will be conducting a POC, you will want to break it down into the following four phases:

1.        Develop Tests: Call a meeting with your customer to define the tests and acceptable results thresholds.

2.        Create Test Environment Start with a clean server, build a MetaFrame server, install any applications that are in question and run the tests that you defined in step 1.  Note that you should document all of the steps taken during the creation of the test environment.

3.        Make adjustments as necessary Once you have run your first round of tests you will want to take a step back and determine where tuning is needed in order to meet the vision.

4.        Document findings You will want to take the documents you created during step 2 and formalize them in form of OS and application installation procedures.   You will also want to document any issues you may have found and your recommendations for resolving them.

This is the last item in the Analysis phase, you are now ready to take your Proof of Concept document and present it as part of the Analysis Phase deliverable.

6. In Analysis - Checkpoint

You thought that we where never going to have any fun.   Now that you have completed the vision/scope, create a project plan, infrastructure assessment, started to design a project plan and finished the proof of concept, it is time to present your findings to your customer. You will deliver documentation that will be presented to your customer during a formal meeting.  

The Analysis Checkpoint document should contain the following sections:

       Preface

       Vision / Scope (Statement of Work)

       Infrastructure Assessment findings

       Proof of Concept assumptions and findings

       Statement of Work that defines scope, deliverables, estimated duration and costs for the design, Implementation, Readiness and Rollout phases.

You should assemble all the key players in the project, along with any of the money people and present the project and estimated times for completion.  At this point your customer can choose to continue with the project or bow out gracefully with the knowledge they have learned about their environment and the design requirements for a future MetaFrame deployment.   In the second case, you will walk away with a slew of service dollars along with a significant amount of additional knowledge and experience that will separate you from a break fix engineer to a Consultant. 

You will find the following examples and templates located in Methodology in a Box 1.0.  (MIAB1.0.ZIP)