Project Brief

Version No

Contents

Date Created

Author

Comments

V0103

Approved Brief

13/05/2016

Chris Lawford

Original project brief approved.

V0104

Modified draft

02/08/2017

Chris Lawford

Major revision, following re-boot of project.

V0105

Modified draft

13/09/2017

Chris Lawford

Revision, following comments made by stakeholders on published draft. 

V0101

EST093 V05 copied to EST109 V01

26/09

Chris Lawford

Project code number change.

Final comments added.

Name

Project Role

Date Signed Off

Comments?

Adamson, Karen

Sponsor  

14/09

See document revision details table. 

Brown, Kristina

Estates Data Steward  

Fiddes, Iain

Senior Supplier

12/09

See document revision details table. 

Finnan, Anne

Apps Mgmt

Granum, Geir

Apps Dev Lead

12/09

See document revision details table. 

Henderson, Gillian

Dev Tech Lead

Kraan, Wilbert

Enterprise Architecture

Larnach, Heather

Tech mgmt Lead

Manley, Rob  

Apps Dev Lead

12/09

No

Mann, Richard

Business lead, space mgmt

Matheson, Derrick  

Estates IS Programme Manager

08/09

No.

McFarlane, Andrew  

Service Mgmt Lead

08/09

No.

Pritchard, Colin

Business lead, Maintenance Mgmt

12/09

No.

O

D

Outputs / Associated Deliverables  

Prty*

Primary Responsible

Also Involved

O01

Business Analysis

D01

Space Mgmt Business Analysis

The analysis was initially created and signed off August 2016. This analysis will be refreshed, and will also make use of the new BI/MI analysis toolkit, being produced by project DTI019.    

Link to original document:

K:\ISAPPS\csg\projects\EST109 Strategic Reporting\25 Business Analysis\10 Space Mgmt\ EST109 Space Requirements Document V0101.doc

M

Project Services

D02

Maintenance Mgmt Business Analysis See D01 above. Link to original document:

K:\ISAPPS\csg\projects\EST109 Strategic Reporting\25 Business Analysis\20 Maintenance Mgmt\EST109 HelpDesk Requirements Document V0101.docx

M

Project Services

O02

Technical Design

D03

Space Mgmt Data Design Part of Application and Data Architecture (ADA) document.

M

Enterprise Arch  

D04

Maintenance Mgmt Data Design. Part of Application and Data Architecture (ADA) document.

M

Enterprise Arch  

D05

Space Mgmt SDS  

M

Apps Dev

D06

Maintenance Mgmt SDS

M

Apps Dev  

O03

EDW Foundation Layer

D07

Space Mgmt Foundation Layer  

M

Apps Dev

Enterprise Arch

D08

Maintenance Mgmt Foundation Layer  

M

Apps Dev

Enterprise Arch

O04

EDW Access Layer

D09

Space Mgmt Access layer(s)  

M

Apps Dev

Enterprise Arch

D10

Maintenance Mgmt Access layer(s)  

M

Apps Dev

Enterprise Arch

O05

Semantic Layer

D11

Space Mgmt SAP/BI suite Universe(s)  

M

Apps Dev

D12

Maintenance Mgmt SAP/BI suite Universe(s)  

M

Apps Dev

O06

Presentation Layer

D13

Certified Space Mgmt Report(s)  

M

Service Mgmt

D14

Certified Maintenance Mgmt Report(s)  

M

Service Mgmt

O07

Training

D15

SAP/BI suite Training & Access

S

Service Mgmt

O08

Organisation & Support

D16

The adaptation of the Estates organisation and processes to encompass local support for a BI/MI service(s), within the overall Service management framework.  

S

Estates

Project Services

D17

Service Mgmt: The inclusion of support for Estates within the overall Service mgmt BAU capability.  

S

Service Mgmt

Estates

O09

De-commission preparation for Existing Space Mart Solution

D18

De-commission process  

M

Apps Dev

Apps Mgmt

D19

Parallel run: Existing solution vs. new solution  

M

Apps Mgmt

Estates

What

Details

OS-01

Provision of a separate DW Infrastructure platform for Estates.  

The Estates solution will be built entirely using the EDW platform.  

OS-02

Operational Reporting

Operational reporting will be provided as part of project EST092 and other, follow-on projects. For a comparison of the differences between operational and strategic reporting, see appendix.

