The University of East Anglia
Project Plan
Priority A
Document Control Information
Title:
Date:
Version:
Derived from template:
Reference:
Authors:
Distribution:
Plan Approval
REVISION
v0.1
v0.2
Application Catalogue Project
31/05/13
v0.2
Project Plan template last amended 12th February 2013
n/a
Keith Porter
Restricted to a subset of the University; Restricted to Staff only
ISDMT on
DATE
30/04/2013
05/06/2013
REVISION DESCRIPTION
First draft
Amended scope/schedule after discussions with team
Page |1
Contents
1.
Business case ..................................................................................................................... 3
1.1
Background & Rationale ........................................................................................... 3
1.2
Objectives .................................................................................................................. 3
1.3
Options ...................................................................................................................... 3
1.4
Benefits...................................................................................................................... 3
1.5
Outline Costs ............................................................................................................. 4
2. Project Scope ..................................................................................................................... 4
2.1
Project Inclusions ...................................................................................................... 4
2.2
Project Exclusions ..................................................................................................... 5
2.3
Project Interfaces ....................................................................................................... 5
2.4
Project Constraints..................................................................................................... 5
2.5
Key Assumptions....................................................................................................... 5
2.6
Success/acceptance criteria ....................................................................................... 5
2.7
Key Performance Indicators ...................................................................................... 5
3. Project Membership........................................................................................................... 6
4. Project Control .................................................................................................................. 6
5. Project Communications ................................................................................................... 6
6. Training and Support Arrangements ................................................................................. 7
7. Project Closure .................................................................................................................. 7
8. Plan Approval .................................................................................................................... 8
Appendix B Risk Log ................................................................................................................ 9
Page |2
1. Business case
1.1 Background & Rationale
The Application Catalogue is a self-service application delivery system allowing end-users to
install software from a catalogue on their systems without requiring admin rights. This
reduces the need for admin rights on Windows desktops, improving security. This also
removes the need for IT Support Technicians to be involved when a user requires a software
installation, providing a time saving for both the end user and for technicians. Modern
software packaging techniques allow for software to be added to the catalogue at speed.
Application virtualisation technology is used where appropriate to enhance the delivery of
these applications and allow co-existence of applications without issue and simpler
management of 3rd party products such as additional Web browsers.
1.2 Objectives





Deliver a web driven application catalogue interface which allows users to install
applications on their desktop with no input from IT staff
Populate the catalogue with popular applications ready for launch
Educate users on how to use the catalogue
New processes to allow users to request applications for inclusion within the catalogue?
Reduction in time used by technicians to perform ad-hoc software installations
1.3 Options
Do Nothing
Continue with existing arrangement where software installation requires input from both
helpdesk and technicians. Work is repeated many times over with technicians manually
installing some software multiple times. Difficulty knowing who should have which software
titles on their machine with some users not having what they need and other being given
software they have no requirement for. Long timescales between a software request being
made and the software actually being installed on the device. Admin rights given out in cases
which could be avoided. Software deployment is machine-centric.
Deploy Application Catalogue and use Application Virtualisation where appropriate
Remove involvement of IT Helpdesk and IT Support Technicians when a user needs to install
a piece of software which will now be available in the catalogue. Reduce time spent by
technicians performing the same task many times over. Make software deployment usercentric, allowing users to decide which software they need. Reduce the delay between a
request for software and installation from days to hours. Reduce the use of admin rights on
workstations. Avoid application conflicts and reduce regression testing.
1.4 Benefits






Users are able to deploy applications to their workstations
User can move between machines and retain access to the same applications
Applications can be deployed quickly and easily without admin rights
Applications in the catalogue are delivered via application virtualisation removing the
possibility of conflicts and reducing the need for regression testing
Technician time savings
Increased agility and ability to meet user expectations
Page |3
1.5 Outline Costs
Delivery of the catalogue is dependent on a UEA wide upgrade of Microsoft System Centre
Configuration Manager from version 2007 to 2012. This element in the ISD Programme of
Work is already in progress and is funded.
2. Project Scope
This section must very clearly describe what the project will cover, and what it will not. This
is the place where the parameters of the project are laid out.
Stage 1: Investigation
 Completed by DTS
Stage 2: Proof of concept
 Completed by DTS
Stage 3: Pilot Live migration (target date: 1st August 2013)
 Testing of live system
 Demonstration of system to IT Helpdesk and IT Support Technicians. Training will
be on June 11th 2013
 Create categories for different types of software within the catalogue to allow users to
find relevant software more easily?
 Identify pilot group – JB and MR, (20 users)(target date:28th June)
 Identify set of software available within the catalogue made available to the pilot
