##Risk Description

= Risk Description =

## Detailed description of this risk and its possible implications.
## E.g. If one of the car's tires suffers a puncture, we may run off the road.

We wish !HelpDesk to be first line of defense on the deployed final system. Unfortunately we have experience of systems developed within the library, where the development group has to do end-user support. 

Note that this does not really impact the project much, but is important to the department as such.

== When to react? ==

## When must we respond to the risk? E.g. When the event occurs or already when we see the warning signs?
## E.g. We must react if we hear a hissing sound.
When support tasks start going directly to the developers.


== Reaction ==

## Detailed description of how to react on the risk and which actions to take, if it is imminent.

## There exists 4 basic reactions:
## 1: Accept the risk.
## 2: Eliminate the cause to the risk.
## 3: Mitigate the probability or the consequence of the risk.
## 4: Delegate the risk to another party, e.g. by outsourcing it or take out insurance for it.

## E.g. We accept the risk and change the tire if we suffer a puncture.
Start communication with HelpDesk about what is required to move the support tasks to HelpDesk. Take steps to better documentation and better support tools. Make training sessions with HelpDesk. Attempt to communicate to end users that support goes through HelpDesk.

== Responsible Persons ==

The below persons are responsible for continuously monitoring and acting on this risk:

## Add a bullet list with links to the wiki pages of the responsible persons here:
## E.g.
## * [:JohnDoe: John Doe]