OS-03

Provision of MI Dashboards

Dashboards will not be provided as part of this project.  

OS-04

Solving data quality issues within Estates operational systems. 

The project is likely to highlight data quality issues within Archibus and other source systems. The rectification of these data quality issues is outside the scope of this project.  

OS-05

Removal of existing Estates ”Space Mart” solution

The existing Space mart solution will be de-commissioned in live as a consequence of this project but NOT as part of it. The de-commissioning work will be a small apps mgmt task and outside the scope of this project.

What

Details

BE-01

Improved business intelligence regarding hard service maintenance mgmt operations.  Improved ability to drive customer satisfaction and efficiency.  

Workload

Volumes and value of work being managed – operational (live), strategic (archived)

Performance

Number of jobs meeting or missing SLA targets

Productivity

Number of visits per craftsperson per productive period

Cost

Cost spent per work stream, e.g. fire alarm activity, or work team or member of staff

Trend Analysis

Reviewing repeated maintenance activity, per location, asset, work team.

BE-02

Improved business intelligence regarding space mgmt; more regular reporting available.

Improved capability for driving the efficient use of space.

BE-03

An enabler for the combination of space data with financial data so that authoritative “cost per unit area” data is readily available.

BE-04

The EST109 project establishes a precedent and repeatable process for all subsequent business data acquisition projects, both in Estates and across the University.

This will drive the creation of a set of project mgmt guidelines, a deliverable via the EDW programme.

Milestone

Date

Governance Milestone?

Details

1. Project re-planning complete  

04-Aug-2017

Yes

2. Business Analysis refresh complete  

09-Oct-2017

No

3. Design complete  

22-Dec-2017

No

4. Acceptance Sign-off review (ASOR)

19-Apr-2018

No

Dependent upon the EDW Test environment available (DTI006).  

5. Deployment DSOR

04-May-2018

Yes

Dependent upon the EDW “Production Ready” programme milestone being reached (DTI006).

6. Project Close  

28-May-2018

Yes

Advantages

Disadvantages

A01. Estates benefits realisation is as early as possible.   

D01. Heavy dependency upon the deliverables of project DTI006.

A02. Project gets more resource focus than is likely if competing against other, higher priority initiatives (student systems, service excellence, core system upgrade).    

D02. ETL processes may be developed using a tactical tool, rather than a strategic one. This may lead to future support issues and/or additional future costs in migrating to the strategic ETL platform.

A03. Estates have the opportunity to become ambassadors for the new BI/MI service across the University and beyond.  

D03. EDW environments are new, and may be subject to change / unavailability at short notice. A degree of flexibility and understanding is required from the project team.

D04. As the technology is new, there will be an inevitable learning curve within the development organisation. This will lead to longer development tasks and higher costs for early adopters. This has been built into the project plan.  

Phase

Activity

Task

A

Planning 

A01

Project Brief 

A02

Planning Sign-off

B

Business Analysis

B01

Space Mgmt

B02

Maintenance Management

Analysis sign-off

C

Technical Design

C01

Space Mgmt Data Design

C02

Maintenance Mgmt Data Design

C03

Space Mgmt SDS

C04

Maintenance Mgmt SDS

D

Build (EDW)

D01

Build Space ETL

Source -> Foundation

Foundation -> Access

D02

Build Maint ETL

Source -> Foundation

Foundation -> Access

E

Build (BI)

E01

Create Space Universe

E02

Create Maintenance Universe

F

Build (Reports)

F01

Build Space Report(s)

F02

Build Maintenance Report(s)

G

Training

G01

SAP BI Suite training for Estates

H

Test

H01

Create Integration Test Plan

H02

Execute Integration Test

H03

Create UAT Test Plan

H04

Execute UAT

H05

ASOR

I

Organisation

I01

Establish Estates BI Super-user  

I02

Service Mgmt preparation

J

Deployment

J01

DSOR

J02

Go Live

K

De-commission Space Mart

K01

Create de-commission process

K02

Prove de-commission process (DEV)

K03

Parallel run existing vs. New

L

Close

L01

Project Completion Report

L02

Handover BAU support to Service Mgmt

L03

Project Close

What

Details

1

Estates must provide strong and clear sponsorship and business leadership.  

Due to the nature of BI / MI style projects, success requires strong collaboration between IS and the business.   

