GOOD PRACTICE GUIDE. Delivering business benefits from IT infrastructure projects

Transcription

1 GOOD PRACTICE GUIDE Delivering business benefits from IT infrastructure projects

2 Contents Purpose 1 Management summary 1 The questions we asked? 2 Delivering clearer business benefits from IT infrastructure projects 7 Appendix 1: Extract from the Business Case EUCLID 9 Appendix 2: EUCLID benefits 10 Apendix 3: Project scope diagram 11 Appendix 4: Major project governance toolkit 12 References 15 Universities and Colleges Information Systems Association University of Oxford 13 Banbury Road Oxford OX2 6NN Tel: +44 (0) Fax: +44 (0) admin@ucisa.ac.uk

3 Purpose This paper proposes techniques that might be employed in improving the identification and realisation of business benefit from IT infrastructure projects. The University of Edinburgh undertakes projects of varying size every year and the paper considers two recent and significant projects carried out at the university and summarises a collection of activities that might be used to improve business benefits management in IT projects. Management summary The problem Benefits realisation can be difficult to measure especially if it is defined in an ambiguous way when the case for the project is made. Connecting the business benefit to the IT enablers helps the business to understand need and for the benefit to be realised. There can be sensitivity around benefits and what they might mean or imply, e.g. a reduction in staff headcount or a change in business direction. This can be a barrier to effective benefits management. Benefits are often consumed by other business processes and can potentially be lost unless these processes are more clearly understood and defined. Many benefits appear unquantifiable or are so complex to measure in isolation that they mean very little. This is also the case when a solution comprises many enhancements each of which has an impact but the project has a perception that the outcome assessed as a whole has a positive impact. IT infrastructure projects can often be expressed in technological terms which exclude the business user who is inadvertently encouraged to disengage from the project. As a result many infrastructure projects can be weak in terms of benefits definition resulting in a negative perception of these projects (as delivering new toys rather than business value) and under investment. Some possible solutions A sound and credible business case is the foundation of making a project compelling and successful. The business case is not simply the document that justifies the project being started it should be used repeatedly as the project progresses to support decision making, confirm priorities and help ensure that benefits are being driven through. Connecting the business benefits unambiguously to the IT enablers (e.g. the solutions that deliver the new functionality, solve the problems, speed up the process etc.) will help the business to understand and value the IT and, ultimately, realise the benefit. It s very important for infrastructure IT projects to deliver early and Minimum Usable Subsets (MUS) of enablers need to be delivered for a project to be considered a success. Do this by defining the must have priorities and make sure the project team focusses on delivering these priorities first. Missing one essential requirement in a project that delivers many other requirements of varying priority means the project fails to deliver the outcomes needed by the business. Furthermore, the impact of failing to deliver MUS can lead to demands for additional resource which in turn can impact other projects and disrupt their ability to deliver. De-scoping of features or functionality needs to be considered in conjunction with the business in order to focus on priorities and to determine whether a scope change has an acceptable impact on the benefits the project is intending to realise. Use the MoSCoW model and avoid having more than 60% of project deliverables considered MUS, challenge this vigorously if the project is found to be in this position. Deliver the MUS then move on to the Should Have and Could Have benefits. After 60% of resource used confirm that all mandatory or essential business benefits/enablers have been delivered, if not take action. B E S T P R A C T I S E G U I D E D E L I V E R I N G B U S I N E S S B E N E F I T S 1

