Pid Example Northumbria Datawarehouse

Project Initiation Document
University of Northumbria Data Warehouse
Author: Date Created: Updated: Version:
Gill Ferrell/Andrew McKirgan 28/09/2001 01/11/2001 Draft v8
Copy Number _____
University of Northumbria Management Information Systems Development Unit Project Initiation Document
1 Document Control
1.1 Change Record
Date 28/9/01 05/10/01 09/10/01 09/10/01 11/10/01 17/10/01 31/10/01 01/11/01 Author Andrew McKirgan Gill Ferrell Dave Beales Patrick Bellis Andrew McKirgan Gill Ferrell Gill Ferrell Andrew McKirgan Version Draft v1 Draft v2 Draft v3 Draft v4 Draft v5 Draft v6 Draft v7 Draft v8 Change Reference
Revisions Revisions Revisions Revisions Revisions; insertion of Approach and Control sections in line with MISDU practice. Changes to template and insertion of numbering. Insertion of section 8
1.2
Reviewers
Name Gill Ferrell Dave Beales Patrick Bellis Position Programme Manager (Business Systems) Oracle Systems Manager Implementation Manager (Student)
1.3
Distribution
Copy No. 1 2 3 4 5 6 Name Library Master Location Project Library
Note To Holders: If you receive an electronic copy of this document and print it out, please write your name on the equivalent of the cover page, for document control purposes. If you receive a hard copy of this document, please write your name on the front cover, for document control purposes.
File Ref: J:\JISC Centre\Materials InfoKits\Project Management\Issue\PID_Example_Northumbria_Datawarehouse_i1.doc
Page ii
Contents
1 1.1 1.2 1.3 2 2.1 2.2 2.3 2.4 2.5 3 3.1 3.2 4 4.1 4.2 4.3 4.4 4.5 5 5.1 5.2 5.3 5.4 5.5 5.6 5.7 6 7 7.1 7.2 7.3 8 8.1 8.2 9 9.1 9.2 9.3 9.4 9.5 10.1 10.2 10.3 10.4 DOCUMENT CONTROL CHANGE RECORD REVIEWERS DISTRIBUTION INTRODUCTION PURPOSE BACKGROUND SCOPE AND APPLICATION IMPLEMENTATION DECISIONS RELATED DOCUMENTS OBJECTIVES PROJECT OBJECTIVES CRITICAL SUCCESS FACTORS SCOPE SCOPE OF PROJECT PHASE 1 PHASE 2 SUBSEQUENT PHASES SCOPE CONTROL CONSTRAINTS, ASSUMPTIONS AND RISKS CONSTRAINTS ASSUMPTIONS RISKS INTERFACES, INTEGRATION, DATA CONVERSION RISKS HARDWARE, NETWORK, SOFTWARE RISKS STAFFING RISKS SCOPE, PROJECT MANAGEMENT RISKS RELATIONSHIP TO OTHER SYSTEMS/PROJECTS APPROACH PLANS ACCEPTANCE PROJECT ADMINISTRATION PROJECT TASKS, DELIVERABLES, AND MILESTONES KEY DELIVERABLES MILESTONES CONTROL AND REPORTING RISK AND ISSUE MANAGEMENT CHANGE CONTROL STATUS MONITORING AND REPORTING PROGRESS REPORTING FINANCIAL CONTROL STAFF RESOURCES PROJECT TEAM PROJECT ROLES AND RESPONSIBILITIES EDUCATION AND TRAINING 14 14 14 14 15 16 16 16 17 13 13 12 12 12 7 7 7 8 8 9 9 4 4 5 6 6 3 3 1 1 1 2 2
II II II
10 RESOURCE MANAGEMENT
Page iii
10.5 PROJECT SOFTWARE/TOOLS 10.6 PROJECT ENVIRONMENTS 10.7 SOFTWARE BACKUP PROCEDURES AND SYSTEM ADMINISTRATION 11 QUALITY MANAGEMENT 11.1 11.2 11.3 11.4 QUALITY REVIEWING TEST STRATEGY TEST LEVELS TEST EXECUTION
18 18 18 19 19 19 19 20
12 CONFIGURATION MANAGEMENT 12.1 DOCUMENT CONTROL 13 APPENDIX A - WORKPLAN 14 APPENDIX B - OTHER ROLES AND RESPONSIBILITIES 14.1 STRATEGIC LEVEL 14.2 MANAGEMENT LEVEL 14.3 OPERATIONAL MANAGEMENT LEVEL 15 APPENDIX C - DETAILED FUNCTIONAL REQUIREMENTS 22 22 23
Page iv
2 Introduction
2.1 Purpose
The purpose of this Project Initiation Document is to define the scope and approach of the University of Northumbria Oracle Data Warehouse implementation. The key overall objective of the Data Warehouse is to provide the facility to extract any data from any of the Universitys systems and allow authorised users to view it. The project will consist of multiple phases of implementation; this document covers Phase 1 - Admissions and Phase 2 Roll-out to Users. This document will be extended and enhanced as subsequent phases of implementation are undertaken hence details of subsequent phases are included for reference purposes where possible.
2.2
Background
This project forms part of the programme of projects being undertaken by the Management Information Systems Development Unit. The implementation will be conducted using Oracle development and reporting tools including: Oracle 8i/9i Express Data Warehouse Builder Discoverer 6i Reports
2.3
Scope and Application

