CIS010 Project Brief v 3.0

Document Sign-off

Background

Recent power outages at King’s Buildings and a number of recent network faults have highlighted the risk of a communication failure resulting in the inability to contact Security or emergency services in the event of an emergency when using the new University Voice over IP (VoIP) telephone system.

The University has a statutory duty to ensure that “any necessary contacts with external services are arranged, particularly as regards first aid, emergency medical care and rescue work.” This duty requires a  phone line that continues to work in the event of a telephony or network system failure or power outage.

Many buildings  have a requirement for a back-up telephone which can survive loss of power or data network or telephony and which can be used to contact external services.

The University also has approximately 170 lifts which must should have a means to summon assistance if someone becomes trapped and a two way means of communication with a lift rescue service designed and constructed so as to function without the normal power supply.

Scope

To provide back-up phones which can provide an alternative means of communication in the event of local power outages, or failures of University telephone service or University data network.  

To install gateway devices over main campuses to provide the necessary resilience.  These gateways allow a telephone to fail over from the new VoIP service to an external line, should the VoIP service fail in any way (e.g. power failure and/or telephone system or data network failure).   These gateways would be located within central communications points within campuses and would be protected from power failures.  Each gateway can support 80 emergency telephones. To ensure appropriate cabling to connect the emergency phone back to the gateway, and in some locations it may be more cost effective to install a standalone external line to the emergency phone, rather than use the gateway solution.

Appropriate Signage

Ensuring that documentation is changed where it refers to processes relevant to emergency procedures

A phased implementation of this solution, with King’s Buildings emergency phones being implemented first.

Changes to Scope will be logged on the Issue Log.  

Lift and Emergency Phones Profile

Lift Phones

• must be able to remain operative for at least 3 hours after loss of power to building, to lift (i.e. not local lift power supply) and data network
• can call out to Security or - where defined - an external emergency number / lift company must receive calls from Security
• from scope (for Security) for this project are 'Car' lift phones i.e. standard passenger lifts (TBC)
• lifts in buildings owned by the University  
• lifts in buildings owned by ACE
• two way communication   

Emergency Phones

• must be able to remain operative for at least 3 hours after loss of power to building, to lift (including any backup power the lift itself is provisioned with) and data network
• the number(s) that the phone can call to be designated on a case-by-case basis
• security and internal and external call can be received
• 'devices' as well as phones are to be resilient e.g. devices at emergency evacuation points : this needs clarified and confirmed by board
• major incident room(s) will have an emergency phone (possibly more than one if required)
• security team locations will have an emergency phone
• provide an emergency backup phone to Major Incident Team (to be clarified)
• Emergency Phones can be used as normal phones outwith emergencies
• Emergency Phones will be distinguishable from other phones - coloured red for example
• where University/ACE does not own the building or  have primary responsibility for Emergency procedures, arrangements for contacting emergency services in the event of a power/network failure should be clarified with the building owner/manager and so may be within project scope
• these phones will be known as 'Emergency Phones'  - this does not mean they are the ONLY phones to be used in an emergency, but are phones that must be operable in an emergency. This will be part of the communications to communities. (Alternative names could be used such as 'Backup Phones' if the project board so decided).

Out of Scope

• evacuation lifts
• non-passenger Lift phones are out of scope - stair lift phones, animal lifts
• Lift and Emergency phones in buildings not owned by the university (e.g. Argyle House)
• in exceptional circumstances where there is a suitable compliant, recorded and understood working solution already in place and the cost of cabling is seen as not justified
• the update of DEEP GEEP and PEEP's profiles for emergency scenarios

• It is not in scope of this project to migrate other systems in the university to the new resilient infrastructure - but the project does acknowledge that this is a long-term objective (i.e. all emergency systems on the one infrastructure) and will seek to make this happen wherever possible. e.g. Refuge Phones may be a system that could migrate.) This project will try and test out a Refuge Phone scenario so that project can be informed and make its own decision for future direction.

Objectives and Deliverables and Success Criteria  

This table can be used through Business and Technical Analysis, Design, Build, and Testing/UAT as a Traceability Matrix to ensure the project brief project objectives and deliverables are followed through.

Requirements

Benefits

Benefits management and realisation will be available on the ITI Sharepoint space.

By delivering the technical solution to provide full resilience to emergency and lift phones, the benefits to the University are of improved safety to staff, students and visitors should an emergency situation develop.

Governance

Project Board

The proposed project board - for approval by Project Sponsor  

Tolerances

The Project Board will be immediately informed and asked for approval if

• the estimation for project budget increases by 10% or more ,
• delivery milestones slip by a month or more,
• if there is a change in scope

Resources Skills and Cost

Budget

£300K TBC

Priority and Funding

This is a highest category priority project for ISG. Priority 1.

Funding TBC by Estates and ISG.

Project Team

The installation of lines and phones will be carried out by the ISG CIS team members or commissioned contractors. The Health and Safety Management Team in Estates must be consulted about installation planes especially any work which is intrusive and may have implications for the management of Asbestos.  

The rest of the project team have the main task of helping with the communications from the project team to the community and stakeholders - in particular with messages to and meetings with building managers, local H&S and Fire and Security officers, and Heads of School or equivalent. This will include establishing 'golden copy' lists of buildings, lift phones and identified stakeholders.

The proposed project team - for approval by Project Sponsor

Quality of Project and Deliverables / Key Project Milestones

User Acceptance Testing plans will be drawn up by the project team to confirm the various scenarios where power, phone network and data network may fail. In addition to the total loss of power or network, the UAT will include partial failures of phone and data network to see if the lift and emergency phones provide the resilience as anticipated.

