How to Undertake a Proof-of-Concept - Citrix Knowledge Center

How to Successfully Implement a MetaFrame Proof-of-
Concept (POC)
By Citrix Consulting Services
Citrix Systems, Inc.

Notice
The information in this publication is subject to change without notice.
THIS PUBLICATION IS PROVIDED “AS IS” WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED,
INCLUDING ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-
INFRINGEMENT. CITRIX SYSTEMS, INC. (“CITRIX”), SHALL NOT BE LIABLE FOR TECHNICAL OR EDITORIAL
ERRORS OR OMISSIONS CONTAINED HEREIN, NOR FOR DIRECT, INCIDENTAL, CONSEQUENTIAL OR ANY OTHER
DAMAGES RESULTING FROM THE FURNISHING, PERFORMANCE, OR USE OF THIS PUBLICATION, EVEN IF CITRIX
HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES IN ADVANCE.
This publication contains information protected by copyright. Except for internal distribution, no part of this publication may
be photocopied or reproduced in any form without prior written consent from Citrix.
The exclusive warranty for Citrix products, if any, is stated in the product documentation accompanying such products.
Citrix does not warrant products other than its own.
Product names mentioned herein may be trademarks and/or registered trademarks of their respective companies.
Copyright © 2003 Citrix Systems, Inc., 851 W. Cypress Creek Road, Ft. Lauderdale, Florida 33309 U.S.A. All rights
reserved.
Version History
1.0 Citrix Consulting Services 2002

Table of Contents
TABLE OF CONTENTS ................................................................................................................................................................ III
INTRODUCTION ............................................................................................................................................................................ 1
PROJECT REQUIREMENTS......................................................................................................................................................... 3
CURRENT ENVIRONMENT................................................................................................................................................................ 3
PROJECT OBJECTIVES ................................................................................................................................................................... 3
BUDGET PLANNING........................................................................................................................................................................ 4
PROJECT SCHEDULE...................................................................................................................................................................... 4
USER PLANNING.......................................................................................................................................................................... 5
USER GROUPS.............................................................................................................................................................................. 5
USER MANAGEMENT...................................................................................................................................................................... 5
USER COMMUNICATIONS ................................................................................................................................................................ 5
USER CONVERSION AND TRAINING .................................................................................................................................................. 5
NETWORK PLANNING ................................................................................................................................................................. 6
DOMAIN CONSIDERATIONS.............................................................................................................................................................. 6
OPERATING SYSTEM CHOICES – WINDOWS NT 4.0 VS. WINDOWS 2000............................................................................................ 6
PROFILE MANAGEMENT AND DESIGN ............................................................................................................................................... 6
SYSTEM SECURITY AND POLICIES ................................................................................................................................................... 6
SERVER ACCESS FOR HOST SYSTEMS............................................................................................................................................. 7
SERVER ACCESS FOR DATABASE SYSTEMS ..................................................................................................................................... 7
SERVER ACCESS FOR FILE SERVERS............................................................................................................................................... 7
VIRUS PROTECTION ....................................................................................................................................................................... 7
PRINT SERVERS ............................................................................................................................................................................ 7
PRINTERS ..................................................................................................................................................................................... 7
SYSTEM BACKUP........................................................................................................................................................................... 7
NETWORK SEGMENTATION ............................................................................................................................................................. 8
NETWORK ANALYSIS...................................................................................................................................................................... 8
REMOTE ACCESS .......................................................................................................................................................................... 8
WAN ACCESS .............................................................................................................................................................................. 8
METAFRAME DESIGN .................................................................................................................................................................. 9
How to Successfully Implement a MetaFrame Proof-of-Concept (POC) iii

