CiCS Development Portfolio Definition 2015 Background 1 Context CiCS Vision We will be an innovative and influential department, respected by the University and recognised as a leader in the sector, delivering excellent customer-focused services. CiCS Strategies CiCS Service Strategy Board site 2 Background CiCS introduced formal Project Management in 2001, which helped us manage projects much more effectively, with better involvement from users, much clearer scoping and planning, and better handover to the services side. We brought in formal Programme Management of our portfolio of projects in 2004, following a formal review of our systems. Programme Management helped us to better co-ordinate projects and resources, to prioritise projects and deliver benefits more effectively, and to improve reporting and analysis of the department s project-based activities. In 2010 we moved to a Portfolio Management approach, which encompasses much of Programme Management but brings together our full development activity, including the smaller developments which are not formal projects, and puts it in the context of service delivery. This also fits well with CiCS shift from 2011 to a more structured approach to Service Management based on ITIL principles. Methodologies Our Project Management methodology is based on an Agile interpretation of PRINCE2. PRINCE2 is the industry-standard method controlled by the OGC (Office of Government Commerce). It requires us to have a clear definition of what each project is about, transparent governance which includes all key stakeholders, effective planning and management of project work and of changes, and controlled handover and closure at the end of each project. Agile PM (or DSDM) is the nearest thing there is to a standard approach to Agile project management. This takes advantage of the dynamism, flexibility and collaboration of Agile development whilst operating within a structure which has firm scheduling and resource controls and enough design up front to operate in a large organisation with various and conflicting demands. Our Portfolio Management approach is also based on the relevant OGC methodology, MoP (Management of Portfolios). The previous Programme Management approach, on which this is based, was also based on the relevant OGC methodology, MSP (Managing Successful Programmes). These focus on the strategic approach and planning of developments within the whole business context, including full lifecycle benefits management and strategic risk management. Service Management within CiCS is based on the industry standard ITIL principles. This particularly bears on developments in terms of identifying the need for a project to create a new or changed service, and later when the project/development transitions to a live service. The Service Manager for the relevant area will normally be on the Project Board to ensure the new/changed service fits the needs of the University, and to help with a successful handover when it goes live. The handover processes have been developed in conjunction with the Change and Release Process Manager to support the transition. CiCS Development Portfolio Background: Page 1 of 5
Business Process Review has become more important in projects and more generally. Often the first and most important part of a project is looking at how our organisational processes can be more effective, with new IT systems (if needed at all) supporting and enabling this rather than driving it. We have organised basic training in Business Process Review for staff in CiCS and other departments. The University s Process Improvement Unit is based in CiCS. It works with departments to examine and improve particular areas of work, including the use of Rapid Improvement Events. This work may well of course spin off projects to organise the implementation of the identified changes. CiCS Development Portfolio Management: Main Features Service Strategy Board: Made up of the CiCS Executive plus the seven Service Managers plus the Portfolio Manager. Service Advisory Groups: For most of the service areas. Made up of key stakeholders with the Service Manager as secretary. Programme and Project Unit: Project support, portfolio and programme management, management of key projects. A number of other staff also manage projects, with support from the PPU. Development Portfolio Definition: A compendium document of which this is a part. Some sections are frequently updated, such as the Portfolio of Projects, whilst others are reviewed annually. Portfolio of Projects: Details all projects and their main phases and inter-project dependencies. A Gantt-style chart aids planning and analysis. Benefits: Projects deliver capabilities but Portfolio Management is concerned more with the benefits that are reaped from these. Projects have their benefits for the University (and disbenefits) clearly identified at start-up and beyond, and the Closure Documents indicate ongoing responsibility for these. Most benefits are reaped long after project closure, and the Service Advisory Groups are key in ensuring that new and existing systems are well used. Resource Planning: CiCS works in a rapidly changing and dynamic environment and the conflicts between regular business as usual work and project work can make longer-term resource planning problematic. The Service Strategy Board tries to keep an effective balance of resource across projects and between projects and services. Ongoing overview of projects/developments: The Service Strategy Board meets monthly. One area of its work is to take highlight reports from each project and each service area and deal with issues raised there. The Service Strategy Board also commissions new projects and oversees the closure of projects and handover of services. Lessons Learned: Each project has a Lessons Learned Review after closure, and the positive and negative lessons feed into the Project Management methodology. Other Programmes The CiCS Services Strategy is guided by the broader University strategies, and there is considerable interaction between the CiCS Development Portfolio and programmes of work in other departments and faculties, for instance the Estates programme. The Service Strategy Board is responsible for ensuring this works well. CiCS Development Portfolio Background: Page 2 of 5
3 Management Strategies 3.1 Benefits Management Strategy 3.1.1 Methodology A key advantage of the Agile Project Management Approach is that the whole project is driven by a Prioritised Requirements List that is made up of user stories indicating what real-world improvements are wanted (rather than traditional system-based requirements). Thus the business/user needs are an integral part of the whole project throughout its lifecycle. In addition to this projects all identify their expected benefits explicitly, and ownership of these at the end is assigned in the project closure document. There is a Benefits Realisation Toolkit for Project Managers, and practical assistance from the PPU in project start-up meetings focuses on expected benefits. At a more strategic level the Service Advisory Groups are expected to have benefits realisation as a key aspect of their work. The Application Groups which preceded the Service Advisory Groups did some work here, and the Service Advisory Group for Communication and Collaboration has been very strongly benefits led from its previous incarnation as the UCI Programme. 3.1.2 Benefits Realisation Responsibility for the realisation of the benefits varies according to the type of development/project. a. Where projects re-engineer or improve business processes the relevant department is responsible for realising the benefits, and minimising dis-benefits. They will take a leading role in the Project Board and will often be represented on the Service Advisory Group. b. Some projects impact on large numbers of departments, particularly those delivering capabilities to academic departments, and in this case realisation of benefits may be quite a broad responsibility. There will be a representative of the departments/faculties on the Project Board who can assist in this. c. Some projects are enabling projects internal to CiCS, particularly infrastructure ones. They may for instance keep the technology up to date and facilitate the delivery of new facilities, like a Network Upgrade project. In these cases the benefits realisation is implicit, providing that the new facilities or requirements do emerge. d. Other CiCS-centred projects do require active promotion of the new capabilities in order to deliver benefits, like the Wireless Network, and the Project Definition and roll-out plan make clear which CiCS staff group is responsible for realising the benefits, and minimising disbenefits. Also, Project Closure documents always include transition and handover details, and these include responsibility for further rollout, publicity, process consolidation etc as appropriate. The Project Manager works closely with the Service Manager to manage the transfer of responsibilities, and the realisation of benefits. The project Post-Implementation Reviews, which happen a few months after a project ends, also address benefits realisation, particularly where new potential benefits have been identified. 3.1.3 Benefits Monitoring Service Advisory Groups have a key role in monitoring and realising benefits. The Benefit Profiles section of this document brings together the strategic benefits expected from the Portfolio and how each project contributes to it. This is updated on an ongoing basis, and is fully reviewed annually. 3.2 Risk Management Strategy Overall Portfolio (not project-only) risks are dealt with here. CiCS Development Portfolio Background: Page 3 of 5
3.2.1 Identification of Risks A strategic risk assessment is carried out annually. Additional strategic risks may be identified through the year, particularly if major projects are newly identified or there is a significant change in CiCS strategic aims. 3.2.2 Monitoring of Risks Service Strategy Board meetings will regularly include a review of the identified risks in the Risk Log, and consideration of potential new risks. This review may include modifying the perceived impact or probability of risks, and may of course involve initiating appropriate action to forestall risks or minimise their impact. 3.3 Quality Management Strategy 3.3.1 Organisation and Processes Projects are organised and run in accordance with the Agile PM/DSDM and the industry-standard PRINCE2 methodologies. The Portfolio organisation is based on the government-recommended MoP methodology. 1 Project Level Each Project Board is responsible for the quality of its deliverables. All deliverables are signed off by the business representatives and ultimately the Project Board. The Service Design & Launch Checklist helps ensure a controlled delivery, and the Post-Implementation Review directly assesses the quality of the products as used Live. Each project also has a Lessons Learned Review after closure, to assist in improving the quality of future projects. Each Project Manager reports monthly to the monthly Service Strategy Board meetings. 2 Portfolio Level The Portfolio Manager and monthly Service Strategy Board meetings monitor and support each project, ensuring that minimum standards of reporting and accountability are maintained, and ensuring that projects operate properly individually and collectively. The Service Advisory Groups, Service Strategy Board and Service Managers also monitor the outcomes of developments and how these match the anticipated benefits and the University s strategy. 3.3.2 Information All project documentation uses standard templates developed on Agile PM and PRINCE2 principles for the University by CiCS. At the end of the Feasibility stage all projects produce a Project Definition which includes an agreed Prioritised Requirements List, against which actual deliverables are judged. The lower level (expanded) PRL can be varied in a dynamic way but any change to the top level PRL affects the purpose of the project and must be formally signed off by The Board, and noted in the Project Definition. A Communications Plan is used to manage all aspects of communications, including documentation, publicity etc. Some projects will have a Quality and Test Log, which defines in a standard format how each low level Requirement is approved and signed off. Some projects do not warrant this level of documentation, either because they are too small or because the deliverables make it inappropriate. All projects issue a Project Closure document which identifies the project s deliverables and what body approved them. CiCS also has a lightweight ProjectsLite methodology. This is used within the department by individuals and teams to manage pieces of work which are too small to be formal projects but would benefit from a project management approach. CiCS Development Portfolio Background: Page 4 of 5
The service management Change and Release Management procedures, helped by the project Service Design and Launch Checklist, ensure that every service launch is undertaken in a controlled manner. 3.3.3 Configuration Project Managers are responsible for project documentation. The PPU ensures that projects produce the necessary documentation for effective communication and record-keeping at both project and programme level, and provides support where necessary. The Portfolio Manager keeps Portfolio documentation up to date, in particular the dynamic sections of this Development Portfolio Definition. The Portfolio Manager also produces reports as required by Service Strategy Board meetings, by the department and by University bodies. All Portfolio documentation is fully reviewed and updated on an annual basis. Project and Portfolio documentation are held either in Google Drive or on a shared file-store, available to the appropriate CiCS and other staff. Support documentation is available on the CiCS Projects website and Google Drive. CiCS Development Portfolio Background: Page 5 of 5