Groupware Project Risk Register

Risk Profile
Detailed Risk Register

Back to List of Project Documents

Groupware Project Risk Profile

Please 'zoom in and out' of this page to read the text (using the 'View' menu of your browser or Ctrl+ and Ctrl-).
26 March 2009


6, 16, 22*
(2), 4, (5), (7), 9, 11, 12, 18 1, 3, 20, 21
10, 14, 15, (19) 8, 13, 17

Low Medium High Severity/Impact

Detailed Risk Register

Threat ID Description Further notes Risk Category Likelihood (1-3) Impact (1-3) Risk factor Proximity / time-scale Consequence(s) Mitigation Owner Author Date Identified Date of last update Current Status Reason for change

High (9)

Moderate (6)

Low-med (2-4)

Low (1-2)

1 Inability to recruit, deploy or retain project staff with relevant technical skills The aggressive time scale means that it may be difficult to re-deploy staff and this will be further compounded by attempting to match the (currently unknown) skills to the staff available. It is difficult to plan when the solution is not known. Staffing 2 3 6 Throughout 1. Inability to train local staff during implementation. 2. Implementation will take longer without local Oxford knowledge. 3. Implementation could be more costly as we rely on contractors. We will seek to use a balance of contractors and internal staff at the outset, gradually phasing out the contractors as staff are re-deployed or hired. OUCS will try to plan ahead in order to back-fill if necessary. Project Manager Mike Fraser 25/01/08 12/02/09 No change (apart from time scale). Time scale change
2 Procurement process delayed by regulation, protracted negotiation, etc. The procurement process must be seen as being fair and in the interests of the whole University and not favouring OUCS over other departments. This means that a large committee-based selection process must be followed and this could cause delays, especially as much of the activity goes into the summer. We should see a threat of a delay possibly being balanced by a higher quality outcome. Financial / Procurement 2 2 4 March to Michaelmas Term 08 1. Procurement delayed followed by implementation and go-live and pilot (early adopters) delayed. We will work very hard to keep to early-advertised meeting dates and to service the committees in such a way that quick decisions are easily made. Project Sponsor Mike Fraser 39472 39743 Dead
3 Recurrent costs, including any licence fees, are underestimated or outwith the control of the University Licensing structures can be opaque. It is also possible that the staffing required could be underestimated by the solution vendors. Financial / Procurement 2 3 6 March to July 08 but impact felt throughout. 1. Costs increase after the first few years. 2. The project may have to go back to the University for more money. We need to be very aware of this threat and to search for solutions with obvious lower recurrent costs. The method of tendering has been designed to avoid this problem. Project Board Mike Fraser 25/01/08 25/01/08 No change (apart from conseq. Column).
4 Failure to identify and address issues relating to change management, communications, and /or business processes outside the control of the project team
Stakeholder management 2 2 4 July to Michaelmas Term 09 1. Poor uptake. 2. Poor PR following each unit's go-live. 3. Migrations and acceptance take much longer than anticipated. 4. Delayed roll out. Consider bringing in marketing expertise and try to learn from others' mistakes in this area. It may also be possible to utilise the UCG to find out about 'how the users work' in order to appear more sensitive. Project Board Mike Fraser 25/01/08 25/01/08 No change (apart from conseq. Column).
5 Mismatch between Project Business Case or Schedule and the selected solution
Planning 2 2 4 March to July 08
Project Board accepts Project Brief (with amended aims and risks) Project Manager Mike Fraser 25/01/08 17/04/08 Dead
6 Chosen solution does not interoperate with existing key infrastructure, resulting in delays and/or requiring further investment
Technical / Financial 3 3 9 Throughout 1. Delays 2. Some barely tractable problems. 3. Great PR loss, especially with the IT Support community. 4. Cost increases as expensive solutions have to be sought. (With Microsoft being the front runner) the TEG advised that there were high risks to interoperability with existing infrastructure. The Short-Listing Panel believed that it was appropriate for the project to accept these risks. Project Manager Mark Norman 25/01/08 12/02/09 Updated from moderate to high risk (now more likely). Time scale change
7 No existing solution meets the essential user requirements (or the defined requirements do not meet user expectations)
Stakeholder management 2 2 4 April to Michaelmas Term 2008 1. Implemented solution is of lower quality than expected. 2. PR problems.
Shortlisting Panel and Project Board Mark Norman 39472 39472 Dead Killed after Project Spec accepted by Short-Listing panel and Project Board.
8 Project manager granted insufficient authority or responsibility to ensure project remains on schedule
Staffing 1 3 3 April to Michaelmas Term 2008 and throughout 1. Project is delayed 2. Other risks are increased in likelihood.
OUCS and Project Board Mike Fraser 25/01/08 25/01/08 No change (apart from conseq. Column).
9 User consultative group or shortlisting panel does not sufficiently represent key stakeholder user groups or engage with the project Previously estimated to be 'Low' risk, there is a further risk that changes to the Selection Panel/Shortlisting Panel could be seen as bypassing the 'representative nature'. Stakeholder management 2 2 4 April to Michaelmas Term 2008 and throughout 1. Lack of endorsement of the chosen solution, leading to other risks (in particular 4, 15, 16, 20, 21).
Project Board Mark Norman 25/01/08 17/04/08 No change (apart from conseq. Column). Time scale change
10 Units already supporting a groupware solution do not, or are not able, to migrate users to a centrally-provided service
Stakeholder management 1 2 2 July to Michaelmas Term 2008 and throughout 1. A federated structure may not work well and we may have a lot of duplicated effort. 2. Huge disappointment in some parts - poor PR. 3. Increased expense overall for the University.
OUCS and Project Board Mike Fraser 25/01/08 25/01/08 No change (apart from conseq. Column).
12 Implementation (by unit) does not give enough time to change management processes and the individual needs of the users within each unit
Stakeholder management 2 2 4 Throughout. 1. Users are annoyed in that the new software does not work with their business practice. 2. Possible delays due to extra training and change management overhead. (We may need the Project Board's guidance as to how swiftly implementation is carried out.) OUCS and Project Board Mark Norman 18/04/08 18/04/08 No change (apart from conseq. Column).
13 Key staff (e.g. Project Manager, chief internal architect/analyst) leave
Staffing 1 3 3 Throughout, but especially April to Michaelmas Term 08 1. Delays.
OUCS and Project Board Mark Norman 18/04/08 18/04/08 No change (apart from conseq. Column).
14 Lack of training for IT support staff gives rise to poor co-operation from ITSS and concomitant resentment from end-users.
Stakeholder management and Staffing 1 2 2 Throughout 1. Lack of endorsement of the chosen solution, leading to other risks. 2. Lack of support for users. 3. Poor PR. 4. Possible delays.
Project Manager Mark Norman 18/04/08 18/04/08 No change (apart from conseq. Column).
15 Lack of engagement or PR means that uptake is poor and understanding is inadequate. This refers to finding early adopters and then capitalising on early success to move the majority of users/departments to the new system. Stakeholder management 1 2 2 Throughout 1. Roll-out takes far longer than anticipated and the 'project' still exists, when it should be entering the 'service' phase. 2. Users do not understand why they are being forced to change, leading to resentment.
Project Manager Mark Norman 18/04/08 18/04/08 No change (apart from conseq. Column).
16 Setup costs (within the original budget, i.e. At January 08) prove insufficient due to scope creep and we have a serious shortfall. Scope creep or enhanced expectations (for example, extending the scale and increasing expectation of 24/7 resilience) above the levels of existing services could make the project more expensive if new scope is considered to be appropriate. Financial / Procurement 3 3 9 April to December 08 (or until PRAC approve the funds) 1. Disappointed stakeholders as/when scope creep is resisted. 2. If scope creep occurs, there could be delays. 3. If scope creep occurs there will almost certainly be increased costs. Project board may need to make a judgement at some stage as to whether to accept previously envisaged plans or whether to apply for an increased overall 'envelope' to the budget or whether reduced scope in other areas is acceptable. Project Board Mark Norman 18/04/08 23/10/08 Likelihood increased from 2 to 3. Scope creep has occurred, but for largely good reasons. There is a widespread expectation that a 2 site DR solution is necessary. Other components of the project have been moved out of scope.
17 Poorly thought-out technical architecture is adopted.
Project Decision 1 3 3 July 08 to Hilary Term 09 1. Scale problems are encountered leading to severe delays and possible complex migration problems when 'service' phase has already effectively begun. Review implementers' suggestions carefully. Internal implementation must be documented, planned and reviewed first. OUCS Mark Norman 18/04/08 23/10/08 Time-scale amended.
18 Some of the technology (at least) will be new to the Project Team and therefore there is a threat that it could be sub-optimally implemented. This threat clearly exists with the Microsoft solution being front-runner. However, the consequence is more likely to be delays than a sub-optimal implementation. Staffing 2 2 4 July 08 to Hilary Term 09 1. Unforeseen problems, probably of scale (see 17). 2. Initial lack of understanding as to how to remedy these. 3. Main consequence will probably be in delays to roll-out. Training needs to be examined closely and the (sensitive) use of contractors should ensure transfer of skills. We plan to enlist ITSS skills to enhance the OUCS skill set. OUCS Mark Norman 18/04/08 23/10/08 Time-scale amended.
19 Lack of space in machine rooms at the correct time.
Planning 1 2 2 July to December 2008 1. Delays before implementation can go ahead. 2. Delays to disaster recovery solution (or 'safe state'). Need to plan ahead and reserve the space, even before the hardware need has been fully planned and procured. (These plans are now in place). Project Manager Mark Norman 39556 39744 Dead Racks have been reserved and are in (or just outside both machine rooms)
20 Solution chosen, despite being the best fit functionally and technically is unpopular due to cultural differences or prejudice. Example: Many IT service providers around the University may be wedded to the multiplcity of tools available for MS Exchange. If Exchange was found not to be the best fit technically or functionally, there may be little uptake because of these pre-conceived notions. e.g.2 Similarly there are also prejudices against Microsoft from many IT SPs at the University (and there are geniune risks with interoperability with a MS solution). Project Decision 2 3 6 July 08 to summer 2009 1. Lack of uptake leading to many of the other risks listed here. The process must be as open as possible, and to be seen to be representative of users as well as technical specialists. We must accept that no one solution will be universally popular. We will have detractors whatever is chosen. Project Board Mark Norman 22/04/08 04/07/08 Reduced from high to moderate. The process has been fairly well managed. The risk is still moderate to high, but much emphasis was put on the 'representative' nature of those taking the decision. This is still a serious issue, but is now a little improved.
21 Failure of pilot after early phase of implementation. This threat is increased in likelihood due to the inability (due to lack of time) for a full technical evaluation phase. Technical 2 3 6 July 08 to Hilary Term 2009 1. Severe delays as repeat evaluation and implementation must be carried out for another solution. 2. Possible contractual problems. Early adopter phase must be seen as trial and exit strategy planned. We must be prepared to run Herald (and other departmental solutions) alongside new groupware solution for some time. Project Board Mark Norman 08/05/08 23/10/08 Time-scale and mitigation amended.
22 Protracted negotiations between Oxford, the designer and Microsoft cause a delay to the implementation.
Technical 3 3 9 Hilary Term 2009 Roll out is delayed, hitting term time and the timetable will need to be adjusted. Much effort has been put in to ensure that the overall architecture is sound. The project team are working incredibly hard and we are bringing in other experts to assist. OUCS Mark Norman 12/02/09 25/03/2009 Likelihood increased from 2 to 3. Some assistance (e.g. from Microsoft) has been a little slow to materialise. Nevertheless, much is currently being done.