4 For IT infrastructure projects it will be helpful to adopt the following approach: z Define the IT enablers to be delivered by the project z Agree the priorities for these enablers (e.g using the MoSCoW Method) z Identify the MUS of these enablers that must be delivered for the project to be considered a success. (Failing to deliver the MUS will have a major business impact and could result in reputational damage for IT and disruption to other projects through resourcing the remedial actions required to fill the gap.) z Ensure the project is adequately resourced so that delivery of the MUS accounts for no more 60% of the available resources to minimise risk of non-delivery due to resource shortages. If this is not the case challenge both the MUS and the resources being made available. (As a corollary to this the 60% resource point can be used to review status on MUS delivery and identify any actions required.) z Schedule the project so that delivery of the MUS is the first priority for the team. When the MUS has been delivered the team can move on to the Should Have and Could Have features if there are resources available and the customer still requires these features Note that although this discussion has focused on IT infrastructure projects all of the techniques can be used in traditional IT business change projects. For example, the MoSCoW model and MUS approach could be used for any project, programme or project portfolio. As an example, consider an annual planning process that allocates available resources to a set of IT projects to be delivered in a financial or calendar year. Application of this approach suggests that no more than 60% of that total effort should be considered critical, i.e. in the MUS, if risk of failure is to be effectively managed. The questions we asked? A series of questions was put to stakeholders and project managers who are involved in delivering IT projects for the University, the questions and their feedback is included and identified in italics below. The questions How can our investments in IT produce measurable benefits as part of their delivery? How can we define this and measure it consistently on a project by project basis? What are the processes that link the upstream IT investments with the downstream business results, productivity gains, increased revenues, sector advantage, better job performance, improved product and service quality? How do we rank IT enabled business transformation projects to determine which are most important? We do a lot of planning and seek collaboration from our partners: is this always successful? As an organisation do we review where things have gone well and not so well? How do we insure that our projects and other business initiatives work in concert with one another? How might we do this differently to improve our benefit realisation? B E S T P R A C T I S E G U I D E D E L I V E R I N G B U S I N E S S B E N E F I T S 2

5 Current practice Typically projects are carried out using traditional waterfall methods adhering to a framework based around PRINCE2 principles. See Projects are typically initiated after the business case is developed and proceeds to a formal planning exercise. Once complete, the project is normally reviewed and lessons learned are recorded. The two cases we reviewed were the EUCLID and Timetabling projects. We asked the project management team the questions and gathered the responses we received and examined them. For EUCLID: EUCLID was a very significant project which had the primary aim of delivering a new student management system. This ambitious project involved many stakeholders and was a very significant investment for the University of Edinburgh. The project was multi-year and transformed all of the workflows involved in managing the student from application through to award. The Business Case for the implementation phase of the EUCLID Project was established in October 2006 (see Appendix 1) and envisaged phased delivery of a vast range of functionality over the web, with responsibility for data keying devolved to source. For Timetabling: The Business Case for the timetabling project was established in November This was a much more comprehensive assessment and justification for carrying out the project. The case covered areas including summarising the reason for the project, the options that had been considered, potential benefits, implementation plan, costs and risks. The case was produced following a significant consultation exercise involving the student association, all of the schools and colleges and the support groups in the University. How can our investments in IT produce measurable benefits as part of their delivery? How can we define this and measure it consistently on a project by project basis? The benefits are very specific to the objectives and context of the project, so the metrics/measures are very different and difficult to compare on a like by like basis, unless all benefits are ultimately translated to money ( ). Unless benefit is delivered immediately following project closure in a measurable way it may never then subsequently be assessed. The business benefit more typically can t be measured at project closure, but accrues over several years post project delivery. Early evidence of success (as of Dec 2010). The nature of the University s business was determined to be too complex to be confident that EUCLID had been a success. At this early stage it was not possible to conclude that it was responsible for such things as increased conversion rates. However, the absence of significant negative indicators was, in itself, identified as an indication of success. Some positive indicators included: Since the introduction of the online postgraduate application form the University has experienced record numbers of applications particularly from international students. The system remained available to staff throughout the intensive processing period at the start of the academic year. Record numbers of students were registered and record sums of money were taken. A number of Schools have recognised the potential of the system in relation to the rules built in through the Degree Programme Tables (DPTs) which can be used to validate course selections and may in future allow progression decisions to be automated. As a result, there is increased interest in reviewing and simplifying DPTs. The Business Objects XI reporting tool has been well received by a number of users who are finding it more powerful and flexible than WISARD. A number of Schools in Humanities and Social Sciences (HSS) are considering adopting SMART (in house application) for managing student assessment data and are recognising that this may require standardisation of their business processes. B E S T P R A C T I S E G U I D E D E L I V E R I N G B U S I N E S S B E N E F I T S 3