The appointed Sponsor must engaged and available to assist the business lead and project manager when issues and escalations occur.   Will act as the ultimate decision maker within Estates.   

2

There must be strong and detailed involvement from various subject matter experts within the Estates dept.  

Due to the nature of BI / MI style projects, success requires strong involvement from Estates subject matter experts.

The appointed Business leads must also be engaged and able to broker agreement and take decisions on behalf of the whole of Estates. The business leads must have a direct line to the sponsor.  

3

Delivery of Enterprise Data Warehouse infrastructure via project DTI006.

The delivery of this project is dependent upon the delivery of DTI006.

4

The availability of specialist skills required to successfully execute a DW / MI / BI project.

We are establishing the core skills and expertise as part of the EDW programme.   

It’s important for both Estates and EDW to allow the key resources to have sufficient time to work in both areas.

What

Details

A01

Project will use the standard university BI/MI toolset e.g. BI Suite  

This has been confirmed. Although the new BI/MI tools modernisation programme will be initiated during 17/18, it is not expected that this will impact this project.  

The existing investment in SAP BI Suite mean that it couldn’t be replaced within a 3-5 year horizon.      

A02

Estates are permitted to access and use data not owned by Estates (e.g. finance data in held eFinancials).  

The role of the data steward has been defined.   

A03

Estates will establish a BO reporting specialist-user function to enable self-service reporting capability.   

- Likely to start with 2-3 people, covering space and maintenance.

- Responsible for support for BI across Estates – initially SAP BI-Suite but later to cover other tools.

- Responsible for ad-hoc reporting, creating and publishing “non-certified” reports for other Estates BI consumers.   

What

Details

C01

Data Frequency

The ETL process can be computer resource intensive and may be constrained by operational system service availability or performance considerations.   It is “usual” to extract operational data no more frequently than daily, normally during non-service hours.

C02

Data Latency

All reporting will be constrained by the frequency of the ETL process. For example, if the ETL process for an operational system runs daily, then any resultant reports will show data that is up to a day old. 

C03

Data Granularity

All reporting will be constrained by the granularity present within the extracted data.

For example, if data is extracted at a summarised level, then reporting can only be conducted at a summarised level.

It is therefore usual to extract operational data at the most detailed level possible. Summaries and totals can then be created within EDW.  

C04

Data Quality

The accuracy and quality of the strategic reporting provided can only be as good as that of the source operational systems. A project of this nature is likely to uncover and highlight any data quality issues with its source operational systems, or with the way data is loaded into the DW. This may require operational business processes to be adapted, or one-off data clean-up activities to be undertaken.      

Title / Description

Probability* Impact** /

Management Approach / Mitigating actions

R01

Lack of availability of specialist BI/MI IS skills

There is a risk that there will be delays in the design / build process of the DW, due to the lack of  specialist BI/MI skills being made available to the project, leading to overall delays in delivery, or compromises in the design of EDW. This has been noted as a key challenge for the IS organisation.

Medium/ Moderate  

REDUCE.   

1) Work with IS resourcing to ensure the skills required are available to the project.

This is in conjunction with the EDW programme. 

R02

Lack of detailed business requirements

Due to the nature of MI/ BI there is always the possibility that detailed and objective requirements may be difficult to create.  

Low/ Moderate  

REDUCE. 

1) Prepare and agree the involvement of the business up front, to ensure enough thought is put in at analysis level.

2) Build the subject areas as flexibly as possible. Accommodate as many data elements as feasible within the design, even if there is no immediate requirement.

R03

Lack of Business Leadership

Strong business leadership is essential in any BI/MI project.  This is at both Sponsor and business lead level.

Medium/ Moderate

REDUCE.  

1) Prepare and agree the involvement of the business up front.

R04

Lack of Business Involvement

Estates must adequately engage with the project at the subject matter level. This will require the business experts to spend time in workshops and other project driven activities.   

Medium/ Moderate  

REDUCE.

1) A separate business resource estimate will be prepared and form part of the sign-off for the next phase.

R05

Temptation to take short cuts

Building a reliable, scalable and lasting Data Warehouse requires time and effort to be expended in the creation of the basic building blocks. There is always a temptation to take short cuts to speed up delivery at the expense of long term goals.  

Low/ Moderate

REDUCE. 

1) Gain buy-in to the concept of EDW.

R06

Changes to Project scope