This document defines the following topics for Project Management of the Oracle Data Warehouse implementation (Phases 1&2): Scope Objectives Approach Project Tasks, Deliverables, and Milestones Control and Reporting Work Management Resource Management Quality Management Configuration Management The document defines the implementation of the project for the defined scope as well as how to meet the defined objectives using the defined approach.
Page 1
2.4
Implementation Decisions
The critical implementation decisions applicable to this project are: Identify which of the available tools are most appropriate for each of the deliverables Identify Phase 2 users and define the nature of their usage
2.5
Related Documents
None identified.
Page 2
3 Objectives
3.1 Project Objectives
The objectives of the project are to: Develop a data mart to support the applications and admissions process by provision of aggregated data. Create an applications subject on the data warehouse to support trend analysis. Make the data available to identified users.
3.2
Critical Success Factors

The critical success factors to meeting the goals of this project are: An architecture for decision support is developed which shows the relationships between the transactional systems, data marts and data warehouse. Subject areas, subjects and table structures are identified and implemented. Extraction, transformation and loading processes are developed for legacy and replacement systems. Technical and business metadata is available to developers and users respectively. Desktop access is available to identified users. Future expansion is possible. Meets identified business needs.
Page 3
4 Scope
4.1 Scope of Project
The full scope of this project is to 1. Replace and expand the functionality of the current data warehouse maintained and developed by SPU in respect of, initially, applications to the university. 2. Replace and extend the functionality of the current Student MIS maintained and developed by SPU in respect of, initially, the Admissions Module 3. Provide on-line access to the data warehouse and associated data marts. 4. Develop appropriate standard reports. 5. Enable users to apply the appropriate software tools to the data warehouse and associated data marts for ad-hoc queries. The full implementation will be: Applications Sites Process Reengineering Architecture Testing Applications and admissions. All UNN campuses. Use of Data Warehouse as the primary source of applications Management Information rather than local statistics. Web deployed where possible, client/server where necessary. A testing model based on the MISDU User Acceptance Testing strategy will form part of the plan.
4.2
Phase 1
The following elements comprise the scope of Phase 1: Phase 1 Applications .1 Current Cycle To create a data mart to support the applications and admissions process with aggregated data. To include UCAS, GTTR, NMAS, SWAS and direct admissions. To break down data to a lower level of granularity where this is desirable/feasible. Customisation Data Conversion N/A Bespoke development. From Admissions Module (VAX Powerhouse), Markets Database (MS Access) and University Statistical Data Warehouse (MS SQL Server). Source data may need to be revised if the scope extends beyond that of the current data warehouse e.g. to include analysis of offers made.
Overview of Functional Requirements
Page 4
Interface Requirements Security Reporting Training
SAS, University Statistical Data Warehouse (USDW), Resource Distribution System. Creation of user profiles for SPU staff. Ability to query and report on data within SPU. Developers and SPU support staff in table creation, ETL and reporting/querying tools.
.2
Historic information To create an applications subject on the data warehouse to support trend analysis. N.B. Historic information may be at an aggregated level only as it may not be possible to break this down further.
Customisation Data Conversion
N/A Bespoke development. From Markets Database (MS Access) and University Statistical Data Warehouse (MS SQL Server). Possibly SAS if data required to a lower level of granularity. There are questions over the feasibility of extracting archived SAS data and the current plan is to investigate the extraction of current and past years data only.
Interface Requirements Security Reporting Training
None. Creation of user profiles for SPU staff. Ability to query and report on data within SPU. Developers and support staff in table creation, ETL and reporting/querying tools.
4.3
Phase 2
Phase 2 Providing access to users
To provide on-line access to standard reports and ad-hoc querying to applications and admissions figures. User population to be defined but is likely to encompass: Admissions Administrators Admissions Tutors Marketing Team Education Liaison Team
Page 5
Customisation Data Conversion Interface Requirements Security
N/A N/A N/A Access to be controlled via firewall. It is likely there will be more than one type of user with different security profiles.
Reporting
Some users will select standard reports from a menu whereas others will have access to one or more of the reporting/querying tools. Admin staff in use of reporting/querying tools.
Training
4.4
Subsequent Phases
Phase 3 onwards The following functionality has been identified for implementation in Phase 3 onwards: Entry Qualifications Course and Unit Enrolments including cohort analysis and first destinations Progression, Completion & Awards Fees
UNDER CONSIDERATION The key overall objective of the Data Warehouse is to provide the facility to extract any data from any of the Universitys systems and allow authorised users to view it. The following highlights examples of the data areas which will ultimately be developed in support of the work of SPU. HESA Funding Resources Staffing External Information e.g. UCAS, HESA, HEFCE Estates
4.5
Scope Control
The control of changes to the scope identified in this document will be managed through the Change Control procedure as defined in section 9.2.
Page 6
5 Constraints, Assumptions and Risks

