eSDO Risk Management Policy and Plan

This document is also available as a pdf.
eSDO Risk Management Policy and Plan
Elizabeth Auden
02 February 2006

Introduction

The eSDO risk management policy document explains how risks affecting eSDO solar algorithms, data centre work and visualization tools will be identified and classified. For an explanation of how identified risks will be dealt with, please see the eSDO risk management plan.

Applicable and Reference Documents

Resources

Project resources can be divided into four categories: staff, developed code, external software and hardware. Five developers work on the eSDO project; two developers are budgeted at full time effort, and three developers are budgeted at 50% time. All developers are budgeted to work through the end of the project on 30 September 2007.

Developed code refers to solar algorithms and visualization tools written by eSDO developers. It also refers to catalogues developed from eSDO algorithms that will be stored in databases and made visible to virtual observatories with the AstroGrid DSA module.

External software includes AstroGrid software, C compilation and debugging tools, databases and the JSOC pipeline. Hardware covers the eSDO server (msslxx), the proposed UK data storage facility (the ATLAS tape store), JSOC storage and processing machines, and other machines in the UK that may be used to host eSDO algorithms during the SDO post-launch phase.

Organization

There are three parties responsible for managing risk on the eSDO project:

  • project manager - as coordinator for all development work, the project manager is responsible for identifying risks as communicated by developers, coordinating advice from scientists and developers into a cohesive action plan, and overseeing the execution of the action plan.
  • scientists - as both algorithm experts and representatives of the UK solar community, this group has a dual role. First, as individuals these scientist will advise their institute’s developer(s) on refinement of the solar algorithms to ensure that these applications use up-to-date scientific methods and produce logical scientific results. Second, this group should collectively advise on the operation of solar algorithms, visualization tools and data centre work to ensure that the UK solar community receives as much benefit as possible from these workpackages.
  • developers - the eSDO developers will have the most in-depth knowledge of solar algorithm code, visualization tool code, and configurations for catalogues and data centres. Therefore, this group is responsible for communicating problems and risks for all of these workpackages to the scientists and project manager.

Project Summary, Goals and Resource Constraints

The eSDO project has been funded for three years by PPARC to make data and algorithms from the Solar Dynamic Observatory available to the UK solar community. The project is divided into research (Phase A) and implementation (Phase B). Both phases addressed three major workpackages: solar algorithms, data centres, and quicklook / visualization tools.

The four institutions of the eSDO project will design and implement 10 solar algorithms covering image and feature recognition, global helioseismology, and local helioseismology. Algorithms will be made available through AstroGrid, the JSOC pipeline, and SolarSoft. Visualization techniques such as streaming tools, catalogues, thumbnail extraction and movie generation aid scientists in archive navigation. The primary SDO data centre will be based in the US, and users can access the data directly through the Virtual Solar Observatory (VSO). A second data centre will be established in the UK. Rather than providing a full data mirror, this data centre will cache recent data products and popular data requests. This local data cache will provide UK scientists with more rapid access to SDO data and allow SDO data searches to be included in AstroGrid workflows.

The eSDO project employs five developers and is advised by six scientists. After the initial 12 month Phase A period of research, the project will spend two years implementing the workpackages during Phase B. A total budget of £500,000 has been allocated from PPARC. Algorithms, visualization tools and data centre work will be conducted with tandem input from the UK solar community and US SDO collaborators.

Risk Management Policy

Risk Management Strategy and Approach

Risk management shall be an ongoing effort in the eSDO project. Developers and scientists shall raise risks with the project manager and rank risks by severity, likelihood and risk index as described in the third section of this document, Risk Management Plan. All risks shall be monitored via entries in the relevant workpackage’s risk register. A summary of project risks and their status shall be reported by the project manager at the end of each quarter.

Overview

Risks likely to have a profound affect on the eSDO project (“red” risks), such as the termination of effort on an algorithm, visualization tool or data centre effort, shall be raised with the entire eSDO project through an email and either a followup telecon or consortium meeting. If necessary, the risks will also be conveyed to JSOC collaborators, UK storage and processing providers or PPARC if necessary.

Risks likely to have a serious effect on the eSDO project (“yellow” risks), such as delayed milestones, redress of post-launch support or serious negotiations with US or JSOC processing and storage providers, will result in an email and telecon between the project manager and the relevant scientist(s) and developer(s) and, if necessary, JSOC collaborators.

Risks that will not have a serious detrimental effect on the eSDO project (“green” risks) will be raised in an email between the project manager and relevant scientist(s) and developer(s).

Margins

The last six months of the project are dedicated to integration of eSDO algorithms, visualization tools and data centre work with virtual observatory, JSOC and UK hosts. This time can also be used for overrun for specific applications if those applications are approved by the project manager and advisory scientists in March 2007.

Ranking, Scoring and Index Comparison Schemes

