HOUSES OF THE OIREACHTAS SERVICE

Transcription

1 February 2013 HOUSES OF THE OIREACHTAS SERVICE Guidelines on Project Management

2 Page 1 of 18

3 Quick Reference Key Principles of Project Management 1. Definition A project delivers something new that is distinct from the routine work of the Service. Projects are clearly defined and time-bound and have specific staff and financial resources assigned. 2. General Requirements Projects must be founded in and consistent with the Service s strategies, plans and policies and they must comply with the Service s and with public service standard guidelines, rules and procedures. All relevant expertise that is necessary to conduct a project should be availed of and training should be provided to equip personnel with appropriate skills and knowledge. Project Management training will be provided by the Service on request. No activity in the nature of a project should be undertaken without due regard to the Project Management Guidelines set out in Office Notice 1 of Governance Framework: Project Roles, Phases and Requirements Every project should have persons at appropriate levels assigned to the following roles: Approver (at the appropriate level as set out in Office Notice 1/2011 or any subsequent notice setting out the Service s financial authority procedures e.g. at MAC, Assistant Secretary level, Commission Finance Committee, Commission). Sponsor (e.g. Assistant Secretary, Clerk of the Seanad, PO reporting to MAC or to MAC Sub Committee). Project Board (chaired, depending on scale and/or impact, by an Assistant Secretary, the Clerk of the Seanad or PO/AP other than the sponsor). Project Manager (designated manager or line manager reporting to project board guides the project through the process. Either accomplishes the task or ensures others accomplish the task.) Project Team (staff delivering the project under direction of project manager). Project Stakeholders (users and other interested and potential parties, including all of the above). External Reviewer (where considered necessary by the approver). Every project goes through the following main project phases within its life cycle. See Appendix 1: Project Governance Framework Diagram. INITIATION --> PLANNING --> IMPLEMENTATION --> CONTROLLING -->CONCLUSION These phases should be applied rigorously in the case of large projects. In the case of medium projects all five project management phases should be implemented but with a reduced level of documentation and formality. In the case of small projects a three phase process (combining some of the phases) can be used. Specific Requirements A project must: Be consultative by creating an environment in which staff and stakeholders can contribute. Be approved on the basis of a clear and comprehensive Phase 1 and Phase 2 Business Case. Be recorded on the Service s Projects Register. Identify the benefits to be achieved and how they will be measured. Be described and documented in a formal project plan. Be subject to risk assessment and critical path analysis that are kept under review and recorded to the Service s Risks Register Database. Have governance structures with project roles assigned and project phases defined. Have any change in scope, budget, timeline formally recognised, signed off and communicated. Have proper project records of decisions, meetings and events available for review. Be subject to financial control and monitoring and reporting of progress in delivery. Provide for timely and appropriate internal and external reviews during and after. Be formally signed off and reported on completion to confirm its purpose is achieved. Be subject to a formal post-project assessment of benefits and outcomes realisation. Page 2 of 18