5.1 Constraints
The following constraints have been identified: Developments in UCAS (e.g., HERCULES, tariff). Lack of GTTR, NMAS, SWAS historical snapshots. Developments in the OSS. Organisational changes to responsibility for management information/decision support may adversely affect the project. On-line access to the data warehouse and data marts is dependent on the general administration and support of desktop tools. System Administration resources limited. Limited availability of technical support with knowledge of SAS.
5.2
Assumptions
The following assumptions have been made: Adequate project management resource will be available. Technical staff will be trained. Use of Oracle Applications via Citrix will be successful. The ITS Call Centre will be able to provide user support in relation to the reporting tools. Prospective users of the information will contribute to the project in a pro-active and timely manner via a Task Group. Responsibility for information management within the university will be clearly defined and adequately resourced.
5.3
Risks
The following general risks have been identified that may affect the project during its progression. These and any other risks identified later will be tracked through the Risk and Issue Management process defined later in this document. Problems in the implementation of the transactional systems may adversely affect the project. Staff may not be retained. Software is new to us. Change management issues need to be addressed.
Page 7
5.4
Interfaces, Integration, Data Conversion Risks

SAS Interfacing Lack of technical resource with appropriate knowledge especially in relation to Powerhouse and SAS Admissions. Risk: High Consequence: At worst inability to extract data although a more likely scenario is that misunderstanding of the data leads to incorrect data being extracted. Contingency: None readily identifiable. Use of skills from elsewhere in MISDU (Student System Implementation Manager) would delay the OSS implementation. Early Mitigation: Negotiate with ITS to make resources available. A thorough mapping exercise at the start of the project (see plan) will reduce reliance on this resource thereafter.
5.5
Hardware, Network, Software Risks

Hardware specification The server may not be specified to meet the Universitys long-term requirements. Risk: High Consequence: Shortage of disk space. Contingency: Purchase more disk space. Early Mitigation: Monitor usage and purchase more disk space in good time to avoid any delay to development. Lack of familiarity with Data Warehousing tools The project team has no previous experience of the toolset. Risk: Medium Consequence: Delay to project. Contingency: Use of consultants. Early Mitigation: Set realistic timescales which allow adequate time for product familiarisation.
Page 8
5.6
Staffing Risks
Staff Retention Project may not be able to retain staff. Risk: High Consequence: Delay to Project. Increased cost in re-training. Contingency: Use of consultants. Early Mitigation: Use CBT where possible. Consider retention clauses in contracts. Scope project in small chunks with end user deliverables at each stage. Technical Resource Existing technical resources may be insufficient. Risk: High Consequence: Delay to project. Increased cost of consultants. Contingency: Use of consultants. Early Mitigation: Either allow lengthy timescale based on existing resources or identify resource shortages and obtain additional resources.
5.7
Scope, Project Management Risks