Please see the Risk Assessment Metrics in the third section of this document, Risk Management Plan, for a detailed assessment of scoring schemes. Risks will be ranked in groups with Green (lowest rank), Yellow, or Red (highest rank) risk indices. Within each risk index, risks will be ranked according to workpackage: Solar Algorithms (highest), Data Centre work, and Visualization Tools (lowest). This rank is decided by community impact; solar algorithms affect the global solar community, data centres affect the UK solar community, and visualization tools affect enhancement to the global solar community.

Action Criteria

For “red” risks, the project manager and relevant scientist(s) and developer(s) shall postpone further work until the risk can be accepted or reduced to “yellow”. For “yellow” risks, the developers and project managers will finish work scheduled to meet immediate milestones within the next quarter and then complete the actions necessary for risk acceptance or reduction before beginning work on a new milestone. “Green” risks may be left until the final six months of the project for address.

Individual Risk Acceptance

Risks shall be accepted rather than reduced if either 1) the risk is due to an external source (such as PLS grants, JSOC, AstroGrid or external UK resource providers) or 2) the effort required to reduce the risk is longer than the time remaining on the relevant milestone (such as starting completely afresh with a solar algorithm).

Overall Risks

At the Phase A review, PPARC stated that it would prefer the eSDO project to complete 70% of its goals than to reach 70% completion on all of its goals. Therefore, risk management and ranking shall concentrate on completing the goals with the highest benefit to the solar community. Therefore, the science advisory team shall work with the project manager to determine which at-risk applications have the highest chance of being completed. “Red” risks which fall into the category of high severity but low likelihood for the community will be ranked behind “yellow” risks of high community likelihood.

Communication

Strategy and Format

The person who raises a risk will be responsible for defining the risk by making a new entry in the appropriate workpackage’s risk register. In addition to workpackage, application, date, number and title, the person should describe the risk’s cause and consequence and email the project manager. The project manager and relevant scientist(s) and developer(s) will determine whether the risk will be accepted or reduced, what action will be taken, who will take the action, and how the risk acceptance or reduction will be verified.

Escalation Strategy

Once actions have been taken to reduce or accept a risk, the risk register shall be updated and person who took the actions shall email the project manager, relevant scientist(s) and relevant developer(s). The risk status shall be reported in the project manager’s quarterly report. If time is of the essence with particular risk actions, this should be communicated by email and phone calls.

Risk Management Process and Procedures

The risk management plan below provides further guidance on the actions to be taken in dealing with identified risks.

Risk Management Plan

Risk Management Policy

Please see the second section of this document, Risk Management Policy.

Risk Management Documentation and Follow-up

Each of the three workpackages – solar algorithms, quicklook / visualization tools and data centre work – will have a risk register. Each workpackage’s risk register will contain one entry per risk raised. Information will include the name of the workpackage, the algorithm, tool or module affected, the date the risk was raised, and a sequential number from that workpackage’s list. A titled risk will be assessed for severity (negligible, major, critical), likelihood (unlikely, likely, certain), and a risk index. A risk register example is provided in this section.

Description of Risk Management Implementation

As stated in the documentation section above, any person who identifies a risk will be responsible for creating a risk register entry and alerting the project manager and relevant scientist(s) and developer(s). The risk will be assessed according to severity and likelihood, and actions to reduce or accept the risk will be determined. The person to whom the risk action is assigned is responsible for updating the risk register entry. The project manager will summarize all risks in quarterly reports.

Risk Identification and Assessment

Identification and Assessment Process and Procedures

Identifying risks will be an on-going process throughout the eSDO Phase B. Risks may be identified during many activities:

  • Developers may identify risks during everyday coding, installation / configuration or research activies.
  • Risks may be identified during regular telecoms between scientists, developers, and the project manager.
  • Risks may be identified during meetings with JSOC colleagues, eSDO consortium meetings, solar and grid conferences, or other interactions.

When a risk is identified, the person who identified the risk should fill in an entry on the relevant risk register on the eSDO wiki and email the project manager as well as any other involved developers or scientists.

Risk Assessment Metrics

Risks should be assessed for severity and likelihood using the following criteria:

  • Severity
    • Negligible – the risk will have very little affect on the eSDO project schedule (or scientific output)
    • Major – the risk will have a substantial affect on the eSDO project schedule and / or have a significant scientific impact, such as needing to use an obsolete algorithm or data resolution at an unnecessary low cadence or resolution.
    • Critical – the risk will halt any further progress on the application, necessitate striking a milestone from the eSDO project schedule, return poor scientific output, or cause unacceptably slow application performance or data returns.
  • Likelihood
    • Not likely – the risk will affect less than 25% of users or occur only if negotiations with funding councils, processing providers or storage providers fall through
    • Likely – the risk will affect between 50% and 75% of users or involve unresolved negotiations with funding councils, processing providers or storage providers.
    • Certain – the risk will affect between 75% and 100% of users or involve rejection of resource requests by funding councils, processing providers or storage providers.

