This is an HTML version of an attachment to the Freedom of Information request 'Guides'.


 
 
 
 
 
 
 
 

CANCELLATION OF LMDMA REFERRAL NOTIFICATION 
 
 
From 
 
LMDMA team 
 
 
 
To 
 
Jobcentre/provider 
 
Name of claimant 
 
 
 
NI Number 
 
 
 
Date of 
 
Transgression 
 
 
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 
 
 
 
Date 
 
 
 
 
 
 

 
 
DMAS Contingency Guide 
Scope 
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.   
Introduction 
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 
experiencing problems. 
  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 
information. 
  Notify the Senior Responsible Officer for DMAS, Carolyn Taylor; (redacted under 
exemption 40) 
  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 
LMS.  
  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. 
Gradual failure 
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 
basis.  
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. 
Sudden failure 
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.  
Contingency Arrangements 
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 
as required.   
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. 
DMA Referrals 
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. 
Referral Maintenance 
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; 
  AR code; 
  Date of transgression; 
  Decision; 
  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 
central repository.  
34. A simplified decision notification template and a cancellation of decision template can be 
accessed via the following links: 
  LMDMA Decision Notification 
  Cancellation Notification 
Server Sharing 
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 
unchanged. 
Management Information 
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: 
  Referrals received; 
  Decisions made by type; 
  Cancellations. 
  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)  .  
Recovery Process 
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 
 
 
From 
 
LMDMA team 
 
 
 
To 
 
Jobcentre/Benefit Centre/provider 
 
Name of claimant 
 
 
 
NI Number 
 
 
 
Date of 
 
Transgression 
 
 
Reason for referral 
 
 
 
AR Code 
 
 
 
JSAPS Code 
 
  
 
Date of referral 
 
 
 
My decision in respect of the above referral is: 
 
 
Allowed 
 
 
 
 
 
 
 
 
 
Disallowed 
From 
 
To 
 
 
 
 
 
 
 
Sanction 
From 
 
To 
 
 
 
 
 
 
 
 
Reserved 
From 
 
To 
 
 
Reason for decision 
 
 
 
 
 
 
 

 
Name of LMDM 
 
 
 
Date of decision 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 
DMAS CONTINGENCY GUIDE 
MI RECORD LOG 
 
Week Ending  

 
Site 
 
LMS Office Mnemonic 
 
 
AR 

Referral 
Decision 
Code 
Received 
 
Disallowed 
Sanctioned 
Allowed 
Reserved 
Cancelled 
 
 

 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 

 
 
 
 
 
 
 

 
 
DMAS CONTINGENCY GUIDE 
REFERRAL RECORD LOG 
 
Month 

 
Year 
 
Site 
 
LMS Office Mnemonic 
 
 
Date of  Contingency  Source 

Claimant Details 
LMS 
Doubt 
AR Code 
Date of 
Decision 
Date 
Receipt 
Reference 
Surname 
Forename 
NINO 
Ref 
Type 
Transgression 
Cleared