Inadequate or insufficient Management input to project. Implementation Manager has insufficient experience or is unable to devote sufficient time to project. Risk: Medium Consequence: Inability to deliver on time/budget. Lack of staff/user confidence. Contingency: Use of consultant. Early Mitigation: Identify Manager with experience who can meet time commitment. Consider PRINCE2 training. Familiarise with MISDU project management framework.
Page 9
Delay to OSS implementation Delays to the OSS implementation may adversely impact the project. Risk: Medium Consequence: Need to extract data from legacy systems then change to OSS. N.B. This may be an issue anyway if it is decided to extract historic data at a greater level of granularity. Contingency: None identified. Early Mitigation: Develop plan with due reference to OSS implementation schedule. Maintain close liaison between these elements of the programme. User Input Identification of the wrong user group may lead to unrepresentative input. Similarly, user unfamiliarity with concepts may lead to inappropriate input. Risk: Medium Consequence: Failure to meet user needs; poor level of user acceptance; need for rework. Contingency: None identified. Early Mitigation: Input from DCG, Steering Board and Academic Advisory Board. Change management to promulgate the value of corporate management information. Training for users to understand the concepts involved. Change Management The project team may be unable to develop user confidence in a corporate data warehouse and managers may continue to use alternative information sources/satellite systems. Risk: Medium Consequence: Failure to achieve user ownership; poor level of user acceptance; cost of maintaining different information sources. Contingency: None identified. Early Mitigation: Input from DCG, Steering Board and Academic Advisory Board. Change management to promulgate the value of corporate management information.
Page 10
6 Relationship to Other Systems/Projects

It is the responsibility of Project Steering Board/Directors Co-ordination Group Members to inform the Project Team of other business initiatives that may impact the project such as online admissions, portal for international students. The implementation of the other Oracle systems, especially OSS, will affect this development as they will be the source of data. The management of the other university systems may/will impact on this development as potential or current sources of data. The project to pilot the use of Oracle Applications via Citrix will impact this project as it is a stated assumption that the pilot will prove successful.
Page 11
7 Approach
The approach follows the standard adopted by the Management Information Systems Development Unit for its programme of projects. The approach has been derived by adapting a combination of methodologies - PRINCE2, KPMG R2I and Oracle Application Implementation Method (AIM) in order to arrive at a Best Practice approach suited to the work of this unit.
7.1
Plans
A plan for the whole programme of MIS projects is maintained by the Project Manager with the assistance of the Project Co-ordinator. The Implementation Manager is responsible for detailed planning and managing delivery against the plan. The Project Manager maintains oversight of the interdependancies between projects and resolves cross-project scheduling issues. MISDU uses a Sliding Planning Window approach which means only undertaking detailed planning as far ahead as is sensible at the time. Each task in the plan has a clearly defined deliverable. The plan identifies key milestones; progress against these milestones is reported to the appropriate management groups. The plan may be subdivided into minor milestones for the purpose of day to day team management. Management against the plan is on an exception basis.
7.2
Acceptance
Project Acceptance is on the basis of a formal testing programme to a set of predefined test scripts. The full Acceptance Criteria and Acceptance of Developments is to be defined in preparing the test scripts.
7.3
Project Administration
The following administrative arrangements have been made for this project: Plan maintenance support from MISDU Project Co-ordinator. Administrative Support from MISDU Project Administrator.
Page 12
8 Project Tasks, Deliverables, and Milestones

8.1 Key Deliverables
Task Model data Implement structure Devise ETL processes Key Deliverable Model of the star schema of fact and dimension tables Create tables and views in Oracle Processes to extract data from legacy and replacement systems and populate or update table structures Record business and technical metadata against data elements. Provide desktop access to the data warehouse Provide facility to choose, view and print standard reports. Train and advise users in the application of software tools. Responsibility SPU SPU SPU
Apply metadata Connect users to the data Produce standard reports Facilitate the use of querying and analysis of data
SPU MISDU SPU SPU/MISDU
8.2
Milestones
The target milestone dates for producing the deliverables for Phases 1 & 2 are summarized below. Whilst any subsequent phases are outside the scope of this document, they are documented, where possible, for information purposes only:
Deliverable Model data Implement structure Devise ETL processes Apply metadata Connect users to the data Produce standard reports Facilitate the use of querying and analysis of data Phase 1 1 1 1 2 2 2 Milestone Date
Page 13
9 Control and Reporting

