ADVANCED INFORMATION SERVICES CENTRE
Project Initiation Document (PID)
AISC Systems Migration & Device Sync
Version 2.4
Author:
Michael Marques [email protected]
i
DOCUMENT HISTORY
Document Completion
Version Author: Date
1st Draft Draft 0.1 Michael Marques 12/9/11
1st Review Draft 0.2 N woods
S Massiah
23/09/11
Quality Assurance Draft v0.6 N Woods 13/10/11
ii
Contents
1. Business case 3 1.1 Background 3 1.2 Justification 3 1.3 Objectives 3 1.4 Benefits 4 1.5 Scope 4 1.6 Budget 5 1.7 Infrastructure 5 2 PROJECT Approach 6 2.1 Staff Resources 72.3 AISC Systems Migration Project Roll-Out Schedule 8
3 Risk and Issues 9
4. Quality Strategy 10 4.1 Responsibilities 10 4.2 Configuration Management 10 4.3 Acceptance Testing/Outcome 10 4.4 Project Quality 10 4.5 Change Control 10 5. Project Governance 11 5.1 Responsibilities 11 6. Project Plan 13 6.1 Milestones 13 6.3 Activity 14 6.4 Reporting Arrangements 14 6.5 Exception Management 14 6.6 Filing Arrangements 14 6.7 Assumptions 14 7. Communication Plan 15 7.1 General communication 15 7.2 Stakeholder communication 15 8. Training Plan 16
Appendix A: Job Descriptions 17
Appendix B: Change Request Form 21
Appendix C: Activities GANTT chart 22
Page 3
1.
BUSINESS CASE
The following sections set-out the business justification for the project and the parameters of what is to be delivered.
1.1 B
ACKGROUNDFollowing the Biomedical Administration Review 2007 (BAR), the strategic vision was set to standardize IT services in the Faculty of Biomedical Sciences (FBS) and remove duplication. This would then free-up existing resources to be redeployed for specialist IT support for research, teaching & learning.
The AISC IT Transformation Programme was established in 2010 to deliver that standardisation by first building faculty-wide technical solutions where necessary, and then managing the migration of thousands of Faculty users onto them.
In 2010/11 the FBS Virtual Servers Project and FBS Active Directory Project, within the
Transformation Programme, successfully designed, procured and built a state-of-the-art virtual server environment and single active directory. This introduced the technical capability to centrally host data and services, currently held on hundreds of separate physical servers located across the divisions, institutes and departments, and enable the secure authentication of users when accessing the data and services.
1.2 J
USTIFICATIONThe divisions, institutes and departments, which AISC support currently have multiple methods of authentication, data storage and services, with varying levels of technical sophistication, reliability and resilience.
A requirement was identified by FBS Senior Staff to provide a faculty-wide data storage solution, which would provide a consistent level of service across the respective divisions and institutes, and provide greater security and resiliency. This would inherently reduce the risk of any inadequate safeguarding of research data and intellectual property, and provide a vastly enhanced service allowing collaboration and sharing of data across SLMS.
There was also a requirement for a system to allow “home/personal” network stores to be seamlessly synchronised to laptop and desktop computers, to cater for users who travel widely and are often not network connected, and to improve the users’ ability to work during network or other service outages. Many users are already making use of commercially available technologies that achieve a multi device synchronous data store such as Dropbox, Box.net, Sugarsync, Mozy, ZumoDrive and SpiderOak.
The Virtual Server environment and Active Directory are now available, and the thousands of AISC users and their data now need to be migrated to the new services, from their current physical servers.
1.3 O
BJECTIVES The migration of all users across the Divisions, Institutes and Departments which AISC support, to the new Active Directory for authentication
The migration of all users’ filestore requirements to the new enterprise file service, providing individual drives/stores and shared areas
The migration of all users across the Divisions, Institutes and Departments which AISC support, to an standardised Windows 7 desktop, where appropriate
Implementation of data synchronisation across multiple end point devices A quota of 50GB per individual user , with potential for more upon formal request A quota of 200GB per shared area, with unlimited user access, available upon request
Extend the current service definition to include a data storage facility suitable for temporary raw research data. When this is defined the service definition should be revalidated with user’s representatives as a whole and submitted for board approval.
Page 4
1.4 B
ENEFITSThe specific benefits that the AISC Systems Migration & Device Sync Project enables are Improved data storage, quality and accessibility for all users.
Improved data integrity, securing intellectual property and business continuity Improved remote access and collaboration, school-wide
Enable more flexible working with the introduction of hot-desking
Increased ease of moves between locations, as the solution is location independent Increased ability to use accommodation flexibly, as users data is no longer
computer-dependent
Decreased user impact during system outages
Reduction in AISC data maintenance costs across multiple systems & locations Ability to increase investment in specialist-IT services (research, teaching & learning) Consolidation and standardisation of support service levels
Decrease use of email as a file store
Readiness to integrate with the UCL Desktop solution, when it is delivered Readiness to integrate with the UCL Encryption solution, when it is delivered Readiness to integrate with the UCL DCHP solution, when it is delivered Reduction in Carbon footprint in line with UCL’s Green Policy
1.5 S
COPEThe proposed deliverables of this project have been identified as:
In Scope
To migrate the existing 6500 users that came under FBS as required to the UCL Active Directory facility
To migrate the existing 6500 users that came under FBS to the AISC data storage facility and make available the agreed data storage services
To migrate existing and new computers that came under FBS to a standardised desktop, where appropriate (PC/Computer numbers are expected to exceed 6500 as many users have multiple devices. There are also many deployed to support meeting room and training requirements)
To migrate existing and new computers that came under FBS to the UCL Active Directory facility (PC/Computer numbers are expected to exceed 6500 as many users have multiple devices. There are also many deployed to support meeting room and training requirements) To investigate, design and implement a device synchronization service
On an exception basis, to also migrate application services hosted on physical servers to the virtual server environment, but only when the application must move with the users in order to be still accessed.
Update any Service Definition Documentation for the Enterprise File Service to include synchronization of data for devices.
Out of scope
The decommissioning of redundant infrastructure (domain controllers & physical servers) will be tracked and monitored at the AISC IT Transformation Programme Board, in the Benefits Realisation Plan. This will allow this project to focus resources, and maintain pace, in achieving the successful migration of all users & computers to the new AISC Systems. The decommissioning of existing Windows Domain or Netware Directories these will be tracked
and monitored at the AISC IT Transformation Programme Board, in the Benefits Realisation Plan.
Page 5
1.6 B
UDGETThe budget for this project is provided by a successful bid made to the Information Strategy Committee (ISC)1 and is £345k in 2011/12 and £300k in 2012/13.
1.7 I
NFRASTRUCTUREThe new infrastructure provides file system access to the Enterprise File System for AISC users with the ability to connect via Windows, Mac and Linux clients.
Remote access is also provided to access the service securely from any location.
1
Page 6
2
PROJECT APPROACH
The project will work to PRINCE2 and AISC IT Transformation Programme standards and guidelines. The project will form part of the overall AISC Transformation Programme, and will be managed in Stages, according to agreed project management standards. The stages are:
Stage 0 – Project Start Up
Stage 1 – Sync Service Design, Procurement and Implementation Stage 2a – Discovery & Planning – Users, Computers & Data
(exceptional application services identified)
Stage 2b - Migration – User, Computers & Data Local
(& approved exceptional application services)
Stage 2c – Stage Closure Final Stage – Project Closure
Note: Stages 2a, 2b & 2c are repeated for each of the Institutes, Divisions and Departments that are supported by AISC, and can run concurrently.
DISCOVERY & PLANNING
The Discovery & Planning Stage will produce an inventory of users, their computers and their data hosting requirements.
From the information gathered a work package for prerequisites will be complied and supplied to local IT Teams. When complete, the Migration Stage can begin.
MIGRATION
The migrations will be scripted and form a repeatable process to be followed by Desktop Migration Engineers, with exceptions escalated to Systems Engineers.
In order to minimise the impact on users it is intended PC backup will be initiated at 5pm to run over night. User’s machines will then be replaced by a temporary PC whist their PC is reimaged and joined to AD.
Any user specific software will then be deployed using Group Policy and when the engineer check list is complete the machine can be swapped back.
At this point data migrations or copies can be in initiated after which user orientation and sign-off will be completed.
Desktop Migration Engineers and Systems Engineers will be identifiable to the users by project polo shirts.
Page 7
ROLL-OUT SCHEDULE
In principle, the project will follow the migration schedule of the AISC live@UCL Project, in order to benefit from:
User account data cleansing already undertaken Physical desktop upgrades already undertaken Any local mail server dependencies already removed
AISC live@ucl planning, which has already taken into account & accommodated the most in-need user groups first, and left those with the most resilient infrastructure (with current support contracts) until last.
Migration to the new systems, whilst following AISC live@UCL migrations, should allow a 6 month gap so as to distribute any disruption to the users.
As with the AISC live@UCL Project, there will be parallel work streams running concurrently, so whilst one area is performing prerequisite activity, another is undertaking discovery & planning, and another is migrating etc.
2.1 S
TAFFR
ESOURCESAt this stage of the project the following staff resources requirements have been identified: (Dates and allocation to be confirmed with the project board at a later date)
Role Total No Days Allocated to
Project, per week
From To
Project Manager (M Marques)
5 05/9/11 31/7/12
Senior Supplier
Head of Client Services (A Harper)
2.0 05/9/11 31/7/12
Senior Supplier
Head of Infrastructure Services (R Passey)
2.0 05/9/11 31/7/12
Central Cluster IT Teams* 2.0 Discovery & Planning 4.0 Migration
05/9/11 31/7/12
Northern Cluster IT Teams* 2.0 Discovery & Planning 4.0 Migration
05/9/11 31/7/12
Southern Cluster IT Teams* 2.0 Discovery & Planning 4.0 Migration
05/9/11 31/7/12
Migration Team
Systems Engineers x 2
Desktop Migration Engineers x 3 5.0 5.0
01/11/11 31/7/12
IT Staff and User Support Training
0.5 05/9/11 31/7/12
Programme Manager 0.5 05/9/11 31/7/12
Page 8
2.3
AISC
S
YSTEMSM
IGRATIONP
ROJECTR
OLL-O
UTS
CHEDULEDivision, Institute or Department
Live@UCL
Infrastructure
migration
AISC Migration Group 1
CHIME
August 2010
November 2011
Dept. of Infection & Population Health (IPH) – Mortimer
Market Centre
February 2011
November 2011
Ear Institute
February 2011
December 2011
Dept. of Epidemiology & Public Health (EPH)
April 2011
January 2012
AISC Migration Group 2
All Users on the Medsch IT Domain
(Royal Free, Whittington, Maple House)
May & June 2011
Q1 2012
AISC Migration Group 3
Institute of Neurology
July 2011
Q2 2012
Institute of Women’s Health
August 2011
Q3 2012
Dept. of Research Strategy
August 2011
Q3 2012
Division of Surgery (Stanmore)
August 2011
Q3 2012
Division of Medicine
September 2011
Q3 2012
AISC Migration Group 4
Institute of Cardiovascular Sciences
September 2011
Q4 2012
Institute of Child Health
October & November
2011
Q4 2012
Eastman Dental Institute
November 2011
Q4 2012
Infection & Immunity
December 2011
Q4 2012
Division of Surgery (Bloomsbury)
December 2011
Q4 2012
DoME (Bloomsbury)
December 2011
Q4 2012
AISC Migration Group 5
Primary Care & Population Health (PCPH)
January 2012
Q1 2013
Institute of Ophthalmology
February 2012
Q1 2013
Cancer Institute
March 2012
Q1 2013
Wolfson Institute of Biomedical Research (WIBR)
March 2012
Q1 2013
AISC Migration Group 6
Mop Up Group A
April 2012
Q2 2013
Mop Up Group B
May 2012
Q2 2013
Mop Up Group C
June 2012
Q3 2013
Page 9
3
RISK AND ISSUES
The following high-level risks & issues have been identified at this stage of the project. Further risk & issue management will be followed in the monthly project reports, and brought to the attention of the project steering group.
Each migration group is likely to have its own identified and specific set of risks and issues, related to the detail of those particular migrations, initial risk & issues log can be found below;
Ref Risk Description Probability Impact Severity Mitigation
1 Not being able to find one synchronisation tool for all client devices
3 3 Medium May need to implement
more than one solution 2 Area yet to be allocated
where PC’s can be rebuilt.
3 3 Medium A suitable area that can house 2 racks and have required network speed needs to be allocated.
3 Impact of the 2012 Olympics on roll-out schedules
5 4 High Adjust roll-out
schedules accordingly for Bloomsbury area and focus on remote sites outside the affected area. 4 Data security, data loss
during migration to a new PC image
3 3 Medium End user education
ensuring data is stored in agreed location. Backup of PC prior to migration.
5 Data security, data sets currently containing a mixture of data types including patient identifiable data
5 5 High End user education and
perquisite requirements to separate data types in advance on
migration. A policy by which to manage data types including patient identifiable data is a deliverable of an AISC project which is currently in start-up. 6 Service disruption during
migration
3 3 Medium Ensure project plan is
known and agreed to limit disruption
Note: An issue is defined as an outcome/event has already occurred.
ID Issue Description Severity Mitigation
1 Delayed delivery of SmartIT phase 3 across AISC
Moderate System Administrators will have to be recruited on a temp basis to cover on-going support.
Page 10
4.
QUALITY STRATEGY
4.1 R
ESPONSIBILITIESIt is the project board’s responsibility to assure itself as to the quality of the project and the delivered products. Individual members may achieve this by delegating quality control to other staff not involved in this project. The project board should assure itself that all activities contained in the relevant stage of the project checklist are completed, or have a good reason for non-completion, before giving authority to proceed to the next stage.
4.2 C
ONFIGURATIONM
ANAGEMENTThe project manager will hold copies of all project documentation. Documentation will be held on ISD Wiki site. Authorised users will have electronic access to all project documentation and be allowed to dynamically share and collaborate on future documentation.
4.3 A
CCEPTANCET
ESTING/O
UTCOMEAcceptance testing will be carried out during each activity stage of the project by members of the project team. Results from these tests will be provided to the project board.
Users at each of the Divisions or Institutes will be expected to test and sign-off all applications
working from within AD prior to migration. This will require PC’s to be setup with the AISC build and all Div / Inst applications installed joined to AD and located in the user area from where the testing can be actioned.
4.4 P
ROJECTQ
UALITYAn end-of-project review will be completed by the project board within 6 months of the end of the project. The project executive, with the project manager, will carry out reviews at the end of each project stage.
Project documentation quality reviews will be completed by the project manager, prior to publication.
4.5 C
HANGEC
ONTROLAll Requests for Change (RFC’s) must be presented for approval by the project manager in a standard format.
Note: A sample of the RFC form to be used can be found in Appendix B, page 2.
Changes will only be acted upon on receipt of an approved Project Managers Instruction (PMI). When additional resource is required, or the proposed change(s) significantly affect deliverables, authorisation will be required from a member of the project board.
Page 11
5.
PROJECT GOVERNANCE
5.1 R
ESPONSIBILITIESThe following governance structure has been identified to provide management for the AISC systems Migration project.
AISC Systems Migration & Device Sync Project Board
Samuel Massiah: Chair – Project Executive Michael Marques: Project Manager
Senior Users: SLMS Faculty Managers: Geoff Dunk – Brain Sciences
Paul Phibbs – Population Health Sciences Edna Murphy – Medical Sciences
Senior User: IT IoN Rick Davis Senior Suppliers:
Alan Harper: AISC Head of Client Services (Desktop & Devices) Ric Passey: AISC Head of Infrastructure (Data & Services) Nicola Woods: Project Quality Assurance
Zaman Wong: Project Support
* Relevant to roll-out schedule
Job description details are provided in Appendix A
Project Steering Group
Project Manager: Michael Marques Samuel Massiah: Project Executive Alan Harper: Senior Supplier Ric Passey: Senior Supplier Nicola Woods: Quality Assurance
Project Working Group(s)
Project Manager: Michael Marques Training Support: Kristina Drew Senior Suppliers: Alan Harper Ric Passey
Relevant AISC Cluster Lead* Relevant AISC IT Lead* System Engineers x2
Page 12
5.2 MEETINGS ARRANGEMENTS
Project Board meetings will be held monthly. In the absence of a project board meeting functions carried out by this team will be fulfilled by direct contact between the project manager and the appropriate parties on an ‘as needed’ basis.
Page 13
6.
PROJECT PLAN
6.1 M
ILESTONESMilestone Name
Estimated
Delivery Date
Stage 0 – Project Start Up
Project Brief
Complete
Project Manager Appointment
Complete
High-Level Discovery
Complete
High- Level Planning
Complete
Project Initiation Document Produced
13/10/11
Project Initiation Document Approved
19/10/11
Stage 0 complete
19/10/11
Stage 1 – Technical Solution (Sync, DHCP & App delivery)
Investigation Synchronisation
11/11/11
Investigation DHCP
11/11/11
Investigation Application Delivery
11/11/11
Solution Proposal Approved
18/10/11
Solution Procurement
25/11/11
Stage 1 Complete
02/12/11
Stage 2a – Discovery & Planning – Users, Computers & Data
CHIMEAudit and discovery
28/10/11
Prerequisites
04/11/11
UAT testing of all applications on from AD Domain
11/11/11
Stage 2b – Migration – Users, Computers & Data
CHIMEAD, Desktop and Data migrations
25/11/11
Stage 2c – Stage Closure
31/12/11
Stage 2 complete
31/12/11
Stages 2a, 2b &2c are repeated for each of the Institutes, Divisions
& Departments that are supported by AISC. See Appendix C.
It is envisaged that it will take two years to migrate all users and
services to the AISC desktop, AD, Data hosting service and Virtual
server hosting service.
31/8/13
Final Stage – Project Closure
Handover & Acceptance
Project Closure Document Approved
Page 14
6.3 A
CTIVITYActivities GANTT chart can be found in Appendix C.
6.4 R
EPORTINGA
RRANGEMENTSThe project manager will report monthly, or more frequently, if required, to the project board and project executive. The project manager will use the report templates and process documented by the ISD PMO.
6.5 E
XCEPTIONM
ANAGEMENTWhere circumstance variation(s) fundamentally change resource requirements, or agreed milestone time scale. Overrun(s) will be regarded as exception(s).
An Issue Log will be maintained in the project SharePoint site and form part of the monthly project reporting. All exceptions to tolerances, quality failures, or other issues raised by project members will be recorded in the issue log.
Any exception, or threatened exception, to tolerances will be highlighted in the project manager’s status report. As will any issue that cannot be resolved by the project manager.
6.6 F
ILINGA
RRANGEMENTSAll project documents will be managed and maintained by the project manager within the transformation program shared area of the project SharePoint site.
6.7 A
SSUMPTIONSKey project assumptions are:
The required resource will be made available by the underlying support teams within AISC for operational support as part of phase III of SmartIT.
Apply fixed IP’s or deploy interim departmental DHCP scopes to be migrated to the UCL DHCP platform when delivered
Page 15
7. COMMUNICATION PLAN
7.1
G
ENERAL COMMUNICATIONProject Board – Structured monthly meeting to review the overall project supported by risks and issues log, project report, decisions required, actions to be taken etc. Pre meeting agenda will be sent along with post meeting minutes circulated with decisions and actions
Monthly Reports – Forming part of the transformation program report details of the project will be published to a set format
Project team meeting – Transformation PM’s will meet once a month to present updates on the respective projects
Working group meetings – Weekly meetings will be held with representation from AISC, DCS & NS during the build stage
Newsletters - Project progress will be reported to the wider AISC user base using a transformation program update on a monthly basis
Share point site – Working group documentation will be published to a project share point site as and when required
7.2
S
TAKEHOLDER COMMUNICATIONAs has been the case with the AISC live@UCL Project the stakeholders for each of the Divisions or Institutes will be brought together prior to work beginning in their area and be presented with the project overview and how it will affect them for discovery through migration and closure. This will form part of the repeatable process as we pass though each of the Divisions and Institutes.
1 month before migration - Migration Group Senior Stakeholder Presentation - all division & institute managers
3-4 weeks before migration - VIP email comms 3-4 weeks before migrations start - All-user comms 2 weeks before migrations start - User Rep comms 1 week before personal migrations - Users
Page 16
8. TRAINING PLAN
Quick start end user service information, to be delivered via a ‘Flash movie’ hosted on the AISC web site.
e.g. Explaining that all local data needs to be in the users profile or centrally stored on a server. Basic end user training will be required in the form of referral documentation regarding the data storage service. This would outline the process by which a storage request is made, permissions and backup cycle applied.
AISC IT support teams will need training in order to support the data storage service and virtual server hosting service for purposes of initial contact. A skills gap analysis has taken place during the AISC virtual server project and the skills gaps were identified and a training plan was approved and is already in place.
Page 17
APPENDIX A: JOB DESCRIPTIONS
Appendix A: Job Descriptions
I Project board 17
II Project board executive role 18
III Project board senior supplier role 18
IV Project board senior user role 19
V Project manager 20
VI Project team 20
I Project Board Purpose:
To agree the terms of reference of the project as identified in the PID To review and accept detailed project plans
To agree responsibilities of key personnel connected with the project To appoint individuals to the Project Team
To review exceptions and approve action them as they arise To ensure all ‘products’ are delivered
To sign off stages off the project To review the project
To be responsible for project quality
To close off the project when all products have been delivered
To be responsible for post-implementation review and benefits realisation study Reporting Arrangements:
The AISC System Migration Project will make its reports available to the AISC Transformation Program Board.
Composition:
Executive role Senior supplier role Senior user role Attendance at Meetings:
Project Manager Meetings:
Initial (to accept PID)
Monthly for reports on progress At end of project
In the event of significant exceptions
Note: The executive role is empowered to sign off products and authorise action on exceptions
Page 18
II Project Board Executive Role
Qualification: Member of AISC Nominee: Samuel Messiah Tasks:
To chair project board & steering group meetings To chair the post project review
To ensure key appointments are made To authorise project resources
To sign off plans and other project documentation To ensure the project remains viable
To recommend future action to senior management if approved resources are exceeded To be responsible for the quality of project management deliverables
To brief UCL ISD Communication:
To provide direction to all project management staff To receive direction from UCL ISD
III Project Board Senior Supplier Role Nominee: Client Service – Alan Harper
Infrastructure Services – Ric Passey
Tasks:
To approve product descriptions and plans for technical products Hiring and day to day management of the sys admin or migration teams To assign technical resources
To arbitrate on and resolve any technical resource conflicts To sign off technical products
To brief non-technical management on technical issues To be responsible for the quality of all technical products
To ensure technical members of project team are properly briefed Communication:
To provide direction to all technical members of the project team To receive direction from executive role
To liaise with technical members of the project team on the quality of technical products and the viability of technical plans
Page 19
IV Project Board Senior User Role
Qualification: An SLMS member who can represent the requirements of the end users and allocate user resources
Nominee: Geoff Dunk & Paul Phibbs Tasks:
To approve product descriptions and plans for user products To negotiate the assignment of user resources
To arbitrate on and resolve any user resource conflicts To sign off user products
To ensure any members of project team are properly briefed Communication:
To receive direction from executive role (in the project board capacity) To liaise with members of the project team on issues relating to users V Project Manager
Nominee: Michael Marques Tasks:
To ensure the project as a whole produces the required products, to the required standard of quality and within the specified constraints of time and cost
Plan the project and agree it with the project board Ensure the plan is implemented
Monitor overall progress and use of resources and initiate corrective action, where needed
Advise the project board of any deviations Agree technical and quality strategy Prepare reviews and present reports Communication:
To provide direction to the Project Team (and sub-project managers) To receive direction from the Project Board
Page 20
VI Project Team
Purpose:
To fulfil the role of stage managers within their spheres of influence To assist the project manager in achieving the project’s success Responsibilities:
To provide support to the project manager
To act as ‘stage managers’, instigating, monitoring and owning activities in their areas of Responsibility
To provide resources within their area of responsibility To work within agreed plans and highlight exceptions Reporting Arrangements:
To the project manager, either at meetings or individual discussions Meetings:
As required (typically weekly ) VII Stakeholders
Project stakeholders are:
Division and Institute managers AISC cluster leads
Page 21
APPENDIX B: CHANGE REQUEST FORM
Change Control Notice
AISC SYSTEMS MIGRATION AND DEVICE SYNC Change Control Notice
CHANGE TITLE: ... Project Ref: ...
Change Ref. No
Priority: High/ Med / Low
AISC SMT Approval: Project Team Approval
Scope: Signature: Signature:
Originator: Name: Name:
Position: Position: Position:
Date raised: Date: Date:
Scope: 1 = Plan & approved documents need changing 2 = Plan needs changing
3 = Project Manager Approval
Reason for Change:
<Explain the reasoning behind the need for the change including any significant events that led to the request>
Description of Change:
<Provide a detailed description of the change required and who is responsible for actions to implement the change.>
Impact Assessment:
<Describe the overall impact on terms of the processes it will change and any change in working practice that will result as a consequence. The need for involving change agents should be identified here if required. If additional costs are incurred these should also be identified here for approval. The narrative here should provide further information on the scope>
Version: 1.0
Page 22
14/05/12
APPENDIX C: ACTIVITIES GANTT CHARTOct-11 Nov-11 Dec-11 Jan-12 Feb-12 Mar-12 Apr-12 May-12 Jun-12 Jul-12 Aug-12 Sep-12 Oct-12 Nov-12 Dec-12 Jan-13 Feb-13 Mar-13 Apr-13 May-13 Jun-13
CHIME (approx 25 users)
Dept of Infection & Population Health (IPH) – Mortimer Market Centre
(approx 50 users) Ear Institute (approx 90 users)
Dept of Epidemiology & Public Health (EPH) (approx 220 users)
All Users on the Medsch IT Domain (Royal Free, Whittington, Maple House) (approx 800 users)
Institute of Neurology (approx 700 users) Institute of Women’s Health (approx 150 users) Dept of Research Strategy (approx 65 users)
Division of Surgery (Stanmore) (approx 40 users)
Division of Medicine (approx 240 users)
Institute of Child Health Eastman Dental Institute Infection & Immunity Division of Surgery (Bloomsbury) DoME (Bloomsbury)
Primary Care & Population Health (PCPH) Institute of Ophthalmology
Cancer Institute
Wolfson Institute of Biomedical Research (WIBR)
Northwick Park Institute for Medical Research Statistics Team (linked to DoRS)
Division or Institute FBS Migration Group 1 FBS Migration Group 3 FBS Migration Group 2 FBS Migration Group 6 FBS Migration Group 4 FBS Migration Group 5
Page 23
14/05/12
APPENDIX D: PROJECT STATUS REPORTMONTHLY PROJECT PROGRESS REPORT
Project name: Project number
Project description: Reporting period:
Project start date: Project end date:
Project Executive Project Manager
Account No: Author:
ISC Functional
Committee: Date of next board meeting:
Overall Project Status
e.g. Red, Amber, Green Amber
O
VERALL
B
ENEFIT
Include summary of benefits here…
H
EADLINES
P
ROJECT PRODUCTS DELIVERED DURING REPORTING PERIOD:
Main products delivered/significant achievements and/or issues resolved in the last month etc.
A
CTIVITIES AND OBJECTIVES FOR NEXT REPORTING PERIOD:
Main activities to be completed in next reporting period etc.
S
LIPPAGE AND REMEDIAL ACTIONS:
Page 24
14/05/12
C
URRENT STATUS SUMMARY FOR
ISD
CONSOLIDATED REPORT
(
NOT MORE THAN
1,000
CHARACTERS
,
NO BULLETS
)
<<Summary including the reason for the project’s current status>>
Slippage and remedial actions:
Slippage that will impact on outcomes, remedial action planned or in-hand and date of likely resolution:
Current status summary for ISD consolidated report (not more than 1,000 characters, no bullets)
Project Milestones
Milestone name Milestone date
from PID or business case Last forecast date Current forecast date
Actual Date Comments
including details of any slippage and
remedial action taken
Page 25
14/05/12
Budget / Expenditure
Actual spend FY to date (£k) (d) Forecast spend rest of FY (£k) (e) Sub-total (£k) (f=d+e) ICT Costs 0 0 0 0 Hardware (s) 0 0 0 0 Software (t) 0 0 0 0 0 0 0 0Other (v) (insert additional rows as required) 0 0 0 0
Sub-total (w=s+t+u+v) 0 0 0 0 0 0 0 0 0 0
Number of staff days
Internal staff cost (no. days x £200) (x) 0 0 0 0 0 0 0 0 0 0
Total (y=w+x) 0 0 0 0 0 0 0 0 0 0 Agreed total budget (£k) (a) Description
External staff (fixed term staff or contract) (u)
Variance between total budget and forecast total spend (£k) (j=a-h) Variance between funds released to date and costs to date (£k) (i=b-c-d) Total forecast spend (£k) (h=c+f+g) Previous year’s actual spend (£k) (c) Funds released to project so far (£k) (b)
Current financial year spend
Future years forecast spend (£k) (g)
N
OTES ON
B
UDGET
/E
XPENDITURE
Page 26
14/05/12
S
TAFF RESOURCE
A
LLOCATED
T
O
T
HE
P
ROJECT
Role name Resource name Start date of
assignment End date of assignment Total no. of person-days allocated to the project Total person-days this period Cumulative total person days to date
S
IGNIFICANT
I
SSUES
ID Date raised Title and description Severity Owner
Target resolution
date
Update log Status
S
IGNIFICANT
R
ISKS
ID Title and Description Likelihood Impact Severity Owner Update log Status
