Struggling with Data Out

Over and above these relatively minor changes, for myself as lead developer and the consortium co-ordinator, the first phase of 'live' use of Hublink was dominated by issues related to reporting for the commissioner, London Borough of Tower Hamlets. Although being able to provide granular reports was a main motivator behind Hublink, the main part of the the actual reporting specification had not arrived from the commissioner until the very end of December 2013, with the equalities reporting categories not arriving until the beginning of February – well after launch. Therefore, in addition to the need to add fields for specific data and make existing fields compulsory, it was at this relatively late stage that we embarked in earnest on providing data outputs for the consortium.

I think the idea is that you would use Hublink to refer but actually the reality is that you need to still pick up the phone and have a

conversation, and then use Hublink as a way of getting information to them, rather than relying on it...and thats fine; its not a negative thing, actually you need that contact really. Karen Linnane 13

March 2014

Textbox 33: Use for referral

The need to do this work was not a surprise to the development team and since the beginning of the project we had reassured the staff at Real that so long as the data was collected in granular form it would always be possible to extract it. While this held true in the sense that the correct information was being collected and held in Hublink, we underestimated the difficulties in extracting the data in the exact format required by the commissioner in a user-friendly way. Textbox and 35 and 34 shows that staff were aware that the granularity of the data was sufficient and potentially useful. Both myself and the project co-ordinator at Real were also unprepared for the extent that this quantitative data requirement can be open to interpretation. For example: In practice, many clients worked with consortium organisations on more than one issue, and so had more than one 'project' or 'enquiry' logged. So when the commissioner asks for a

breakdown of cases by domain of service per client, we found that it was open to interpretation whether a client with two different projects with two different domains should be counted once or twice. Dealing with this issue was made more complex by the fact that the partners were still struggling to incorporate Hublink into their own workflows, and therefore and data was not always being entered consistently or on time.

It was also here that we came up against the limitations of the web-based configurability of the Drupal system. Drupal has a powerful and query-building tool called 'views' which has the capability to create good user interfaces for selecting and filtering data. However, the complexity of the data and the need for more than one level of aggregation was more than Views could manage. Bugs appeared in the community contributed modules as they were being pushed beyond their intended use and some custom code was needed to generate the correct data. Drupal could easily deal with the volume of data, but the complexity of the relationships between the data stretched its capabilities as a content-management framework.

What tends to happen in commercial databases is that people just start to miss stuff out; because that’s not how I work so I just won't put it in, and what I found doing reports from databases is that you have a lot of

information missing which I’m semi-confident that we won't have, because all the information we are asking people to collect is what we need and what we know they can collect, so I'm hopeful that our reports, though I think there is more work to be done on reports, I think that the information that we are going to get should be what we specifically need. Cathie Duncan 13 March

2014

Textbox 34: Reflection on reports

The benefit of hublink is that we can ask for exactly what we need to pull out of it. its all there. in other

databases it would have been there but it would have been so intermingled that it would have been virtually impossible to extract it.

Cathie Duncan 13 March 2014

Textbox 35: Reflection on use for reporting

158

There were various ways that the reporting issues could be approached so we discussed with

Real how we might proceed. We discussed two options . One was that we could supply reports

specific to each output required by the commissioner. The second option was to supply downloads of 'raw' data in spreadsheet form that could then by manipulated in a programme such as Excel of Open Office to provide the required information. The advantages of the second option as more transparency over the exact data that is in the system that would enable Real and partners to gain an overview of the data, so it would possible for them to check for gaps and omissions that might be attributable to the system either not working properly or data not being recorded. The raw data downloads would have the added advantage that same data should be able to be used for changed or additional reporting requirements, therefore giving Real more independence and control over the data. This suggestion could be seen as a way of drawing on the practices of tailorability, though in this case using tools that are outside of our own system. Indeed spreadsheets have been cited as good examples of end-user tailorable applications (Nardi 1993; Gantt & Nardi 1992) (Ko et al. 2011). The disadvantage of course is that the burden of work to write formulas for the spreadsheet would fall on Real.

At this point, Real opted for the raw data option and so work focussed on making this as complete as possible. We worked on this up until the first set of reports were due in June 2014, and beyond. We also made downloadable reports available to each organisation manager.

To summarise this phase, there were many difficulties, especially the first three months.

Adoption was difficult (Textbox 36) and the user interface did not suit everybody. Terminology used in Hublink did not always match the terminology used by case workers which led to confusion around the user interface.

It was obviously particularly hard in this situation with the consortium, where we had people in different organisations, and we needed to take some short cuts on the collaborative working. To have done that really properly would have been a massive project, but then not involving some people at that stage means that we are still... yes catching up but it was, I'd still say, its significantly better than the traditional method of starting with someone trying to write a spec. Mike Smith 9April 2014

Textbox 36: Reflection on difficulties with adoption

The appearance of the application, that was more like a website or web survey than what people were used to as a database was a barrier for some of the partners though was popular with others. For reasons that we will return to, partners were not involved early in the process and that led to late-coming requirements and the problems were exacerbated by the late coming reporting templates. Nevertheless, the system itself was quite robust due to its basis in a well- tested Open Source framework. Added to that, the depth of knowledge that the staff at Real had gained from their involvement in the design process made it possible for the entire group to work as a team and tackle the issues that arose.

5.4.6 Reflections on phase 4