6 Replies: This project has subsequently been considered a success but generally in poorly defined ways, often relying on impression rather than a clear correlation with a set of agreed business benefits or enablers. How much more satisfactory would it have been to determine that all of the business enabling IT had been delivered at the close of the project as required by the business? The project overran and cost significantly more than had been previously estimated or justified in the business case. The project overran and delivered later than was expected delivering important functions later than was needed and impacting the benefit. The project requested and successfully secured additional resources in order to complete, placing other projects in under resourced situation which in turn were delayed. What was clear was that trying to understand the impact and the relative benefits of a complex service like EUCLID was very difficult to achieve. A service like this in its infancy with staff and users still coming to terms with the solution is effectively impossible to evaluate. It was also clear that there had been considerable project descoping carried out in order to ensure particular milestones were achieved and that certain functionality remained outstanding. Whether this was rigorously checked against the business case in every occasion is not clear. The business case demanded changes to the IT infrastructure and services we ran. Confirming that the MUS of features or enablers had been delivered at the close of the project would have helped the business to assess whether the project had been a success or not. It would have been helpful for the project to have clearly defined the major benefit priorities at the start to enable these same priorities to be assessed at project closure. Achieving this would have focussed the project team on delivering these priorities first, then once delivered they could have moved on to lower priority objectives. Using the MoSCoW model all critical objectives should have been delivered after 60% of the total resource for the project was consumed. Had this been reviewed it would have been clear that this had not been achieved, action could have been taken early to resolve this by de-scoping according to the business priority. An illustration of project scope business benefits is seen in Appendix 3. The EUCLID and Timetabling projects consumed more resources than they was entitled to or budgeted to from the business case. Projects are generally prioritised to make sure that the highest priority projects get the resources they require. However, this does not mean that every deliverable of a project is essential. Not having proper governance across not only projects but programmes of work has a tendency to make projects soak up resources for work that might not actually have the business priorities behind it. This lack of focus means that projects inevitably fail to deliver the best business benefit for the organisation. Considering scope change in conjunction with the business case and agreeing the current state of priorities with the business helps to avoid this situation from developing. An example of where project governance can encourage projects to ultimately succeed can be seen in Appendix 4. As a general rule, however, delivering the critical enablers first (MUS) should leave 40% of the available resource to deliver the remaining lower priority Should Have and Could Have objectives. If a project starts to run out of resources/time the business should be left with easy choices relating to priority rather than essential deliverables still to be delivered once all the resource has been consumed forcing conflict. What are the processes that link the upstream IT investments with the downstream business results, productivity gains, increased revenues, sector advantage, better job performance, improved product and service quality? The original EUCLID business case identified a range of benefits from increasing revenues from better admission processes. A key business process surrounded admissions and, in particular, online PG application process and form for International students. Implementation of changed workflows and processes as a consequence of implementing EUCLID improved this process significantly and delivered faster turnaround in decisions resulting in greater uptake of offers. B E S T P R A C T I S E G U I D E D E L I V E R I N G B U S I N E S S B E N E F I T S 4