The project will operate a set of Control and Reporting procedures as developed by the Management Information Systems Development Unit for its programme of projects. The purpose of these procedures is to provide effective and transparent mechanisms to control the scope of the project, manage issues and risks and monitor progress.
9.1
Risk and Issue Management

A risk identification and assessment forms part of this initiation document. Risk assessment and management is an ongoing process. Risks will be evaluated at the planning stage of each phase of the project as a minimum requirement. Risks are logged in the Project Control Database and appropriate management strategies identified and implemented. Any question, problem or suggestion, which may impact the project achieving its aims, is logged as an issue in the Project Control Database. Each issue is allocated an owner and progress is tracked until the issue is resolved. An escalation procedure is in place and issues are regularly reviewed by the appropriate management groups.
9.2
Change Control
The project will operate a formal Change Control procedure. The purpose of this is to control the acceptance or rejection of proposed changes to the scope of the project in order to avoid unnecessary risks associated with scope creep. Any modification to or deviation from the agreed scope will be logged as an issue in the Project Control Database and subjected to an impact analysis that will determine the impact of implementing the change in terms of Time, Quality and Cost. The project management team will take decisions on changes which do not impact key milestones. These changes are described as being within tolerance. Changes which impact on key milestones will be referred to the Directors Coordination Group for acceptance or rejection.
9.3
Status Monitoring and Reporting

The Implementation Manager will report to the Project Manager the progress on work allocated to the implementation team at a weekly status meeting. The management team will work together to ensure delivery against the project plan.
9.4
Progress Reporting
The Programme Manager will monitor progress against key milestones and report progress to the Directors Co-ordination Group and Project Steering Board at intervals determined by the stages of the project plan.
Page 14
9.5
Financial Control
The Implementation Manager will be responsible for managing training and consultancy expenditure in line with an agreed budget. Overall budgetary control lies with MIS Programme Management which has responsibility for reporting on financial matters to the Project Sponsor.
Page 15
10 Resource Management
The Resource Management process provides the project with the right level of staffing and skills and the right environments to support them.
10.1 Staff Resources

The project will have a dedicated team working with management, administrative and technical support from the MIS Development Unit and consultancy support from Oracle where appropriate.
10.2 Project Team

Implementation Manager, Andrew McKirgan Team Members Graeme Barnett, Developer Keith Robson, Developer ?, Information Officer
10.3 Project Roles and Responsibilities

Implementation Manager (1) The Implementation Manager is responsible for: Managing and leading the implementation team. Detailed project planning and control including: managing project deliverables in line with the project plan. recording and managing implementation issues and escalating where necessary. managing project scope and change control and escalating issues where necessary. providing status reports to the project manager
Managing implementation training within the defined budget. Managing consultancy input within the defined budget. Final approval of the design specification. Working closely with users to ensure the Data Warehouse meets business needs. Definition and management of the User Acceptance Testing programme. Identifying user training needs and devising and managing user training programmes.
Page 16
Developer (2) The Developer is responsible for: Working with the Implementation Manager on definition of development requirements and priorities Specification, design and build of the Data Warehouse. Data Migration. Interfaces with other systems. Reporting configuration and deployment. Set up and maintenance of security rights and access permissions. Contributing to technical strategy, policy and procedure. Development and operation of technical testing programmes. Production of technical documentation to agreed quality standards. Reporting on progress/issues to management and users. System Administration (service provided by MIS Development Unit) The Systems Administration service is responsible for: Management and support of the various environments. Network operating systems management and support. Database management and support. Back-up and disaster recovery measures. Contributing to technical strategy, policy and procedure. Development and operation of technical testing programmes. Production of technical documentation to agreed quality standards. Project Co-ordination (service provided by MIS Development Unit) The Project Co-ordinator is responsible for: Maintenance of the project plan. Maintenance and updating of the project website. Project Administration (service provided by MIS Development Unit) The Project Administrator is responsible for: Routine office support including financial administration. Meeting organisation and minute taking. Training booking. Travel arrangements.
10.4 Education and Training