WINDOWS BASED TERMINALS......................................................................................................................................................... 9
PC CLIENTS ................................................................................................................................................................................. 9
CONSOLE VS. PUBLISHED APPLICATIONS ......................................................................................................................................... 9
PUBLISHED DESKTOP..................................................................................................................................................................... 9
PROGRAM NEIGHBORHOOD VS. NFUSE CLASSIC .............................................................................................................................. 9
HARDWARE CONFIGURATION/SIZING ............................................................................................................................................... 9
APPLICATION DESIGN................................................................................................................................................................... 10
APPLICATION INSTALLATION.......................................................................................................................................................... 10
LOGIN SCRIPTS ........................................................................................................................................................................... 10
TEST/STAGING ENVIRONMENT ...................................................................................................................................................... 10
PRINT DESIGN............................................................................................................................................................................. 10
LOAD BALANCING ........................................................................................................................................................................ 11
IMPLEMENTATION ..................................................................................................................................................................... 12
UNATTENDED BUILD PROCESS...................................................................................................................................................... 12
CLIENT CONFIGURATION AND DELIVERY......................................................................................................................................... 12
RESOURCE/PERSONNEL PLANNING ............................................................................................................................................... 12
SYSTEM SUPPORT..................................................................................................................................................................... 13
SUPPORT REQUIREMENTS............................................................................................................................................................ 13
LEGACY AND CUSTOM APPLICATIONS ............................................................................................................................................ 13
SERVER ADMINISTRATION............................................................................................................................................................. 13
DEDICATED USER SUPPORT ......................................................................................................................................................... 13
ISSUE TRACKING ......................................................................................................................................................................... 13
CORPORATE HELP DESKS ............................................................................................................................................................ 13
DISASTER RECOVERY PLANNING................................................................................................................................................... 13
RESULTS ANALYSIS.................................................................................................................................................................. 14
USER INTERVIEWS....................................................................................................................................................................... 14
ISSUE REVIEW............................................................................................................................................................................. 14
IMPLEMENTATION REVIEW ............................................................................................................................................................ 14
SCALABILITY REVIEW ................................................................................................................................................................... 14
ADMINISTRATION REVIEW............................................................................................................................................................. 14
FINAL PROJECT ANALYSIS ............................................................................................................................................................ 14
How to Successfully Implement a MetaFrame Proof-of-Concept (POC) iv

Introduction
The objective of this document is to provide a high-level analysis and checklist of all elements and
attributes necessary to successfully implement a MetaFrame proof-of-concept (POC). The POC is the
initial step prior to undertaking a detailed system design and implementation, and is intended to function as
a prototype system, much like a prototype car from GM or Ford. It is meant to demonstrate key
technologies, as well as provide an environment for experimentation and evaluation. The design and
implementation of a POC, while very detailed and organized, does not serve as a replacement for a
complete system analysis and design.
The standard progression on MetaFrame projects will entail the following steps:
• Proof-of-Concept – Technology and Process demonstration/evaluation
• Enterprise System Analysis & Design – Detailed process planning, analysis, and system design
• Production Pilot Implementation –The pilot should be implemented exactly as defined in the
Enterprise System Analysis & Design, but on a limited scale
• Full Scale Production Implementation – Complete system implementation and user conversion
For the purposes of this document, a proof-of-concept will be defined as a limited implementation.
However, unlike a production pilot, the proof-of-concept will have the following limitations:
• All users will have redundant means of accomplishing tasks – usually through desktop installations.
• Usually no more than 50 users will actively use the proof-of-concept. More commonly, the number will
rarely exceed 10 users.
• Hardware and architecture limitations that are not critical for success will not be addressed.
• Compromises will be made to accommodate the smaller scale of the implementation.
• Only critical path applications will be analyzed and delivered through the MetaFrame system.
• The capacity of the server environment should comfortably exceed the planned system utilization
levels.
• The MetaFrame farm and servers should be on a separate network from production systems.
• Hardware and network planning must include network/server access to:
o Required database servers.
o Required host/legacy systems.
o Required file servers.
• Domain administrators must plan for user and group architecture modifications necessary to implement
a proper MetaFrame design.
• The user community and managers must clearly understand that the system is not a full production
system and that availability will not be 24 x 7.
How to Successfully Implement a MetaFrame Proof-of-Concept (POC) 1

• Complete success is not an entry criterion for the proof-of-concept. A proof-of-concept is a technology
demonstration, meant to uncover issues and identify critical design issues.
• The system architecture may change over the course of the project. These changes will be driven by a
need to implement critical design changes discovered over the duration of the proof-of-concept.
• The project duration will be defined and limited, with the proof-of-concept system rarely active for more
than 30 days. A more common scenario would be a 1-2 week evaluation / implementation of the POC.
Scope control and project management will be critical throughout the proof-of-concept. Clients must clearly
articulate project goals and objectives. These goals must then be translated into requirements, and a
complete (though limited in scale) system design must be created and implemented. Throughout this
process, concise and consistent communication with the user community will be critical. Network and
system analysis can capture and analyze the objective data gathered over the course of the POC, but the
users will often provide the more critical subjective data necessary to uncover issues with either the design
or applications.
How to Successfully Implement a MetaFrame Proof-of-Concept (POC) 2

