project mandate - my.anglia homepage

Project MandateApproval to proceed to Project Planning Phase

Project Name:Desktop 2009 Feasibility Project

IS-Project Code: IS-0021 Capital Steering Committee Code (if applicable)

Project Description:This strategic transformation project will establish the foundations for the modernisation and enhancement of the service received by students and staff as customers of our University’s desktop and key business applications. It will specifically focus on:

1) Providing access to applications quickly and easily to all who have a need regardless of location. This will include the delivery of applications across the Internet and, wherever possible, will be end-device independent.

2) Reducing the high direct and indirect effort, capital and revenue costs associated with desktop software provision and support.

3) Ensuring that we are keeping our carbon footprint to a minimum.

4) Helping assist us in achieving IS140001 quality accreditation. The ISO 14000 family addresses various aspects of environmental management.

5) Helping improve student satisfaction which is one of the Corporate Plan objectives in that that 9 out of 10 students will recommend us to a friend.

6) Replacement of the ageing desktop infrastructure which will help with staff productivity through more reliable equipment.

Purpose of Mandate To seek approval for a feasibility study to be undertaken which will;

Identify the potential for implementing thin client technology.

Identify the technology options available including costs/savings using the technical hypothesis articulated in paragraph 10.

Identify the applications capable of being converted and those that could be problematic.

Show the benefits in cost terms for implementing thin client. Provide a prioritised requirements list following a requirements gathering

workshop involving service and Faculty representatives. Provide a small pilot to demonstrate the capabilities of thin client. Plan for a Programme of desktop replacements. Submission of a Project Planning Document for the first implementation

phase.

Prepared By: Alec Coleman Date: October 2008

Project Sponsor Approval

/tt/file_convert/55cf6bbabb61eb39588b4701/document.doc of 14 Version:

FORM – PMv3

Project Sponsor: Ajay Burlingham-Böhr Title:

Contact Details of Sponsor: 0845 196 2853

Signature: Date:

ITSG Approval (if Escalated)

Result: Approve / Reject / Change /

Hold / Escalate

Date:

Name: Signature:

Comments:

To maximise the chance of the project being accepted, please complete the form in conjunction with the guidance notes


FORM – PMv3

Version Control Sheet - Change History

Version Section Reason / Description Author Date

1.0 All First Draft Alec Coleman 4/9/08

1.1 All Including initial comments from Gregor Waddell following meeting on 2 Oct

Alec Coleman 6/10/08

1.2 All Including comments from Nicky Morland, Rob Spalding and Dave Willis.


1.3 All Including comments from Gregor, Dave Willis and Carrianne Baker


1.4 All Including comments from Ajay, Gregor, Nicky and Chris Herbert, ALSS. Plus further comments from Gregor on the potential for a more limited pilot of Server Based computing only depending on resource availability


1.5 All Update from meeting held 23/10 attended by Ajay, Gregor Waddell, Joe McIntyre, and Nicky Morland.


1.6 All Added comments from Alex Collins and Mark Norman.



FORM – PMv3

1. Project Background (A brief introduction to the project, including the project context, history and who has been involved to date)

Anglia Ruskin University currently operates a disparate and incoherent legacy estate of approximately 4500 laptops, Macintoshes and PC workstations. This has led to high support, management and update costs for the University.

With the increasing cost of utilities and the ever-important sustainability agenda, it is necessary to review the use and potentially disposal of PC’s and consider whether there is a lower cost, more sustainable technology for delivering applications to users to enable them to do their jobs more effectively.

Pressure is being brought to bear with the 2010 Carbon Reduction Commitment in which HEI’s are expected to play a part. The University is to adopt best practises in order to reduce our carbon footprint – computers switched off overnight, reduce the power consumption and heat output.

There is currently little centralised purchasing, management or support. It is difficult to respond quickly to customer need. Key business and desktop applications are sometimes unavailable when required. There is a limited ability to respond to unforeseen circumstances, business continuity and disaster recovery requirements.

No formal or consistent approach to managing specialist applications exists. Access to applications is limited and often difficult from outside our University local areas networks. Where access can be provided, the lack of a consistent user friendly interface makes the experience cumbersome and time consuming. Large effort is required to roll-out critical security updates to the estate, leaving key systems vulnerable to virus and Trojan attack.

These issues and problems have led to too much effort being spent on fire-fighting and short term response. This, in turn, has led to a failure to address longer term business need.

Anglia Ruskin currently operates a distributed budget scheme. Hardware and software are purchased independently by each faculty and department. Although the central service units provide standards and negotiate preferred suppliers the existing governance is ineffective and equipment can be purchased without reference to University specifications.