Due to the difficulty in creating objective business requirements, the project may be liable to scope change. The plan needs to be flexible enough to accommodate this.  

Medium/ Moderate

REDUCE.

1) Design & Build the ETL process as flexibly as possible. To accommodate as many data elements as possible, even if they do not all get stored within the foundation layer.

2) Design & Build the foundation layer as flexibly as possible, capturing as much captured data as is reasonable.

3) Design & Build the access, semantic and presentation layers as flexibly as possible. Accommodate as many data elements as feasible within the design, even if there is no immediate requirement.

R07

Delivery of the EDW infrastructure platform

The initial EDW capability is being delivered by project DTI006 and there are numerous and substantial dependencies between the two projects.   

Medium/ Major

REDUCE.

R08

Strategic ETL Tool is not in place.

Very High/ Minor

ACCEPT

Who

Brief Sign-off Required?

Role

Communication Plan

Adamson, Karen  

Y

Sponsor

Senior Stakeholder

Berry, Dave  

N

IS Enterprise Architecture

Interested 3^rd Party

Brown, Kristina

Y

Estates Data Steward

Senior Stakeholder  

Carter, Alex  

N

IS Service Mgmt

Interested 3^rd Party

Fiddes, Iain  

Y

Senior Supplier

Senior Stakeholder

Finnan, Anne  

Y

Apps Mgmt Lead

Project Team

Granum, Geir  

Y

Dev Apps (BI) lead

Project Team

Henderson, Gillian  

Y

Dev Tech Lead

Project Team

Heyn, Ana

N

Apps Mgmt Lead  

Project Team? (I have asked Ana H, Anne F  to confirm if they both wish to be part of the project team).

Kraan, Wilbert

Y

Enterprise Architecture Lead  

Project Team

Lang, Mark  

N

Dev Tech manager

Interested 3^rd Party

Larnach, Heather  

Y

Tech Mgmt Lead

Project Team

Lawford, Chris  

Y

Project Manager

N/A

Lee, Bill

N

Apps Dev Manager  

Interested 3^rd Party

Ma, Defeng  

N

Apps Dev Manager

Interested 3^rd Party

Manley, Rob  

Y

Dev Apps Lead

Project Team

Mann, Richard  

Y

Business Lead

Project Team

Matheson, Derrick  

Y

Estates Programme Manager

Senior Stakeholder

McFarlane, Andrew  

Y

Service Mgmt Lead

Project Team

McLeod, Ron

N

IS Subject matter expert for existing space mgmt solution  

Interested 3^rd Party

Pritchard, Colin  

Y

Business Lead

Project Team

Communication Plan

Details

01

Senior Stakeholder

- Receives Monthly Project report

- Receives regular updates from Programme Manager  

02

Project Team  

- Attends regular team meetings

03

Interested 3^rd Party  

- Receives Monthly Project report

04

Inter project dependency

- Regular catch-up meetings between PMs

Subject Area

Prty

Details

1

Space Mgmt

HIGH

Upgrade and/or re-engineer existing Space Mart solution, in support of :- 

- Estates space mgmt.

- Resource Allocation Model (RAM) in development by Governance And Strategic Planning (GASP) - Enabler for Estates Mgmt Record (EMR) process. - Potential use of timetable data for more accurate RA2018 reporting.

Gasp have confirmed that 2017/2018 RAM process will use the existing space model.

2

Maintenance Mgmt

HIGH

Create a data mart to support performance mgmt. and decision making of the new helpdesk and maintenance workflows.

It may be that part of this requirement will be satisfied as part of EST092 Operational reporting.  

3

Finance Mgmt  

MED

Financial data is already available as part of the enterprise DW.

For estates, summary data is extracted, and then manipulated for reporting and control purposes.

However, the underpinning detailed financial data is in Archibus, and there needs to be a way of cross referencing one to the other.

NB. There is a danger that 2 different (but related) flows of data could show different results e.g.

a) Summary:  Archibus -> eFin -> ESSA

b) Detail: Archibus -> ESSA?  

4

Energy Mgmt  

LOW

Monitoring & Targeting (M&T) Operational System is Optima, currently under review (May 2016).

Optima can provide extensive reporting (operational, strategic) out of the box.

It’s envisaged that UofE energy stakeholders will use Optima directly to access detailed reporting.

This will satisfy any short term requirements for