Project Requirements
Current Environment
A thorough analysis of the current environment should be made prior to undertaking the POC. The project planners
should concentrate on:
• Current desktop configuration methods, such as system imaging
• Current support requirements
• Current support costs
• Known application issues
• Network performance
• Critical applications
Project Objectives
Prior to undertaking a proof-of-concept, the project planners must clearly define their goals and objectives. Often,
these objectives fall into three categories:
• Corporate Objectives: High-level goals that focus on a reduction in overall system cost, as well as seeking a
method to improve system redundancy and reduce IT related incidents that reduce employee effectiveness.
Often, these requirements are linked to a search for an enterprise solution that could be leveraged throughout the
company.
• Management Objectives: Mid-level goals that focus on addressing specific deployment/integration issues.
These often include:
o Deploying specific ERP applications.
o Reducing desktop support activities.
o Correcting specific application issues, such as slow WAN performance.
o Deploying applications to users faster, with fewer resources.
o Enhancing network security and streamlining user deployment/configuration.
• User Objectives: Low-level goals that focus on the quality of service provided by the desktop or Windows-based
terminal configuration:
o Faster application performance.
o Enhanced application stability.
o Faster issue resolution.
o Better access to new applications.
• Success Criteria: Objectives that must be met in order to determine the success of the POC:
o Application availability/connectivity.
How to Successfully Implement a MetaFrame Proof-of-Concept (POC) 3

o Application functionality.
o High-level scalability indicators.
Budget Planning
The single largest factor controlling the scope of a POC will be the budget constraints. Prior to undertaking a POC, a
concise and realistic budget must be established. This does not include simply funding for outside resources and
hardware. The budget planning process must include:
• Funds for third party consultants, such as Citrix Consulting Services.
• Funds for additional project personnel, such as contractor resources.
• Hardware and network devices that could be used in the proof-of-concept.
• Internal department budgeting to ensure client resources are available to support and learn from the POC.
• Funds to purchase software necessary for the pilot (i.e. virus scanning software compatible with Terminal
Services).
Project Schedule
A POC is not an open-ended project. It is a limited implementation for a fixed period of time. The project duration will
be a direct result of the project objectives. As a basic guideline, a POC should not exceed 30 days. This duration does
not include project time necessary to plan, design, and implement the POC system. When these items are factored in,
a POC could extend over a 90-day period.
Whatever project duration is ultimately chosen, project management should actively work to control scope. Project
management should resist the urge to extend the project into a production pilot without performing a detailed enterprise
analysis & design.
How to Successfully Implement a MetaFrame Proof-of-Concept (POC) 4

User Planning
User Groups
Project management should work to identify a representative sample of users/user groups. If the goal of the POC is to
deploy SAP on MetaFrame, then identify the departments that currently use SAP. Ensure that the users are familiar
with the environment and will not confuse application issues with system issues. Relying on a homogenous sampling
of users for a POC will reduce the effectiveness of the project. Additionally, this may lead to critical issues being
overlooked.
User Management
A user’s manager is often a critical component that is overlooked in a POC. The manager must rely on their
employees to accomplish critical tasks, and this process may be affected if the user is participating in a POC. The
manager must understand the critical nature of the POC, as well as the role they will play in evaluating the overall
effectiveness of the system. If the manager is not educated and included in project planning, too often users may be
removed from a POC prematurely.
User Communications
A regular method of communicating with the user community should be planned and implemented throughout the
course of the POC. Project management must remember that feedback is a cyclical process, and that users are often
more responsive if they participate in the POC. The best method to ensure this is a consistent communications
process that details:
• Issues encountered
• Progress made on issues
• Public recognition of user participation
• Hints, Tips, and Tricks
Project management must remember that these users will become a critical factor in any large-scale deployment.
Often, they will become the power users that train others. However, if they perceive their contribution as negligible,
they may develop a negative view of the project. This can be a significant hurdle to overcome, and is best avoided by
handling the project in an open, professional fashion.
User Conversion and Training
Some level of training and user documentation must be provided. Users cannot be blindly placed into a MetaFrame
POC environment without feeling overwhelmed and unfamiliar. It is critical that the conversion process proceeds
smoothly and that users are given the opportunity to succeed on the system. If users are not transitioned and trained
properly, then the subjective opinions and issues that are captured from the POC will focus on non-critical items.
How to Successfully Implement a MetaFrame Proof-of-Concept (POC) 5

