Project Initiation Document
Project Cumulus
Cumulus Project Only Last updated Monday, 13 December 2010
Project Initiation Document for Project Cumulus
2
Version Control
Version Comments Author
Project Initiation Document for Project Cumulus
3
Project Initiation Document for Project Cumulus ... 2
Version Control ... 2
Purpose of Document ... 4
Background ... 4
Project Cumulus Vision ... 5
Project Objectives ... 6
Project Benefits ... 7
Success Criteria ... 8
Project Structure ... 9
Roles and Responsibilities ... 10
Project Management Board... 10
Project Manager for Project Cumulus ... 10
Consortium Members ... 11
User Acceptance Testing Manager (UAT) ... 12
Project Manager for UNIT4 ... 12
UNIT4 Product Manager ... 12
Responsibilities Chart – Project Cumulus... 13
Project Control ... 14
Project review meetings ... 14
Main reports ... 15
Change Control ... 16
Project Scope ... 17
Milestone Plan ... 18
Assumptions ... 19
Constraints ... 19
Dependencies ... 19
Project Initiation Document for Project Cumulus
4
Purpose of Document
The purpose of this Project Initiation Document (PID) is to present the project requirements and responsibilities of Project Cumulus, and to introduce a common understanding of the implementation methodology to be used in the management of the project. This document details the Objectives & Scope of the project, the Procedures & Strategy that are to be employed and the Roles &
Responsibilities of the Project Cumulus consortium and UNIT4 Business Software Limited.
Background
Project Cumulus is a JISC funded project to demonstrate how a large ERP system can be disaggregated to allow modular functionality from that system, which will then be offered and supported within the “cloud”.
It is intended that the cloud deployment approach will be supported by a Service Orientated
Architecture, which will enable integration and interoperability with other systems to be achieved using Web Services.
The project will explore and report on the issues of deployment in such an environment and the modular, cloud based approach will be tested at 4 different Universities.
Project Initiation Document for Project Cumulus
5
Project Cumulus Vision
It is important to identify and understand the Vision that Project Cumulus must satisfy. Listed below is the Vision detailed in the Project Cumulus proposal provided by the lead institution, Roehampton University, to JISC as the prime driver for the project:
Demonstrate that it is possible and productive to develop a modular approach to systems architecture and to deliver “services” for the HE Sector from the “cloud”
To change the current common implementation situation where one supplier and one large system (or ERP installation) attempts to satisfy the requirements of an increasingly volatile and complex HE business landscape in each individual institution
To demonstrate that it is possible to work with suppliers to develop new methods of product development and deployment. These new methods must satisfy the requirements of the institutions for agility, flexibility and cost effectiveness and the requirements of the suppliers for a revenue stream which will enable research and development and software
supportability.
To achieve this vision the consortium has chosen to undertake this project using Agresso Curriculum Management System (ACMS). The project will:
Remove the dependencies of the ACMS module on other non-administrative modules in the ABW Framework and place it in the cloud
Facilitate communication with the “outside world” (workflow) through web services and Enterprise Service Bus technology
Raise and explore new issues relating to the storing of User Accounts and Passwords, integration with enterprise directories and with identity management systems on different platforms and from different suppliers
Explore the impact of these issues within the context of a modular, cloud based application deployment.
Project Initiation Document for Project Cumulus
6
Project Objectives
Given the Vision identified, a number of Project Objectives have been identified that will allow the Vision to be achieved. Listed below are the deliverables detailed in the Project Cumulus proposal provided by the lead institution, Roehampton University, to JISC as the prime driver for the project:
A standalone business module, with a specific set of business processes, available in the Cloud
A set of web services which enable data to be imported and exported from the module XCRI/Unit 4 mapping Document
Report on XCRI 1.1 suitability and recommendations
A set of standards for web services which facilitate interoperability especially with XCRI
A set of web services facilitating links to business processes and workflows within other systems
An exploration of the issues which impact on this type of deployment with suggested solutions.
Project Initiation Document for Project Cumulus
7
Project Benefits
One of the requirements of a successful project is that Project objectives must be clearly
communicated and perceived to have value. Objectives and Benefits can be associated with each of the Project Drivers identified. By achieving the objectives and benefits the Project will be considered successful. Listed below are the benefits detailed in the Project Cumulus proposal provided by the lead institution, Roehampton University, to JISC as the prime driver for the project:
The project will provide evidence of how the barriers to integration can be overcome, how it is possible to work with suppliers towards the specific objectives of modularisation and cloud computing solutions.
It will enable an exploration of what deployment in the cloud will mean for cost of provision, licensing arrangements, support and new business models both for supplier and customer.
It will illuminate, although not necessarily solve, “hidden” problems within this method of service delivery.
Although this is essentially a proof of concept project the value of the investment by the JISC lies in the potential of a production system, with a set of re-usable, interoperable web services which have been defined by the consortium to meet the needs of the HE marketplace. The cloud environment would allow institutions to take and share benefit without the normal infrastructure costs borne by each individual implementation. Unit4 estimates that there will be considerable savings to be made through deployment in the cloud, specifically on hardware, maintenance and support costs. The company estimates, without prejudice, that these saving could amount to £50,000 per institution which indicates that the sector would benefit financially overall with as few as 3 or 4 sales of the production application.
Project Initiation Document for Project Cumulus
8
Success Criteria
Many things must happen in order for the project to be completed. Critical Success Factors are the things that are essential if the project is to be successful. As set out in the Project Cumulus proposal, the project will be considered to be a success if:
The ACMS module is accessible within the cloud
The web services, conforming to clearly specified standards, enable the importing and exporting of data to and from the module
Interoperability is achieved through XCRI compatible web services
The module, in the cloud, carries out the business functions correctly
Issues which impact the deployment in the cloud and operability with web services are thoroughly documented
Project Initiation Document for Project Cumulus
9
Project Structure
Dr John King has been appointed as Project Sponsor/Project Manager, who will:
actively support the project
obtain “buy in” from consortium members
support the cultural change
provide a pragmatic approach and timely decision making
Dr John King will ensure sufficient resources are made available to carry out the tasks identified for a successful implementation (refer to section 10 for assumptions).
An effective communication plan is put in place both within the Project Team and the wider organisation.
Project Initiation Document for Project Cumulus
10
Roles and Responsibilities
The roles and responsibilities of people required to be involved in the project are defined below. A Responsibilities Chart listing the names of the individual people is shown at the end of this section.
Project Management Board
A Project Management Board comprising representatives of the Project Cumulus consortium members together with Paul Harnden and Peter Brown of UNIT4 has been formed.
The Project Management Board is responsible for:
Facilitating the smooth running of the project
Making key business decisions on project critical issues, for example, availability of user resources
Attending project board meetings
Identify and specifying any external constraints on the project
Approving an accurate and satisfactory Project Initiation Document (PID), ensuring it complies with the relevant JISC standards and policies, plus any associated contract with the supplier
Committing project resources
Providing guidance and direction to the project, ensuring it remains within any constraints
Approving changes to the project scope.
Project Manager for Project Cumulus
The Project Manager for Project Cumulus will is responsible for the day to day management of the project and for ensuring that the Project Team and consortium members are suitably well informed of their project roles.
In this instance the Project Manager will be Dr. John King, who is also undertaking the role of Project Sponsor.
The Project Manager will:
Produces and maintains the project plan in conjunction with the Project Manager from UNIT4
Monitors the project and reports back to the Project Management Board on progress at regular project meetings
Manages the „Change Control‟ procedure by agreeing changes at the project board meeting
Ensures operational decisions are followed up promptly and effectively
Maintains communications within the consortium, with JISC, with the Project Management Board and relevant external bodies
Project Initiation Document for Project Cumulus
11
Acts as the primary line of communication between UNIT4 and the Project Cumulus consortium.
Consortium Members
The Senior Users are consortium staff members, who understand the business requirements and are familiar with existing business processes.
The Senior Users:
Work with UNIT4 consultants to configure Agresso Curriculum Management System to meet the business requirements of Project Cumulus
Identify the business procedures for the individual business functions
Manage the production of business procedures
Train End Users if appropriate
The Agresso Curriculum Management System must be the responsibility of a Senior User who is capable of fully understanding the relationship between the Agresso Curriculum Management System, non-Agresso systems and the business. This Senior User will become the Lead Application Expert
Project Initiation Document for Project Cumulus
12
User Acceptance Testing Manager (UAT)
The User Acceptance Manager role will be undertaken by Super Users from each consortium and will be co-ordinated by Dr John King:
Plans the scope and coverage of the testing
Identifies the Users who will carry out the testing
Prepares the procedures that Users will follow during the testing
Reports the test results to the Project Manager after each round of testing
Project Manager for UNIT4
The Project Manager for UNIT4 is responsible for coordinating all activities on the project.
The Project Manager for UNIT4, Paul Harnden:
Ensures that UNIT4 meets its obligations to the consortium
Acts as the primary communicator between UNIT4 and the Project Cumulus consortium
Provides support to the Project Manager for Project Cumulus
Supports the Project Manager for Project Cumulus in the production and maintenance of the project plan.
UNIT4 Product Manager
The Implementation Consultants for UNIT4 are responsible for the delivery of training and advice on the configuration of the system.
The Implementation Consultants for UNIT4:
Run any Agresso Curriculum Management System training, if required
Work with Project Cumulus Senior Users to configure the Agresso Curriculum Management System to meet the identified business requirements
Liaise with the UNIT4 Project Manager to ensure that any actions are followed up promptly and effectively
Project Initiation Document for Project Cumulus
13
Responsibilities Chart – Project Cumulus
Responsibility Name
Project Management Board De Montfort University
Christ Church Canterbury University The University of Nottingham The University of Lincoln Roehampton University
Project Manager Dr John King
Project Manager – UNIT4 Paul Harnden
Education Product Manager Caroline Drew
UK Platform Manager Tim Strong
Senior Users
Consortium Members De Montfort University
Christ Church Canterbury University The University of Nottingham The University of Lincoln Roehampton University
Project Initiation Document for Project Cumulus
14
Project Control
Control of the project is maintained by holding regular project meetings. A summary schedule is detailed below showing the main checkpoints in the life of the project:
Summary Schedule
Sign Off of Web Services Design Document
Delivery of Cloud based Agresso Curriculum Management environments
Completion of adequate Integrated Systems Testing and User Acceptance Testing Assistance with the completion of the required reports
Project review meetings
Project Management Board meetings are planned to be held at regular intervals throughout the life of the project. The provisional dates are detailed below:
Tuesday, 20th July 2010 Thursday, 23rd September 2010 Thursday, 14th October 2010 Thursday, 25th November 2010 Wednesday, 12th January 2011 Wednesday, 16th February 2011 Thursday, 31st March 2011 Wednesday, 11th May 2011 Wednesday, 1st June 2011 The meetings will be attended by:
Project Management Board members
Project Manager for UNIT4
Project Initiation Document for Project Cumulus
15
Main reports
The Project Managers for Project Cumulus and UNIT4 will prepare a monthly status report for discussion at the monthly project Management Board meeting. The Project Sponsor will use the report to monitor progress on the project. The reports will highlight:
Main activities during the reporting period
Significant issues arising from current activities, and any operational decisions taken to address the issues, if any
The possibility of meeting future milestones based on activities and timescales since the last report – to be given as a percentage
Project Initiation Document for Project Cumulus
16
Change Control
Should UNIT4 or consortium members consider that there is a need for a significant change to the project, then a Change Control Note (CCN) must be issued.
Neither UNIT4 nor the consortium members will unreasonably withhold its agreement to any change.
UNIT4 and the consortium members will discuss any changes proposed by either party and: Either:
Agree not to proceed further Or
The consortium members will confirm the request for change
Or
UNIT4 will recommend a change
When a request for change is submitted, an Impact Assessment should be carried out. During the assessment, the following points should be considered:
Project milestones
Overall timetable for the project
Implementation plan for the project
Price to be charged
Overall project costing
Documentation
Resources
Contractual issues
Serviceability and performance levels System configuration
Project Initiation Document for Project Cumulus
17
Project Scope
Inside Scope of the project
Delivery of the Agresso Curriculum Management System:
A centrally hosted ACMS environment comprising of:
Secure HTTPS connectivity to individual client web sites
Individual client database instances on a single database server
Agresso Smart Client via Citrix or Application Managed Service for systems administration
To implement Microsoft ISA Server/Forefront Server to manage authentication. System interfaces which currently include the following systems:
Secure HTTPS connectivity to individual Web Service instances per client organisation
To provide a Curriculum Web Service that will be XCRI compliant
To provide a Resource Web Service for inbound traffic only that will be used to populate the ABW HR module within the centrally hosted ACMS installation
To provide an Attributes Web Service , which will be two-way for the retrieval and updating of attribute values (reference data)
All Web Services will conform to XML & SOAP standards. The following reports and documentation:
A report on XCRI 1.1 suitability and recommendations (compiled by the consortium)
A set of standards for web services which facilitate interoperability (compiled by the consortium)
An exploration of the issues which impact on this type of deployment with suggested solutions (compiled by the consortium).
Project Initiation Document for Project Cumulus
18
Milestone Plan
Phasing for the delivery of the Agresso Curriculum Management System deliverables has been agreed as follows, and is described in more detail in the project plan.
Target project completion: June 2011
The table below shows the key milestones used for the high level planning.
Key Project Milestone End Date
Completion of Web Services specification document November 2010 Delivery of Cloud based Agresso Curriculum Management
environments
November 2010
Delivery of Web Services December 2010
Testing by Consortium December 2010-May 2011
Contribution by Consortium to final documentation April 2010-May 2011
Project Closure June 2011
IMORTANT: The timing, resource requirements and detailed tasks for these phases will not be finalised until the requirements analysis has been completed and a high level solution approach has been agreed. This means that the end dates for these milestones can only be estimated at this time.
Project Initiation Document for Project Cumulus
19
Assumptions
The assumptions made about the project are that:
The consortium members have appointed a Project Management Board to support the project and to ensure the delivery of the research project requirements
The consortium members will appoint a Project Manager from the project start date
The Project Cumulus Project Manager will be responsible for maintaining the Project Plan
The Project Cumulus Project Manager will ensure sufficient resources are made available to carry out the tasks identified for a successful implementation
UNIT4 will provide a Project Manager with effect from September 2010
UNIT4 will define their project team to ensure sufficient and consistent resources are available to carry out the tasks identified for a successful project solution to a suitable level to ensure the continuation of the research project.
Constraints
The constraints made on the project are that:
The project must be completed within the agreed budget.
Dependencies
The dependencies of the project are that:
A sufficient level of Project Cumulus resource is made available.
Issues and Risks
Project issues and Risks will be recorded in the project register. Issues and Risks should be reviewed and updated regularly throughout the project.