7 This aside, there does not appear to have been a process undertaken where the University considered and assessed each of the benefits as having been delivered, see Appendix 1: Business Case Extract. Additional fringe benefits have emerged post go live that relate to cost savings and advantages with compliance using a package solution rather than in house developed. (The latter not being mentioned as a goal in the business case.) There is an apparent gap between technology investment on one hand with the measurement of the benefits on the other. Many of the benefits may well have been delivered from the project but it is unclear whether they have been realised and there appears to be no other record of this other than hearsay and personal opinion. At what point has the business recognised that the project has fulfilled its role. Not having clear linkages between the business case and the targets of the project mean that at the closure of the project it was not possible to confirm or underline that the project had delivered what was needed. Often it is not clear when an evaluation will even take place following closure, who has the responsibility for carrying out the assessment. How does it influence project lessons learned and planning or organisational priorities, this is often quite unclear? Often planning is so focused on looking forward that what has come before is examined rigorously across all projects to confirm that business benefits are realised. This suggests that in the absence of having an agreed benefits assessment methodology established at project closure, the time to confirm whether a project has delivered only really comes at the point of project closure. This may well prove to be the only time to make this assessment. Benefits that are defined as enablers in IT infrastructure can be assessed as the project closes. The business can then form ways of measuring the impact of the enablers and satisfy the business drivers over the longer term. The business case for the timetabling project spent considerable time developing the case for benefits. There is an overriding benefit to having an institutional timetable that is accepted. It is recognised that in terms of value to the University, as a result of improving student experience, this will have a sufficiently positive effect and is therefore a priority for the University. The business case makes an argument for saving in efficiencies in use of Estates and Buildings but also recognised that only after full implementation would many of the benefits be realised. Many of the described benefits for the projects do not have clear yes or no answers when the question is asked about delivery. Often words like improved, better, more, greater, less and effective are used, which are very difficult to evaluate or represent by a true value. Some of the business benefits are not even direct benefits but seen somewhere along a chain.this sort of positive outcome for the business cannot realistically be assessed when the project closes. An example might be a second or third line efficiency that comes from greater use of a shared dataset. The use of which was never factored into the business case. If the business needs to confirm that the effects of change are being delivered then it is important that ways of evaluating this effect are developed in order to carry out this long term assessment. How do we rank IT enabled business transformation projects to determine which are most important? We do a lot of planning and seek collaboration from our partners: is this always successful? As an organisation do we review where things have gone well and not so well? Each year, a major planning exercise is undertaken. IS Applications Division coordinates this planning process to determine central IT systems developments for the following year. The purpose of this process is three fold: 1. to identify the needs of the University community 2. to prioritise the use of the centrally funded resources in IS Applications 3. to seek additional funding if the available resources are insufficient to meet the priorities of the University community B E S T P R A C T I S E G U I D E D E L I V E R I N G B U S I N E S S B E N E F I T S 5

8 The planning process starts with initiation, where requirements are gathered and project briefs are prepared, outlining the objectives of the project, costs and benefits. Some rough estimation is also undertaken at this stage to give the planning process some idea of the amount of effort required to carry out the project. Once prioritised and ranked against the other projects that are submitted, a total cost of effort is calculated. Where this exceeds the total amount of resource days available to the department to complete, the lower priority projects are either held back or dropped. For projects that are successful and pass this first red line cut a business case can then be completed. This is increasingly the case for both large and small projects and forms a fundamental part of a project defining major targets, requirements and deliverables. Requirements are driven by the users of the solution. Once the project is cleared to progress, project managers are assigned and resources secured to participate on the development. The project executes, with a governance framework, supporting changes to the project including scope, timing, resources etc. Once complete, the project is assessed to confirm that the benefits have indeed been delivered and records made of any lessons that can be learned from the experience. This is particularly useful when something has not gone well and suggestions on how to adapt the way we work are discussed and potentially adopted. How do we insure that our projects and other business initiatives work in concert with one another? Transparency is very important. Our annual planning process encourages business areas to share their plans for the future, making it easier for us to identify potential conflicts or impacts at an early stage. Creating forward plans helps to demonstrate these potential conflicts and stimulate discussion. As we move to executing our projects, and we begin to understand more of the detail, interrelationships and dependencies, or perhaps we may need to make changes to scope, milestones and/or budget. To minimise the impact of our project decisions, we have a governance framework in place, which operates at a number of levels. Within the Applications Division we ensure that all project changes are submitted to a weekly review group who will look for evidence of stakeholder engagement and, where possible, will highlight instances where a change has a wider impact. Within a programme, the programme owner and the programme manager are responsible for identifying changes which impact another project or element of the service. At the portfolio level, programme managers, the portfolio manager and the portfolio owner consider the impact of project changes across the portfolio. Whilst the combination of transparency and governance might not always ensure that our projects and business initiatives work in concert with one another, it makes it much easier to identify where they cannot, so that a suitable course of action can be agreed. B E S T P R A C T I S E G U I D E D E L I V E R I N G B U S I N E S S B E N E F I T S 6