Network Planning
Domain Considerations
Placing all users within a new domain can often reduce the administration of the POC. In addition to the reduced
administration, this approach will focus control and management of the users to the POC project team. This flexibility,
as well as the assurance that the POC does not impact the production domain, can be significant factors when
determining if a separate POC domain will be necessary.
Operating System Choices – Windows NT 4.0 vs. Windows 2000
When choosing an operating system, a number of factors must be considered:
• Are all applications compatible with Windows NT 4.0/Windows 2000?
• Is a migration planned to Windows 2000?
• Does the POC have as a goal to test Active Directory?
• If Active Directory is to be deployed, will the client systems be upgraded to Windows 2000 Professional?
• Are there 16-bit applications that require application compatibility flags? If so, Windows 2000 is a poor choice, as
it is not configured to use those settings.
Profile Management and Design
A critical aspect of network planning is choosing between two profile types:
• Roaming -- The roaming profile provides the greatest level of flexibility and personalization. However, it is slower
on login as data must be copied from the network to the local server. Proper planning can reduce this effect
through the implementation of folder redirection.
• Mandatory -- The mandatory profile provides the greatest level of control, but will not allow users to customize and
retain their personal settings. In addition to control, the mandatory profile will usually provide the fastest login time.
Whichever choice is made, it is critical that the project team considers the implications of each choice and reconciles
that against the project schedule and project goals.
System Security and Policies
The integrity of the servers must be assured through the implementation of NTFS permissions on the local servers.
However, this must be tested with the client applications, as some applications require access to local disk resources
and will not run with a tightly controlled system.
Beyond NTFS permissions, policies need to be planned and implemented that control what the user community can do
and access. A number of policy templates are available for specific application control, such as:
• Outlook
• Word
• Internet Explorer
How to Successfully Implement a MetaFrame Proof-of-Concept (POC) 6

Server Access for Host Systems
If the MetaFrame servers will be running terminal emulator software, or X-Windows software, then those servers will
need to access their respective host systems. Project planners must account for this and ensure that the servers are
configured to successfully work with these host systems.
Server Access for Database Systems
Many applications require database access, and both ODBC drivers and network configuration often control this
access. Project planners must account for this, as well as resolve any driver incompatibility issues, either through
physical separation or application upgrades.
Server Access for File Servers
In nearly all enterprise environments, it is necessary for users to store data on network file servers. Since the local
MetaFrame server is tightly controlled and should not be used as a file server, the POC servers will require access to
network file servers.
Virus Protection
Virus protection software is critical in any network implementation. However, Terminal Services/MetaFrame
environments present a unique challenge, as a limited number of anti-virus software providers support this type of
environment. If the anti-virus software currently used is not compatible (with either Terminal Services/MetaFrame or
the operating system), then it may be necessary to purchase the proper software package.
Print Servers
In a LAN environment, the use of IP-based printing through print servers provides a significant level of control and
stability for a POC printer environment. The project team should evaluate all printing options, including leveraging
existing print servers for the delivery of print requests.
Printers
For the purpose of the POC, if printers are to be auto-created, then the POC should research and support only a limited
number of printers and print drivers. Supporting a significant number of printers can present serious logistical and
planning challenges that may hamper the effectiveness of the POC.
System Backup
Backup schedules should be identified and the servers, as well as users’ home directories/files should be backed up
nightly. It is also useful to ensure that the servers are not on the same network segment as the backup servers, as
they might compete with the backup servers for bandwidth during the backup process.
How to Successfully Implement a MetaFrame Proof-of-Concept (POC) 7

Network Segmentation
Physically isolating the POC on a separate subnet can help to enhance system stability, as well as reduce the impact
of other MetaFrame servers being placed on the network. This becomes especially critical if an existing MetaFrame
farm is in production and the project team desires to minimize project risk.
Network Analysis
Network analysis tools may become a necessary element in helping to resolve or tune the MetaFrame POC
environment. It is often useful to establish a baseline analysis prior to implementing the POC, thereby identifying any
potential network issues that could impact the environment.
Remote Access
If a critical goal of the project is to deliver application functionality to remote users, then the project team must research
the support and integration of various remote access solutions. Possible options are:
• Shiva or similar systems
• Microsoft’s RAS with modem banks
• Citrix’s direct dial functionality with modems
WAN Access
WAN links are often limited to between 256k and 56K frame relay connections. Prior to implementation, the project
team should analyze utilization levels and plan for handling multiple scenarios that may impact bandwidth, including:
• File copies
• COM port mapping
How to Successfully Implement a MetaFrame Proof-of-Concept (POC) 8