However, could be some significant benefits in bringing a summarised set of energy figures into EDW to allow energy consumption etc. to be used in conjunction with other figures to calculate e.g. energy consumption per room.

At this stage, this benefit is ‘imagined’, rather than based upon any empirical requirement. 

HESA (Higher Education Statistics Agency) annual reporting is currently created from Optima extracts, with manual manipulation, correlation, data cleansing and validation.

There is not a strong requirement at present to automate the production of HESA energy figures.  

5

Capital Planning  

LOW

No specific operational system in place to handle Capital planning /projects. Currently data is pulled together manually from multiple sources into one complex XLS.

Current audit /study underway to review how Estates manage their Capital projects, and to recommend ways of working, and suitable underpinning operational systems.  

Overall, it would seem sensible for any plans to move Capital Planning data into ESDW to wait for the outputs of the audit / study.  

6

Asset Mgmt

LOW

Estates are in the process of starting up a project to create an Asset Register.

One for the future.

7

Supplier Mgmt  

LOW

Estates use several different procurement systems (PECOS, Sciquest, LPM part of eFin)).

Intention is to consolidate procurement into SciQuest.

Issue with sheer volume of different supplier – e.g. same supplier has different billing / ship-to in different systems. Monitoring spend / buying limits is a challenge.

8

Security Mgmt

LOW

Need to know how estate will grow, to forecast growth in security assets (people / technology).

Operational security systems in use :-

 - Incident mgmt. – Perspective (supplier = resolver)

 Provides a level of its own mgmt. reporting. Ok for the time being.

 - Access Mgmt – C*Cure (supplier = Tyco)

Would be interested in stats e.g. volume of alarm calls per building / analysis of CCTV breakdowns.

9

Strategic Mgmt  

LOW

Dashboards / KPIs

Possible future development.

These are the KPIs produced by Estates on an annual basis. They are currently collated manually from a variety of sources.

1. Income per square metre
2. Investment in Buildings 5% of IRV
3. Capital spend as a % of total University income
4. Building condition at grades A and B
5. Cost to upgrade to condition B is 5% of IRV
6. Maintenance Statutory Compliance
7. Response to Helpdesk Calls
8. Health and Safety
9. Cleaning Services
10. Servitorial Services
11. Overall Department customer satisfaction level
12. Waste Services (landfill avoidance)
13. Teaching Utilisation measures
14. Absence
15. Carbon Emissions

Strategic Reporting

Operational reporting

1

Report contains historical data, and is concerned with aggregates, trends and patterns.

Report contains current data and is typically concerned with events that happened today or yesterday.

2

The underlying data is rarely required to be close to ‘real-time’. Yesterday’s, last week’s or last month’s data is sufficient.

The underlying data needs to be up-to-date e.g. it needs to be ‘real-time’, or close to it. It should be comparable to the contents of the operational system 

3

Reports supports strategic and ad-hoc business decision making processes within an organisation.

Report supports a set of defined, regular and repeated operational processes.

4

Report is presented at an aggregated and summarised level, but frequently with drill-down access to the underlying transactional data.

Report relates primarily to some form of transactional activity, and as a result is quite granular in detail.

5

The information presented can be extracted from multiple, diverse operational systems. Reports will commonly cross departmental boundaries, and may contain information with different data owners.

The information presented is extracted from a single operational system.

6

The information presented may not correlate closely with any single source of data. E.g. the terminology, column headings etc. may be quite different.

The information presented is closely correlated to its source operational system. E.g. the terminology, columns headings etc. will match operational system.

7

Report can be presented in a tabular, matrix format, but also in a number of graphical and visually helpful ways e.g. Dashboards, Graphs etc. 

Report is normally presented in a tabular, matrix format.  

8

Reporting is commonly produced using a set of Data Warehouse (DW), Business Intelligence (BI) and Management Information (MI) tools and techniques. See below.

Term

Description  

Access Layer

A conceptual space within EDW.

Data is transferred from the Foundation layer, using ETL tooling.

It is the layer that contains the solution specific data marts and start schemas, and is designed for targeted, quick and efficient access.

The access layer utilises the concept of dimensional modelling.

It is normally considered an externally focussed space, with many users accessing data via tools such as Business objects etc.

BI

Business intelligence (BI) can be described as “a set of techniques and tools for the acquisition and transformation of raw data into meaningful and useful information for business analysis purposes”.