Health and Safety are the Senior User and their sign-off of UAT is essential.

Outline plan

Pilot Phase

The project team proposes that we pilot these buildings for emergency and lift phones.  

The CIS team will default to providing an emergency phone at the reception area for a building - to be confirmed by a survey - or upgrading existing emergency phones.

Communication to the local stakeholders (Head of School, Building Owner, H&S, Fire, Security) will propose provision of emergency phones. The project team will arrange a meeting with representatives from the selected buildings.

Part of this communication is to make it clear that Laboratory phones are not Emergency phones and should be upgraded to Standard VOIP handset.

We will trial this communication approach at KB Pilot and if successful would intend to continue in this way for full deployment across the estate.

The Project Team will provide Golden Copy information on all lifts and building profile.

The Project Board will provide approve the buildings which are to have one (or more) Emergency Phones in or none.

There are two approaches once Pilot has proven successful and we can estimate time and effort and cost- the project team will ask the project board to select the option to be chosen after the pilot is completed successfully.  

Deployment to the Estate - Option 1

Only upgrade the Lift Phones - pilot at KB then whole Estate Once competed, start on Emergency phones  

Deployment to the Estate - Option 2

Upgrade the Lift Phones and Emergency Phones

Assumptions

The Key Assumption being made is the Profile of an Emergency Phone and Profile of a Lift Phone (as above). This drives the requirements.

We assume our information on buildings and lifts is up to date.

We are making the assumption that around 250 buildings will require one emergency phone.

Constraints

There are no known constraints on the project

Risks

Due to the sensitivity of the information, this project will share its documentation, risks and issues on Sharepoint. The current risks are listed in the CIS010 Project Logs. The project website will only be used for high level milestones and project brief and high level project progress reports.

Issues

Due to the sensitivity of the information, this project will share its documentation, risks and issues on Sharepoint.

Previous Lessons Learned

Important that what is Out of Scope is understood and agreed at the project start - project board has this responsibility.

From the CIS001 VOIP replacement project, we know that meeting are much more effective in clarity and engagement  than any email communication, even from senior management.

Dependencies

No dependencies on other project.

CIS001 VOIP replacement is dependant on this project to allow it to decommission analogue telephony network and to replace Laboratory and other 'emergency' phone handsets with VOIP.

Version Control

Project Documentation will adopt the following convention 

• Documentation in development will be version 0.x or 1.x
• Documentation submitted for Approval will be version 2.x
• Documentation signed-off as complete will be version 3.0
• And changes to the document will be change managed and result in version 3.x  

Communication

The communication for the project will be a key element in its success.

The outline may be summarised as Stakeholder : -

Project Team to help with initial communication to the Head of School/equivalent to set up meeting with key stakeholders of buildings effected to explain what is to be done and importantly, not in scope Project Board to deal with escalations from stakeholders

Project Board :- monthly report from project manager project board meetings : after pilot to KB is complete and then every four months during full deployment TBC) escalations when tolerances breached or critical risks and issues are raised

The Communication Plan will be on Sharepoint and set out the comms for the project - as planned and as executed.

Run / Grow / Transform

This a Grow project

Alignment with Strategic Vision  

IS Strategic Vision the main elements of the vision that this projects contibutes to are highlighted in bold.

University's Strategic Vision for 2025 the main elements of the vision that this projects contributes to are highlighted in bold.

IS Change Programme - How will this project's Deliverables and Benefits promote the Themes  

Service Excellence - Information and Security

n/a

Service Excellence - Process Improvement, efficiency, quality and best practice (Social Responsibility and and Sustainability)

n/a

Digital Transformation

n/a

IS Change Programme - How will the execution of this project promote the Themes

Project Sponsor – Project Responsibilities

The sign-off milestones are associated with specific responsibilities of the Sponsor role .

Start of project – Explicitly Included in the Initiation Milestones Sign-Off

1. Negotiates and confirms funding for the project
2. Ensures the project is in line with organisational strategy and priorities
3. Chairs the project board, appoints its members and ensures they are effective
4. Advises the project manager of protocols, political risks, issues and sensitivities
5. Makes the project visible within the organisation  

End of Planning – Explicitly Included in the Planning Milestone Sign-Off

1. Works with the project manager to develop the Project Brief
2. Ensures a realistic project plan is produced
3. Sets tolerance levels for escalation to themselves and to the project board
4. Ensures that project team have representation and engagement from users and suppliers
5. Helps identify Stakeholders
6. Approves Communication Plan
7. Agrees on frequency of meetings with Project Manager
8. Agrees of frequency of meetings with Project Team
9. Agrees on milestones and who signs-off

Execution – ongoing

1. Provides strategic direction and guidance to the project manager as directed by the Board
2. Approves changes to plans, priorities, deliverables, schedule
3. Encourages stakeholder involvement and maintains their ongoing commitment
4. Chief risk taker
5. Makes go/no-go decisions
6. Communicates change in organisational structure, priorities, business benefits or funding
7. Helps the project manager in conflict resolution
8. Helps resolve inter project boundary issues
9. Gains agreement among stakeholders when differences of opinion occur
10. Assists the project by exerting organisational authority and the ability to influence  

Delivery – Explicitly Included in the Delivery Sign-Off

1. Ensures that Service is ready for change

Closure - Explicitly Included in the Closure Milestone Sign-Off

1. Helps with publicity for the change delivered
2. Ensure that benefits will be managed, measured and realised post-project
3. Evaluates the project’s success upon completion