9 Delivering clearer business benefits from IT infrastructure projects Benefits are delivered by projects when they deliver solutions that are fit for purpose. In today s world there should be no such thing as an IT project. All IT projects must deliver business benefit. All IT projects are, therefore, business projects. Defining these business benefits is a very important part of being able to assess them as having been delivered or not by a project. Determining what the benefit is and how it will be assessed is fundamental to reaching the goals of the project. This demands project decision making to be taken with benefits in mind. This requires a close understanding of true business priority and should be reflected by the business case for the project. IT projects often do not deliver direct business benefits. In fact, in many cases the technology is simply a conduit or an enabler bringing about business change. A key element in determining whether an IT project will be successful or not is establishing with the business which of the enablers are essential to deliver a usable or viable solution. This is the Minimum Usable Subset (MUS, see MoSCoW). As the project executes changes of scope can be expressed as changes to the benefits and decisions can be made by the business to assess the impact and the cost. Even a change to the delivery milestones might have an impact that should be considered. This might for example have an impact benefit realisation. This must be evaluated. A project team must remain focussed on priority at all times. The project manager must ensure that having defined the MUS with the business, the team delivers this set of requirements first. The project manager must make sure that the technical team working on an infrastructure project understand that to follow anything other than this path is to put the project into very difficult territory. Technical requirements can be essential of course, but the technical team needs to explain to the business why it is essential and why it must form part of the MUS. Technical teams must not be given unclear objectives that allow room for personal priorities. Personal or undefined requirements do not have agreed priority by the project team or the business and threaten the ability of the project to deliver. Planning exercises use business priorities to determine which projects make most sense to undertake, based on cost benefit. There may well be situations where a new strategy is declared by a business visionary (CIO, Principle etc.) that has not a fully formed business case, but due to the nature of how this initiative is undertaken, it can push aside or override seemingly strong cases and proposals. In situations like this it is very important to understand quickly what associated projects are attempting to achieve to ensure those visionary benefits. Doing this increases the probability that they are realised and they align with the vision. In assessing the business case for a project it is essential to determine the different benefits and what their relative priorities are. It is wise to consider a short and manageable number of benefits. This keeps the projects focussed and allows the business to easily determine the right path when scope changes are discussed. Projects should break down benefits into Must Have, Should Have, Could Have, Won t Have this time (MoSCoW) and agree this prioritised list before the project commences with the business. In addition, there should be no more than 60% of the total effort of the project allocated to Must Have features. To do otherwise places considerable risk on the projects ability to deliver. Every technical activity in an infrastructure project should sit within this prioritised list. The recommended proportions of priority should be: z 60% effort Must Have to produce a viable solution z 20% effort Should Have, losing these could be costly or time consuming z 20% effort Could Have, workarounds are cheap to implement Once the benefits have been established the acceptance criteria should be established too. This, in an IT sense, is often simply a matter of delivering the enabling technology. The argument being that the full business benefit might be realised as a consequence of exercising these enablers. The acceptance criteria should be SMART (Specific, Measurable, Achievable, Realistic and Timely). B E S T P R A C T I S E G U I D E D E L I V E R I N G B U S I N E S S B E N E F I T S 7

10 The infrastructure example A business case is developed that presents a compelling argument that by upgrading to a new Storage Area Network (SAN) the business would realise significant advantage. The business case details the cost and benefit in terms that focus on the business priorities and draws a linkage between the solution and how these business benefits are going to be realised. The proposal is given support and a project commences. The details of the deliverables are established and their relative priorities determined. The number of critical or Must Have objectives are highlighted. These being objectives that would render the project a failure if they are not delivered. The remainder of the benefits fall into the other categories of Should Have and Could Have. The likelihood is that the deliverables in this case are most likely enabling technologies or capabilities and are subsequently examined to agree what acceptance criteria would be used. This process requires the linkage from the technology to the business benefit to be clearly understood and agreed by all participants in the project. The project executes very well. The project manager uses a simple list of priorities to keep the team focussed on the Must Have actions. By 60% of the total resource consumed by the project, the team has successfully delivered all of the Must Have enabling technologies. This milestone is recognised by the business and the governance team, and the project team is praised for the work they have done to reach this milestone. The project governance team can assess at this point that regardless of what happens beyond this point the project has delivered the essential enabling benefits and is likely to be a success. The project continues from this point with the same attention to priority and by project resource consumption of 90%, has delivered all of the Must Have and Should Have enabling technologies and all pass acceptance tests. [SW53][SF54] Due to a combination of overrun and site specific difficulties the project consumes all of the allocated time and it is clear that unless the costs are adjusted and further resource is allocated the remaining Could Have enablers will not be delivered. The project determines, in collaboration with the business, that these items should be de-scoped rather than consume additional resource to complete. The project can close and can immediately declare where the successes have been delivered and make sense of why the remaining Could Have enablers were de-scoped. The project closes, on time, using the expected amount of resource and the maximum business benefits are ultimately realisable. This approach allows the business to inform the project and ultimately choose which path to take to ensure that the project delivers the enablers that are most important to the business. This follows the argument that all IT projects are in fact Business Projects. At 60% resource used the governance team already knew that the project would be a success! The project services view Asked about this matter, Projects Services in Applications Division here at the University highlighted the following points for infrastructure projects: All infrastructure projects should be considered business benefit projects. Regularly revisit business case statements as the project continues to make sure that the ship is sailing in the right direction. We should all benefit from having greater business focus and being more open and clear about changes in projects to make sure the right decisions are being made. The list of benefits needs to be short to keep focus and understanding of priorities. Decisions are hard to make and need everyone to understand why they are being taken. B E S T P R A C T I S E G U I D E D E L I V E R I N G B U S I N E S S B E N E F I T S 8