Business Objects (BO)

Part of SAP BI Suite. Toolset used to creates the semantic layer (universe) and reports.

Dashboard

In management information systems, a dashboard is “an easy to read, often single page, real-time user interface, showing a graphical presentation of the current status (snapshot) and historical trends of an organization’s or computer appliances key performance indicators to enable instantaneous and informed decisions to be made at a glance.

Data Mart

A data mart is the access layer of the data warehouse environment that is used to get data out to the users. The data mart is a subset of the data warehouse that is usually oriented to a specific business line or team. Data marts are small slices of the data warehouse. A popular form of Data Mart is a Star Schema.

Data Model

A data model is an abstract model that organizes elements of data and standardizes how they relate to one another and to properties of the real world.

Data Steward

A Data Steward is responsible for a particular data set. They ensure the data is secure, authorise access, ensure it is documented and establish data quality processes.

The University’s Central Management Group has approved a recommendation to formally define this role and to assign stewards for the University’s core data sets.

Data Warehouse (DW)

A data warehouse (DW or DWH) is a system used for reporting and data analysis. DWs are central repositories of integrated data from one or more disparate sources. They store current and historical data and are used for creating analytical reports for knowledge workers throughout the enterprise.

Dimensional Data Mart  

See Star Schema

DW

See Data Warehouse

EDW

Enterprise Data Warehouse

Generic term for the Corporate Data Warehouse, storing data from across the University.

The Enterprise Data Warehouse service will:

• provide a platform to store University data translated into University terminology for management information and business intelligence purposes
• manage a service for the extraction and translation of data from source systems ensuring that data is consistent with the source system
• provide high quality, performant, access to the data in the EDW for consumption by BI tools
• curate data definitions and purpose for each of the EDW elements
• advise and respond to changes required to support strategic decision making and University reporting needs
• reduce the coupling with source systems and BI tools, thus simplifying the migration from one vendor to another  

ETL

Extract, Transform and Load (ETL) refers to a process in database usage and especially in data warehousing that:

- Extracts data from operational systems - Transforms the data for storage in a proper, long-term format - Loads it into the final target subject area.

Foundation Layer

A conceptual space within EDW.

Data is transferred from the Staging layer, using ETL tooling.

It is the layer that contains the enterprise data model, and is at the very heart of EDW.

The enterprise data model utilises the concept of hyper generalised modelling.

It is considered an internal space, with only very specialist users able to gain access.

Hyper Generalised Modelling (HG)

A technique for modelling data and its relationships.

This is used within the foundation layer.

MI

A management information system (MI or MIS) focuses on the management of information systems to provide efficiency and effectiveness of strategic decision making. The concept may include systems termed decision support system, expert system, or executive information system.  

Normalisation / De-normalisation

Database normalisation is the process of organizing the columns (attributes) and tables (relations) of a relational database to minimize data redundancy. Normalization involves decomposing a table into less redundant (and smaller) tables without losing information; defining foreign keys in the old table referencing the primary keys of the new ones. The objective is to isolate data so that additions, deletions, and modifications of an attribute can be made in just one table and then propagated through the rest of the database using the defined foreign keys. Typically used in OLTP systems, not designed for efficient reporting. Implies that one piece of data (e.g. Building name) is only stored in 1 place.

De-normalisation is the process of attempting to optimize the read performance of a database by adding redundant data or by grouping data. This is a technique typically used in Dimensional (Star Schema) Data marts and are designed for efficient reporting. Implies that one piece of data (e.g. Building name) could be stored in many places.

OLAP

On line analytical processing, or OLAP is an approach to answering multi-dimensional analytical queries swiftly. OLAP is part of the broader category of business intelligence, which also encompasses relational database, report writing and data mining.

OLTP

On line transaction processing, or OLTP, is a class of information systems that facilitate and manage transaction-oriented applications, typically for data entry and retrieval transaction processing. E.g. Archibus, eFinancials.

Semantic Layer

A semantic layer is a business representation of corporate data that helps end users access data autonomously using common business terms. It maps complex data into familiar business terms such as product, customer, or revenue to offer a unified, consolidated view of data across the organization. This is the purpose of a Business objects universe.

Slowly Changing Dimension (SCD)

Dimensions that change slowly over time, rather than changing on regular schedule, time-base.

