CANCELLATION OF LMDMA REFERRAL NOTIFICATION
Name of claimant
Reason for referral
Date of referral
The above referral has been cancelled because:
It is more than 10 days since the Jobcentre was asked to respond to an enquiry
It is more than 10 days since the provider was asked to respond to an enquiry
It has been cancelled at your request.
No claim on date of sanctionable failure
Cancelled for other reason (please state reason)
Please re-refer if a decision is still required.
Name of LMDM
DMAS Contingency Guide
1. The scope of this product is limited to detailing the contingency procedures to be invoked
should the Decision Making and Appeals System (DMAS) be unavailable or unusable. It
includes certain clerical and/or off-system processes where this activity is critical to the
operation of the LMDMA process.
2. Action to take in the event of failure of other relevant existing IT systems such as the
Jobseeker’s Allowance Payment System (JSAPS), Decision and Automated Referral Toolkit
(DART) or Labour Market System (LMS) are out of scope for this product. Existing
contingency arrangements for each of those systems should be followed.
3. Incidents involving premises and staffing failures etc should be covered in local business
continuity plans and are also out of scope for this product.
4. DMAS is used to support the Labour Market Decision Making and Appeals (LMDMA)
process between Work Services Directorate (WSD) and Benefit Directorate (BD).
5. The system is used by staff responsible for the decision making and appeals process.
Historically, these are centralised teams based in Benefit Centres. Only around 60
designated sites nationally have DMAS built on their server. As there is no virtuality within
DMAS, a site can only see cases recorded and decisions made on their local system.
6. DMAS was sized for one million cases but figures supplied by HPES on 22 April 2013
advised that it now houses a caseload of three million and is now three times over capacity.
System performance is poor, characterised by slow response times. Although the system will
not crash, it will work ever more slowly until it becomes unusable but to the user, there will be
no discernable difference between the two scenarios.
7. There is a Service Level Agreement with HPES whereby the loss of DMAS is treated as a
priority 1 incident with the aim of restoring service the same day or as soon as possible
thereafter. However, as any loss of functionality is likely to be as a result of over capacity, this
may be outside the scope of the SLA. This guide is therefore based on the assumption that
functionality cannot be readily restored.
8. Because of the lack of virtuality, some sites with a larger server load may have no
adequately functioning DMAS system whilst others may be able to continue to work normally.
It is unlikely; therefore, that the situation where the contingency plan needs to be invoked will
be reached at the same time for each site.
9. To date, as much action as possible to improve system performance has been taken
behind the scenes (such as a purge of old cases) but nothing has made a significant
difference. At the time of writing, there are no system enhancements planned for DMAS and
no available funding identified. There is very little more, if anything, that can be done tactically
to improve DMAS performance.
10. The purpose of this product is to set out in a single plan, the business contingency
procedures for all work areas impacted by a DMAS ‘failure’. Failure may be classified as:
gradual but increasingly slow running of the system until it becomes, for all practical
purposes, unusable; or
a sudden and catastrophic loss of system functionality.
Invoking Contingency Arrangements
11. Unless otherwise delegated, the LMDMA Manager will act as the Contingency Manager
and take responsibility for the day-to-day management of the contingency.
12. The role of the Contingency Manager will be to:
Notify and liaise with IT to ascertain seriousness of system problems or unacceptable
slow running, likely length of duration, actions to take etc; In the first instance any loss
of DMAS whether through slow running or crash should be reported as an incident to
the DWP Service Desk on 0800 9754000 (redacted under exemption 40) by each site
Decide, in the light of all available information, whether to invoke contingency plans;
Notify Brendan Cronie (redacted under exemption 40), DWP WSD National
Performance Reporting Team, that DMAS contingency plans are being invoked and
that MI will be captured clerically. Please see Management Information for further
Notify the Senior Responsible Officer for DMAS, Carolyn Taylor; (redacted under
Notify all relevant Jobcentres, Benefit Centres and providers:
that contingency plans have been invoked;
if known, when normal procedures should be resumed;
of changes to procedures as a result of the contingency;
ensure Jobcentres are aware of the need to fully record all relevant referral details in
To this end, a local contingency contact list should be established and maintained.
13. The decision to invoke this contingency plan should be made by the head of LMDM,
Graham Dumbell, (redacted under exemption 40) or deputy Mike Kelly (redacted under
exemption 40) in his absence.
14. DMAS performance at each LMDMA site may deteriorate to such an extent as to be
practically unusable. As the level of available functionality may therefore differ from site to
site, the decision to invoke this contingency plan will need to be made locally on a site by site
15. However, as system deterioration will be apparent for some time, certain actions will need
to take place ahead of functionality being lost completely:
all adverse decision records will need to be stored locally in the event of a request for a
reconsideration or appeal of the decision being received. It can be determined locally
whether the records are printed or save electronically.
establish a ‘recovery log’. See Recovery Process for further information;
if sites require details of which regulation(s) apply to each decision, these will need to
be compiled and retained in a shared folder or as determined locally;
any other DMAS outputs which are required locally which will not be available in the
event of a system failure should be copied and stored locally such as:
letters such as the WP12 and ES86 etc;
any local paragraph templates;
establish a local contingency contact list;
establish a ‘referral record log’ and a ‘recovery log’.
16. It will be the responsibility of each site to monitor their system functionality and ensure that
the actions described above are taken in sufficient time before the system is lost.
17. Because of the likelihood that each site may experience functionality deterioration at a
different rate to others, it will not be possible to prescribe in this product when each site
should begin preliminary action or when to invoke contingency arrangements. This will be
down to local judgement.
18. In the event of a sudden and unexpected loss of DMAS functionality, the Contingency
Manager should invoke contingency arrangements.
19. To enable the site to continue functioning in the event of a sudden DMAS failure, it is
recommended that sites establish referral and recovery logs, MI collation templates, save
their required local paragraph templates and establish a contact list now.
20. Once contingency arrangements have been invoked, do not input any new cases into
DMAS although existing cases should be completed where possible. If there is still any
functionality remaining, this may be enable users to view, access and print decision records
Exporting of work
21. Once the likely duration of the loss of DMAS functionality has been determined, a decision
will need to be made by the LMDMA Manager in conjunction with Service Planning and
Delivery Assurance Team as to whether to export work to another site.
22. The type and quantity of work to be exported and for how long will need to be determined.
23. When determining whether to move work, consideration must be given to the effect this
will have on the DMAS server capacity at any possible alternative locations.
24. It is assumed that the current process of making DMA referrals will continue.
25. As the referral process should be unaffected by the loss of DMAS, Jobcentre staff will still
be able to refer using DART and/or clerically and providers will still be able to refer direct via
email and/or clerically.
26. Upon receipt of the DART or clerical referral, the LMDMA admin team will need to record
receipt on a Referral Record Log. This will enable the LMDMA Manager to manage
workflows, for case management purposes and to aid in the recovery process.
27. As a minimum, the log should capture the following information:
Date of receipt;
Name and NINO of the claimant;
A unique identification number for that case;
Where the referral originated from;
Reason for doubt;
Date of transgression;
Date of clearance.
28. LMDMA teams may also wish to record additional data of their own as decided locally
such as the name of the LMDM to whom the case is allocated.
29. Forwarding of the case to the designated LMDM for action and decision determination
should continue as per current procedures. Enquiry/decision templates will need to be
accessed by the LMDM as required.
30. As the DMAS-LMS link will be broken, LMS will need to be updated manually with the
decision. It is recommended that where LMDMA teams have the access to do so, they
undertake this task. This should, however, be the subject of local liaison so that the Jobcentre
know whether it is being done by the LMDM and whether to expect to receive a decision
notification. A Benefit Centre notification may still be required, however, depending on the
type of case.
31. A local B/F file will need to be established so that timely action can be taken on cases for
which an enquiry has been sent on which the ‘return by’ date has matured.
32. Copies of all documents used in the decision making process will need to be printed out
and stored locally (or stored electronically) in case of a request for a reconsideration or
appeal and to aid the recovery process.
Letters and Notifications
33. As detailed previously, paragraph and letter templates which the LMDM will need in order
to raise enquiries with the claimant will have been stored in a local shared folder or in a
34. A simplified decision notification template and a cancellation of decision template can be
accessed via the following links:
LMDMA Decision Notification
35. An alternative to adopting an entirely clerical process may be ‘server sharing’. This is
where one site uses the server of another. The scope, usage and limits of sharing another
site’s server will need to be negotiated and agreed locally.
36. Where the sharing of a server has been agreed, it is recommended that usage by the
‘guest’ site is kept to a minimum and perhaps only for the use of printing letters and
notifications. It is also recommended that the guest site does not save anything on the host
server as this may, in time, have an adverse impact on the functionality of the host server.
Copies of any printed output issued will need to be obtained and saved with the rest of the
clerical decision documents (or saved electronically).
Explanations, Reconsiderations and Appeals
37. Sites will need to start producing and retaining clerical or electronic copies of all relevant
decision documents before the anticipated loss of their system. This is because the decision
details will be required in order to undertake a detailed explanation or reconsideration. Should
the case go to appeal, copies of all the decision documents used in making the decision will
be required and these may no longer be obtainable from DMAS. Without the relevant
decision documents, the case will not be able to go to appeal and will need to be allowed.
38. The process for undertaking explanations, reconsiderations and appeals work remains
39. The current process of sending weekly MI on intake and cases outstanding to the Benefit
Directorate Service Planning and Delivery Assurance Team each Monday will continue.
However, without DMAS, this count will need to be performed clerically. Although the ‘referral
record log’ will be able to be used for this purpose, only the number of cases received since
loss of DMAS will be shown. Sites will have to ensure that they have robust processes in
place to accurately capture current work.
40. HPES currently gather additional MI on the number and type of sanction referrals and
decisions made. With the loss of DMAS functionality, this MI will need to be captured
clerically. Please see MI Record for a copy of the MI Record template. The specific MI which
needs to be captured is:
By each AR code, the number of:
Decisions made by type;
Your site LMS Office Mnemonic.
41. MI returns should be collated and sent on a weekly basis by email to Brendan Cronie
(redacted under exemption 40) at the team’s generic email in-box which can be found in
the global address list as DWP WSD National Performance Reporting Team (redacted
under exemption 40) .
42. Once DMAS functionality has been restored, cases operated wholly clerically should not
to be input into DMAS. Those cases which were started before functionality was lost should
be completed on DMAS.
43. To aid in the recovery process, sites should establish a ‘recovery log’ in which all of the
data they will need to complete the case on DMAS should be recorded. If desired, the
‘referral record log’ and ‘recovery log’ may be merged.
44. Exactly what form the log takes or whether saved case documents are used will be down
to local discretion.
45. Alternatively, and depending on the length of the loss of DMAS, number of cases and
storage capacity, sites may wish to retain the decision documents locally and use these to
build the case on DMAS once the system is restored.
LMDMA DECISION NOTIFICATION
Name of claimant
Reason for referral
Date of referral
My decision in respect of the above referral is:
Reason for decision
Name of LMDM
Date of decision
DMAS CONTINGENCY GUIDE
MI RECORD LOG
LMS Office Mnemonic
DMAS CONTINGENCY GUIDE
REFERRAL RECORD LOG
LMS Office Mnemonic
Date of Contingency Source