4 Checklist: Service Guidelines on Project Management Activity or Deliverable Yes Partly No Comment Project Initiation Consult (Finance Officer, ICT, Procurement, staff at all levels and other stakeholders, as applicable) Business Case Phase:1 Approval in Principle (Purpose, Strategic Fit, Timescale/Priority, Benefits, Impacts, Interdependencies, Risks, Budget, Resources). Office Notice 1/2011refers Business Case Phase:2 Approval to Proceed (MAC, Assistant Secretary, Commission, other. Office Notice 01/2011 refers. Project Planning Project Plan (Scope, Roles, Structures, Systems, Procedures, Timescales, Tolerance Levels, Deliverables, Risk Assessment, Critical Path Analysis, Communications ) Project Implementation Governance Controls (Governance: Roles, structures, systems, and procedures observed and maintained. Issues Management. Project Team meetings and Project Board meetings held) Review of Progress & Continued Validity (Milestones and Deliverables) (Formal Internal Review Meetings) Project Control Control (Change Control, Project Records, Project Code, Expenditure Control, Interim Review& Monitoring ) Project Conclusion/Closure Closure (Delivered, piloted if applicable, Sign-Off Procedures, Post Project Assessment, Closure Report, Benefits Realisation Assessment, close risks) Compliance, where applicable Service Procurement Policy, Government & EU Public Procurement Procedures requirements met. Service and Public Expenditure Standards Rules and Procedures followed. Audit and risk management requirements met. ICT and consultancy guidelines followed. Training & Specialist Expertise, if applicable Training (Training needs of project personnel, identified and met) Specialist Expertise (Specialist Expertise needs identified, sourced and provided) Page 3 of 18

5 1. Introduction These guidelines are for staff of the Houses of the Oireachtas Service who are involved in the management of projects. The guidelines include general requirements (section 2 below) and a governance framework (section 3 below) for managing projects. These Guidelines supersede Office Notice 04/2008. A quick-reference summary of key project management principles is provided at the beginning of these guidelines and a project governance framework diagram is provided at Appendix 1. Training in project management will be organised on request to supplement these guidelines. 1.1 Purpose of the Guidelines: The purpose of the guidelines is to provide a common-sense toolkit to enable staff to deliver the proper and efficient use of the resources of the Commission and to ensure that projects in the Service are undertaken and managed in accordance with applicable public service rules and policies and with generally accepted best practice. 1.2 Definition of a Project: A project is an activity that requires the allocation of a budget and/or dedicated staff resources for a clearly defined and approved purpose and that brings beneficial change or added value. A project is therefore something that is distinct from the routine work of the Service and that is: new - i.e. it delivers a new product, system, process or other outcome that directly furthers stated business objectives of the Service in an obvious and defined way; defined clearly - i.e. it is clear what exactly is to be achieved, what are the critical stages along the way, what will measure whether it is working or not, what the finished product will look like and what exactly the benefits expected from that product will be; time bound - i.e. it has specified start and finish dates - if a project doesn t finish by the planned date, this must be accounted for; resourced with a specific budget and/or staff, the amount of which should be estimated at the start and kept under constant review - if a project exceeds its budget there must be a clear and accepted justification for this. 2. General Requirements The following are the high level requirements to be observed in undertaking projects within the Service. 2.1 Strategic and Policy Fit Projects should contribute directly to the delivery of the strategic commitments of the Commission as set out in its Strategic Plan and they should be consistent with the policies and corporate business plans of the Houses of the Oireachtas Service. 2.2 Public Service Standard Rules & Procedures Regard should be had to the applicable requirements of the law and of regulations, guidelines and indicators of best practice in the public service, including those in respect of expenditure, audit and risk, procurement, value for money, ICT projects and Business Continuity Plans. Page 4 of 18

6 Many of the requirements regarding are set out in the Blue Book on Public Financial Procedures, and in the Service s Financial Governance Handbook (Nov 2011) and in Office Notice 1/2011. Staff must ensure that they fulfil the requirements that are set out in Office Notice 1/2011 when seeking approval/sanction for new items of expenditure. Any queries in relation to the exercise of financial authority should be address to the Service s Finance and Management Information Unit The Department of Public Expenditure & Reform s The Public Spending Code, Expenditure Planning, Appraisal & Evaluation in the Irish Public Service (July 2012) brings together in one place details of the obligations that those responsible for spending public money are obliged to adhere to, as well as guidance material on how to comply with the obligations outlined. Link: Elements of the Public Spending Code apply to any project that: may incur expenditure in the near future (Initiation, Planning); is currently incurring expenditure (Management, Monitoring, Evaluation); has incurred expenditure in the recent past (Review, Evaluation). Managers of projects must comply, as appropriate, with the relevant requirements of the Code. 2.3 Procurement Where projects involve the procurement of goods or services, including incidental or indirect procurements, Service policy and applicable Government and EU public procurement procedures should be implemented rigorously. Many of these are set out in the Procurement Guidance for Staff booklet issued by the Procurement Unit in November 2010 and in the Service s Financial Governance Handbook that are available in the Discussion Database. If there is any doubt as to the procedures to apply in a given situation, the Procurement Officer should be consulted. A submission must be sent to the Oireachtas Service Contracts Committee (OCC) where: A. it is proposed for exceptional reasons not to have a competitive process (where the contract value is in excess of 25,000 exclusive of VAT), B. only one tender was received in response to an advertisement or invitation to tender, or C. it is proposed not to accept the lowest priced tender (where the contract value is in excess of 65,000 exclusive of VAT). The OCC will examine and quality assure the tendering procedure used, based on the documentation provided, and ensure that as far as possible, it was carried out in an open, objective and transparent manner. Additional requirements for IT and telecommunications expenditure on projects in the public sector are set out in Department of Public Expenditure & Reform Circulars 2/09 and 2/11. Guidance regarding the Management of Risk are set out in the Department of Public Expenditure and Review (D/PER) Risk Management Guidance for Government Departments and Offices (2004). Page 5 of 18

7 2.4 Specialist Expertise Different types of expertise will typically be required at different stages of a project (e.g. procurement expertise; including RFT design expertise; legal advice on contracts; financial advice on budgeting and calculating cost benefits or technical advice). The sources of expertise and practical experience available both formally and informally in the Service in the areas of law, procurement, ICT, finance and project management should be availed of, accordingly. Where a project requires specialist expertise that is not available from within the Service, it should be sought in the wider public service or procured from outside. DPER s Public Spending Code (2012) and Guidelines for Engagement of Consultants and other External Support by the Civil Service (2006) sets out best practice principles and guidance on the engagement and management of external consultants in the Civil Service. Evidence of the basis for selection of expert advisers should be contained on file and full attendance by external advisers at Project Board meetings should be required. The time spent by external advisors at meetings should be documented for expenditure monitoring and control purposes. In addition, terms of engagement should be completed to set out the role and responsibilities of external advisers. This should be agreed at the start of the project and address matters including the requirement to attend meetings. 2.5 Training Training that sets out in more detail the specific requirements in areas such as project plans, methodologies and checklists for project sponsors, managers and approvers to ensure that projects in the Service are properly managed will be made available, on request, to those involved in projects. Project management training needs should be identified by staff in their annual PMDS Learning & Development Plans. Any additional training requirements for staff involved in individual projects should also be incorporated as necessary in project plans and provided, accordingly, as part of each project. 3. Governance Framework The MAC is the strategic oversight, advisory and co-ordinating management board of the Houses of the Oireachtas Service. The reviewing and deciding on proposals for projects, new policies or investments for the Service in accordance with the provisions of Office Notices 1/2011 and 1/2013 is a function of the MAC as set out in the MAC Charter (revised June 2011). The relevant sub-committee of MAC shall consider business cases for project proposals as are referred to it by the Secretary General/MAC. The following governance measures and structures are necessary to ensure that projects are well structured and managed in accordance with best practice and can thus lead to successful outcomes for the Service and the Commission. 3.1 Project Roles Every project should have persons at appropriate levels assigned to the following roles, identified in the business case for approval of the project and incorporated in the project plan: Approver (at the appropriate level as set out in Office Notice 1/2011 or any subsequent notice setting out the Service s financial authority procedures e.g. at Management Advisory Committee, Assistant Secretary level). Sponsor (e.g. Assistant Secretary, Clerk of the Seanad, PO reporting to MAC or to MAC Sub Committee). Page 6 of 18

8 Project Board (chaired, depending on scale, by an Assistant Secretary, the Clerk of the Seanad or PO/AP other than the sponsor). Project Manager (designated manager or line manager reporting to project board guides the project through the process. Either accomplishes the task or ensures others accomplish the task.) Project Team (staff delivering the project under direction of project manager). Project Stakeholders (users and other interested and potential parties, including all of the above). External Reviewer (where considered necessary by the approver). Each of the project roles has a purpose and no project should unfold without the roles being formally designated. Training will made available on request to equip staff with the knowledge and skills necessary to fulfil their project roles. Where appropriate, training for project personnel should also be incorporated within individual projects. Reporting of large projects should be at an appropriate level and should not involve an undue level of administrative burden for the Project Board and Project Manager. In the case of projects that are large in either value or significance to the Service, it is recommended that the Project Board should include a member at Senior Management level in the Oireachtas Service (i.e. above PO level for Project Management Guidelines purposes). The following factors should be considered together when determining the overall requirement of Senior Management membership above PO level on a Project Board. The project cost (Appendix B, New Items of Expenditure, Cir 1/2011 refers). The level of Service resources, including staff required. Is the project a capital project valued at above 0.5m? Is the project an ICT/ ICT dependent project valued at above 250,000? Is there a high risk assessment score attached to the project. The stakeholders impacted by the project (e.g. cross-functional business areas, Members, Commission, external, potential). The complexity of the project. 3.2 Project Phases Every project goes through five main phases within its life cycle. Each phase, together with the tasks and activities that are typically associated with it, is described briefly further below and illustrated in Appendix 1. Project Governance Framework Diagram. INITIATION --> PLANNING --> IMPLEMENTATION --> CONTROLLING -->CONCLUSION Projects can be classified based on their size and complexity so that small and straightforward projects are implemented using simple and straightforward processes. Larger and more complex projects will use the fully defined process. In short, the project framework should be tailored to cater for the size and complexity of the project. Large Projects Projects that are strategically important, large cost, high risk or long duration will need formal and rigorous processes to ensure success. For these projects, all of the elements of the Guidelines on Project Management should be implemented in full, including all five project phases. Page 7 of 18

9 Medium Projects Other projects that may be large in size, but with less strategic importance or a lower risk profile, then all five phases should be implemented, but with a reduced level of documentation and formality. A Project Board should be considered. Small Projects Projects with low risk, low cost and shorter durations will require a less formal and less rigorous approach. For small projects, the recommendation is to combine some of the phases so that a three phase process is used (i.e. Initiate Plan, Implement Control, Conclude) with a reduced set of project records and outputs. The Project Sponsor and Project Manager may function as the Project Board. INITIATION APPRAISAL BEFORE EXPENDITURE IS INCURRED The Service s business case appraisal process is a two phased process, with Phase 1 aiming to establish whether, at face value, a sufficient case exists for considering a proposal in more depth. It leads to a recommendation on whether or not to proceed to the detailed appraisal stage, which can often be a costly exercise. Sanction/Approval requirements for new items of expenditure should be strictly adhered to. The Service Financial Governance Handbook, Office Notice 1/2011 and the D/PER Public Spending Code (2012) currently refer. Business Case: Phase 1 Request for Approval in Principle The Phase 1 Business Case submitted for approval should contain a full and clear definition of the resource commitments, including staff resources, for all projects. Staffing and other current costs arising must be consistent with the Service s policy on staffing and be consistent with the staffing levels approved in the Annual Resource Plan for the Service. The Business Case Proposal must outline cross-directorate relationships and inter-dependencies that may affect the project. The impact of the project on the work, processes and outcomes of other business areas must be discussed and any issues resolved with the relevant individuals and sections. The project management team should create an environment in which staff at all levels and other stakeholders who have experience, skills and knowledge of the project area can contribute appropriately to the project development. The ICT Unit must be consulted before putting forward a business case that involves any ICT dependency or that may impact on the Service s Business Continuity Plan, however incidental. The Business Continuity Plan for the relevant Sections should be amended to reflect any changes necessary as a result of the project s implementation. The Section Head(s) responsible should be notified of the amendments made. Where goods or services are to be purchased, the business case should also set out a procurement strategy for the project. Refer to: Procurement Guidance for Oireachtas Staff (Nov 2010); Public Procurement Guidelines ICT Procurement Frameworks ictprocurement.gov.ie for guidance. It is not envisaged that a Phase 1 approval would be valid for more than six months, unless there is a bona fide reason for the delay. Page 8 of 18

10 Business Case Phase 2: Request for Approval to Proceed with Project The detailed Phase 2 Business Case appraisal aims to provide a basis for decision on whether or not to give sanction to proceed with the project. It includes the clarification of the objectives, risks, impacts, exploration of options and quantification of costs and benefits. Cost Benefit Analysis: The costs of a project versus the expected benefits to be realised (and how they will be measured) should be set out in the business case. Where savings or increased outputs or efficiencies are expected to result, these should be quantified with reference to current costs/outputs etc. Sponsors and approvers should review with caution any project proposals where the benefits to be realised cannot be clearly identified. In particular, projects involving both significant innovation and a significant degree of risk should be subject to additional and rigorous monitoring and control throughout. Budget and Financial Authority: Projects should be undertaken in accordance with the applicable authorisation limits and rules in respect of official expenditure (currently Service s Finance Governance Handbook (Sept 2011), Office Notice 1/2011 and D/PER Public Spending Code (2012) currently refer). The budget should, for this purpose, include the full cost of all resources, including staff. The fact that a budget allocation may exist for a particular project in any given year does not mean that there is authority to commence the project without a business case and formal financial approval. All new approved projects should be reported to the OCSG by to declan.bale@oir.ie to be recorded to the Service s Register of Projects. Any potential impact of projects on the Service s Business Continuity Plan should be communicated immediately to the relevant person in charge of the Plan. PLANNING Project Plan: Every project, however small, should be governed by a project plan agreed by the Project Board or its equivalent and setting out the scope, roles, structures, systems, procedures, stages, timescales and deliverables of the project. The project plan should reflect the rationale as set out at the initiation stage (purpose, benefits, budget, resources), it should clearly convey what the project is for and identify its boundaries in terms of what it will and will not cover. The project plan should also include a communications plan and specify project tolerance levels, if any. A critical path analysis and a risk assessment should also be included. Communications Plan: The management of expectations amongst stakeholders and potential stakeholders is a key role of the Project Manager. Regular and open communication is essential where the project will impact on roles, responsibilities and/or work practices. The Project Plan should include a communications plan that includes a list of proposed communication activities associated with events and stakeholders, including the sponsor, project board, project team, ICT and external consultants as required. Forms of communication could include presentations to staff or members, ed newsletters, the development of a project website/shared documentation database etc. Budget, Scope and Time Tolerance Levels: Project tolerances, if granted, define the range within which the Project Manager can make decisions regarding the project plan s budget, scope and timelines without the Project Manager having to get approval from (or consult with) the Project Sponsor or Project Board. By defining tolerances, the Project Manager has the scope to make timely decisions regarding small deviations to the project plan and has clear criteria to make decisions on when it is necessary to submit changes to the Project Board for approval. Cost tolerance amounts should not be regarded by Project Managers as a blank cheque. Expenditure based on cost tolerance Page 9 of 18

11 amounts should comply with normal financial and procurement procedures including the sanction/approval requirements for new items of expenditure (Office Notice 1/2011 refers). Critical Path Analysis: This involves identifying time-critical tasks during implementation of the project, i.e. what must happen and by when for the project to remain on target. These are the tasks that, if delayed, will delay the entire project. It is, therefore, essential that this critical path, or schedule of project milestones and their expected achievement dates, be set out from the start in a formal (though simple) way in the project plan, approved by the Project Board or its equivalent and reviewed and updated regularly as the project unfolds. Without this, it will not be possible for those involved in a project to recognise whether or not it is achieving its milestone targets on time and is on track for completion. Risk Assessment: Risks are the things that can go wrong in projects. All projects involve some level of risk and failure to deal adequately with risks can have serious consequences, leading ultimately to project failure. The Houses of the Oireachtas Service s Risk Management Policy (Managing for Results) (Dec 2011) and the Department of Public Expenditure and Review (D/PER) Risk Management Guidance for Government Departments and Offices (2004) should be consulted when putting project risk management mechanism in place. Identified project risks should feed into the Service s business areas and organisation-wide risk management structures e.g. sections risk action plans, risk register database, risk materialisation reports. The overall feasibility of the project strategy should be tested in order to mitigate the risk of failure. In this regard, the importance of comprehensive pilot testing should not be overlooked. Obvious risks include cost overruns, purpose becoming unachievable or benefits unrealisable, delays and unforeseen (e.g. industrial relations or legal) difficulties. Other less obvious or projectspecific risks will need to be assessed in each case. Consideration of fraud risks should be part of any new project or service initiative. Identification of fraud risks and fraud prevention and detection measures and appropriate controls should be considered as a standard requirement. The key to dealing with risks is to anticipate them as far as possible and, when they arise, to address them in such a way as to minimise their effect on the progress and outcome of the project. To achieve this, risks need to be: identified and classified (what can go wrong Strategic, Environmental, Operational, Financial, Reputational, Procedural Core Business, Security, Legislative, other e.g. legal, risks); assessed (in terms of likelihood and significance); mitigate (accept, reduce, avoid, transfer); monitoring (constant monitoring and reassessed during lifetime of project) reporting: (report any perceived risks and failures of controls promptly including on risk register and risk materialisation reports. Any emerging new risk should never be ignored or denied - it should be declared by the Project Manager and dealt with up front even if this requires suspending the project while the problem is being investigated. Identified risks should be entered onto the Service s Risk Register Database. Page 10 of 18

12 Project Management Techniques: Training will be organised, on request, to staff involved in projects in the use of appropriate tools and methodologies, including IT software products, for planning and managing projects, for assessing risks and for carrying out critical path analysis. ICT Unit has a limited number of project management software licences that give access to project management tools, tables, templates and methodologies. These will be issued to project managers following confirmation of the requirement by a PO or Section Head with an indication of how long the licence will be required. IMPLEMENTATION Governance: Project managers and boards should ensure that the roles, structures, systems and procedures set out in the project plan are maintained during the project. Regular formal reviews should be provided and held to assess how the project is progressing against its original objectives, whether the purpose and/or project plan need to be revised and whether any remedial actions, including reconsideration of the viability of the project, are necessary. Issue Management: The Project Manager should define how issues will be managed and escalated during the project and ensure that the project team and board understand what the ground rules are. In general, the project team should know to advise the Project Manager of issues as soon as they arise do not wait for the next formal meeting. Issues must be resolved quickly and effectively. Project Managers should enter the issue into an issues log; determine who needs to be involved in its resolution; identify any potential costs; decide on action to be taken; track resolution of action points and communicate status to relevant personnel through methods established in the project s communication plan. CONTROLLING Change Control: Project Managers, Project Sponsors and Project Boards should maintain constant vigilance to ensure that, where there is any change, outside of specified tolerance levels, in the scope, cost or duration of a project, this is done by a formal change to the project plan that is signed off by the Project Board and the Project Approver before proceeding with the change. This is necessary to avoid drift in the scope, cost and duration of projects. Changes to the project scope, budget or duration should be managed by way of an exception report submitted by the Project Manager to the Project Board. Exception reports should inform the Project Board of the situation, and offer options and recommendations on the way to proceed. The exception report should include an assessment of the impact of the change on the approved business case, including costs. Exception reports must be resolved quickly and effectively and the decision to accept or reject the change resulting from the exception report should be communicated immediately to the appropriate personnel (e.g. Project Manager and Team, ICT/ Business Continuity Plan, external consultant, affected business areas, Finance Unit, MAC/subcommittee, Commission, as appropriate). To ensure that changes are monitored through to completion, a Change Log should be maintained by the Project Manager. This allows the Project Manager to identify any outstanding changes and to measure the actual impact of each change once implemented. It also ensures that a history of all changes is available later in the project. Page 11 of 18

13 If the change adopted affects any existing risk recorded or creates a new risk, this should be reflected on the Risk Register Database and if relevant, notified to the owner of the Business Continuity Plan. Project Records: An internal or external auditor or any senior manager accountable for a project will always be entitled to look for project records which should, therefore, be kept to a high standard in anticipation of such requests. A proper paper trail should, therefore, be kept for audit/accountability purposes as per Office Notice 1/2011. This means that immediately available and organised records should be maintained at all times covering the entire project history, including approval, planning, procurement, budget and expenditure control, minutes of project board meetings and all decisions made and significant events, including appropriate references to detailed information, occurring at Project Board, Project Manager and Project Team level. Project files should contain signed copies of Project Board minutes. Appropriate resources and training should be made available to ensure the maintenance of high standard project records. Control of Expenditure: Project Managers should forward the confirmation of the approval of the project business case expenditure (Office Notice 1/2011 currently refers) and details of the master budget, from which the project budget is being drawn, to the Finance Unit. The Finance Unit will record the approved budget in Integra, allocate a project code to the project and notify the Project Manager of the project code. It is the responsibility of the Project Manager to ensure the full and proper use of this coding by all involved. The Integra system will record a running total of the project budget spend and balance. The Project Manager should notify the Finance Unit of any cuts or additional costs approved by the Project Board. If the costs fall below or above budget tolerance levels, then the Project Manager should immediately inform the Project Board and Sponsor and other relevant stakeholders (e.g. Finance Unit, Assistant Secretary). Where budget tolerances are exceeded, the project should be referred to the appropriate management authority for further funding approval and review. The Project Manager should notify the Finance Unit when the final project payment is made. Interim Reviews and Monitoring of Progress: Project plans should include provision for effective and continuous reporting and monitoring within the project and, where appropriate, for independent external peer review. The Peer Review Process is a central initiative following a Government decision in The process is applied to major ICT projects in the public sector. Peer reviews provide assurance that a project can progress successfully to the next stage. Reviews are carried out at key decision points of a project. While it is unlikely that the Service will be engaged in many projects large enough to require such external review, peer review within the Service should be considered and implemented as a measure of best practice for large projects. Clear guidance in relation to peer review, templates and checklists are available on the Peer Review Process in the Public Sector website Regular reports should be submitted to the Project Board or its equivalent to ensure that project milestones are being met and expenditure is within budget. If adverse developments occur, such as cost overruns or delays, the progress reports should include recommendations to address the situation, including where warranted, the option of project termination. Page 12 of 18

14 CONCLUSION/ PROJECT CLOSURE Project Delivery: The Project Manager should ensure that all of the items in the Project Scope are successfully delivered at the end of the project. Pilot Project: Where appropriate, the project should undergo a period of testing of the new processes, systems or programme before they are put to productive use. The purpose of a pilot project is to test whether the system is working as it was designed while limiting business exposure. All projects that involve data processing (this may also apply to other areas) should be tested in a non-live environment (i.e. they should not interface with live systems). Pre-live testing should include personnel not involved in development Such tests should be carefully planned and results documented for review before going live to assure that the new system is robust. Sign-off Procedures: To ensure that projects are completed in a proper and formal manner, the end of each project must be formally signalled by a signing-off by the Sponsor to the effect that the completed project addresses the business need identified in the Business Case and that the project was delivered to the required specification, within budget and on time. The OCSG should be notified of the project closure to be record in the Projects Register. Post-Project Evaluation and Benefits Realisation: Within an appropriate period following completion of a project, a closure report should be prepared and submitted to the Sponsor setting out the extent to which the project has achieved its intended outcomes and whether the predicted benefits have been realised. Where realisation of these outcomes and benefits is expected to take a further period, a method and reporting system for assessing them in the future should be implemented. Risk Assessment: Risks that are no longer relevant should be terminated on the Risk Register. 4. Guidance and Reference Material Houses of the Oireachtas Service Policies and Guidelines, available in the Discussion Database under Project Management: Project Management Guidelines (updated Feb 2013) Project management Toolkit ( Feb 2013) Risk Management Policy Management of Results (Dec 2011) Financial Governance Handbook (Nov 2011) Office Notice 1/2011: Exercise of Financial Authority and the Placement of Orders for Goods and Services Procurement Guidance for Staff booklet (Nov 2010) ICT Unit: Project Managers access to project management software licences following confirmation of the requirement and indication of how long licence will be required. Public Service Policies and Guidelines and links Guidelines for Engagement of Consultants and other External Support by the Civil Service (2006). Page 13 of 18

15 Public Procurement Guidelines S.I. No.329 of 2006 European Communities (Award of Public Authorities' Contracts) Regulations. ICT Procurement Frameworks ictprocurement.gov.ie Peer Review in the Public Service. Risk Management Guidance for Government Departments and Offices (2004). Public Spending Code (July 2012). Public service ICT and egovernment Comptroller & Auditor General. Appendix 2: Summary of Conclusions of the Comptroller and Auditor General Report on PPARS. Appendix 3: Summary of Requirements for Management, Monitoring and Evaluation of egovernment Projects from the 2007 Report 1 of the Comptroller and Auditor General. Chapters from the 2010 Annual Report of the C&AG (Volume 2- Vote Management) Chapter 19 - Central Statistics Office - Data Management System Chapter 21 - Justice and Law Reform and Garda Síochána Fingerprint Systems Link: Other Article on Project Management by Ken Garrett ACCA. ACCA website. 1 Comptroller and Auditor General, Report on egovernment, Special Report 58, January 2008 Page 14 of 18

16 Appendix 1: Project Governance Framework Diagram Page 15 of 18

17 Appendix 2: Summary of Conclusions of the C&AG Report on PPARS 2 Vision and Goals: Business transformation projects demand a clear and consistent articulation of vision and goals; a full understanding of the cultural, organisational, process and technical changes required to support that vision; and a coherent but adaptable plan to effect those changes in practice at every level of the organisation. ICT alone cannot transform business processes. It is but one element in what must be a broadly-based approach to business change. The ICT solution selected should be appropriate to the needs being addressed and its requirements fully factored into the implementation plan. Cost Benefit Analysis: The cost benefit analysis must identify costs on as wide a basis as possible, be maintained and reassessed on an ongoing basis and set out targets and plans to achieve those benefits. User involvement: Users of a proposed system must be centrally involved at all stages of the project and additional resources must be provided to allow them to be so involved. Feasibility testing and piloting: The overall feasibility of the project strategy should be tested in order to mitigate the risk of failure. In this regard, the importance of comprehensive pilot testing should not be overlooked. Governance: Projects must not proceed without clearly defined lines of authority, responsibility and accountability and a means of ensuring they are observed in practice. Risk Management: A Risk Management process should form an integral part of projects at all stages and a process to mitigate and manage all risks identified should be put in place. Reviews: Gateway reviews (reviews at each major stage in a project cycle) need to be built into the approval process for major ICT projects and should be independent of the project team. Multiple Agency involvement: Where multiple agencies are involved, there must be clear buy-in based on an agreed project charter, resourcing agreements, governance protocols and budgets. Technical Management: Technical Management should rest with the party best equipped to handle it and there should be clear contractual terms to enforce this. Commissioning: Commissioning protocols should be in place. Expertise: Industry-best ICT and project management expertise should be developed within the public sector. Consultants: Contracts should be based either on defined specifications or managed in a way that focuses on milestones, deadlines and deliverables. High value contracts with consultants on large IT projects should incorporate provisions whereby each party shares the rewards and the risks. All agreements entered into should be subjected to regular, independent performance review. Such review should engage with all stakeholders in the project, including users. Funding: Effective accountability for results is more likely to be achieved through the use of a high level budget holder with regular financial reporting responsibilities. 2 Comptroller and Auditor General, Report on Value for Money Examination, Health Service Executive Development of Human Resource Management System for the Health Service (PPARS), December 2005 Page 16 of 18

18 Appendix 3: Summary of Requirements for Management, Monitoring and Evaluation of egovernment Projects from the 2007 Report 3 of the Comptroller and Auditor General For each major egovernment project, whether within an individual department/agency or across a number of departments/agencies, the following elements are required to support the achievement of effective process transformation. A current performance baseline against which results can be measured Target business benefits defined in measurable terms i.e. measurable change in service, efficiency, or effectiveness Formal assessment of the project risks An organisation appropriate to, and capable of, executing the process, drawn from the managers of the process itself, supported as required by expertise from other departments or from external sources An adequate budget for the full scope of the strategy Supporting methods, training, staffing and systems An appropriate change management programme An appropriate programme management control structure Management and governance structures that are effective and empowered Development methodologies which are appropriate to the project for instance, modular, incremental, agile development approaches may be more appropriate for complex innovative projects than the traditional, sequential software development model (the waterfall approach) Regular specific reporting on progress against measurable targets and budgets Regular review of business case targets Post-implementation review for all projects or programmes with benefits realised assessed against projected benefits and the costs incurred. 3 Comptroller and Auditor General, Report on egovernment, Special Report 58, January 2008 Page 17 of 18