It is assumed that the UNN staff involved with this project are suitably qualified in terms of background and experience for the tasks to be undertaken.
Page 17
Staff will require training in and familiarisation with the Oracle product suite.
10.5 Project Software/Tools

The software available to the project includes: Software Oracle Express 8i Oracle Express 9i Operating and Other System Software Solaris 8 Veritas Netbackup Software Tools Discoverer Reports 6i Forms 6i
10.6 Project Environments

The project environment is located in the MIS Development Unit at the Technopole although the project team members and Implementation Manager will be required to split their time between this and other locations.
10.7 Software Backup Procedures and System Administration

Backups and basic system administration (machine start-up, shutdown, and recovery) of the working environment software installation will be performed by system administration staff in line with the agreed procedures. Database sizing and environment synchronization will be performed by system administration staff in line with the agreed procedures.
Page 18
11 Quality Management
This section defines how the quality of the project processes and deliverables is to be assured.
11.1 Quality Reviewing

The project sponsor will appoint an external assessor to undertake periodic reviews of the project.
11.2 Test Strategy

The deliverables of the project will be subject to User Acceptance Testing (UAT). UAT phases are included in Phases 1 & 2 of the project. Tests will be carried out according to pre-defined test scripts.
11.3 Test Levels

The following levels of testing will be used for each Phase of this project: CRP 1 Final Acceptance
11.4 Test Execution

The following project roles are responsible for test execution: Implementation Manager Implementation Team User Task Group
Page 19
12 Configuration Management
The Configuration Management process identifies the items that form the configuration that will be developed for the project, baselines these items at intervals, and manages changes to the items. The Data Warehouse Implementation Manager is responsible for Configuration Management on the Project.
12.1 Document Control

Documents will be stored, for the duration of the project, in directories shared by MISDU and the Data Warehouse Implementation Team. SPU document control procedures will apply. SPU will be responsible for document storage and control following Go Live and handover to routine operation and maintenance.
Page 20
13 Appendix A - Workplan
To be added.
Page 21
14 Appendix B - Other Roles and Responsibilities

14.1 Strategic Level
Project Sponsor (1) Champions the project and raises awareness at senior level. Makes key organisation/commercial decisions for the project. Assures availability of essential project resources. Approves the budget and decides tolerances. Leads the Project Steering Board. Ultimate authority and responsibility for the project. Project Steering Board Members (9) Champion the project and raise awareness at senior level. Approve strategies, implementation plan, project scope and milestones. Resolve strategic and policy issues. Drive and manage change through the organisation. Prioritise project goals with other ongoing projects. Communicate with other key organisational representatives. Project Director (1) Provides direction to the project. Direct communication with the wider organisation. Acts as focal point for resolving resourcing issues.
14.2 Management Level

Programme Manager (2) Overall management and co-ordination of the programme of MIS Development projects. Contributes to strategy, policy and procedure. Management of supplier/contractual relationships. Budgetary control of the programme. Monitor and respond to issues at programme level. Directors Co-ordination Group (5) Deals with department co-ordination issues within the project. Supervises the change control function and makes change recommendations to the Project Steering Board.
Page 22
14.3 Operational Management Level

Project Manager (1) Manages the development and maintenance of the project plan. Resolves cross-functional issues at project level. Reports progress to senior management.
Page 23
15 Appendix C - Detailed Functional Requirements

To be added following user consultation.
Page 24

Pid Example Northumbria Datawarehouse

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Pid Example Northumbria Datawarehouse

Caricato da

Copyright:

Formati disponibili

Project Initiation Document

University of Northumbria Data Warehouse

Author: Date Created: Updated: Version:

Gill Ferrell/Andrew McKirgan 28/09/2001 01/11/2001 Draft v8

Copy Number _____

File Ref: J:\JISC Centre\Materials InfoKits\Project Management\Issue\PID_Example_Northumbria_Datawarehouse_i1.doc

File Ref: J:\JISC Centre\Materials InfoKits\Project Management\Issue\PID_Example_Northumbria_Datawarehouse_i1.doc

File Ref: J:\JISC Centre\Materials InfoKits\Project Management\Issue\PID_Example_Northumbria_Datawarehouse_i1.doc

Scope and Application