group.
 Document processes for IT Helpdesk and IT Support Technicians and users (JB) (
target date:28th June)
 Communications to IT Helpdesk and IT Support Technicians and pilot group
 Rollout (1st July)
 Package software training – JB with AP
 Perform user acceptance testing, web site and testing apps (key supported app ArcGIS, Matlab etc.)
Stage 4: migration to all users (target date: 30th August)
 Choose limited set applications for launch
 Include site licensed and freeware software.
 Individual Licensed software to be excluded
Stage 5: Project closure (target date:30 August)
 Ensure all webpages are updated to reflect software catalogue.
 On-going application and catalogue building
 Communication to all
2.1 Project Inclusions





Proof of concept within ITCS and pilot group
Live deployment to all users post POC
Functioning application catalogue
New processes to allow users to request applications for inclusion within the
catalogue
Communication strategy (to include usage of the catalogue and migration from
currently installed applications)
Page |4
2.2
Project Exclusions
 Packaging software
 Auditing current software licenses and record management.
 The inclusion of software within the catalogue that requires an individual license.
 Virtual desktop configuration
 Virtualised software will be made available to workstations in student IT areas
managed via Active Directory groups. Access to the software catalogue will not be
available to student workstations. Information about available software to be added
to ISD website.
2.3
Project Interfaces
 IT Helpdesk – Procedure changes
 IT Support/Technician Teams – Procedure changes and support
 IT Users – New methods of installing and requesting additional software
 Systems – SCCM
2.4 Project Constraints





2.5
Budget: No budget allocated to this project
Time frames: Project must be completed by 30th August
Resources: The primary technical knowledge for this system rests with AP, LJ, JB.
Scope: Change control
Quality: No defined quality constraints
Key Assumptions
 Key project team members are available
 Dedicated technician availability for duration of project
 SCCM update is successful
 Project members have appropriate tools to complete tasks
 Accuracy of the project schedule dates: All timescales are estimated and will need to
be reviewed at the beginning of each stage
2.6 Success/acceptance criteria

Project:
o No additional costs are incurred
o Working catalogue of software

Deliverables:
o Consistent user experience
o Deliver an alternative method of installing software with an online catalogue
o Reduction in the number of requests for help for installing software
2.7 Key Performance Indicators




Number of applications requested via catalogue by users
Number of helpsheet requests via web pages
Number of calls raised by helpdesk for software inclusion into the catalogue
Number of apps in the catalogue
.
Page |5
3. Project Membership
Project Role
Project Sponsor
Project Manager
Project Board
Project Team
Consultative Group
Users
Name
Jonathan Colam-French
Keith Porter
ISDMT
Keith Porter (KP) Mark Jones (MJ), Malcolm Rae (MR), Alex Pooley
(AP), Lee Jones (LJ), Jason Bird (JB),
Users in a nominated pilot group
All members of staff
4. Project Control
Ad-Hoc Meetings if required
A highlight report produced for the project board
(ISDMT) will be created on a monthly basis.
Project Team
The project team will meet on a bi-weekly basis
Standard Means of Monitoring  Highlight Reports to Project Board & ISDMT
Progress
(each month to ISDMT)
 Issue & Risks Highlighted in this report
 Change Control logged and highlighted in this
report
Project Sponsor
Project Board
5. Project Communications
Stakeholders will be informed of the implementation of the Application Catalogue and the
changes taking place with software installations using established communication routes.
Stakeholder
Type of
name
communication
UEA
Email to
Technicians Technicians
UEA Staff
(Potential
Pilot Group)
Email (@info) to
UEA Staff
identified by
technicians/Meeting
if required
UEA Staff
(Pilot
Group)
Email to UEA Staff
involved in Pilot
UEA
Technicians
Email to UEA
Technicians
UEA Staff
(General)
Email to all UEA
Staff
UEA Staff
(General)
Email
Twitter
Helpsheet
Description
Email to ITHD and ITST
Technicians requesting list of
suggested names for Pilot Group
Email to Staff put forward by UEA
Technicians previously to explain
project and to get them involved.
Offer chance to have face to face
meeting to discuss further is Staff
request it
Send through information on how
the pilot is going to proceed and
what information will be required
from them during the course of the
pilot
Informing the UEA Technicians of
users in the pilot group and the steps
for support
Inform UEA Staff of the project, and
projected dates for implementation.
Frequency of
communication
W/C 10th June
Follow up 13th
June
W/C 17th June
Email from IT Helpdesk to inform
all staff that software is now live and
give them details of helpsheet
location and specifics to request
Page |6
Stakeholder
name
Type of
communication
Description
Frequency of
communication
additional software
UEA Staff
(General)
Email to UEA Staff
Email to Users from IT Technicians
detailing same information as
previous email from Helpdesk for
any staff member who missed email
from Helpdesk
6. Training and Support Arrangements
6.1 Project Team
Team Members
All
Technicians, helpdesk
JB
Type of Training & Cost
Provider
No
additional
software
requirements
Demonstration and training
Training on how to package
software by AP
6.2 End Users
User Group
All Users
Pilot group
Type of Training to be Type of support that will be
Provider
needed.
Web Pages updated detailing
process.
Helpsheet produced and
available on Web pages
Helpsheet and feedback
questionnaire
7. Project Closure
The following will need to be completed before handover of the project into on-going
service occurs:






Acceptance Testing by the project team (checking product meets user needs)
Support mechanisms: IT helpdesk referral system should be in place.
Communication lines: Clearly defined areas of responsibility for troubleshooting and
resolving issues.
Training Sessions and helpsheets for users should be updated.
User/System Documentation: Documentation should be completed to allow ongoing technical support.
Post-project review should be completed to close the project and pass onto service.
Page |7
8. Plan Approval
This Project Plan has been approved by the Board.
Project Sponsor:
Date Approved:
Page |8
Appendix B Risk Log
Budget
Risk
Risk reduction
strategy/contingency
Owner
Likelihood
(H, M, or L)
Impact
(H,M, or L)
Risk reduction
strategy/contingency
Time is allocated to Project
Manager to use specifically
for this project
Owner
KP
Likelihood
(H, M, or L)
L
Impact
(H,M, or L)
H
Create a communication
plan with assistance from
internal communication
team
JB
L
L
Provide suitable usage and
guidance documentation /
helpsheets prior to launch
JB
L
L
Provide training and
guidance sessions for
helpdesk and technicians
AP
L
L
N/A
Communication
Risk
Project
Manager does
not have
sufficient time
to lead project
effectively
Guidance on
how to use the
application
catalogue is not
properly
communicated
Installing a
App-V package
for the same
software title
which is
installed
physically
creates
confusion as
two versions of
the same title
will be
available on the
machine
IT Support
teams are not
properly
informed of
changes or
trained
Version V0.1
9 of 12
Contractual
Risk
Risk reduction
strategy/contingency
Owner
Likelihood
(H, M, or L)
Impact
(H,M, or L)
Risk reduction
strategy/contingency
Investigate and resolve
issues with App-V package
or continue to distribute
package using physical
installation
Owner
AP
Likelihood
(H, M, or L)
L
Impact
(H,M, or L)
L
Check which titles should
not be available to all users
and deploy these to specific
groups
JB
L
L
Provide access to these
packages for software
owners as soon as is
possible
DTS
H
M
N/A
Internal to the project
Risk
Existing
applications
now delivered
via App-v do
not function as
they did with
physical
installation
Software which
is not site
licensed or
Open Source
becomes
available to all
users via
catalogue
Software
owners do not
test software
which is either
newly available
or has been
sequenced as
an App-V
package
Version V0.1
10 of 12
External to project, but within UEA
Risk
SCCM 2012
Infrastructure
unable to cope
with demand of
user initiated
installation
Desktop
Services Team
are overloaded
with requests
for new
software to be
added to
catalogue,
creating a
backlog and a
failure to meet
expectations /
deadlines
Risk reduction
strategy/contingency
Add additional server(s)
running distribution point
and application catalogue
roles
Owner
DTS
Likelihood
(H, M, or L)
L
Impact
(H,M, or L)
M
Technicians still able to
physically install software
on machines if deadlines are
too short to allow for the
packaging or sequencing
process to take place
AP
M
L
Risk reduction
strategy/contingency
Owner
Likelihood
(H, M, or L)
Impact
(H,M, or L)
Risk reduction
strategy/contingency
Owner
Likelihood
(H, M, or L)
Impact
(H,M, or L)
Risk reduction
strategy/contingency
Owner
Likelihood
(H, M, or L)
Impact
(H,M, or L)
Risk reduction
strategy/contingency
Owner
Likelihood
(H, M, or L)
Impact
(H,M, or L)
External to UEA
Risk
N/A
Plan
Risk
N/A
Quality
Risk
N/A
Reputation
Risk
Version V0.1
11 of 12
Resources
Risk
Risk reduction
strategy/contingency
Owner
Likelihood
(H, M, or L)
Impact
(H,M, or L)
Risk reduction
strategy/contingency
Owner
Likelihood
(H, M, or L)
Impact
(H,M, or L)
Scope
Risk
Version V0.1
12 of 12