Workstations are associated with faculties and service units, as opposed to the organisation as a whole, and equipment distribution is based on the availability of local funds rather than identified business requirements. When items are replaced, cascades occur only within, rather than between, faculties and service units. The result is an uneven spread of quality PCs and many “poor relations”.

There are a large number of workstation images currently in use across the estate as a result of the organic and relatively unplanned growth of IT across our University.

This feasibility study will address these issues through a consistent build using virtual desktops and thin client technology. The study will build upon the findings from the small scale installation of 34 thin client devices terminals already installed in the teaching area of the new Faculty building and will consider their wider deployment throughout our University with a small pilot and requirements gathering workshop. It is recognised that it is possible that this technology will not be appropriate for all users.

The study will also inform the Cambridge Master Plan 2009.


FORM – PMv3

2. Project Aim and Drivers for Change (The rationale for why the project should take place, clear definition of what the project is intended to achieve and the opportunities to be realised)

The drivers are:

● An aging PC and laptop environment;● Costly to support and manage – e.g. thin clients do not generally require maintenance or

support team visits. ISMS Customer Support team estimate that they make around 30 PC visits per week representing at least £40,000 of time. The key benefit of this project from Ajay’s point of view is that it should reduce the workload on our support and operational resources.

● Data security – the need for improved Data Protection and Software license controls. ● Lack of flexibility / agility to meet changing customer demand;● Heat output and power consumption is increasingly important. According to a recent study by

ISMS Architecture and Development team, the difference in cost between 1000 thin client devices and PCs could be £32,000 - £200,000. (£32k if used 9-5pm, £200k if left on 24x7).

● The promise of new technology● Thin client devices have a longer life time than PC’s so refresh intervals are less frequent.

The aims of the project are:

To conduct a feasibility study lasting 3 months to look at the current PC estate using the learning from a proof of concept thin client implementation in the Faculty building. This will involve :

o A requirements gathering workshop with representatives from the business including students;

o Use of in-house ISMS resources rather than use external consultancy;o Production of a prioritised requirements list;o Documenting the technical architecture for a pilot;o A small scale pilot of up to 100 devices in each category of user;o Provision of a technical architecture for wider deployment. This will document the

technology options available including costs and will be based on a working hypothesis articulated for the technology in paragraph 10;

o Identification of the applications capable of being converted;o Provision of more detailed benefits in cost terms for implementing thin client;o To produce a Project Planning Document for the next phase of the project.

Earlier work undertaken by Architecture and Development team has identified 4 categories of user within our University. The following table shows each user category and lists which technology will be used as follows:

Type A. Kiosk provision e.g. in open access areas – minimal client install (e.g. Office and Adobe) (approximately 700 PCs);

Type B. Undemanding user – minimal client install (Office Pro and Adobe 80%) plus very few simple applications (approximately 400 PCs)

Type C. Undemanding business application user e.g. SITS, HR, Finance (approximately 1100 PCs);

Type D. Demanding resource-hungry user – various applications, high processor or graphics demand - may have admin rights. Non Windows, Mac’s (approximately 1800 Macs & PCs);

Technology Proposed

Thin client. Business

As type A As type A Will retain desktops but


FORM – PMv3

applications will be delivered via either Windows Terminal Services; Microsoft Office applications will be installed on and delivered via a virtualised desktop. Other applications will also be installed on and delivered via a virtualised desktop.

business applications will be delivered via Terminal Services.

Staff √ √ √ √Student √ √Other

It is worth noting that we would expect to retain newly purchased PC’s and run them as virtual desktops as the cost and environmental implications of replacing everything in favour of thin clients may not be cost effective. There are various options for running existing devices as thin clients and these will be considered. There are approximately 4000 PC’s, 200 Macs and 800 laptops.

3. Benefits (Outline the benefits expected from delivering the project)

The benefits of carrying out this feasibility study will be:

To provide an informed view of whether it is possible to implement thin client devices for accessing business applications for particular user types through the identification of business requirements and a small pilot;

To identify in more detail whether there are likely to be reduced costs for supporting thin client devices (devices will simply be replaced if they fail by plugging in a replacement );

To examine how data security could be increased by the use of thin client technology (data will be held securely on central storage and backed up);

To identify what increased flexibility thin client will offer to meet changing customer demands; To quantify how much could be saved by the reduced carbon footprint through reduced heat

output and power consumption at the desktop (although balanced by additional power and heat output at the centre)

To identify any cost savings possible through more environmentally friendly through longer life of equipment and consequently less frequent refresh intervals;

