Cardinal Point Specification

Purpose

Cardinal Point Specification define the Project requirements. This document forms the basis for the management of the Project and assessment of overall success.

There are two primary uses for this document:

·       To ensure that the project has a sound basis before asking the Project Board to make any major commitment to the Project.

·       To act as a base document against which the Project Board and Project Manager can assess progress, change management issues and on-going viability questions.

Derivation and Source Requirements

The main sources for this document are the Feasibility and Options Reports developed during Feasibility and Options, the Tender Responses and the updated User Requirements.

Composition

Unlike the other documents the following items is a list of information required to make the decisions necessary to define the Project they are not a list of contents.

The information is divided into static and dynamic to indicate which sections will change as the Project progresses.

Static information:

·       Project Objectives,

·       Defined method of approach,

·       Project Scope,

·       Project deliverables and/or desired outcomes

·       Exclusions,

·       Constraints,

·       Interfaces,

·       Assumptions.

·       Project Controls, how control will be exercised and the reporting and monitoring mechanisms that support this, including an exception process.

As an example the following information (section headings) has been derived for other Cardinal Point Specifications.  Note that these specifications have not been derived considering the same objectives and as such the following list is an example only.

·       General Requirements – precedence statements with other requirements documents, change control, funding and escalation of delays.

·       Business Aims and objectives – operational life-times for the systems, capacity requirements throughout the systems life-time, project efficiency and management of significant outages.

·       Scope – inclusion of sites, scope of systems at each site, control and monitoring, disposal, specific sustainment activities.

·       Performance – Performance requirements for the delivered systems

·       Site order – implementation order for sites (including completion dates), maximum outage durations, dependencies on the site order.

·       Safety – Business Impact analysis (a review and acceptance of the impact to ATC of the Project), references to apportioned safety requirements, MOD safety assurance requirements.

·       Related projects – requirements for projects included in the Project that do not form part of the main delivery.

·       Methods of communication with customers and stakeholders.

·       Project Governance – requirements for reviews, Project Boards, reporting and reporting requirements to the Project Boards, financial reporting requirements.

·       Control and monitoring– System interfaces, requirements.

·       Maintenance and support – support contract requirements, remote maintenance requirements, scope and number of training courses, scheduling of training, maintenance documentation, spares.

·       Sustainment activities, specific list of sustainment activities included within the scope of the Project.

·       Centre Requirements – scope of connectivity in terms of sites and services to each stakeholder connectivity requirements.

Quality Criteria

Does the CPS correctly define the scope of the Project?

Does the CPS completely, unambiguously and without any contradictions define the scope of the Project?

Is the scope of the Project credible and achievable?

Does the CPS demonstrate that the Project support corporate strategy and support the needs of other Project?

Are the controls, relationships and interfaces to the Project Board and other Projects and the users clearly defined?

Does the CPS answer the following questions?

·       What is the Project aiming to achieve?

·       Why is it important?

·       Who’s going to be involved in the management of the Project and their responsibilities?

·       How and when is it going to happen?

Are the requirements clearly measurable in terms of deliverables?

Quality method and skills

The Cardinal Point Specification will be reviewed by the Project Team to ensure that it meets the Quality Criteria, defined above, by the Key Stakeholders to ensure their requirements are completely and unambiguously checked, and reviewed and agreed.

The Project Board will review and accept the Cardinal Point Specification.