MetaFrame Design
Windows Based Terminals
Windows based terminals (WBT) offer the advantage of centralized control and relatively inexpensive client hardware.
However, if there is a requirement to run applications locally, WBTs may not be the best option. The project team
should research the operating system options available with WBTs and determine if their needs can be met by these
systems. The current supported operating systems are Windows CE, embedded Windows NT 4.0 Workstation, and
embedded Windows XP Professional.
PC Clients
PC clients offer the greatest flexibility, but often continue to require ongoing desktop support – a significant cost factor
for any enterprise. However, for the purposes of the POC, the PC client provides the maximum redundancy, as the
users can immediately switch to their desktop should the POC environment experience difficulties.
Console vs. Published Applications
The simplest MetaFrame and Terminal Services/RDP implementations deliver a complete desktop. In simplest terms,
the user connects to a specific system and accesses only those applications that are installed locally on the server.
The sole advantage of this approach is simplicity, but the use of a console does not provide the scalability and flexibility
required by most enterprise environments. More often, servers are categorized and organized by application groups.
These applications are then published through the server farm, and the system will load balance the applications at the
time a user connects. While more complex, this is the preferred architecture, especially for a POC.
Published Desktop
Project management must determine if the user community requires a desktop. Depending on the sophistication of the
users, delivery of individual applications can cause confusion. Planning must account for this and determine if a
published desktop should be supported.
Program Neighborhood vs. NFuse Classic
Program Neighborhood is the Win32 client most commonly used to deliver application sets to a user’s desktop.
However, many enterprises are increasingly exploring the use of NFuse Classic (either through a portal or through the
default site) to deliver applications through a corporate portal. NFuse can simplify client deployment, as well as provide
a seamless method of transitioning users to the MetaFrame POC. In many cases, all that is required of the client is a
browser and the address of the NFuse web site. However, if NFuse is to be used, then a separate web-server should
be configured to host the POC NFuse site.
Hardware Configuration/Sizing
Hardware configuration and sizing is dependent upon a number of factors:
• Maximum number of concurrent users
• Maximum number of processes/session/server
How to Successfully Implement a MetaFrame Proof-of-Concept (POC) 9

• Process/Program CPU and memory utilization
In order to control these factors, it is often desirable to publish a limited number of applications throughout the POC and
utilize Citrix Resource Manager or a performance-monitoring tool to capture actual utilization levels. In general terms, it
will be critical that the hardware provided for the POC provide significant overcapacity. As the POC progresses, if the
servers are sharply underutilized, it will be a simple matter to remove server capacity. However, the need for additional
capacity is usually discovered through poor performance and user issues.
Application Design
Applications should be analyzed and grouped by functionality and expected utilization levels. It is critical that items
such as ODBC drivers and Oracle client versions be considered, as often this will drive the requirement that
applications be physically separated on different MetaFrame servers. If possible, the POC should be implemented
utilizing rough generalizations. This ‘strawman’ design can be modified over the course of the POC as the system is
analyzed.
Application Installation
If possible, applications should not be manually installed onto MetaFrame servers. Manual installation can be prone to
error and may introduce configuration variances that may make issue resolution difficult and more time-consuming.
The options that should be explored are:
• Automated installation
• Package installation (such as through Wyse)
• Citrix Installation Manager
• Installation during an unattended installation/server build
Login Scripts
Login scripts are used in a MetaFrame environment to configure the user’s environment and modify critical registry
entries necessary for proper application execution. However, the POC should seek to limit the complexity of the login
script to critical functionality only.
Test/Staging Environment
Throughout the POC, no application or environment changes should be implemented unless they have been tested
and reviewed in a test environment or application staging server(s).
Print Design
Print management and design often prove critical to any MetaFrame implementation. The project team must plan for:
• Multiple print drivers
• Print driver distribution/replication
• Client printer mapping
• IP-based printing
How to Successfully Implement a MetaFrame Proof-of-Concept (POC) 10

• Default printer mapping
Load Balancing
Throughout the POC, the project team should review the load balancing settings and attempt to design a configuration
that ensures optimal efficiency. At the start of the POC, the sole load evaluator that should be configured is the Default
load evaluator. As other performance metrics are analyzed, they should be modified in a controlled and monitored
fashion to ensure an accurate understanding of the impact on the POC system.
How to Successfully Implement a MetaFrame Proof-of-Concept (POC) 11