The benefits of the wider project arising from the feasibility study will be:

To help reduce the financial burden associated with the increasing Cost of Utilities (Anglia’s Environmental Manager has advised that Electricity tariffs have increased by approximately 40% and estimates that electricity prices may continue to increase by 15-20 %)

More responsive IT service resulting in potentially improved user satisfaction. Secure remote access will ensure that we are able to meet the Anglia Objective of educating

an equal number of students off campus and on as well as providing the capability for Location Independent working.


FORM – PMv3

4 Stakeholders (List the stakeholders who are likely to form part of the Project Team)

Name Job Title Project Role

Ajay Burlingham- Böhr Director of IT Strategy and Systems Project Sponsor

Gregor Waddell Assistant Director – Architecture &

Development, ISMS

Senior Technical

Nicky Morland Assistant Director – Programme

Management, ISMS

Programme Manager

Mike Smith Computing Lecturer, FST Senior User

John Cornell Senior Technical Officer, FST Senior User

Alex Collins Library Systems & Support Officer Senior User

Chris Herbert Senior Technical Officer, ALSS Senior User

Alec Coleman Senior Project Manager, ISMS Project Manager

Mark Norman Environmental Manager, Estates and

Facilities

Environmental Adviser from

the user community

Stephen Jackson Architecture & Development, ISMS Technical

Rob Spalding Architecture & Development, ISMS Technical

Nigel Holderness Operations Team, ISMS Technical

Marcus Hanwell Computer Services Manager and P/T

Lecturer AIBS

Senior User

Mark Miller Learning Technologist Faculty of

Education

Senior User

Lisa Pool Student Union Communications Officer Student representative

Business Relationship

Managers

ISMS Customer representatives

5. Critical Success Factors (Outcomes which will deem the project a success)

Agreement as to the scope of the wider programme. Attendance of a range of University representatives including student representatives at a

requirements gathering workshop as defined in section 8. (This could be supplemented by a student questionnaire to establish requirements)

Provision of a documented Prioritised Requirements List in accordance with project timescales. Provision of technical document that scopes a pilot. Identification of a suitable candidate area for a small but representative pilot for all categories

of user. Procurement of the appropriate equipment and then implementation of that equipment.


FORM – PMv3

Documentation of the success factors for the pilot. Following an analysis of the resources available, as a minimum the pilot will showcase the

capability of server based computing to deliver applications using Terminal Services. Use of in-house technical resources to document the success of the pilot. Production of a technical architecture document for proposed production environment including

costs and benefits. Production of a Project Planning Document that identifies the various phases for

implementation, and includes costs, timeframes and resource required.

6 Risks (Identify any known risks at this point)

The risks are documented in detail in a separate project risk log. The key risks are shown below:

Risk Countermeasure

That resource will not be available during the

feasibility study period.

ITSG to recommend and support the provision of

resources for this study. In the event of non-

availability of designated representatives, a

suitable replacement to be provided where

possible.

That agreement may not be reached as to the

design across our University.

Ensure that the Architectural principles are

documented by ISMS Architecture and

Development team. Ensure buy-in from a cross

Anglia team comprising at least 2 Faculties and

1 service area.

Insufficient power, space and air conditioning could become a limiting factor in the Cambridge and Chelmsford Computer Rooms.

Ensure that we liaise closely with Estates and

Facilities to ensure that this is provided.

That the necessary support and management of

the pilot will not be sufficient for production

environment.

Have a dedicated help line for the duration of the

pilot.

Dependency on AD project for the standard

image

Pilot can be re-imaged after AD rollout. Create

new images post AD migration that removes

Netware.

Environment may be too locked down thus

preventing flexibility and resulting in an inability

to meet business requirements.

Hold a requirements gathering workshop that

identifies requirements. Use of BRM’s to identify

pilotees and stakeholders. Use of prototyping to

iteratively improve the client builds. Testing.

Inability to deliver adequate multimedia e.g.

YouTube, Face Book.

Provide independent browser access or

separate technology that will facilitate this.

Testing.

Printing issues using thin client. Testing.


FORM – PMv3

That the project could be monopolised by the

technical folk involved in the project.

Sanity checking from NetConsult – allow a

contingency of £10K for independent view of the

architecture. BRM’s to get sign off from the

business.

That the implementation of Virtual Desktop

would make our university an early adopter with

the risk of ‘bleeding edge’ issues.

Thorough testing and risk analysis.

7. Interfaces and Dependencies (Identify any technical interfaces with other systems, organisations. Identify dependencies, i.e. what needs to be in place for this project to proceed)

The Active Directory Project is a dependency. Discussions have taken place to ensure these dependencies are taken into account. Specifically, the use of SCCM as a deployment and asset management tool will be required to deliver a supportable and cost effective Desktop 2009 virtual server provision. SCCM will be delivered by the Active Directory project towards the end of February 2009.

8. In Scope (A description what will be addressed as part of this project)

● A feasibility study that considers the viability of implementing thin client. ● A workshop involving a subset of Student, Faculty and Service representatives as defined in

section 4.● The production of a prioritised requirements list for thin client from the workshop.● The technical design for and the purchase and implementation of equipment for a pilot of thin

client within a small area. (It has been suggested that this be carried out in the Cambridge Library Learning Zone on the student open access PC’s where there are aging PC’s which represent a major support issue. These PC’s are totally uniform in their image and use and have no individual "owners" attached which could make them a more basic challenge than some other PC stocks elsewhere.) It will also be necessary to pilot in areas that fall into the other user categories. One possible outcome as a result of resource analysis would be to move business applications to server based computing delivery using terminal services.

● Technical recommendations and report including conclusions and recommendations. (See Appendix A for the specifics of what this will include.)

● The consideration of resilience at Chelmsford and technical options for doing so.● The technical design will include a VM test environment. ● The technical design will consider whether the VDI Infrastructure falls into the category of a

Tier 1 service● The technical design will consider the option of running existing PC’s as thin clients to avoid

early replacement.● Identification of total capital, effort and revenue costs associated with a Desktop 2009 roll-out –

there are likely to be several alternative roll-out strategies with correspondingly different costs.● Production of a PPD.

9. Out of Scope (A description of what will not be addressed as part of this project)

● Application upgrades e.g. Office and Outlook upgrade from 2003● Application and patch deployment process - this is resolved using SCCM within the Active

Directory project.● Disposal policy.● Any network upgrade.● Security policy development.● Printers/Printer policy and replacement.● Replacement of Net store. ● Students own provision using their own technology rather than that of Anglia.


FORM – PMv3

● Apple Macs.● Citrix and non Microsoft products – unless Microsoft products have first been considered and

ruled out as inappropriate.● Any storage for students is part of the active Directory Project for replacement of Net store

(e.g.ALSS require 100Mb per student on an existing H: Drive. Also, ALSS training PC’s have a partition for local storage on the C: drive – which ALSS students may access without any security controls)

10. Assumptions (List any assumptions that have been made with regard to the project: financial, skills, technical, timescales, skills, culture)

Financial1. Funding will be available for the necessary back-end infrastructure from the

funds allocated in the Cavalry budget for this.

Business2. That the business will be able to provide suitable representation to progress

the requirements gathering phase.3. That it will not be possible to deploy thin client to all users e.g. Apple Mac

users. 4. There will be a phased implementation over a period of time.

Technical5. ISMS Architecture and Development have stated that the working

hypothesis is that:

a) We will implement VMWare Virtual Desktop Infrastructure incorporating Microsoft Terminal Services 2003 for the delivery of business applications to individual desktops.

b) We will use SCCM to deploy and manage software and assets on virtual desktops (this is provided via the Active Directory project),

c) We will use Microsoft Softricity for application virtualisation.d) We will use where possible non-proprietary end user thin client devices e.g.

Wyse.e) Remote access will be via Microsoft ISA server to provide remote and

secure access to the virtual desktop,

The above hypotheses will be tested as part of the feasibility study.

6. That Cambridge will be the Primary Data Centre for the deployment of the server infrastructure.

7. That suitable power and air conditioning exists at Cambridge and to a lesser extent Chelmsford for the new infrastructure.

Timescales 8. That the study will last three months initially.

Skills 9. In-house resources will be used rather than external resources for the feasibility study

Culture 10. That the culture of the organisation is able to accept a move towards thin client technology.


FORM – PMv3

11. Estimated Costs and Resources (Outlines the detailed planning costs, anticipated capital and revenue costs, and effort of delivering the project)

Feasibility Study Costs Capital Revenue Estimate

type*

Source of

funding

Discovery/Planning work to be

done in house.

* Purchase of thin client hardware:

c.100 devices (at £315 each incl

VAT = £31,500 plus 3 servers at

£5K each incl VAT = £17,625)

(Subject to

resource/timescales/other

priorities. Server based computing

could be implemented at lower

cost)

Sanity check from NetConsult of

the technical design estimated 10

days.

£50K

£10K

£5K

Cavalry funds

budget of

£100K

originally

approved -

now down to c

£60K following

Faculty

project.

Total £60K £5K

