ITD PROJECT MANAGEMENT AND SYSTEM DEVELOPMENT PROCEDURE PURPOSE
ITD’s core business is to implement IT solutions. The purpose of this procedure is to facilitate the identification, management and monitoring of IT projects through their life cycles. Most projects do not require an explicit design phase as it is University policy to implement existing commercial solutions rather than developing bespoke in-house solutions.
PROCEDURE
RMS is used as a central repository for all projects. The process for implementing IT solutions consists of six stages:
1. Project Proposal (Code 6 + Checklist & auto email)
2. Project Proposal Circulation (Code 16 & auto email to Mgt Team) 3. Project Approval (Code 46 – auto email)
4. Project Analysis and Planning (Code 47 & RMS Notes)
5. Project Implementation (Code 48 & RMS Notes + auto email requesting project plans to be forwarded to Section Head / Manager)
6. Verification and Validation (Code 86 - Auto email) 7. Project Completion (Code 99)
Additional Code: Project ‘On Hold’ (Code 49) (see Exception Conditions)
Progression of an ITD project is the responsibility of the assigned project leader. New project proposals are reviewed weekly at the management meeting. Project plans are reviewed at section meetings. A review of all projects takes place fortnightly between the Director and section Head. Project reports are stored on SharePoint:
https://sharepoint.ul.ie/SiteDirectory/ITDManagement/Quality/Shared%20Documents/Forms/AllItems.aspx ?RootFolder=%2FSiteDirectory%2FITDManagement%2FQuality%2FShared%20Documents%2FProjects &FolderCTID=0x012000500C541FC65BE642BA1D0AE59D05C63A&View={7D92FEC8-5B41-4C39-8248-6F8B776DE22F}
Inputs:
Requests are generated by:
1. The University to implement strategic objectives/new initiatives. 2. ITD staff, following consultation with customers to:
a. Deploy IT infrastructure/services b. Develop and Deploy new services c. Enhance current processes
d. Trend analysis, Preventative or Corrective Action e. Follow-on from Change Control Requests.
Project Proposal Stage
All project requests are logged in RMS. The Call Type is ‘PRO’, and the Application is ‘PRO’. This generates a checklist of proposal questions, which is saved with the call. The status code changes to ‘6’. This generates an auto-email to the Section Head / Manager. Upon receipt of the email, the Section Head / Manager will change the status to 16, which will generate an email to the Management Team outlining details of the project proposal. The management team evaluates project proposals weekly at the ITD management meeting.
Based on the business need and availability of resources, projects are either accepted or rejected. Projects are classified as:
Size Duration SLA
1. Small 3 months SML 2. Medium 6 months MED 3. Large 1 year LGE
The size of the project is recorded using the SLA field in RMS.
Project Approval Stage (Stop / Go #1)
If accepted, a project leader is assigned to the project. The Section Head / Manager updates the status after the operational meeting. The project leader then becomes the call owner in RMS. The status code changes to 46. This generates an email to the requestor, and a copy is sent to the project leader, stating that the project proposal has been approved and can now move to the planning phase.
If the proposal is rejected, the person who proposed the project is informed and the reason for rejection is given. A record of this communication is kept in the Notes field of the call. The status code changes to 90. In the event that a project is being handed over to another Division, relevant notes will be recorded and the project will be closed at code 90.
Project Analysis and Planning Stage
Once work begins on the planning stage, the status code is changed to 47. It is recommended that any additional documentation relating to projects be stored as document links to the project call in RMS.
It is the responsibility of the project leader to determine the project requirements.
These requirements should be arrived at after reviewing any available customer inputs. The customer requirements and inputs may have to be interpreted from trend data, customer surveys, customer meetings or interviews on specific projects as required. The project leader determines how to achieve this at the start of the project. The projects requirements should include as a minimum:
1. Functional and performance requirements
2. Applicable statutory and regulatory requirements
3. Applicable information derived from previous similar designs 4. Any other requirements essential for design and development The project leader produces a project plan, which must indicate:
1. Resources required
a. In particular human resource required ‘the project team’
2. Project Milestones consisting of:
a. When milestone activity is scheduled to begin b. How long it should take to complete
c. When a review is planned
Project plans and milestones are discussed at section team meetings.
(Stop / Go #2)
Small projects proceed to implementation once the project leader has prepared the
project plan and populated theNotes field in RMS appropriately. Medium and Large projects are reviewed fortnightly with the Director and Section Head. Project reports are stored on SharePoint.
Project Implementation Stage
At this stage of the procedure, the status code in RMS changes to 48.
Support structures (for example, Project Board, Steering Committee) are put in place as appropriate and recorded in the notes field of the project call in RMS.
(Stop / Go #3)
Project milestones are recorded in the notes field in RMS. Although achieving a
milestone may be the responsibility of other team members, the overall responsibility for the project management and progression of milestones rests with the project leader. The project leader monitors the project plan and provides status reports at individual section meetings. Project delays, cancellations or accelerations are recorded in the RMS notes field.
Verification and Validation Stage
Once work has been complete on the project, and before the final closure, the project leader sets the status code to 86. This code generates an automatic email to the Section Head / Manager. The Section Head / Manager verifies that the results of the project meet the requirements and validates the final product/service meets the customer needs.
Closure Stage
1. The project outputs have been verified.
2. The customers have formally accepted all outcomes (validated). 3. Documentation and reference material is in place.
4. Operational procedures are in place.
5. The training and handover to operational staff has been completed. 6. The stakeholders are notified of the project outcome.
7. Any further actions and recommendations are documented and disseminated. 8. The project has been reviewed.
a. Small projects are reviewed with the head of section of the project leader.
b. Medium projects are reviewed by ITD Management team c. Large projects may be externally audited
All project documentation is held in RMS.
A periodic overview of all projects is conducted by the Management Team. EXCEPTION CONDITIONS
Non-ITD Projects
UL-managed projects that require ITD resources will be logged in RMS at Code 6 – project proposal. Once the project has been approved at the weekly operational meeting, it does not go through the complete ITD project life-cycle, but progress / updates are recorded in the Notes field in RMS.
On-Hold Projects
Projects are put on-hold by changing priorities and/or resourcing. The Section Head / Manager changes the status code to 49 (Project On-Hold) and updates the notes field with the reason for stoppage. Code 49 will stop the clock against the SLA in RMS. When work resumes on the project, the status code is changed back to the pre ‘on-hold’ status.
RECORDS
Records are maintained in RMS for a minimum of 3 years. Project reports are stored on SharePoint. All other project records are stored in a projects network folder and are maintained for a minimum of 3 Years.
It is the responsibility of the project leader to manage changes to the projects network folder. This may be facilitated by imposing access restrictions to the projects network folder or specific files within the projects network folder.
PROCESS VERIFICATION
Evaluation of process effectiveness is carried out using Internal / External Quality Audits and the Corrective Action process where the procedure itself is found to be the source of the problem under investigation. Particular attention is paid to any feedback on the results of the project from the user community via RMS or direct contact through management.
Project review meetings are conducted monthly. Review records, along with relevant minutes, are stored on SharePoint.
Revision No. Date Approved by: Details of Change
1 Feb ‘05 Mgt Team Initial Release
2 18 Apr ‘05 Martin Leonard Updated procedure as a result of internal audit
3 25 Apr ‘05 Martin Leonard Added info re templates, corrected
‘database’ references.
4 28 Apr 05 Martin Leonard More detailed record keeping.
Removed references to ‘development’ Better clarification on closure.
5 31 May 05 Martin Leonard Clarified ISO requirements, added
references to the Database.
6 22 June 05 Martin Leonard Simplified procedure for small projects. Added detail for rejected/cancelled projects Clarified the data to be recorded in the database.
7 22 June 05 Martin Leonard Improved wording for clarity following
suggestions from ITD staff.
8 24 June 05 Kim O’Mahony Updated title and headings for consistency
9 12 Sept 06 Kim O’Mahony Procedure revised to use RMS for project
management instead of Martin’s customised database.
10 9 May ‘07 Kim O’Mahony Page 2 (Project Analysis and Planning
Stage) updated to include the ITD Management link on the portal for additional project documentation.
11 11 May ‘07 Kim O’Mahony /
George Hayes
Updated procedure to change tense of the grammar. Also identified the three Stop / Go phases of the project life cycle.
12 3 Jul ‘08 Kim O’Mahony Updated to include reference to project
overview by Mgt team. Also some typographical changes following recent audit.
13 22 Oct ‘08 Kim O’Mahony /
George Hayes
Updated ‘Procedure’ section on page 1 to outline macro-level project reviews and details of the monthly project meeting. Included the section ‘Exception Conditions’ to refer to UL-managed projects and also ‘On-Hold’ projects. These
were recommendations made during the NSAI audit in Sept.
14 6 July ’09 Management
Team
Updated procedure following
recommendations from internal audit on 28 may. 1) Made reference to projects being handed over to other Divisions; 2) Included auto email at code 48 for copy of project plan to be sent to Section Head / Mgt for approval at next project board meeting (pg 3)
15 10 May ‘10 Kim O’Mahony Projects now reviewed at the monthly
quality meeting instead of the management operational weekly meeting. Noted this on Page 1.
16 3 Nov ‘10 Kim O’Mahony Clarified under ‘Project Approval Stage’
that the project proposal has been approved to move to the planning stage (p2)
17 24 Jan ‘11 Kim O’Mahony Implemented new phase in the procedure
(Code 16 – Project Proposal Circulation) which allows the Mgt Team to view project proposals prior to discussion at the weekly meeting. (See minutes of weekly meeting 24 Jan ’11)
18 5 Apr ‘11 Kim O’Mahony Updated procedure to outline current
practice for approving project proposals and project plans.
19 31 May ‘11 Kim O’Mahony Removed reference to project folders on
Clio and SharePoint. All project
documentation to be stored as linked files to the project call. Also included
SharePoint link to project reports
20 18 Jan ‘12 Kim O’Mahony Updated procedure to outline current
practice for project reviews.
21 2 Oct ‘12 Kim O’Mahony Replaced ‘Quality Officer’ with ‘Section
Head / Manager’.
22 1 Jul ‘13 George Hayes Two procedural changes:
1. All project documentation is stored in RMS
2. Project review meetings are conducted monthly