The risk index is a combination of severity and likelihood:

Risk Unlikely Likely Certain
Neglible GREEN GREEN YELLOW
Major GREEN YELLOW RED
Critical YELLOW RED RED

Risk Report Information and Example

The risk register entry should include all information in the example below. References to specific code modules, URLs, documentation or meeting minutes can be appended below the register entry.

Workpackage Solar algorithms Application Magnetic Field Extrapolation Date Raised 31/01/06 Number 1
Risk Title Parallel processing machine with UK wide VO access required
Risk Raised By ElizabethAuden Severity 2 Likelihood 3 Risk Index RED
Cause and Consequence Magnetic field extrapolation algorithm requires parallel processing machine to run quickly. UCL parallel processor may not provide UK wide access through VO for post-launch hosting.
Accept / Reduce Accept Agreed by ElizabethAuden, LenCulhane, Lidia van Driel-Gesztelyi Status Assigned Date 02/02/06
Means of Verification Install mag extrap code, show access through AstroGrid workbench Action Negotiate VO use of parallel processor with UCL

Decide and Act

Risk Treatment

Outstanding risks will be reviewed during telecoms and consortium meetings. For risks marked as “reduce”, actions shall be reviewed to determine whether the risk has lessened. Risks marked “accept” will be reviewed to determine whether the severity or likelihood has changed; if either has reason, the risk will be reevaluated for acceptability or reduction. The person to whom a risk action has been assigned will be responsible for updating the risk register when the action is performed.

Risk Acceptance Criteria (Beyond Risk Management Policy)

Risks beyond this document include future provision of resources through a post-launch support grant (PLS) such as UK storage space for a data centre, processing capability for AstroGrid integrated algorithms, inclusion of algorithms in SolarSoft gateways, staff funding for user interaction and technical maintenance, and UK hosting of visualization tools. In addition, future risks also include JSOC integration of solar algorithms in the SDO pipeline, US hosting of catalogues and visualization tools, and UK access to pertinent data sets.

These risks shall be addressed individually:

  1. PLS Support
    • If storage space in the ATLAS tape facility is not funded, the UK solar community must acquire solar data directly from JSOC, either through AstroGrid (if JSOC permits installation of AstroGrid DSA module) or through VSO.
    • If UK processing capabilities are not funded for specific algorithms, those algorithms will only be available through the JSOC pipeline, SolarSoft, or from source code from eSDO instutions.
    • If algorithms cannot be integrated with SolarSoft, then they will only be available as AstroGrid tools, JSOC pipeline modules, or source code from institutions.
    • If no further staff are funded for the SDO post launch effort in the UK, then there will be no user or JSOC support for eSDO algorithms or visualization tools and no UK data centre.
    • If UK hosting of eSDO visualization tools is not funded, the tools will only be available if JSOC decides to host them in the US.
  2. JSOC integration
    • If JSOC does not include specific solar algorithms in the SDO pipelines, those algorithms will only be available through AstroGrid, SolarSoft, or as source code from eSDO institutions.
  3. US Hosting of catalogues and visualization tools
    • If the US does not host eSDO catalogues generated from large catalogues (such as global helioseismology catalogues) then either the UK must fund bandwith / storage / processing to move the relevant datasets to the UK for catalogue generation, or else the catalogues will not exist.
    • If the US does not host eSDO visualization tools, those tools will only exist through UK hosts.
  4. UK data access * If JSOC does not permit local installation of AstroGrid DSA modules, then UK data centre access to JSOC datasets must be through VSO. * If eSDO algorithms in the JSOC pipeline do not have read access to specific datasets (such as HMI time series for global helioseismology catalogues), then those algorithms will not be able to run in the pipeline.

A copy of the source and compiled code for all solar algorithms and visualization tools will be provided to PPARC, along with documentation for all algorithms, visualization tools and data centre / catalogue configuration work. Code for algorithms and visualization tools will also be provided to JSOC.

Risk Management Tools

Risk management will be documented and maintained using the risk register on the eSDO wiki.

Risk Monitoring and Communication

Operational Approach

Once a risk has been identified, the risk will be addressed by the project manager at least once a month through telecoms, developer meetings or consortium meetings.

Risk Report Format and Responsibility

The risk report will take the form of a risk register entry described above. All risks will be collated in a risk report by the project manager at the end of each quarter. Green risks should be raised between scientists or developers and the project manager. Yellow risks should be raised between the project manager and the relevant scientists and developers. Red risks affect the entire eSDO project team.

-- ElizabethAuden - 02 Feb 2006


This topic: SDO > RiskPolicyAndPlan
Topic revision: r3 - 2006-02-02 - ElizabethAuden
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback