Published on July 10th, 2012 | by Adrian Stevenson0
Risk analysis and success plan
|Risk||Action to Prevent/Manage Risk|
|Phase1 recommendations are not technically feasible to deliver on within the Phase 2 timeframe
Stakeholder expectations about quality and robustness of the interface are high and potentially difficult to meet through a ‘meta’ API approach, and rapid and experimental development project.
|Collaborate with KCL and JISC to manage expectations, identify quick wins, and establish what can be achieved through this project and longer term (post July 2012)
Use project blog and communications to be as transparent as possible. Ensure that stakeholders (i.e. JISC & KCL) are fully consulted and made part of the decision-making, e.g. when project may have to make a call on whether to prioritise quality of user experience over proof of ‘ecosystem’ concept.
|The short term and specialist nature of the work may lead to difficulties recruiting staff with the right expertise.
The specialist and complex nature of the work may result in difficulties recruiting 3rd parties to develop the interface.
|Contingency arrangements to redeploy existing staff already made; where necessary use existing networks for formal and informal advice.|
|Distributed development teams and differing focus/agenda will mean information and knowledge is not effectively shared.||Advance scheduling of all meetings; use telephone conferencing/skype; keep in regular email contact.|
|During this project Mimas is commissioned to work on other areas related to Discovery and open/linked data and this may lead to over committed staff.||Start to explore early backfilling key staff; reward staff who work above and beyond their allocated work hours and at levels above current grades.|
|Collaborators/contributors are geographically dispersed and so physical meetings and workshops will be difficult to organise.||Advance scheduling of meetings & workshop; keep in regular email contact; address partners in comms planning.|
|Few datasets identified by KCL conform to the baseline requirements for a Discovery‘fit’ API.
API may not be regarded as appropriate by all stakeholders.
|Manage expectations for this particular projects’ outcomes. Gather and understand requirements for other contexts early in process. Establish baseline requirements, and where compromises are made ensure these are fully understood and external communications are transparent.|
|Approach to aggregating data from multiple contributors will be complex, slowing down refinement of the API.||Early in the Phase 1 requirements gathering phase, clarify what can be achieved within this Phase 2 project, identify quick wins for timescale of this project, and what recommendations will be made for additional work (in terms of additional content or API refinement).|
|Issues concerning metadata licensing and risks around opening data to commercial third parties are not fully understood, and so participation is hampered.||Do not make agreement to open license a prerequisite for contribution/participation. Use the project as an opportunity to explore opportunities and strengthen the business case.|
Image: © Imperial War Museum (Q 23580)