ITD Project Management and System Development Procedure ITD PROJECT MANAGEMENT AND SYSTEM DEVELOPMENT PROCEDURE

Transcription

1 PURPOSE ITD PROJECT MANAGEMENT AND SYSTEM DEVELOPMENT PROCEDURE 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 ) 2. Project Proposal Circulation (Code 16 & auto to Mgt Team) 3. Project Approval (Code 46 auto ) 4. Project Analysis and Planning (Code 47 & RMS Notes) 5. Project Implementation (Code 48 & RMS Notes + auto requesting project plans to be forwarded to Section Head / Manager) 6. Verification and Validation (Code 86 - Auto ) 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: &FolderCTID=0x C541FC65BE642BA1D0AE59D05C63A&View={7D92FEC8-5B41-4C F8B776DE22F} 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. Page 1 of 6 Rev: 22

2 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- to the Section Head / Manager. Upon receipt of the , the Section Head / Manager will change the status to 16, which will generate an 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 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: Page 2 of 6 Rev: 22

3 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 the Notes 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 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 The Section Head / Manager closes the call at 99, when: Page 3 of 6 Rev: 22

4 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. Page 4 of 6 Rev: 22

5 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 Apr 05 Martin Leonard More detailed record keeping. Removed references to development Better clarification on closure May 05 Martin Leonard Clarified ISO requirements, added references to the Database June 05 Martin Leonard Simplified procedure for small projects. Added detail for rejected/cancelled projects Clarified the data to be recorded in the database June 05 Martin Leonard Improved wording for clarity following suggestions from ITD staff 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 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 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 Jul 08 Kim O Mahony Updated to include reference to project overview by Mgt team. Also some typographical changes following recent audit 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 Page 5 of 6 Rev: 22

6 14 6 July 09 Management Team were recommendations made during the NSAI audit in Sept. Updated procedure following recommendations from internal audit on 28 may. 1) Made reference to projects being handed over to other Divisions; 2) Included auto at code 48 for copy of project plan to be sent to Section Head / Mgt for approval at next project board meeting (pg 3) May 10 Kim O Mahony Projects now reviewed at the monthly quality meeting instead of the management operational weekly meeting. Noted this on Page Nov 10 Kim O Mahony Clarified under Project Approval Stage that the project proposal has been approved to move to the planning stage (p2) 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 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 Jan 12 Kim O Mahony Updated procedure to outline current practice for project reviews Oct 12 Kim O Mahony Replaced Quality Officer with Section Head / Manager Jul 13 George Hayes Two procedural changes: 1. All project documentation is stored in RMS 2. Project review meetings are conducted monthly Page 6 of 6 Rev: 22