A good example is the universities organisational structure. This data is relatively static, but does change from year to year. However, it is usually important to track these changes, to enable accurate historical reporting.

Staging Layer

A conceptual space within EDW.

The staging layer is used for ETL activities such as loading, validating and transforming data.

It is normally considered an ‘internal’ space, not accessible to users.

Star Schema

Star schema is the simplest style of data mart schema and is the approach most widely used to develop data warehouses and dimensional data marts. The star schema consists of one or more fact tables referencing any number of dimension tables. Also known as dimensional data marts.

Static Dimension

Data that is required within a data Warehouse but doesn’t change (as part of any regular update activity).

Static dimensions are not extracted from the original data source, but are created within the context of the data warehouse. A static dimension can be loaded manually — for example with status codes — or it can be generated by a procedure, such as a date or time dimension.  

Subject Area  

The foundation layer within EDW will conceptually be made up of business specific containers known as subject areas. These subject areas will be built over time, as and when business driven projects deliver data into EDW.  The subject areas can be linked together in many different ways, to provide enterprise wide information.

Universe  

A semantic layer provided by Business Objects

Version No

Comment / Response

Date

Who

Document Updated?  In Version? When?

V0104

When you write that the scope is “better” in the preamble do you really mean, clearer perhaps?

CL: Updated.

Also I recognise the need to make sure we can drop elements of the project should we find ourselves pressed for resource or funding but are we really able to drop things like production handover and support from the project. I am slightly worried that if we make this assumption then when the time comes this is the first thing against the wall…

I would prefer that we looked again at the project objectives and decided which of those components we could prioritise in extremis. The solution of course is to flex the budget (up the way) and this is also an option I’m fine with if this is preferred.

CL: I am not aware of any pressures at present to the scope of the project. We have a funding gap, and were are working to close it. The two subjects areas in scope are closely linked together, we would if difficult to deliver one without the other.   

12/09

Iain Fiddes

YES

V0105

13/09

V0104

GG: Are these the ADA document (applications and data architecture) as described on: https://www.wiki.ed.ac.uk/display/insite/Project+Methodology+and+Enterprise+Architecture  ??

CL: Yes, this is a good point. I would expect this deliverable to be incorporated within the ADA. I have updated the description.

12/09

Geir Granum

YES

V0105 13/09

V0104

KA: I am very supportive of the project as you know and  I am happy to approve the brief subject to some minor amendments/ queries as follows:

Section 4 – Scope - Maintenance management.  Could we tighten up the wording of this scope (Colin to assist?) as I am not clear on what we are getting.

CL: I have tightened up the wording. 

Section 8 – Benefits – BE-02 – I would not mention resource allocation as I am uncertain about what is happening to this – I would put the full stop after space.

CL: I have removed the reference to resource allocation.

BE-03 – Slightly nervous about this as I would hate people to draw the wrong conclusions from the ‘numbers’ – Do we know what eFin information is going in?

CL: I’m not sure this is still in scope – It will be down to the detailed analysis. I will add that this work is an enabler and moves us in this direction.  

14/09

Karen Adamson

YES

V0105 15/09

V0104

CP: Section 4 – Maintenance Management

My reading of this section was a brief narrative to explain what Maintenance Management is, rather than a deliverable, with the second set of bullets outlining the deliverables – agreed set of reports etc.

A further wording of Maintenance Management could be – Covers hard services maintenance delivery, including 60k reactive maintenance tasks, and 15k planned and compliance maintenance tasks.  

18/09

Colin Pritchard

YES V0105 25/09

V0101

Project EST093 renamed to EST109, and references to project code changed throughout. Document changes from EST093 V0105 to EST109 V0101

26/09

Chris Lawford

YES V0101 26/09

V0101

Agreement to amendment, based upon feedback from Apps. Mgmt (AF).

1. I will write into the scope that Space Mart will be de-commissioned in live, as a consequence of the project but not as part of the project. 

2. The project will undertake to:

- Create a de-comm process.

- Test the de-comm process against DEV.    

3. The project will undertake to:

- Once LIVE, perform 1 parallel run Old vs. New. This will either be as part of normal schedule, or a special run, depending upon timing.

- When parallel run has completed, we would remove user access to Old DB/Reports. 

4. Post project, Apps Mgmt would undertake to execute the de-comm process in LIVE.

27/09

Anne Finnan

NO

V0101

27/09