File Ref: J:\JISC Centre\Materials InfoKits\Project Management\Issue\PID_Example_Northumbria_Datawarehouse_i1.doc

File Ref: J:\JISC Centre\Materials InfoKits\Project Management\Issue\PID_Example_Northumbria_Datawarehouse_i1.doc

Critical Success Factors

File Ref: J:\JISC Centre\Materials InfoKits\Project Management\Issue\PID_Example_Northumbria_Datawarehouse_i1.doc

Overview of Functional Requirements

File Ref: J:\JISC Centre\Materials InfoKits\Project Management\Issue\PID_Example_Northumbria_Datawarehouse_i1.doc

Interface Requirements Security Reporting Training

Overview of Functional Requirements

Customisation Data Conversion

Interface Requirements Security Reporting Training

Overview of Functional Requirements

File Ref: J:\JISC Centre\Materials InfoKits\Project Management\Issue\PID_Example_Northumbria_Datawarehouse_i1.doc

Customisation Data Conversion Interface Requirements Security

File Ref: J:\JISC Centre\Materials InfoKits\Project Management\Issue\PID_Example_Northumbria_Datawarehouse_i1.doc

5 Constraints, Assumptions and Risks

File Ref: J:\JISC Centre\Materials InfoKits\Project Management\Issue\PID_Example_Northumbria_Datawarehouse_i1.doc

Interfaces, Integration, Data Conversion Risks

Hardware, Network, Software Risks

File Ref: J:\JISC Centre\Materials InfoKits\Project Management\Issue\PID_Example_Northumbria_Datawarehouse_i1.doc

Scope, Project Management Risks

File Ref: J:\JISC Centre\Materials InfoKits\Project Management\Issue\PID_Example_Northumbria_Datawarehouse_i1.doc

File Ref: J:\JISC Centre\Materials InfoKits\Project Management\Issue\PID_Example_Northumbria_Datawarehouse_i1.doc

6 Relationship to Other Systems/Projects

File Ref: J:\JISC Centre\Materials InfoKits\Project Management\Issue\PID_Example_Northumbria_Datawarehouse_i1.doc

File Ref: J:\JISC Centre\Materials InfoKits\Project Management\Issue\PID_Example_Northumbria_Datawarehouse_i1.doc

8 Project Tasks, Deliverables, and Milestones

SPU MISDU SPU SPU/MISDU

File Ref: J:\JISC Centre\Materials InfoKits\Project Management\Issue\PID_Example_Northumbria_Datawarehouse_i1.doc

9 Control and Reporting

Risk and Issue Management

Status Monitoring and Reporting

File Ref: J:\JISC Centre\Materials InfoKits\Project Management\Issue\PID_Example_Northumbria_Datawarehouse_i1.doc

File Ref: J:\JISC Centre\Materials InfoKits\Project Management\Issue\PID_Example_Northumbria_Datawarehouse_i1.doc

10.1 Staff Resources

10.2 Project Team

10.3 Project Roles and Responsibilities

File Ref: J:\JISC Centre\Materials InfoKits\Project Management\Issue\PID_Example_Northumbria_Datawarehouse_i1.doc

10.4 Education and Training

File Ref: J:\JISC Centre\Materials InfoKits\Project Management\Issue\PID_Example_Northumbria_Datawarehouse_i1.doc

10.5 Project Software/Tools

10.6 Project Environments

10.7 Software Backup Procedures and System Administration

File Ref: J:\JISC Centre\Materials InfoKits\Project Management\Issue\PID_Example_Northumbria_Datawarehouse_i1.doc

11.1 Quality Reviewing

11.2 Test Strategy

11.3 Test Levels

11.4 Test Execution

File Ref: J:\JISC Centre\Materials InfoKits\Project Management\Issue\PID_Example_Northumbria_Datawarehouse_i1.doc

12.1 Document Control

File Ref: J:\JISC Centre\Materials InfoKits\Project Management\Issue\PID_Example_Northumbria_Datawarehouse_i1.doc

File Ref: J:\JISC Centre\Materials InfoKits\Project Management\Issue\PID_Example_Northumbria_Datawarehouse_i1.doc

14 Appendix B - Other Roles and Responsibilities

14.2 Management Level

File Ref: J:\JISC Centre\Materials InfoKits\Project Management\Issue\PID_Example_Northumbria_Datawarehouse_i1.doc