11 Appendix 1: Extract from the Business Case EUCLID Vision The EUCLID Project will transform student administration. It will deliver radical improvement to the way the University interacts with students and supports academic staff. This will be delivered through investment in technology, and organisational commitment to far reaching business change across the University, especially in the Schools and Colleges. Goals Enquirers and applicants will receive a world class service z Online enquiries with fast, friendly responses z Effective approach to handling enquiries by phone, , letter and in person z Online application facilities for all non-ucas students z Online application facilities for scholarships and bursaries z Fast decisions on postgraduate taught and research applications Student administration will underpin the quality of the educational experience z Seamless online services delivered through the portal from e-learning to assessment results z Faster, easier ways for students to carry out administrative tasks z Online registration and fee payment z Online enrolment on courses and personalised timetables of classes and exams Teaching and research will benefit from significantly improved support z Academic staff time released unnecessary tasks eliminated or delegated z One single shared student information system z Interoperation between core University systems in this context the transfer of information to and/or from other corporate systems as required z Greater uniformity and shared working practices z Accurate, accessible management information whenever it is needed The University will have the flexibility to enhance its position among the top 30 world institutions z The stability and the reach to be fleet of foot when the organisation wants to take advantage of new directions, such as partnership relationships z Make a generation leap to give us a competitive edge in the services we offer our students z Turnaround times that make us more effective in postgraduate and international recruitment z A strong infrastructure to react smoothly and effectively to change B E S T P R A C T I S E G U I D E D E L I V E R I N G B U S I N E S S B E N E F I T S 9

12 Appendix 2: EUCLID benefits Immediate benefits EUCLID provides a secure and accurate in house student record system to replace the existing system which is built using Oracle technology and is, therefore, a significant risk to business continuity. EUCLID provides an integrated admissions, student, course and programme record system, which reduces duplication of data entry. EUCLID provides new functionality including: z online application forms for postgraduates and visiting students; z an online applicant portal which allows all applicants to track the progress of their application; z integration between DPTs and the courses catalogue facilitating publication to the web; z validation of course enrolments against the DPTs. Moving from a bespoke in house student record system to a package solution reduces the risk and cost of ensuring current and future statutory compliance by: z sharing the compliance cost across all SITS users; z combining with the group of SITS users in taking a uniform approach to compliance. Related or linked systems will: z meet UKBA managed migration regulations; z facilitate access to postgraduate student administration data; z provide an accurate timetable of courses. Potential longer term benefits EUCLID will provide a platform from which: z on line student self service functions can be delivered; z areas such as assessment can be integrated into the student record, and automated progression based on DPT rules can be introduced. EUCLID offers the potential to devolve student administration functionality to Schools. As a package solution, EUCLID offers the opportunity to adopt additional functionality that is already in use elsewhere in the sector. B E S T P R A C T I S E G U I D E D E L I V E R I N G B U S I N E S S B E N E F I T S 10

13 Appendix 3: Project scope diagram BENEFITS Deliverables OBJECTIVES B E S T P R A C T I S E G U I D E D E L I V E R I N G B U S I N E S S B E N E F I T S 11