Implementation
Unattended Build Process
If possible, all servers should be built with an unattended build process. Designing and implementing this will ensure
consistent server configuration, as well as lead to a faster system deployment. In addition to automating the server
build procedures, if possible, applications should be installed in an automated fashion. Automating the build and
installation procedures will provide valuable input into the best methods for handling large scale enterprise
deployments, as well as providing a basis for designing the production automation processes.
Client Configuration and Delivery
Client configuration and delivery should be automated, either through the NFuse website or through client automation
software. This will ensure a consistent client configuration, as well as provide a method for deploying client updates
and modifications. While not an absolute requirement of the POC, the POC is intended to explore options for handling
the issues expected in a large-scale implementation. When the final production system is designed and implemented,
the information gathered through the efforts undertaken in the POC will help to ensure a rapid and efficient
design/deployment.
Resource/Personnel Planning
Project resources will be required for the following areas:
• Client deployment
• Training
• User deployment
• Implementation
• User support
• System administration
• Project management
How to Successfully Implement a MetaFrame Proof-of-Concept (POC) 12

System Support
Support Requirements
The support requirements for a server-based system are somewhat different than desktop support requirements.
Project management should treat the POC as a data center implementation, with requirements to provide 7x24 help
desk and system administration support. This can prove to be critical, as multiple users are impacted when the server
system is compromised. A quality design and implementation will provide levels of redundancy, but all effort must be
made to ensure that even the POC is available 99.999% of the time.
Legacy and Custom Applications
Often, over the course of the POC, legacy and custom applications will experience issues. In many cases, these
issues will mistakenly be ascribed to the POC system. Support personnel should establish a means of obtaining the
latest enterprise alerts, as well as pro-actively helping to notify the POC user community of any impending issues.
Server Administration
Dedicated POC system administration must be planned and provided throughout the project.
Dedicated User Support
Dedicated user support should be provided throughout the POC. This will help to minimize the impact of issues, as
well as provide resources that can assist with user training and issue resolution.
Issue Tracking
It is imperative that all user and system issues be tracked and prioritized. This should be a systematic process, such
as spreadsheet or database application. The issues should be reviewed weekly and when resolved, the concerned
parties should be notified (such as the user’s manager).
Corporate Help Desks
Often, users are familiar and comfortable with relying on the corporate help desk to log issues and help resolve
problems. The corporate help desk should be trained on simple POC issue resolution, and all issues captured by them
should be forwarded to the POC project team.
Disaster Recovery Planning
A disaster recovery plan should be available when the POC is activated. This plan should focus on coordinating with
the enterprise administrators and help desk to provide timely and efficient system recovery. In addition to this, the POC
architecture should be highly redundant. A simple means of implementing this is to ensure that applications are
published on at least two MetaFrame servers.
How to Successfully Implement a MetaFrame Proof-of-Concept (POC) 13

Results Analysis
User Interviews
Users should be interviewed through the project to obtain their critical and subjective impressions of the system. Often,
this information can be used to fine-tune the support, deployment, and architecture of future MetaFrame systems. The
value of this information cannot be discounted. The system exists to serve the needs of the user community, and no
issue is too small to note, and hopefully resolve.
Issue Review
When the POC is complete, as detailed review of all issues and solutions should be prepared. This information may
help to identify opportunities and modifications that may be applied in later implementations.
Implementation Review
How well did the initial implementation and deployment proceed? Could the project team have accomplished key tasks
better? What was the impact on the users? Were the users satisfied? Was this a painless process? How would a
large-scale implementation be handled?
Scalability Review
RMS reports and subjective analysis should be completed to determine system scalability figures. This information will
be used to calculate initial capital costs for the deployment of either a pilot or full-scale system implementation.
Administration Review
How well did the project processes work? Was the system project administration effective? Did the users perceive
that issues were quickly resolved? How would the administrative aspects of this project scale to handle an enterprise
deployment?
Final Project Analysis
What were the final lessons learned from this project? Should the system be deployed on a larger scale? Were all the
project objectives met? Would this project be characterized as a success?
How to Successfully Implement a MetaFrame Proof-of-Concept (POC) 14

851 W. Cypress Creek Road Fort Lauderdale, FL 33309 954-267-3000 http://www.citrix.com
Copyright © 2000 Citrix Systems, Inc. All rights reserved. Citrix, WinFrame and ICA are registered trademarks, and MultiWin and
MetaFrame are trademarks of Citrix Systems, Inc. All other products and services are trademarks or service marks of their respective
companies. Technical specifications and availability are subject to change without prior notice.