Report - Fire Brigades Union

SECTION B — FIRE AND RESCUE SERVICE POLICY
40) To give some examples: business parks that are currently
built generally identify the different premises as Unit 1,
Unit 2 etc. This is how these buildings appear in the NLPG
database. Once let the building now has a name and may
change hands several times even 1 year. These names do
not appear on the NLPG database for some considerable
time – if ever – and the company name provided will result
in no match against the gazetteer when searched by the
operator at the RCC. Invariably the unit number will not be
given or known and does not form part of the new
address. To overcome this each FRS will have to generate
an “extra” database containing this information, maintained
by them, a not inconsiderable task.
41) Another example is that many towns and cities have areas
within them, these areas form part of the address to the
local inhabitant. In one FRS there are nine areas in one
town which do not exist in the NLPG database, as such
every property in those areas will have to become part of a
local database for that FRS to allow matching against the
supplied address. The only alternatives are to get the NLPG
database amended (only allowed through local government
request and a lengthy procedure) or to get the residents to
change the way they report addresses. It is our belief that
it is almost certainly impossible to do either within the
timescales involved.
42) There will be many similar examples that will come to light
as the database generation continues and practical use of
NLPG emerges, these items should have been known and
dealt with at the outset.
43) The transfer of information is time consuming and
cumbersome. It also has to be provided by FRSs and is out
of scope work.
DCMT1 and DCMT2
44) These are the toolkits for converting and transferring the
FRS’s existing data into a format that EADS can use to link
the FRS related data to the NLPG database and also to
generate the “extra” databases that contain the entries
that do not exist in the NLPG database.
45) Problems with the DCMT1 toolkit became apparent to fire
and rescue services in the summer of 2008 and has played
a major role in the delays. We understand these problems
only became apparent after CLG, as the Project Managers,
had signed off the toolkits as meeting the contract
specifications and it was then rolled out FRSs.
46) Up to that point CLG at imposed itself as the go-between
linking EADS to the FRS. We understand it made a point of
ensuring there was little or no direct contact between the
contractors and other stakeholders meaning the problems
only became apparent after the toolkits had been cleared
for release to FRSs.
47) This issue of direct collaboration was addressed – belatedly
– in the summer of 2009 with the creation of Solution
Establishment Workshops, the first attempt at genuinely
collaborative working. But what it highlights is that this was
not happening before and only started when the Project
ran into serious trouble with delays mounting.
48) The DCMT1 toolkit may now be substantially complete,
albeit nearly two years late. Some of the issues have been
inexcusable. But in the absence of close contact between
EADS and the FRSs – a decision taken by CLG as Project
Managers – it was perhaps inevitable.
49) Project Managers should have known that the larger
authorities would have enormous data sets and for the
initial releases to appear to have problems handling large
data sets is ridiculous. The other reported issues show the
poor quality systems at Departmental Project Management
level that allowed these to get to the end user.
50) Again the Project Management systems and methodology
(Prince 2) should have picked these items up and managed
them rather than supplying poor quality tools – albeit to
specifications agreed and signed off by CLG - within the
project life cycle.
51) Switching the mobilising system from Ericcson to
Intergraph/ICAD may produce further problems with the
DCMT1 toolkit. That remains to be seen.
52) CLG has consistently under-estimated the amount of work
needed to be completed by FRSs to identify, cleanse and
capture the data even with the toolkit working perfectly.
This is at least three to five years of work.
53) There is limited and reducing capacity within the fire
service to deliver this quickly – the ability is there, simply
not the number of control personnel needed to carry out
the task in addition to their existing workloads.
54) Whilst DCMT1 is used to identify what FRS address data is
contained within NLPG, and what is not, it is the more
complicated DCMT2 that “binds” this information together.
Only time will tell whether similar issues will emerge with
DCMT2 as did with DCMT1. It is imperative that mobilising
arrangements for a life-saving emergency service such as
that for the fire and rescue service aren’t changed without
being fully validated and tested beforehand. Testing “in the
field” is not a professional option to adopt.
55) It would be surprising, given the complexity of the technical
challenges, if they did not. There may also be issues relating
to the switch to Intergraph I/CAD as the mobilising system.
56) We are aware, given the delay to the roll out of the
DCMT1 toolkit, that many FRSs have not completed the
work and some are only at the early stages of starting the
work relating to the use of DCMT1. Without this data it is
difficult to conceive how any meaningful testing of the
system can take place.
57) Performance of this system will depend on the volume of
data searched and a system that works with a small data
set may not even work, or work as well, with a large data
set if the hardware is not specified correctly.
FBU Annual Report 2011 67