* Figures are worst case based upon an earlier purchase of Wyse terminals for the Faculty project. In reality, alternative lower specification devices from Wyse or Sun Ray’s could suffice subject to the Requirements Gathering Workshop.

Implementation Costs will be

added following the Feasibility

stage

Capital Revenue Estimate

type*

Source of

funding

Hardware and Software TBC

Total TBC

Resourcing for Planning Stage Estimated Days

PO A&D Ops plus

CST

Other

Workshop 3 2 2 10 person

days

(assumes

representation

from Libraries,

FST, ALSS,


FORM – PMv3

Estates plus

others)

Prioritised Requirements List 1 1 1 1

Technical Design 1 5 2 3

Lead Architect

will be Ed

Lobo with

assistance

from Ian

Kitching

Procurement and implementation

of pilot equipment

3 5 10 Stephen

Jackson

Carrianne,

Beck and

Jennifer

2 (for pilot

area)

Write up of pilot 1 2 1 0.5

Document feasibility study 2 2 1 2

Project Meetings / Planning 10 1 1 3

Training 2 2 2 plus 2

CST

Production of PPD 9 1 1 0.5

Total 32 21 plus 5

BRM

21 plus 2

CST

22

* Estimate types: Outline (+/- 50% accuracy)

12. Timescales (Include any requirements, deadlines for project implementation)

The feasibility Stage will last for approximately three months from approval.

13. Comments (Enter any useful / pertinent information as required)


FORM – PMv3

APPENDIX A – List of technical areas in scope for review

● A report jointly authored by ISMS A&D and Operations team that provides a recommended architecture for the deployment of thin client within our University. This will be informed by the prioritised requirements list and will include:1. Costs of deployment and support of thin client2. Benefits of deployment3. A roll out phased plan4. Consideration of the following:

a. Power and environmental considerations (and associated costs)b. Blades PC and server including whether Blades are more cost effective than

traditional server. c. Approach for implementation of Virtual desktops on servers.d. Which Virtual Desktop Infrastructure broker we should use e. Client end point validation/multifactor authentication/ SSL-vpn gateway.f. Application virtualization - investigate VMware Thinapp; MS Softricity; Altiris

SVS; Appstream g. ESX4 and VDI3 is due out in 6 months and they both have interesting

developments in this area. 1 of note is offline Virtual desktop for remote workers use.

h. Application streamingi. OS Streamingj. Technical approach for peripatetic users – e.g. laptop users or those working

from public terminals.k. Costs/benefits of approachl. Resources and timescales for wider implementationm. Secure remote access using ISA servern. SAN storage needed to support thin client including an analysis of WMS100 and

AMS 1000 platforms. o. To test printing for students / staff


FORM – PMv3

Appendix B - Glossary

Term Definition

Thin Client A thin client (sometimes also called a lean or slim client) is a client computer or client

software in client-server architecture networks which depends primarily on the central

server for processing activities, and mainly focuses on conveying input and output

between the user and the remote server. In contrast, a thick or fat client does as

much processing as possible and passes only data for communications and storage

to the server.

http://en.wikipedia.org/wiki/Thin_client

Virtualization Virtualization is the creation of a virtual (rather than actual) version of something, such

as an operating system, a server, a storage device or network resources

Operating system virtualization is the use of software to allow a piece of hardware to

run multiple operating system images at the same time. The technology got its start

on mainframes decades ago, allowing administrators to avoid wasting expensive

processing power.

http://searchservervirtualization.techtarget.com/sDefinition/

0,,sid94_gci499539,00.html

Server

Based

Computing

Refers to applications that run in a server. Also known as "thin client computing," it may refer

to a browser-based environment that uses a Web browser as the client with all applications

running on a Web server on the Internet or in an intranet on the Local Area Network.

It may also refer to a terminal environment, in which the client machine serves as a dumb

terminal in the centralized architecture like that of earlier mainframes.

http://www.techweb.com/encyclopedia/defineterm.jhtml?term=server-

based+computing


FORM – PMv3

http://www.techweb.com/encyclopedia/defineterm.jhtml?term=server-based+computing

http://www.techweb.com/encyclopedia/defineterm.jhtml?term=server-based+computing

http://searchservervirtualization.techtarget.com/sDefinition/0,,sid94_gci499539,00.html

http://searchservervirtualization.techtarget.com/sDefinition/0,,sid94_gci499539,00.html

http://en.wikipedia.org/wiki/Thin_client

project mandate - my.anglia homepage

Documents

project code

feasibility project

allincluding comments

project planning phaseproject

project planning document

allincluding initial

applicable project description

alladded comments