14 Appendix 4: Major project governance toolkit Overview of the Major Projects Governance Toolkit Project: Major Project: A set of activities which are managed and coordinated together to deliver a specific outcome in a defined timescale A project which has a significant financial, operational, or reputational impact on the University, College, School or Support Group Undertaking major projects brings higher risks to the performance and future success of the University. Major projects, therefore, require a more rigorous approach to project management and the identification and management of risks. A Major Projects Governance Toolkit has been developed to assist staff who are managing or participating in major University projects. The Toolkit provides: a) guidance on assessing which projects should be classed as major projects b) a governance framework identifying the key elements that must be established in the management of major projects c) an assessment tool and approach to ensure that the required governance activities work effectively throughout the life of the project d) a visualisation tool for project governance which gives a view of the project as it currently stands and the changes since project initiation The Toolkit can be used as a reference point for all projects, but for major IT projects use of the Major Governance Toolkit is now mandatory. Major projects often naturally break into a number of phases. For example: Initiation Business case Procurement Implementation Closure Normal service An initial governance assessment should take place as part of project start up with further reviews at least once per project phase (or every six months; whichever is the sooner) for the lifetime of the project to ensure that all of the required governance activities remain in place and working effectively. It is a primary key of the Project Sponsor to ensure that an appropriate governance framework is established and maintained for the duration of their project. For major projects this framework must include regular assessments of project governance using the assessment tools provided in the toolkit. In assessing whether a project is a major project, there are a number of criteria that need to be considered including: total cost of the project, i.e. the whole life cost including recurring costs over 48 months the impact of the project on staff and students the complexity of the project the reputational impact on the University if the project runs into difficulties The Toolkit includes a simple assessment tool to help determine whether a project should be classified as major. The Toolkit uses the following generic model for managing major projects and the changes they aim to bring about. The Toolkit is used to visualise the project s status based on each of these governance elements. B E S T P R A C T I S E G U I D E D E L I V E R I N G B U S I N E S S B E N E F I T S 12

15 Create vision Vision for the change Grip people Team building Sponsorship/ Stakeholder Communication Grip task Project management Governance/ Risk management/ Implementation Embed Learning Measurement Ongoing As the project moves forward there will be significant iteration, i.e. there will be a constant need to maintain team cohesion, reinforce project sponsorship and stakeholder buy in, restate the vision, assess governance and risk management etc. For this reason the governance assessment cannot be a one off event and must be repeated with an appropriate frequency during the lifetime of the project. Using the Project Status Assessment Tool This assessment tool should be completed by members of the Project Board, User Group and other key project stakeholders. Each assessor records a score for each governance element in the range 0 10 based on the following guidance: 0 Not started. Typically only valid for later Embed elements. Action is required to address omission. 1 3 Emerging, immature and/or incomplete. Typically only acceptable in the early stages of a project or for later Embed elements. Action is required to improve overall management of element. 4 6 Progressing towards best practice with clear evidence of positive impact. Action is required to further improve position Mature. Good framework and practices in place. Clear evidence of positive impact. Action may be required to maintain position. All the responses are analysed, collated and plotted on a Radar Diagram to indicate the individual and collective perception of the current project status. The analysis will be repeated at different stages through project delivery, and the shape of the Radar Diagram will change over time, giving an indication of where the project is going well and where action may be needed. B E S T P R A C T I S E G U I D E D E L I V E R I N G B U S I N E S S B E N E F I T S 13

16 The figure below provides a Project Status Visualisation Diagram which can be produced using the Microsoft Excel Radar Chart Type. Multiple assessments can be included on a single diagram to produce a view of both current status and the changes since project initiation. Vision Learning Ongoing improvement Measurement Business case Stakeholder buy in Team building Implementation Communications Project management Risk and assurance Governance B E S T P R A C T I S E G U I D E D E L I V E R I N G B U S I N E S S B E N E F I T S 14

17 References en.wikipedia.org/wiki/moscow_method en.wikipedia.org/wiki/agile_management B E S T P R A C T I S E G U I D E D E L I V E R I N G B U S I N E S S B E N E F I T S 15